1 / 10

Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposals for 802.15.

Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs) 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]

jemima
Télécharger la présentation

Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposals for 802.15.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE 802.15 Working Group for Wireless Personal Area Networks (WPANs) 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. Phil Beecher, CompXs Ltd

  2. 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. Phil Beecher, CompXs Ltd

  3. 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. Phil Beecher, CompXs Ltd

  4. 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). Phil Beecher, CompXs Ltd

  5. 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. Phil Beecher, CompXs Ltd

  6. 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. Phil Beecher, CompXs Ltd

  7. 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. Phil Beecher, CompXs Ltd

  8. 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. Phil Beecher, CompXs Ltd

  9. 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. Phil Beecher, CompXs Ltd

  10. Issues ?? Optional Features • Problem – Current FFD and RFD definitions are too restrictive. • Proposal – modify PICS to allow optional features which are currently mandatory. Phil Beecher, CompXs Ltd

More Related