The IrDA protocol stack consists of multiple protocol layers, with only three required in a minimal implementation (IrMAC, IrLAP, and IrLMP). The other layers are optional based on the requirements of the target system (see http://www.irda.org/standards/standards.asp for details).

    At the lowest layer (IrMAC), the IrDA specification provides for three different physical layer protocols over the infrared medium. At the lowest (physical) layer, an implementation is required to support the Serial Infrared (SIR) physical layer (this provides a common medium to negotiate other parameters) and can optionally support the faster version, Fast Infrared (FIR).

    The first of the protocols is SIR, which defines an asynchronous serial communications format with a maximum speed of 115,200bps using one start bit, eight data bits and one stop bit. One benefit of the SIR format is that existing COM ports can be used as a very inexpensive interface to the device.

    The second protocol at the physical layer is FIR for high-speed 4Mbps connections in wireless LAN environments.

    Building on top of the SIR/FIR physical layer, the data link layer of an IrDA stack implements several protocols. Two of the most important are IrLAP and a discovery protocol. IrLAP is a variant of the high-level data link control (HDLC) and synchronous data link control (SDLC) protocols with modifications for handling some unique features of infrared communication. IrLAP provides for reliable data transfer, freeing upper layers from those responsibilities. However, it only guarantees that if a frame is received by the destination device, it is received error-free. It does not guarantee delivery of complete streams of application data. If frames are dropped due to a transmission error (such as someone blocking the infrared beam), IrLAP will notify higher-level protocols so that those protocols can take appropriate corrective actions.

    The discovery protocol is used during connection establishment and during device enumeration queries (more on those later). By using this protocol, a device can enumerate all visible devices that are currently in range, as well as obtain hinting information like device type and preferred character sets. I'll show you how to access this information from within a program in the main article.

    A typical IrDA implementation adds a third layer, the network layer. At this layer, IrDA specifies two protocols: IrLMP and TinyTP. IrLMP implements service access points to allow multiple sessions to communicate simultaneously over IrLAP. In IrDA terms, these service access points are referred to as Link Service Access Point Selectors (LSAP-SELs).

    LSAP-SELs are analogous to the TCP/IP port numbers, since there is not a transport layer protocol in IrDA to provide a similar service. To minimize the amount of data sent over an infrared connection, only seven bits used in an LSAP-SEL. Applications are normally identified via the Information Access Service (IAS), which I'll describe below, so that no hardcoded LSAP-SEL values are used. As compared to TCP/IP, where port 80 is reserved for HTTP data, you would create a service name in the IAS like "HTTP Provider" and the remote device would use IAS to query the underlying LSAP-SEL.

    The TinyTP protocol adds two functions to the IrDA stack. The first function is the addition of flow control on a per-LMP connection basis. Working with IrLMP, TinyTP will help to ensure that an application will not overflow data buffers on either the sending or receiving machines.

    The second function that TinyTP adds is segmentation and reassembly. TinyTP will break down large chunks of data from applications into multiple pieces for delivery, and piece it back together on the receiving side. These subdata items are referred to as service data units (SDUs). The actual size of an SDU is negotiated between TinyTP and IrLMP on both the source and destination machines while establishing the connection.

    In addition to the basic communications provided by the lower three layers of the protocol stack, IrDA also has several other features that are worth mentioning.

Information Access Service

    IAS is a directory service protocol for services running on a device running an IrDA protocol stack. One of its primary purposes is to allow services on a machine to add an entry in the local IAS for its LSAP-SEL. Client applications on other machines can then query and obtain this value and establish a connection.

    The IAS can also be used as a generic database of objects that can be accessed by clients of the device. Information in the IAS is organized as objects of a particular class name with associated attributes. A client application connecting to another system can query the remote machine's IAS for information on a particular object class. I'll show how to use this feature in the main article.

IrDA Addressing

    When an application establishes a connection between itself and another machine, it must specify the logical address of the target machine in the connect socket call. However, IrDA devices do not have fixed addresses. So how do you go about establishing a connection with another machine if you don't know its address?

    The process of establishing connections between two machines requires that the connecting machine know the LSAP-SEL of the process on the destination machine. But this adds an additional problem: how does the source machine know the LSAP-SEL of a process on another machine if it cannot talk to it?

    Establishing connections is accomplished by TinyTP, which automatically performs an IAS query during a connect socket call to obtain the LSAP-SEL of the remote service. When a server service on a machine is initialized, it will perform a socket bind function specifying an ASCII name for the service. A client then can specify this service by name when it performs the connect socket call. TinyTP and IrLMP will then perform the IAS query for the LSAP-SEL and establish the connection between the services on the two machines. This process is equivalent to performing a TCP/IP socket bind to an IP address and port.

    When two IrDA devices come within range of each other, the data link layer of each device performs a discovery process. A service on either machine can then use the getsock-opt socket function to enumerate the information that has been discovered by the local machine. Through this process, a device can learn the identity of nearby devices and attempt to connect to services on those machines.

Device Hints

    On Windows 2000-based systems, the getsockopt query for discovery information is expected to return not only the names and addresses of other devices within range, but also what is referred to as hinting information. (Windows CE does not support this feature at this time.) This hinting information should provide additional details such as the type of device (printer, palmtop, modem, and so on), and what character set the device prefers to communicate with.

    This can be quite useful if you are trying to dynamically connect a particular type of device such as a printer, but multiple devices are in range. This hinting can therefore allow your application connect to the candidate system that best fits your needs. The server application included with this shows how to access and use hinting information.

Communication Speed Negotiation

    During IrDA connection establishment, all devices communicate at 9600bps, eight bits, and no parity to ensure that they are using the same communications rules. Once a successful connection is established, the two systems exchange communications capabilities and will upshift the communications speed as far as both sides are capable.

For More Information

    This information is only starts to explain the operation of IrDA. For more details, I recommend checking out the Counterpoint Systems Foundry Web site at http://www.counterpointsys.com and the IrDA organization Web site at http://www.irda.org. They have several very good whitepapers on the IrDA protocols and their implementations.