1. Some thoughts on broadcast frame delivery in mesh
January 2006
doc.: IEEE /340r0
October 2006
Some thoughts on broadcast frame delivery in mesh
Date:
Authors:
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
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

2. January 2006
doc.: IEEE /340r0
October 2006
Abstract
Slides for discussion of the ambiguity in the current spec and potential issues which may occur in the mesh environment, specifically focusing on broadcast/multicast frame delivery.
Distinction between “1-hop broadcast” and “multi-hop broadcast”
Reliability risk of broadcast frames
How to deliver “multi-hop broadcast”
Power management and broadcast frame delivery restrictions
Sync MP power management and broadcast frame delivery
Motivation of these slides is to check how these issues are treated in the current draft spec.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

3. “1-hop broadcast” and “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
“1-hop broadcast” and “multi-hop broadcast”
Traditionally, the “broadcast” in network is 1-hop broadcasting or relayed delivery by the AP.
The broadcast frame delivery in a BSS is defined as following.
STA transmit BC/MC frame to AP.
AP transmit (relay) BC/MC based on DCF or PCF.
Simply transmit BC/MC frame based on DCF
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

4. “1-hop broadcast” and “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
“1-hop broadcast” and “multi-hop broadcast”
In case of infrastructure BSS without CFP
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

5. “1-hop broadcast” and “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
“1-hop broadcast” and “multi-hop broadcast”
In case of infrastructure BSS with CFP
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

6. “1-hop broadcast” and “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
“1-hop broadcast” and “multi-hop broadcast”
In case of IBSS
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

7. “1-hop broadcast” and “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
“1-hop broadcast” and “multi-hop broadcast”
In case of mesh operation, broadcast is assumed to be “multi-hop broadcast” at many circumstances.
Physical connectivity is hidden to higher layer or outside of the mesh, as described in subclause )
Broadcast forwarding is defined in subclause 11A
However, some of the “broadcast” seem to be referred to as 1-hop broadcasting.
Beacon frame
1-hop
Probe frame
MDA frame
Neighborhood congestion announcement frame
Route request
WDS
RA-OLSR frame
Portal announcement
Connectivity report frame
Data frames
ESS
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

8. “1-hop broadcast” and “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
“1-hop broadcast” and “multi-hop broadcast”
Further, MAPs also forward broadcast frame to STA in the BSS according to subclause 11A
Some of the Mesh management frames do not have to be forwarded to STA in a BSS.
It seems that the current draft spec mix up following 3 broadcasting behaviors by a single word “broadcast”.
1-hop broadcasting
Mesh intra multi-hop broadcasting
Seamless multi-hop broadcasting throughout the ESS.
 Clear distinction is preferable.
Discussion: In TGs adhoc meeting in July, some of the TGs members discussed on this issue, and conducted the following potential resolution.
Add some filtering function at the MP, or
Define new pre-assigned MAC addresses for “mesh broadcast/multicast”.
What else ?
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

9. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
According to P REVma/D8.0 :
“The fundamental access method of the IEEE MAC is a DCF known as carrier sense multiple access with collision avoidance (CSMA/CA)” [in subclause 9.1.1], which has a risk for collision and depends on ARQ mechanisms for recovery.
“There is no MAC-level recovery on broadcast or multicast frames, except for those frames sent with the ToDS bit set” [in subclause 9.2.7], where the exception implies the message is directed to AP only. This assumption is not valid for broadcasting in mesh environment.
“As a result, the reliability of this traffic is reduced, relative to the reliability of directed traffic, due to the increased probability of lost frames from interference, collisions, or time-varying channel properties”.
It is concluded that the reliability of broadcast traffic is low, (especially in the absence of a PCF).
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

10. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
Broadcast traffic without any treatment (just based on DCF) is under the risk of collisions, interference, or time-varying channel properties.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

11. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
In case of general DCF transmission
Error in Physical layer
frame TX
Error by Collision
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

12. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
Option 1: MPs (re-)transmit broadcast frames immediately based on DCF.
frame TX
frame TX
frame TX
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

13. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
Option 1: MPs (re-)transmit broadcast frames immediately based on DCF.
Pros:
The frame will be delivered with a minimal delay.
Cons:
It’s under the risk of lower reliability due to interference, collisions, or time-varying channel properties.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

14. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
Option 2: MPs transmit broadcast frames with some sort of scheduling.
frame TX
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

15. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
Option 2: MPs transmit broadcast frames with some sort of scheduling.
Pros:
The collision probability will be reduced among neighbors.
Cons:
Introduce some latency for broadcast frame delivery.
It’s under the risk of lower reliability due to interference, collisions from hidden node, or time-varying channel properties.  In order to serve a similar reliability as PCF operation in a BSS, we need to add scheduled reception announcement/protection mechanism.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

16. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
Option 3: MPs break the broadcast frames to multiple unicast frames.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

17. Reliability risk of broadcast frames
January 2006
doc.: IEEE /340r0
October 2006
Reliability risk of broadcast frames
Option 3: MPs break the broadcast frames to multiple unicast frames.
Pros:
Achieve reasonable frame delivery delay to neighbors.
Reliability of the broadcast frames will become as same as unicast frames.
Cons:
Significant overhead in case of dense MP deployment.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

