Optimizing Ditto Wi-Fi Aware for Your Android Hardware

Documentation Index

Fetch the complete documentation index at: https://docs.ditto.live/llms.txt

Use this file to discover all available pages before exploring further.

Wi-Fi Aware (Neighbor Awareness Networking, or NAN) is a high-speed Android peer-to-peer transport that Ditto uses to form its mesh network. Whether it runs reliably alongside a standard Wi-Fi AP connection depends on your device’s Wi-Fi chipset architecture. This page helps you:

1. Identify which concurrency mode your hardware supports — SCC, MCC, or DBS.
2. Act on that information to optimize Ditto for your specific hardware.

---

​

Step 1: Identify Your Hardware’s Concurrency Mode

Android Wi-Fi chipsets handle concurrent connections (Wi-Fi Aware + AP) in one of three ways:

​

How to Find Your Device’s Mode

The mode your device operates in is determined by its Wi-Fi chipset, not its Android version or marketing specs. A device advertised as “Dual Band” is not necessarily DBS-capable — that label only means it can connect to either 2.4 GHz or 5 GHz networks, not that it can operate on both simultaneously. Check the chipset model using one of these methods:

1. Android diagnostics: Run adb shell dumpsys wifi and look for the chipset or WLAN driver identifier in the output.
2. Device technical spec sheet: OEM spec sheets often list the Wi-Fi chipset model number. Marketing sheets typically do not.
3. Reference table below: If your device uses a known chipset, check the table.

​

Chipset Reference

---

​

Step 2: Configure Ditto Based on Your Hardware Mode

​

DBS Hardware

DBS devices have two independent radio chains (LMACs) and can run Wi-Fi Aware and an AP connection simultaneously with no interference between them. No special Ditto configuration is required. Recommended actions:

• Validate in a lab environment: run Ditto with Wi-Fi Aware enabled on a 5 GHz AP and monitor for onSessionConfigFailed errors and AP beacon loss over at least a 1-hour test window.
• If a carrier variant of your device exists, obtain the WLAN spec for that specific variant — an additional cellular radio may introduce concurrency constraints not present in the standard model.

​

SCC Hardware

In SCC, the AP connection and Wi-Fi Aware share the same channel. Because there is no time-slicing, SCC is stable. However, your AP must be configured on a compatible channel for SCC to occur naturally. Recommended actions:

• Pin your infrastructure AP to 2.4 GHz channel 6. This aligns it with the Wi-Fi Aware NAN Discovery Window channel, keeping both connections on the same channel without radio switching.
• Be aware that 2.4 GHz offers lower throughput than 5 GHz. Evaluate whether this trade-off is acceptable for your use case.

​

MCC Hardware (Single-LMAC)

MCC cannot be fully eliminated without DBS-capable hardware, but the following mitigations reduce instability significantly. Apply these mitigations in order of impact:

​

1. Align Your AP to Channel 6 (Force SCC)

If your AP can be pinned to 2.4 GHz channel 6, both the AP connection and Wi-Fi Aware NAN discovery will operate on the same channel, eliminating the need for time-slicing. This converts MCC behavior into SCC. This trade-off reduces infrastructure Wi-Fi throughput (5 GHz is significantly faster). Evaluate whether the trade-off is acceptable for your use case before applying it fleet-wide.

​

2. Disable Wi-Fi Aware Instant Communication Mode (ICM)

ICM is an optional Wi-Fi Aware feature that uses a 5 GHz channel for NAN data paths after discovery. On single-LMAC devices, ICM adds a third channel for the radio to juggle (2.4 GHz NAN discovery + 5 GHz ICM data path + 5 GHz AP), which increases MCC instability. Ditto provides a system parameter to disable ICM. Contact Ditto Support for guidance on applying this parameter for your SDK version and deployment configuration.

​

3. Tune Wi-Fi Aware Error Recovery Thresholds

Ditto’s Wi-Fi Aware stack includes a configurable error detector that restarts the Wi-Fi Aware subsystem when errors accumulate past a threshold. On MCC-affected devices, tuning these parameters can improve recovery speed: Lowering these values makes the subsystem restart more aggressively when errors are detected. Setting them too low can cause premature restarts when Wi-Fi Aware is actually functional. Work with Ditto Support to determine appropriate values for your hardware.

