CN118487626A - System and method for dynamic adaptation in data transfer in ultra wideband communication - Google Patents

Abstract

The present disclosure provides systems and methods for dynamic adaptation in data transfer in ultra-wideband communications. A method for optimizing data transmission in UWB communications comprising: receiving one or more first application data packets from a UWB device as a first portion of a sequence of application data packets, the sequence having a first number of application data packets; determining a receiver status value based on the one or more first application data packets; comparing the receiver status value to a threshold value; and determining a second number of application data packets of the sequence based on a difference between the receiver state value and the threshold value. The second number is different from the first number. The method further comprises: generating said second number of messages indicative of said sequence of application data packets; and transmitting the message to the UWB device.

Description

System and method for dynamic adaptation in data transfer in ultra wideband communication

Technical Field

The present disclosure relates to Ultra Wideband (UWB) communications between UWB devices, and in particular to a system and method for dynamic adaptation in data transmission in UWB communications.

Background

Ultra Wideband (UWB) is a wireless communication technology that uses a wide bandwidth, typically about 500MHz or more, or a10 dB bandwidth with more than 20% of the center frequency. Pulse UWB (IR-UWB) is a special case of UWB in which signals are transmitted by extremely short pulses (in nanoseconds). The pulse UWB is particularly suited for ranging or sensing applications because the pulses are robust to multipath. Another advantage of IR-UWB is its ability to transmit data with low power consumption and low latency.

Ranging is a process of determining a distance between two devices using UWB technology. A fine ranging (FiRa) complex is established to ensure interoperability between UWB-enabled devices and to enable various use cases. FiRa was originally focused on ranging, but data transfer functionality was introduced in recent years. Initially, data transfer was introduced as an additional item to the ranging session: the short packets are piggybacked to ranging messages. However, due to the lack of communication between two UWB devices, the resources allocated for data transfer between the two UWB devices are not optimized. This may lead to wasted resources and to reduced performance, data collisions and overload on the UWB device. Accordingly, there is a need to improve allocation of resources for data transfer between UWB devices to facilitate faster and reliable data transfer while maintaining a reasonable workload on UWB devices.

Disclosure of Invention

Embodiments of the present disclosure provide a method for optimizing data transmission in UWB communications. The method comprises the following steps: receiving one or more first application data packets from a UWB device as a first portion of a sequence of application data packets, the sequence having a first number of application data packets; determining a receiver status value based on the one or more first application data packets; comparing the receiver status value to a threshold value; and determining a second number of application data packets of the sequence based on a difference between the receiver state value and the threshold value. The second number is different from the first number. The method further comprises: generating said second number of messages indicative of said sequence of application data packets; and transmitting the message to the UWB device.

In some embodiments, the method includes reducing or maintaining the first number such that the second number is less than or equal to the first number in response to the receiver state value being equal to or greater than the threshold value. In some embodiments, the method includes increasing the first number such that the second number is greater than the first number in response to the receiver state value being less than the threshold.

In some embodiments, the number of second application data packets is less than a difference between the first number and the number of first application data packets in response to the receiver status value being equal to or greater than the threshold value. In some embodiments, the number of second application data packets is greater than a difference between the first number and the number of first application data packets in response to the receiver status value being less than the threshold.

The method further includes storing one or more first application data packets in memory. The receiver state value comprises storage space for one or more first application data packets in memory and the threshold comprises threshold storage space.

In some embodiments, the threshold storage space is one of a predetermined percentage of memory or a predetermined percentage of total storage space corresponding to a sequence of the first number of application data packets.

In some embodiments, the threshold storage space is equal to or greater than 50% of the memory, such as a predetermined value/percentage, or equal to or greater than 50% of the total storage space corresponding to the sequence of the first number of application data packets; and the memory space is equal to or greater than the threshold memory space.

In some embodiments, the number of second application data packets is equal to zero.

In some embodiments, the threshold storage space is less than 50% of the memory, such as a predetermined value/percentage, or equal to or greater than 50% of the total storage space corresponding to the sequence of the first number of application data packets; and the memory space is less than the threshold memory space.

In some embodiments, the receiver state value includes a throughput at a UWB Control Interface (UCI) calculated based on the first application data packet; and the threshold comprises a threshold bandwidth.

In some embodiments, the method further comprises: receiving one or more other sequences from one or more other connections, each of the other sequences having a plurality of application data packets; calculating, for each of the connection and the other connections, a respective throughput at the UCI; determining that at least one of the throughput at the UCI is above a threshold bandwidth; comparing the priority of the connection for the sequence with the priority of one or more other connections for one or more other sequences; and determining that the connection for the sequence has the lowest priority. The threshold bandwidth is equal to or greater than 50%, e.g., a predetermined value/percentage, of the maximum throughput at UCI.

In some embodiments, the maximum number of second application data packets is equal to zero.

In some embodiments, the method further comprises: receiving one or more other sequences from one or more other connections, each of the other sequences having a plurality of application data packets; calculating, for each of the connection and the other connections, a respective throughput at the UCI; determining that at least one of the throughput at the UCI is below a threshold bandwidth; comparing the priority of the connection for the sequence with the priority of one or more other connections for one or more other sequences; and determining that the connection for the sequence has the highest priority. The threshold bandwidth is less than 50%, e.g., a predetermined value/percentage, of the maximum throughput at UCI.

In some embodiments, the method further includes receiving a message from the UWB device requesting an adjustment of the bit rate prior to determining the number of second application data packets to transmit.

In some embodiments, the receiver status value includes Central Processing Unit (CPU) usage; and the threshold comprises a predetermined threshold percentage of CPU usage.

In some embodiments, the method further comprises: receiving one or more other sequences from one or more other connections, each of the other sequences having a plurality of application data packets; comparing the priority of the connection for the sequence with the priority of one or more other connections for one or more other sequences; and determining that the connection for the sequence has the lowest priority. The threshold CPU utilization is equal to or greater than, for example, 50% (e.g., predetermined value/percentage) of the maximum CPU utilization; and the CPU utilization is equal to or greater than the threshold CPU utilization.

In some embodiments, the number of second application data packets is zero.

In some embodiments, the method further comprises: receiving one or more other sequences from one or more other connections, each of the other sequences having a plurality of application data packets; comparing the priority of the connection for the sequence with the priority of one or more other connections for one or more other sequences; and determining that the connection for the sequence has the highest priority. The threshold CPU usage is less than 50% of the maximum CPU usage, e.g., a predetermined value/percentage; and the CPU utilization is less than the threshold CPU utilization.

In some embodiments, the method further includes receiving a second message from the UWB device requesting transmission of a second number of application data packets in the sequence prior to determining the second number of application data packets in the sequence.

In some embodiments, the message is a link layer message.

Embodiments of the present disclosure provide a method for adjusting data transmission in Ultra Wideband (UWB) communications. The method comprises the following steps: transmitting one or more first application data packets as a first portion of a sequence of application data packets, the sequence having a first number of application data packets; receiving a second number of messages from the UWB device containing application data packets in the sequence, the second number being different from the first number; and adjusting the number of second application data packets to be transmitted as the second portion of the sequence such that the second number of application data packets is to be transmitted as the sequence.

In some embodiments, in response to the second number of application data packets being less than or equal to the first number of application data packets, the number of second application data packets is between zero and a difference between the first number and the second number. In some embodiments, in response to the second number of application data packets being greater than the first number of application data packets, the number of second application data packets is greater than a difference between the second number and the first number.

Embodiments of the present disclosure provide a method for optimizing data transmission in Ultra Wideband (UWB) communications. The method comprises the following steps: transmitting a first number of application data packets; receiving an acknowledgement message for a second number of application data packets; and determining a transmitter status value based on at least one of the first number of application data packets or the second number of application data packets.

In some embodiments, the method further comprises: retransmitting a third number of application data packets for which no acknowledgement message was received; receiving acknowledgement messages for a fourth number of retransmitted application data packets; and determining a fifth number of application data packets for which acknowledgement messages have not been received. The determination of the transmitter status value is further based on one or more of a third number of retransmitted application data packets, a fourth number of retransmitted application data packets, or a fifth number of application data packets.

