Transport block size indication for an ambient internet of things device in wireless communications

Abstract

Various techniques pertaining to managing transport block sizes between a device and a reader of an ambient Internet of Things (AIoT) system are described. In a method of data transfer, a device of the AIoT system indicates to a reader of the AIoT system a maximum size of any physical-layer data block receivable by the device under a set of criteria. In response, the device receives from the reader a physical-layer data block with a size not exceeding the maximum size.

Description

TRANSPORT BLOCK SIZE INDICATION FOR AN AMBIENT INTERNET OF THINGS DEVICE IN WIRELESS COMMUNICATIONSCROSS REFERENCE TO RELATED PATENT APPLICATION

[0001] The present disclosure is part of a non-provisional patent application claiming the priority benefit of PCT Application No. PCT / CN2024 / 108552, filed 30 July 2024, the content of which herein being incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure is generally related to wireless communications and, more particularly, to negotiation of communication parameters by a device and a reader in an ambient internet of things (AIoT) system.BACKGROUND

[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.

[0004] 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. An AIoT interface may be realized by a protocol stack including, 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 (from the perspective of the PHY layer, e.g., MAC layer and above) 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.

[0005] Data exchange between the reader and the device may take place in either of 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.

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

[0007] However, at the time of the present disclosure, details on how a device and a reader negotiate a transport block size that can be used for a particular transmission have yet to be defined. Therefore, there is a need for a solution of negotiating and indicating a size of a transport block for transmission on an AIoT interface, between a device and a reader.SUMMARY

[0008] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0009] An objective of the present disclosure is to provide schemes, concepts, designs, techniques, methods and apparatuses pertaining to negotiating and indicating a size of a transport block for transmission on an AIoT interface, between a device and a reader, in wireless communications.

[0010] In one aspect, a method of data transfer in an AIoT system may involve a device of the AIoT system indicating to a reader of the AIoT system a maximum size of any physical-layer data block receivable by the device under a set of criteria. The method may also involve the device receiving, responsive to the indicating, from the reader a physical-layer data block with a size not exceeding the maximum size.

[0011] In another aspect, a method of data transfer in an AIoT system may involve a device of the AIoT system indicating to a reader of the AIoT system a maximum size of any physical-layer data block transmittable by the device under a set of criteria. The method may also involve the device receiving from the reader an indication of radio resources responsive to the indicating. The method may further involve the device transmitting to the reader a physical-layer data block using at least a subset of the radio resources. A size of the physical-layer data block may be less than or equal to the maximum size.

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

[0013] The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation to clearly illustrate the concept of the present disclosure.

[0014] FIG. 1 is a diagram illustrating a portion of an exemplary AIoT system in which various proposed schemes in accordance with the present disclosure may be implemented.

[0015] FIG. 2 is a diagram illustrating an exemplary set of protocol stacks for the interfaces of an AIoT system under a proposed scheme in accordance with the present disclosure.

[0016] 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. under a proposed scheme in accordance with the present disclosure

[0017] 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 under a proposed scheme in accordance with the present disclosure.

[0018] 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 under a proposed scheme in accordance with the present disclosure.

[0019] 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 under a proposed scheme in accordance with the present disclosure.

[0020] 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 under a proposed scheme in accordance with the present disclosure.

[0021] 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 under a proposed scheme in accordance with the present disclosure.

[0022] 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 under a proposed scheme in accordance with the present disclosure.

[0023] 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 under a proposed scheme in accordance with the present disclosure.

[0024] FIG. 11 shows dynamic TB size negotiation on the AIoT interface, including paging, negotiation request, assessment, final indication, and data transfer under a proposed scheme in accordance with the present disclosure.

[0025] FIG. 12 shows upper layer segmentation adaptation on the AIoT interface, including paging, segmentation request, data segmentation, and data transfer under a proposed scheme in accordance with the present disclosure.

[0026] FIG. 13 is a block diagram of an example communication system under a proposed scheme in accordance with the present disclosure.

[0027] FIG. 14 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure.

[0028] FIG. 15 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0029] Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. Overview

[0030] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to negotiating and indicating a size of a transport block for transmission on an AIoT interface, between a device and a reader, in wireless communications. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.