18. How to deliver “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
How to deliver “multi-hop broadcast”
According to P802.11s-D0.01 :
Broadcast Data Packets “Any layer-2 broadcast mechanism can be used to deliver broadcast packets, so long as the packets are delivered to all Mesh nodes. As an example, broadcast data packets can be delivered to all nodes in the Mesh by flooding.” [in subclause 11A ]
RREQ frames “This frame is typically transmitted in a broadcast manner. The intermediate MP rebroadcasts this frame.” [in subclause ]
The broadcasting mechanism within the mesh is not defined specifically.
RREQ frame loss (especially due to collision) will cause significant route setup delay, or serious failure in route discovery.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

19. How to deliver “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
How to deliver “multi-hop broadcast”
RREQ frames will be re-broadcasted, upon the reception.
RREQ
RREQ
Potential collision
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
RREQ
Potential collision
RREQ
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

20. How to deliver “multi-hop broadcast”
January 2006
doc.: IEEE /340r0
October 2006
How to deliver “multi-hop broadcast”
Traffic frames may be transmitted at the same time, and RREQ frames has no recovery mechanism against the collision.
Management frames/action frames has a higher user priority (NC) which will be mapped to the AC_VO (in case of EDCA), leading to the prioritized media access and the higher probability of collisions.
Discussion: Is it OK to leave the “multi-hop broadcast” scheme as implementation dependent feature?
Flooding is given as one of the example scheme for multi-hop broadcasting.
Simple flooding seems to generate significant overhead for the “multi-hop frame delivery”, if the mesh is operated in a dense deployment.  Significant overhead will cause larger probability of collisions.
CID167 suggests to investigate on the alternate protocol to mitigate this issue.  DBA, OLSR's MPR set as broadcast/multicast forwarders.
Should we work on this ?
Plus, broadcast frame delivery has a risk of reliability...
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

21. Power management and broadcast frame delivery restrictions
January 2006
doc.: IEEE /340r0
October 2006
Power management and broadcast frame delivery restrictions
According to P802.11s-D0.04 :
“A mesh point considers the mesh to operate in a power save mode if any one of its neighbors is operating in the power save mode.” “1) All broadcast and multicast traffic will be buffered by mesh points that perceive the mesh to operate in power save mode. These packets will be transmitted only on DTIM intervals.” [in subclause 11A.8.6], which introduces broadcast frame delivery restriction throughout the mesh.
“Beacon Period: 100TU” “DTIM period : 10” [in subclause 11A.8.8 (informative)] DTIM interval is 1,000[msec]
Basically, “per hop” frame delivery latency is restricted by this rule.
Might be OK for 1 hop frame delivery, where mesh is not the case of this assumption.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

22. Power management and broadcast frame delivery restrictions
January 2006
doc.: IEEE /340r0
October 2006
Power management and broadcast frame delivery restrictions
significant frame delivery latency between source MP and destination MP.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

23. Power management and broadcast frame delivery restrictions
January 2006
doc.: IEEE /340r0
October 2006
Power management and broadcast frame delivery restrictions
Discussion: Shall we leave this restriction as it is defined?
Some of the management frames may have an assumption that broadcast frame delivery does not take so long time.
Some of the management frames may not need to be delivered to the MPs in power save mode.
We should leave more flexibility to the spec regarding multi-hop broadcast frame delivery, since mesh has a broad use cases and deployment scenario which has different requirements.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

24. Sync MP power management and broadcast frame delivery
January 2006
doc.: IEEE /340r0
October 2006
Sync MP power management and broadcast frame delivery
According to P802.11s-D0.04 :
“all synchronizing MPs need to share a common Mesh DTIM interval.” [in subclause 11A.7.3.2], which means DTIM beacon timing will be aligned among the sync MPs.
“1) All broadcast and multicast traffic will be buffered by mesh points that perceive the mesh to operate in power save mode. These packets will be transmitted only on DTIM intervals.” [in subclause 11A.8.6], which implies buffered broadcast frames are transmitted by all the sync MPs after DTIM beacon transmission.  significant collision of broadcast frames throughout the mesh.
Root of this problem is considered to be :
All the MPs attempt to transmit the buffered broadcast frames at the same time.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

25. Sync MP power management and broadcast frame delivery
January 2006
doc.: IEEE /340r0
October 2006
Sync MP power management and broadcast frame delivery
If the DTIM timing is shared among MPs, and they buffer BC frames...
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

26. January 2006
doc.: IEEE /340r0
October 2006
Summary
Some of the potential issues related to broadcast frame delivery are presented.
Distinction between “1-hop broadcast” and “multi-hop broadcast”
Recall the different type of broadcasting, and check the current status.
Reliability risk of broadcast frames
Recall the reliability risk of broadcast frames, and present the Pros/Cons of 3 type of potential broadcasting schemes.
How to deliver “multi-hop broadcast”
Recall the relationship between multi-hop broadcast and the reliability, again.
Power management and broadcast frame delivery restrictions
Recall the frame delivery latency at the multi-hop environment.
Sync MP power management and broadcast frame delivery
Point the potential collision issue.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

27. References [1] P802.11-REVma/D5.2 [2] P802.11s-D0.04
January 2006
doc.: IEEE /340r0
October 2006
References
[1] P REVma/D5.2
[2] P802.11s-D0.04
[3] doc11-06/0602r16 “comments from may1”
[4] doc11-06/0581r0 “some thoughts on potential issues in mesh operation”.
[5] “The Broadcast Storm Problem in a Mobile Ad Hoc Network”, Wireless Networks 8, 153–167, 2002 Kluwer Academic Publishers.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola

28. January 2006
doc.: IEEE /340r0
October 2006
End of slides
Comments/Questions/Suggestions/Corrections are purely welcomed.
Kazuyuki Sakoda
Donald Eastlake 3rd, Motorola