Wi-Fi Aware (NAN)

Supported ICs[ RTL8730E ][ RTL8721Dx ][ RTL8721F ]

Note

Realtek Wi-Fi NAN only supports Linux hosts with wpa_supplicant, including Fat Host in Wi-Fi Card mode (WHC Wi-Fi Configuration Options and Operating Modes) and RTL8730E Linux architecture.

Wi-Fi NAN Overview

Wi-Fi Aware, also known as NAN (Neighbor Awareness Networking), is a technical standard certified by the Wi-Fi Alliance. It enables supported devices to quickly discover, connect, and exchange data with other Wi-Fi devices without relying on traditional network infrastructure, Internet connection, or GPS signals. Compared with traditional Wi-Fi Direct, NAN is more energy efficient and effective at the device discovery phase, making it suitable for applications that require continuous awareness of the surrounding environment. This enables a new range of innovative peer-to-peer applications, such as:

• Social applications: find nearby friends with similar interests, or join a local game.

• Information sharing: quickly share files with all participants in a meeting room.

• Local services: receive coupons from nearby stores in a shopping mall, or get detailed information about exhibits in a museum.

The efficiency and low power consumption of Wi-Fi NAN benefit from its unique mechanisms, mainly including the NAN cluster, the service publication/subscription model, and data path establishment.

NAN Cluster

Multiple neighboring NAN devices can automatically form a NAN Cluster, enabling communication between devices in the cluster. Devices inside the cluster share a common time beacon for synchronization.

Devices are not always awake, but instead follow a strict synchronized schedule and only wake up during a very short period called the Discovery Window (DW). During the DW, devices can broadcast their services or listen for services from others. For most of the remaining time, devices stay in low-power sleep mode. This synchronized sleep/wake mechanism is the key to NAN’s low power consumption, avoiding the significant battery drain caused by continuous scanning in traditional Wi-Fi device discovery.

Wi-Fi NAN Cluster

Service Publish/Subscribe Model

Wi-Fi NAN adopts an efficient publish/subscribe model for service discovery:

• Publish Service: Devices can act as publishers to broadcast the services they can provide.

• Subscribe Service: Other devices (subscribers) listen for particular services of interest.

• Service Discovery: When a subscriber receives a published message matching its subscription during a discovery window, the service is successfully discovered.

Establishing NAN Data Path (NDP)

Once successfully subscribed, two devices can choose to establish a NAN Data Path - a direct, peer-to-peer Wi-Fi link, featuring:

• High bandwidth: High data rates using Wi-Fi for transmission.

• Low latency: Direct connection without AP relay.

• Security: WPA2 encryption can be used for data path security.

After NDP establishment, devices can conduct file transfer, video streaming, real-time gaming, and other high-bandwidth, low-latency activities.

References

• Wi-Fi Alliance - Wi-Fi Aware™

• Apple Wi-Fi Aware Documentation

Wi-Fi NAN Supported Features

Realtek devices provide comprehensive support for the Wi-Fi NAN protocol and are capable of operating in any role within a NAN network. The specific supported features are as follows:

• Core Functional Support

  • Creating a NAN Cluster: When no available NAN network is nearby, the device can actively initiate a new NAN cluster, assume the master role, broadcast synchronization beacons, and provide the foundation for other devices to join.

  • Joining a NAN Cluster: The device can automatically scan for and discover existing NAN clusters nearby, synchronize its clock with them, seamlessly integrate into the existing Neighbor Awareness Network, and perform service discovery with other devices.

  • Publish Service: The device can broadcast (publish) one or more services to allow nearby devices to discover them.

  • Subscribe Service: The device can subscribe to (search for) specific services and discover devices providing those services.

  • Establishing Data Paths: Devices can establish either open or encrypted NAN data paths and negotiate time windows for point-to-point data exchange.

• NAN Security Support

  • Supports establishing encrypted data paths between devices. Unicast data frames are protected with WPA2 AES encryption.

  • Supports NAN Pairing for device authentication, key agreement, distribution, and management.

  • Supports protection of unicast management frames using PTK.

  • Supports protection of multicast data frames and management frames using GTK / IGTK.

  • Supports beacon protection using BIGTK.

