1

802.11s Proposal - Joint SEE-Mesh/Wi-Mesh Proposal

to 802.11 TGsIEEE 802.11-06/0328r0

Feb 2006

This proposal can be obtained from http://www.802wirelessworld.com/.

2

Current 802.11s Proposals

Table from:“Proposals for TGs”, IEEE 802.11-05/0597r20

Contact

Short Name Ratio Rank Ratio Rank Ratio Rank Ratio Rank

B/G Joint SEE Mesh Wi-Mesh

G 7 SEE Mesh 83.58% 1 82.84% 1 77.67% 1B 31 Wi-Mesh Alliance (WiMA) 77.16% 2 58.93% 2 39.79% 2

H 9 Mesh Networks Alliance (MNA) 60.62% 4 35.54% 3 15.07% 3

J 35 Proactive Mesh 53.89% 5 28.16% 4 (merged into G:7)M 22 Common Control Channel 34.05% 10 15.17% 5A 8 Mesh DCF 26.02% 12 11.18% 6

K 32 Samsung 76.82% 3 (merged into G:7)C 6 Cooperative Protocol 52.16% 6 (merged into B:31)E 5 Hybrid Mesh Routing 51.03% 7 (merged into B:31)L 19 Siemens 50.92% 8 (merged into G:7)N 18 SNOW Mesh 48.66% 9 (merged into G:7)I 20 Tree Based Routing (TBR) 33.48% 11 (merged into G:7)

F 3 Dynamic Backbone 18.93% 13D 17 Intermittent Periodic Transmit (IPT) 11.98% 14O 29 Self Organizing 10.61% 15

Defer untilMarch

Jan-06Nov-05Sep-05Jul-05Proposal #

3

Outline1. General Description2. Mesh Topology Discovery and Formation3. NEW! Path Selection: Hybrid Wireless Mesh Proto

col (HWMP)4. Interworking Support5. NEW! Multi-Channel Support (CCF) (optional)

4

3. Path Selection: Hybrid Wireless Mesh Protocol (HWMP) Combines the flexibility of on-demand route discovery with

the option for efficient proactive routing to a mesh portal On demand service is based on Radio Metric AODV (RM-

AODV) same as the SEE-mesh When a root portal is not configured, RM-AODV is used to

discover routes to destinations in the mesh Pro-active routing is not for all links; it is a tree-based routing

If a Root portal is present, a distance vector routing tree is built and maintained

advantage: most traffics are destined to the Root can reduce unnecessary route discovery flooding

5

Path Selection Protocol – RMAODV Radio Metric Ad hoc On-Demand Distance Vector Summary of features beyond AODV:

Identify best-metric path with arbitrary path metrics Reduce flooding when maintaining multiple paths

Aggregate multiple RREQs in same message Modification to RREQ/RREP processing/forwarding rul

es Forward RREQ with better metric No route caching

Optional periodic path maintenance Allows proactive maintenance of routes to popular desti

nations (e.g. MPP)

6

Example: MP 4 wants to communicate with MP 9

1. MP 4 first checks its local forwarding table for an active forwarding entry to MP 9

2. If no active path exists, MP 4 sends a RREQ to discover the best path to MP 9

3. MP 9 replies to the RREQ with a RREP to establish a bi-directional path for data forwarding

4. MP 4 begins data communication with MP 9

59

710

6

4

3

2

1

8

X

On-demand path

HWMP Example #1: No Root Portal(s), Destination Inside the Mesh

7

Example: MP 4 wants to communicate with X

1. MP 4 first checks its local forwarding table for an active forwarding entry to X

2. If no active path exists, MP 4 sends a RREQ to discover the best path to X

3. When no RREP received, MP 4 assumes X is outside the mesh and sends messages destined to X to Mesh Portal(s) for interworking

4. MP 1 forwards messages to other LAN segments according to locally implemented interworking

59

710

6

4

3

2

1

8

X

On-demand path

HWMP Example #2: No Root Portal(s), Destination Outside the Mesh

8

Example: MP 4 wants to communicate with X

1. MP 4 first checks its local forwarding table for an active forwarding entry to X

2. If no active path exists, MP 4 may immediately forward the message on the proactive path toward the Root MP 1

3. When MP 1 receives the message, if it does not have an active forwarding entry to X it may assume the destination is outside the mesh and forward on other LAN segments according to locally implemented interworking

Advantage: No broadcast discovery required when destination is outside of the mesh

59

710

6

4

3

2

1

8

X

Proactive path

Root

HWMP Example #3: With Root Portal,Destination Outside the Mesh

9

Example: MP 4 wants to communicate with MP 9

1. MP 4 first checks its local forwarding table for an active forwarding entry to MP 9

2. If no active path exists, MP 4 may immediately forward the message on the proactive path toward the Root MP 1

3. When MP 1 receives the message, it flags the message as “intra-mesh” and forwards on the proactive path to MP 9

4. (Reverse RREQ) When MP 9 receives the message, it may issue an on-demand RREQ to MP 4 to establish the best intra-mesh MP-to-MP path for future messages

59

710

6

4

3

2

1

8

X

Proactive path

Root

On-demand path

HWMP Example #4: With Root Portal,Destination Inside the Mesh

10

5. Multi-Channel Support: Common Channel Framework (CCF) Using RTX, the transmitter suggests a

destination channel. (RTX ≠ RTS) Receiver accepts/declines the suggested

channel using CTX. (CTX ≠ CTS) After a successful RTX/CTX exchange, the

transmitter and receiver switch to the destination channel.

Switching is limited to channels with little activity.

Existing medium access schemes are reused.

11

CCF Example (1)

RTX

MP1

MP2

MP3

MP4

CommonChannel

DataChannel n

DataChannel m

CTX

SIFS

CTX

SIFS

RTX

DIFS

DIFS

DATA

SwitchingDelay

ACK

SIFS CTX

SIFS

RTX

DIFS

SwitchingDelay

DATA

SwitchingDelay DIFS

ACK

SIFS

DataChannel n

DataChannel m

12

Channel Coordination To increase channel utilization, a channel

coordination window (CCW) is defined on the common channel. P is the period with which CCW is repeated. MPs should stay tuned to CCW, and may remain in the comm

on channel beyond CCW duration. P and CCW are carried in beacons. At the start of CCW, CCF enabled MPs tune to the

common channel. This facilitates all MPs to get connected. Channel Utilization Vector (U) of each MP is reset. MPs mark a channel as unavailable based on information

read from RTX/CTX frames.

13

CCF Example (2)

RTXA® B

CTXB® A

RTXC® D

CTXD® C

RTSE® F

CTSF® E

RTXB® A

CTXA® B

DATAE® F

ACKF® E

RTXC® D

CTXD® C

Common Channel

Channel m

Channel n

DATAA® B

ACKB® A

DATAC® D

ACKD® C

DATAB® A

Channel Coordination Window (CCW)

P

ChannelSwitching Delay

DIFS

14

Conclusions SEE-Mesh + Wi-Mesh for IEEE 802.11s New materials:

Hybrid path selection protocol (RM-AODV + tree-based DSDV)

Multi-channel support (Channel coordination function)