370 likes | 495 Views
Power efficient and unified 802.11s solution. Authors:. Date: 2007-11-12. Abstract.
E N D
Power efficient and unified 802.11s solution Authors: Date: 2007-11-12 Jarkko Kneckt, Nokia
Abstract This presentation provides a high level view of the 802.11s mesh network as seen by the authors. Detailed proposal is given on power save mechanisms. In general the objective has been to have a standard amendment with a feature set meeting the following main objectives: • suitable for both backbone and ad hoc type of mesh networks • power save mechanisms defined to allow for battery powered MPs • one solution to one problem Jarkko Kneckt, Nokia
Contents • Introduction • The big picture • Basic components • Five basic components of MPs • Power save in details • Two levels of power save • Power mode transition rules • Mesh service period Jarkko Kneckt, Nokia
The big picture • 802.11s mesh network should be built on the same components independently from the reason to form and run the network • Don’t want to end up with fragmented standard and markets with separate feature sets and vendor specific extensions breaking interoperability • Consequently all the 802.11s compliant devices should be capable of operating as MPs • Path selection metrics and protocols mandatory for all the 802.11s devices • Power save support mandatory • One beaconing mechanism is enough for all the network cases • MP should be able to form a link to any other MP • Resource and security constraints are only reasons to deny link creation • Broaden the market space of 802.11s devices and networks to the very maximum Jarkko Kneckt, Nokia
Exemplary backbone 802.11s network Other networks; internet etc. • The very basics of the network assumes static MPs • Portable terminal in the network is typically a “full MP” like any other node • Most of the time expected to run in power save though • More often than the other MPs establishes only a few links to peer MPs Jarkko Kneckt, Nokia
Exemplary ad hoc 802.11s networks • More traditional usage of 802.11s in portable terminal is to form and run ad hoc network • Terminals able to form multi-hop networks • Network structure and topology dependent on use case and terminals run accordingly through the SME Jarkko Kneckt, Nokia
Basic components of 802.11s MPs • Same mandatory features and functionality for each MP • Infrastructure beaconing • Power save support • EDCA • Routing • Security Jarkko Kneckt, Nokia
Basic component #1: Infra beaconing • All MPs beacon as per the infrastructure beaconing rules • The infrastructure beaconing is the solid basis for static and larger backbone networks for which the IBSS beaconing is not suitable • The IBSS beaconing is the ad hoc beaconing mode and not robust enough for larger backbone networks • 2-hop neighbors cause collisions to beaconing • Link management and network discovery logic more complicated than with infra beaconing • IBSS beaconing may force MPs to participate to multiple beacon transmissions. • Only one beaconing mechanism should be specified in 802.11s • Beaconing mechanisms are not trivial to implement. Multiple beaconing mechanisms increase implementation complexity. Jarkko Kneckt, Nokia
Basic component #2: Power save support • All MPs need to support power save service • Signal processing and frame delivery scheme related to communication with power saving MP • Capability to operate as a power saving MP is optional • Implementation of power save mode optional • Why? • Power save is an essential feature in new type of use cases in home and consumer electronic products Jarkko Kneckt, Nokia
Basic component #3: EDCA • Contention based EDCA proposed to be the mandatory scheme • Some EDCA compatible enhancements for better performance may be introduced • MDA type of channel access should be defined (improved PMPS) • Currently MDA requires too heavy synchronization (not proven otherwise :-) • Thus biggest problems we envision are on timing and implications to synchronization requirements Jarkko Kneckt, Nokia
Basic component #4: Routing • All devices will be routing capable • As default, each MP acts as forwarding MP • Devices may opt not to forward data e.g. due to low battery capacity • Implementation complexity of the HWMP is, however, something we’re a bit concerned about • Is it too heavy burden for devices that are not designed nor intended to be used in multi-hop mesh networks? • Currently we believe the benefits of the common feature set across all the MPs overweigh the possible implementation complexity costs Jarkko Kneckt, Nokia
Basic component #5: Security • The basic requirement is that every link is authenticated and secured • However in N-node network there shouldn’t be N-1 user interactions • What’s needed to ensure this? • How current MA & MKD model is planned to fit in semi-static mesh networks? Jarkko Kneckt, Nokia
Beaconing in nutshell • The framework for infrastructure beaconing • Mesh beacons need to be separate management type frames from the legacy beacons • Mesh beacon period of the MP indicated as n*100 TUs • Mesh DTIM period indicated as the number of mesh beacon intervals between successive DTIMs • Shall have a value equal to or larger than 5 • Mesh beacon period and mesh DTIM period are possible to update on DTIM beacon • The power save proposal in the following slides has been built upon this framework Jarkko Kneckt, Nokia
Power save proposal in nutshell • The proposal builds upon the current two power management modes • Active mode • Power save mode • Two levels of power save proposed • Light sleep designed for battery powered active MPs • Deep sleep provides a low duty cycle mode for all the MPs • Light sleep power save operations are based on wake-up signaling in beacons and a U-APSD –like operations • Deep sleep MP can be woken up only after its own mesh DTIM beacons for short data exchange periods Jarkko Kneckt, Nokia
Power management modes • Active mode • The MP is awake all the time • Power save mode • Light sleep – “Diet sleep” • The MP is awake during the time needed to send own mesh beacon, receive the peer MP mesh beacons, and to serve peer links as per the mesh service period rules • Designed to be used when the MP desires to reduce the power consumption and the full bandwidth is not needed for data from/to the peer MPs • Deep sleep • The MP is awake during the own mesh DTIM beacon and the following wake-up period, and to serve any subsequent mesh service periods • Designed to be used when there is no or very limited amount of traffic from/to the peer MPs Jarkko Kneckt, Nokia
Minimum activity in power saving MP MP1 = Minimum activity of active mode MP1 =Minimum activity of light sleep mode MP1 = Minimum activity of deep sleep mode MP1 MP1 and MP2 are peer-MPs to each other MP2 = Wake-up period = TIM beacon = DTIM beacon The following slides present the light sleep mode and deep sleep mode in more details See appendix for power consumption calculations in different power modes Jarkko Kneckt, Nokia
The basic rules of light sleep • Beaconing MP uses Mesh TIM field in its own beacon to indicate presence of buffered data to power saving peer MPs • Power saving MP checks if the peer MP indicates presence of buffered data for it • If the bit is set, the MP triggers a mesh service period • Beaconing MP serves power saving peer MPs to which it has buffered data during mesh service periods • Doze state can be entered only when all the mesh service periods have been closed • The mesh service period handling rules are described later in the slide set Beacon Beacon Trigger frame ACK Mesh service period Jarkko Kneckt, Nokia
The basic rules of deep sleep • Power saving MP in deep sleep shall be active at least during its mesh DTIM beacon and the following Awake Window • The Awake Window is used for two purposes • MPs can request specific actions from the power saving MP • The MP in deep sleep transmits multicast and broadcast frames to peer MPs • Specific actions one can request during the Awake Window depend on the requesters role • Peer MP can use the Awake Window to initiate a mesh service period with the power saving MP • Non-peer MP can use the Awake Window to transmit a mesh management frame related to mesh discovery or peer link establishment Jarkko Kneckt, Nokia
Mode and level transitions (1/2) • Power save mechanisms are link specific • In some traffic models or network topologies it may make sense to raise the local MP to operate in higher power save level (or power management mode) for only one or few peer links • Transition to lower power save level needs to be unicasted because only those are acknowledged • Robust and reliable power management state transitions from higher power save level to lower power save level require acknowledgement from the peer MP • Transition to higher power save level may use unicast, multicast and broadcast transmissions • The transition from a lower power save level to a higher one is robust • Even if MP assumes that the peer MP operates on the lower power save level, it will not cause failure to frame transmission Jarkko Kneckt, Nokia
Two bits in the MAC header indicate the power management mode Power management bit indicates whether the MP operates in active or power save mode The power save level bit indicates the level of the power save, when the MP has set the power management bit to 1 Power management indicated in BC/MC frames is set as per the lowest power management mode used in the links The power management mode that is indicated in BC/MC frames is used also by non-peer MPs to determine the times for scan and link creation frame exchange Mode and level transitions (2/2) Jarkko Kneckt, Nokia
Mesh service periods – enabling transmissions while MP operates in power save mode • The MP may use mesh service periods for data transmission, when it is operating in power save mode, i.e. have power management bit set to 1 • A mesh service period is initiated by acknowledged trigger frame • Unicasted and acknowledged PS-POLL, ATIM, QoS-Null, data or management frame may be used as a trigger frame. • A trigger frame initiates a mesh service period, which type is specified in the link setup. The following slides discusses more on the service period types. • Mesh service periods are link specific • The peer MP shall be active for the duration of the service period • During a mesh service period, frames from all ACs may be transmitted • Trigger frame’s AC does NOT limit the ACs of the frames transmitted during the mesh service period • Mesh service period termination rules discussed in the following slides Jarkko Kneckt, Nokia
Mesh service period types • Mesh service period may be unidirectional or bi-directional • Unidirectional mesh service period enables either MP to transmit data during the mesh service period. The mesh service period is terminated when the MP indicates that the last frame is transmitted and receives acknowledgement for the frame. • Bi-directional mesh service period enables both MPs to transmit data during the mesh service period. The mesh service period is terminated when both data frame and acknowledgement indicate that all buffered traffic is transmitted. • 2 unidirectional mesh service periods may be used to allow for the both MPs to transmit data • Bi-directional mesh service period shall be used, if both MPs support bi-directional mesh service periods • Bi-directional mesh service periods enable: • better efficiency and controllability of the mesh service period, because both sides may actively transmit data and other MP is not forced to receive only • Better coordination to transition from active mode to power save, no lost frames in power mode transition • Efficient termination Jarkko Kneckt, Nokia
Termination of the unidirectional mesh service periods Termination of one unidirectional mesh service period Termination of two unidirectional mesh service periods Both MP 3 and MP4 are data transmitters in the mesh service periods. The mesh service period from MP3 is terminated, when MP3 indicates that it does not have more data to transmit. MP4 acts accordingly with its own mesh service period. MP 1 is data transmitter in the mesh service period. The mesh service period is terminated when MP1 indicates that it does not have more data to transmit with EOSP. Data Data Ack Ack Data, EOSP=1 Data, EOSP=1 Ack Ack Data, EOSP=1 Ack MP1 MP3 MP2 MP4 = MP may transmit data = MP may receive data MD = More Data bit Jarkko Kneckt, Nokia
Termination of the bi-directional mesh service periods Termination of the bi- directional mesh service period Both MPs are in light sleep mode Both MPs indicate that they have transmitted all frames. After data frame transmission, which contains more data bit set to 0 and ack with more data bit set to 0, the mesh service period is terminated. Data Ack Data, EOSP=1 Ack, MD=1 Data, EOSP=1 Ack, MD=0 MP3 MP4 = MP may transmit data = MP may receive data Jarkko Kneckt, Nokia
Active mode to light sleep transition(complicated case) • The MP3 indicates that it does not have any data to be sent and it is going to power save mode. • MP4 has data in its buffers and it initiates mesh service period which keeps MP3 in active mode until end of mesh service period. • MP3 may send any additional data it has during the mesh service period MP indicates that is does not have data to be sent anymore and it moves to power save mode Data Ack MP initiates mesh service period, receiving MP waits until mesh service period has ended before going to Data, PM=1 Ack Data Ack Data, EOSP=1 Ack MP3 MP4 = MP may transmit data = MP may receive data Jarkko Kneckt, Nokia
Mesh service period between active mode and light sleep MPs • MP1 is in active mode • MP2 is in light sleep mode • MP1 has data to be sent for MP2 and MP1 indicates it in its beacon • MP2 responses with appropriate trigger frame which initiates mesh service period • Service period is ended with setting of EOSP bit after the MP1 buffers further data for MP2 MP1 indicates in beacon that it has data pending MP2 responses with trigger frame starting mesh service period Data Ack Data Ack Data, EOSP=1 Ack MP1 MP2 = MP may transmit data = MP may receive data Jarkko Kneckt, Nokia
Mesh service period summary • Unidirectional Mesh Service Period • Used when link configured to support only unidirectional service periods • Used in between active mode and light sleep mode MPs • Bi-directional Mesh Service Period • Provides efficient method to send data between light sleep MPs when there isn’t equal amount of data to be sent and other MP is not forced to receive only • Better coordination to transition from active mode to power save, no lost frames in power mode transition • Efficient termination through a single frame and ack transmission. Jarkko Kneckt, Nokia
Appendix, power consumption calculations in different power management modes Jarkko Kneckt, Nokia
Calculations on stand-by modes power consumption • 11-07-1996-r2 (Power save and routing) presentation presents radio power consumption parameters and beacon transmission density. • Next slide is copied from the presentation in order to provide power consumption analysis for beaconing mechanisms. • The presentation calculates power consumption estimations for IBSS beaconing, light sleep and deep sleep beaconing modes. Jarkko Kneckt, Nokia
A quantitative analysis of benefit derived from power management mechanism • Some calculation: • Assumption on the power consumption captured from [1] • Operational parameter setting • Beaconing interval : 1000 /100ms • DTIM interval : 0 (every beacon is DTIM beacon, no TIM beacons) • ATIM Window : 10 / 5 / 2,5 ms • Ramp up margin: 1ms • Number of neighbouring peer MPs : 6 • Beacon frame length: 200us Take this parameters for example Jarkko Kneckt, Nokia
Analysis on benefits derived from power save capabilities • Case 1. MP uses IBSS beaconing, all peers are using the same beacon. • MP transmits every seventh (1/7) beacon and receives 6/7 of the beacons. MP stays active during the ATIM period. • Total power consumption per 1[sec] • Amount of beacons per second x (ramp up + 1/7 beacon transmission + 6/7 beacon reception + ATIM Wakeup) + rest of time x Doze State power drain Jarkko Kneckt, Nokia
Analysis on benefits derived from power save capabilities IBSS beaconing power consumption results Note, The time consumption is given for 1 beacon/second case. Jarkko Kneckt, Nokia
Analysis on benefits derived from power save capabilities • Case 2. MP operating in light sleep • Total power consumption per 1[sec] • Amount of beacons per second x [ (ramp up + beacon transmission + ATIM Wakeup) + 6*(ramp up + beacon reception)] + rest of time x Doze State power drain Jarkko Kneckt, Nokia
Analysis on benefits derived from power save capabilities Light Sleep beaconing power consumption results Note, The time consumption is given for 1 beacon/second case. Jarkko Kneckt, Nokia
Analysis on benefits derived from power save capabilities • Case 3. MP operating in Deep sleep • Case assumes that MP using Deep Sleep receives every 10th (1/10) beacon from peer MPs in order to maintain links from timeout. • Total power consumption per 1[sec] • Amount of beacons per second x (ramp up + beacon transmission + ATIM Wakeup) + 6*(ramp up + beacon reception) /10 + rest of time x Doze State power drain Jarkko Kneckt, Nokia
Analysis on benefits derived from power save capabilities Deep Sleep beaconing power consumption results Note, The time consumption is given for 1 beacon/second case. Jarkko Kneckt, Nokia
Analysis on benefits derived from power save capabilities Total stand-by power consumption, excluding the sleep mode power consumption Total stand-by power consumption Jarkko Kneckt, Nokia