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 15 Mar,
2004 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 02/09/2004 Abstract This
document proposes improvements to the current
IEEE 802.15.4 MAC sub-layer. Purpose For
discussion within the IEEE 802.15. study group
4b. 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
Content

• Association in non-beacon networks.
• Active scan
• GTS
• Duplicate frame detection
• Missing status enumeration

4
Procedure for associating in beacon networks
Standard requires that association response
command frame is sent indirectly.
5
Procedure for associating in non-beacon networks
Standard requires that association response
command frame is sent indirectly.
6
aResponseWaitTime calculation

• aResponseWaitTime 32 aBaseSuperframeDuration
• aBaseSuperframeDuration aBaseSlotDuration
  aNumSuperframeSlots
• aBaseSlotDuration 60 symbols
• aNumSuperframeSlots 16

30,720 symbols
7
Proposed recommendation
Allow association response frame to be sent
directly in non-beacon networks.(Reduce
complexity)

• Alternatively make aResponseWaitTime a variable
  allowing implementer programmability.

8
Active scan procedure

• Returned status parameter values include
• SUCCESS
• NO_BEACON
• INVALID_PARAMETER

9
Active scan procedure (what if)

• PHY operates in the 868MHz band, or MAC was
  instructed to scan a single channel.
• Beacon request command can not be sent due to
  busy channel.

Add CHANNEL_ACCESS_FAILURE as valid status to the
MLME-SCAN.confirm primitive
10
Guaranteed time slot (GTS) mechanism

• Intended usage HMI, such as mice, keyboard, and
  joystick.
• Pat Kinney proposed to make support for GTS
  optional (see 802.15-03/286r0)
• Eaton supported Pats proposal

11
Industrial applications
Today
Tomorrow

• Event-based monitoring
• Low periodicity monitoring.

• Non-safety critical control
• Time based
• Constant data stream

12
GTS advantages

• Facilitates systems with hard real-time
  requirements.
• Provides a deterministic communication mechanism.
  
• Provides a channel for constant data stream (low
  volume).

Keep GTS but make it optional!
13
Duplicate frame detection

• Function currently not provided by MAC
• Easy to add this feature
• Sequence number already part of frame (MAC frames
  do not need to be changed)

14
Proposed recommendation
Add duplicate frame detection to the MAC
sub-layer.

• Alternatively pass the data sequence number
  (DSN) up to the higher layer for duplicate
  detection.

15
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 to
  be able to indicate this status.
• Solution Add BUSY_TX as valid status to the
  PD-DATA.confirm primitive.

16
PHY Simplification

• Simplify stack implementations on small
  microprocessors.

17
PHY Simplification
Remove BUSY_RX, BUSY_TX, and FORCE_TRX_OFF from
the PHY and instead allow it to be implementation
specific.