January 2003 doc.: IEEE 802.15-03/037r0 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:[[email protected]]

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.

Submission Slide 1 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

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.

Submission Slide 2 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

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.

Submission Slide 3 Ed Callaway, Motorola

January 2003

Market Penetration

doc.: IEEE 802.15-03/037r0

• 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!

Submission Slide 4 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

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.

Submission Slide 5 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

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.

Submission Slide 6 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

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.

Submission Slide 7 Ed Callaway, Motorola

January 2003 Beaconing Device

Submission

doc.: IEEE 802.15-03/037r0

Battery Life Extension

2560 us 160 symbols 80 octets First Five Full Backoff Periods after the Beacon IFS period Backoff Period Backoff Period Minimum Beacon Backoff Period Backoff Period Backoff Period Backoff Period Backoff Period Listen Interval (when no frame detected) Backoff Period SIFS 576 us 36 symbols 18 octets 1792 us 112 symbols 56 octets Transmit Frame

Always at least three backoff periods available to start transmission

Transmit Frame Transmit Frame Slide 8 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

Resulting Duty Cycle Improvement

Coordinator Transceiver Activity Ratio with Superframe Order = 0

Without battery life extension

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

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

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.

Submission Slide 9

6x reduction!

(for SO=0, better for higher SO) Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

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) Submission Slide 10 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

Detail 1

1.

2.

3.

(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.

Submission Slide 11 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

Detail 2

4.

5.

(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.

Submission Slide 12 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

Detail 3

6.

Submission (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.” Slide 13 Ed Callaway, Motorola

January 2003 doc.: IEEE 802.15-03/037r0

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.

Submission Slide 14 Ed Callaway, Motorola