1. ‘Express’ Forwarding in a Multi-hop Wireless Network
Month Year
doc.: IEEE yy/xxxxr0
May 2007
‘Express’ Forwarding in a Multi-hop Wireless Network
Date:
Authors:
Name
Address
Company
Phone
Mathilde Benveniste
233 Mt Airy Road
Basking Ridge, NJ 07920, US
Avaya Labs-Research
Susan Hares
825 Victors Way
Ann Arbor, MI 48108, US
NextHop
Kyeong Soo (Joseph) Kim
1060 East Brokaw Road, MS 212, San Jose, CA 95131, US
STMicroelectronics
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. May 2007
‘Express’ Forwarding in a Multi-hop Wireless Network Mathilde Benveniste Avaya Labs - Research
Mathilde Benveniste, Avaya Labs

3. May 2007
Introduction
Unless there is a way to reduce delay jitter, the proposed mesh standard will not enable VoIP delivered via wireless mesh to meet QoS requirements
End-to-end delay and jitter is too high because of multi-hop transmissions
Delay/jitter is what determines the delay experienced by all end-users receiving QoS traffic
To reduce the worst-case delay, we propose “express forwarding” of QoS frames that traverse paths with too many hops
Reducing the worst-case delay causes all users receiving mesh QoS traffic to experience lower delay
A shorter jitter buffer will be needed to deliver VoIP to the end-user
The end-user will experience a shorter delay for all VoIP traffic, even though the delay along shorter paths may increase
Mathilde Benveniste, Avaya Labs

4. QoS for VoIP/multi-media
May 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

5. Delay considerations for mesh
May 2007
Delay considerations for mesh
Multiple-hop delay
The mesh backbone network is a multi-hop network
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 be bounded
The goal is to reduce the delay experienced on the path with the longest delay by forwarding QoS frames fast
Mathilde Benveniste, Avaya Labs

6. Ways to reduce delay in a wireless mesh
May 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 may produce 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
The focus of this paper is ‘fast forwarding’
Mathilde Benveniste, Avaya Labs

7. May 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 (shortest AIFS)
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

8. May 2007
‘Express’ forwarding
In order to reduce delay of a multi-hop path, ‘express’ forwarding enables a forwarding node to incur a shorter per-hop delay than a single-hop transmission
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
‘Time-critical’ frames can be exempted; they may be transmitted even before express-forwarded traffic
Note: There exist ways for express forwarding also on a multi-channel mesh (not covered here)
Mathilde Benveniste, Avaya Labs

9. Designating frames for ‘express’ forwarding
May 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 will depend on the type of traffic
For instance, a TSQ frame could be a frame of a specified user priority (e.g. VO)
The designation may be supplied by a forwarding node
For instance, express forwarding is engaged only or once a certain time-to-live remains
Each frame contains a TTL field that can give the # traversed hops:
HN = dot11MeshTTL – TTL
Mathilde Benveniste, Avaya Labs

10. Single channel ‘express’ forwarding
May 2007
Single channel ‘express’ forwarding
Mathilde Benveniste, Avaya Labs

11. Express Forwarding procedure
May 2007
Express Forwarding procedure
A known time increment DT0 (MIB variable Dot11MeshDTC) is added to the value of the Duration field when a TSQ frame is forwarded to a node other than the final destination
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 (MIB variable Dot11MeshDEF) from the Duration value of a received frame before setting its NAV, and attempts transmission when its NAV expires
DT0 is at least one timeslot long; it would not be more than a couple of timeslots
DTI is shorter than DT0 by at least a time slot, if DT0 is nonzero
Mathilde Benveniste, Avaya Labs

12. Express Forwarding Illustration
May 2007
Express Forwarding Illustration
DT0
NAV setting at receiving node
DTI
NAV setting at all other neighbor nodes
Value in Duration field
Channel
1-2
Frame
ACK
2-3
3-4
time 5
3-hop path 1-4 1 2 3 4
The Duration field is set at value longer than usual when a TSQ 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

13. Express Forwarding -- Channel Access
May 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 DT0 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 defers transmission with a random back off
Mathilde Benveniste, Avaya Labs

14. May 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 DT0 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 (where DTI < DT0) 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

15. May 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 DT0
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 (where DTI < DT0) 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

16. Making room for time-critical transmissions
May 2007
Making room for time-critical transmissions
Mathilde Benveniste, Avaya Labs

17. Time-critical frames don’t get delayed
May 2007
Time-critical frames don’t get delayed
Time-critical (TC) frames = top-priority management frames, or top-priority frames with a delay in excess of a threshold (MIB variable Dot11MeshTCTrigger)
The MSDULifetime timer of EDCA can be used for TC frames
TC frames include frames sent on a single hop
Without TC provisions, express-forwarded traffic would delay the transmission of frames that are not forwarded on a multi-hop path
The ‘bypass’ feature eliminates for the time-critical frames access delay that could be caused by express forwarding
Mathilde Benveniste, Avaya Labs

18. Express Forwarding Bypass
May 2007
Express Forwarding Bypass
Nodes with time-critical (TC) frames are allowed to count down or transmit before a TSQ frame, according to EDCA rules
If a node with a TC frame hears a TSQ frame transmitted, it subtracts DT0 from the frame’s Duration value when setting its NAV
When the NAV expires the node counts down backoff or attempts transmission if backoff expires
Because DT0 exceeds DTI by at least one time-slot, the node with the forwarded frame will sense the channel busy when a TC frame with expired backoff is transmitted
The forwarding node will back off, using a random delay
EF Bypass for TC frames can be cancelled by setting DT0 = 0
Mathilde Benveniste, Avaya Labs

19. Postponing express forwarding
May 2007
Postponing express forwarding
‘Express forwarding’ may be postponed until a specified number of hops has been traversed
Postponing EF better balances the (express forwarded) traffic on long multi-hop paths with traffic on the shorter paths (which is not express forwarded)
A hop counter HN is carried on the frame; a forwarded frame is not marked TSQ, and its Duration value is not increased, until HN reaches a designated value EFNH (MIB variable dot11MeshEFNH)
TTL [# of remaining hops, TGs draft] is the hop counter set on frame initiation
HN= dot11MeshTTL – TTL
Hence, the TSQ flag is set when TTL  dot11MeshTTL – EFNH
Mathilde Benveniste, Avaya Labs

20. Month Year
doc.: IEEE yy/xxxxr0
May 2007
Conclusion
‘Express’ forwarding can reduce channel access delay along multi-hop mesh paths
VoIP can thus use a wireless mesh this way
One can specify the trigger hop count when express forwarding takes effect
Increasing the trigger hop count makes express forwarding less aggressive
Fairness to all frames; Time-Critical frames get through
No time-sensitive frame builds excessive delay, whether forwarded or not
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

21. Month Year
doc.: IEEE yy/xxxxr0
May 2007
Motion
Move to adopt the changes in Doc r2 into the TGs Draft D1.03
Mathilde Benveniste, Avaya Labs
John Doe, Some Company