1 / 6

Proposed Change to 802.11 Intra-Mesh Congestion Notification Frame

Proposed Change to 802.11 Intra-Mesh Congestion Notification Frame. Authors:. Date: 2010-12-08. Abstract.

ogillespie
Download Presentation

Proposed Change to 802.11 Intra-Mesh Congestion Notification Frame

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposed Change to 802.11 Intra-Mesh Congestion Notification Frame Authors: Date: 2010-12-08 Barbara Staehle, Uni Würzburg

  2. Abstract This presentation provides a motivation for a small, simple extension of the Congestion Notification element. This extension allows a more flexible use of the Congestion Notification element for different intra-mesh congestion control mechanisms. The presentation and the corresponding submission 11-10/1428r0 address CIDs 28, 85, 204, 205. Barbara Staehle, Uni Würzburg

  3. Congestion Situation A: Solvable The Congestion Notification element described in 7.3.2.99 supports a node selective congestion control. Which is helpful in the situation depicted below: C is not able to forward packets from mesh STA B fast enough over link (C,D) and consequently sends a Congestion Notification element to mesh STA B. This causes B to apply local rate control as specified in 11C.11 in order to avoid a waste of mesh resources. In turn, B can not forward the packets from A fast enough and will send a Congestion Notification element to mesh STA A. Despite the congestion detected at mesh STA B, E is however still allowed to send packets to mesh STA B, as there is no congestion for link (B,A). Barbara Staehle, Uni Würzburg

  4. Congestion Situation B: Currently Unsolvable The Congestion Notification element described in 7.3.2.99 does, however, NOT support a flow selective congestion control which would be necessary to avoid the waste of mesh resources in the situation depicted below. Due to the same reasons as before, B has to use the Congestion Notification element to cause A to apply local rate control as specified in 11C.11 in order to avoid a waste of mesh resources. However, B could still forward packets from mesh STA A to mesh STA E. But as the format indicated in the standard does not provide the possibility to indicate that A should apply rate control only to packets destined for D and not for packets with mesh destination E, the congestion control causes an unnecessary throughput reduction. Barbara Staehle, Uni Würzburg

  5. Proposed Solution • Extend the format of the Congestion Notification element with the mesh destination in order to indicating which path causes the congestion. • “The Destination Mesh STA Address field is represented as a 48-bit MAC address and is set to the address of the mesh destination for which the intra-mesh congestion control shall be applied. It is set to the broadcast address if the intra-mesh congestion control shall be applied to all destinations.” (i.e. broadcast address = current functionality) • multiple Congestion Notification elements in a single Congestion Control Notification frame • full proposed normative text in 11-10/1428r0 (only a few lines) Barbara Staehle, Uni Würzburg

  6. References • 11-10/1428r0 M. Bahr, B. Staehle, D. Staehle: „Destination Address in Congestion Notification“ • IEEE 802.11s Draft Standard D7.03 Barbara Staehle, Uni Würzburg

More Related