In some embodiments, the transmitter status value includes at least one of a ratio between the second number and the first number, a ratio between the fourth number and the first number, or a ratio between the fifth number and the first number.

In some embodiments, the method further includes transmitting a message with the transmitter status value to the UWB device.

In some embodiments, the message is a link layer message.

In some embodiments, the method further comprises: determining a second transmitter state value after transmitting the previous transmitter state value; and transmitting a second message having a second transmitter status value after a predetermined period of time after transmitting the message.

In some embodiments, the message is transmitted periodically.

In some embodiments, the method further includes adjusting a modulation rate for transmitting a sixth number of application data packets based on the transmitter status value.

Embodiments of the present disclosure provide a method for optimizing data transmission in Ultra Wideband (UWB) communications. The method comprises the following steps: receiving a transmitter status value indicative of a transmission condition of the UWB device over a first time period; and allocating a time slot for transmitting the application data packet in a second time period subsequent to the first time period based on the transmitter status value.

In some embodiments, the transmitter status value includes at least one of a first ratio, a second ratio, and/or a third ratio. The first ratio is between the number of application data packets transmitted by the UWB device in the first time period and the number of application data packets whose acknowledgement messages are received by the UWB device after the first transmission. The second ratio is between the number of application data packets transmitted by the UWB device in the first period of time and the number of application data packets whose acknowledgement messages are received by the UWB device after retransmission. The third ratio is between the number of application data packets for which no acknowledgement message is received by the UWB device and the number of application data packets transmitted by the UWB device in the first time period and the number of application data packets for which an acknowledgement message is received by the UWB device after the first transmission.

In some embodiments, the method further includes not allocating a time slot for retransmission to the UWB device in response to the first ratio being equal to 1.

In some embodiments, the transmitter status value is received in a link layer message.

Those skilled in the art will recognize the scope of the present disclosure and appreciate additional aspects thereof upon reading the following detailed description of the preferred embodiments and the associated drawings.

Drawings

The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several aspects of the present disclosure and, together with the description, serve to explain the principles of the disclosure.

Fig. 1A illustrates an exemplary system of two UWB devices for implementing dynamic adaptation of data transmissions in accordance with aspects of the present disclosure.

Fig. 1B illustrates an exemplary architecture of a dynamically adapted UWB device for implementing data transfer in accordance with some aspects of the present disclosure.

Fig. 1C illustrates a frame structure for use in UWB communications in accordance with some aspects of the present disclosure.

Fig. 2A illustrates a scenario in which a UWB device transmits a receiver status PDU to another UWB device for dynamic adaptation in data transmission, in accordance with some aspects of the present disclosure.

Fig. 2B illustrates an exemplary data frame with a dynamically adapted receiver (Rx) status PDU for use in data transmission, in accordance with some aspects of the present disclosure.

Fig. 3A illustrates a scenario in which a UWB device transmits a transmitter status PDU to another UWB device for dynamic adaptation in data transmission, in accordance with some aspects of the present disclosure.

Fig. 3B illustrates an example data frame with a dynamically adapted transmitter (Tx) status PDU for use in data transmission, in accordance with some aspects of the present disclosure.

Fig. 3C illustrates slot assignments for data transmission at different stages, in accordance with some aspects of the present disclosure.

Fig. 3D illustrates an example of talk time as a function of Link Layer (LL) packet size at different modulation rates in accordance with some aspects of the present disclosure.

Fig. 4A and 4B each illustrate a method for implementing dynamic adaptation in data transmission using Rx state information in UWB communications, in accordance with some aspects of the present disclosure.

Fig. 5A and 5B each illustrate a method for implementing dynamic adaptation in data transmission using Tx state information in UWB communications, in accordance with some aspects of the present disclosure.

Detailed Description

The embodiments set forth below represent the information necessary to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.

It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the present disclosure. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising" (comprises, comprising) and/or "including" when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. In addition, like reference numerals refer to like features throughout the specification and drawings.

It will be understood that each block of the signaling diagrams or flowchart illustrations, and combinations of signaling diagrams or flowchart illustrations, can be implemented by computer program instructions. Because the computer program instructions may be provided in a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions described in conjunction with the blocks of each signaling diagram or flowchart. Because computer program instructions may be stored in a computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing apparatus to implement the functions in a specified manner, the instructions stored in the computer-usable or computer-readable memory can produce an article of manufacture including instructions that implement the function specified in the flowchart block or blocks. Because the computer program instructions may be provided in a computer or other programmable data processing apparatus, the instructions which produce a process implemented process such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in each signaling diagram or block of the flowchart block or blocks.

Each block may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). Furthermore, it should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order. For example, two blocks shown in succession may be executed substantially concurrently or the blocks may be executed in the reverse order, depending upon the functionality involved.

Hereinafter, embodiments are described in detail with reference to the accompanying drawings. Furthermore, although a communication system using Ultra Wideband (UWB) is described in connection with the embodiments, the embodiments are also applicable to other communication systems having similar technical backgrounds or features, as examples. For example, a communication system using bluetooth or ZigBee may be included therein. Furthermore, embodiments may be modified within such ranges without significantly departing from the scope of the disclosure, and such modifications may be applicable to other communication systems, as determined by one of ordinary skill in the art.

UWB may refer to short range high rate wireless communication technologies that use a wide frequency band of a few GHz or more, low spectral density, and short pulse width (e.g., 1nsec to 4 nsec) in the baseband state. UWB may refer to the frequency band itself in which UWB communications are applied. UWB can achieve safe and accurate ranging between devices. Thus, UWB enables a relative position estimate based on the distance between two devices, or an accurate position estimate of a device based on the distance from a fixed device (whose position is known, also referred to as an anchor device). The present disclosure assumes that a user carries a device capable of UWB communication (referred to as a "UWB-enabled device" or simply "UWB device"). More generally, the present disclosure assumes communication between two UWB devices.

In this disclosure, a UWB communication session (or data session) may include multiple rounds (or ranging rounds), a round may include multiple phases (or data phases), and a phase may include multiple time slots. The communication session, round, phase, and time slot may each be referred to as a time period. In the present disclosure, the term "time slot" and the term "slot" are used interchangeably.

In data transmission, the controller UWB device (or simply controller) acts as a central scheduler to decide how time slots (or interchangeably slots in this disclosure) can be allocated in both directions for data transmission with the slave UWB device (or simply slave): downlink (DL, from controller to controller) and uplink (UL, from controller to controller). The slave transmits and receives data in the form of frames that are transmitted in time slots allocated by the controller. As disclosed in U.S. provisional application No. 63/512,210, which is incorporated herein in its entirety, a slave may report the status of its buffers to a controller, e.g., a data queue in the controller's receiver buffer and/or transmitter buffer, so that the controller may allocate time slots (or simply time slots) for data transmissions from the slave. However, slot allocation is static, which may result in inefficient use of slots, slow data transfer, data collisions, and overload on the slave and/or controller. For example, existing buffer control cannot solve the following problems. In the following description, a transmitter (e.g., one of a controller and a slave) transmits a data packet to a receiver (e.g., the other of the controller and the slave).

First, there may be receiver memory constraints. The transmitter transmits data packets, e.g., LL Packet Data Units (PDUs), to the receiver. If some LL PDUs are not successfully received, the received PDUs are stored in the memory of the receiver until the missing LL PDUs are retransmitted, and the received LL PDUs may form a sequential chain of LL PDUs. The memory requirement may increase to a LL window size x a maximum LL PDU size, where the LL window size is the maximum number of LL PDUs transmitted by the transmitter without receiving an Acknowledgement (ACK), and the maximum LL PDU size refers to the maximum storage capacity required for the LL PDUs or the maximum amount of data that can be transmitted in a slot. This memory requirement can meet or exceed the on-chip memory capacity of the UWB chip and impose constraints on Software (SW) memory management of the host of the receiver.

Furthermore, UWB throughput may become too high. For example, on the receiver side, the UWBS host (upper layer) interface or UWB Control Interface (UCI) may be very busy or the host may be so slow that it cannot consume and consume the received data packets or LL PDUs, resulting in data congestion and loss at this interface.

