IrLAP: Infrared Wireless Link Access Protocol

By Mike Rodbell

The more general services provided by IrLAP are discussed, along with an introduction to the HDLC basics employed in the protocol.

Continuing our journey through the Infrared Data Association's (IrDA) wireless standards, let's review the IrDA link access protocol (IrLAP). Recognizing that many of the link access protocol issues have been addressed through the well-worn high level data link control (HDLC) protocol, IrLAP chooses not to reinvent the wheel, but rather to fit it to a new axle with a few useful adjustments. While a background in the operation of HDLC is useful, if you're involved in implementing an IrDA interface, plan on spending a bit of time with the IrLAP protocol standards - as you can expect to find a healthy share of unique twists and turns.

The version of IrLAP that we'll cover is one that is widely supported in the world of IrDA (as opposed to some of the more recently researched areas). Version 1.1 is used to support the transfer of information between two devices that are interconnected using the infrared serialization services of serial infrared (SIR), at all rates supported by SIR version 1.1. While more sophisticated features such as multipoint connections may be given attention, the standard is best understood in its current incarnation as a link layer protocol intended to support point-to-point connections over a half-duplex connection.

Half-duplex operation offers a unique set of challenges when providing services over a peer-to-peer protocol. Only one station can transmit at a time; if two stations transmit simultaneously, the transmissions collide, resulting in useless garbage. There are many techniques that could have been employed to allow the devices to communicate. The approach developed for IrDA is based on a master/slave arrangement, in which one of the stations controls all access to the infrared transmission media. The slave (or secondary) station will speak only when spoken to. Through this arrangement, collisions are inherently avoided with both stations abiding by the rules associated with their prescribed roles. In HDLC language, this is termed normal response mode (NRM).

Given the complexity of the topic of link layer protocol, this month I'll focus on some of the more general services provided by IrLAP and provide an introduction to the HDLC basics that are employed in the protocol. We can save some of the more sophisticated (and unique) features of IrLAP for next month.

Link layer services
It's generally useful to understand a protocol first from an outside perspective of the services it provides. In the case of IrLAP, think of the protocol (IrLAP) as a mechanism that can be used between two IrDA-capable machines to establish a logical relationship and transmit information at a relatively low level. The informational contents is an issue for upper-layer protocols. The actual format of the information in optical pulses is handled by the IrDA SIR protocol that we discussed in last month's article.

To help organize the descriptions of the different types of services provided by IrLAP, the specification identifies two general categories: connection-oriented services and connectionless services. To those of you who have spent much time with data communication standards, this shouldn't come as any surprise.

The connectionless services include the following:

• Discovery is a process where a station can determine if any devices are within range and available for communication.
• Address conflict provides a set of mechanisms to ensure that all stations participating in an optical link use unique link-layer addresses. In providing this service, if a duplicate address is detected, the IrLAP processes can negotiate new link addresses.
• Unit data provides a mechanism for the transport of unsequenced, broadcast data frames. This out-of-band traffic is often used for the routing and management of protocols that have requirements conflicting with the general nature of the services provided by connection-oriented protocols.

These services are primarily concerned with the general relationship of two adjacent machines and the transfer of information not normally associated with a logical connection.

The connection-oriented services include the following:

• Connect is the establishment of a logical connection between two devices across an IrDA SIR interface. Once the connect service has been completed, the IrLAP communication processes can transfer information over the resulting connection.
• Sniffing is a special low-power connect procedure intended to support devices with power-critical modes of operation.
• Data is the exchange of upper-layer protocol information. Data services include reliable (using HDLC sequencing) and unreliable (datagram frame transmissions).
• Status is a process that monitors the health of the IrDA link. In particular, the link quality is monitored for excessive noise and the presence of unacknowledged data transmissions.
• Reset is a process that, through mutual agreement of the two stations, causes all counters and timers to be reset.
• Disconnection is the actual termination of a connection between two IrLAP stations. When disconnecting, any unacknowledged data is discarded from local queues, with delivery not guaranteed.

