1 / 14

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG4 Battery Life Ext

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG4 Battery Life Extension] Date Submitted: [13 January 2003] Source: [Ed Callaway] Company: [Motorola] Address: [8000 W. Sunrise Blvd, Plantation, Florida, 33322, USA]

emily
Télécharger la présentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG4 Battery Life Ext

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 P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG4 Battery Life Extension] Date Submitted: [13 January 2003] Source: [Ed Callaway] Company: [Motorola] Address: [8000 W. Sunrise Blvd, Plantation, Florida, 33322, USA] Voice:[+1 954 723 8341], FAX: [+ 1 954 723 3712], E-Mail:[ed.callaway@motorola.com] Re: [ IEEE 802.15.4 draft 18 ] Abstract: [This contribution describes a method by which the battery life of beaconing TG4 devices may be greatly extended.] Purpose: [To encourage discussion.] 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. Ed Callaway, Motorola

  2. Beaconing Device Duty Cycle • In draft 18, when the beacon order BO=0 (15.36 ms beacon interval), the coordinator’s transceiver must be continuously active. • This is because the superframe order SO ≤ BO. • For other beacon orders, the minimum transceiver active time including the beacon is a power of 2 multiple of 15.36 ms. Ed Callaway, Motorola

  3. CAP Length • For most application scenarios, this is far more time than needed to perform the CSMA-CA algorithm—there is simply not that much channel activity. • Even if the system were “spoofed” with fake GTS, the minimum CAP is still 420 symbols (6.72 ms), to enable a complete message transfer before the first GTS. Ed Callaway, Motorola

  4. Market Penetration • Having a constantly-active receiver effectively precludes 15.4 from entering any application space that requires a low latency, battery-powered, beaconing device. • For these applications, Bluetooth has lower power consumption—and lower latency! Ed Callaway, Motorola

  5. What to do? • For TG4’s low data throughput applications, the contention access period (CAP) may be shortened with minimal effect on network performance—especially in networks of low beacon order. • This should be optional, to protect the existing CAP for higher throughput applications. Ed Callaway, Motorola

  6. What to do? • The real requirement is for more than 420 symbols of unassigned time prior to the first GTS to allow space for a maximum sized PSDU and associated ACK. If this requirement is met, the CAP may be shortened to below 420 symbols, enabling the receiver to sleep before the first GTS—or the next beacon. Ed Callaway, Motorola

  7. What to do? • One of two reserved bits in the beacon superframe specification field may be defined as the “battery life extension” field. When set, it limits the CAP such that a device has at least 5 backoff slots in which to do the 2 CCA’s and initiate a transmission. When cleared, the CAP is as defined in D18. Ed Callaway, Motorola

  8. Battery Life Extension Ed Callaway, Motorola

  9. Coordinator Transceiver Activity Ratio with Superframe Order = 0 BO 0 BO 1 BO 2 BO 3 BO 4 BO 5 BO 6 BO 7 BO 8 BO 9 BO 10 BO 11 BO 12 BO 13 BO 14 Without battery life extension 1.0000 0.5000 0.2500 0.1250 0.0625 0.0313 0.0156 0.0078 0.0039 0.0020 0.0010 0.0005 0.0002 0.0001 6E-05 With battery life extension 0.1667 0.0833 0.0417 0.0208 0.0104 0.0052 0.0026 0.0013 0.0007 0.0003 0.0002 8E-05 4E-05 2E-05 1E-05 Resulting Duty Cycle Improvement • ASSUMPTIONS: • The beacon is the minimum size (36 symbols @ 2.4 GHz PHY). • The idle time between the beacon and the first full backoff period is considered an active period (conservative estimate). • Without the battery life extension, the coordinator must be active (listening or transmitting) during the entire 15.36 ms minimum superframe. • With the battery life extension, the coordinator goes inactive (stops listening to the channel) if a Frame Start Delimiter is not detected in the fifth full backoff period after the beacon’s IFS period. 6x reduction! (for SO=0, better for higher SO) Ed Callaway, Motorola

  10. Things that would change in D17 • (7.1.14.1.1 Semantics of the [MLME-START.request] service primitive) • (7.1.14.1.3 Effect on receipt) • (Table 55—MLME-START.request parameters) • (7.2.2.1.2 Superframe specification field) • (Figure 37—Format of the superframe specification field) • (7.5.1.3 The CSMA-CA algorithm) • (Table 70—MAC PIB attributes) Ed Callaway, Motorola

  11. Detail 1 • (7.1.14.1.1 Semantics of the [MLME-START.request] service primitive) Add the parameter “BatteryLifeExtension” to the MLME-START.request primitive. • (7.1.14.1.3 Effect on receipt) Add the following after p. 95, l. 45: “The MLME shall set macBattLifeExt to the value of the BatteryLifeExtension parameter.” • (Table 55—MLME-START.request parameters) Add a row: Name: BatteryLifeExtension. Type: Boolean. Valid Range: TRUE or FALSE. Description: If this value is TRUE, the receiver of the beaconing device is disabled if a frame start delimiter is not detected by the third full backoff period of the CAP. If this value is FALSE, the receiver of the beaconing device remains enabled for the entire CAP. Ed Callaway, Motorola

  12. Detail 2 • (7.2.2.1.2 Superframe specification field) p. 112, l. 32: Strike “(receiver enabled)”. Following l. 40, add “The battery life extension field is one bit in length and shall be set to 1 if frames transmitted to the beaconing device during the CAP must start in or before the fifth full backoff period following the beacon and its IFS. Otherwise the battery life extension field shall be set to 0.” • (Figure 37—Format of the superframe specification field) Define bit 12 of the superframe specification field to be the “battery life extension” field. Ed Callaway, Motorola

  13. Detail 3 6. (7.5.1.3 The CSMA algorithm) Change line 35 to read, “In a slotted CSMA-CA system with the battery life extension field set to 0, …” Insert the following after line 45: “In a slotted CSMA-CA system with the battery life extension field set to 1, the MAC sublayer shall ensure that, after the random backoff, the remaining CSMA-CA operations can be undertaken and the entire transaction can be transmitted before the end of the CAP. The backoff countdown shall only occur during the first five full backoff periods after the end of the beacon’s IFS period. The MAC sublayer shall proceed if the remaining CSMA-CA algorithm steps (two CCA analyses), the frame transmission and any acknowledgement can be completed before the end of the CAP, and the frame transmission will start in or before the first five full backoff periods after the end of the beacon’s IFS period. If the MAC sublayer can proceed, it shall request that the PHY perform the CCA in the current superframe. If the MAC sublayer cannot proceed, it shall wait until the start of the CAP in the next superframe and repeat the evaluation.” Ed Callaway, Motorola

  14. Detail 4 7. (Table 70—MAC PIB attributes) Add a row: Attribute: macBattLifeExt. Identifier: [as required]. Type: Boolean. Range: TRUE or FALSE. Description: This parameter indicates whether battery life extension, by reduction of coordinator receiver operation time during the CAP, is enabled. A value of TRUE indicates that it is enabled. Default: FALSE. Ed Callaway, Motorola

More Related