[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] FIG. 1 shows a portion of an exemplary AIoT system 100. The AIoT system 100 as shown involves at least two devices, namely a first device (denoted as ” Device 1” in FIG. 1) and a second device (denoted as “Device 2” in FIG. 1) , which are intended to be low-cost and low-power or even battery-less (for example, powering themselves via energy harvesting) , and the following network elements / nodes associated with a cellular / mobile communication network: (1) a user equipment (UE) -type reader, which communicates over an AIoT interface with the first device and which is embodied in a UE; (2) a base station (BS) such as a gNode B (gNB) that serves the UE-type reader over a Uu interface; (3) a BS-type reader, which communicates over an AIoT interface with the second device and which is embodied in a BS; (4) a controller (also known as an “AIoT function” ) , 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 5th Generation (5G) and / or 6th Generation (6G) core network (CN) ; and (5) 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 FIG. 1, 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] FIG. 2 shows an example scenario 200 of an exemplary set of protocol stacks for the interfaces of an AIoT system similar to that shown in FIG. 1. In scenario 200, a device and a reader communicate on an AIoT interface via an AIoT physical (PHY) layer and an AIoT medium access control (MAC) layer. The reader and a controller communicate via a reader application protocol (R-AP) on a logical A-RC interface, supported by network and / or Uu interfaces (indicated in FIG. 2 as “NW / Uu” ) , the details of which 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 a UE hosting the reader. The controller and an AF communicate via an AIoT API over a logical A-CA interface, supported by a service-based interface (SBI) protocol stack the details of which 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, include 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 the present 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 (e.g., application layer) between the AF and the device.

[0034] FIG. 3 shows a flow diagram of an exemplary procedure 300 on the AIoT interface for device-terminated (DT) data transfer. That is, procedure 300 may pertain to delivery of data from a reader to a 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 signaling message) , the reader sends an AIoT paging message to the device. Steps 2, 3, and 4 may 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] FIG. 4 is a flow diagram showing an exemplary procedure 400 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 a device (e.g., due to the arrival of data from upper layers or the generation of a signaling message) , a 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) , to complete the random access procedure. In step 3, the reader sends data in the R2D direction, completing the transfer of data to the device.

[0036] FIG. 5 is a flow diagram showing an exemplary procedure 500 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 a device, a reader sends an AIoT paging message to the device. Steps 2, 3, and 4 may 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, to complete 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 FIG. 5. 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 may involve a transmission from the reader to the device requesting D2R data transmission, and a following sixth step may involve a transmission of the requested D2R data from the device to the reader. A further following seventh step may involve an acknowledgement of the D2R data, sent from the reader to the device.

[0037] FIG. 6 is a flow diagram showing an exemplary procedure 600 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 a device, a 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, to complete 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 FIG. 6. 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 may involve a transmission from the reader to the device requesting D2R data transmission, and a following fourth step may involve a transmission of the requested D2R data from the device to the reader. A further following fifth step may involve an acknowledgement of the D2R data, sent from the reader to the device.

