GB2494871A - Re-transmission of timely data in a Bluetooth communication system - Google Patents
Re-transmission of timely data in a Bluetooth communication system Download PDFInfo
- Publication number
- GB2494871A GB2494871A GB1116245.0A GB201116245A GB2494871A GB 2494871 A GB2494871 A GB 2494871A GB 201116245 A GB201116245 A GB 201116245A GB 2494871 A GB2494871 A GB 2494871A
- Authority
- GB
- United Kingdom
- Prior art keywords
- data
- text
- packet
- buffer
- transmitter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1825—Adaptation of specific ARQ protocol parameters according to transmission conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
- H04L1/1877—Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/28—Timers or timing mechanisms used in protocols
Abstract
A method of controlling data transmission at a transmitter, the transmitter comprising a link controller that reads data from a buffer for transmission, the transmitter operating according to a protocol in which it is mandatory for the link controller to retransmit a packet until that packet is acknowledged e.g. Bluetooth (RTM), the method comprising transmitting a data packet including first data read from the buffer; determining to retransmit the packet due to lack of receipt of an acknowledgment (ACK) that the data packet was received; determining whether the first data in the buffer is still timely e.g. by checking if a timestamp has expired, and if it is not, deleting the first data from the buffer and replacing it with second, timely data. The data packet is then retransmitted with a payload comprising the second data. The invention is suited to the transmission of time critical data (TCD).
Description
INTELLECTUAL
. . PROPERTY OFFICE Application No. GB 1116245.0 RTM Date:9 January 201 The following terms are registered trademarks and should be read as such wherever they occur in this document: Bluetooth Intellectual Properly Office is an operaling name of Ihe Patent Office www.ipo.gov.uk
CONTROWNG DATA TRANSMISSION
This disclosure relates to controlling the transmission of data at a transmitter, for example controlling the transmission of time critical data, Many communication protocols define an acknowledgment procedure for the communication of messages between devices. Typically, an acknowledgment procedure requires that a receiver acknowledges the receipt of each packet or group of packets from a transmitter by sending an acknowledgment packet back to the transmitter. If the transmitter does not receive an acknowledgment for a packet it has transmitted then it retransmits that packet. Protocols often require that a packet continues to be retransmied until the transmitter receives an acknowledgment from the receiver that that packet has been received. This ensures reliable transfer to the receiver of all the data transmitted by the transmitter.
Bluetooth Low Energy devices as defined in the Bluetooth Specification v4.0 are required to use reliable data connections. Such devices are bound by their operating protocols to retransmit packets until they receive an acknowledgment from the receiver.
For the purpose of transmitting delivery critical data (DCD), i.e. data for which the delivery of the data is more important than the timeliness of the data transmittal, retransmitting packets until receipt of an acknowledgment from the receiver ensures reliable delivery and is not problematic. However, for the purpose of transmitting time critical data (TCD), i.e. data for which the timeliness of the transmittal is more important than that all the data is reliably delivered, retransmitting packets until receipt of an acknowledgment from the receiver is problematic because it introduces high latency into the communication of the data, The problem is exacerbated when the qualities of the links between the transmitter and receiver are low, because the lower the quality, the fewer the number of packets being received and acknowledged first time, the more retransmissions are required, the higher the latency. For real-time communications such as audio, this high latency is particularly problematic.
Thus, there is a need for an improved method of controlling data transmission at a transmitter that is bound to continue retransmitting a packet until it receives an acknowledgment, the method being more suitable for the transmission of time critical data.
According to a first aspect there is provided A method of controlling data transmission at a transmitter, the transmitter comprising a link controller that reads data from a buffer for transmission, the transmitter operating according to a protocol in which it is mandatory for the link controller to retransmit a packet until that packet is acknowledged) the method comprising, at the link controller: transmitting a data packet, the payload of the data packet comprising first data read from the buffer; determining to retransmit the data packet due to lack of receipt of an acknowledgment that the data packet was received; determining whether the first data in the buffer is still timely; and if the first data in the buffer is not still timely, deleting the first data from the buffer and replacing it with second data, and retransmitting the data packet wherein the payload of the retransmitted data packet comprises the second data read from the buffer.
Suitably, determining that the first data in the buffer is still timely if a timestamp associated with the first data has not expired.
Suitably, the timestamp is relative to a Bluetooth clock of the transmitter.
Suitably, a timestamp associated with time critical data is shorter than a timestamp associated with delivery critical data.
Suitably, determining that the first data in the buffer is still timely if a retry count associated with the first data has not expired.
Suitably, the transmitter further comprises an application) wherein the application generates data for transmission and metadata associated with the data for controlling the data transmission.
Suitably, the link controller interprets the metadata as comprising the timestamp mentioned above.
Suitably, the link controller interprets the metadata as comprising the retry count mentioned above.
Suitably) if the first data in the buffer is still timely, the link controller retransmits the data packet wherein the payload of the retransmitted data packet comprises the first data read from the buffer.
Suitably, the link controller applies a sequence number to each data packet, the sequence numbers of consecutive data packets being defined by the protocol, wherein if the first data in the buffer is not still timely, the link controller applies the same sequence number to the retransmitted data packet as was applied to the transmitted data packet.
Suitably, the link controller applies the same sequence number based on a determination that the link quality of the downlink from the transmitter is worse than the link quality of the uplink to the transmitter.
Suitably, the link controller applies a sequence number to each data packet, the sequence numbers of consecutive data packets being defined by the protocol, wherein if the first data in the buffer is not still timely, the link controller applies the sequence number of the subsequent packet to the retransmitted data packet.
Suitably, the link controller applies the sequence number of the subsequent packet based on a determination that the link quality of the downlink from the transmitter is better than the link quality of the uplink to the transmitter.
According to a second aspect there is provided a transmitter operable in accordance with a protocol in which it is mandatory for the transmitter to retransmit a packet until that packet is acknowledged, the transmitter comprising: a buffer configured to store data to be transmitted; and a link controller configured to read data from a buffer for transmission, the link controller operable to: transmit a data packet) the payload of the data packet comprising first data read from the buffer; determine to retransmit the data packet due to lack of receipt of an acknowledgment that the data packet was received; determine whether the first data in the buffer is still timely; and if the first data in the buffer is not still S timely, delete the first data from the buffer and replace it with second data, and retransmit the data packet wherein the payload of the retransmitted data packet comprises the second data read from the buffer.
Suitably, the transmitter may comprise an application, wherein the application is configured to generate data for transmission and metadata associated with the data for controlling the data transmission.
The following disclosure will now be described by way of example with reference to the accompanying drawings. In the drawings: figure 1 illustrates a layered protocol stack; figure 2 is a flow chart illustrating a method of controlling retransmitted data at a link controller; figure 3 is a flow chart illustrating a method of controlling data transmission at a link controller; and figure 4 illustrates a schematic diagram of an exemplary transmitter.
The following disclosure is directed at an effective way of controlling the transmission of data from a transmitter that operates according to a protocol in which it is mandatory for the transmitter to retransmit a data packet until it receives an acknowledgment (ACK) from the receiver confirming receipt of the data packet. For example, the following disclosure can be an effective way for such a transmitter to transmit data that is time-sensitive.
As mentioned above, Bluetooth Low Energy (BLE) devices are an example of devices required by the protocols according to which they operate (as defined in the Bluetooth specification v4.0) to retransmit a packet until receipt of an ACK from the receiver that that packet has been successfully received. For the purposes of communicating data, BLE devices operate according to the layered protocol stack structure illustrated in figure 1. The 5.
Application (APP) layer 100 is at the top of the stack, This is followed by the Generic Attribute Protocol (GATI) layer 102, the Attribute Protocol (ATT) layer 104, the Logical Link Control and Adaptation Protocol (L2CAP) layer 106 and the Link Controller (IC) layer 108.
These layers are defined in the Bluetooth Specification v4,0, All of these layers may be implemented in software. Alternatively, the Link Controller layer may be partially or entirely implemented in hardware.
Two types of acknowledgment schemes are defined in the Bluetooth Specification v4,0: indications and notifications. Indications are messages that incorporate an ACK received and processed by the LC layer and an ACK received and processed by the APP layer. This means that the transmitted packet is known to have been reliably transmitted at both the IC layer and the APP layer. Notifications are messages that incorporate an ACK received and processed by the LC layer only. The transmission of the packet is thus reliable at the LC layer but not at the APP layer. Notifications are more suitable than indications for Bluetooth Low Energy devices because they require a much lower overhead as a result of not providing an ACK at the APP layer.
Suitably then, in an exemplary system comprising two BIE devices operating in accordance with the Bluetooth Specification v4.0, the receiver uses notifications to acknowledge receipt of a data packet transmitted by the transmitter. Control of retransmissions primarily resides with the link controller which is the only layer in the protocol stack of figure 1 which receives ACKs from the receiver in this exemplary system. Suitably, the link controller reads data for transmission from a buffer. Each buffered data set can have associated with it an indication of timeliness. In an exemplary method, the link controller uses this indication of timeliness to control retransmissions as will now be explained with reference to figure 2.
At step 200, the link controller determines whether an ACK has been received from the receiver for a first data packet comprising first data transmitted by the transmitter.
Suitably, the link controller has a timeframe following transmittal of each data packet in which it expects to receive an ACK for that packet from the receiver. If the ACK has not been received within this timeframe, the link controller determines to retransmit the data packet. If the ACK for the first data packet is received then the link controller transmits the second data packet to the receiver (step 202). Preferably, the second data packet is the next packet after the first data packet in the sequence of data packets to be transmitted. If the ACK for the first data packet is not received then the link controller determines to re-transmit the first data packet (step 204). At step 206, the link controller determines if the S first data is still timely. If the first data is still timely, then at step 208, the link controller retransmits the first data packet in which the payload comprises the first data read from the buffer. If the first data is not still timely, then at step 210 the link controller deletes the first data from the buffer. Second data is written to the buffer in step 212. Then, at step 214, the link controller retransmits the first data packet in which the payload comprises the second data read from the buffer. The payload does not comprise the first data. As an alternative to steps 212 and 214, the second data may have already been written to a second buffer. The link controller then retransmits the first data packet in which the payload comprises the second data read from the second buffer. The payload does not comprise the first data, In this way, the transmitter operates according to a protocol which mandates that a packet is to be retransmitted until it is acknowledged, but reduces the latency of the data transmission by replacing non-timely data with more recent data in the retransmitted packets. Thus, this method is more suitable for the transmission of time critical data.
Additionally, latency in the data transmission is further reduced by implementing the methods described herein at the link controller layer of the protocol stack illustrated in figure 1 rather than any of the higher layers. It takes time for each layer to process signals and provide an output to the layer above. Thus, providing the functionality to control the data content of the transmissions and retransmissions at the link controller rather than up at, for example, the APP layer, minimises the processing time at the transmitter and hence minimises latency in the data transmission. Thus, this method is more suitable for the transmission of time critical data.
Optionally, the determination to transmit data only if it is still timely is applied to all transmissions of that data, including the first transmission of that data. Figure 3 illustrates this process. Nth data is written to a buffer. At step 300, the link controller determines if the nth data is still timely. If the answer is yes, then at step 302, the link controller transmits a data packet with a payload which comprises the nth data read from the buffer.
If the answer is no, then at step 304, the link controller deletes the nth data from the buffer.
The link controller then moves on to assessing the next data, i.e. the (n+i)th data where i = 1. In step 306, the link controller determines if the (n+i)th data is still timely. If the answer is yes, then at step 308, the link controller transmits a data packet with a payload which comprises the (n+i)th data. If the answer is no, then at step 310, the link controller deletes the (n+i)th data from the buffer. Steps 306 and 310 iterate assessing each consecutive data until the link controller assesses that a data is still timely, at which point that data is incorporated into a data packet and transmitted.
Suitably, when the link controller determines that a data packet is to be retransmitted, but that the data in that data packet is no longer timely, the link controller preferably assesses the next data to determine if it is timely. If the next data is timely, the link controller transmits the next data in the payload of the retransmitted packet. However, if the next data is not timely, that data is deleted from the buffer, and the link controller assesses whether the data after that is timely. The iterative process continues until the link controller determines that a data is timely. Then the timely data is incorporated into the payload of the retransmitted packet and transmitted.
Suitably, each data unit which is assessed by the link controller for timeliness has associated with it an indication of timeliness applied by a higher layer in the protocol stack. The link controller interprets this indication of timeliness in order to determine whether the data is still timely.
For example, the indication of timeliness may be a timestamp. This timestamp may set an expiry time. The expiry time may be an absolute time after which the data associated with the timestamp is not to be transmitted. This absolute time may be relative to a clock in the transmitter. For example, this absolute time may be relative to a Bluetooth clock of the transmitter. Suitably, the timestamp is configurable in dependence on a property of the data being transmitted. As an example, delivery critical data is suitably allocated a long timestamp. This is because the priority for delivery critical data is that it is reliably transmitted, not that it is transmitted quickly. Suitably, the timestamp is infinity. This means that the link controller will always determine that the data is still timely, and will hence always opt to retransmit the data rather than replace the data with more recent data for retransmission. Time critical data, on the other hand, is suitably allocated a short S timestamp. This is because the priority for time critical data is that it is transmitted quickly, not that it is transmitted reliably. Suitably, the timestamp may be lOms. Thus, the link controller is able to control the latency on the link by replacing data for transmission whenever the acceptable latency limit of the data has been exceeded.
As a further example, the indication of timeliness may be a retry count. This retry count sets a limit to the number of times a transmitter will attempt to transmit the same data.
Suitably, this retry count is configurable in dependence on a property of the data being transmitted. For example, delivery critical data is suitably allocated a high retry count.
Suitably, the retry count for delivery critical data is infinity. Time critical data, on the other hand, is suitably allocated a small retry count. Suitably, the retry count for time critical data islor2.
Suitably, the APP layer generates data units for transmission and also generates metadata associated with each data unit. Suitably, this metadata incorporates information which the link controller interprets as an indication of timeliness. For example, the metadata incorporates the timestamp described above. Alternatively, the metadata incorporates the retry count described above. The link controller analyses the metadata associated with data in the buffer, and based on this analysis chooses to delete the data in the buffer or incorporate it into a data packet for transmission, Suitably, the metadata itself is not transmitted. If the link controller concludes that the data is no longer timely, then it deletes the data and its associated metadata, If the link controller transmits a data packet and receives an ACK, then it deletes the data and its associated metadata. If the link controller determines that data is still timely, it transmits the data but does not discard the data and its associated metadata. This is because if no ACK is received, then the link controller again analyses the metadata and determines to retransmit the data based on the timeliness of the data as indicated in the metadata.
Suitably, the link controller applies a sequence number to each data packet that it transmits.
This sequence number is associated with the payload of the data packet. Typically, consecutive packets are allocated consecutive sequence numbers in a sequence which is specified by the protocol according to which the transmitter and receiver operate. The S receiver expects consecutive packets that it receives to have consecutive sequence numbers in the sequence. In BLE, the sequence number sequence 101010101010... is used. So, in the example of two BLE devices communicating, the receiver expects consecutive received packets to alternate between having sequence number 0 and sequence number 1. Receipt of two packets having the same sequence number in a row is interpreted by the receiver as receipt of the same packet twice, and hence it discards the second received packet and does not send it up to the higher layers in the stack. This would happen, for example, if the receiver received a packet having sequence number 1 and sent an ACK to the transmitter, but the transmitter did not receive the ACK and hence retransmitted the same packet having sequence number 1.
When a transmitter does not receive an ACK of a packet from a receiver, it is ambiguous to the transmitter whether this is because (i) the receiver did not receive the packet; or (2) the receiver received the packet but the transmitter did not receive the ACK. In such a situation, according to the above described methods, the transmitter may determine that the originally transmitted data is no longer timely and decide to transmit more recent data in the retransmitted packet. Consider the originally transmitted packet to have had a sequence number 1. The transmitter may determine to retransmit the packet with the same sequence number as the originally transmitted packet. If the transmitter retransmits the packet with the same sequence number as the originally transmitted packet, in this example sequence number 1, and if the receiver did not receive the original packet, and hence is still expecting a packet with sequence number 1, then the receiver receives this packet and passes the recent data up the stack. However, if the transmitter retransmits the packet with sequence number 1, but the receiver had received the original packet, then the receiver deletes the recent data without passing it up the stack) because the receiver is expecting a packet with sequence number 0 and hence interprets the receipt of a packet with sequence number 1 as a retransmission of a packet it has already received.
Alternatively, the transmitter may retransmit the packet with the next number in the sequence after the sequence number of the originally transmitted packet. In the example of the previous paragraph, the transmitter transmits the retransmitted packet with sequence number 0. In this case, the receiver receives this packet and, if the receiver did receive the S original packet and hence is expecting a packet with sequence number 0, the receiver passes the recent data up the stack. However, if the transmitter retransmits the packet with sequence number 0, but the receiver had not received the original packet, then the receiver deletes the recent data without passing it up the stack, because the receiver is expecting a packet with sequence number 1 and hence interprets the receipt of a packet with sequence number 0 as a retransmission of a packet it has already received.
Suitably, the transmitter chooses to (i) maintain the sequence number of the retransmitted packet to be the same as that of the originally transmitted packet; or (ii) change the sequence number of the retransmitted packet to be the next sequence number in the sequence that the receiver expects to receive, based on an indication of whether it is more likely that the receiver did not receive the original packet or that the transmitter did not receive the ACK from the receiver. For example, this indication may be based on an analysis of the link quality on the downlink to the receiver and the uplink from the receiver. If the downlink quality is lower than the uplink quality, then it is more likely that the receiver did not receive the original packet. In this case, the transmitter suitably transmits the retransmitted packet with the same sequence number as the originally transmitted packet.
On the other hand, if the uplink quality is lower than the downlink quality, then it is more likely that the receiver received the original packet but that the transmitter did not receive the ACK. In this case, the transmitter suitably transmits the retransmitted packet with the next sequence number in the sequence that the receiver expects to receive. The quality may be based on a signal to noise ratio) an error rate, RSSI or similar measure.
A receiver implemented solution to the above-described sequence number problem is to pass data up the stack even if the receiver interprets a packet to have been received twice.
The methods described herein are suitable for application to the transmission of any type of data because the determination of whether the data is still timely or not is configurable for different types of data as previously explained. If it is more important that data is reliably delivered to the recipient than that the data gets to the recipient quickly, then the data is considered to still be timely for longer than if it is more important that data is delivered to the recipient quickly than that it is delivered to the recipient reliably. The methods described herein are particularly suitable for use with time critical data which is being transmitted in accordance with a protocol in which the transmitter is bound to retransmit a packet until an ACK is received, because these methods reduce the latency involved with the transmission of such data, The methods described herein are particularly suitable for the transmission of real time data. Examples of applications transmitting time critical data are: monitoring applications, for example a thermometer which regularly communicates a temperature; handheld gaming devices for which the demand for low latency is high for the communication of control signals; and the transmission of audio signals for which low latency is also of particularly high demand.
Although Bluetooth Low Energy devices have been referred to in the examples herein, this is just an example. The disclosure applies to any transmitter whose link controller is restricted by a protocol which it operates in accordance with, to continue retransmitting data packets until they are acknowledged.
Figure 4 illustrates a schematic diagram of an exemplary transmitter according to the methods described herein. Transmitter 400 comprises an application 402 and a link controller 405. The application incorporates a module for data and metadata generation 404. Link controller 405 incorporates a buffer 408 which stores data from the application.
Link controller also incorporates logic 410 which receives and interprets metadata associated with the buffered data from the application. Logic 410 controls the buffer 408 to either delete its contents or output them to packet formation unit 412. Packet formation unit 412 generates a packet by formatting the data into a payload and including a header.
Following packet formation the data packet is output to packet transmission unit 414 for transmission. Packet transmission unit 414 incorporates functionality known in the art, for example modulation, shaping, frequency mixing etc. It is understood that figure 4 illustrates the layout of a transmitter in terms of functional boxes. The operations of one or more of these functional boxes may be combined or performed by separate components. It will be understood that this figure does not illustrate those conventional components of the transmitter known to a person skilled in the art.
Preferably, the link controller described herein is implemented in software. Alternatively, S the link controller is implemented in hardware.
The applicant draws attention to the fact that the present invention may include any feature or combination of features disclosed herein either implicitly or explicitly or any generalisation thereof, without limitation to the scope of any of the present claims. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.
Claims (1)
- <claim-text>C LA I1. A method of controlling data transmission at a transmitter, the transmitter comprising a Pink controller that reads data from a buffer for transmission, the transmitter operating according to a protocol in which it is mandatory for the link controller to retransmit a packet until that packet is acknowledged, the method comprising, at the Fink controller: transmitting a data packet, the payload of the data packet comprising first data read from the buffer; determining to retransmit the data packet due to lack of receipt of an acknowledgment that the data packet was received; determining whether the first data in the buffer is still timely; and if the first data in the buffer is not still timely, deleting the first data from the buffer and replacing it with second data, and retransmitting the data packet wherein the payload of the retransmitted data packet comprises the second data read from the buffer.</claim-text> <claim-text>2. A method according to claim 1, comprising determining that the first data in the buffer is still timely if a timestamp associated with the first data has not expired.</claim-text> <claim-text>3. A method according to claim 2, wherein the timestamp is relative to a Bluetooth clock of the transmitter.</claim-text> <claim-text>4. A method according to claim 2 or 3, wherein a timestamp associated with time critical data is shorter than a timestamp associated with delivery critical data.</claim-text> <claim-text>5. A method according to claim 1, comprising determining that the first data in the buffer is still timely if a retry count associated with the first data has not expired.</claim-text> <claim-text>6. A method according to any preceding claim, wherein the transmitter further comprises an application, wherein the application generates data for transmission and metadata associated with the data for controlling the data transmission.</claim-text> <claim-text>7. A method according to claim 6, wherein the link controller interprets the metadata as comprising the timestamp of any of claims 2 to 4.</claim-text> <claim-text>8. A method according to claim 6, wherein the link controller interprets the metadata as comprising the retry count of claim 5.</claim-text> <claim-text>9. A method according to any preceding claim, wherein if the first data in the buffer is still timely, the link controller retransmits the data packet wherein the payload of the retransmitted data packet comprises the first data read from the buffer.</claim-text> <claim-text>10. A method according to any preceding claim, wherein the link controller applies a sequence number to each data packet, the sequence numbers of consecutive data packets being defined by the protocol, wherein if the first data in the buffer is not still timely, the link controller applies the same sequence number to the retransmitted data packet as was applied to the transmitted data packet.</claim-text> <claim-text>11. A method according to claim 10, wherein the link controller applies the same sequence number based on a determination that the link quality of the downlink from the transmitter is worse than the link quality of the uplink to the transmitter.</claim-text> <claim-text>12. A method according to any of claims 1 to 9, wherein the link controller applies a sequence number to each data packet, the sequence numbers of consecutive data packets being defined by the protocol, wherein if the first data in the buffer is not still timely, the link controller applies the sequence number of the subsequent packet to the retransmitted data packet.</claim-text> <claim-text>13. A method according to claim 12, wherein the link controller applies the sequence number of the subsequent packet based on a determination that the link quality of the downlink from the transmitter is better than the link quality of the uplink to the transmitter.</claim-text> <claim-text>14. A transmitter operable in accordance with a protocol in which it is mandatory for the transmitter to retransmit a packet until that packet is acknowledged, the transmitter comprising: a buffer configured to store data to be transmitted; and a link controller configured to read data from a buffer for transmission, the link controller operable to: transmit a data packet, the payload of the data packet comprising first data read from the buffer; determine to retransmit the data packet due to lack of receipt of an acknowledgment that the data packet was received; determine whether the first data in the buffer is still timely; and if the first data in the buffer is not still timely, delete the first data from the buffer and replace it with second data, and retransmit the data packet wherein the payload of the retransmitted data packet comprises the second data read from the buffer.</claim-text> <claim-text>15. A transmitter according to claim 14, further comprising an application, wherein the application is configured to generate data for transmission and metadata associated with the data for controlling the data transmission.</claim-text>
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US13/237,380 US20130070581A1 (en) | 2011-09-20 | 2011-09-20 | Controlling Data Transmission |
| GB1116245.0A GB2494871B (en) | 2011-09-20 | 2011-09-20 | Re-transmission of timely data in a Bluetooth communication system |
| DE102012018614A DE102012018614A1 (en) | 2011-09-20 | 2012-09-20 | Controlling a data transmission |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1116245.0A GB2494871B (en) | 2011-09-20 | 2011-09-20 | Re-transmission of timely data in a Bluetooth communication system |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| GB201116245D0 GB201116245D0 (en) | 2011-11-02 |
| GB2494871A true GB2494871A (en) | 2013-03-27 |
| GB2494871B GB2494871B (en) | 2018-04-11 |
Family
ID=44937571
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB1116245.0A Expired - Fee Related GB2494871B (en) | 2011-09-20 | 2011-09-20 | Re-transmission of timely data in a Bluetooth communication system |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20130070581A1 (en) |
| DE (1) | DE102012018614A1 (en) |
| GB (1) | GB2494871B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7266150B2 (en) | 2001-07-11 | 2007-09-04 | Dolby Laboratories, Inc. | Interpolation of video compression frames |
| US8620379B2 (en) * | 2010-12-06 | 2013-12-31 | Broadcom Corporation | Windows portable devices interface for Bluetooth low energy devices |
| CN110856077A (en) * | 2014-05-20 | 2020-02-28 | Gn瑞声达A/S | New method for wireless transmission of digital audio |
| US10248447B2 (en) * | 2015-11-25 | 2019-04-02 | Red Hat, Inc. | Providing link aggregation and high availability through network virtualization layer |
| EP3185455A1 (en) * | 2015-12-21 | 2017-06-28 | Thomson Licensing | Method and apparatus for detecting packet loss in staggercasting |
| CN113271641A (en) * | 2021-05-18 | 2021-08-17 | 南京大学 | Method for reducing packet loss rate based on Bluetooth scattering network communication |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002030033A2 (en) * | 2000-10-06 | 2002-04-11 | Apple Computer, Inc. | Improved connectionless arq protocol |
| US20060256785A1 (en) * | 2005-05-10 | 2006-11-16 | Kabushiki Kaisha Toshiba | Mobile terminal |
| WO2007131880A1 (en) * | 2006-05-16 | 2007-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Bi-directional rlc non-persistent mode for low delay services |
| EP1914922A1 (en) * | 2006-10-16 | 2008-04-23 | Alcatel Lucent | Intelligent IPTV retransmission request |
| US20100070813A1 (en) * | 2008-09-18 | 2010-03-18 | Sheng-Chung Chen | Packet Retransmission Method and Related Electronic Device |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7424494B2 (en) * | 2001-08-23 | 2008-09-09 | Comverse, Inc. | System for synchronizing voice messaging subscriber information |
| CA2397905A1 (en) * | 2002-08-13 | 2004-02-13 | University Of Ottawa | Differentiated transport services for enabling real-time distributed interactive virtual systems |
| US7539143B2 (en) * | 2003-08-11 | 2009-05-26 | Netapp, Inc. | Network switching device ingress memory system |
| US9380269B2 (en) * | 2003-09-23 | 2016-06-28 | Time Warner Cable Enterprises Llc | Scheduling trigger apparatus and method |
| US8852164B2 (en) * | 2006-02-09 | 2014-10-07 | Deka Products Limited Partnership | Method and system for shape-memory alloy wire control |
| EP2059060B1 (en) * | 2006-09-01 | 2015-03-04 | Mitsubishi Electric Corporation | Radio communication system and radio communication method |
| US8102836B2 (en) * | 2007-05-23 | 2012-01-24 | Broadcom Corporation | Synchronization of a split audio, video, or other data stream with separate sinks |
| US8289895B2 (en) * | 2009-04-24 | 2012-10-16 | Research In Motion Limited | Relay link HARQ operation |
| US8452888B2 (en) * | 2010-07-22 | 2013-05-28 | International Business Machines Corporation | Flow control for reliable message passing |
-
2011
- 2011-09-20 US US13/237,380 patent/US20130070581A1/en not_active Abandoned
- 2011-09-20 GB GB1116245.0A patent/GB2494871B/en not_active Expired - Fee Related
-
2012
- 2012-09-20 DE DE102012018614A patent/DE102012018614A1/en not_active Withdrawn
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002030033A2 (en) * | 2000-10-06 | 2002-04-11 | Apple Computer, Inc. | Improved connectionless arq protocol |
| US20060256785A1 (en) * | 2005-05-10 | 2006-11-16 | Kabushiki Kaisha Toshiba | Mobile terminal |
| WO2007131880A1 (en) * | 2006-05-16 | 2007-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Bi-directional rlc non-persistent mode for low delay services |
| EP1914922A1 (en) * | 2006-10-16 | 2008-04-23 | Alcatel Lucent | Intelligent IPTV retransmission request |
| US20100070813A1 (en) * | 2008-09-18 | 2010-03-18 | Sheng-Chung Chen | Packet Retransmission Method and Related Electronic Device |
Non-Patent Citations (1)
| Title |
|---|
| "Deadline-Aware Video Delivery in a Disrupted Bluetooth Network", Razavi et al, 2007 IEEE Sarnoff Symposium, 30 April - 2 May 2007. * |
Also Published As
| Publication number | Publication date |
|---|---|
| DE102012018614A1 (en) | 2013-01-24 |
| GB201116245D0 (en) | 2011-11-02 |
| GB2494871B (en) | 2018-04-11 |
| US20130070581A1 (en) | 2013-03-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7746786B2 (en) | Retransmission control method and device | |
| EP1527431B1 (en) | Method and apparatus for reducing transmission errors in a third generation cellular system | |
| KR101313291B1 (en) | Method for Retransmission in Mobile Communicaton System | |
| US8856633B2 (en) | Millimeter-wave communications for peripheral devices | |
| EP2959622B1 (en) | System and method for multi-layer protocol selection | |
| JP5432263B2 (en) | HARQ process restart after reporting CQI only | |
| KR102056880B1 (en) | Cross-layer scheduling based on lower layer feedback | |
| JP5587406B2 (en) | Method and apparatus for high-speed retransmission in radio link control layer confirmation mode | |
| US20130070581A1 (en) | Controlling Data Transmission | |
| KR20070033292A (en) | Method and apparatus for transmitting signaling data messages in a wireless communication system | |
| CN101119183A (en) | Retransmission control method and transmission equipment | |
| JP2007531432A5 (en) | ||
| WO2009051386A2 (en) | Method of performing arq procedure for transmitting high rate data | |
| KR20070121585A (en) | Method and apparatus for detection local nack in a wireless communications system | |
| CN102387485B (en) | The method and apparatus sent control signaling | |
| CN103873211B (en) | A kind of HARQ is retransmitted and blind checking method | |
| JP2012529800A (en) | Message resending method and apparatus | |
| RU2010115272A (en) | METHOD FOR PERFORMING A SURVEY PROCEDURE IN A WIRELESS COMMUNICATION SYSTEM | |
| US20130028189A1 (en) | Method and apparatus for using physical layer error control to direct media access layer error control | |
| CN102694631A (en) | Method and device for controlling data transmission | |
| WO2010128636A1 (en) | Communication system, communication device, communication method, and program | |
| CN102377544A (en) | Retransmission method in communication system | |
| US11258721B2 (en) | Radio link control (RLC) acknowledged mode (AM) data reception | |
| KR20070115787A (en) | Dual receiving window method and related apparatus for automatic retransmission request | |
| EP2736189B1 (en) | Status report processing method, communication device, and communication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PCNP | Patent ceased through non-payment of renewal fee |
Effective date: 20190920 |