Transcript Aug 2001 doc.: IEEE 802.15-01/yyyr0 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE802.15.3: Power Save Proposal. Date Submitted:

Aug 2001
doc.: IEEE 802.15-01/yyyr0
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: IEEE802.15.3: Power Save Proposal.
Date Submitted: 30 July, 2001
Source: Dr. Rajugopal Gubbi
Company: Broadcom, Corp
Address: 400, E-Caribbean Drive, Sunnyvale, CA 95070
Voice: 408-543-3470 , FAX: 408-543-3470 , E-Mail: [email protected]
Re: [ Power save mechanism in TG3-MAC ]
Abstract: This provides an overview of proposed power save mechanism for TG3-MAC.
Purpose: To provide information and solicit comments on proposed power save mechanism
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
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Overview of MAC Power Save Proposal
Submission
Slide 2
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Changes from 292/293r1 to the current
• Made a separate doc with just the
power-save mechanism
• Add traffic indication from PNC in the
Beacon
Submission
Slide 3
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Salient features
• Two possible power save states
– Snooze state for both DEV and PNC:
locally managed
– Sleep state for DEV only: cooperation from
PNC
• Traffic indication in Beacon to allow max
power save when no traffic is pending
for the DEV that is in Sleep state
Submission
Slide 4
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Beacon
Snooze state Operation
Contention Free Period
Contention
Access
Period
Period of Reduced Power Opportunity
• PNC can also use this state
• Stay awake for
–
–
–
–
–
Submission
Beacon
CAP
Broadcast GTS, if allocated
Assigned receive slot
Assigned tx slot with activity
Slide 5
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Sleep state operation
• Sleep state req by DEV, permit/reject by
PNC with indication of max-sleep-time
• Skipped super-frames
• Traffic indication in Beacon for support
of Sleep state and sleep-cycles
• Repeater service for sleep state
• Association timeout
Submission
Slide 6
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Wake to beacon –
no traffic
Indicated
Wake to beacon at the end of
sleep-cycle Traffic Indicated
Indicate active state
Receive/ack data
Submission
Beacon
Beacon
Beacon
Sleep state Operation – skipped
superframes
PNC Generated Superframes
Slide 7
Contention Free Period
Opportunity to reenter EPS
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Beacon Content for Support of Sleep
State
1 Octet
Element ID
1 Octet
2 Octets
2 Octets
TIB
TIB
Length = (n*2)
Power save information element
1 Octet
1 Octet
Start Device Address
Traffic Indication
Traffic indication block (TIB)
•
Power-save information element (new)
– each DEV in sleep state need at-most ONE bit information and that too if
there is traffic pending for them
– PNC creates a traffic indication blocks (TIB)
•
PNC does NOT send data unless the DEV has indicated the “Activestate”
PNC can buffer even the MCAST and BCAST data for the sleeping
DEV
•
Submission
Slide 8
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Association Timeout Operation
• Based on aAssociationTimeoutPeriod parameter
(7.3.5 in 0.4 draft).
• Communicated to PNC by all devices during
association
• DEVs must choose sleep times shorter than
association timeout
• If active state indication is not received by the PNC
before this timeout, the DEV will be disassociated by
the PNC
• Applies to ALL DEVs
Submission
Slide 9
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Repeater Considerations
• Use repeater in normal manner as piconet
coverage enhancer.
• Add use of repeater as part of support to
Sleep state
• Either the sender or the dest-DEV can
request the repeater service
Submission
Slide 10
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Operation over multiple super frames
Sleep State Request
ACK at end of SIFS
Sleep State Permit
ACK at end of SIFS
Submission
CFP
Wakeup, rx beacon
No traffic indication
or zero traffic pending
Slide 11
CAP
Receive frames
Beacon
CAP
CFP
Sleep-cycle of
multiple super-frames
Beacon
CAP
Beacon
Sleep-cycle of
multiple super-frames
CFP
Wakeup, rx beacon
traffic pending
Active State Indication
ACK at end of SIFS
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Need for Sleep-state request and
permission commands
• Without the indication from the DEV that it is going into or coming
out of sleep state
– The slot allocations for the Sleep-state DEV must always be made even
when it is asleep
– The DEV must wakeup for every beacon (no deep sleep or skipping
multiple superframes). If not, the PNC might indicate “traffic pending”
when the dev is asleep and the tx of frames in that frames will be lost.
This causes the retry limit on the frames to be reached faster. Worse,
MCAST/BCAST and frames with no response will be lost forever.
Missed beacons at the DEV also cause the same problem.
– With the command exchange the DEV can wakeup near the end of this
time and hence saving more power than the case of waking up every
Beacon and still be assured the frames are not lost because it was
asleep.
– As a modification to the proposal, the sleep-state response from PNC
can be made as an imm-response to the sleep-state-request command.
Submission
Slide 12
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Need for repeater service and traffic
indication in Beacon
• Sender need not keep track of frames sent v/s the indicated
traffic state
• PNC has to do this anyway for one or the other reason in both
the proposals
• Traffic indication, needs one bit (best case) in this proposal
where it needs two bytes in the proposal in 262r0. Hence the
best case overhead in this proposal is nearly 8-times better.
• No need for sender-PNC communication on traffic indication
• Hence no concern of sync issues between what is indicated in
the Beacon and what goes on in the slot.
Submission
Slide 13
<Dr. Rajugopal Gubbi> <Broadcom>
Aug 2001
doc.: IEEE 802.15-01/yyyr0
Conclusions
• Emphasis on lowest power use for “no op” wake cycles.
• Beacon provides
– traffic indication necessary for low power operation during
no-traffic states
• MCAST/BCAST are also handled
• No sync issues between the PNC, sender and the receiver
• Direct data transfer between the Sender and receiver is possible
by extending the sleep/active state indications to the sender
from the rx-dev
• PNC provides repeater service
Submission
Slide 14
<Dr. Rajugopal Gubbi> <Broadcom>