[0038] FIG. 7 is a flow diagram showing an exemplary procedure 700 on the AIoT interface for DT data transfer with a 4-step random access procedure including transport block size information in Msg3, under a proposed scheme in accordance with the present disclosure. Steps 1-3 may be similar as or identical to that described with respect to FIG. 3 (paging / Msg1 / Msg2) . In step 4 (Msg3) , in addition to the device identifier, the device may include 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 (e.g., an explicit block size) or a selection from an enumerated set of candidate values. As another example, the TB size information in Msg3 may comprise a flag or enumeration with two or more values, representing agreed-upon concepts of a “small” or “large” TB, a “small”  /  “medium”  / “large” TB, and so on (e.g., a quantized block size such as small, medium or large, with defined thresholds) . As a third example, the TB size information in Msg3 may comprise an indication of a maximum reception / transmission 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, thereby 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 millisecond (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 energy 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 the present disclosure for D2R transmission.

[0041] FIG. 8 is a flow diagram showing an exemplary procedure 800 on the AIoT interface for DT data transfer with a 2-step random access procedure including TB size information in Msg1, under a proposed scheme in accordance with the present disclosure. Step 1 may be similar as or identical to that described with respect to FIG. 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 with respect to FIG. 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. That is, while the TB size indication may be provided in an explicit field in a message (e.g., a D2R message) , alternatively such indication may be provided implicitly in the choice of transmission parameters, such as a particular choice of Msg1 radio resources implying a particular value of the size indication. 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 is used 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, thereby allowing the device to receive the data successfully (with an acceptably high probability) according to the constraints affecting the supportable TB size.

[0042] FIG. 9 is a flow diagram showing an exemplary procedure 900 on the AIoT interface for DO-DTT data transfer with a 4-step random access procedure including TB size information in Msg1, under a proposed scheme in accordance with the present disclosure. Step 1 may be similar as or identical to that described with respect to FIG. 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 with respect to FIG. 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 signaling, PHY layer signaling, or a combination of MAC and PHY layer signaling. 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, to complete 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 may involve a transmission from the reader to the device requesting D2R data transmission, and a following sixth step may involve a transmission of the requested D2R data from the device to the reader. A further following seventh step may involve 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] FIG. 10 is a flow diagram showing an exemplary procedure 1000 on the AIoT interface for DO-DTT data transfer with a 2-step random access procedure including TB size information in Msg1, under a proposed scheme in accordance with the present disclosure. Step 1 may be similar as or identical to that described with respect to FIG. 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 with respect to FIG. 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 signaling, PHY layer signaling, or a combination of MAC and PHY layer signaling. 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. 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 in case 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 or a subsequent D2R transmission, 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] FIG. 11 is a flow diagram showing an exemplary procedure 1100 on the AIoT interface for dynamic TB size negotiation for R2D data transmission, under a proposed scheme in accordance with the present disclosure. Steps 1-2 may be similar as or identical to that described with respect to FIG. 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, thereby allowing the device to receive the data successfully according to the constraints affecting the supportable TB size.

[0047] This proposed scheme 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, thereby reducing the likelihood of retransmissions with different TB sizes. Padding is placed at the end of the MAC PDU if present, and the presence and length of padding may be 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 may be similar to that in FIG. 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 a subsequent step 7 (not explicitly shown in FIG. 11) , 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] FIG. 12 is a flow diagram showing an exemplary procedure 1200 on the AIoT interface for upper layer segmentation adaptation for R2D data transmission, under a proposed scheme in accordance with the present disclosure. Steps 1-2 may be similar as or identical to that described with respect to FIG. 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, thereby 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 proposed scheme 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, thereby 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 ensures that the segmented data fit within the TB size, and the padding is correctly handled. Furthermore, the MAC PDU structure may be maintained, where the last MAC subPDU for a 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 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 may be similar as or identical to that described with respect to FIG. 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. Feature Highlight

[0052] In view of the above, key features of various proposed schemes in accordance with the present disclosure are highlighted below.

[0053] In one aspect with respect to DT data transfer, a method of transferring data operable at a device of an AIoT system may involve certain operations, including: (a) 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; and (b) receiving, from the reader, at least one physical-layer data block.

[0054] In some implementations, the set of criteria may include one or more of the following: (i) a minimum decoding probability, (ii) a minimum anticipated signal-to-noise ratio, (iii) a maximum data rate, (iv) a maximum reception time, (v) a maximum probability of symbol error, and (vi) a maximum probability of block error.

[0055] In some implementations, the indicating may involve sending the maximum size in a Msg3 transmission of a random access procedure. Alternatively, or additionally, the indicating may involve sending the maximum size in a Msg1 transmission of a random access procedure.

[0056] In some implementations, the maximum size may be selected from a set of possible data block sizes. Alternatively, or additionally, the maximum size may be indicated as an explicit number of bits or octets. Alternatively, or additionally, the maximum size may be indicated as a maximum reception time.

[0057] In one aspect with respect to DT data transfer, a method of transferring data operable at a reader of an AIoT system may involve certain operations, including: (a) sending, to a device of the AIoT system, a paging message; (b) receiving, from the device, a maximum size of a physical-layer data block; and (c) transmitting, to the device, at least one physical-layer data block of size less than or equal to the maximum size.

