doc.: ieee 802.15-04-0536-00-004b submission september 2004 myung lee, et al,slide 1 note: update...

September 2004

Myung Lee, et al,Slide 1

doc.: IEEE 802.15-04-0536-00-004b

Submission

NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriatefields. All Blue fields are informational and are to be deleted. Black stays. After updating delete this box/paragraph.

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: [Combined proposal of Enhancements to IEEE 802.15.4]Date Submitted: [16 September, 2004]Source: [Myung Lee, Jianliang Zheng, Yong Liu, Huai-Rong Shao,Hui Dai and Jinyun Zhang, Hoin Jeon] Company [Samsung Lab @ CUNY, Mitsubishi Electric Research Lab, Kyungwon University]Address [T677, EE Dept. Steinman Hall 140th Street and Convent Ave, NY, NY 10031 ]Voice:[212-650-7260], FAX: [212-650-8249], EMail:[[email protected]]

Re: [Response to the call for proposal of IEEE 802.15.4b, MAC Enhancement .]

[If this is a response to a Call for Contributions, cite the name and date of the Call for Contributions to which this document responds, as well as the relevant item number in the Call for Contributions.][Note: Contributions that are not responsive to this section of the template, and contributions which donot address the topic under which they are submitted, may be refused or consigned to the “General Contributions” area.]

Abstract: [Discussion for several potential enhancements for current IEEE 802.15.4 MAC]

Purpose: [For the discussion at IEEE 802.15.4b Study 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.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission

Combined Beacon Scheduling Proposal to IEEE 802.15.4b

Myung Lee, Jianliang Zheng, Yong LiuSamsung Lab@ CUNY

Huai-Rong Shao, Hui Dai, Jinyun ZhangMitsubishi Electric Research Labs.

Ho-in JeonKyungwon University

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission

Proposed Change to 802.15.4

• Add only one attribute “macPostbeacon-delay” in MAC PIB.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission

Support of Multi-hop Beacon Enabled Networks (1)

• Beacons are very important to network operations.

• Beacon transmissions do not follow CSMA/CA.

• In a multi-hop beacon enabled network, each node has to prevent its beacons and data packets from destroying the beacons from its parent and its neighbors’ parents.

• Current 802.15.4 MAC has to be enhanced to support beacon scheduling operated at the upper layer.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission

Support of Multi-hop Beacon Enabled Networks (2)0

1 16

2

3

4

6

7

9

10

11

13

14

17

18

19

21

22

24

25

26

28

29

Tree Link

Direct Reachable

• To assign a contention-free time-slot to a node u in a tree type network – (c.1) u’s time-slot must be different

from u’s parent’s time-slot.

– (c.2) u’s time-slot must not be the time-slot of the parent of anyone of u’s neighbors, excluding u’s own children.

• In other words, the time-slot used by one node is “unavailable” to its children and their neighbors.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission


1 16

2

3

4

6

7

9

10

11

13

14

17

18

19

21

22

24

25

26

28

29

Tree Link

Direct Reachable

• For example– The time-slot used by node 0 is

unavailable to its children: 1, 16, as well as their neighbors: 2, 9, 17, 24.

– The time-slot used by node 1 is unavailable to its children: 2, 9, as well as their neighbors: 3, 6, 10, 13, 18, 17.

– However, node 1 and node 16 can share the same time-slot since they do not have common children.

– Node 3 can share the same time-slot with node 0 since they are three-hop away.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission


1 16

2

3

4

6

7

9

10

11

13

14

17

18

19

21

22

24

25

26

28

29

Tree Link

Direct Reachable

• Since the time-slot used by one node is “unavailable” to its children and their neighbors,– Each coordinator has to obtain its

parent’s time-slot and notify its neighbors about its parent’s time-slot.

– It has to collect the time-slots used by its neighbors’ parents.

– It has to select a time-slot different from those of its parent and its neighbors’ parents.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission


• Approach 1:– Each coordinator selects a contention-free time-slot for its active period.

– It includes the Beacon_Tx_Offset (between its beacon and its parent’s beacon) in its beacon payload.

– Every new coordinator obtains its neighbors and their parents time-slots from the neighbors’ beacons.

Beacon Tracking

Parent

Child

BeaconTx Offset

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission


• Problems of approach 1:

– Assumption: very low duty cycle and very short active period.• Shall we limit the beacon-enabled mode only to low duty-cycle applications?

– Active period cannot be dynamically extended, unless sufficient guard interval is provided. – Every coordinator has to wake up in both its own active period and its parent’s active period.– Direct communications between sibling nodes are problematic if each node only wakes up in

its own active period and its parent’s active period.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission


• Approach 2:– Every coordinator selects a contention-free time-slot within

the Beacon-only-Period to transmit its own beacon.

ActivePAN

Coordinator

InactiveChild

CoordinatorActive

InactiveGrandchildCoordinator

wake-up

Active

Beacon

Beacon-only Period

Guard Interval

wake-up

postBeaconDelay

postBeaconDelay

postBeaconDelay

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission


• Approach 2 (cont.):– A Beacon-only-Period is formed at the beginning of each

superframe.

– At the beacon scheduling stage, the coordinators have to

include the Beacon-only-Period parameters (beginning time, length) and their parent’s time-slot numbers in their beacon payloads.

– A postBeaconDelay has to be added to the MAC PIB to delay the data transmissions to the end of the Beacon-only-Period.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission


• Benefits of approach 2:– Without the limitation of low duty-cycle– Superframes/Active-Periods are nicely synchronized

• Coordinators can freely extend their active-periods based on their own traffic conditions.

• Every node only needs to wake up once within one beacon interval.

• Coordinators can directly talk with siblings since they share the same active period.– Beacon-enabled network can also conduct Zigbee integrated

routing.

• Enable instant packet relays and multihop GTS alignment.

September 2004


doc.: IEEE 802.15-04-0536-00-004b

Submission


• Backward compatibility:– For 15.4 device, the NWK layer has to prevent the

MAC layer from sending packets before the end of the Beacon-only-Period.• At the end of each active period, NWK layer of 15.4 devices

shall purge (MCPS-PURGE) the packets queued at the MAC layer.

• macAutoRequest is always set as FALSE to prevent the MAC layer of 15.4 devices from sending data request command automatically.

• The NWK layer of 15.4 devices issues MCPS-DATA or MLME-POLL only after the Beacon-only-Period ends.

doc.: ieee 802.15-04-0536-00-004b submission september 2004 myung lee, et al,slide 1 note: update...

Documents