Furthermore, the static slot allocation is done by the controller. The data transfer is completed on a plurality of phases scheduled at periodic intervals. Before each phase begins, the controller LL may assign a time slot to the slaves participating in the data session within the upcoming phase. This slot allocation typically contains a maximum number of retransmissions per PDU for each connection. The slot allocation is typically static per stage (e.g., slots for a given stage are pre-allocated and the allocation is typically not changed in the given/current stage). Thus, if the UWB channel is very clean (e.g., low noise and/or low interference), the probability of retransmission is low and there is no need to allocate time slots for retransmission. The time slots are then wasted in this stage/connection, but they can be used for another connection. Furthermore, buffer control does not provide a solution to adapt bit rates to reduce talk time and collision risk. For example, if there is more than one UWB device in the neighborhood that is active (uncoordinated) in the local UWB network, the risk of data collision is high.

Embodiments of the present disclosure improve data transfer (e.g., transfer of LL application PDUs) between two UWB devices (e.g., a transmitter and a receiver) such that one or both of the UWB devices may use certain status data to optimize data transfer. The receivers and/or transmitters of the two UWB devices may each obtain certain status data reflecting the transmission from their own data transfer perspective, and may use the status data to suggest/adjust certain parameters of the data transfer between the two UWB devices. The status data may be used as feedback to allow the UWB device to optimize data transmission by reducing resource waste, reducing data collisions in the channel, and reducing overload on one or more UWB devices. In the present disclosure, when improved data transfer is desired, one UWB device (receiver or transmitter) may send an LL PDU containing a status value, e.g., an LL status PDU, to the other of the UWB devices (the other of the receiver or transmitter). For example, certain parameters associated with data transfer may be calculated and processed in real-time (or based on a predetermined time interval) for a UWB device to determine whether improved data transfer is needed. The criteria and embodiments of the method for optimization are described below.

For example, to address the issues of receiver memory constraints and high throughput, the receiver may transmit a message containing a novel LL Rx status PDU to the transmitter, where the receiver proposes a smaller LL window size (e.g., the number of LL packets/frames transmitted by the transmitter if the transmitter does not receive an acknowledgement (or ACK)). In this way, the transmitter may transmit less data or cease transmitting data before receiving the ACK, and the maximum amount of data that needs to be stored in the on-chip memory of the receiver may be lower. Also, viewing by a host of the receiver (or an upper layer of the transmitter) or a UWB control interface (or UCI) can be reduced and represented by the equationAnd determining effective throughput. In some embodiments, the transmitter is a controller and has multiple connections to multiple controllers. The UWB device may determine the effective throughput of one or more connections at UCI and send LL Rx status PDUs to the connection with lower priority to reduce the LL window size of the connection. In various embodiments, the receiver may transmit the LL Rx status PDU autonomously or upon request by the host (e.g., from the transmitter or receiver).

To address the problem of static slot allocation, the transmitter may first detect whether the UWB channel is clean or what the average retransmission ratio per PDU is. For example, if all of its transmitted LL application PDUs are positively acknowledged at the time of the first transmission, the transmitter determines that the channel is clean and the transmitter does not need to retransmit its LL PDUs. The transmitter may send a message containing the LL Tx status PDU to a controller (e.g., receiver). The LL Tx status PDU may contain information (ACK status) for determining the number of slots required for retransmission of the LL application PDU in the latest phase/round. The receiver (e.g., controller) may then allocate a next phase of time slots to the transmitter (e.g., slave) based on the information contained in the LL Tx status PDU.

To address the issues of data collision and poor transmission quality, a UWB device (e.g., a transmitter) may adjust its bit rate based on an LL Tx status PDU containing an ACK status transmitted by another UWB device (e.g., a receiver). If the ACK state shows many non-acknowledged LL application PDUs and the number of LL application PDUs that need to be retransmitted is greater than the LL application PDUs that were positively acknowledged at the time of the first transmission, the UWB device may determine that there are a large number of undesirable collisions. UWB devices may increase the physical layer (PHY) bit rate to reduce talk time. Alternatively or additionally, the UWB device may not transmit the LL Tx status PDU. Alternatively, the UWB device may use the ACK status to evaluate the transmission quality and reduce the PHY bit rate if the transmission quality is low. In existing UWB community systems, the bit rate is the same and constant for all UWB devices in a session. The present disclosure proposes to allow multiple bit rates per session so that UWB devices can flexibly adjust their bit rates based on recent transmission conditions to reduce collisions.

The present disclosure provides LL Rx status PDUs (or LL signaling PDUs) to adjust the LL window size for data transmission. If the amount of memory required on the receiver side increases too much, the received throughput is too fast for the receiving application or the CPU load of the receiver is too high, a new LL Rx status PDU is sent. By adapting the LL window size, the optimal end-to-end throughput can be continuously searched and memory constraints are controlled. The present disclosure also provides for LL Tx status PDUs (or LL signaling PDUs) to indicate to a receiver (e.g., a controller) a proposed number of slots for retransmission or transmission statistics on the transmitter side (e.g., a slave) so that the controller can optimize UWB slot allocation. By suggesting a maximum number of retransmissions to bias the slot allocation algorithm, UWB slot allocation may be optimized and slots are not allocated for retransmissions when no retransmissions are needed. Moreover, dynamic adaptation of the transmission bit rate may be implemented based on the received LL ACK state to reduce talk time and, thus, reduce the probability of packet collisions. By using the LL ACK state to adapt to the transmitted bit rate, the connection may be more robust.

Fig. 1A depicts an exemplary system 100 for implementing dynamic adaptation in data transmission in UWB communications, according to some embodiments of the present disclosure. The system 100 may include a UWB device 102 in wireless communication with another UWB device 104, as symbolically shown by wireless link 114. UWB device 102 may be a controller UWB device (or simply a controller), and UWB device 104 may be a slave UWB device (or simply a slave) in wireless communication. In the present disclosure, the controller may be one of a transmitter and a receiver, and the controller may be the other of the transmitter and the receiver. UWB device 102 may be an on-board computer or a mobile device. In some embodiments, UWB device 104 is a mobile device. For example, UWB device 102 may be a device installed at a POS for contactless payment, and UWB device 104 may be a user mobile device. It should be noted herein that the terms "mobile device," "mobile handset," "wireless handset," and "User Equipment (UE)" are used interchangeably hereinafter to refer to a wireless communication device capable of voice and/or data communication. Some examples of such mobile handsets include smartphones, tablet computers, and wearable devices. It is observed here that UWB device 102 may not necessarily be a separate computing unit (in hardware or software form) dedicated to performing dynamic adaptation functionality. In one embodiment, the functionality of UWB device 102 may be implemented in physical computing/data processing units or (non-physical) server software already present in the cloud. The wireless link 114 may include a UWB communication interface. The wireless link 114 may also support other types of wireless connections, such as a bluetooth communication interface, a Wi-Fi communication interface, a cellular network connection (e.g., 4G, 5G) interface, a Near Field Communication (NFC) interface, a ZigBee communication interface, or a combination thereof.

The control unit 124/126 is one of the mobile applications installed in the UWB devices 102/104, respectively. In addition to the control units 124/126, the UWB devices 102 and 104 may each have one or more mobile applications (e.g., controller application 106/slave application 116) resident therein. These mobile applications are software modules that may have been pre-packaged with the respective UWB device 102/104 or may have been downloaded by a user into the memory (not shown) of the respective UWB device 102/104. For example, UWB device 102 may also store other controller-specific applications in its memory (not shown), such as applications that facilitate ethernet-based communications, applications that interact with the cloud, and so on. In some embodiments, control units 124 and 126 perform dynamic adaptation in data transfer for UWB communications. For example, control units 124 and 126 may generate and process control packets (e.g., LL status PDUs) transmitted between UWB devices 102 and 104 for dynamic adaptation functions. The following contains a detailed description. The mobile application and control units (e.g., 124 and 126), respectively, may be executed by the processor under the control of a mobile operating system (e.g., controller operating system 110 and controller operating system 120). UWB device 102 may include a relatively high power controller Central Processing Unit (CPU) 112 that executes a controller operating system 110. UWB device 102 may further include a wireless interface 108 to facilitate wireless communication with UWB device 104 via wireless link 114. Applications (e.g., 106 and 124) may optionally utilize wireless interface 108.

