# Topology Comparison: Sample ACS Product vs M62

This note compares:
- the sample ACS export from another product
- the current M62 USP behavior observed in this lab

Goal:
- show why topology works on the other product
- show what is missing on M62
- show what engineering should fix first

Source file analyzed:
- [device-80691A-MX56CF-59N10M21E01910-2026-03-25T191800353Z.csv](/home/lucas/projects/oktopus/artifacts/sampleACS/device-80691A-MX56CF-59N10M21E01910-2026-03-25T191800353Z.csv)

## Executive Summary

The sample ACS product already exposes enough standard USP data to build a useful mesh topology view.

It works because it provides three important things together:

1. Node relationship data from `Device.Hosts.Host.{i}`
2. Wi-Fi client attachment data from `Device.WiFi.AccessPoint.{i}.AssociatedDevice.{i}`
3. Band and SSID mapping from `Device.WiFi.SSID.{i}` and `Device.WiFi.Radio.{i}`

The current M62 implementation does not yet expose this combination consistently enough.

Main gap on M62:
- `Device.Hosts.Host.{i}.ParentNodeID` is missing for some wired child-connected clients
- some topology and Wi-Fi enrichment fields are incomplete or not reliable enough yet

Recommended engineering order:
1. Fix `Hosts.Host`
2. Fix `AssociatedDevice`
3. Improve backhaul telemetry after that

## Why Topology Works On The Sample ACS Product

The sample ACS product exposes:

### `Device.Hosts.Host.{i}`

Observed useful fields:
- `DeviceRole`
- `ParentNodeID`
- `AssociatedDevice`
- `Layer1Interface`
- `HostName`
- `PhysAddress`
- `IPAddress`
- `DeviceID` for the child node entry

This is enough to identify:
- child node
- client devices
- which node a client belongs to
- whether the client is on Wi-Fi or Ethernet in many cases

### `Device.WiFi.AccessPoint.{i}.AssociatedDevice.{i}`

Observed useful fields:
- `MACAddress`
- `SignalStrength`
- `LastDataDownlinkRate`
- `LastDataUplinkRate`
- `OperatingStandard`
- `Active`

This is enough to identify:
- Wi-Fi client MAC
- RSSI
- rates
- per-client AP attachment

### `Device.WiFi.AccessPoint.{i}` + `Device.WiFi.SSID.{i}` + `Device.WiFi.Radio.{i}`

Observed useful fields:
- `AccessPoint.SSIDReference`
- `SSID.SSID`
- `SSID.LowerLayers`
- `Radio.OperatingFrequencyBand`

This is enough to identify:
- which SSID a client is on
- whether the client is on 2.4 GHz or 5 GHz

## Topology Reconstructed From The Sample ACS Product

### Node count

The sample export supports a 2-node topology:

1. Parent node
- inferred from `Device.DeviceInfo.DeviceID`
- value: `84A31AB5-F310-48A5-B5C0-80691A9F80E1`

2. Child node
- identified from `Device.Hosts.Host.6`
- `DeviceRole = slave`
- `DeviceID = 68A8285D-0361-44CB-AAD7-E89F8093B27D`
- `MAC = ee:9f:80:93:b2:7f`
- `IP = 192.168.1.62`

### Child-connected clients identified successfully

Clients with `ParentNodeID = 68A8285D-0361-44CB-AAD7-E89F8093B27D`:

- `192.168.1.79` `9c:65:eb:5c:1c:6e`
  - Wi-Fi
  - 5 GHz
  - RSSI `-45`
- `192.168.1.49` `c4:23:60:f2:23:21`
  - Wi-Fi
  - 2.4 GHz
  - RSSI `-55`
- `192.168.1.242` `74:84:69:59:34:36`
  - Wi-Fi
  - 5 GHz
  - RSSI `-73`
- `192.168.1.229` `ec:71:db:ff:2d:4b`
  - Ethernet
  - no RSSI expected
- `192.168.1.72` `96:0c:95:71:54:a0`
  - Wi-Fi
  - 5 GHz
  - RSSI `-46`

### Parent-connected clients identified successfully

Clients with `ParentNodeID = 84A31AB5-F310-48A5-B5C0-80691A9F80E1`:

- `192.168.1.111` `d2:b5:de:68:7f:a2`
  - Wi-Fi
  - 5 GHz
  - RSSI `-65`
- `192.168.1.47` `a8:b1:3b:42:2f:ef`
  - Wi-Fi
  - 2.4 GHz
  - RSSI `-58`
