Implementation of MAC-level sleep-scheduling

Implementation of MAC-level sleep-scheduling for delay-constrained

application over WLANs

Glossary – Important terms

• WNIC (Wireless Network Interface Controller)- Works on both Layer 1 (PHY) and Layer 2 (MAC).- 2 different kinds of MAC layer implementations,

HardMAC/FullMAC and SoftMAC

• STA (station): generic term for stations. i.e computers, phones, routers …

Glossary – Important terms

• IBSS (Independent Basic Service Set): Ad-Hoc mode.

• Monitor Mode: allows a WNIC to monitor all traffic received from the wireless network.

• AP Mode: allows a WNIC to function in station mode. Our WNIC must supports AP and Monitor modes of operations if we want to be able to modify the behavior of the AP, and monitor the traffic. IBSS Mode is facultative and we don’t need it at the moment.

SoftMAC vs HardMAC

• HardMAC/FullMAC devices: MAC functions implemented in Hardware

- Contributes less to CPU load- Not very flexible.- FullMAC devices have become scarce, but widely

used in mobile devices.- No Monitor Mode, AP mode not configurable.

Not very well suited for our needs !

SoftMAC vs HardMAC

• SoftMAC devices: MAC functions implemented in software, through mac80211 framework

- Allows finer grain control of the hardware.- 802.11 frame management: parsing and generation of wireless frames.- Ability to modify code for advanced functions, such as Power Saving Mechanisms (PSM).

Corresponds to our needs !

SoftMAC vs HardMAC

• Advantages of SoftMAC- Potentially lower hardware cost- Possibility to upgrade to newer standards by updating the driver only- Possibility to correct faults in the MAC implementation.- Different drivers for different WNIC can all share the same MAC implementation.- Allows to specify new management frames (like Sleep Request / Sleep Grant frames).

SoftMAC vs HardMAC

• Advantages of HardMAC- Proprietary implementation (in hardware).- Less CPU load.- Portable devices (like in smartphones).

Nexus 5: SoftMAC or HardMAC ?

• Nexus 5: Broadcom chipset, multiple drivers:- brcm80211: Broadcom open-source mac80211-

based driver. Divided in two parts: brcmfmac for HardMAC/FullMAC driver. brcmsmac for SoftMAC driver.

- b43: Reverse-engineered version of proprietary drivers: supports station (STA), Monitor Mode, Packet injection using Radiotap.

- broadcom-wl: restricted-license (proprietary) driver.

Nexus 5: SoftMAC or HardMAC ?

• Nexus 5 Wi-Fi chipset reference:- Broadcom BCM4339 SDIO interface FullMAC

driver (as 100% of smartphones chipsets).

can’t modify a FullMAC driver (hardware) ! need another WNIC that is SoftMAC.

Alternatives (1)

• mac80211_hwsim - software simulator of 802.11 for mac80211. Can be

used to simulate any number of radios, and test most mac80211 functionalities.

- Allows to test our implementation with settable network parameters.

- Problem: impossible to test in real real conditions.

Alternatives (2)

• Do research on a SoftMAC WNIC instead !- USB Wireless Adapter that implements MAC layer in

software (SoftMAC), and add it as a wireless extension to the Nexus 5.

- Need to find one with a mac80211-based driver, support for AP mode and Monitor mode, and has existing implementation of PSM.

- Still searching ! USB devices supported by ath9k_htc or carl9170 driver seem perfect.

ath9k_htc driver• Same as popular ath9k driver, but for USB WNIC.

• ath9k = successor of a popular research wireless driver called MadWifi.

• ath9k has support for AP mode, Monitor Mode, and has existing (but buggy and disabled by default) implementation of PSM (Power Saving Mode).

• mac80211-based simplifies our task.

• Wireless drivers with existing implementation of PSM are scarce, especially in the open-source world.

ath9k_htc driver• ath9k located in the Linux kernel

linux/drivers/net/wireless/ath/ath9k

• ath9k_htc also differs from ath9k it has a firmware part and a software part.

