Doc.: IEEE 802.11-07/2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 1 ‘Express’ Forwarding for single-channel wireless mesh Notice:

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0916r0 Submission September 2005 Slide 1 Adjacent channel interference and its impact on the Mesh MAC Date: Authors: Notice:
Advertisements

Doc.: IEEE /90r0 Submission Nov., 2012 NICTSlide b NICT Proposal IEEE P Wireless RANs Date: Authors: Notice: This document.
Doc.: IEEE /2910r0 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 1 Simplified ‘Express’ Forwarding for single-channel wireless.
Doc.: IEEE /2180r0 SubmissionM. Benveniste (Avaya Labs) Some Simulation Results for ‘Express Forwarding’ Notice: This document has been prepared.
doc.: IEEE /1059r0 Submission July 2006 Mathilde Benveniste, Avaya LabsSlide 1 Next generation MAC Notice: This document has been prepared to.
Doc.: IEEE /0644r2 Submission May 2006 Päivi Ruuska, NokiaSlide 1 Measurement Pilot Transmission Information as optional information in Probe.
Doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Scheduled service periods in wireless mesh Notice: This document has been prepared.
Doc.: IEEE /0015r0 Submission Month YearJanuary 2005 Bryan Wells, DENSO, LA LabsSlide 1 Proposed MAC Enhancements Report Notice: This document.
Doc.: IEEE /0072r0 Submission January 2009 Slide 1 Proxy ARP Issue for Direct Link Setup Notice: This document has been prepared to assist IEEE.
Doc.: IEEE /0569r0 Submission April 2006 Tomoko Adachi, Toshiba CorporationSlide 1 Performance evaluation of 40MHz transmission - regarding CCA.
Doc.: IEEE /0039r1 Submission January 2007 Larry Green, Ixia Slide 1 TCP Parameters and Settings Notice: This document has been prepared to assist.
Doc.: IEEE /2814r0 Submission Slide 1 Performance implications of wireless mesh coexistence with WLANs 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.
Doc.: IEEE /0076r0 Submission Jan 2006 Tom Siep, Cambridge Silicon Radio PlcSlide 1 Coexistence TAG Liaison Report Notice: This document has been.
Performance implications of wireless mesh coexistence with WLANs
Can RTS/CTS remedy problems caused by single-channel wireless meshes?
‘Express’ Forwarding in a Multi-hop Wireless Network
Triggered QoS Measurements
September 2005 Performance Evaluation of the CCC MMAC Protocol for s Mesh Networks Date: Authors: Notice: This document has been prepared.
[ Interim Meetings 2006] Date: Authors: July 2005
Fair and protected DLS July 2007 Date: LG Electronics
TCP Parameters and Settings
Long SlotTime Option for RTS/CTS Procedure
‘Express’ Forwarding in a Multi-hop Wireless Network
Fair and Protected DLS September 2007 Date:
LB73 Noise and Location Categories
Waveform Generator Source Code
Splicing in a Mesh Network
[ Considering of Intra-cell multiple CBP response]
Congestion Control Date: Authors: March 2007 Month Year
Fair and Protected DLS September 2007 Date:
QoS Statistics Date: Authors: January 2005 January 2005
Coexistence issues for single-channel wireless mesh
Proposed resolution text for CCF related CIDs
Avoiding Adjacent Channel Interference with Multi-Radio Mesh Points
Extension Coexistence with OBSS
Coexistence problem of s Congestion Control
Splicing in a Mesh Network
On Coexistence Mechanisms
[Comparison between CDMA Code and Contention-based Access]
On Coexistence Mechanisms
Reflector Tutorial Date: Authors: July 2006 Month Year
Coexistence problem of s Congestion Control
Proposal for Resolving Comments on Intra-Mesh Congestion Control
Selection Procedure Recommendation
IEEE P Wireless RANs Date:
More on Performance Evaluation of ‘Express Forwarding’ for Mesh
Performance comparison of RTS/CTS and ‘Express Forwarding’ for mesh
TGu-changes-from-d0-01-to-d0-02
May 2006 doc.: IEEE /0601r0 May 2006 Handling the Groupcast Sequence Number for Proxied Device in Multihop Mesh Date: Authors: Notice:
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.
Off-channel selection
Long SlotTime Option for RTS/CTS Procedure
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
Acknowledgment for CBP transmission
Some Simulation Results for ‘Express Forwarding’
for video transmission, Status
NAV Clearing: Problems and Proposed Remedy
Triggered QoS Measurements
Mesh QoS Control Date: Authors: January 2008
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
September 2006 doc.: IEEE /1351r0 September 2006
Proposal for Diagnostic Alerts
Multiple NAV Protection - Revisited
‘Express’ Forwarding in a Multi-hop Wireless Network
Selection Procedure Recommendation
Presentation transcript:

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 1 ‘Express’ Forwarding for single-channel wireless mesh 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, 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. Date: Authors: NameAddressCompanyPhone Mathilde Benveniste 233 Mt Airy Road Basking Ridge, NJ 07920, US Avaya Labs- Research e.org

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 2 ‘Express’ Forwarding for Single-Channel Wireless Mesh ‘Express’ Forwarding for Single-Channel Wireless Mesh Mathilde Benveniste Avaya Labs - Research

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 3 Introduction VoIP cannot meet QoS requirements on a single- channel wireless mesh unless there is a way to reduce delay/jitter End-to-end delay and jitter can be too high because of multi-hop transmissions –Single-hop latencies compound at the least –Collisions due to “hidden nodes” increase latencies severely when CSMA/CA is used

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 4 Excessive latency in single-channel meshes An Ack may cause a hidden terminal collision 4 node mesh on a single channel A and C cannot hear each other B cannot receive when C transmits to D A BCD ACK Tx (((((((( X Hidden node Tx

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 5 Excessive latency in single-channel meshes – 2 Hidden terminal collisions between two transmissions are likely to repeat Single channel mesh A and D cannot hear each other C cannot receive when A transmits B cannot receive when D transmits Retransmission attempts likely to fail Increased delay for successful transmission A B Tx X C D (((((((( (((((((( X Interference

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 6 Delay Budget Recommended one-way total delay (ITU G.114) – 150 ms Delay introduced in IP network and end system – 110 ms –IP network delay – sum of transmission and queuing delays traveling thru IP network (~50 ms) –End-system delay – sum of the encoding (20 ms), decoding (small), jitter buffer (~40 ms), and other data handling delays The target for maximum latency in a wireless mesh should be 40 ms* * In TGe, a target of 10 ms was used for WLAN delay in top-priority ACs

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 7 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 (and channels) at nodes of high traffic concentration to match traffic profiles Congestion control Even with proper provisioning, the stochastic nature of traffic may produce short term fluctuations which may cause congestion at certain nodes Reducing load by rerouting traffic can alleviate congestion at a node, given the provisioning Fast forwarding of QoS traffic MAC layer prioritized transmission and retransmission of forwarded QoS traffic across the mesh helps reduce end-to- end delay along a multi-hop path, given congestion control and capacity provisioning

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 8 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

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 9 ‘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 )

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 10 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 after a specified number, HN, of hops or once a certain time-to-live remains Each frame contains a TTL field that can give the # traversed hops: HN = dot11MeshTTL – TTL

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 11 Single channel ‘express’ forwarding

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 12 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 time-critical frame protection is desired; o/w it is equal to DT0

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 13 Express Forwarding Illustration 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 increment DT0 >= 1 timeslot + IP processing delay – AckTime - SIFS The forwarding nodes, 2 and 3, adjust the Duration value on the received frame by subtracting the increment DTI when setting their NAV DT0 >= DTI >= 1 timeslot The non-forwarding neighbor nodes (e.g. 5) set NAV according to Duration field NAV setting at all other neighbor nodes NAV setting at receiving node Channel time ACK Value in Duration field of TSQ frame Frame DT0 3-hop path DTI ANIMATED

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 14 Express Forwarding procedure - 2 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

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 15 … with multiple fragments When multiple fragments of a frame are transmitted, the express forwarding node will start transmitting only at the end of the last fragment The Duration field value on each fragment of the frame to be forwarded is increased by DT0 and the fragments are flagged as TSQ The Duration field on the ACK (if any) for each of the fragments received at the destination node is set based on received fragment duration (i.e., a SIFS and ACK tx time are subtracted) The NAV at the node to which the fragments are 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 fragments starts when the NAV expires, which occurs once all the fragments have been received and acknowledged

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 16 … 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

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 17 … 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

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 18 Collisions, retransmissions, and ACK rate

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 19 P VIDEO (L) VIDEO (H) VIDEO (L) VOIP Collisions caused by multi-hop flows  If the ACK from 2 (or 3) causes collision at Node6, retransmission of frame from Node25 will wait till multi-hop TX P->Node5 completes  The sooner the latter completes, the sooner the transmission Node25->Node6 will complete  Express forwarding reduces time of transmission P->Node5, thus shortens delay for flow Node25- >Node6  With Express Forwarding, the ACK from 2 prevents collision by Node25 for the remainder of multi-hop transmission P->Node5 Multi-hop flow from P to Node5 ANIMATED

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 20 Hidden node collision ‘loop’ Collisions between a pair of hidden nodes may repeat –Retransmission attempts likely to fail –They increase delay and may cause frames to be dropped Large backoff values help break collision cycle Prioritizing one of the transmissions helps break collision cycle Single channel mesh A and D cannot hear each other C cannot receive when A transmits B cannot receive when D transmits A B Tx X C D (((((((( (((((((( X

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 21 Express Retransmission Retransmission typically involves backoff using a wider contention window With express retransmission, a frame is retransmitted by dispensing with backoff and transmitting after AIFS following AckTimeout, within DT0 time period An express forwarded frame is less likely to collide on retransmission because of its prioritization Only the first retransmission attempt receives priority treatment Prevents two express-forwarded frames from colliding repeatedly Subsequent retransmission attempts less likely to lead to collision when using large CWmax Channel time ACKtimeout TSQ Frame DT0 DTI TSQ Retransmission NAV setting at all other neighbor nodes NAV setting at receiving node Value in Duration field of TSQ frame

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 22 Express retransmission illustration Express retransmission (X-RTX) enables a multi-hop transmission to complete faster Express forwarding and X-RTX on single-channel mesh The transmissions from A->B and F->E lead to hidden terminal collisions Express retransmission enables the TSQ frame (A->B) to succeed upon retransmission The ACKs sent by B and C protect the frame as it is forwarded on A B E F (((((((( Tx Interference X X TSQ (((((((( Interference DC X-RTX TSQ ANIMATED

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 23 Benefit of lower ACK rate Reducing the ACK rate benefits express forwarding as ACK range increases Nodes further away hear the TSQ ACK and set their NAV accordingly –The express-forwarded frame will be on the air when the neighbors’ NAV expires; collision is averted Example: F can decode an ACK from B B will be able to forward the received TSQ frame without interference from F A B CD TSQ ) ) ACK F

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 24 Making room for time-critical transmissions

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 25 Prevent delay of time-critical frames 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

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 26 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 = DTI

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 27 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

doc.: IEEE /2452r1 Submission November 2007 Mathilde Benveniste, Avaya LabsSlide 28 Conclusion ‘Express’ forwarding can reduce channel access delay along multi- hop mesh paths –VoIP can thus use a wireless mesh this way Express Forwarding does not cause significant delays for other flows –Often it reduces the delay of other flows substantially 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 without delay –No time-sensitive frame builds excessive delay, whether forwarded or not Express Retransmission preserves priority in case of hidden terminal collisions and helps reduce overall collision rate Low ACK rates and large CWmax limits enhance express forwarding by reducing the collision rate It is compatible with stations/APs observing any of the existing MAC protocols The features are optional