doc.: ieee 802.11-05/0379r0 submission liwen chu et al. may 2005 slide 1 st+ucla tgs mesh network...
TRANSCRIPT
May 2005
Slide 1
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
ST+UCLA TGs Mesh Network ProposalDate: 2005-05-16
Authors:Name Company Address Phone email
L. Chu STMicroelectronics, Inc.
1060 East Brokaw Road, San Jose, CA 95131
+1 408 467-8436 [email protected]
M. Gerla UCLA 420 Westwood Plaza – BH3732F, Los Angeles, CA 90095
+1 310 825 4367 [email protected]
K.-S. Kim STMicroelectronics, Inc.
1060 East Brokaw Road, San Jose, CA 95131
+1 408 451-8137 [email protected]
Y.-Z. Lee UCLA 420 Westwood Plaza – BH3803A, Los Angeles, CA 90095
+1 310 206 3212 [email protected]
D. Maniezzo UCLA 420 Westwood Plaza – BH3803A, Los Angeles, CA 90095
+1 310 206 3212 [email protected]
J. S. Park UCLA 420 Westwood Plaza – BH3803A, Los Angeles, CA 90095
+1 310 206 3212 [email protected]
G. Vlantis STMicroelectronics, Inc.
1060 East Brokaw Road, San Jose, CA 95131
+1 408 451-8109 [email protected]
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 <[email protected]> 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 <[email protected]>.
May 2005
Slide 2
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Outline
• Routing Protocol• Congestion Control• Neighbor-list Low Collision MAC• Admission Control
May 2005
Slide 3
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Routing Protocol
• Routing architecture allows different protocols to adapt to different usage scenarios
• Unicast routing– Based on “OLSR+FSR” (Optimized Link-state Routing+Fish-eye State
Routing)– With “Different Granular Destinations”
• Multicast routing– Based on “Enhanced ODMRP” (On-demand Multicast Routing Protocol)
• Following features can be supported:– QOS routing– Multiple-channel
May 2005
Slide 4
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Unicast Routing ---- Previous Works: OLSR*
• Link state information is broadcast in the network.
• Each node establishes its routing table according to the link state it received.
• To decrease the control packet overhead, MPR (multiple point relay) is used. Because the green nodes can reach all the 2-hop yellow nodes, only the green nodes broadcast the selector’s (red) link state information. Gray nodes just receive.
1-hop neighbors
2-hops neighbors
MPR of central node
Central node
* OLSR: Optimized Link State Routing
May 2005
Slide 5
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Unicast Routing---- Previous Works: FSR*
Central Node
1-hop neighbor
2-hops or more neighbor
• Link state information is broadcast in the network by each node
• Each node establishes its routing table according to the link state it received
• Link state information updates for a near destination are propagated more frequently than updates for a remote destination
• Reduces link overhead
Scope 1
Scope 2
* FSR: Fisheye State Routing
May 2005
Slide 6
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Unicast Routing---- Our Proposal: OLSR+FSR
• Forwarding link state information is broadcast by MPR in the network
• Each node establishes its routing table according to the link state it received
• Link state information updates for a near destination are propagated more frequently than updates for a remote destination
1-hop neighbors
2-hops neighbors
MPR of central node
3-hops or more neighbors
Central node
Scope 2
Scope 1
May 2005
Slide 7
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Unicast Routing Protocol----OLSR+FSR
• Pros– Lower control overhead compared with FSR or OLSR
individually– Suitable for large network – Suitable for the mesh network with much distributed short lived
traffic– Adaptable to node mobility– Suitable for high dense network
• Cons– The temporary inconsistent link state database (routing tables) in
different nodes may last a longer time compared with OLSR
May 2005
Slide 8
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
QOS Routing—QOS OLSR+FSR
• To support QOS, Basic OLSR+FSR is not suitable• Each mesh point measures QOS metrics (for example delay,
remaining bandwidth) • QOS metrics are carried in the TC and hello messages• Optimal paths in terms of bandwidth and delay are acquired
according to QOS link state information– The path with minimum delay should be selected– Remaining bandwidth is used to prune links
May 2005
Slide 9
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Multiple-channel Support
• When the mesh point has multiple channels, 11s routing protocol should use them effectively
• Channel-aware routing metric is used• When the path is more channel-diverse, the path metric
is smaller
May 2005
Slide 10
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Mesh Layer Header
• A new shim header (OSI 2.5 layer header) is added between MAC layer and LLC layer
– Frame Type (1 Octet)
– TTL (1 Octet)
– Source STA MAC ADDR (6 Octets, optional field)
– Destination STA MAC ADDR (6 Octets, optional field)• Source/destination MAC address should be included in the
packets from LLC layer. 11s routing packets and other management frames do not includes these two fields
Type Source MAC Address Destination MAC AddressTTL802.11 MAC Header IP Header
May 2005
Slide 11
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Routing To Mesh Point• Only the Mesh Point is the routing destination• The mesh AP broadcasts its associated non-AP STAs to the border mesh points which
include mesh portals and mesh APs• A special map table which maps the non-AP STAs to the associated mesh AP is defined
in each border mesh point• When a non-AP STA roams, the former mesh AP forwards the packets to the current
associated mesh AP before the association information reaches the whole network • 6 MAC addresses are required to route the packet
ForwardMesh Point1
Mesh Portal1
Mesh AP1
Mesh AP2STA1
STA2
STA3 STA4 STA5
InternetMesh Network
BSS
BSS
Forward Mesh Point1’s routing table:Destination : Next HopMesh AP2 : Mesh AP2Mesh AP1 : Mesh AP1Mesh Portal1: Forward Mesh Point2
Mesh AP2’s routing table:Destination : Next HopMesh AP1 : Forward Mesh Point1Forward Mesh Point1: Forward Mesh Point1Mesh Portal1: Forward Mesh Point1
Mesh AP2’s Map table:Non-AP STA : Mesh APSTA1 : Mesh AP1STA2 : Mesh AP1STA3 : Mesh AP2STA4 : Mesh AP2STA5 : Mesh AP2
May 2005
Slide 12
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Routing To Mesh Point
Mesh AP1
MAC Address1 MAC Address2 MAC Address3 MAC Address4
RA TA Destination STA5 Source STA1
MAC ddress1 MAC ddress2 MAC Address3 MAC Address4 11s Address1 11s Address2
RA TA Destination Mesh AP2 Source Mesh AP1 Destination STA5 Source STA1
Mesh AP2 MAC Address1 MAC Address2 MAC Address3 MAC Address4
RA TA Destination STA5 Source STA1
MAC ddress1 MAC Address2 MAC Address3 MAC Address4 11s Address1 11s Address2
RA TA Destination Mesh AP2 Source Mesh AP1 Destination STA5 Source STA1
Source Mesh AP
Destination Mesh AP
• Pros– Smaller routing table for non-border MPs– Lower protocol processing overhead
• Cons– Two more address fields
ForwardMesh Point1
Mesh Portal1
Mesh AP1 Mesh
AP2STA1
STA2
STA3 STA4 STA5
Internet Mesh Network
BSS
BSS
May 2005
Slide 13
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Routing To Non-AP STA• Both non-AP STAs and mesh points are the routing destinations• The mesh AP is the routing proxy of its associated non-AP STAs• Pros
– 4 MAC addresses are enough• Cons
– Larger routing table– Higher protocol processing overhead
Forward Mesh Point1’s routing table:Destination : Next HopSTA5 : Mesh AP2STA4 : Mesh AP2STA3 : Mesh AP2STA1 : Mesh AP1STA2 : Mesh AP1Mesh AP2 : Mesh AP2Mesh AP1 : Mesh AP1Mesh Portal1: Mesh Portal1
Mesh AP2’s routing table:Destination : Next HopSTA1 : Forward Mesh Point1STA2 : Forward Mesh Point1Mesh Portal1: Forward Mesh Point1Mesh AP1: Forward Mesh Point1Forward Mesh Point1 : Forward Mesh Point1STA5 : Mesh AP2STA4 : Mesh AP2STA3 : Mesh AP2
ForwardMesh Point1
Mesh Portal1
Mesh AP1
Mesh AP2STA1
STA2
STA3 STA4 STA5
InternetMesh Network
BSS
BSS
May 2005
Slide 14
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Multicast Routing----Mesh-based Multicast Routing Protocol
• A mesh forwarding structure is built for group communication
• More than one path may exist between multicast sender and multicast receiver pair
• Every source node will periodically send out route request through the network
• Pros
– The mesh-based multicast is more robust than tree-based ones since alternative paths exist
• Cons
– The control overhead in a network with less mobility is higher than tree-based multicast routing protocol
– It does not scale well for the large traffic source number and large multicast group size
May 2005
Slide 15
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Multicast Routing---- Previous Work: ODMRP*
• ODMRP (On-Demand Multicast Routing Protocol) is a mesh-based multicast routing protocol
• When a multicast source has packets to send, it periodically floods a JOIN QUERY with data piggybacked
• When a node receives a non-duplicate JOIN QUERY, it stores the upstream node ID into the route table and rebroadcast the packet
• When the JOIN QUERY packet reaches a multicast receiver, the receiver creates and broadcast a JOIN REPLY to its neighbors
• When a node receives a JOIN REPLY and it is on the path to the source, it sets forwarding group flag and broadcasts its own JOIN REPLY until it reaches the multicast source
Receiver
Forwarding Node
Source
* ODMRP: On-Demand Multicast Routing Protocol
May 2005
Slide 16
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Multicast Routing – Our Proposal:Enhanced ODMRP - Overview
• ODMRP with new features: MPR and Adaptive Refreshing• New features reduce control overhead
• ODMRP + MPR (Multi-point Relay)
– Only MPRs rebroadcast JOIN QUERY when OLSR runs as underlying unicast routing protocol
• ODMRP + Adaptive Refreshing– JOIN QUERY broadcasting rate is adjusted on the fly
• Pros:– Enhanced data delivery due to reduced control overhead– More scalable to the number of sources and/or groups
• Cons:– MPR feature can only be activated if OLSR routing protocol is used as
unicast routing protocol– Less robust in highly mobile networks– Increased complexity
May 2005
Slide 17
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Multicast Routing – Our Proposal:Enhanced ODMRP - Details
• ODMRP + MPR
– Unicast OLSR selects MPR set for each node
– When a MPR receives JOIN QUERY from its MPR selector, it processes this message according to ODMRP and broadcasts JOIN QUERY out
– The other mesh points discard received JOIN QUERY message
• Explicit join:
– Due to possibly long route refresh interval of JOIN QUERY
– Newly joining nodes don’t wait until next route refresh from a source to graft onto the multicast group mesh
– Newly joining nodes perform expanding ring search to find a member or a forwarder of the multicast group
– 3-way hand-shaking procedure• Receiver Join Request
• Receiver Join Reply
• Receiver Join ACK
May 2005
Slide 18
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Multicast Routing – Our Proposal:Enhanced ODMRP - Details
• Local Route Recovery :
– On detection of detachment, (only) receivers perform local route recovery
– A receiver regards itself as detached if no Join Query has arrived for multiple inter-packet time intervals from the source
– Local route recovery process is the same as Explicit join process
• Global Route Recovery :
– If local recovery fails, a node performs global route recovery
– The node floods the network with Refresh Request packet
– The multicast group source floods Join Query in response to the request
• Adaptive Refresh Rate :
– A source decreases route refresh interval when receiving Refresh Request
– A source linearly increases route refresh interval if no Refresh Request has arrived during the previous refresh interval
– Refresh interval is bounded by the min and max values
May 2005
Slide 19
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Congestion Control• If packets are discarded because of network congestion,
network resource is wasted especially in multi-hop mesh network
– Congestion control should be used
• Each MP (mesh point) detects network congestion according to:
– Delay
– Queue size
– Packet loss rate
• When congestion occurs, random early congestion notification information is sent to the upstream MP. The most straightforward method is to use ACK frames
• The upstream MP adjusts the packet transmission rate
May 2005
Slide 20
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Neighbor-list LC-MAC*
• Two mesh point priorities are used to lower the collision probability– Highest priority (transmit the first frame after a shorter
IFS idle medium time)– Low priority (the standard EDCA/DCF medium access
method is used)• A neighbor list is maintained in each STA
– Each Mesh point allocates one weight to each of its neighbors
• The TXOP owner (the highest or low priority mesh point) selects the next highest priority mesh point
* LC-MAC: Low Collision Medium Access Coordination
May 2005
Slide 21
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Neighbor-List LC-MAC
• The highest priority MPs– Services more than one Access Category– Gets the medium access right after the medium is idle for LCIFS (low-collision IFS)– Switches to the low priority state when the LCTXOP ends – The last frame of its LCTXOP carries NHPM (Nest High priority Mesh Point)
information
• The low priority MPs– Use EDCA/DCF medium access method to access the medium– The last frame of a TXOP carries NHPM information
May 2005
Slide 22
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Admission Control
• Admission control is used to guarantee QOS and/or realize the traffic engineering
• Admission control decides if aggregate real-time traffic between border mesh points (mesh portal and mesh AP) is allowed based on the available bandwidth along the path being used
• The available bandwidth equals the difference between the total bandwidth allocated to the real-time traffic and the bandwidth used by the real-time traffic
• The bandwidth used by the real-time traffic at any node is measured based on the real-time packets the node detected
May 2005
Slide 23
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Admission Control• Admission control is done at the destination Mesh Point (MP)
– A request message is used to get the available bandwidth of the selected path, and the requested bandwidth
– The destination decides if the request is admitted
– The forwarding information is established when the response message is sent back to the source MP
To InternetTo Internet
Mesh Point
Mesh Point
Mesh Point
Mesh Portal
Mesh Portal
Mesh AP
Mesh AP
STASTA STA STA
STA
Req Req
RepRep
May 2005
Slide 24
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Conclusion
• The ST+UCLA mesh network proposal has been presented with the following major components:– Unicast and multicast routing protocols with lower control overhead
– Notification-based congestion control scheme
– Efficient new medium coordination access method
– Admission control
May 2005
Slide 25
doc.: IEEE 802.11-05/0379r0
Submission Liwen Chu et al.
Reference
• T. Clausen, et al, “Optimized Link State Routing Protocol (OLSR)”, RFC 3626
• M. Gerla, et al, “Fisheye State routing Protocol (FSR) for Ad Hoc Networks”, <draft-ietf-manet-fsr-03.txt>
• YunJung Yi, et al, “On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Network”, <draft-ietf-manet-odmrp-04.txt>
• R. Draves, et al, “Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks”, MobiCom’04
• H. Radis, et al, “Quality of Service for Ad hoc Optimised Link State Routing Protocol (QOLSR)”, <draft-badis-manet-qolsr-01.txt>
• H. Badis, et al, “Optimal Path Selection Analysis in Ad Hoc Networks”