doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Mesh Networking for IEEE and IEEE ] Date Submitted: [ 20 July, 2005] Source: [Michael Sim] Company [Panasonic Singapore Laboratories] Address [Blk 1022 Tai Seng Avenue # , Singapore, Singapore , Singapore] Voice:[ ], FAX: [ ], Re: [Response to call for proposal for Mesh protocol] Abstract:[Partial proposal describing how “Mesh Networking” support can be enabled for IEEE and IEEE WPAN.] Purpose:[For 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

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 2 IEEE PAR Scope: “To provide a recommended practice to provide the architectural framework enabling WPAN devices to promote interoperable, stable, and scaleable wireless mesh topologies and, if needed, to provide the amendment text to the current WPAN standards that is required to implement this recommended practice.” Objectives: facilitates wireless mesh topologies optimized for IEEE WPANs. –Extension of network coverage without increasing the transmit power or the receiver sensitivity –Enhanced reliability via route redundancy –Easier network configuration –Better device battery life

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 3 Multiple Associations Inter-piconet Communications WPAN Mesh Topologies A C B Master (PNC/FFD)Slave (DEV/RFD) Control & Data path Mesh Control & Data path Data path Mesh Data path A C B D F E IEEE IEEE

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 4 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) This Presentation

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 5 IEEE WPAN Superframes (Structure) B CAP Channel time allocation period CTA 1CTA 2CTA n … CTA n-1 B Active Superframe Inactive Superframe n-1Superframe nSuperframe n+1Superframe n-1Superframe nSuperframe n+1 IEEE IEEE CAP (+CFP) Similarities: - Structure contains: - Beacon slot => Piconet synchronization and control - Contention Access Period (CAP) => command/response packet + contention-based data - Contention Free Period (CFP) => contention-less access - A piconet may potentially use the full duration of channel time. Differences: - In 15.4, an inactive period is defined and may be used by other piconets for their superframes. - In 15.3, the CFP come after CAP. In 15.4, CAP slot can be allocated for CFP use.

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 6 IEEE WPAN Superframes (Coexistence) Child/Neighbor Piconet –Dependent on parent piconet –Available channel time limited to private CTA allocated by parent piconet –No inter-piconet communication possible Inactive Period –Piconet requiring long duration of CFP may have long active superframe => short inactive period left for sharing B CAP Channel time allocation period PCTA 1PCTA 2CTA n … CTA n-1 B Active Superframe Inactive IEEE IEEE B CAPCFP B CAPCFP Active SFInactive Active SFInactive How to share channel time? CAP (+CFP)

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 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 piconet + provide basic data exchange –In 15.4, Beacon slot + CAP = Active superframe Definition: –Core Slot (CS) = Beacon slot + CAP –Extension Slot (ES) = Additional block of channel time reserved by a piconet for exclusive use (e.g. for CFP, extend CAP, or for proprietary channel access method etc.)

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 8 Recommendation (Channel Sharing) Channel time is partitioned into equal-sized Medium Slots (MSs) A piconet uses a MS exclusively for its CS to start and maintain a basic piconet –Every piconet is ensured fair share of time for beacon and CAP Rest of unused MSs can be allocated as ES by any master device B CAP Channel time allocation period PCTA 1PCTA 2CTA n … CTA n-1 B Active Superframe Inactive IEEE IEEE B CAPCFP B CAPCFP Active SFInactive Active SFInactive CAP (+CFP)

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 9 Recommendations (Channel Sharing) Channel Time Sharing Friendly Settings Define MS duration such that it will fit a CS that it is sufficient for: –TX of longest Beacon Frame + Command/Response/Data –For 15.3 => CS = Max(Beacon Slot) + Max(CAP) –For 15.4 => CS = Max(Active superframe) = 960 x 2 SOmax symbols Define a base beacon broadcast rate (i.e. shortest superframe) –i.e. Number of MSs in the shortest superframe –Dependent on: Number of concurrent piconets to be supported Minimum beacon interval requirement –For example: Min(MS) = 1 => Entire channel time is used by Beacon Slot + CAP by a piconet Min(MS) = 32 => The channel can support 32 piconets (assuming no CFP) All beacon broadcast rates to be integer multiples of base beacon broadcast rate

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 10 Recommendations (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 CS instead of exclusively occupying channel time for its entire superframe –If required, a piconet can reserves additional MSs for ES use. –The rest of unused MSs can be used by other piconets for their CS or be reserved for ES Master device that first starts a piconet defines the MS boundary –MS boundary is to be synchronized if other master devices is present –Any arbitrary methods can be used (e.g TSF) Master devices include in their beacon the MS occupancy information –Devices listen to all CS in the neighbourhood –Provide 1-hop information to support network extension All master device to listen CSs in the neighborhood Master device informs nearby master devices of its presence by sending an announcement in the CSs (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

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 11 Recommendations – Example A 1 A 2 1 A 2 B 1 A 2 B 3 4 DEV-A starts a piconet DEV-1 and DEV-2 Joins Piconet-A. CFP is setup for them DEV-B starts another piconet DEV-3 and DEV-4 Joins Piconet-B. CFP is setup for them

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 12 Recommendations – Collisions Collision Detection –3 rd parties exists: Local device not heard in neighbor’s MS occupancy information (CS Collision) Associated slave unable to heard beacon (CS Collision) Packet addressed to devices not associated with master device heard in CAP (CS Collision) Conflict heard in MS occupancy information (ES Collision) –No 3 rd parties exists: Random periodic scan Repeated communication failure CS Collision Resolution –ES collision: Re-allocate ES –CS collision: Relocate CS to a random FS

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 13 Recommended Changes in MAC IEEE IEEE IEEE IEEE Slave (DEV or RFD) No changes Associate with secondary PNCs Listen to multiple beacons Inter-piconet communication Associate with secondary FFDs Listen to multiple beacons Inter-piconet communication Master (PNC or FFD) Adopt channel time sharing friendly settings Only CS is required to start and maintain a basic piconet Allocate ESs from available FSs Support secondary DEVs Listen to multiple beacons Broadcast MS occupancy information Inter-piconet communication Adopt channel time sharing friendly settings Only CS is required to start and maintain a basic piconet Allocate ESs from available FSs Support secondary RFDs Listen to multiple beacons Broadcast MS occupancy information Inter-piconet communication

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 14 Backward Compatibility IEEE –DEV+ DEV+ shall not make secondary association with PNC –PNC+ PNC+ may choose associate as child/neighbor of PNC –PNC+ operate within Private CTA granted by PNC PNC+ may choose to stay as “parent PNC” for PNC –PNC+ allocates 1 or more consecutive ESs for PNC IEEE –RFD+ RFD shall not make secondary association with FFD –FFD+ To support CFP for RFD, FFD+ may sacrifice some CAP slots with CS (i.e. active SF) to be used for CFP

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 15 Future Work Outstanding issues/work: Determining suitable parameters for both 15.3 and 15.4: –MS duration –Base beacon broadcast rate (shortest superframe) 15.3 MAC typically shorter superframe –Number of concurrent piconets to supportber of concurrent Typically lesser for 15.3 Finalizing details in operating procedures –MS duration synchronization

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 16 Conclusion Mesh Networking requires both Mesh Networking Routing mechanism and MAC level support To support Mesh Networking, collaborative effort within the MAC to share channel time is necessary Recommended changes to enable IEEE WPAN for mesh networking involves: –Defining a channel time sharing scheme –Mechanism to support piconets coexistence and route redundancy Advantages of recommended changes: –All piconets receive equal share of channel time for beacon slot and CAP –Unused channel time available to be shared by all piconets –Enable inter-piconet communication –Most of the existing 15.3 and 15.4 MAC functionalities preserved Further discussion will be needed for other outstanding issues

doc.: IEEE Submission July 2005 Michael Sim, Panasonic Singapore LaboratoriesSlide 17 End of Presentation. Thank You.