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

# Optimizing Ditto Wi-Fi Aware for Your Android Hardware

> How to identify your Android device's Wi-Fi concurrency mode and configure Ditto for reliable Wi-Fi Aware operation.

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.

<Note>
  This article applies to Android devices only. In Ditto, iOS and macOS use Apple Wireless Direct Link (AWDL)
  for P2P Wi-Fi, which is unaffected by the considerations below.
</Note>

***

## Step 1: Identify Your Hardware's Concurrency Mode

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

| Mode                                 | What it means                                                             | Wi-Fi Aware + AP Stability                       |
| ------------------------------------ | ------------------------------------------------------------------------- | ------------------------------------------------ |
| **DBS** — Dual Band Simultaneous     | Two independent radios; each handles a separate band with no interference | ✅ Stable — recommended                           |
| **SCC** — Single Channel Concurrency | One radio; both connections share the same channel                        | ✅ Stable — requires AP channel alignment         |
| **MCC** — Multi-Channel Concurrency  | One radio; time-slices between channels                                   | ⚠️ Unreliable — common cause of device islanding |

### 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

| Chipset                             | LMAC Count      | DBS Capable | Notes                                                                     |
| ----------------------------------- | --------------- | ----------- | ------------------------------------------------------------------------- |
| Qualcomm WCN6755                    | 1 (single-LMAC) | ❌ No        | Used in Samsung Galaxy Tab Active5 Pro; confirmed MCC islanding incidents |
| Qualcomm WCN6750                    | 1 (single-LMAC) | ❌ No        | Similar architecture to WCN6755                                           |
| Qualcomm FastConnect 6900 / WCN6855 | 2 (dual-LMAC)   | ✅ Yes       | Recommended for Wi-Fi Aware + AP concurrency                              |
| Qualcomm FastConnect 6800           | 2 (dual-LMAC)   | ✅ Yes       | 4-stream DBS variant also available                                       |

<Note>
  This table covers commonly encountered chipsets. If your chipset is not listed, check the manufacturer's WLAN
  datasheet or [contact Ditto Support](https://support.ditto.com) with your device model and Android logs.
  Ditto Support can analyze `dumpstate` / `dumpsys wifi` output to identify MCC signatures.
</Note>

***

## Step 2: Configure Ditto Based on Your Hardware Mode

<Warning>
  Regardless of chipset mode, always keep Bluetooth Low Energy (BLE) enabled on devices running Ditto with
  Wi-Fi Aware. BLE operates on a separate radio and is unaffected by Wi-Fi concurrency constraints. If
  Wi-Fi Aware fails or the AP connection drops for any reason, Ditto falls back to BLE to maintain peer
  connectivity. Disabling BLE removes this fallback and significantly increases islanding risk.
</Warning>

### 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)

<Warning>
  MCC is the most common cause of Wi-Fi Aware–related device islanding in Ditto deployments. On single-LMAC devices,
  the radio must time-slice between the AP channel and the Wi-Fi Aware NAN discovery channel. This can cause missed
  AP beacons, acknowledgment failures, and full AP disconnection — all while Wi-Fi appears enabled on the device.
</Warning>

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](https://support.ditto.com)
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:

| Parameter                                        | Description                                        |
| ------------------------------------------------ | -------------------------------------------------- |
| `TRANSPORTS_WIFI_AWARE_MAX_ERROR_COUNT`          | Number of error events before Wi-Fi Aware restarts |
| `TRANSPORTS_WIFI_AWARE_RECENT_ERROR_DURATION_MS` | Time window in which error events are counted      |

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](https://support.ditto.com) 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](#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:

<Tip>
  Request the device's full WLAN specification sheet and confirm the Wi-Fi chipset part number. Look explicitly
  for "Dual Band Simultaneous (DBS)" in the WLAN section — and verify that this refers to dual independent LMACs
  at the silicon level, not just dual-band frequency support.
</Tip>

**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

| Scenario                                                      | Likely Cause                     | Action                                                                             |
| ------------------------------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------- |
| Devices island when AP is on 5 GHz and Wi-Fi Aware is enabled | MCC on single-LMAC chipset       | Verify chipset; enable BLE fallback; apply SCC/ICM mitigations or upgrade hardware |
| Wi-Fi Aware works but AP disconnects periodically             | MCC beacon loss                  | Enable BLE fallback; consider SCC channel alignment                                |
| `onSessionConfigFailed` loop in Ditto logs                    | Wi-Fi Aware subsystem stuck      | Check for MCC; tune error thresholds; verify BLE fallback                          |
| No Wi-Fi Aware peers despite transport enabled                | MCC exhaustion or firmware issue | Disable and re-enable Wi-Fi Aware; review driver logs for DELBA/beacon-loss        |
| Works on some devices in fleet, not others                    | Mixed chipset models             | Audit chipset models across device inventory                                       |

***

## Related Resources

* [Mesh Networking Overview](/key-concepts/mesh-networking)
* [Wi-Fi Aware Checker App](https://github.com/getditto/wifi-aware-checker) — test whether a device supports Wi-Fi Aware
* [Android Developer: Wi-Fi Aware](https://developer.android.com/develop/connectivity/wifi/wifi-aware)
* [Android AOSP: Wi-Fi STA/AP Concurrency](https://source.android.com/docs/core/connect/wifi-sta-ap-concurrency)

If you are experiencing Wi-Fi Aware instability and are unsure whether it is chipset-related,
[contact Ditto Support](https://support.ditto.com) 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.