21 07 333 00 0000 IEEE 802 21

  • Slides: 17
Download presentation
21 -07 -333 -00 -0000 IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: 21 -07

21 -07 -333 -00 -0000 IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: 21 -07 -333 -00 -0000 Title: 802. 11 TGv Power Management Features Date Submitted: September 18, 2007, Presented at IEEE 802. 21 session #22, Big Island Authors or Source(s): Allan Thomson (Cisco) and Emily Qi (Intel) Abstract: This document provides an overview of the power saving enhancement features proposed in 802. 11 TGv D 1. 0 12/16/2021 1

21 -07 -333 -00 -0000 IEEE 802. 21 presentation release statements This document has

21 -07 -333 -00 -0000 IEEE 802. 21 presentation release statements This document has been prepared to assist the IEEE 802. 21 Working Group. 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. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802. 21. The contributor is familiar with IEEE patent policy, as outlined in Section 6. 3 of the IEEESA Standards Board Operations Manual <http: //standards. ieee. org/guides/opman/sect 6. html#6. 3> and in Understanding Patent Issues During IEEE Standards Development http: //standards. ieee. org/board/pat/guide. html> 12/16/2021 2

21 -07 -333 -00 -0000 802. 11 TGv Power Saving Objective • Req[2010] TGv

21 -07 -333 -00 -0000 802. 11 TGv Power Saving Objective • Req[2010] TGv shall support a “long term” Power Saving management feature; to optimize a STA’s power consumption during prolonged time periods of no transmission or reception activity in the order of several hundred’s of ms’s or above. 12/16/2021 3

21 -07 -333 -00 -0000 Power Saving Features in TGv • • Traffic Filter

21 -07 -333 -00 -0000 Power Saving Features in TGv • • Traffic Filter Service and Sleep Mode BSS Max Idle Timeout FBMS and Proxy ARP TIM Broadcast 12/16/2021 4

21 -07 -333 -00 -0000 Traffic Filter Service and Sleep Mode • Issues and

21 -07 -333 -00 -0000 Traffic Filter Service and Sleep Mode • Issues and motivation – Mobile clients need to be awake to receive unwanted traffic – Mobile clients need to be awake for security state update • Solutions: – AP Traffic Filtering Service (TFS): allow general pattern matches on trigger frames for traffic delivery – Sleep Mode: allow mobile client stay in low power state until a traffic filter is triggered • TFS and Sleep mode can be used independently 12/16/2021 5

21 -07 -333 -00 -0000 TFS Protocol • • • AP advertises support for

21 -07 -333 -00 -0000 TFS Protocol • • • AP advertises support for TFS in Wireless Network Management Capabilities IE AP/Client negotiates TFS via TFS (Sleep Mode, or Re-association) Request and Response frames – Client can add traffic filters any time after association (non-RSN) or key establishment (RSN); Client can delete filters at any time – AP may delete filters if it executes the filter action (e. g. wakeup) AP Operations – AP inspects unicast and multicast traffic on behalf of client which installed filter. – AP discards unmatched unicast traffic regardless of power states when TFS is enabled – TFS Notify frame is delivered before the triggering frame if requested by the client 12/16/2021 6

21 -07 -333 -00 -0000 Sleep Mode Protocol • • • AP advertises support

21 -07 -333 -00 -0000 Sleep Mode Protocol • • • AP advertises support for Sleep Mode in Wireless Network Management Capabilities IE AP advertise GTK/IGTK update policy in RSN IE in beacons, probe responses and 4 WHS – GTK/IGTK may or may not be updated by AP when client in Sleep Mode AP/Client negotiate Sleep Mode operation via Sleep Mode (or Reassociation) Request and Response frames – AP/STA may include TFS Request/Response IE in Sleep Mode Request/Response frames to set up traffic filtering pattern for the sleep mode client – TFS Notify or Triggering frame delivered using standard TIMbased PS operation while client is in Sleep Mode 12/16/2021 7

21 -07 -333 -00 -0000 Sleep Mode with TFS Procedure - Example Client Beacon

21 -07 -333 -00 -0000 Sleep Mode with TFS Procedure - Example Client Beacon {RSN IE (Capabilties. SM-GTKU-Policy), WNM capabilities IE (TFS bit, Sleep Mode bit)} Sleep Mode Request {Sleep Mode IE (enter), TFS Request IEs} Client enters Sleep Mode Response {Sleep Mode IE (enter), TFS Response IEs} § § § Beacons {the corresponding TIM bit is set} Beacons (the corresponding TIM bit is set) PS-Poll TFS Notify {TFS ID} if required AP AP sets up traffic filter, group key update policy, and maintains association states for the sleep mode client Frame 1 Frame n Trigger frame (matched with filter pattern) Traffic is matched with filter pattern, AP to wake up Sleep Mode client. Trigger frame Client exits Sleep Mode 12/16/2021 Sleep Mode Request {Sleep Mode IE (exit sleep mode)} Sleep Mode Response {Sleep Mode IE (exit sleep mode)} § § § GTK/IGTK update messages if required 8

