1. ‘Express’ Forwarding in a Multi-hop Wireless Network
Month Year
doc.: IEEE yy/xxxxr0
March 2007
‘Express’ Forwarding in a Multi-hop Wireless Network
Date:
Authors:
Name
Company
Address
Phone
Mathilde
Benveniste
Avaya Labs
233
Mt Airy Road
Basking Ridge, NJ
07920
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Mathilde Benveniste, Avaya Labs
John Doe, Some Company

2. March 2007
‘Express’ Forwarding in a Multi-hop Wireless Network Mathilde Benveniste Avaya Labs - Research
Mathilde Benveniste, Avaya Labs

3. QoS for VoIP/multi-media
March 2007
QoS for VoIP/multi-media
Latency – an issue for VoIP/multi-media
Meeting QoS requires short total end-to-end over the air delays
Ad hoc vs infrastructure mode
A wireless mesh may use any of the following modes
Ad hoc mode (not attached to a wired network)
Infrastructure mode (attached to a wired network)
In general, both traffic with source and destination in the mesh and traffic bound from/to a wired network may co-exist on a mesh
The latency/jitter limit for voice traffic traversing the wired network is lower than that for traffic staying on the mesh
A target of 10 ms for maximum latency/jitter was set for top priority AC in TGe
Mathilde Benveniste, Avaya Labs

4. Delay considerations for mesh
March 2007
Delay considerations for mesh
Multiple-hop delay
The mesh backbone network is a multi-hop network
The per-hop latency target for e WLANs is inadequate for mesh
The multi-hop path delay will be a multiple of the single hop delay
Max number of hops is what matters
The max number of hops drives the delay, much like delay jitter determines the delay experienced by end-user
Multi-hop delay must approach single-hop delay
The goal is to reduce the delay experienced on the longest multi-hop path by forwarding QoS frames fast
Mathilde Benveniste, Avaya Labs

5. Ways to reduce delay in a wireless mesh
March 2007
Ways to reduce delay in a wireless mesh
Capacity provisioning
The nodes and links of the mesh network must have sufficient capacity to prevent traffic buffer from building up anywhere in the network
Proper provisioning involves the use of multiple radios at nodes of high traffic concentration to match traffic profiles
Congestion control
Reducing transmit rate and rerouting traffic can alleviate congestion, given the provisioning
Even with proper provisioning, the stochastic nature of traffic will cause short term fluctuations which may cause congestion at certain nodes
Fast forwarding of QoS traffic
MAC layer prioritized transmission of forwarded QoS traffic across the mesh helps reduce end-to-end delay along a multi-hop path, given congestion control and capacity provisioning
Mathilde Benveniste, Avaya Labs

6. March 2007
The role of EDCA
For fast forwarding, QoS traffic would require top priority access when forwarded on a multi-hop path
Lower priority access would be used for all other traffic
EDCA offers access prioritization on a single channel
Further prioritization is not possible with EDCA, however
Top-priority 11e traffic (VO/VI) already uses the top-priority access category
A different mechanism is needed for forwarded QoS traffic
‘Express’ forwarding is therefore proposed
It is compatible with EDCA
It is an optional feature
Mathilde Benveniste, Avaya Labs

7. ‘Express’ forwarding March 2007
In order to reduce delay along a multi-hop path
Forwarding nodes incur less delay than single-hop transmissions
For a single-channel mesh
Forwarding delay is reduced by reserving the channel for a forwarded transmission longer, in order to enable the next forwarding node to seize the channel
Immediate access is thus given to nodes, other than the first node on a multi-hop path, forwarding QoS traffic
Note: There exist ways for express forwarding also on a multi-channel mesh (not covered here)
Mathilde Benveniste, Avaya Labs

8. Designating frames for ‘express’ forwarding
March 2007
Designating frames for ‘express’ forwarding
A frame to be express forwarded is designated as a ‘time-sensitive QoS’ (TSQ) transmission
A special flag may be necessary to mark a transmission as ‘express’ forwarded, depending on the criteria for a TSQ transmission and/or the information available along its path
Examples
The TSQ designation may be supplied by the application
For instance, a TSQ frame could be a frame of a specified user priority (e.g. VO)
Alternatively, the TSQ designation may also be supplied by the originating node
For instance, If there is differentiation between ad hoc and infrastructure traffic, all voice frames starting or destined to the portal would be designated TSQ by the originating node
The TSQ designation can be used for other criteria
Mathilde Benveniste, Avaya Labs

9. Single channel ‘express’ forwarding
March 2007
Single channel ‘express’ forwarding
Mathilde Benveniste, Avaya Labs

10. Express Forwarding procedure
March 2007
Express Forwarding procedure
A known time increment DTI is added to the value of the Duration field when a TSQ frame is forwarded 1
The Duration field of the ACK (if any) returned for the TSQ frame received at the destination node is set based on the Duration field of the received frame
All nodes that hear the transmission other than the receiving node set their NAV according to the Duration field of the received transmission
If the receiving node forwards the frame, it subtracts DTI from the Duration value of a received frame before setting its NAV, and attempts transmission when its NAV expires
____________________________________________________
1 An alternative more efficient implementation will not add DTI to the Duration value of the frame transmitted on the last hop (i.e. to the final destination MP)
Mathilde Benveniste, Avaya Labs