[0058] In some implementations, the receiving may involve receiving the maximum size in a Msg3 transmission of a random access procedure. Alternatively, or additionally, the receiving may involve receiving the maximum size in a Msg1 transmission of a random access procedure.

[0059] In some implementations, the maximum size may be selected from a set of possible data block sizes. Alternatively, or additionally, the maximum size may be indicated as an explicit number of bits or octets. Alternatively, or additionally, the maximum size may be indicated as a maximum reception time.

[0060] In some implementations, the data block may include a set of application data bits and zero or more padding bits.

[0061] In one aspect with respect to DO-DTT transfer, a method of transferring data operable at a device of an AIoT system may involve certain operations, including: (a) 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; (b) receiving, from the reader, an indication of radio resources; and (c) transmitting, to the reader, at least one physical-layer data block. The at least one physical-layer data block may occupy at least a subset of the indicated radio resources. Additionally, the size of the physical-layer data block may be less than or equal to the maximum size.

[0062] In some implementations, the set of criteria may include one or more of the following: (i) a minimum decoding probability, (ii) a minimum anticipated signal-to-noise ratio, (iii) a maximum data rate, (iv) a maximum transmission time, (v) a maximum probability of symbol error, and (vi) a maximum probability of block error.

[0063] In some implementations, the indicating may involve sending the maximum size in a Msg3 transmission of a random access procedure. Alternatively, or additionally, the indicating may involve sending the maximum size in a Msg1 transmission of a random access procedure.

[0064] In some implementations, the maximum size may be selected from a set of possible data block sizes. Alternatively, or additionally, the maximum size may be indicated as an explicit number of bits or octets. Alternatively, or additionally, the maximum size may be indicated as a maximum transmission time.

[0065] In one aspect with respect to DO-DTT transfer, a method of transferring data operable at a reader of an AIoT system may involve certain operations, including: (a) sending, to a device of the AIoT system, a paging message; (b) receiving, from the device, a maximum size of a physical-layer data block; (c) transmitting, to the device, an indication of radio resources; and (d) receiving, from the device, at least one physical-layer data block. The at least one physical-layer data block may have a size less than or equal to the maximum size. Moreover, the at least one physical-layer data block may occupy at least a subset of the indicated radio resources.

[0066] In some implementations, the receiving may involve receiving the maximum size in a Msg3 transmission of a random access procedure. Alternatively, or additionally, the receiving may involve receiving the maximum size in a Msg1 transmission of a random access procedure.

[0067] In some implementations, the maximum size may be selected from a set of possible data block sizes. Alternatively, or additionally, the maximum size may be indicated as an explicit number of bits or octets. Alternatively, or additionally, the maximum size may be indicated as a maximum reception time.

[0068] In one aspect with respect to dynamic TB negotiation for R2D, 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 may involve certain operations, including: (a) sending, to the device, a paging message and a request for data block size negotiation; (b) receiving, from the device, an indication of a maximum data block size; and (c) transmitting, to the device, a physical-layer data block. The size of the data block may be less than or equal to the maximum size.

[0069] In some implementations, the sending the request for data block size negotiation may involve sending the request in a paging message. Alternatively, or additionally, the sending the request for data block size negotiation may involve sending the request in Msg2 of a random access procedure.

[0070] In some implementations, the data block may include a set of application data bits and zero or more padding bits.

[0071] In one aspect with respect to dynamic TB negotiation for R2D, 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 may involve certain operations, including: (a) receiving, from the reader, a request for data block size negotiation; (b) determining a maximum data block size; (c) transmitting, to the reader, an indication of the maximum size; and (d) receiving, from the reader, a physical-layer data block. The size of the data block may be less than or equal to the maximum size.

[0072] In some implementations, the receiving the request for data block size negotiation may involve receiving the request in a paging message. Alternatively, or additionally, the receiving the request for data block size negotiation may involve receiving the request in Msg2 of a random access procedure.

[0073] In some implementations, the data block may include a set of application data bits and zero or more padding bits.

[0074] In one aspect with respect to dynamic TB negotiation for D2R, 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 may involve certain operations, including: (a) sending, to the device, a paging message and a request for data block size negotiation; (b) receiving, from the device, an indication of a maximum data block size; (c) transmitting, to the device, an indication of radio resources; and (d) receiving, from the device, a physical-layer data block. The size of the data block may be less than or equal to the maximum size.