- `192.168.1.146` `90:ca:fa:b6:50:a0`
  - Wi-Fi
  - 5 GHz
  - RSSI `-65`
- `192.168.1.10` `fc:fe:c2:06:9b:05`
  - Wi-Fi
  - 2.4 GHz
  - RSSI `-74`

The child node itself is also visible as attached to the parent:
- `192.168.1.62` `ee:9f:80:93:b2:7f`
- role `slave`
- 5 GHz
- RSSI `-73`

## Remaining Imperfections In The Sample ACS Product

The sample ACS product is better than M62, but not perfect.

Observed gaps:
- no `WiFi.DataElements`
- no `MultiAP`
- no explicit `master` row under `Hosts.Host`
- some unmapped hosts still exist:
  - blank `ParentNodeID`
  - blank `Layer1Interface`
- one MAC appears duplicated in `AssociatedDevice`

So this is not a perfect model, but it is already good enough to build a useful topology.

## What Is Missing On M62

From current M62 testing in this lab:

### 1. `Hosts.Host.ParentNodeID` is incomplete

This is the biggest problem.

On M62:
- some child-connected wired devices do not report `ParentNodeID`
- this breaks node placement in topology
- support tools cannot tell which node those devices belong to

This is the highest-priority fix.

### 2. `Hosts.Host` is not consistently complete enough

On M62, some hosts also have gaps in:
- `HostName`
- `Layer1Interface`
- other host-identification fields

That makes support views weaker and creates more unmapped devices.

### 3. `AssociatedDevice` exists, but not all topology logic can rely on it alone

On M62:
- `AssociatedDevice` is useful for Wi-Fi client enrichment
- but it is not sufficient as the source of truth for topology

Reason:
- Ethernet clients behind child nodes may not appear there
- node placement still depends on `Hosts.Host`

### 4. M62 does not expose a good vendor replacement for `WiFi.DataElements`

Observed on M62:
- no `Device.WiFi.DataElements.*`
- no practical vendor-specific Wi-Fi topology tree already exposed
- `X_LINKSYS_MultiAPMode` exists, but is not reliable enough to use as the main topology anchor

## Recommended Fix Order For M62

## First Fix

Improve `Device.Hosts.Host.{i}`:
- `DeviceRole`
- `ParentNodeID`
- `Layer1Interface`
- `HostName`
- `DeviceID` where relevant

Expected result:
- parent/child/client relationship becomes usable
- wired child-connected clients can be placed correctly

## Second Fix

Improve `Device.WiFi.AccessPoint.{i}.AssociatedDevice.{i}`:
- `MACAddress`
- `SignalStrength`
- `LastDataDownlinkRate`
- `LastDataUplinkRate`
- `Active`

Expected result:
- Wi-Fi client enrichment becomes good
- UI can show band, SSID, RSSI, and rate cleanly

## Third Fix

Add structured backhaul telemetry if needed:
- example:
  - `Device.X_LINKSYS_Mesh.BackhaulLink.{i}.`

Expected result:
- support can see child-to-parent wireless quality directly
- no need to reverse-engineer it from local Linux-only data

## Recommended Logic For Both Products

This is the logic that works best:

### Use `Hosts.Host` for topology

Use:
- `DeviceRole`
- `ParentNodeID`
- `Layer1Interface`
- `DeviceID` where available

This decides:
- which device is parent
- which device is child
- which clients belong to which node

### Use `AssociatedDevice` for Wi-Fi enrichment

Use:
- `MACAddress`
- `SignalStrength`
- `LastDataDownlinkRate`
- `LastDataUplinkRate`
- `Active`

This adds:
- RSSI
- Wi-Fi link rate
- AP attachment

### Use `SSID` and `Radio` for SSID and band

Use:
- `AccessPoint.SSIDReference`
- `SSID.LowerLayers`
- `SSID.SSID`
- `Radio.OperatingFrequencyBand`

This adds:
- 2.4 GHz / 5 GHz labeling
- SSID naming

## Final Conclusion

The customer claim is substantially correct.

The sample ACS product already exposes enough standard USP data to:
- identify a child node
- identify clients
- map many clients to parent vs child
- show RSSI for Wi-Fi clients
- label 2.4 GHz vs 5 GHz attachment

The M62 should first aim to match this level of data quality.

Best first target for M62:
- make `Device.Hosts.Host.{i}` reliable enough to support topology

Best second target:
- make `AssociatedDevice` reliable enough to enrich Wi-Fi clients with RSSI and rate data

After those two are complete, M62 can improve further with explicit backhaul vendor objects.