• Still need to figure out if power saving is done in the firmware or software part (very vague).

• Once we know, decide if use ath9k_htc or another driver, then choose an USB adapter.

mac80211 framework

• mac80211: framework (API) for SoftMAC WNICs• Subsystem of Linux kernel.• Follow 802.11 standards.

• Used for implementing SoftMAC drivers.• Implement callbacks with cfg80211 (kernel side) and

user control with nl80211 (user-space side).• ath9k_htc (among many others) is mac80211-based.

mac80211 The Big Picture

mac80211hostapd

• hostapd- user-space daemon for access points and

authentication servers. - allows a device to function as an Access Point,

assuming the hardware support AP mode.- creates STATIC templates of the Beacon frames (i.e

SSID, supported rates, …) and passes it down to mac80211.

- Authenticator

mac80211 wpa_supplicant

• wpa_supplicant- User-space application, runs on basic STA (stations).- Implements WPA and SME (to handle initiating

MLME commands).- Supported wireless cards/drivers: all mac80211

drivers.- Supplicant (authenticated).

mac80211 MLME

• Media Access Control (MAC) Sublayer Management Entity.

• Where the Physical layer (PHY) MAC state machines reside.

• Functions: authenticate, deauthenticate, associate, disassociate, beacon, probe.

• net/mac80211/mlme.c

mac80211 PSM for infrastructure (AP) mode

mac80211 Power Management - pm-qos

• Power Management Quality of Service• Allows customizations of different kernel subsystem for power

savings enhancements.• Parameters configurable in user-space:

- cpu_dma_latency- network_latency- network_throughput- system_bus_freq

• Upon userspace network latency changes, mac80211 informs the kernel to be notified, and update its policy on dynamic power save (only on/off).

• Configured network latency will affect the timeout used for dynamic power save.

mac80211 Power Management - struct ieee80211_hw

mac80211 Power Management – ieee80211_hw_flags

• Flags used to indicate hardware capabilities to the stack.

• IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING- Some WLAN chipsets buffer broadcast/multicast frames for power saving

stations in the hardware/firmware and others rely on the host system for such buffering.

- This option is used to configure the IEEE 802.11 upper layer to buffer broadcast and multicast frames when there are power saving stations so that the driver can fetch them with ieee80211_get_buffered_bc.

• IEEE80211_HW_NO_STACK_DYNAMIC_PS- Hardware which has dynamic power save support, meaning that power save

is enabled in idle periods, and don’t need support from stack.

mac80211 Power Management – struct ieee80211_ops

mac80211 Power Management – struct ieee80211_ops

mac80211 Power Management - struct ieee80211_conf

mac80211 Power Management – ieee80211_conf_flags

• Flags used to define PHY configuration options

• IEEE80211_CONF_RADIOTAP- Add radiotap header at receive time (if supported).

• IEEE80211_CONF_PS- Enable 802.11 power save mode.

mac80211 Power Management - ieee80211_get_buffered_bc

mac80211 Power Management - ieee80211_beacon_get

mac80211 How does it all fit together ?

Transmission path: kernel mac80211 ath9k


Transmission path: ath9k hardware

mac80211 How does it all fit together ?Reception path: hardware ath9k


Reception path: mac80211 kernel


Beacon Tx path: ath9k mac80211


Beacon set up: hostapd/wpa_supplicant


Beacon Rx path: mac80211

Mac80211Management frames

Mac80211Management frames – AP side

Mac80211Management frames – Station (STA)

Implementation detailsAP Side

• Need to define 2 new management frames, or modify existing beacon frames:

need access to the MAC layer, so can be done only for SoftMAC implementations !

• sleep request frames• Wake-up entry (WUE) composed of two fields:

REQ: 1 bit to set automatic or manual mode.• BBWU: Beacons Before Wake-Up.

• sleep grant frames. Grant entry (GE) composed of two fields:

• GRANT: 1 bit that indicates if granted. BBWU: Beacons Before Wake-Up if GRANT == 0