Due to the battery-powered nature of the mobile device, in some embodiments, the processor of the UWB device 104 (e.g., the slave CPU 122) may be designed to conserve battery power, such as a relatively low power CPU. UWB device 104 may communicate wirelessly with UWB device 102 via its own wireless interface 118. Wireless interface units 108 and 118 may wirelessly communicate data or information between UWB device 102 and UWB device 104 using wireless link 114 as shown.

In operation, a UWB device (e.g., 102 or 104) may be dynamically adapted to transmission conditions to improve data transfer. In some embodiments, the UWB device is a receiver and may be a controller or a slave. The control unit (e.g., 124 or 126) of the UWB device may calculate certain metrics reflecting the current data transfer of the LL application PDU and compare these metrics to a predetermined threshold. Based on the results of the comparison, the UWB device may generate a message embedded with an LL Rx status PDU containing the proposed LL window size if the LL application PDU being transmitted occupies too much/too little space in the on-chip memory of the receiver's UWB system (e.g., UWBS or UWB chip), uses too much/too little resources in the CPU (e.g., 112 or 122), or causes an overload/underload on the UWB Control Interface (UCI) between the host (or upper layers or applications 106/116) and UWBS. The UWB device may transmit the message to another UWB device (e.g., a transmitter) over a wireless link 114. A transmitter receiving the proposed LL window size may adjust its LL window size, e.g., for transmitting LL application PDUs to a receiver (e.g., over wireless link 114) to relieve pressure/burden on the receiver.

In some embodiments, the UWB device is a slave. The control unit (e.g., 126) of the UWB device may calculate certain metrics reflecting the retransmission information of the current data transmission of the LL application PDU. In some embodiments, the UWB device calculates statistics reflecting a particular retransmission ratio of one or more previously-staged LL application PDUs (e.g., total time slots required to transmit a certain set of LL application PDUs) from the perspective of the transmitter, and may suggest the calculated statistics to other UWB devices (e.g., controllers) via LL PDUs transmitted over wireless link 114. The controller may then allocate time slots to the next stage of data transfer based on the actual demand of the slave (e.g., reflected in the calculated statistics) to reduce the waste of time slots. In some embodiments, the UWB device may be a controller or a slave.

The control unit (e.g., 124 or 126) may calculate statistics reflecting a particular retransmission ratio and adjust the modulation/data rate used to transmit the LL application PDUs based on the retransmission ratio to shorten talk time, reduce data collisions, and/or improve transmission quality in the UWB channel.

Fig. 1B shows a diagram of an architecture (e.g., a hierarchical view) of UWB device 101 in accordance with some embodiments of the present disclosure. UWB device 101 may be an example of UWB devices 102 and 104. As shown in fig. 1B, UWB device 101 may include one or more upper layers 103 (e.g., hosts for UWB device 101), UWB Control Interface (UCI) 105, secure Element (SE) interface 109, link layer 111, medium Access Control (MAC) layer 113, physical (PHY) layer 115, UWB radio interface 117, and control module 119. In some embodiments, UCI 105, link layer 111, MAC layer 113, PHY layer 115, SE interface 109, and UWB radio interface 117 may be referred to as UWB system (UWBS) 107 (or UWB chip). UWBS107 and upper layer 103 may communicate via UCI 105.

PHY layer 115 is configured to transport data (e.g., packets, such as control packets and data packets) using its interface, such as UWB radio interface 117. PHY layer 115 provides an electrical, mechanical, and/or procedural interface to the transmission medium. The MAC layer 113 is configured to control hardware responsible for interacting with wired, optical, and/or wireless transmission media. The link layer 111 is configured to provide methods and communication protocols that are limited to the link to which the UWB device 101 is connected. For example, the link layer 111 generates packets by framing data bits, such as source and destination addresses, information for detecting and controlling transmission errors, message types, and indications of receiver (Rx)/transmitter (Tx) status for the data stream. The link layer 111 is a layer that adapts data from the upper layer 103 to MAC frames, manages transmissions and retransmissions to deliver a lossless connection. Lossless connections are typically configured by two parameters: maximum number of retransmissions and LL window size.

SE interface 109 allows UWBS for direct communication with the SE through link layer 111, MAC layer 113, PHY layer 115, and SE interface 109. Upper layer 103 may include layers above link layer 111, such as a network layer, transport layer, session layer, presentation layer, and application layer, each having their respective functionality for UWB system communications. Upper layer 103 communicates with UWBS107,107 via UCI 105. UCI 105 may allow a host (e.g., UWB device 101) to configure and control UWBS107 and collect data forming UWBS107, and may allow UWBS107 to receive application data and/or configuration parameters from upper layer 103.

The control module 119 may control the functions of the link layer 111. For example, the control module 119 may control generation, reception, and analysis of link layer control messages. The control module 119 may be a dedicated entity for controlling the link layer 111, or may be part of a more general control entity for the UWB device 101 for controlling various other layers. For example, the control module 119 may perform some or all of the functions of the control unit 124 (and/or the control unit 126). For example, the control module 119 may include any suitable hardware and/or software that may control the link layer 111. In an embodiment, the control module 119 is implemented by an on-chip processor of UWBS107,107. In some embodiments, the control module 119 is implemented by a general purpose processor of the UWB device 101 (or host). The control module 119 may allow packets transmitted between two UWB devices to be parsed and executed at the link level without having to transmit and parse the packets at a higher level. In some embodiments, control module 119 is communicatively connected to upper layer 103 to collect/receive data and/or configuration parameters. On the transmitter side, control module 119 may use the collected/received information to construct an LL header and add the LL header to the LL PDU. On the receiver side, control module 119 may use the collected/received data to parse the received LL header and determine the operations to complete accordingly.

The control module 119 may configure Rx or Tx status data based on the current data transfer and related metrics. For example, control module 119 may configure Rx state data based on-chip memory usage, user throughput calculated at UCI 105, and/or processor usage of UWBS 107. In another example, control module 119 can configure Tx status data based on buffer status data (e.g., LL application PDUs transmitted and to be transmitted) and ACKs received for the transmitted data. Control module 119 may construct the LL status PDU to include an Rx status (e.g., generate LL Rx status PDU) or a Tx status (e.g., generate LL Tx status PDU) and transmit the LL status PDU to another UWB device over UWB radio interface 117. Additionally or alternatively, control module 119 may use the Tx status to adjust bit rate and talk time.

Fig. 1C illustrates a process for forming packets for transmission through different layers of a UWB device. Packets containing various data, such as user data or application data, may be transmitted from an upper layer (e.g., upper layer 103) and/or a secure element to a UWB radio interface (e.g., UWB radio interface 117). As shown in fig. 1C, on the transmitter side, a data payload (e.g., a link layer service data unit or LL SDU) may be provided UWBS (e.g., UWBS 107) to the link layer (e.g., link layer 111) by UCI (e.g., UCI 105). The payload may be segmented and the LL header may be appended to the segment. The LL header and fragments may be from LL Packet Data Units (PDUs). The LL PDU may then be transmitted to a MAC layer (e.g., MAC layer 113). The LL PDU may then be embedded in the MAC payload (or MAC SDU or MSDU). MSDUs may be appended to the MAC header and MAC footers to form MAC frames or MAC Protocol Data Units (MPDUs). MPDUs may be transmitted to a PHY layer (e.g., PHY layer 115). The MPDU may then be embedded in a PHY payload (or physical layer convergence procedure SDU or PSDU). The PSDU may be appended to the PHY header and the synchronization header (or SHR) to form a physical layer protocol data unit or (PPDU). The PPDU may then be transmitted to another UWB device (via UWB radio interface 117 or SE interface 109).