[0075] In some implementations, the sending the request for data block size negotiation may involve sending the request in a paging message. Alternatively, or additionally, the sending the request for data block size negotiation may involve sending the request in Msg2 of a random access procedure.

[0076] In some implementations, the data block may include a set of application data bits and zero or more padding bits.

[0077] In one aspect with respect to dynamic TB size negotiation for D2R, 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 may involve certain operations, including: (a) receiving, from the reader, a request for data block size negotiation; (b) determining a maximum data block size; (c) transmitting, to the reader, an indication of the maximum size; (d) receiving, from the reader, an indication of radio resources; and (e) transmitting, to the reader, a physical-layer data block. The size of the data block may be less than or equal to the maximum size. Furthermore, the data block may occupy at least a subset of the indicated radio resources.

[0078] In some implementations, the receiving the request for data block size negotiation may involve receiving the request in a paging message. Alternatively, or additionally, the receiving the request for data block size negotiation may involve receiving the request in Msg2 of a random access procedure.

[0079] In some implementations, the data block may include a set of application data bits and zero or more padding bits.

[0080] In one aspect with respect to upper-layer segmentation adaptation for R2D, a method operable at a reader of an AIoT system may involve certain operations, including: (a) transmitting, to a device of the AIoT system, a paging message; (b) receiving, from the device, an indication of a maximum physical-layer data block size; (c) indicating, to an upper-layer entity, the maximum size; (d) receiving, from the upper-layer entity, an SDU of a MAC layer; and (e) transmitting, to the device, a physical-layer data block. The application data in the physical-layer data block may include the application data in the MAC SDU.

[0081] In some implementations, the upper-layer entity may be a controller of the AIoT system. Alternatively, or additionally, the upper-layer entity may be an application function of the AIoT system.

[0082] In one aspect with respect to upper -layer segmentation adaptation for D2R, a method operable at a device of an AIoT system may involve certain operations, including: (a) sending, to a reader of the AIoT system, an indication of a maximum physical-layer data block size; (b) receiving, from the reader, an indication of radio resources; (c) indicating, to an upper layer of the device, a request for data segmented to fit the maximum size; and (d) transmitting, to the reader, a physical-layer data block. The size of the physical-layer data block may be less than or equal to the maximum size. Moreover, the physical-layer data block may occupy at least a subset of the indicated radio resources. Illustrative Implementations

[0083] FIG. 13 illustrates an example system 1300 having at least an example apparatus 1310 and an example apparatus 1320 in accordance with an implementation of the present disclosure. Each of apparatus 1310 and apparatus 1320 may perform various functions to implement schemes, techniques, processes and methods described herein pertaining to negotiating and indicating a size of a transport block for transmission on an AIoT interface, between a device and a reader, in wireless communications, including the various schemes described above with respect to various proposed designs, concepts, schemes, systems and methods described above as well as processes described below. For instance, apparatus 1310 may be implemented in or as a device (e.g., AIoT device) and apparatus 1320 may be implemented in or as another device (e.g., a UE reader) , or vice versa.

[0084] In some implementations, each of apparatus 1310 and apparatus 1320 may be implemented in the form of one or more integrated-circuit (IC) chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. In the various schemes described above, each of apparatus 1310 and apparatus 1320 may be implemented in or as a target UE or an anchor UE / positioning server UE. Each of apparatus 1310 and apparatus 1320 may include at least some of those components shown in FIG. 13 such as a processor 1312 and a processor 1322, respectively, for example. Each of apparatus 1310 and apparatus 1320 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and, thus, such component (s) of apparatus 1310 and apparatus 1320 are neither shown in FIG. 13 nor described below in the interest of simplicity and brevity.

[0085] In one aspect, each of processor 1312 and processor 1322 may be implemented in the form of one or more single-core processors, one or more multi-core processors, one or more RISC processors or one or more CISC processors. That is, even though a singular term “aprocessor” is used herein to refer to processor 1312 and processor 1322, each of processor 1312 and processor 1322 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of processor 1312 and processor 1322 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors and / or one or more varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of processor 1312 and processor 1322 is a special-purpose machine specifically designed for negotiating and indicating a size of a transport block for transmission on an AIoT interface, between a device and a reader, in wireless communications in accordance with various implementations of the present disclosure.