• Key Features

  • High bandwidth and low latency data transfer: Ensures excellent data exchange performance based on Wi-Fi technology.

  • Secure connections: Authenticates and encrypts connections between paired devices at the Wi-Fi layer.

  • Multiple connections: Supports simultaneous connections with multiple Wi-Fi NAN devices.

  • Network concurrency: Supports concurrent use of Wi-Fi NAN functionality and traditional Wi-Fi networks (STA mode) without interference.

  • Robust topology: Employs a fully peer-to-peer topology, so the joining or departure of a single node does not interrupt existing connections between other nodes.

Wi-Fi NAN Porting Guide

Realtek Wi-Fi NAN supports Linux Host, Wi-Fi Card mode S2H (WHC Wi-Fi Configuration Options and Operating Modes), or RTL8730E Linux.

RTL8721FRTL8721DxRTL8730E

For device driver porting, refer to Wi-Fi Card mode Configuration Options and Operating Modes. For host driver porting, refer to the Linux tab in Wi-Fi Card mode Driver Porting.

Wi-Fi NAN Usage Guide

Realtek NAN Utility is a user-space tool based on the open-source iw library and the proprietary nan_vendor_wrapper library. It provides the nan_test test script, which allows users to operate Wi-Fi NAN in a straightforward and convenient way.

The architecture of NAN Utility is shown as below:

Wi-Fi NAN Utility Architecture

Obtain and Compile NAN Utility

RTL8721DxRTL8721FRTL8730E

1. Obtain the SDK

   SDK download: IoT SDK

   NAN Utility is located at: {sdk}/component/wifi/linux_app/nan_utility.

2. Prepare Environment

   Install dependencies on Linux:

   sudo apt-get install build-essential
   

3. Compile NAN Utility

   Copy nan_utility to Linux kernel source tree, then open new terminal and compile:

   cd nan_utility
   make script
   

   Executable script nan_test is located in nan_utility/script/.

NAN Application Example

To establish a Data Path between NAN devices, prepare two sets of equipment, and complete the NAN porting and NAN Utility porting mentioned above.

Note

When executing commands in the example, please replace the MAC addresses with the actual NAN MAC addresses of your devices. After NAN is started on the device, you can get the address information of the nan0 interface using the ifconfig command, as shown below:

root@raspberrypi:/# ifconfig

nan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
      inet6 fe80::2e2:4cff:fe00:102d  prefixlen 64  scopeid 0x20<link>
      ether 00:e2:4c:00:10:2d  txqueuelen 1000  (Ethernet)
      RX packets 0  bytes 0 (0.0 B)
      RX errors 0  dropped 0  overruns 0  frame 0
      TX packets 6  bytes 516 (516.0 B)
      TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Case 1 - Setup Open NDP

Wi-Fi NAN Open NDP Setup Flow

Execute commands as listed in the following table to establish an open NDP.

Step	Device A(NDP Responder) MAC: 00:11:22:33:44:55	Device B(NDP Initiator) MAC: 66:55:44:33:22:11	Description
1	nan_test init nan_test start pref 128 bands 2GHz 5GHz		Device A initializes NAN in 2GHz & 5GHz.
2		nan_test init nan_test start pref 5 bands 2GHz 5GHz	Device B initializes NAN in 2GHz & 5GHz.
3	nan_test add_func type publish unsolicited name nanservice data_path		Device A publish an open service unsolicitedly.
4		nan_test add_func type subscribe name nanservice	Device B passively subscribe to the service.
5		nan_test data_req req_type ndp rsp_nan_mac 00:11:22:33:44:55 publish_id 1	Device B sends a Data Path Request command to Device A to set up NDP.
6	nan_test data_rsp rsp_mode peer ndl_rsp accept data_path_id 1		Device A accepts NDP request and sends a Data path Response command to set up NDP.
7	nan_test set_ipv6 nan_test set_neigh 66:55:44:33:22:11	nan_test set_ipv6 nan_test set_neigh 00:11:22:33:44:55	Device A & B set self IPv6 link-local addresses and set peer as IPv6 neighbor.
8	ping6 fe80::6655:44ff:fe33:2211%nan0		Device A ping Device B via IPv6.
9		ping6 fe80::0011:22ff:fe33:4455%nan0	Device B ping Device A via IPv6.

Case 2 - Setup Secure NDP

Wi-Fi NAN Secure NDP Setup Flow