On the receiver side, packets from another UWB device may be received at the PHY layer (e.g., PHY layer 115) and parsed at the PHY layer level, the MAC layer level (e.g., MAC layer 113), and the link layer level (e.g., link layer 111). For example, a link layer PDU may be received at the link layer and processed

In the present disclosure, the Rx and Tx states are determined by control module 119 and may be constructed in an LL PDU (or LL status PDU). The LL status PDU may then be transmitted as a PPDU and parsed at the link layer level by UWB devices receiving the PPDU. The LL PDU allows the UWB device to construct and parse control packets in time without the need for construction and processing by the host.

Fig. 2A shows a signaling diagram 200 between UWB device 1 (transmitter) and UWB device 2 (receiver), wherein UWB device 2 transmits LL PDUs containing the Rx state of UWB device 2 to UWB device 1. As shown in fig. 2A, UWB device 1 transmits application data PDU 202-1 (e.g., LL application PDU) to UWB device 2. Application data PDU 202-1 may be a first portion (e.g., a first number of LL application PDUs) of sequence 202 of LL application PDUs that UWB device 1 schedules to transmit to UWB device 2. Sequence 202 may include a first number of LL application PDUs to be transmitted in the original LL window. After receiving the application data PDU 202-1, UWB device 2 transmits an Rx State PDU 204 (e.g., a LL Rx State PDU with the Rx State of UWB device 2) to UWB device 1. Fig. 2B illustrates an example data frame 201 of an Rx status PDU 204, according to some embodiments. As shown in fig. 2B, data frame 201 is a LL PDU that includes field 203 "message type=rx state", field 205 "message header 205", and field 207"Rx state value: LL window size. In some embodiments, the "LL window size" of field 207 contains a proposed LL window size that is different from the most recent (or current) LL window size used for data transfer. In various embodiments, the proposed LL window size may be greater or less than the current LL window size. Based on Rx status PDU 204, uwb device 1 may determine to adjust the number of LL application PDUs, e.g., application data PDUs 202-2, scheduled to be transmitted as a second portion of sequence 202 such that sequence 202 has a second number of LL application PDUs transmitted at LL window sizes that match or are sufficiently close to the proposed LL window size. The second number is different from the first number. The number of LL application PDUs, e.g., application data PDUs 202-2, in the second portion of sequence 202 may be determined based on the difference between the proposed LL window size and the size of the first portion of sequence 202. In some embodiments, if a smaller LL window size is suggested, the number of LL application PDUs, e.g., application data PDUs 202-2, that are the second portion of sequence 202 may be equal to zero or less than the difference. In some embodiments, if a larger LL window size is suggested, the number of LL application PDUs in the second portion of sequence 202 may be greater than the difference. In some embodiments, the proposed LL window size (or data frame 201) is used as a means for flow control. The following describes different scenarios with the Rx status PDU 204.

In a first scenario, if the current data transfer results in too much or too little on-chip memory for storage/caching, a UWB device, such as a receiver in UWB communications, may provide an Rx status value for flow dependent storage control. The receiver may include the suggested LL window size in field 207 to make a suggestion to the transmitter. The proposed LL window size may lead to better flow control on the receiver side. For example, the transmitter may transmit a sequence of LL application PDUs (e.g., application data PDU 202-1) to the receiver in the established connection, each having a sequence number or SN. Upon receiving one or more of the LL application PDUs, the receiver may reorder the received LL application PDUs into an ordered list (e.g., according to their sequence numbers or SNs) to deliver the ordered data to the upper layers. If an LL application PDU with sn=n is not received by the receiver, then the other LL application PDUs with sn=n+1, n+2 … … must be stored in the receiver memory until the LL application PDU with sn=n is retransmitted and received. If the receiver slowly sends a status report with negative acknowledgement (or NACK) for LL application PDU sn=n, the number of stored LL application PDUs may be increased to the current LL window size, which may trigger retransmission of the LL application PDU sn=n. Alternatively or additionally, the transmitter may not have a time slot allocated for short-term retransmission (or retransmission in the current phase). The memory required by the receiver may then be close to the maximum memory available for on-chip memory, especially if the size of the LL application PDU is large. On the other hand, if the received LL application PDU occupies only a small portion of on-chip memory, then on-chip cannot be used effectively and the LL window may be larger.

To address this issue, LL Rx status PDUs with the proposed LL window size may be transmitted by the receiver based on memory constraints on the receiver side. Upon receiving the LL Rx status PDU with the proposed LL window size, the transmitter may update/adjust the current LL window size to: minimum (local/transmitter LL Tx window, LL window proposed by receiver) if the received LL application PDU occupies too much on-chip memory. By adjusting the LL window size, the use of on-chip memory on the receiver side, as well as data transfer, can be optimized.

In some embodiments, the receiver may determine on-chip memory for this connection and generate an LL PDU (e.g., 201) with an Rx status value using the following criteria:

1) Memory for this connection > =x0kb; or (b)

2) The memory used for this connection is < Y0 kB.

In some embodiments, if criterion 1) is met, the receiver may generate an LL Rx status PDU to suggest a smaller LL window size. If criterion 1) is met, the transmitter may continue to transmit few or zero LL application PDUs, e.g., PDUs waiting for acknowledgement. In this case, the sequence of LL application PDUs received and stored by the receiver is shorter (e.g., has less total LL application PDUs) than the length of the original sequence (e.g., transmitted at the current LL window size prior to adjustment). In some embodiments, if criterion 2) is met, the receiver may generate an LL Rx status PDU to suggest a larger LL window. The transmitter may continue transmitting LL application PDUs until the proposed window size is reached. In this case, the sequence of LL application PDUs received by the receiver is longer than the length of the original sequence (e.g., has more total LL application PDUs).

X0 and Y0 may each be a predetermined threshold. In some embodiments, X0 may be a desired high percentage (e.g., equal to or greater than 50%, such as 52%, 55%, 60%, 65%, 70%, 75%, 80%, 85%, 90%, 95%, 98%, etc.) of the maximum available on-chip memory for the connection, and Y0 may be a desired low percentage (e.g., less than 50%, such as 48%, 45%, 40%, 35%, 30%, 25%, 20%, 15%, 10%, 5%, 2%, etc.) of the maximum available on-chip memory for the connection. In some embodiments, instead of percentages, X0 may be a desired high capacity value and Y0 may be a desired low capacity value.

In an example, the receiver may allocate 16kB (e.g., link memory) for the connection, where x0=10 kB (e.g., 62.5% of link memory). Assuming that the average LL application PDU size is 1kB and that LL application PDUs with sn=n are missing, LL application PDUs with sn=n+1, … … to sn=n+10 are received and/or cached in the link memory. The receiver may then transmit the proposed LL Rx status PDU (e.g., rx status PDU 204) with LL window=10 (e.g., in field 207). Upon receiving the LL Rx status PDU, the transmitter can update the LL Tx window for this connection to 10 and stop sending any new LL application PDUs. In some embodiments, the transmitter may retransmit the LL application PDU of sn=n until the LL application PDU is positively acknowledged.

In another example, the current LL window size for a connection may be 16, and X0 equals 50%. Assuming that the average LL application PDU size is 1kB and that LL application PDUs with sn=n are missing, LL application PDUs with sn=n+1, … … to sn=n+10 are received and/or cached in the link memory. The receiver will then send an LL Rx status PDU with LL window=8 (e.g., in field 207). Upon receiving the LL Rx status PDU, the transmitter may update its LL Tx window to 8 and stop sending any new LL application PDUs. In some embodiments, the transmitter may retransmit the LL application PDU of sn=n until the LL application PDU is positively acknowledged.

In a second scenario, if the current data transmission (e.g., transmission of the first portion of the sequence) results in user throughput being too high or too low at UCI (e.g., 105), a UWB device, such as a receiver in UWB communications, may provide an Rx status value for flow-dependent throughput control. The receiver may include the suggested LL window size in field 207 to make a suggestion to the transmitter. The proposed LL window size may lead to better flow control on the receiver side. In UWB communication, the effective user throughput at UCI is calculated as Where the LL window size represents the number of LL application PDUs transmitted by the transmitter without receiving an ACK, the LL PDU size represents the size of the LL application PDUs, and the average ACK RTT represents the average round trip time of the ACKs for the LL application PDUs. In some embodiments, UCI (UWBS host interface) may be overloaded and may not have sufficient bandwidth to carry data traffic. If the traffic on this connection is reduced, the UCI will be assisted in transferring all application data to the host.