[0086] In some implementations, apparatus 1310 may also include a transceiver 1316 coupled to processor 1312. Transceiver 1316 may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data. In some implementations, apparatus 1320 may also include a transceiver 1326 coupled to processor 1322. Transceiver 1326 may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data. It is noteworthy that, although transceiver 1316 and transceiver 1326 are illustrated as being external to and separate from processor 1312 and processor 1322, respectively, in some implementations, transceiver 1316 may be an integral part of processor 1312 as a system on chip (SoC) , and transceiver 1326 may be an integral part of processor 1322 as a SoC.

[0087] In some implementations, apparatus 1310 may further include a memory 1314 coupled to processor 1312 and capable of being accessed by processor 1312 and storing data therein. In some implementations, apparatus 1320 may further include a memory 1324 coupled to processor 1322 and capable of being accessed by processor 1322 and storing data therein. Each of memory 1314 and memory 1324 may include a type of random-access memory (RAM) such as dynamic RAM (DRAM) , static RAM (SRAM) , thyristor RAM (T-RAM) and / or zero-capacitor RAM (Z-RAM) . Alternatively, or additionally, each of memory 1314 and memory 1324 may include a type of read-only memory (ROM) such as mask ROM, programmable ROM (PROM) , erasable programmable ROM (EPROM) and / or electrically erasable programmable ROM (EEPROM) . Alternatively, or additionally, each of memory 1314 and memory 1324 may include a type of non-volatile random-access memory (NVRAM) such as flash memory, solid-state memory, ferroelectric RAM (FeRAM) , magnetoresistive RAM (MRAM) and / or phase-change memory.

[0088] Each of apparatus 1310 and apparatus 1320 may be a communication entity capable of communicating with each other using various proposed schemes in accordance with the present disclosure. For illustrative purposes and without limitation, a description of capabilities of apparatus 1310, as a device, and apparatus 1320, as a UE reader, is provided below in the context of example processes 1400 and 1500. It is noteworthy that, although a detailed description of capabilities, functionalities and / or technical features of one of apparatus 1310 and apparatus 1320 is provided below, the same may be applied to the other of apparatus 1310 and apparatus 1320 although a detailed description thereof is not provided solely in the interest of brevity. It is also noteworthy that, although the example implementations described below are provided in the context of air interface communications in an AIoT system, the same may be implemented in other types of systems. Illustrative Processes

[0089] FIG. 14 illustrates an example process 1400 in accordance with an implementation of the present disclosure. Process 1400 may represent an aspect of implementing various proposed designs, concepts, schemes, systems and methods described above. More specifically, process 1400 may represent an aspect of the proposed concepts and schemes pertaining to negotiating and indicating a size of a transport block for transmission on an AIoT interface, between a device and a reader, in wireless communications in accordance with the present disclosure. Process 1400 may include one or more operations, actions, or functions as illustrated by one or more of blocks as well as subblocks. Although illustrated as discrete blocks, various blocks of process 1400 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 1400 may be executed in the order shown in FIG. 14 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 1400 may be executed repeatedly or iteratively. Process 1400 may be implemented by or in apparatus 1310 and apparatus 1320 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 1400 is described below in the context of apparatus 1310 implemented in or as a device and apparatus 1320 implemented in or as a reader of a wireless network such as a mobile network in accordance with one or more of 3GPP standards. Process 1400 may begin at block 1410.

[0090] At 1410, process 1400 may involve processor 1312 of apparatus 1310 indicating, via transceiver 1316, to a reader of the AIoT system (e.g., apparatus 1320) a maximum size of any physical-layer data block receivable by the device under a set of criteria. Process 1400 may proceed from 1410 to 1420.

[0091] At 1420, process 1400 may involve processor 1312 receiving, via transceiver 1316, from the reader a physical-layer data block with a size not exceeding the maximum size responsive to the indicating.