Execute commands as listed in the following table to establish a secure NDP.

Step	Device A(NDP Responder) MAC: 00:11:22:33:44:55	Device B(NDP Initiator) MAC: 66:55:44:33:22:11	Description
1	nan_test init nan_test start pref 128 bands 2GHz 5GHz		Device A initializes NAN in 2GHz & 5GHz.
2		nan_test init nan_test start pref 5 bands 2GHz 5GHz	Device B initializes NAN in 2GHz & 5GHz.
3	nan_test add_func type publish unsolicited name nanservice data_path sec_pmk 123456789abcdef0123456789abcdef0		Device A publish an open service unsolicitedly and announce it supports ND-TKSA (SDEA with Unicast NDP required and Security Required).
4		nan_test add_func type subscribe name nanservice	Device B passively subscribe to the secure service.
5		nan_test data_req req_type ndp rsp_nan_mac 00:11:22:33:44:55 sec publish_id 1 sec_pmk 123456789abcdef0123456789abcdef0	Device B sends a Data Path Request command with sec_pmk to Device A to set up NDP.
6	nan_test data_rsp rsp_mode peer ndl_rsp accept data_path_id 1		Device A accepts NDP request and sends a Data path Response command to set up NDP.
7	nan_test set_ipv6 nan_test set_neigh 66:55:44:33:22:11	nan_test set_ipv6 nan_test set_neigh 00:11:22:33:44:55	Device A & B set self IPv6 link-local addresses and set peer as IPv6 neighbor.
8	iperf -s -i 1 -V		Device A starts iperf server.
9		iperf -c fe80::0011:22ff:fe33:4455%nan0 -i 1 -t 30 -V	Device B starts iperf client, establishing TCP connection with Device A.

nan_test Usage Reference

