‘Express’ Forwarding in a Multi-hop Wireless Network

Slides:



Advertisements
Similar presentations
Doc.: IEEE /2910r0 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 1 Simplified ‘Express’ Forwarding for single-channel wireless.
Advertisements

Doc.: IEEE /2180r0 SubmissionM. Benveniste (Avaya Labs) Some Simulation Results for ‘Express Forwarding’ Notice: This document has been prepared.
Doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Scheduled service periods in wireless mesh Notice: This document has been prepared.
Doc.: IEEE /0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Scheduled service periods in wireless mesh Notice: This document has been prepared.
LB84 General AdHoc Group Sept. Closing TGn Motions
[ Interim Meetings 2006] Date: Authors: July 2005
TCP Parameters and Settings
IEEE WG Status Report – July 2005
‘Express’ Forwarding in a Multi-hop Wireless Network
LB73 Noise and Location Categories
LB73 Noise and Location Categories
Waveform Generator Source Code
Splicing in a Mesh Network
Power Save Mechanism for Unsync MPs
TGp Closing Report Date: Authors: July 2007 Month Year
Attendance and Documentation for the March 2007 Plenary
Motion to accept Draft p 2.0
TGs January Final Report
3GPP liaison report July 2006
[place presentation subject title text here]
Avoiding Adjacent Channel Interference with Multi-Radio Mesh Points
Extension Coexistence with OBSS
Mesh Networks Alliance (MNA)
Coexistence problem of s Congestion Control
Splicing in a Mesh Network
TGp Closing Report Date: Authors: March 2006 Month Year
On Coexistence Mechanisms
TGp Closing Report Date: Authors: May 2007 Month Year
Quick Beacon Impacts on LB 92
JTC1 Ad Hoc Mid-week Report
On Coexistence Mechanisms
TGp Closing Report Date: Authors: March 2006 Month Year
Reflector Tutorial Date: Authors: July 2006 Month Year
CID#102 - Channel Allocation for P2P
TGv Redline D0.07 Insert and Deletion
Coexistence problem of s Congestion Control
MAC Extensions for Increasing Aggregate WLAN Throughput
TGv Redline D0.06 Insert and Deletion
Experimental DTV Sensor
ADS Study Group Mid-week Report
Proposal for Resolving Comments on Intra-Mesh Congestion Control
IEEE P Wireless RANs Date:
More on Performance Evaluation of ‘Express Forwarding’ for Mesh
Protection Assurance Method
TGu-changes-from-d0-01-to-d0-02
LB73 Noise and Location Categories
May 2006 doc.: IEEE /0601r0 May 2006 Handling the Groupcast Sequence Number for Proxied Device in Multihop Mesh Date: Authors: Notice:
TGy draft 2.0 with changebars from draft 1.0
TGs January Final Report
TGv Redline D0.10 Insert and Deletion
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
November 2007 Effect of Contention Window Size on ‘Express Forwarding’ Performance for Single-Channel Mesh Date: Authors: Name Address Company.
Simulation Results for Adaptive Rate Control
Off-channel selection
Beamforming and Link Adaptation Motions
Adaptive Rate Control NAV Setting
Mesh Distributed Coordination Function
Questions to the Contention-based Protocol (CBP) Study Group
QoS Metrics Date: Authors: January 2005 Month Year
Proposed Changes for LB81 Comments
‘Express’ Forwarding for single-channel wireless mesh
Some Simulation Results for ‘Express Forwarding’
Motion to go to Letter Ballot
for video transmission, Status
Simulation Results for Adaptive Rate Control
Mesh QoS Control Date: Authors: January 2008
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Multiple NAV Protection - Revisited
WNG SC Closing Report Date: Authors: July 2006 July 2006
‘Express’ Forwarding in a Multi-hop Wireless Network
Presentation transcript:

‘Express’ Forwarding in a Multi-hop Wireless Network Month Year doc.: IEEE 802.11-yy/xxxxr0 May 2007 ‘Express’ Forwarding in a Multi-hop Wireless Network Date: 2007-05-01 Authors: Name Company Address Phone email Mathilde Benveniste Avaya Labs 233 Mt Airy Road Basking Ridge, NJ 07920 908 696 5296 benveniste@ieee.org Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 <stuart.kerry@philips.com> 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Mathilde Benveniste, Avaya Labs John Doe, Some Company

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

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 802.11 TGe Mathilde Benveniste, Avaya Labs

Delay considerations for mesh May 2007 Delay considerations for mesh Multiple-hop delay The mesh backbone network is a multi-hop network The per-hop latency target for 802.11e 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

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 Mathilde Benveniste, Avaya Labs

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 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

‘Express’ forwarding May 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

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 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

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

Express Forwarding procedure May 2007 Express Forwarding procedure A known time increment DT0 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 DTI is at least one time slot long DTI is shorter than DT0 by at least a time slot DT0 - DTI should be sufficiently long to enable a forwarding node to prepare frame for the next hop ____________________________________________________ 1 An alternative more efficient implementation will not add DT0 to the Duration value of the frame transmitted on the last hop (i.e. to the final destination MP) Mathilde Benveniste, Avaya Labs

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 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

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 backs off from a short contention window CWmin(EF) Mathilde Benveniste, Avaya Labs

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

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

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

May 2007 Time-critical frames Express forwarding gives priority access to frames marked TSQ over all other traffic Time-critical (TC) frames Certain management frames, often sent on a single hop, may require transmission before the forwarded traffic As it stands, express forwarded traffic would delay the transmission of frames that are not forwarded on a multi-hop path Express forwarding can accommodate prioritized channel access for time-critical frames through its ‘bypass’ feature Mathilde Benveniste, Avaya Labs

Express Forwarding Bypass May 2007 Express Forwarding Bypass Nodes with time-critical (TC) frames may gain access to the channel sooner than forwarded frames as follows: If a node with a TC frame hears a TSQ frame transmitted, it subtracts DT0 from the Duration value of a received TSQ frame before setting its NAV, and attempts transmission when its NAV expires Before transmitting, such a node performs CCA If the channel is busy, the forwarding node backs off from a short contention window CWmin(EF) In the event of a collision, a random backoff will be drawn and transmission will be attempted when the backoff expires Since DT0 exceeds DTI by at least one time-slot, a TC frame will be transmitted before a forwarded frame The node with the forwarded frame will sense the channel busy when the TC frame is transmitted and will back off using a random delay from a short contention window Mathilde Benveniste, Avaya Labs

Month Year doc.: IEEE 802.11-yy/xxxxr0 May 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, ‘express forwarding’ can reduce delay jitter, enabling QoS requirements to be met Time-critical frames can get through It is compatible with stations/APs observing any of the existing 802.11 MAC protocols The feature is optional Mathilde Benveniste, Avaya Labs John Doe, Some Company