IEEE 802.15 subject

1
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 _at_ CUNY,
Mitsubishi Electric Research Lab, Kyungwon
University Address T677, EE Dept. Steinman Hall
140th Street and Convent Ave, NY, NY 10031
Voice212-650-7260, FAX [phone],
EMaillee_at_ccny.cuny.edu 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 do not 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.
NOTE Update all red fields replacing with your
information they are required. This is a manual
update in appropriate fields. All Blue fields
are informational and are to be deleted. Black
stays. After updating delete this box/paragraph.
2
Combined Beacon Scheduling Proposal to IEEE
802.15.4b

• Myung Lee, Jianliang Zheng, Yong Liu
• Samsung Lab_at_ CUNY
• Huai-Rong Shao, Hui Dai, Jinyun Zhang
• Mitsubishi Electric Research Labs.
• Ho-in Jeon
• Kyungwon University

3
Proposed Change to 802.15.4

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

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

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

• To assign a contention-free time-slot to a node u
  in a tree type network
• (c.1) us time-slot must be different from us
  parents time-slot.
• (c.2) us time-slot must not be the time-slot of
  the parent of anyone of us neighbors, excluding
  us own children.
• In other words, the time-slot used by one node is
  unavailable to its children and their neighbors.

6
Support of Multi-hop Beacon Enabled Networks (3)

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

7
Support of Multi-hop Beacon Enabled Networks (4)

• Since the time-slot used by one node is
  unavailable to its children and their
  neighbors,
• Each coordinator has to obtain its parents
  time-slot and notify its neighbors about its
  parents 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.

8
Support of Multi-hop Beacon Enabled Networks (5)

• 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 parents beacon) in its beacon
  payload.
• Every new coordinator obtains its neighbors and
  their parents time-slots from the neighbors
  beacons.

9
Support of Multi-hop Beacon Enabled Networks (6)

• 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 parents active period.
• Direct communications between sibling nodes are
  problematic if each node only wakes up in its own
  active period and its parents active period.

10
Support of Multi-hop Beacon Enabled Networks (7)

• Approach 2
• Every coordinator selects a contention-free
  time-slot within the Beacon-only-Period to
  transmit its own beacon.

11
Support of Multi-hop Beacon Enabled Networks (8)

• 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 parents
  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.

12
Support of Multi-hop Beacon Enabled Networks (9)

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

13
Support of Multi-hop Beacon Enabled Networks (10)

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