MAC Improvements Proposal - Eaton

1
Project IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs) Submission Title
Eaton Proposal for IEEE 802.15.4
Improvements Date Submitted 5 Nov,
2003 Source Marco Naeve and Jose A.
Gutierrez, Company Eaton Corporation Address
4201 North 27th Street, Milwaukee, WI 53216,
USA Voice414-449-7270, FAX [phone],
E-Mailmarconaeve_at_eaton.com , josegutierrez_at_eaton
.com, Re Meeting minutes from bi-weekly
conference call on 10/03/2003 Abstract This
document proposes improvements to the current
IEEE 802.15.4 MAC sub-layer. Purpose For
discussion within the IEEE 802.15.4 task group on
future work and direction. 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.
2
Eaton Proposal for IEEE 802.15.4 Improvements

• Jose Gutierrez and Marco Naeve

3
Additional PIB table entry needed

• Comment Type Errata
• Comment The MAC requires knowledge about the
  power source of the node for assembling the
  capability information field of the association
  request command. (7.3.1.1.2). The MAC does not
  have any mechanism for getting this information.
• Solution Add an additional attribute to the MAC
  PIB table called macPowerSource

4
Missing status enumeration

• Comment Type Errata
• Comment When performing an active scan, the MAC
  may not be able to send a beacon request commend
  due to a busy channel. However, the MAC can not
  indicate this status in its MLME-SCAN.confirm
  primitive (7.1.11.2.1).
• Solution Add CHANNEL_ACCESS_FAILURE as valid
  status to the MLME-SCAN.confirm primitive.

5
Missing status enumeration

• Comment Type Errata
• Comment When a MAC sub-layer issues a
  PD-DATA.request but the transceiver is already
  busy transmitting, the PD-DATA.confirm need not
  be able to indicate this status.
• Solution Add BUSY_TX as valid status to the
  PD-DATA.confirm primitive.

6
PHY Simplification

• Comment Type Corrigendum
• Proposal To reduce complexity of the PHY layer
  remove
• BUSY_RX,
• BUSY_TX, and
• FORCE_TRX_OFF
• from the PHY enumerations.

7
868 MHz PHY Enhancement

• Comment Type Corrigendum
• Proposal To expand number of channels offered in
  the 868 MHz band according to the new European
  regulations.

8
Remove Parameter from MAC Reset

• Comment Type Corrigendum
• Proposal Remove the SetDefaultPIB parameter from
  the MLME-RESET.request primitive to reduce
  complexity. This parameter specifies if MAC PIB
  tables is reset or not. Purpose of reset is to go
  to a default state why keep PIB values?

9
Beacon Payload

• Comment Type Corrigendum
• Issue Assuming a higher layer attaches
  additional information as payload to the MAC
  beacons, during scans the MAC will interrupt the
  higher layer for each incoming beacon using the
  MLME_BEACON_NOTIFY.indication. MAC and higher
  layer will collect duplicate information.
• Proposal Originally beacon payload intended for
  communicating a Cluster ID. Remove the beacon
  payload from the beacon frame and the PIB table.

10
Association in non-beacon networks

• Comment Type Corrigendum
• Issue The association response frame is sent
  using indirect transmission. Device polls
  coordinator after aResponseWaitTime. Introduces
  significant delay (490ms _at_ 2.4GHz, 768ms _at_
  915MHz, 1.54s _at_ 868MHz) in non-beacon networks.
• Proposal Allow association response frame to be
  sent directly in non-beacon networks.

11
Optional GTS

• Comment Type Corrigendum
• Proposal Support Pat Kinneys proposal to make
  GTS optional.