1 / 27

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ EPS Talking Points ] Date Submitted: [ 23 January, 2002 ] Source: [ Mark E. Schrader ] Company [ Eastman Kodak Co. ] Address [ 1447 Saint Paul St., Rochester, NY, 14653-70223, USA ]

hamish
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

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: [EPS Talking Points] Date Submitted: [23 January, 2002] Source: [Mark E. Schrader] Company [Eastman Kodak Co.] Address [1447 Saint Paul St., Rochester, NY, 14653-70223, USA] Voice:[585-253-5241], FAX: [585-726-5658], E-Mail:[mark.e.schrader@kodak.com] Re: [PM Discussion Illustrating the Points.] [If this is a response to a Call for Contributions, cite the name and date of the Call for Contributions to which this document responds, as well as the relevant item number in the Call for Contributions.] [Note: Contributions that are not responsive to this section of the template, and contributions which do not address the topic under which they are submitted, may be refused or consigned to the “General Contributions” area.] Abstract: [Illustrations and Summary Points and PM Architecture Compromise] Purpose: [Show functionality and PNC implementation and addition of asynchronous sleep capability.] 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. NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriate fields. All Blue fields are informational and are to be deleted. Black stays. After updating delete this box/paragraph. Mark E. Schrader, Eastman Kodak>

  2. Overview • EPS Criteria • D09 EPS Operation • Compromise Proposal Mark E. Schrader, Eastman Kodak>

  3. In the course of discussing power management in the MAC conference calls, various members suggested criteria for evaluating proposed PM methods that would make for a superior standard, while being consistent with this committee’s overall 802.15.3 requirements. The following is an unofficial list of the criteria that came out of the MAC conference calls. Mark E. Schrader, Eastman Kodak>

  4. Primary Power Save Requirements • Allow power sensitive DEVs to save power or sleep as much as possible, not park etc. • Primary requirement: A DEV shall be allowed to not listen for multiple superframes, and then listen only to a beacon unless the CTAs in that beacon tell the DEV to listen to a time slot. This sequence repeated over and over is defined as “sleep mode” (or extended power save, EPS, mode). • The PM scheme shall not decrease the PNCs doze time significantly. • The PM scheme shall require minimal DEV interaction with the PNC when in sleep mode. Mark E. Schrader, Eastman Kodak>

  5. Synchronization Criteria • Synchronization is supported and not required by a station setting up its sleep mode. • We shall support three or more DEVs communicating with each other while in sleep mode. • A new DEV may join and communicate synchronously with other sleep mode devices. • Or a device may choose its own sleep mode parameters rather than synchronizing to an existing sleep mode. Mark E. Schrader, Eastman Kodak>

  6. Cost and Performance Criteria • The PM method shall not significantly impact the cost, complexity, and performance of the MAC. • The PM method shall not degrade the performance of the piconet. • By example: If N devices each want a time one slot in every 30 superframes, the PNC shall be capable of not overloading a single superframe with all N time slots in fulfilling that request. • High rate devices shall operate in the presence of sleep mode devices without being impacted. Mark E. Schrader, Eastman Kodak>

  7. Burst Criteria • Transitions from sleep to “full power mode” shall be fast, and vice versa. • Fast means within the time required for the PNC to respond to one command to the PNC. • “full power mode” is with all CTA slots restored and sending data as before sleep mode. • This enables burst data from power sensitive devices (e.g. remotely operated cameras with motion detection capability) to start quickly. Mark E. Schrader, Eastman Kodak>

  8. Flexibility Criteria • Devices shall be able to save power individually. “I am going into sleep mode!” • Devices shall be able to save power synchronously as a group. “We are going into sleep mode now.” (“...because I know best, and you gave me the authority switch your mode”). • Devices in sleep mode shall be able to only listen to beacons and have no time slots, or send the occasionalpacket of data. Mark E. Schrader, Eastman Kodak>

  9. The current method fulfills all of the previous criteria and functionality. It is designed to meet the very high expectations of the MAC subcommittee and this standards body -- to manage power both very effectively and very efficiently. Mark E. Schrader, Eastman Kodak>

  10. How It Works and Why It Works This Way Mark E. Schrader, Eastman Kodak>

  11. Channel Time Allocations • A stream is initiated with QoS parameters that are mapped one-to-one to equivalent channel time request, CTRB fields. • Each stream connection request or channel time request that is accepted by the PNC, results in at least one channel time allocation, CTA owned by the DEV that “originates” that stream connection Mark E. Schrader, Eastman Kodak>

  12. Allocation Types • There are two types of streams/CTAs, that can be originated by a DEV, an ACTIVE stream/CTA or an EPS stream/CTA. • The PNC switches between CTA types when the DEV, that originated the stream, switches modes. • The following figure shows the relationship between CTA types and PM modes. Mark E. Schrader, Eastman Kodak>

  13. Switching Between Extended Power Save and ACTIVE Modes Mark E. Schrader, Eastman Kodak>

  14. Why not just ask for new CTAs? • Normal (ACTIVE) CTA’s have timing parameters that can be used by only one stream. • Suppose that an EPS mode DEV A sleeps 6 superframes, and then has one slot, and repeats this pattern. • It is impossible for DEV B to tell the PNC that it wants to sleep and communicate in phase with DEV A using a standard (ACTIVE) channel time request. Mark E. Schrader, Eastman Kodak>

  15. A Low Complexity Solution • The EPS Set is equivalent to a shared version of the Allocation Period part of the channel time request. • The DEV now can say “I request the same timing as the other members of the EPS Set” • It is no more difficult for the PNC then asking it for two independent channel time allocations, both with unrelated parameters. • The slot width and jitter are private in both cases and computed from the CTRB parameters. Mark E. Schrader, Eastman Kodak>

  16. An abbreviation used in this document: AP is defined as the Allocation Period field of the Channel Time Request Block used by the PNC to create CTA elements in the beacon. Mark E. Schrader, Eastman Kodak>

  17. CTRB CTRB How CTAs are Specified in ACTIVE Mode & EPS Mode AP EPS Set N AP slot allocation period slot allocation period ACTIVE CTA EPS CTA AP = Allocation Period field of CTRB of the Channel Time Request Command Mark E. Schrader, Eastman Kodak>

  18. CTRB Yes but what about the AP in EPS mode? EPS Set N AP slot allocation period ?! EPS CTA Claim: The Allocation Period field in the CTRB (AP) enables critical EPS functionality with minimal PNC overhead. Mark E. Schrader, Eastman Kodak>

  19. Definition of AP Field in EPS Mode • The AP specifies how many slot allocation periods (specified by the EPS Set) to count before putting in the specified non-zero channel time allocation. • This is not hard for a PNC to do. It is one counter function per EPS CTA. It can be done in firmware. • Whenever the AP value is 1, the specified time slot is always used as in ACTIVE mode Mark E. Schrader, Eastman Kodak>

  20. The EPS AP Reduces PNC Overhead. • Example: 25 PDAs to communicate • Each PDA asks for a source slot at a rate of 1 per every 12 SFs. The EPS Set used was set to a period of 3 superframes. Thus, AP = 4 will give 1 slot per 12 superframes. • The PNC will distribute the 25+ slot requests among 4 possible superframes randomly -- no superframe overloading and very small PNC overhead compared with any alternative method. • All PDAs can sleep 2 superframes at a time. • Any PDA will be able to have a stream to any other PDA at this rate. Mark E. Schrader, Eastman Kodak>

  21. EPS AP Continued • By using the same EPS Set and AP value, the PNC overhead is minimized. • In a large piconet situation where each device of the type PDA the PNC might restrict the value of AP and what EPS set it would use by the PNC rather than each device being able to select arbitrary timing parameters. • The PNC burden for this synchronized network with power save is less than a non-synchronized network without power save. Mark E. Schrader, Eastman Kodak>

  22. EPS AP for Very Long Slot Periods • Applications requiring very long times between EPS slot allocations may require the DEV to just listen to some intermediate beacons. This allows it to receive momentary data and management commands from the PNC. • The EPS allocation period in the CTRB is all that is required to implement this function. Mark E. Schrader, Eastman Kodak>

  23. Controlling Complexity and Performance Mark E. Schrader, Eastman Kodak>

  24. Add number of EPS Sets supported by PNC to capabilities list. • Add min and max delay to switch modes to PNC capabilities. • Assign MTS slots in EPS mode consistent with max delay-to-switch-modes capability of PNC. • Combine the three “switch” commands to one command with one or two parameters. • Change dual use CTRB field to two fields. Mark E. Schrader, Eastman Kodak>

  25. Power Management Architecture Compromise Mark E. Schrader, Eastman Kodak>

  26. Compromise • CTA elements indicate channel time only and are absent if no channel time in allocated • Traffic pending indicator in the beacon. • Beacon indication of DEV’s in EPS mode using an EPS set. This is absent for DEVs not in EPS mode. • Ability of a DEV to sleep and wake up as proposed by Raju. • A single beacon entry for EPS Next for each EPS Set that is in use. Mark E. Schrader, Eastman Kodak>

  27. Compromise Continued • For PNC capable DEV’s • Support 1 EPS Set minimum if Des mode bit not set • Support 4 EPS Set minimum if AC powered. • Add “EPS Sets supported” to PNC capabilities table. Mark E. Schrader, Eastman Kodak>

More Related