The document discusses implementing MAC-level sleep scheduling for delay-constrained applications over WLANs. It determines that the Nexus 5 uses a FullMAC WiFi chipset that cannot be modified. An alternative is to use an USB WiFi adapter supported by the ath9k_htc driver, which is SoftMAC based and supports the necessary AP, monitor, and power saving modes. Implementing the scheduling would require modifying frames, adding scheduling logic on the AP side, and power management algorithms on the client side. The plan outlines prerequisites, and breaking the work into AP side implementation, client side implementation, and testing phases between the developers.

1. Implementation of MAC-level sleep-
scheduling for delay-constrained
application over WLANs

2. 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 …

3. 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.

4. 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 !

5. 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 !

6. 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).

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

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. mac80211
The Big Picture

16. mac80211
hostapd
• 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

17. 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).

18. 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

19. mac80211
PSM for infrastructure (AP) mode

20. 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.

21. mac80211
Power Management - struct ieee80211_hw

22. 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.

23. mac80211
Power Management – struct ieee80211_ops

24. mac80211
Power Management – struct ieee80211_ops

25. mac80211
Power Management - struct ieee80211_conf

26. 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.

27. mac80211
Power Management - ieee80211_get_buffered_bc

28. mac80211
Power Management - ieee80211_beacon_get

29. mac80211
How does it all fit together ?
Transmission path: kernel  mac80211  ath9k

30. mac80211
How does it all fit together ?
Transmission path: ath9k  hardware

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

32. mac80211
How does it all fit together ?
Reception path: mac80211  kernel

33. mac80211
How does it all fit together ?
Beacon Tx path: ath9k  mac80211

34. mac80211
How does it all fit together ?
Beacon set up: hostapd/wpa_supplicant

35. mac80211
How does it all fit together ?
Beacon Rx path: mac80211

36. Mac80211
Management frames

37. Mac80211
Management frames – AP side

38. Mac80211
Management frames – Station (STA)

39. Implementation details
AP 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

40. Implementation details
AP Side
• 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.

41. Implementation details
AP Side
• 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.

42. Implementation details
AP Side
• 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.
𝑬𝑫𝑻 =
𝑫 𝒏,𝒎𝒊𝒏 −
𝑳
𝒓 𝒅
− 𝑻 𝒔,𝒈𝒖𝒂𝒓𝒅
𝒓 𝒅 − 𝒓 𝒂

43. Implementation details
Station (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.

44. Implementation details
Station (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.

45. 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.

46. 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).

47. 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.

48. 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 ?