​

4. Evaluate a Hardware Upgrade

If MCC-related instability persists after applying the above mitigations, the most reliable long-term solution is to transition to DBS-capable hardware. See the chipset reference table above for confirmed DBS chipsets, and refer to Hardware Procurement below.

---

​

Diagnosing MCC-Related Problems

If you are unsure whether your device is experiencing MCC issues, look for these symptoms:

• Periodic Wi-Fi disconnects that recover on their own, or require an app restart/device reboot
• Ditto reports zero Wi-Fi Aware peers even though the SDK reports Wi-Fi Aware as enabled
• Ditto SDK logs show onSessionConfigFailed errors in a repeating loop
• AP disconnects coincide with high Wi-Fi Aware activity (e.g., when a new device joins the mesh)
• Devices that are stable when Wi-Fi Aware is disabled but unstable when it is re-enabled

In Android system logs (dumpstate / dumpsys wifi), MCC activity may be visible as:

• Rapid band/channel switching between 2.4 GHz and 5 GHz at short intervals
• DELBA frames in host driver logs
• Beacon loss events followed by deauthentication

---

​

Hardware Procurement

For new hardware purchases, Ditto recommends the following evaluation criteria: DBS Validation Checklist:

1. Confirm the chipset model (e.g., Qualcomm FastConnect 6900, WCN6855, or DBS-equivalent from other vendors).
2. Verify the chipset datasheet or OEM technical guide confirms dual-LMAC architecture.
3. If a carrier variant of the device exists, obtain the full spec for that variant — additional cellular radios may introduce concurrency constraints.
4. Validate in a lab environment: run Ditto with Wi-Fi Aware enabled on a 5 GHz AP and monitor for onSessionConfigFailed errors and AP beacon loss over a minimum 1-hour test window.
5. Confirm that BLE is available and enabled as a fallback transport.

---

​

Background: How Wi-Fi Chipset Architecture Affects Wi-Fi Aware

Wi-Fi Aware uses the 2.4 GHz band (channel 6) for its NAN Discovery Window — the periodic beacon-like signal that lets devices find each other. Once two devices discover one another, Ditto establishes a direct data path, which can operate on either 2.4 GHz or 5 GHz (via ICM). Most deployed Android devices are also connected to an infrastructure Access Point (AP), typically on the 5 GHz band. This creates a fundamental challenge: the device’s Wi-Fi radio must serve at least two different channels simultaneously. How the chipset handles this depends on whether it has one or two independent Lower MAC (LMAC) hardware chains:

• Single-LMAC: The one radio time-slices between channels (MCC), or both connections are forced onto the same channel (SCC).
• Dual-LMAC (DBS): Each radio chain handles one band independently — no time-slicing, no missed beacons.

In MCC, the failure chain that causes islanding is:

1. The radio leaves the 5 GHz AP channel to service the Wi-Fi Aware NAN Discovery Window on 2.4 GHz ch6.
2. While away, the device misses AP beacons. Consecutive misses (typically 3–7) trigger a beacon loss event.
3. The AP stops receiving acknowledgments and sends DELBA frames, tearing down the block ACK session.
4. Beacon timeout is reached — the device disconnects from the AP.
5. With the AP connection lost and no BLE fallback, Ditto loses all peers and cloud connectivity.

In severe cases, sustained MCC duty cycles can also cause firmware-level exhaustion events visible as critical reason codes in driver logs. Wi-Fi chipset architecture is a hardware constraint, not an OS constraint. Upgrading Android OS does not change the LMAC count. However, newer Android versions may include improved firmware for edge cases — known improvements in Android 15 and 16 have addressed some Wi-Fi Aware stuck-state behaviors on specific Pixel hardware. Ditto supports Wi-Fi Aware on Android 10 (API level 29) and higher.

---

​

Summary

---

​

Related Resources

• Mesh Networking Overview
• Wi-Fi Aware Checker App — test whether a device supports Wi-Fi Aware
• Android Developer: Wi-Fi Aware
• Android AOSP: Wi-Fi STA/AP Concurrency

If you are experiencing Wi-Fi Aware instability and are unsure whether it is chipset-related, contact Ditto Support with your device model, Android version, and Ditto SDK logs. Our team can help identify MCC signatures in the logs and recommend the appropriate mitigation path.