21 -07 -333 -00 -0000 BSS Max Idle Timeout - Motivation • Goal –

21 -07 -333 -00 -0000 BSS Max Idle Timeout - Motivation • Goal – All STA to stay asleep longer without having to wake to remain associated • Problem – Clients may go to sleep while associated to an AP – Clients have no way of knowing how long they are allowed to remain asleep before AP disassociates the Client – Effect: Clients can not maximize sleep time while remaining associated 12/16/2021 9

21 -07 -333 -00 -0000 BSS Max Idle Timeout - Solution • How it

21 -07 -333 -00 -0000 BSS Max Idle Timeout - Solution • How it works… – Mechanism for AP to advertise max idle time period – STA must send keep-alive before idle time period expires to reset the AP’s idle timer for the STA • Sent in (re) association responses • Two fields – Max Idle Period – Idle Options: protected frame, or not protected frame for notification 12/16/2021 10

21 -07 -333 -00 -0000 Flexible Broadcast/Multicast Service (FBMS) • Motivation – Increase the

21 -07 -333 -00 -0000 Flexible Broadcast/Multicast Service (FBMS) • Motivation – Increase the period of time a STA may be in power save state by not waking for multicast/broadcast traffic at every DTIM • Solution – A client can request a delivery interval longer than the normal DTIM interval for selected traffic – A client may not have to wake up at every DTIM interval in order to receive the selected broadcast and multicast frames. – Backward compatible with existing 802. 11 method for delivering these streams 12/16/2021 11

21 -07 -333 -00 -0000 FBMS Protocol • Beacon – FBMS Descriptor IE •

21 -07 -333 -00 -0000 FBMS Protocol • Beacon – FBMS Descriptor IE • New Wireless Network Management action frames – FBMS Request IE – FBMS Response IE • Reassociation Request/ Response – FBMS Request IE – FBMS Response IE 12/16/2021 AP Non-AP STA Beacon + FBMS Descriptor IE FBMS Request Action frame FBMS Response Action frame Reassociation Request + FBMS Request IE Reassociation Response + FBMS Response IE 12

21 -07 -333 -00 -0000 Proxy ARP • Motivation – Remove the need for

21 -07 -333 -00 -0000 Proxy ARP • Motivation – Remove the need for a STA to wake and respond to ARP requests unnecessarily – ARP request a common broadcast frame – Helps all STAs remain in power save state • Solution An AP can advertise when it provides Proxy ARP on behalf of the STA in the beacon 12/16/2021 13

21 -07 -333 -00 -0000 Example of Power Saving for Broadcast/Multicast Current delivery: AP

21 -07 -333 -00 -0000 Example of Power Saving for Broadcast/Multicast Current delivery: AP sends DTIM Beacon to indicate scheduled delivery Beacon Proxy ARP Service: AP responds to ARP request on behalf of clients Flexible Delivery: AP delivers traffic based on traffic categories and its delivery intervals Broadcast/multicast client wakes up to receive broadcast /multicast traffics Proxy ARP and Flexible delivery allows long sleep periods 12/16/2021 14

21 -07 -333 -00 -0000 TIM Broadcast • Motivation – Reduce the time taken

21 -07 -333 -00 -0000 TIM Broadcast • Motivation – Reduce the time taken to process the TIM information in a beacon and how often a STA has to wake to get the TIM • Solution – AP transmits two TIM frames per beacon period • one TIM at the same rate as the Beacon • one TIM at a higher rate which is not DSSS (i. e. OFDM) – TIM Broadcast has advantage over receiving a Beacon or a Probe Request: • 1, 620 us Beacon (all Rx) • 1, 024 us Probe Request/Response (152 us Tx) • 36 us TIM frame at 24 Mbps (all Rx) 12/16/2021 15

21 -07 -333 -00 -0000 Summary • TGv power saving features allow long sleep

21 -07 -333 -00 -0000 Summary • TGv power saving features allow long sleep periods • • Traffic Filter Service and Sleep Mode BSS Max Idle Timeout FBMS and Proxy ARP TIM Broadcast • Power management schemes across technologies (802. 11/16/3 GPP) should take account of the unique features of the technology, and common schemes may not always apply: – Sleep Mode in 802. 11 may provide the same functionality as the Idle Mode defined in 802. 16 and 3 GPP – Paging service is not provided in 802. 11 TGv, unlike 802. 16 and 3 GPP 12/16/2021 16

21 -07 -333 -00 -0000 Thank You! 12/16/2021 17

21 -07 -333 -00 -0000 Thank You! 12/16/2021 17