Patent Application
20130034061
1. Technical Field
This disclosure relates to communication protocols. In particular, this disclosure relates to an implementation of the reverse direction protocol for wireless communications.
2. Related Art
Continual development and rapid improvement in wireless communications technology have lead the way to increased data rates and broad wireless functionality in many different environments, including the home and business environments. These developments and improvements have been driven in part by the widespread adoption of digital media, including high definition video and music. The most recent developments in wireless connectivity promise new functionality and data rates far exceeding rates that the 802.11n and the 802.11TGac standards provide. These recent developments include the Wireless Gigabit Alliance (WiGig) 60 GHz wireless specification.
The WiGig specification provides data transmission rates of up to 7 Gbps in a single stream, which is more than 10 times faster than the highest data rate that the 802.11n multiple input mulitple output (MIMO) standard supports. At the same time, the WiGig specification implements backward compatibility with the 802.11 standard. Another benefit of the WiGig specification is that devices in the 60 GHz ecosystem will have the bandwidth to wirelessly communicate significant amounts of information without performance compromises, thereby eliminating the current need for tangles of cables to physically connect devices. WiGig devices may, for example, wirelessly stream high definition video content directly from a Blu-Ray player to a TV with little or no compression required.
The WiGig specification has adopted the reverse direction (RD) protocol that was originally specified in the 802.11n specification for contention based Transmit Opportunities (TXOPs), and has extended the RD protocol to allocation/contention free based Service Periods (SPs) that are defined in the WiGig specification. During a TXOP or SP, the default data flow is from the SP owner or TXOP holder to the SP destination or TXOP responder respectively, namely the forward direction. However, in many high quality of service (QoS) applications, immediate reverse direction data flow is very useful (i.e., data flow from the SP destination or TXOP responder back to the SP owner or TXOP holder respectively). In these cases, the SP owner or TXOP holder may initiate (as the RD initiator) one or more reverse direction grants (RDGs) for a specified maximum duration to potentially responding devices along with the data packets in the forward direction to give the peer device a chance to respond back with its data packets. The RD responder may accept the grant and then communicate data, if any is available, back to the RD initiator. The RD protocol provides a flexible, low latency, reverse direction communication channel that is also efficient because it does not incur the channel access and TXOP/SP scheduling overhead.
The WiGig specification, however, mandates far more challenging response times by an RD responder. Essentially, the RD responder must begin to transmit its sequence of data packets back to the RD initiator within the Short Interframe Spacing (SIFS) time if no acknowledgement is required for the data in the forward direction. The RD responder must also indicate whenever more data will follow by setting the MorePPDU bit field to 1. In the WiGig specification, the SIFS period is 3 μs (3 microseconds), compared with the much more generous 16 μs allowed in 802.11n.
Under the 802.11 standard, a “control wrapper frame” allows any control frame to be returned inside of (wrapped in) the control wrapper frame. The control frames wrapped in the control wrapper frame may include acknowledgement frames or block acknowledgement frames. The control wrapper frame also adds a High Throughput (HT) control field that includes the MorePPDU bit field. Accordingly, the RD responder may send a control wrapper frame and inform the RD initiator that the RD responder has more data to return by setting MorePPDU to 1 in the HT control field. Alternatively, the RD responder may inform the RD initiator that there is no more data to return by setting MorePPDU to 0. Using the control wrapper frame for this purpose, however, incurs the overhead of transmission of another control frame wrapped inside the control wrapper frame.
The WiGig specification does not support the control wrapper frame. The WiGig specification thereby eliminates one mechanism for informing the RD initiator that more data will be communicated to it over the reverse direction channel. In general, devices in the WiGig ecosystem face significant challenges in responding quickly enough (within the 3 μs SIFS time) to take advantage of the significant benefits of the RD protocol.
The system may be better understood with reference to the following drawings and description. In the figures, like reference numerals designate corresponding parts throughout the different views.
This description relates to the reverse direction protocol under standards such as the IEEE 802.11 standards or the WiGig standards, including the 60 GHz wireless specification promoted by the Wireless Gigabit Alliance and the IEEE 802.11TGad standard. Accordingly, the discussion below makes reference to reverse direction (RD) initiators and responders. The RD initiators and RD responders implement a reverse direction (RD) protocol that permits an RD responder to transmit data back to the RD initiator, even though the RD initiator presently owns the current transmission opportunity (TXOP) or Service Period (SP). The RD initiators and RD responders may be endpoints that communicate wirelessly or over physical connections.
The endpoints, and therefore the RD initiators and RD responders, may take many different forms. As examples, the endpoints may be cell phones, smart phones, laptop computers, personal data assistants, pocket computers, tablet computers, portable email devices, people or pets, or processes or threads executed in memory by a processor. Additional examples of endpoints include televisions, stereo equipment such as amplifiers, pre-amplifiers, and tuners, home media devices such as compact disc (CD)/digital versatile disc (DVD) players, portable MP3 players, high definition (e.g., Blu-Ray (™) or DVD audio) media players, or home media servers. Other examples of endpoints include musical instruments, microphones, climate control systems, intrusion alarms, audio/video surveillance or security equipment, video games, network attached storage, network routers and gateways, pet tracking collars, or other devices.
Endpoints may be found in virtually any context, including the home, business, public spaces, or automobile. Thus, as additional examples, endpoints may further include automobile audio head ends or DVD players, satellite music transceivers, noise cancellation systems, voice recognition systems, climate control systems, navigation systems, alarm systems, engine computer systems, or other devices.
Other examples of endpoints in the environment 100 include the application and file server 108 that is in communication with the laptop computer 110.
The endpoints may communicate wirelessly using the 802.11a/b/g/n/ac standards, according to the WiGig 60 GHz specification, or according to other wireless standards. In some cases, such as with the WiGig or 802.11n/ac standards, the endpoints are allocated SPs or obtain TXOPs by winning the channel access contention during which they are entitled to specific windows of time to transmit information without other endpoints attempting to access the channel. Furthermore, the endpoints may implement a RD protocol that permits a RD initiator to grant a RD responder the opportunity to transmit data back to the RD initiator during the RD initiator's TXOP or SP. A specific example will be provided below with respect to the TV 104 and the media player 102 to aid understanding, but it is noted that the techniques described below may be employed as part of a RD protocol in any environment by any of the endpoints for whatever reason the endpoints decide to use a reverse direction channel.
Setting the RDG bit to 1 indicates to the destination addressee (e.g., the TV 104) that it has an opportunity to establish a reverse direction communication channel, and that it may accept the RD grant to communicate data back to the RDG initiator (e.g., the media player 102). The RD responder (in this case the TV 104) needs to respond within the SIFS interval 308 (about 3 μs). The TV 104 does so by transmitting an acknowledgement (ACK) or block acknowledgement (BACK) 310, followed by a QoS Null frame 312 with the MorePPDU bit set to 1 to indicate that more data follows.
In particular, within a SIFS or Reduced Interframe Spacing Time (RIFS) 314, the TV 104 sends additional data in (optionally aggregated) QoS Data frames (e.g., the QoS Data frames 316 and 318). The QoS Data frames set MorePPDU to 1 to indicate that the TV 104 has additional data to transmit to the media player 102. The TV 104 continues to send data during its response burst until, as shown by the QoS Data frames 320 and 322, with MorePPDU set to 0, the TV 104 has no further data to transmit back to the media player 102. The media player 102 then transmits an ACK 324 of the response burst from the TV 104 and the RDG ends.
In terms of the response structure shown in
The signaling sequence shown in
The QoS Data frame 402 also includes a frame body field 416 specifically allocated to carry a data payload. To track and account for each data payload that is sent in a QoS Data frame 402, the sequence control field 410 in the QoS Data frame uses, for example, a 12 bit sequence number. The sequence number provides a specific number assigned to data payload in the QoS Data frame. The sequence number may be identical for each frame sent for a fragmented frame. Otherwise, the sequence number is incremented by one until reaching 4095, when it resets to zero.
The sequence control field 410 may also include a 4 bit fragment number. The fragment number sequentially increments to indicate each fragment of a fragmented frame. The sequence control field 410 thereby permits the recipient to understand how any particular data payload fits into the overall data stream that is sent. There is a certain amount of overhead required to track, monitor, count, and maintain the correct sequence and fragment data in the sequence control field 410. In addition, each QoS traffic stream has its own dedicated sequence number generator for the MPDUs carrying data payload belonging to that QoS traffic stream. The sequence number generator for a particular QoS traffic stream is maintained independently from other sequence number generator(s) for their corresponding QoS traffic stream(s) running concurrently.
Note, however, that the frame body field 416 is absent in the QoS Null frame 404. In other words, the QoS Null frame 404 does not carry any data in a specifically defined separate payload field. Therefore, the sequence control field 412 in the QoS Null frame 404 need not be updated and does not reflect any ordering information for data payloads. Again, there is no data payload in the QoS Null frame 404 to track.
Furthermore, the current WiGig specification, as well as the 802.11/a/g/n/ac specifications, do not require the sequence control field 412 to meet any particular content or payload tracking requirements. In other words, the sequence control field in the QoS Null frame 404 can carry any value without violating the specifications. note that, even though the QoS Data frame 402 looks identical to the QoS Null frame 404 when the length of the QoS Data frame's frame body 41 is 0, the sequence number for the zero-length payload QoS data frame is still required under the specifications.
Note that the QoS Null frame 404 does not include a data payload field, need not maintain any tracking requirements over the sequence control field 412, and includes an RDG/MorePPDU data field. Accordingly, the RD responder may very quickly return a QoS Null frame 404 to the RD initiator, with MorePPDU=1, when the RD responder has data to return, but cannot have the data ready within the required SIFS time. The ability to quickly return the QoS Null frame greatly relaxes the hardware and software implementation difficulty. Part of the reason that the difficulty exists is that timely establishing a RD channel requires a response from the RD responder within the SIFS time.
Thus, one technique for establishing a reverse direction communication channel from a RD responder to a RD initiator includes receiving a reverse direction grant indicator at the RD responder, and transmitting from the RD responder to the RD initiator, in response to the reverse direction grant indicator, a continuation frame (e.g. a QoS Null frame) that includes a continuation indicator (e.g., a MorePPDU bit). The continuation indicator determines whether the reverse direction communication channel should persist. The continuation frame includes a control field (e.g., QoS Control 408) that includes the continuation indicator. The continuation frame need not have a data payload field. The RD responder may send the continuation frame when it does want to send data back to the RD initiator, but the data is not ready or available to send. Said another way, the RD responder establishes the reverse direction channel, even when it has no data presently available to send in the channel, or when data is presently available, but the RD responder decides to withhold the data for any reason (e.g., to buffer additional data not yet available before starting to send data back to the RD initiator).
The RD responder may transmit the continuation frame as an initial response to the reverse direction grant indicator. Alternatively, the RD responder may transmit an acknowledgement (ACK) or block ACK frame immediately followed by the continuation frame as the initial response to the reverse direction grant indicator. As noted above, there are no content constraints on the sequence control field 412 in the QoS Null frame 404. Accordingly, the RD responder may use that existing field (or other unused fields), although defined for sequence control purposes (or other purposes), for communicating data or commands from the RD responder to the RD initiator for a different purpose.
In the example above, the TV 104 may, for example, send environmental data (e.g., room brightness) back to the media player 102 in one or more 2-byte sequence control fields 412 in one or more QoS Null frames. Similarly, any type of endpoint may send any type of data or commands back in the reverse direction channel using the sequence control field. Another example is a car engine computer that communicates speed or acceleration data back to the car stereo for noise cancellation purposes or volume adjustment purposes. Yet another example is a portable video game player sending a light dimming command to a home environment controller. Additional examples include setting the sequence control field to indicate how much data is coming from the RD initiator to the RD responder, how much data is queued up at the RD responder, how much buffer is left at the RD responder, and channel conditions (e.g., signal to noise ratio).
Note that the RD responder may continue to send QoS Null frames as long as desired until the specified RD duration expires. Thus, the RD responder may transmit a series of continuation frames with the continuation indicator set, until the RD responder has its data ready to send back to the RD initiator, or until it chooses to start sending data back to the RD initiator. When ready, the RD responder may transmit its data back to the RD initiator using a QoS Data frame and the data payload field provided in the QoS Data frame.
Following on the example of
Once the reverse direction channel is established, the RD responder provides data to the RD initiator in a series of QoS Data frames 514, 516, and 518. The QoS Data fames follow in sequence within whatever spacing is required (e.g., within a SIFS/RIFS time 520, 522, 524). When the RD responder has no more data, it sets MorePPDU=0 in the QoS Data frame 518. There may be as many QoS Null or QoS Data frames as the reverse direction grant time allows. In this example, the RD initiator then transmits an ACK 526 of the response burst from RD responder along with a QoS Null frame 528 with RDG=1 in an AMPDU. The reverse direction channel from the RD responder to the RD initiator then terminates. However, the RD initiator immediately signals another opportunity for a reverse direction channel by building and sending the QoS Null frame 528, as described with reference to
Once the reverse direction channel is established, the RD responder provides, within the SIFS/RIFS time 606, its data to the RD initiator in an AMPDU 608 (e.g., with only data aggregation). The AMPDU includes the three QoS Data frames 610, 612, and 614. Each of the QoS Data frames 610, 612, 614 has MorePPDU=0 to indicate that no further data is coming from the RD responder.
The processor 704 executes the logic 710. The logic 710 may be an operating system, application program, firmware, or other logic. The logic 710 includes an RD protocol handler 712 (or other response logic for handling RDGs). The RD protocol handler 712 may implement the processing noted above with respect to the reverse direction grants, and described below with respect to
To that end, the transceiver 702 stores received frames 714 in the memory 706. The protocol handler 712 may check the received frames 714 for a reverse direction grant indicator (e.g., an RDG field set to 1). As noted above, the endpoint 700 may quickly respond to RDGs using a QoS Null frame 716 with MorePPDU=1, even if the data 718 for the RD initiator is not yet available. When the data 718 becomes available, the endpoint 700 communicates the data 718 to the RD initiator using one or more QoS Data frames, for example. At any time, the endpoint 700 may communicate data back to the RD initiator using data fields that were originally specified for another purpose. For example, the endpoint 700 may send data back to the RD initiator in the sequence control field of a QoS Null frame.
However, if the RDG bit is set, then the processor 704 determines whether the endpoint 700 has primary data (e.g., data that is formally tracked through the sequence control field 410 or other sequencing information) to send to the RD initiator. If there is no data to send, then the endpoint 700 may simply acknowledge receipt (803) of the frame containing the RDG, and return to receiving frames (802). When the endpoint 700 has data to send to the RD initiator, however, the processor 704 determines whether the endpoint 700 can respond with the data within the required response time (e.g., the SIFS time). When the endpoint 700 can meet the required response time, then the endpoint may send an ACK or block ACK (804) if the protocol requires one. The endpoint 700 then prepares, for example, QoS Data frames 402 (806) and inserts at least a portion of the data that is ready for the RD initiator into the QoS Data frames (808). The endpoint also sets a continuation bit (e.g., the MorePPDU bit) appropriately (810). For example, when the endpoint 700 has additional data to send, then the processor 704 may set MorePPDU=1; otherwise, the processor may set the MorePPDU bit=0. The transceiver 702 sends the QoS Data frames individually, or aggregated into larger units (e.g., AMPDUs) (812).
Because the required response time may be very short, the endpoint may not always be able to respond with its data in the required response time. In that case, the transceiver 702 may send an ACK (814), and may prepare a QoS Null frame 404 with MorePPDU=1 (816). Note also that even if the primary data for the RD initiator is not ready, the processor 704 may insert other data or commands into the QoS Null frame. This other data is “out of band” in the sense that it is not part of the primary data tracked with sequence information (e.g., with the sequence control field 410). In one implementation, the processor 704 inserts the other data or commands into the sequence control field 412 (818). The endpoint 700 thereby uses the sequence control field 412 for a different purpose other than that originally specified.
The QoS Null frame thus provides a command and data stream back to the RD initiator, even though it has no specific data payload field. Furthermore, the endpoint 700 may signal to the RD initiator that other data or commands are present in the sequence control field 412 (or other field) by using a specific bit pattern in the sequence control field 412 (or other field) agreed upon ahead of time by the RD initiator and the RD responder. The transceiver 702 then transmits the QoS Null frame (820). The endpoint 700 may continue to transmit QoS Null frames, for example until the primary data in the endpoint 700 is ready for the RD initiator.
The processor 704 determines when the primary data is ready in the endpoint 700. At that time, the processor 704 prepares, for example, one or more QoS Data frames 402 (822) and inserts at least a portion of the primary data into the QoS Data frames (824). The processor 704 also sets the continuation bit(s) (e.g., the MorePPDU bit(s)) appropriately (826). For example, when the endpoint 700 has additional data to send, then the processor 704 may set MorePPDU=1; otherwise, the processor may set the MorePPDU bit=0. The transceiver 702 sends the QoS Data frames individually, or aggregated into larger units (e.g., AMPDUs) (828). The endpoint may continue to send QoS Null or QoS Data frames until it has no further primary data to send, or until the RDG time is over.
The endpoint 700 may establish and hold open the reverse direction channel in other ways. For example, in other implementations, the endpoint 700 may communicate a control wrapper frame with an HT control field with MorePPDU set to 1. For example, if the endpoint does not adhere to the WiGig specification, but does adhere to the 802.11 n standard, then the endpoint 700 may hold the reverse channel open using the control wrapper frame instead of a QoS Null frame. In this scenario also, the endpoint 700 may continue to send control wrapper frames in which the MorePPDU bit is set to 1 until the endpoint 700 has data ready to send, or until the endpoint 700 decides to send the data that it has ready. In other words, the control wrapper frame may also act to keep the reverse direction channel open (even though it has no data to send), while the endpoint 700 prepares to send primary data back to the RD initiator.
The methods, devices, and logic described above may be implemented in many different ways in many different combinations of hardware, software or both hardware and software. For example, all or parts of the endpoint 700 may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of circuitry. All or part of the logic may be implemented as instructions for execution by a processor, controller, or other processing device and may be stored in a machine-readable or computer-readable medium such as flash memory, random access memory (RAM) or read only memory (ROM), flash memory, erasable programmable read only memory (EPROM) or other machine-readable medium such as a compact disc read only memory (CDROM), or magnetic or optical disk.
While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.
