Get<Mac::Mac>().SetEnabled

[arun-mahasenan]

In ThreadNetif::Up(), OT code set GetMac::Mac().SetEnabled(true);
Why is GetMac::Mac().SetEnabled(false) not set in ThreadNetif::Down()?

[jwhui]

The asymmetry—enabling the MAC when the interface goes up, but not disabling it when the interface goes down—stems from a strict Separation of Concerns in OpenThread's architecture between the Network Layer (Thread IP/MLE) and the Link Layer (802.15.4 MAC).

Here is the technical breakdown of why Get<Mac::Mac>().SetEnabled(false) is intentionally omitted in ThreadNetif::Down():

1. Independent Link-Layer Operations

Even when the Thread network interface is "Down" (meaning IPv6 routing, Mesh Link Establishment, and upper-layer protocols are halted), the device may still need the physical and MAC layers to remain active. For example, an application might need to perform an Active Scan (looking for 802.15.4 beacons), an Energy Scan (assessing channel noise), or to listen for raw, low-level commissioning frames. If ThreadNetif::Down() automatically disabled the MAC, it would abruptly break these underlying operations.

2. Shared Radio and Multiprotocol Support

Many modern IoT SoCs use dynamic multiprotocol (DMP) to share a single radio between Thread and other protocols like Bluetooth Low Energy (BLE), Zigbee, or proprietary 802.15.4 stacks. The OpenThread MAC layer is often involved in arbitrating this radio time. Unconditionally shutting down the MAC layer just because the Thread IPv6 interface went down could forcefully kill the radio for other concurrent protocols.

3. Layer Dependency Logic (The Asymmetry)

The logic in Up() and Down() serves two fundamentally different purposes:

• On Up() (Enforcement): The Thread network interface physically cannot function without the MAC layer being active. Calling SetEnabled(true) acts as a dependency enforcer—guaranteeing the underlying transport is ready before bringing up the IP stack.
• On Down() (Agnosticism): When the Thread network interface tears down, it simply stops passing traffic to the MAC. It doesn't actually care if the MAC remains active. By leaving the MAC state alone, it delegates the decision of powering off the radio to the application or a dedicated link-layer controller.

4. Explicit Link Control via API

OpenThread is designed to give developers granular control over state management. If a developer genuinely wants to power down the MAC and the radio to enter a deep sleep state, they are expected to explicitly call link-layer APIs (such as otLinkSetEnabled(false)). Tying the MAC teardown directly to ThreadNetif::Down() would conflate the Network and Link layers, stripping power-management control away from the application.

---

Summary: ThreadNetif::Up() enables the MAC because it is a strict prerequisite for network operations. ThreadNetif::Down() leaves the MAC alone because shutting it down is a link-layer decision that could interrupt background scans, disrupt parallel protocols, or override the application's explicit power management strategy.