These services are directly concerned with the establishment of a logical relationship between two stations, the management of that relationship (connection), and the reliable transfer of information between the two devices.

Finally, given that a range of services is provided by SIR, IrLAP also includes capabilities to provide framing for lower data-rate transmissions - necessary only for the asynchronous transmissions. The higher-speed transfer services provided by SIR have built-in framing.

Given these services, we can now explore some of the mechanisms behind providing them.

SIR framing and HDLC with IrLAP extensions
To understand the protocol exchanges used within IrLAP, it's a good idea to first understand the types of frames that are used in the protocol. If you've already invested some time in working with HDLC, there shouldn't be any significant surprises here. Most of the frames used by IrLAP are rehashes of the HDLC protocol; some changes of the basic frame types have been extended to support the unique features offered by IrLAP, and information has been added to the basic frames.

The HDLC frames are organized into three general categories of frames: un-numbered frames, supervisory frames, and information frames. The un-numbered frames are used to provide a broad range of services, including connection request management and unsequenced (datagram) information exchange. The supervisory frames contain sequencing information with no information and are used to control the flow of information within the constraints of a connection.The final group, information frames, contains both sequencing information and data for transmission within a connection.

At its most basic level, the HDLC frame consists of several components ( Figure 1 ). Looking at the frame as a collection of individual fields, regardless of the encoding, the IrLAP frame will consist of:

• A preamble is used to allow the receiving station to identify the beginning of a frame that follows. Within IrDA, the format of this sequence depends on the data rate and the corresponding encoding method. At low data rates that use asynchronous data encoding, the IrLAP appendix identifies a character-oriented coding scheme. At medium data rates, standard HDLC encoding is employed. Finally, at the highest 4-Mbps rate, the IrDA pulse position modulation (PPM) encoding scheme is used.
• An address immediately follows the preamble. While HDLC includes provisions for this field to be either 1 or 2 octets in length, IrDA employs only the 1-octet presentation. The address field consists of two components: the link address and the command/response (C/R) bit. When set, the C/R bit is used to indicate that the primary station is issuing a command to an indicated secondary station. When "0," the C/R bit indicates that a response is being generated by the secondary station.
• The control field octet is used to identify the type of frame, and in the case of S and I frames, carries additional sequencing information used to control the flow of information in a connection.
• The data (or information) field is used to transport additional information. This optional field is included in some of the un-numbered frames and is always present in the information frames.
• The frame check sequence , as in the case of the preamble, uses different frame-check sequences depending on the transmission data rate. Refer to last month's article for more details on the types of frame check sequences, used within SIR and IrLAP.
• The postamble is the presence of the trailer on the frame, which serves to complete the encapsulation of an IrDA LAP frame. This field immediately follows the FCS, and like the preamble and FCS, is based on a format that is data-rate dependent.

All IrDA information and control exchanges are based on this basic format.

Frame types
IrLAP uses the three general types of frames supported by HDLC: un-numbered frames ( Table 1 ), supervisory frames ( Table 2 ), and information frames. A considerable number of un-numbered frames are largely used to control connections and the relationship between the stations participating over the infrared link. A smaller set of supervisory, or S frames, are used to manage the sequenced flow of information within a connection. Finally, there is one type of information frame, the I frame, that is used to carry sequenced information within a connection. These frame types form the basis for IrLAP to manage communications between two devices participating in a wireless link.

Next month, I'll review the various procedures for two stations to exchange these messages in providing the general IrDA-link information and control services.

Mike Rodbell is president of DG Technology, a consulting firm that specializes in the development and integration of distributed processing and communication systems. He has developed voice and data communication systems for a wide range of military and commercial systems. He holds a BSCS from Trinity College of Hartford, CT, and an MSEE from Loyola College of Baltimore, MD. He can be reached at mrodbell@dg-tech.com or http://www.dg-tech.com.