[0092] In some implementations, the set of criteria comprises one or more of the following: (i) a minimum decoding probability, (ii) a minimum anticipated signal-to-noise ratio, (iii) a maximum data rate, (iv) a maximum reception time, (v) a maximum probability of symbol error, and (vi) a maximum probability of block error.

[0093] In some implementations, in indicating, process 1400 may involve processor 1312 indicating the maximum size in a Msg3 transmission associated with a random access procedure. Alternatively, in indicating, process 1400 may involve processor 1312 indicating the maximum size in a Msg1 transmission of a random access procedure.

[0094] In some implementations, the maximum size may be selected from a set of data block sizes.

[0095] In some implementations, the maximum size may be indicated as an explicit number of bits or octets. Alternatively, the maximum size may be indicated as a maximum reception time.

[0096] In some implementations, process 1400 may involve processor 1312 performing additional operations. For instance, process 1400 may involve processor 1312 transmitting, via transceiver 1316, to the reader a physical-layer data block with an indication that there are remaining data to be transmitted. Moreover, process 1400 may involve processor 1312 receiving, via transceiver 1316, from the reader a configuration or grant allowing transmission of the remaining data in one or more subsequent physical-layer data blocks. Furthermore, process 1400 may involve processor 1312 transmitting, via transceiver 1316, to the reader the remaining data responsive to receiving the configuration or grant.

[0097] In some implementations, in transmitting the physical-layer data block with the indication, process 1400 may involve processor 1312 transmitting the physical-layer data block with the indication in a Msg3 transmission associated with a random access procedure.

[0098] In some implementations, the indication may include a single-bit flag indicating whether more data exist, or an amount of queued data, or a required transport block size to contain the data to be transmitted.

[0099] FIG. 15 illustrates an example process 1500 in accordance with an implementation of the present disclosure. Process 1500 may represent an aspect of implementing various proposed designs, concepts, schemes, systems and methods described above. More specifically, process 1500 may represent an aspect of the proposed concepts and schemes pertaining to negotiating and indicating a size of a transport block for transmission on an AIoT interface, between a device and a reader, in wireless communications in accordance with the present disclosure. Process 1500 may include one or more operations, actions, or functions as illustrated by one or more of blocks as well as subblocks. Although illustrated as discrete blocks, various blocks of process 1500 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 1500 may be executed in the order shown in FIG. 15 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 1500 may be executed repeatedly or iteratively. Process 1500 may be implemented by or in apparatus 1310 and apparatus 1320 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 1500 is described below in the context of apparatus 1310 implemented in or as a device and apparatus 1320 implemented in or as a reader of a wireless network such as a mobile network in accordance with one or more of 3GPP standards. Process 1500 may begin at block 1510.

[0100] At 1510, process 1500 may involve processor 1312 of apparatus 1310 indicating, via transceiver 1316, to a reader of the AIoT system (e.g., apparatus 1320) a maximum size of any physical-layer data block transmittable by the device under a set of criteria. Process 1500 may proceed from 1510 to 1520.

[0101] At 1520, process 1500 may involve processor 1312 receiving, via transceiver 1316, from the reader an indication of radio resources responsive to the indicating. Process 1500 may proceed from 1520 to 1530.

[0102] At 1530, process 1500 may involve processor 1312 transmitting, via transceiver 1316, to the reader a physical-layer data block using at least a subset of the radio resources, with a size of the physical-layer data block being less than or equal to the maximum size.

[0103] In some implementations, the set of criteria comprises one or more of the following: (i) a minimum decoding probability, (ii) a minimum anticipated signal-to-noise ratio, (iii) a maximum data rate, (iv) a maximum transmission time, (v) a maximum probability of symbol error, and (vi) a maximum probability of block error.

[0104] In some implementations, in indicating, process 1500 may involve processor 1312 indicating the maximum size in a Msg3 transmission associated with a random access procedure. Alternatively, in indicating, process 1500 may involve processor 1312 indicating the maximum size in a Msg1 transmission of a random access procedure.

[0105] In some implementations, the maximum size may be selected from a set of data block sizes.

[0106] In some implementations, the maximum size may be indicated as an explicit number of bits or octets. Alternatively, the maximum size may be indicated as a maximum reception time.