11. Express Forwarding Illustration
March 2007
Express Forwarding Illustration
DTI
NAV setting at receiving node
NAV setting at all other neighbor nodes
Value in Duration field
Channel
1-2
2-3
3-4
time
Frame
ACK 5
3-hop path 1-4 1 2 3 4
The Duration field is set at value longer than usual when a frame is transmitted to a forwarding node of a multi-hop path
The forwarding nodes, 2 and 3, adjust the Duration value on the received frame by subtracting the increment when setting their NAV
The non-forwarding neighbor nodes – e.g. 5 – sets NAV by Duration field
Mathilde Benveniste, Avaya Labs

12. Express Forwarding -- Channel Access
March 2007
Express Forwarding -- Channel Access
Contention is reduced when forwarding a TSQ frame for all forwarding nodes other than the first node on path
Neighbor nodes have their NAV still set to at least DTI when the new forwarding node is ready to transmit (barring any independent NAV-setting request); thus they will not contend for the channel, letting that node transmit before any of them
A forwarding node performs CCA before attempting transmission
This avoids collision with another node that has not heard the received TSQ transmission to set the NAV accordingly
If the channel is busy, the forwarding node backs off from a short contention window CWmin(EF)
Mathilde Benveniste, Avaya Labs

13. March 2007
… with TXOPs
TXOPs allow multiple frames to be transmitted with a single contention
TXOPs can be used together with express forwarding
The combination reduces contention and collisions along the forwarding path!
The Duration field value on each frame of a TXOP to be forwarded is increased by DTI and the frames are flagged as TSQ
The Duration field on the ACK (if any) for each of the TXOP frames received at the destination node is set based on received frame
The NAV at the node to which the TXOP is forwarded is set by subtracting DTI from the Duration value of a received frame if the frame is to be forwarded
Forwarding of the received TXOP starts when the NAV expires, which occurs once the entire TXOP has been received and acknowledged
Mathilde Benveniste, Avaya Labs

14. March 2007
… with RTS/CTS
RTS/CTS is the mechanism for reducing the impact of hidden terminals, which are common in a wireless mesh
RTS/CTS protection may be used in conjunction with express forwarding
The combination reduces contention and collisions on the forwarding path
The RTS of time-sensitive QoS frame is flagged TSQ and the Duration field on the RTS is increased by the increment DTI
The node to which the RTS is addressed responds with a CTS with Duration value set based on the Duration field of the received RTS.
If the node receiving the RTS must forward the RTS-protected frame(s), it sets its own NAV by subtracting DTI from the Duration value of the RTS and of all frames received subsequently as part of the same RTS-protected frame(s)
Forwarding of the received frame or TXOP starts when the NAV expires, which occurs when the frame or TXOP has been received and acknowledged
Mathilde Benveniste, Avaya Labs

15. Month Year
doc.: IEEE yy/xxxxr0
March 2007
Conclusion
‘Express’ forwarding can reduce channel access delay along a multi-hop mesh path
Reserving the channel on each hop long enough to enable the next node on the path to seize the channel reduces forwarding delay
In conjunction with EDCA, it can reduce delay jitter, enabling QoS requirements to be met
It is compatible with stations/APs observing any of the existing MAC protocols
The feature is optional
Mathilde Benveniste, Avaya Labs
John Doe, Some Company

16. Backup March 2007 Month Year doc.: IEEE 802.11-yy/xxxxr0
Mathilde Benveniste, Avaya Labs
John Doe, Some Company

17. Express Forwarding with TXOPs
March 2007
Express Forwarding with TXOPs
The Acks to transmissions on the previous hop help notify nodes ahead of the transmission on the next hop
The length of the notice will depend on the mode of reservation (frame by frame vs entire TXOP)
Reservation frame by frame
DTI
DTI
NAV setting at neighbors of the
receiving node caused by ACK
Channel 1 2 3
time
Frame
ACK
3 frame TXOP
Mathilde Benveniste, Avaya Labs

18. March 2007
… with TXOPs – 2
Reserving for entire TXOP increases length advance notice delivered along the path
Reservation for entire TXOP
DTI
NAV setting at neighbors of the
receiving node caused by ACK
Channel 1 2 3
time
Frame
ACK
3 frame TXOP
Mathilde Benveniste, Avaya Labs

19. March 2007
… with RTS/CTS
The CTS/Acks to transmissions on the previous hop help notify nodes ahead of the transmission on the next hop
The length of the notice will depend on the mode of reservation (frame by frame vs entire TXOP)
DTI
DTI
DTI
Reservation frame by frame
NAV setting at neighbors
of the receiving node
caused by ACKs and CTS
Channel 1 2 3
time
RTS/CTS
Frame
ACK
3 frame TXOP
Mathilde Benveniste, Avaya Labs

20. March 2007
… with RTS/CTS – 2
Reserving with RTS/CTS for entire TXOP further increases length of advance notice delivered along the path
DTI
Reservation for entire TXOP
NAV setting at neighbors
of the receiving node
by ACKs and CTS
Channel 1 2 3
time
RTS/CTS
Frame
ACK
3 frame TXOP
Mathilde Benveniste, Avaya Labs