1 / 15

Mesh Networking Considerations for IEEE 802.15.3

Delve into how IEEE 802.15.3 MAC can support Mesh Networking, the challenges it faces, and necessary modifications to tackle these issues. This submission aims to aid discussions in the IEEE 802.15.5 Task Group.

paynem
Download Presentation

Mesh Networking Considerations for IEEE 802.15.3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Mesh Networking Considerations for IEEE 802.15.3] Date Submitted: [ 18January, 2006] Source: [Michael Sim] Company [Panasonic Singapore Laboratories] Address [Blk 1022 Tai Seng Avenue #06-3530, Singapore, Singapore 534415, Singapore] Voice:[+65-6550-5323], FAX: [+65-6550-5201], E-Mail:[michael.simhc@sg.panasonic.com] Re: [Mesh Networking considerations for IEEE 802.15.3 MAC protocol] Abstract: [A look at how can IEEE 802.15.3 MAC can support Mesh Networking, its problems, and modifications needed to address these problems.] Purpose: [To aid discussion in the IEEE 802.15.5 Task Group] Notice: This document has been prepared to assist the IEEE P802.15. 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 P802.15. Michael Sim, Panasonic Singapore Laboratories

  2. IEEE 802.15.5 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. … B CAP CFP B CAP CFP … … B CAP CFP B CAP CFP … IEEE 802.15 WPANs Medium Access IEEE 802.15.3 • 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 … B CAP CFP B CAP CFP … … B CAP CFP B CAP CFP … CH_4 CH_3 CH_2 CH_1 IEEE 802.15.4 … B B … … B B … … B B … … B B … CH_4 CH_3 CH_2 CH_1 Michael Sim, Panasonic Singapore Laboratories

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

  6. B CAP CFP MESH PROTOCOL / TRAFFIC B CAP CFP Child/Neighbor Superframe 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 Michael Sim, Panasonic Singapore Laboratories

  7. 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 802.15 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 • 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. What About IEEE 802.15.4? • Generic idea applicable to 15.4 Superframe • In 15.4, CB = Active Superframe IEEE 802.15.3 IEEE 802.15.4 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 • 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 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 • 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. IEEE 802.15.3 Compatibility • Notation: Let denote Mesh enabled IEEE 802.15.3 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 • 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 802.15.3 • Concept applicable to IEEE 802.15.4 Michael Sim, Panasonic Singapore Laboratories

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

More Related