1. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
January 2006
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Mesh Networking Considerations for IEEE ]
Date Submitted: [ 18 January, 2006]
Source: [Michael Sim] Company [Panasonic Singapore Laboratories]
Address [Blk 1022 Tai Seng Avenue # , Singapore, Singapore , Singapore]
Voice:[ ], FAX: [ ],
Re: [Mesh Networking considerations for IEEE MAC protocol]
Abstract: [A look at how can IEEE MAC can support Mesh Networking, its problems, and modifications needed to address these problems.]
Purpose: [To aid discussion in the IEEE Task Group]
Notice: This document has been prepared to assist the IEEE P 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
Michael Sim, Panasonic Singapore Laboratories
<author>, <company>

2. IEEE 802.15.5 Scope Mesh Network Routing Mechanisms above MAC
January 2006
IEEE Scope
Mesh Network Routing Mechanisms above MAC
Routing
Range Extension
Route Redundancy
Support for Mesh Networking in MAC
Mesh Topology (point to multi-point)
Support for SOP
Handle multiple Master devices
Handle multiple supeframes coexistence
Fair sharing of channel time
Backward Compatibility
Samsung’s Adaptive
Robust Tree (ART)
The topic we are
debating now
Michael Sim, Panasonic Singapore Laboratories

3. IEEE 802.15 WPANs Medium Access
January 2006
IEEE WPANs Medium Access
IEEE B
CAP
CFP … … B
CAP
CFP B
CAP
CFP … B
CAP
CFP … … B
CAP
CFP B
CAP
CFP …
CH_4
CH_3
CH_2
CH_1
IEEE … B B … … B B … … B B … … B B …
CH_4
CH_3
CH_2
CH_1
Every channel uses same medium access method
Beacon Period + CAP + CFP (optional for 15.4)
If a channel is busy, a PNC/FFD may select another channel to start its piconet
Michael Sim, Panasonic Singapore Laboratories

4. IEEE 802.15.3 Mesh Support? ? Does it support Mesh? No, but it can…
January 2006
IEEE Mesh Support?
Does it support Mesh? No, but it can… A B
CAP
CFP
PNC
MESH PROTOCOL /
TRAFFIC B D C ?
802.11?
MPA?
Some ??? Mesh Protocol?
Michael Sim, Panasonic Singapore Laboratories

5. What is the problem then?
January 2006
What is the problem then?
IEEE
IEEE A C B D F 4 5 13 8 12 14 3 6 9 1 16 11 10 15 7 2 E A C B 4 5 8 13 3 6 9 1 7 2
Inter-piconet
Communications
Multiple Associations
Master (PNC/FFD)
Slave (DEV/RFD)
Control & Data path
Mesh Control & Data path
Data path
Mesh Data path
Michael Sim, Panasonic Singapore Laboratories

6. Mesh Networking Issues
January 2006
Mesh Networking Issues
Multiple-piconet coexistence?
Still possible: Use Child/Neighbor… BUT:
Inter-piconet communication?
Only child PNC can communicate in parent piconet
Communicate using a “Mesh period” allocated in CFP? Complexity?
Limited medium access for child/parent piconet?
Child/Neighbor piconet dependent on parent piconet?
Mesh devices to be discoverable? => Multiple beaconing devices B
CAP
CFP
MESH PROTOCOL /
TRAFFIC
Child/Neighbor Superframe
Michael Sim, Panasonic Singapore Laboratories

7. Recommendations (Introduction)
January 2006
Recommendations (Introduction)
Motivation:
Recall generic superframe structure for both 15.3 and 15.4 MAC consists of:
Beacon slot => Piconet synchronization/control
CAP => Piconet command/response + Contention-based data
CFP => Contention-less data
Beacon slot + CAP : Sufficient to start and maintain a IEEE WPAN piconet + provide basic data exchange
In 15.4, Beacon slot + CAP = Active superframe
Definition:
Medium Slot (MS) = Equal size block divided from channel time
Core Block (CB) = Beacon slot + CAP
Extension Block (EB) = Additional block of channel time reserved by a piconet for exclusive use (e.g. for CTAs, extend CAP, or for proprietary channel access method etc.)
Michael Sim, Panasonic Singapore Laboratories

8. “Distributed” IEEE 802.15.3 Superframe
January 2006
“Distributed” IEEE Superframe
A piconet’s CB = piconet’s exclusive channel time
PNC_A’s Superframe
PNC_A’s Superframe A A A A A A B B B B B B
Only piconet B
can use
Only piconet A can use
PNC_B’s Superframe
PNC_B’s Superframe
Any piconet can use
PNC_A’s Superframe
PNC_A’s Superframe A A B B A A B B A A
PNC_B’s Superframe
PNC_B’s Superframe
Michael Sim, Panasonic Singapore Laboratories

9. Channel time allocation period
January 2006
What About IEEE ?
Generic idea applicable to 15.4 Superframe
In 15.4, CB = Active Superframe
IEEE
IEEE B
CAP
Channel time allocation period
Active Superframe
Inactive …
PCTA 1
PCTA 2
CTA n-1
CTA n B
CAP (+CFP)
Active SF
Inactive B
CAP
CFP B
CAP
CFP
Active SF
Inactive
Michael Sim, Panasonic Singapore Laboratories

10. Coexistence & SOP Operating Procedures
January 2006
Coexistence & SOP
Operating Procedures
Before 15.3 or 15.4 piconet is set up, scanning for existing piconet is done.
To start a new piconet, master device (PNC/FFD) uses 1 MS for its CB instead of exclusively occupying channel time for its entire superframe
Master devices include in their beacon the MS occupancy information
Devices listen to all CB in the neighbourhood
Master device informs nearby master devices of its presence by sending an announcement in the CBs (during CAP) of the nearby master devices
To facilitate route redundancy and inter-piconet communications, slave devices already associated with a master device may make secondary associations with other master devices
Devices uses CAP in secondary piconet to communicate with devices in secondary piconet
Michael Sim, Panasonic Singapore Laboratories

11. Simple Example January 2006
DEV-A starts a
piconet A 2
DEV-1 and DEV-2
Joins Piconet-A.
CFP is setup for them A 1 2
DEV-B starts
another piconet A B 1 2 A
DEV-3 and DEV-4
Joins Piconet-B.
CFP is setup for them B 1 4 3
Michael Sim, Panasonic Singapore Laboratories

12. Collisions Detection and Resolution
January 2006
Collisions Detection and Resolution
Collision Detection
3rd parties exists:
Local device not heard in neighbor’s MS occupancy information (CB Collision)
Associated slave unable to heard beacon (CB Collision)
Packet addressed to devices not associated with master device heard in CAP (CB Collision)
Conflict heard in MS occupancy information (EB Collision)
No 3rd parties exists:
Random periodic scan
Repeated communication failure
CB Collision Resolution
EB collision: Re-allocate EB
CB collision: Relocate CB
Michael Sim, Panasonic Singapore Laboratories

13. January 2006
IEEE Compatibility
Notation: Let denote Mesh enabled IEEE DEV and PNC to be “DEV+” and “PNC+” for short.
Qn1: How do DEV works with PNC+ network?
Ans1: No changed. DEV listen to PNC+’s beacon, able to use CAP for command/async data and also able to reserve CTAs. PNC+ networks look like PNC networks to DEV.
Qn2: How do DEV+ work with PNC network?
Ans3: PNC is not mesh enabled, so just behave like DEV. If DEV+ want to support mesh, it can switch role to PNC+ (if it is capable)
Qn3: How do PNC and PNC+ work each other?
Ans2: When PNC and PNC+ meets, 2 case:
PNC+ refuse to be dependent PNC. PNC shall request to be child or neighbor PNC of PNC+
PNC+ request to be child or neighbor PNC
Michael Sim, Panasonic Singapore Laboratories

14. What do we have? Minimal IEEE 802.15.3 changes
January 2006
What do we have?
Minimal IEEE changes
Based on 15.3 Superframe structure. Backward compatible.
Hybrid centralized + distributed
Support multiple beacon devices (PNC/PNC+) and non-beaconing devices (DEV/DEV+)
Inter-piconet communication supported
Fair use of channel time
Channel time not owned by PNC+. PNC+ only owns beacon slot + CAP time.
Efficiency? Async and Isoch still uses CAP and CTA allocations so it is the same as IEEE
Concept applicable to IEEE
Michael Sim, Panasonic Singapore Laboratories

15. End of Presentation. Mahalo for your time! January 2006
Michael Sim, Panasonic Singapore Laboratories