Doc.: IEEE 802.11-05/0379r0 Submission Liwen Chu et al. May 2005 Slide 1 ST+UCLA TGs Mesh Network Proposal Date: 2005-05-16 Authors: Notice: This document.

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”