[0107] In some implementations, process 1500 may involve processor 1312 performing additional operations. For instance, process 1500 may involve processor 1312 transmitting, via transceiver 1316, to the reader a physical-layer data block with an indication that there are remaining data to be transmitted. Moreover, process 1500 may involve processor 1312 receiving, via transceiver 1316, from the reader a configuration or grant allowing transmission of the remaining data in one or more subsequent physical-layer data blocks. Furthermore, process 1500 may involve processor 1312 transmitting, via transceiver 1316, to the reader the remaining data responsive to receiving the configuration or grant.

[0108] In some implementations, in transmitting the physical-layer data block with the indication that there are remaining data to be transmitted, process 1500 may involve processor 1312 transmitting the physical-layer data block with the indication that there are remaining data to be transmitted in a Msg3 transmission associated with a random access procedure.

[0109] In some implementations, the indication that there are remaining data to be transmitted may include a single-bit flag indicating whether more data exist, or an amount of queued data, or a required transport block size to contain the data to be transmitted. Additional Notes

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

[0111] 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 data transfer in an ambient Internet of Things (AIoT) system, comprising:indicating, by a device of the AIoT system, to a reader of the AIoT system a maximum size of any physical-layer data block receivable by the device under a set of criteria; andreceiving, by the device, from the reader a physical-layer data block with a size not exceeding the maximum size responsive to the indicating.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, anda maximum probability of block error.3.The method of claim 1, wherein the indicating comprises indicating the maximum size in a Msg3 transmission associated with a random access procedure.4.The method of claim 1, wherein the indicating comprises indicating 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 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.The method of claim 1, further comprising:transmitting, by the device, to the reader a physical-layer data block with an indication that there are remaining data to be transmitted.9.The method of claim 8, wherein the transmitting of the physical-layer data block with the indication comprises transmitting the physical-layer data block with the indication in a Msg3 transmission associated with a random access procedure.10.The method of claim 8, wherein the indication comprises a single-bit flag indicating whether more data exist, or an amount of queued data, or a required transport block size to contain the data to be transmitted.11.The method of claim 8, further comprising:receiving, by the device, from the reader a configuration or grant allowing transmission of the remaining data in one or more subsequent physical-layer data blocks; andtransmitting, by the device, to the reader the remaining data responsive to receiving the configuration or grant.12.A method of data transfer in an ambient Internet of Things (AIoT) system, comprising:indicating, by a device of the AIoT system, to a reader of the AIoT system a maximum size of any physical-layer data block transmittable by the device under a set of criteria;receiving, by the device, from the reader an indication of radio resources responsive to the indicating; andtransmitting, by the device, to the reader a physical-layer data block using at least a subset of the radio resources,wherein a size of the physical-layer data block is less than or equal to the maximum size.13.The method of claim 12, 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, anda maximum probability of block error.14.The method of claim 12, wherein the indicating comprises indicating the maximum size in a Msg3 transmission associated with a random access procedure.15.The method of claim 12, wherein the indicating comprises indicating the maximum size in a Msg1 transmission of a random access procedure.16.The method of claim 12, wherein the maximum size is selected from a set of data block sizes.17.The method of claim 12, wherein the maximum size is indicated as an explicit number of bits or octets.18.The method of claim 12, wherein the maximum size is indicated as a maximum transmission time.19.The method of claim 12, further comprising:transmitting, by the device, to the reader a physical-layer data block with an indication that there are remaining data to be transmitted.20.The method of claim 19, wherein the transmitting of the physical-layer data block with the indication that there are remaining data to be transmitted comprises transmitting the physical-layer data block with the indication that there are remaining data to be transmitted in a Msg3 transmission associated with a random access procedure.21.The method of claim 19, wherein the indication that there are remaining data to be transmitted comprises a single-bit flag indicating whether more data exist, or an amount of queued data, or a required transport block size to contain the data to be transmitted.22.The method of claim 19, further comprising:receiving, by the device, from the reader a configuration or grant allowing transmission of the remaining data in one or more subsequent physical-layer data blocks; andtransmitting, by the device, to the reader the remaining data responsive to receiving the configuration or grant.

Images