Command parameter	Usage	Comment
-h	show help message
status	show current NAN status	Include the following information: Module existence Main interface down/up NAN interface existence
init	Init NAN interface Example: nan_test init	Register nan0 interface by this command. iw dev result show Interface nan0, and it share the same phy with wlan0
deinit	deinit NAN interface Example: nan_test deinit	Un-register nan0 interface by this command.
start [pref <value>] [bands [2GHz] [5GHz]]	Start NAN Example: nan_test start pref 5 bands 2GHz 5GHz	pref: Master Preference, Default pref = 5 bands: (publish) Support bands, 2GHz or 2GHz 5GHz
stop	Stop NAN
add_func type <publish|subscribe|followup> [solicited] [unsolicited] name <name> optional param: [info <info>] [active] [bcast] [flw_up_id <id> flw_up_req_id <id> flw_up_dest <mac>] [srf <include|exclude> <bf|list> [bf_idx] [bf_len] <mac1;mac2…>] [rx_filter <str1:str2…>] [tx_filter <str1:str2…>]	Add a NAN function with or without filters Example: nan_test add_func type publish unsolicited name android data_path nan_test add_func type subscribe active name nan_service	type: the type of the adding service solicited / unsolicited: (publish) only present when service type is publish indicate the service is solicited or unsolicited publish name: service name from which service id is generated and is not case sensitive default name : org.wifi.nan.test info: could be a simple buffer or a formatted buffer. A simple buffer will be appended to SDA attribute. A formatted buffer started with supported OUI is expected as a well-structured service Info and will be appended to SDEA. Currently, user can only choose one kind of service info for a service, and driver only support OUI specified in ref[1]. active: (subscribe) only present when service type is subscribe present if the service is active subscribe bcast: (publish) only present when the service is solicited publish present if the service is broadcasting as well Follow up service the following parameters are presented only when service type is followup flw_up_id: (followup) the instance id of the local publish or subscribe service which this followup service wants to follow flw_up_req_id: (followup) the instance id of the remote publish or subscribe service flw_up_dest: (followup) the nmi of the remote publish or subscribe service Service response filter the following parameters are presented only when srf is configured include / exclude indicate the srf is as a white list or a black list list <mac1;mac2…> indicate a list for memory comparing with peers’ nmi e.g. type subscribe active srf include list “00:11:22:33:44:55;66:55:44:33:22:11” bm bf_idx bf_len <mac1;mac2…> indicate the method and the components to generate a bloom filter e.g. type subscribe active srf include bf 3 16 “00:11:22:33:44:55;66:55:44:33:22:11” Matching filter rx_filter <str1:str2…> tx_filter <str1:str2…> e.g. 1 type publish solicited rx_filter RTK:ABCD:A23D type subscribe active tx_filter RTK e.g. 2 type publish unsolicited tx_filter ::* type subscribe passive rx_filter none
rm_func <cookie>	Remove a NAN function with cookie	Cookie is shown when add func.
data_req support param: [req_type <ndp>] [rsp_nan_mac <mac_addr>] [sec] [publish_id <id>] [min_duration <value>] [max_latency <value>] [sec_pmk <key_content | pairing>] [srv_info <hex_data>] [port_num <value>] [hostname <str>]	NAN data request Example: nan_test data_req req_type ndp rsp_nan_mac 00:11:22:33:44:55:66 publish_id 1	req_type: type for data request; only ndp is supported rsp_nan_mac: the mac address of ndp responder sec: present if security data path is required publish_id: specified the instance id of the peer service note: if the id is not specified, the first service of rsp_nan_mac will be selected as publish_id. min_duration: minimum number of available nan slots needed per dw interval. (unit: nan slot) present if qos is required (check NDL QoS attr in nan spec for more details) max_latency: maximum nan slots between every two non-contiguous NDL CRBs. (unit: nan slots) present if qos is required (check NDL QoS attr in nan spec for more details) sec_pmk: only present when the sec is set specified the pmk for secured ndp setup value: pmk content: e.g. sec_pmk 123456789ABCDEF0123456789ABCDEF1 (note: the length of pmk should be 32) pairing: use this value if nan pairing is processed before the ndp setup (the pmk will be generated automatically after nan pairing is completed.) sec_password: only present when the sec is set specified the password using to extend to the pmk for secured ndp setup note: the max length of password is 32 srv_info: the info should be presented in hex format, and separated by comma. e.g. srv_info 50,6f,9a,02,00,02,00,58,1b,01,01,00,06 note: service info could be in various formats, but for the current command set, srv_info is expected as a simple buffer that is going to append to the NDP attribute. port_num Transport Port : Current port on which the service is listening. if this parameter is set, NDPE will append service info with generic service fromat, and ignore srv_info parameter hostname hostname: DNS-SD hostname. if this parameter is set, NDPE will append service info with generic service fromat, and ignore srv_info parameter
data_rsp support param: [rsp_mode <peer | auto>] [ndl_rsp <reject | accept>] [data_path_id <id>] [publish_id <id>] [initiator_data_address <mac_addr>] [min_duration <value>] [max_latency <value>] [srv_info <hex_data>] [port_num <value>] [hostname <str>]	NAN data response Example: nan_test data_rsp rsp_mode peer ndl_rsp accept data_path_id 1	rsp_mode: response mode value: peer, auto ndl_rsp: response status value: reject, accept data_path_id: present when the rsp_mode is peer the ndp id created by the initiator (check ndp attr in nan spec for more details) publish_id: present when the rsp_mode is auto the instance id of the peer’s publish service initiator_data_address: present when the rsp_mode is peer the mac addr of initiator min_duration: minimum number of available nan slots needed per dw interval. (unit: nan slot) present if qos is required (check NDL QoS attr in nan spec for more details) max_latency: maximum nan slots between every two non-contiguous NDL CRBs. (unit: nan slots) present if qos is required (check NDL QoS attr in nan spec for more details) srv_info: the info should be presented in hex format, and separated by comma. e.g. srv_info 50,6f,9a,02,00,02,00,58,1b,01,01,00,06 note: service info could be in various formats, but for the current command set, srv_info is expected as a simple buffer that is going to append to the NDP attribute. port_num Transport Port: Current port on which the service is listening. if this parameter is set, NDPE will append service info with generic service fromat, and ignore srv_info parameter hostname hostname: DNS-SD hostname. if this parameter is set, NDPE will append service info with generic service fromat, and ignore srv_info parameter
data_end [ndp_id <id>] [initiator_ndi <mac>]	NAN data end
set_ipv6	Set own ipv6 link-local address based on mac address via ifconfig	automatically convert own mac address to ipv6 address
set_neigh <dst_mac>	Set neighbor ipv6 link-local address with dst mac address	automatically convert dst mac address to ipv6 address