• Need a scheduling table/queue (AP side) to keep track of clients’ wake-up time.

• Scheduling table/queue BBWU: Beacons Before Wake-Up. EDT: Estimated Download Time (in BI units).

Estimated by AP in function of network status.


• Need a scheduling algorithm (AP side).• Scheduling algorithm 1. Receive sleep request frame. 2. Create a sleep grant frame (MAC level). 3. Look up in the sleep table / queue: - If the last entry has superior BBWU, request not granted. Unset GRANT field and generates a new BBWU. - If the last entry has inferior BBWU, request granted. Set GRANT field and pad BBWU field with zeroes. 4. Add entry to the table/queue, along with the calculated EDT. 5. Send the sleep grant frame. 6. Each beacon interval (BI): decrease all BBWU in table/queue by one. 7. If BBWU reaches 0, establish download link, and trigger download for EDT Beacon Intervals. When done, pop entry of the table/queue.


• Determining EDT (Estimated Download Time):

• Need to figure how to determine all those network parameters !

• Functions exist in mac80211 to have some information on the network.

𝑬𝑫𝑻=𝑫𝒏 ,𝒎𝒊𝒏−

𝑳𝒓 𝒅−𝑻 𝒔 ,𝒈𝒖𝒂𝒓𝒅

𝒓 𝒅−𝒓 𝒂

Implementation detailsStation (STA) side

• Need an algorithm to process sleep requests and sleep grants.

• Receiving algorithm: 1. Creates a sleep request frame (MAC layer). 2. If no response from the AP (request lost), stay awake. 3. If sleep grant frame received:

- If GRANT is set, go to sleep for BBWU immediately.- If GRANT is unset, check BBWU in received frame and send a new sleep request with that BBWU.

4. Wakes up after BBWU, and start receiving downlink buffered packets.

5. After reception of buffered packets, stay awake for at least Tawake,min.

Implementation detailsStation (STA) Side

• Determining BBWU (Beacons Before Wake-Up)

• Implement dynamic algorithm to determine BBWU.

• Functions exist in mac80211 to have some information on the network.

Planning

• Pre-requisites (2 weeks / developer)- Set up build and testing environments- Activate monitor mode- Activate AP mode- Trace all incoming and outgoing packets- Compile and build new driver modifications- Flash a new kernel / custom ROM.

Planning

• AP side (2 months – 1 developer // 1 month – 2 developers)- First phase – Setting developing / testing environments

- Activate mac80211 AP mode, sending/receiving to another device.- Test tune up/down of the Beacon Interval (BI).- Test tune up/down of the Listen Interval.- Monitor traffic with mac80211 tracing framework.- Modify source code of 80211, change some parameters (aggressivity, etc.)- Test modifications and monitor traffic again, show differences in power savings.- Graph some calculations of EDT and see if they match with theory.

- Second phase – Implementation and testing of the algorithms- Implement support for receiving sleep request and sending sleep grants.- Test the implementation (can only be done after client side frame mgmt is done).- Implement sleep scheduler v1 (sleep request scheduling).- Implement sleep scheduler v2 (calculation of EDT based on network parameters).- Test implementations (can only be done after client side is done).

Planning

• Client side (1 month – 1 developer // 2 weeks – 2 developers)- Determine how to switch power modes (low power / high power).- Implement support for send/receive sleep requests/grants.- Implement sleep calculator based on network measurements.- Find a way to measure power consumption on the device (either at the user level, or preferably at the kernel level).- Run a lot of tests to measure power consumption with different settings.

Summary• Nexus 5 Wi-Fi chipset: FullMAC implementation.

• Need to add an USB WNIC supported by open-source driver that has support for AP mode, Monitor mode, and existing PSM implementation.

• ath9k_htc driver seems like a good fit and is mac80211-based.

• Writing of mac80211 drivers is (almost) well documented. At least 1 book exist on mac80211 subsystem.

• Lot of stuff to do ! Somebody help ?

Implementation of MAC-level sleep-scheduling

Documents