IrDA Driver Stacks in Windows Mobile 6.5

In Windows Mobile 6.5, Infrared Data Association (IrDA) driver stacks managed line-of-sight communication by abstracting optical hardware into standard networking protocols. The operating system mapped infrared communication into the Windows Sockets (Winsock) framework, allowing applications to discover nearby devices and transfer data without handling raw optical signals. Behind this user-level interface, a multi-layered driver stack controlled device discovery, optical link parameters, packet sequencing, and error recovery, maintaining reliable half-duplex communication over short, directed infrared beams.

The IrDA Protocol Layers

The core of Windows Mobile 6.5's infrared subsystem was split into three primary protocol layers that sat above the hardware and below the application layer:

  1. IrLAP (Infrared Link Access Protocol): Operating at the data link layer, IrLAP established the peer-to-peer connection between devices. It handled device discovery, negotiated transmission speeds, verified data integrity using Cyclic Redundancy Checks (CRC), and established a primary/secondary (master/slave) relationship to prevent transmission collisions over the shared optical medium.
  2. IrLMP (Infrared Link Management Protocol): Positioned directly above IrLAP, IrLMP enabled multiplexing. It allowed multiple virtual channels to operate simultaneously over a single optical link. IrLMP also hosted the Information Access Service (IAS), a device directory where local services registered their presence and queried the capabilities of the peer device.
  3. TinyTP (Tiny Transport Protocol): TinyTP provided per-channel flow control. Because mobile devices had limited memory buffers, TinyTP prevented receiving applications from being overwhelmed with incoming packets by managing transmission credits between endpoints.

Hardware Abstraction and the Miniport Driver

At the base of the stack, Windows Mobile used miniport drivers to bridge software protocols to physical transceivers. The transceiver hardware typically consisted of an infrared LED, a PIN photodiode receiver, and an encoder/decoder chip connected to a UART (Universal Asynchronous Receiver-Transmitter).

The IrDA miniport driver controlled the physical signaling. For standard Serial Infrared (SIR), the driver formatted outgoing UART bytes into 3/16th bit-duration optical pulses using Return-to-Zero-Inverted (RZI) modulation at speeds up to 115.2 kbps. On devices that supported Fast Infrared (FIR) at up to 4 Mbps, the driver engaged specialized Direct Memory Access (DMA) controllers and 4PPM (Four-Pulse Position Modulation) schemes to bypass UART limitations and minimize CPU utilization.

Managing the Line-of-Sight Connection

Because infrared requires an unobstructed optical path—typically limited to a 30-degree cone and a range of one meter—the IrLAP layer enforced rigid connection routines to handle physical instability:

  • Discovery Phase: The initiator periodically broadcast dynamic discovery packets (XID frames) across standardized discovery slots. The driver adjusted transmission parameters to the minimum base rate (9600 bps) to maximize optical reception reliability during discovery.
  • Link Parameter Negotiation: Once a peer responded, both devices negotiated parameters, including maximum turnaround time, data packet size, window size, and baud rate, matching the capabilities of the weaker transceiver.
  • Temporary Occlusion Recovery: If a physical obstruction momentarily broke the line of sight (such as a hand moving through the beam), the IrLAP layer did not immediately drop the connection. Instead, it triggered a configurable link timeout timer. During this window, the stack repeatedly sent supervisory frames to query the peer. If the line of sight was restored before the timeout expired, the stack re-synchronized frame sequence numbers and resumed transmission without interrupting upper-level applications.