How Windows Mobile 6.5 Routed Wi-Fi and Cellular

Windows Mobile 6.5 managed concurrent Wi-Fi and cellular connections through an operating system service called the Connection Manager alongside the core Windows CE TCP/IP stack. By default, the system prioritized unmetered, high-speed Wi-Fi links over cellular data for standard internet traffic while using metric-based routing tables and destination network mappings to handle multi-homing scenarios such as simultaneous MMS or corporate intranet delivery.

The Role of Connection Manager (ConnMgr)

At the core of network management in Windows Mobile 6.5 was the Connection Manager (ConnMgr). Rather than allowing applications to bind directly to a specific physical network adapter, the operating system abstracted connections into logical "Destination Networks" identified by GUIDs (such as "The Internet" or "Work").

When an application requested internet connectivity—typically by calling APIs like ConnMgrEstablishConnection or ConnMgrMapURL—Connection Manager evaluated the available physical adapters (NDIS miniports) mapped to that destination. It selected the optimal path based on predefined cost, speed, and latency profiles.

Metric-Based IP Routing

At the network layer, Windows Mobile 6.5 functioned as a multi-homed device using the Windows CE TCP/IP stack. When both Wi-Fi (802.11) and cellular data (GPRS, EDGE, or HSDPA via the Radio Interface Layer) were active concurrently, each adapter had its own IP address, subnet mask, and default gateway.

To prevent route conflicts, the system used interface metrics to determine which default route (0.0.0.0/0) took precedence:

  • Wi-Fi Precedence: The Wi-Fi adapter was assigned a lower route metric than the cellular interface. As a result, the kernel’s routing table directed all standard outbound IPv4 packets to the Wi-Fi gateway.
  • Cellular Fallback: The cellular default route remained in the routing table with a higher metric. If the Wi-Fi link dropped or failed to renew its DHCP lease, the lower-metric route disappeared, and outbound traffic immediately fell back to the cellular gateway without requiring the application to re-resolve the domain.

Split Routing and Concurrent Multi-Homing

Although general web browsing routed entirely through Wi-Fi when present, Windows Mobile 6.5 supported simultaneous data paths for specific traffic types through policy-based routing:

  • MMS Handling: Multimedia Messaging Service (MMS) traffic bypassed the general Wi-Fi route. The MMS client requested a connection mapped specifically to the cellular carrier's dedicated WAP/MMS Access Point Name (APN). The Connection Manager maintained the cellular PDP context and added static host or network routes specifically for the carrier's MMSC IP, routing that traffic over cellular while the rest of the device used Wi-Fi.
  • Corporate and VPN Routing: If a device was configured to access a "Work" network, Connection Manager could maintain an active cellular or Wi-Fi VPN tunnel while standard internet traffic was split according to the device's routing table rules.

Radio Power and State Arbitration

To conserve battery life, Windows Mobile 6.5 included logic to tear down or suspend idle cellular data sessions once an active Wi-Fi connection was verified. However, carrier customizations often governed this behavior. Some OEM configurations maintained the cellular PDP context in an idle, dormant state while Wi-Fi carried the payload, allowing instantaneous handoff back to cellular data the moment the device moved out of Wi-Fi range.