WiFi Aware (NAN) Explained

What Is WiFi Aware?

WiFi Aware - formally known as Neighbor Awareness Networking (NAN) - allows WiFi devices to discover each other and exchange small amounts of data without connecting to a network. No access point is needed. No association. No IP address assignment. Devices simply find each other and communicate directly at the link layer.

Think of it as the WiFi equivalent of Bluetooth's advertising mechanism, but with WiFi's range and throughput. A device can announce "I am a photo printer" or "I have files to share" to anyone nearby without establishing a full WiFi connection. Other devices can discover these announcements and decide whether to initiate a data transfer.

WiFi Aware was certified by the Wi-Fi Alliance in 2015 and is supported on Android devices running Android 8.0 (Oreo) and later. Apple has not implemented WiFi Aware in iOS, using its proprietary AWDL (Apple Wireless Direct Link) protocol instead for similar functionality in AirDrop and AirPlay.

Neighbor Awareness Networking Architecture

NAN operates as a cluster of devices that synchronize their radio activity to specific time windows. The cluster forms organically - when a device enables WiFi Aware, it either joins an existing NAN cluster or creates a new one.

Each NAN cluster has a Master device that maintains synchronization. The Master is elected automatically based on a preference value and random tiebreaker. If the Master disappears, another device in the cluster takes over. The Master does not route traffic or manage connections - its only role is broadcasting synchronization beacons that keep all devices aligned to the same timing schedule.

graph TD
    subgraph "NAN Cluster Formation"
        D1[Device 1 - enables NAN] -->|No cluster found| CREATE[Creates new cluster]
        CREATE --> MASTER1["Device 1 becomes Master"]
        D2[Device 2 - enables NAN] -->|Finds cluster| JOIN1[Joins cluster]
        D3[Device 3 - enables NAN] -->|Finds cluster| JOIN2[Joins cluster]
        MASTER1 --> SYNC[Sync beacons on channel 6]
        JOIN1 --> SYNC
        JOIN2 --> SYNC
    end
    subgraph "Master Election"
        PREF1["Device 1: preference 200"] --> ELECT{Highest preference}
        PREF2["Device 2: preference 150"] --> ELECT
        PREF3["Device 3: preference 180"] --> ELECT
        ELECT --> WINNER["Device 1 remains Master"]
    end

NAN clusters self-organize - the device with the highest preference value becomes Master and broadcasts sync beacons

Discovery Windows and Synchronization

NAN devices do not keep their radios on continuously. Instead, they synchronize to periodic Discovery Windows (DW) - short time intervals during which all cluster members are awake and listening on the same channel.

The default NAN discovery channel is channel 6 on 2.4GHz (2437 MHz). A secondary discovery channel on 5GHz (channel 149, 5745 MHz) can be used for higher-bandwidth discovery. All devices in a cluster wake up during the same DW, exchange discovery frames, and then return to sleep or resume their normal WiFi activities.

Discovery Windows repeat every 512 time units (approximately 524 milliseconds). Within each DW, the Master broadcasts a synchronization beacon, and other devices transmit their service advertisements and discovery queries. The DW duration is short - typically 16 milliseconds - keeping power consumption low.

A device participating in NAN can simultaneously maintain a regular WiFi connection to an access point. The NAN operations happen in the gaps between regular WiFi activity, using time-division to share the radio between infrastructure WiFi and NAN discovery.

Service Advertisement and Subscription

NAN's core purpose is service discovery. Devices can publish services and subscribe to services they are interested in.

Publishing: A device announces a service by broadcasting a Service Discovery Frame (SDF) during Discovery Windows. The SDF contains a service name (a UTF-8 string hashed to a 6-byte identifier), optional service-specific information, and match filter data. For example, a printer might publish a service named "com.example.print" with information about supported paper sizes and color capabilities.

Subscribing: A device looking for a service sends subscribe frames with the service name hash it wants to find. When a subscriber's query matches a publisher's advertisement, the NAN stack notifies the application of the match.

Two matching modes exist:

Passive subscribe: The subscriber listens for matching publish frames. No frames are transmitted - the subscriber just monitors the DW for advertisements.

Active subscribe: The subscriber transmits solicited frames asking for specific services. Publishers that match respond directly.

Data Path Establishment

Discovery alone does not transfer data beyond the small amounts included in service advertisements. For actual data exchange, NAN provides the NAN Data Path (NDP) - a direct device-to-device connection established after discovery.

