Doc.: IEEE 802.15-05-0469-01-0005 Submission July 2005 Michael Sim, Panasonic Singapore...

July 2005

Michael Sim, Panasonic Singapore LaboratoriesSlide 1

doc.: IEEE 802.15-05-0469-01-0005

Submission

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Submission Title: [Mesh Networking for IEEE 802.15.3 and IEEE 802.15.4]Date Submitted: [ 20 July, 2005]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:[[email protected]]Re: [Response to call for proposal for 802.15.5 Mesh protocol]

Abstract: [Partial proposal describing how “Mesh Networking” support can be enabled for IEEE 802.15.3 and IEEE 802.15.4 WPAN.]

Purpose: [For 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.

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

IEEE 802.15.5 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 802.15 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

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

Multiple Associations

Inter-piconet Communications

WPAN Mesh Topologies

A

C

B

4

5

8

13

3

6

9

1

7

2

Master (PNC/FFD) Slave (DEV/RFD)

Control & Data path

Mesh Control & Data pathData path

Mesh Data path

A

C

B

D

F

4

5

13

8

12

14

3

6

9

1

16

11

10

15

7

2

E

IEEE 802.15.3 IEEE 802.15.4

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

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)

This Presentation

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

IEEE WPAN Superframes (Structure)

B CAPChannel time allocation period

CTA 1 CTA 2 CTA n… CTA n-1 B

Active SuperframeInactive

Superframe n-1 Superframe n Superframe n+1 Superframe n-1 Superframe n Superframe n+1

IEEE 802.15.3 IEEE 802.15.4

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.

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

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


PCTA 1 PCTA 2 CTA n… CTA n-1 B


IEEE 802.15.3 IEEE 802.15.4

B CAP CFP B CAP CFPActive SF Inactive

Active SF Inactive

How to share channel time?

CAP (+CFP)

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

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.)

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

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


PCTA 1 PCTA 2 CTA n… CTA n-1 B


IEEE 802.15.3 IEEE 802.15.4

B CAP CFP B CAP CFPActive SF Inactive

Active SF Inactive

CAP (+CFP)

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

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 2SOmax 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

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

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. 802.11 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

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

Recommendations – Example

A

1

A

2

1

A

2

B

1

A

2

B

34

DEV-A starts a piconet

DEV-1 and DEV-2Joins Piconet-A.

CFP is setup for them

DEV-B starts another piconet

DEV-3 and DEV-4Joins Piconet-B.

CFP is setup for them

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

Recommendations – Collisions

• Collision Detection– 3rd 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 3rd parties exists:• Random periodic scan• Repeated communication failure

• CS Collision Resolution– ES collision: Re-allocate ES– CS collision: Relocate CS to a random FS

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

Recommended Changes in MAC

IEEE 802.15.3 IEEE 802.15.4 IEEE 802.15.3+ IEEE 802.15.4+

Slave(DEV

or RFD)

•No changes •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

•Adopt channel time sharing friendly settings

•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

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

Backward Compatibility

• IEEE 802.15.3– 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 802.15.4– 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

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

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

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

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

July 2005


doc.: IEEE 802.15-05-0469-01-0005

Submission

End of Presentation.

Thank You.

Doc.: IEEE 802.15-05-0469-01-0005 Submission July 2005 Michael Sim, Panasonic Singapore...

Documents

Transcript of Doc.: IEEE 802.15-05-0469-01-0005 Submission July 2005 Michael Sim, Panasonic Singapore...