IEEE P802.15 Working Group for Wireless Personal Area Networks by ICJ1H4Zm

VIEWS: 0 PAGES: 10

									   Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs)
      May 2004                                                                  doc.:15-04-0460-00-004b
Submission Title: [Proposals for 802.15.4 MAC Issues]

Date Submitted: [07Sep2004]

Source: [Phil Beecher] Company [CompXs Ltd]
Address [Robert Denholm House, Bletchingley Road, Nutfield, RH1 4HW, UK]
Voice:[+44 1737 822509], E-Mail: [pbeecher@compxs.com]
Re: [15-04-0234-nn-4b]
Abstract: [Summary proposals for 802.15.4 Issues]
Purpose: [To focus resolutions for 802.15.4 MAC Issues.]
Notice: This document has been prepared to assist the IEEE 802.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 802.15.




      Submission                                    Slide 1                          Phil Beecher, CompXs Ltd
May 2004                             doc.:15-04-0460-00-004b



  Issue 7, 95 - macTransactionPersistenceTime

 • Problem - macTransactionPersistenceTime is
   undefined for non-beacon enabled PANs
 • Proposal - Redefine the units for
   macTransactionPersistenceTime to be
   aBaseSuperframeDuration for non-beacon
   enabled PANs. N.B. for beacon enabled PANs
   macTransactionPersistenceTime will be the
   maximum number of beacons in which the
   message is pended.

Submission             Slide 2           Phil Beecher, CompXs Ltd
May 2004                                        doc.:15-04-0460-00-004b


         Issue 41,49 – Disassociation request by
                       coordinator
 • Problem – Currently a disassociation request always uses
   the extended address for the destination address. This is
   impractical for non-beacon enabled PANs as devices use
   their short addresses to poll.
 • Proposal – Allow the disassociation request to be issued to
   either a short destination address or extended address. The
   MLME-DISASSOCIATE.request primitive parameter list
   must be amended to include the addressing mode. It is
   suggested that it also include the PANID for consistency
   with other primitives.



Submission                    Slide 3               Phil Beecher, CompXs Ltd
May 2004                                  doc.:15-04-0460-00-004b



             Issues 53, 66 – ACK timing

 • Problem – Currently (in beacon-enabled PANs)
   ACKs must be transmitted on 20 symbol slot
   boundaries. However, clock drift means that an
   ACK could be transmitted up to 20 symbols late
   i.e. on the next slot boundary.
 • Proposal – Specify that ACK transmission may
   start from 12 symbols after receipt of packet, up to
   next 20 symbol boundary (for backward
   compatibility).

Submission                Slide 4             Phil Beecher, CompXs Ltd
May 2004                                 doc.:15-04-0460-00-004b



   Issue 57 – Data Request to PAN coordinator

 • Problem - MAC layer cannot know in the general
   case whether the packet is targeted to a PAN
   coordinator or a coordinator.
 • Proposal - For data requests, specification should
   be updated to replace “shall” with "may" from
   section 7.3.2.1.1 relating to presence of source
   address for packets targeted to the PAN
   coordinator.


Submission                Slide 5            Phil Beecher, CompXs Ltd
May 2004                                doc.:15-04-0460-00-004b


   Issue 104 – Disassociating Multiple Devices
                by the coordinator
 • Problem - If more than 1 device is being
   disassociated simultaneously, there is no way for
   the upper layer to know which device is being
   indicated by the MLME-
   DISASSOCATE.confirm, since the primitive does
   not contain the device address.
 • Proposal - Add a new parameter, DeviceAddress,
   to the MLME-DISASSOCIATE.confirm
   primitive.

Submission               Slide 6            Phil Beecher, CompXs Ltd
May 2004                                   doc.:15-04-0460-00-004b


             Issue 63, ??- Broadcasts in Beaconing
                            networks
 • Problem: There is no method for sending
   broadcast messages to devices with
   macRxInWhenIdle set FALSE.
 • Proposal: For beacon-enabled PANs, set
   the frame pending bit in the beacon, then
   transmit (using CCA) the broadcast
   message immediately after the beacon.

Submission                    Slide 7          Phil Beecher, CompXs Ltd
May 2004                             doc.:15-04-0460-00-004b


  Issue 35- Coordinator realignment to indicate
                beacon change
 • Problem: Coordinator realignment message
   following MLME-START.request will not
   be received by sleeping devices.
 • Proposal: Use the proposal in the former
   slide to transmit the coordinator realignment
   after the next beacon.



Submission             Slide 8           Phil Beecher, CompXs Ltd
May 2004                                doc.:15-04-0460-00-004b



             Issue 38 - Promiscuous Mode
 • Problem – Spec does not define behaviour of
   MAC or how to indicate to next higher layer
 • Proposal - Send the entire PSDU to the next
   higher layer using MCPS-DATA.indication
   primitive, where the received PSDU is included as
   the MSDU parameter. In order to identify that this
   MCPS-DATA.indication primitive contains an un-
   filtered PSDU the DstAddrMode and
   SrcAddrMode fields are both set to 0x00 (No
   Address). The mpduLinkQuality field should be
   valid.

Submission               Slide 9            Phil Beecher, CompXs Ltd
May 2004                             doc.:15-04-0460-00-004b



             Issues ?? Optional Features

 • Problem – Current FFD and RFD
   definitions are too restrictive.
 • Proposal – modify PICS to allow optional
   features which are currently mandatory.




Submission               Slide 10        Phil Beecher, CompXs Ltd

								
To top