An NDP creates a link-layer connection between two devices with its own security context. The devices negotiate a shared key using a passphrase, PMK (Pairwise Master Key), or an out-of-band method. Once established, the NDP provides a standard network interface that applications can use for TCP/UDP communication.

Multiple NDPs can exist simultaneously, creating a mesh of direct device-to-device links within the NAN cluster. Each NDP is independent with its own security credentials and encryption keys.

graph TD
    subgraph "WiFi Aware - Full Workflow"
        PUB[Publisher - advertises service] -->|Discovery Window| MATCH{Service Match}
        SUB[Subscriber - looking for service] -->|Discovery Window| MATCH
        MATCH -->|Match found| NOTIFY[App notified of match]
        NOTIFY -->|App requests connection| NDP_REQ[NDP Request]
        NDP_REQ -->|Security negotiation| NDP_SEC[Key exchange]
        NDP_SEC -->|Data path created| NDP_ACTIVE[Active NDP - TCP/UDP ready]
    end
    subgraph "Power States During NAN"
        SLEEP1[Radio sleep] --> DW1[Discovery Window - 16ms]
        DW1 --> SLEEP2[Radio sleep]
        SLEEP2 --> DW2[Discovery Window - 16ms]
        DW2 --> SLEEP3[Radio sleep - 508ms gap]
    end

WiFi Aware moves from service discovery to data exchange - the radio stays asleep between short discovery windows

Android's Implementation

Android exposes WiFi Aware through the WifiAwareManager API starting with Android 8.0. The Nearby Connections API, which powers Quick Share (formerly Nearby Share), can use WiFi Aware as one of its transport layers alongside Bluetooth and WiFi Direct.

The typical flow on Android: an app creates a WiFi Aware session, publishes or subscribes to a service, receives discovery callbacks, and optionally creates a network connection through the NDP. The API abstracts the NAN cluster management, DW synchronization, and security negotiation, presenting a simple publish/subscribe/connect model to developers.

Google uses WiFi Aware in several system features beyond file sharing. Nearby Notifications (now deprecated) used it for proximity-triggered content delivery. Indoor positioning systems can use NAN ranging (RTT-based distance measurement between NAN peers) for centimeter-accurate location without GPS.

Apple does not use WiFi Aware. Instead, Apple devices use AWDL (Apple Wireless Direct Link), a proprietary protocol that serves a similar purpose but is incompatible with NAN. AWDL powers AirDrop, AirPlay, and Sidecar. This means cross-platform proximity discovery between Android and iOS devices cannot use WiFi Aware and must fall back to Bluetooth or other mechanisms.

Privacy Implications

WiFi Aware's discovery mechanism has privacy implications that users should understand. When a device publishes a NAN service, it broadcasts that service advertisement to every device in the cluster during every Discovery Window. This broadcast includes:

The device's NAN Interface Address: A MAC address (which may or may not be randomized depending on the implementation). Some early Android implementations used a fixed NAN MAC address derived from the device's WiFi MAC, making device tracking possible.

Service names: While hashed, the hash is deterministic. An observer who knows the service name can compute the hash and identify which devices in the area are advertising or seeking specific services.

Presence information: Simply being in a NAN cluster reveals that a device is nearby and has WiFi Aware enabled. The sync beacons and DW participation are detectable by any passive monitor on channel 6.

Modern Android versions (11+) address some of these concerns by randomizing the NAN Interface Address and limiting service discovery to apps with appropriate permissions. But the fundamental broadcast nature of NAN means that any device in radio range can detect NAN activity and enumerate active services.

WiFi Aware and the BLEShark Nano

The BLEShark Nano operates on 2.4GHz, which includes channel 6 - the default NAN discovery channel. During passive scanning, the Nano can detect NAN synchronization beacons and Service Discovery Frames. These frames identify NAN clusters in the area and the services being advertised.

NAN frames use specific Action frame subtypes within the 802.11 Public Action frame category. They are transmitted in the clear (unencrypted) during Discovery Windows. A passive scanner on channel 6 will see periodic bursts of NAN activity every ~524ms as devices in nearby clusters exchange discovery information.

This capability is useful for wireless environment characterization. Detecting active NAN clusters reveals the presence of devices engaged in peer-to-peer discovery - information that does not appear in regular AP beacon scans. Combined with BLE scanning (since many peer-to-peer protocols use BLE for initial discovery before upgrading to WiFi), the BLEShark Nano can build a comprehensive picture of both infrastructure WiFi and ad-hoc peer-to-peer activity in an area.