The receiver may be a controller or a slave. In some embodiments, the receiver may determine the user throughput for the connection at UCI and generate a LL Rx status PDU (e.g., rx status PDU 204) with an Rx status value using the following criteria:

1) UCI throughput > X1 Mbps; or (b)

2) UCI throughput is less than Y1 Mbps; or (b)

3) The host of the receiver sends UWBS a command to decrease or increase the transmission bit rate.

In some embodiments, if criterion 1) is met, the receiver may transmit an LL Rx status PDU to the transmitter to suggest a smaller LL window for the connection. In some embodiments, if criterion 2) is met, the receiver may transmit the LL Rx status PDU to the transmitter to suggest a larger LL window for the connection. In some embodiments, if criterion 3) is met, the receiver may transmit a LL Rx status PDU to the transmitter to suggest a smaller or larger LL window according to the host's command.

X1 and Y1 may each be a predetermined threshold. In some embodiments, the values of X1 and Y1 may depend at least in part on the type of interface (e.g., UCI) and the capabilities of the interface. In some embodiments, X1 is a desired high bandwidth value and Y1 is a desired low bandwidth value. In some embodiments, X1 and Y1 may each be a percentage of the maximum throughput capability of UCI. For example, X1 may be equal to or greater than 50% (e.g., 52%, 55%, 60%, 65%, 70%, 75%, 80%, 85%, 90%, 95%, 98%, etc.) of the maximum throughput at UCI, and Y1 may be less than 50% (e.g., 48%, 45%, 40%, 35%, 30%, 25%, 20%, 15%, 10%, 5%, 2%, etc.) of the maximum throughput at UCI.

In some embodiments, the receiver is a controller and may have multiple connections with multiple controllers. The UCI of the controller may have a large amount of data to be delivered to the host (upper layer). The receiver may calculate UCI throughput for one or more connections and may determine a priority for each connection. If the UCI throughput of one or more connections is too high using the above criteria, the controller may select one or more connections with lower priority (e.g., starting from the lowest priority connection) and transmit LL Rx status PDUs suggesting a reduced LL window size for the selected connection. The selected connection may or may not be a connection with an undesirably high throughput/bandwidth at the UCI. The receiver/controller may continue to decrease the LL window size of another low priority connection (in ascending order of priority, e.g., a second-lowest priority connection) until the total user throughput at the UCI is reasonably low and the UCI operates in a secure mode of operation. If the UCI throughput of one or more connections is too low using the above criteria, the controller may select one or more connections with higher priority (e.g., starting from the highest priority connection) and transmit an LL Rx status PDU suggesting an increased LL window size for the selected connection. The selected connection may or may not be a connection with an undesirably low throughput/bandwidth at the UCI. The controller may continue to increase the LL window size of another connection (in descending order of priority, e.g., the next highest priority connection) until the total user throughput at the UCI is reasonably high and the UCI operates in the secure mode of operation. Thus, a transmitter receiving the LL Rx status PDU may adjust the LL window size, e.g., by adjusting the number of LL application PDUs (e.g., application data PDUs 202-2) that are to be transmitted as the second portion of the sequence, such that the adjusted sequence/LL window size may create more desirable conditions for data transmission on the receiver side.

In a third scenario, if the current data transfer (e.g., the transfer of the first part of the sequence) results in too high or too low a CPU usage, then a UWB device, such as a receiver in UWB communication, may provide an Rx state value for flow-dependent CPU control. The receiver may include the proposed LL window size in the LL Rx status PDU (e.g., in field 207) to make a proposal to the transmitter. In some embodiments, the on-chip CPU of UWBS may be a CPU with limited processing power. The CPU utilization of the data stack grows linearly with PDU rate. Thus, if the number of LL application PDUs per second is high, CPU usage may be high. For example, if the CPU usage exceeds the CPU usage threshold, the receiver may transmit an LL Rx status PDU (e.g., rx status PDU 204) to the transmitter to suggest a smaller LL window size. The receiver may be a controller or a slave.

In some embodiments, the receiver is a controller and may have established multiple connections with multiple slaves. The on-chip CPU may be overloaded by processing LL application PDUs from more than one connection. If the CPU usage is too high, the receiver may determine the priority of each connection. The receiver may select one or more connections with lower priority (e.g., starting from the lowest priority connection) and transmit LL Rx status PDUs suggesting a reduced LL window size for the selected connection. The receiver/controller may continue to decrease the LL window size for another low priority connection (in ascending order of priority, e.g., the next lower priority connection) until CPU utilization is relatively low. If CPU usage is too low, the controller may select one or more connections with higher priority (e.g., starting from the highest priority connection) and transmit an LL Rx State PDU suggesting an increased LL window size for the selected connection. The controller may continue to increase the LL window size of another connection (in descending order of priority, e.g., the next highest priority connection) until CPU utilization is relatively high. Thus, a transmitter receiving the LL Rx status PDU may adjust the LL window size, e.g., by adjusting the number of LL application PDUs (e.g., application data PDUs 202-2) that are to be transmitted as the second portion of the sequence, such that the adjusted sequence/LL window size may create more desirable conditions for data transmission on the receiver side. For example, if the CPU usage is too high, the transmitter may stop transmitting LL application PDUs.

In some embodiments, the receiver determines that the CPU usage is too high if the CPU usage exceeds a CPU usage threshold that is a predetermined percentage of the maximum CPU usage, e.g., equal to or greater than 50%, e.g., 52%, 55%, 60%, 65%, 70%, 75%, 80%, 85%, 90%, 95%, 98%, etc. In some embodiments, the receiver determines that the CPU utilization is too low if the CPU utilization is less than a predetermined percentage of the maximum CPU utilization, such as less than 50%, e.g., 48%, 45%, 40%, 35%, 30%, 25%, 20%, 15%, 10%, 5%, 2%, etc.

Fig. 3A shows a signaling diagram 300 between UWB device 1 (transmitter) and UWB device 2 (receiver), wherein UWB device 1 transmits LL Tx state PDUs containing the Tx state of UWB device 1 to UWB device 2. As shown in fig. 3A, UWB device 1 transmits an application data PDU 302 (e.g., LL application PDU) to UWB device 2. In some embodiments, UWB device 1 receives ACK 306 for application data PDU 302 from UWB device 2. In some embodiments, UWB device 1 retransmits application data PDU 302 without receiving ACK 306, and/or may not receive an ACK for the retransmission. For simplicity, the retransmission and ACK for the retransmission are not shown in fig. 3A. UWB device 1 may also transmit Tx status PDU 304 (e.g., LL Tx status PDU with Tx status of UWB device 1) to UWB device 2. In some embodiments, UWB device 306 does not receive an ACK before transmitting Tx status PDU 304. Fig. 3B illustrates an example data frame 301 of a Tx status PDU 304, according to some embodiments. As shown in fig. 3B, data frame 301 is a LL PDU that includes field 303 "message type = Tx status", field 305 "message header 305", and field 307"Tx status value: tx statistics). In some embodiments, the "Tx statistics" of field 307 includes statistics of the transmitters of UWB device 1, calculated based on the number of LL application PDUs transmitted, retransmitted, and acknowledged in the current and/or previous phases. In some embodiments, UWB device 1 is a slave and UWB device 2 is a controller, and the Tx statistics are used to optimize the slot allocation of the controller. In some embodiments, UWB device 1 is a controller or slave and does not transmit Tx statistics (not shown). Alternatively, UWB device 1 may use Tx statistics to adjust (e.g., increase or decrease) its physical bit rate. The different scenarios of the data frame 301 are described below.

