Transcript Aug 2001 doc.: IEEE 802.15-01/384r2 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/384r2
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 and Dr. Bill Shvodian
Company: Broadcom, Corp. and XtremeSpectrum, Inc.
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 for comment resolution of LB12
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/384r2
Simplification of EPS Mechanism for
802.15.3 MAC
Submission
Slide 2
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
Background
• 802.15.3 has two possible power save
mechanisms
– Reduced power save (RPS) mechanisms
for both DEV and PNC: locally managed.
NO change proposed for this mechanism
– Extended power save (EPS) mechanism
for multi-superframe long sleep
• Traffic indication in Beacon to allow max
power save when no traffic is pending
for the DEV that is in EPS state
Submission
Slide 3
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
EPS operation (1)
• EPS state req by DEV, permit/reject by PNC with
indication of max-sleep-time
• If permitted, the DEV can go to sleep only at the end of
current superframe
• If permitted to sleep, DEV can sleep through multiple
super-frames
• Traffic indication in Beacon, allows DEVs to either
request new Sleep time or remain awake
• Optional Repeater service during sleep
• max-sleep time is smaller than Association timeout
• PNC does NOT allocate GTS unless both the tx and rx
DEVs of that GTS are known to be awake
Submission
Slide 4
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
EPS Operation (2)
Beacon
Beacon
PNC Generated Superframes
Wakeup at the end of sleep-time. Wait for beacon
if traffic Indicated, wait for traffic using RPS
else, request new sleep time
DEVs may Wake to beacon during sleep-time to
check for traffic indication.
DEVs shall inform PNC that they are awake by
sending any frame (incl. Command frame with
no payload) directed to PNC
Submission
Slide 5
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
TIM element in Beacon
1 Octet
Element ID
•
•
•
•
•
•
•
•
1 Octet
Length =
(2 to 33)
1 Octet
1-32 Octets
Start Device Address Traffic Indication Map (TIM)
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 map based on the GTS-requests received
Bit-pos corresponding to AD-AD of 0xFF is used for BC traffic indication
Bit-pos corresponding to AD-AD of 0xFD is used for MC traffic indication
Bits corresponding to reserved AD-AD values shall be set to zero upon tx and
ignored upon rx
If this element is not present in the beacon, it shall be interpreted as all the
DEVs being awake in the current superframe.
On the other hand if this element is present, then the DEVs indicated in the TIM
are currently asleep. In the case of AD-AD of 0xFF and oxFD being set, it shall
be interpreted as atleast one DEV in the piconet being asleep during the current
superframe.
If PNC does not have any pending GTSs or BC/MC traffic but it knows that
atleast one DEV is asleep, this element shall be sent in beacon with TIM of
zeros.
Submission
Slide 6
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
TIM construction at PNC
• When a GTS is ongoing, the dest-DEV can detect no
traffic coming in and hence request to go to EPS
state. When PNC permits it, the PNC shall remove
the GTS allocated with the current DEV as rx-DEV.
• A new GTS-request from a src-DEV at PNC results in
the TIM-bit corresponding to the dest-DEV to be set
in the beacon
• If src-DEV enters EPS state, all the pending GTSrequest from that DEV are cancelled and hence the
TIM-bits corresponding to those GTS-requests. When
the DEV comes out of sleep state it has to send new
request for GTS.
Submission
Slide 7
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
BC/MC traffic management (1)
• DEV: When a src-DEV has BC/MC traffic to send it
has two options (a) the src-DEV can see the
presence of Tim-element in beacon and defer the
transmission of BC/MC traffic or (b) simply request
repeater request for BC/MC traffic
• PNC: PNC shall indicate BC/MC traffic pending in
beacon is there is a pending GTS-request for BC/MC
traffic or a pending BC/MC frame at PNC. Under
such conditions, PNC shall issue new sleeppermission to any requesting DEV to be smaller (or
equal) than the max of remaining sleep times of all
the currently sleeping DEVs
Submission
Slide 8
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
BC/MC traffic management (2)
Beacon
Beacon
PNC Generated Superframes
GTSs for BC/MC
allocated
Different DEVs ending sleep-time
Max remaining sleep time
Max permitted sleep time
BC/MC traffic indicated in beacon
Submission
New request
Slide 9
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
Optional 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
• DEVs can request and avail repeater service
only when they are entering sleep state.
When they are awake they can simply cancel
the repeater service for direct communication
Submission
Slide 10
Dr. Rajugopal Gubbi, Broadcom
Aug 2001
doc.: IEEE 802.15-01/384r2
Conclusions
• Emphasis on lowest power use for “no op” wake cycles.
• Emphasis on simple EPS mechanism
• 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
Submission
Slide 11
Dr. Rajugopal Gubbi, Broadcom