Fig. 3C illustrates a scenario in which an LL Tx status PDU (e.g., tx status PDU 304) may be used to optimize slot allocation, according to some embodiments. Currently, the slot allocation is done a priori by the controller (e.g., UWB device 2) at the beginning of a transmission round containing N time slots distributed in one or more phases, N being a positive integer. The slot allocation of the N time slots is notified to the slave (e.g., UWB device 1) by a data transfer control message (DTPCM) message from the controller. For example, as shown in FIG. 3C, at the beginning of stage 310, the controller allocates a plurality of time slots 314-1, 314-2, 314-3, 314-4, 314-5, 314-6, 314-7, … … for communication between the controller and the three slaves 1, 2, and 3. Time slots 314-1 and 314-2 are allocated to slaves 1 and 2 to transmit data to the controllers, respectively. Time slots 314-3 and 314-4 are allocated to the controllers to send ACKs to slaves 1 and 2, respectively. Time slots 314-5 and 314-6 are allocated to slaves 1 and 2 after time slots 314-1, 314-2, 314-3 and 314-4, respectively, to retransmit data to the controllers if needed. The slave 3 may have data to transmit but there is not enough time slot in stage 310. Time slots 314-7 are allocated to the slave 3 in stage 310 to transmit data to the controller. However, there are not enough slots for the slave 3 to transmit all of its data in stage 310. Thus, time slots 316-1 and 316-2 are allocated to the controller in stage 312 (e.g., a stage subsequent to stage 310) to send an ACK and to the slave 3 to retransmit the data. In other words, time slots 314-5 and 314-6 are pre-allocated regardless of whether a retransmission is required or not, and can be wasted without requiring a retransmission from slaves 1 and 2. If the controller knows a priori (prior to assigning the time slots of data phase 1) that the data of slaves 1 and/or 2 does not need time slots for retransmission, the controller may assign these time slots (e.g., 314-5 and/or 314-6) to slave 3. the slave 3 may transmit its pending data in stage 310 without waiting to stage 312. Thus, if the controller has updated information about the statistics of the data transmission and retransmission, it may optimize the slot allocation algorithm and allocate the time slots when they are most likely to be needed based on the statistics. In some embodiments, the controller does not allocate time slots to the slave when the time slots are unlikely to be needed based on the statistics. In various embodiments, the controller may receive statistics from the slave or calculate statistics itself/locally. The locally received or calculated statistics may be used to optimize the slot allocation at the beginning of the next round. In some embodiments, the slave may transmit the Tx status PDU 304 regularly or at the end of the data phase. In some embodiments, the controller may also calculate its Tx state regularly or at the end of the data phase.

The Tx statistics may reflect statistics on recent LL application PDU transmissions and retransmissions to the controller. For example, tx statistics may include, but are not limited to, average number of transmissions of LL application PDUs, minimum number of transmissions and/or maximum number of transmissions per LL application PDU, and the like. In some embodiments, tx statistics may be calculated based on the following metrics:

X0: the number of LL application PDUs transmitted since the last Tx status PDU 304;

X1: the number of LL application PDUs or the percentage of X0 that have been positively acknowledged at the first transmission;

X2: the number of LL application PDUs or the percentage of X0 that are positively acknowledged at the first retransmission; and

X3: the number of LL application PDUs that have not been positively acknowledged after one retransmission or the percentage of X0.

In some embodiments, a controller (e.g., UWB device 2) transmits LL application PDUs to each of one or more controllers (e.g., UWB device 1) in one or more phases. The slave may send Tx statistics to the controller after M LL application PDUs transmitted since the last Tx status PDU 304 (M is a configuration parameter and N is the number of slots distributed in one or more phases, e.g., m=n) and/or in the last slot of the round the controller has allocated to the slave. Thus, the controller may have an updated view of Tx statistics of all connections in both directions, and thus a more complete and regularly updated view of pending data (e.g., waiting time slots for transmission/retransmission) on all connections in both directions. Therefore, the controller more easily optimizes the use of the UWB channel.

In an example, at the beginning of a round, the controller determines that pending data connecting "slave k (e.g., UWB device 1) to the controller (UWB device 2)" requires the complete transmission of n0 LL application PDUs. The controller may also receive an LL Tx status PDU (Tx status PDU 304) from slave k at the end of the last round, where the Tx status indicates Tx statistics from slave k in the last round. The controller also knows from Tx status PDU 304 that in the last round, X0 is equal to X1 for this connection, which means that all LL application PDUs were successfully transmitted at the first transmission. Thus, the controller may allocate n0 time slots to slave k in the current round. Referring back to fig. 3C, time slots 314-5 and 314-6 may not be allocated. In another example, if Tx status PDU 304 indicates x1=0.5×x0 and x2=0.5×x0, meaning that the LL application PDU requires an average of 1.5 transmissions in the last round, the controller may allocate about 1.5×n0 time slots to slave k for the connection. In another example, if Tx status PDU 304 indicates x1=x2=0 and x3=x0, the controller may allocate 2 time slots for retransmission of each LL application PDU and thus 3×n0 time slots to slave k for connection.

In some embodiments, the controller may calculate X0, X1, X2, and X3 for its own Tx statistics, similar to the above. The controller may use its own Tx statistics to optimize the slot allocation for the connection.

In another case, the UWB device may determine its own/local Tx statistics and use it to adjust/increase the bit rate for data transmission. For example, the UWB channel between the transmitter and receiver may be reloaded, and the Tx statistics may reflect collisions in the UWB channel. In some embodiments, the transmitter may calculate its local statistics on the number of retransmissions for a given connection, such as the number of LL application PDUs successfully transmitted at the time of the first transmission, and the number of LL application PDUs that need one or more retransmissions. The transmitter may calculate Tx statistics over a sliding window (e.g., a predetermined time window or a window of N recently transmitted LL application PDUs). If some LL application PDUs are positively acknowledged, the transmitter may determine that the link budget is good. If the number of retransmitted LL application PDUs is significantly higher than the number of LL application PDUs that were positively acknowledged at the time of the first transmission, the transmitter may determine that the connection is subject to UWB packet collisions. The transmitter may then select a higher modulation rate (e.g., switch from a Base Pulse Repetition Frequency (BPRF) to a High Pulse Repetition Frequency (HPRF) and/or switch from 6.8Mbps to 27.2 Mbps). After bit rate adjustment, the transmission duration of the LL application PDUs or the number of LL application PDUs transmitted in the UWB channel will be much smaller and the collision probability may be reduced. For this purpose, the transmitter may be able to select from more than one physical layer (PHY) bit rate for the session. The transmitter may then adapt its bit rate based on its recent LL Tx statistics history. Fig. 3D shows a comparison of talk time per LL application packet size between modulation rate 1 (6.8 Mbps) and modulation rate 2 (27.2 Mbps). The x-axis represents LL application PDU size and the y-axis represents talk time. Fig. 3D shows that talk time decreases significantly as modulation rate increases.

The transmitter may be a controller or a slave. In some embodiments, the transmitter is a slave and may calculate its Tx statistics after N transmitted LL application PDUs, or calculate Tx statistics accumulated in previous rounds. In an example, if the Tx statistics show t1×x0< (x1+x2+x3) < t2×x0 (e.g., T1 and T2 are predetermined weighting factors less than 100%), the transmitter may determine that the packet error rate is not caused by a poor link budget (otherwise x1+x2+x3 should be close to 100% for the desired high link budget), but may be due to UWB collisions. In some embodiments, T1 is between 0% and 50%, and T2 is between 50% and 95%. For example, T1 may be 0%, 10%, 20%, 25%, 30%, 45%, and 50%; and T2 may be 55%, 60%, 70%, 80%, 85% and 90%. In some embodiments, T1 equals 30%, and T2 equals 70%. The transmitter may increase the modulation rate for the incoming round. If (x1+x2+x3) is close to X0, the transmitter may determine that the link budget may be poor (e.g., high noise and/or high interference) and that the poor link budget is the cause of the failed transmission. The transmitter may determine to improve transmission quality by reducing the modulation rate.

Fig. 4A is a flow chart of a method 400 for a UWB device (e.g., receiver) to implement dynamic adaptation using LL Rx status PDUs in a UWB system, according to some embodiments of the present disclosure. The method 400 is merely an example and is not intended to limit the present disclosure beyond what is explicitly recited in the claims. Additional operations may be provided before, during, and after the method 400, and some of the operations described may be replaced, removed, or moved around for additional embodiments of the method 400. For ease of illustration, fig. 4A is described in conjunction with fig. 2A and 2B.

At step 402, one or more first application data packets are received from a UWB device as a first portion of a sequence of application data packets. The sequence includes a first number of application data packets. Referring back to fig. 2A, application data PDU 202-1 is transmitted from UWB device 1 to UWB device 2 as a first portion of the sequence in the LL window.

At step 404, a receiver status value is determined based on the one or more first application data packets. Referring back to fig. 2B, "Rx status value: LL window size ", e.g., the proposed LL window size, is determined based on the application data PDU 202-1.

At step 406, the receiver state value is compared to a threshold value.

At step 408, a second number of application data packets of the sequence is determined based on a difference between the receiver status value and the threshold, the second number being different from the first number.

At step 410, a second number of messages indicating a sequence of application data packets is generated. Referring back to fig. 2B, a message, e.g., data frame 201, is generated that contains the proposed LL window size in field 207.

At step 412, the message is transmitted to the UWB device. Referring back to fig. 2A, an Rx status PDU 204, which is an example of a data frame 201, is transmitted from UWB device 2 to UWB device 1.

Fig. 4B is a flow chart of a method 401 for a UWB device (e.g., transmitter) to implement dynamic adaptation using LL Rx status PDUs in a UWB system, according to some embodiments of the present disclosure. The method 401 is merely an example and is not intended to limit the present disclosure beyond what is explicitly recited in the claims. Additional operations may be provided before, during, and after the method 401, and some of the operations described may be replaced, removed, or moved around for additional embodiments of the method 401. For ease of illustration, fig. 4B is described in conjunction with fig. 2A and 2B.

At step 403, one or more first application data packets are transmitted as a first portion of a sequence of application data packets. The sequence has a first number of application data packets. Referring back to fig. 2A, application data PDU 202-1 is transmitted from UWB device 1 to UWB device 2 as a first portion of the sequence in the LL window.

At step 405, a second number of messages containing application data packets in the sequence are received from the UWB device. The second number is different from the first number. Referring back to fig. 2b, uwb device 1 receives a message, such as data frame 201, containing the proposed LL window size in field 207.

At step 407, the number of second application data packets to be transmitted as a second portion of the sequence is adjusted such that the second number of application data packets is to be transmitted as the sequence. Referring back to FIG. 2A, the application data PDU 202-2 may be transmitted as a second portion of the sequence

Fig. 5A is a flow chart of a method 500 for a UWB device (e.g., transmitter) to implement dynamic adaptation using LL Tx state (or LL Tx state PDU) in a UWB system, according to some embodiments of the present disclosure. The method 500 is merely an example and is not intended to limit the present disclosure beyond what is explicitly recited in the claims. Additional operations may be provided before, during, and after the method 500, and some of the operations described may be replaced, removed, or moved around for additional embodiments of the method 500. For ease of illustration, fig. 5A is described in conjunction with fig. 3A and 3B.

At step 502, a first number of application data packets are transmitted. Referring back to fig. 3A, application data PDU 302 is transmitted from UWB device 1 to UWB device 2.

At step 504, an acknowledgment message for a second number of application data packets is received. Referring back to fig. 3a, uwb device 1 may receive ACKs 306 for a second number of application data packets in application data PDUs 302.

At step 506, a transmitter status value is determined based on at least one of the first number of application data packets or the second number of application data packets. Referring back to fig. 3A and 3B, the Tx status value contained in, for example, the LL Tx status PDU (e.g., in field 307) is determined.

Fig. 5B is a flow chart of a method 501 for a UWB device (e.g., receiver) to implement dynamic adaptation using LL Tx state (or LL Tx state PDU) in a UWB system, according to some embodiments of the present disclosure. The method 501 is merely an example and is not intended to limit the present disclosure beyond what is explicitly recited in the claims. Additional operations may be provided before, during, and after the method 501, and some of the operations described may be replaced, removed, or moved around for additional embodiments of the method 501. For ease of illustration, FIG. 5B is described in connection with FIGS. 3A-3C.

In step 503, a transmitter status value is received indicating a transmission condition of the UWB device over a first period of time. Referring back to fig. 3A and 3B, the Tx status value contained in, for example, the LL Tx status PDU (e.g., in field 307) is determined. The Tx status value is received from UWB device 2 to UWB device 1.

In step 505, a time slot is allocated for transmitting an application data packet in a second time period subsequent to the first time period based on the transmitter status value. As shown in fig. 3C, after receiving the Tx status value, a time slot is allocated for transmitting the application data packet. In some embodiments, if no retransmission is needed, no time slot retransmission is allocated to the slave.

Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.

Claims (10)

1. A method for optimizing data transfer in Ultra Wideband (UWB) communications, comprising:

receiving one or more first application data packets from a UWB device as a first portion of a sequence of application data packets, the sequence having a first number of application data packets;

Determining a receiver status value based on the one or more first application data packets;

comparing the receiver status value to a threshold value;

Determining a second number of application data packets of the sequence based on a difference between the receiver status value and the threshold value, the second number being different from the first number;

generating said second number of messages indicative of said sequence of application data packets; and

Transmitting the message to the UWB device.

2. The method according to claim 1, comprising:

In response to the receiver status value being equal to or greater than the threshold value, reducing or maintaining the first number such that the second number is less than or equal to the first number; and

In response to the receiver status value being less than the threshold value, the first number is increased such that the second number is greater than the first number.

3. The method according to claim 2, wherein:

Reducing a number of second application data packets to be less than a difference between the first number and the number of first application data packets in response to the receiver status value being equal to or greater than the threshold value; and

In response to the receiver status value being less than the threshold, the number of second application data packets is increased to be greater than the difference between the first number and the number of first application data packets.

4. The method of claim 3, further comprising storing the one or more first application data packets in a memory, wherein the receiver state value comprises a storage space of the one or more first application data packets in the memory, and the threshold comprises a threshold storage space.

5. The method of claim 4, wherein the threshold storage space is one of a predetermined percentage of the memory or a predetermined percentage of a total storage space of the sequence corresponding to the first number of application data packets.

6. The method according to claim 5, wherein:

The threshold storage space is equal to or greater than a predetermined percentage of the memory, or is equal to or greater than the predetermined percentage of the total storage space corresponding to the sequence of the first number of application data packets; and

The memory space is equal to or greater than the threshold memory space.

7. The method according to claim 5, wherein:

the threshold storage space is less than a predetermined percentage of the memory or is equal to or greater than the predetermined percentage of the total storage space corresponding to the sequence of the first number of application data packets; and

The memory space is less than the threshold memory space.

8. A method according to claim 3, wherein:

the receiver state value includes a throughput at a UWB Control Interface (UCI) calculated based on the first application data packet; and

The threshold includes a threshold bandwidth.

9. The method as recited in claim 8, further comprising:

Receiving one or more other sequences from one or more other connections, each of the other sequences having a plurality of application data packets;

Calculating, for each of the connection and other connections, a respective throughput at the UCI;

Determining that at least one of the throughput at the UCI is above the threshold bandwidth;

Comparing the priority of the connection for the sequence with the priority of the one or more other connections for the one or more other sequences; and

Determining that the connection for the sequence has the lowest priority,

Wherein the threshold bandwidth is equal to or greater than a predetermined percentage of a maximum throughput at the UCI.

10. The method as recited in claim 9, further comprising:

Receiving one or more other sequences from one or more other connections, each of the other sequences having a plurality of application data packets;

Calculating, for each of the connection and other connections, a respective throughput at the UCI;

determining that at least one of the throughput at the UCI is below the threshold bandwidth;

Comparing the priority of the connection for the sequence with the priority of the one or more other connections for the one or more other sequences; and

Determining that the connection for the sequence has the highest priority,

Wherein the threshold bandwidth is less than a predetermined percentage of a maximum throughput at the UCI.