Overview of IrDA Specifications--Part 1

IrDA was established to develop standards for infrared system design. In Part 1, we'll explore the required protocol layers of the IrDA specification.

By Patrick Megowan, David Suvak, and Charles Knutson, Counterpoint Systems Foundry

Infrared (IR) technology has long been used for the development of low-cost, short-range wireless data links. This technology has found its way into TV remote controls, PCs, personal digital assistants (PDAs), handheld data loggers, medical equipment, and printers.

Until 1993, the IR industry was plagued by a lack of standardization. To counteract this problem, industry members worked together and formed the Infrared Data Association (IrDA). IrDA was established to develop protocols for IR point-to-point communications applications. Today, IrDA specifications define the communications protocol for many IR applications.

In general, communications protocols are broken into layers. Each of these layers deals with a manageable set of responsibilities and supplies needed capabilities to the layers above and below. When these layers are placed on top of each other, they form a protocol stack.

Similar to other communications protocols, the IrDA specification features a protocol stack made up of several layers (Figure 1).

Figure 1: The IrDA protocol stack consists of required and optional layers. In this figure, the optional layers are in shaded boxes while the required layers are in un-shaded boxes.

The IrDA protocol stack can be divided into two groups -- required and optional layers. The required layers of IrDA include a link access protocol (IrLAP), a link management protocol (IrLMP), and the Information Access Service (IAS). The optional protocol layers include the TinyTP transport protocol, an object exchange protocol (IrOBEX), a serial and parallel port emulation protocol (IrCOMM), and a local-area network access protocol (IrLAN).

In the first part of this two-article set, we will focus on the required protocol layers of the IrDA specification. In part 2, we will cover the optional layers.

IrLAP
The required link access protocol layer (IrLAP) corresponds to the OSI layer 2 data link protocol. This layer is based on high-level data link control (HDLC) and synchronous data control (SDLC) with extensions for some characteristics of IR communications.

IrLAP provides reliable data transfer using retransmission, low-level flow control, and error detection. IrLAP allows IR systems to deal with data transfer at a low level. By handling data transfer at a low level, IrLAP frees the upper layers of an IrDA system from dealing with data transmission. As a result, the upper layers are assured that their data will be delivered (or at least that they will be informed if it was not).

Several environmental factors influenced the development of the IrLAP layer. These factors include:
1. Point-to-point communication--Connections are one-to-one, such as camera to PC or data collector to printer. The range is typically 0 to 1 m, although extended range up to 10 m or more is under development.
2. Half-duplex operation--IR light, and therefore data, is sent in one direction at a time. In IR systems, however, the link changes directions frequently. Thus, IR systems can simulate full-duplex operation in cases where timing is not extremely sensitive.
3. A narrow IR cone--IR transmission is directional within a 15 deg. half angle in order to minimize interference with surrounding devices.
4. Hidden nodes--Other IR devices approaching an existing connection may not be immediately aware of the connection if they approach from behind the current transmitter. They must wait and see if the link turns around before stepping in.
5. Interference--IrLAP must overcome interference from fluorescent lights, other IR devices, sunlight, and moonbeams.
6. No collision detection -- IR systems are designed to not detect collisions. Therefore, the protocol layer software must handle cases where collisions cause lost data with methods such as random backoff.

Roles Within a LAP Connection
In the IrDA specifications, the LAP connection is set up as a master/slave relationship. The master is called the primary station and the slave is called the secondary station.

The primary station sends command frames initiating connections and transfers. This station is responsible for organization and control of data flow and deals with unrecoverable data link errors.

On the other hand, the secondary station only sends response frames. It only speaks when spoken to.

In any connection, one device must play the primary role while the other device plays the secondary role. Once communication is started, the two sides take turns talking. The primary station leads off and the secondary station follows. Sides cannot talk for more than 500 ms at a time. They must allow the other side to talk, even if just to say it has nothing to send for the moment. This process continues until the communication is completed.

During connection, the IrLAP operates in a normal response mode (NRM). In this mode, higher stack layers use normal command and response frames to exchange information.

Once communication is completed, the IrLAP sends the IR system into a normal disconnect mode (NDM). NDM, known as a contention state, is the default state of disconnected devices. In this mode, a device must observe a set of media access rules. Of utmost importance, a device in NDM must check whether other transmissions are occurring (a condition known as media busy) before transmitting. To check for other transmissions, the IrDA device listens for activity. If activity is not detected for greater than 500 ms (the maximum time for the link to turn around), the media is considered to be available for establishment of a connection.

IrLAP Frame Format
The basic IrLAP frame format is displayed in Figure 2:

Figure 2: The basic frame format of the IrLAP protocol layer.

Before sending, a frame is wrapped with framing information. Three different frame wrappers are used by IrLAP. These wrappers include: 1. Asynchronous (ASYNC) Framing: 9600 b/s to 115.2 kb/s
2. Synchronous (SYNC) HDLC Framing: 576 kb/s and 1.152 Mb/s
3. Synchronous 4 PPM Framing: 4 Mb/s

Engineers should choose a frame wrapper based on the speed of connection employed in their system.

Service Primitives
IrLAP operations are described in the specification using service primitives. An engineer can think of the service primitive as a conceptual model of an API for an operation that IrLAP performs.

Figure 3 illustrates an operation. In this figure, the operation starts with a service request and then travels across the link as a frame. The operation is then reported as an indication (frequently an up-call) on the receiving side. Finally, the receiver formulates a response that travels back as a frame to the original requester. This response provides the original requester with a confirmation that the operation has been received.

Figure 3: This figure illustrates an IrLAP operation.

A number of services are defined in the IrLAP specification. Not all services are necessary for all devices. In addition, the IrLAP specification (along with the IrDA Lite standard) describes the minimum service requirements for operation. The most important IrLAP services include:
1. Device Discovery -- These services explore the nearby IR space to see who is present and get some hint as to what they can do.
2. Connect -- These services choose a specific partner, negotiate the best possible communication parameters supported by both sides, and connect.
3. Send Data -- These services are used by higher layer protocols for almost all of their work.
4. Disconnect -- These services close down and return to the NDM state as well as prepare the IrDA system for a new connection

IrLMP Link Management Protocol
The required link management protocol (IrLMP) layer provides multiplexing, high-level discovery, address conflict resolution of the IrLAP discovery, and an Information Access Service (IAS). This protocol layer depends on the reliable connection and negotiated performance provided by the IrLAP layer.

In order to have multiple IrLMP links on a single IrLAP connection, there must be a high-level addressing scheme. The following terminology is used to describe this addressing:
1. Logical Service Access Point (LSAP): The point of access to a service or application within IrLMP. This access point is referenced with an LSAP selector (LSAP-SEL).
2. LSAP-SEL: A 1-byte number that corresponds to an LSAP. Engineers should think of the selector as the address of a service within the LMP multiplexor. This byte is broken into ranges for the IAS server, for legal connections, for connectionless service, and for future use.

Given the limited number of LSAP-SEL values, services are not assigned fixed port addresses as in TCP/IP. Instead, services have fixed published names which are searchable using the IAS.

Similar to IrLAP, the IrLMP layer defines services. These services include:
1. Device Discovery -- This service finds out information about other services in the IR space.
2. Connect -- This service establishes a connection between a pair of services at the LMP level.
3. Send Data -- This service sends data back and forth in the IR system.
4. Disconnect -- This service closes the LMP connection. But, this service does not necessarily close the LAP connection.

It is important to note that this service set is identical to the set listed in the IrLAP section above. It is common for protocol stacks to propagate upward like this, with each layer adding its particular contribution.

Information Access Service
The IAS acts as the "yellow pages" for a device. All of the services/applications available for incoming connections must have entries in the IAS. These entries are used to determine the service address (LSAP-SEL). These entries are also queried for additional information about services.

A full IAS implementation consists of client and server components. The client is the component that makes inquiries about services on another device using the Information Access Protocol (IAP). The server is the component that knows how to respond to inquiries from an IAS client. The server uses an information base of objects supplied by the local services/applications.

The IAS information base is a collection of objects that describe the services available for incoming connections. Objects consist of a class name and one or more attributes. These objects are quite similar to entries in the yellow pages of a phone book.

The class name is equivalent to the business name in the phone book--it is the official published name of the service or application. IAS clients will inquire about a service using this name.

The attributes contain information similar to phone number, address, and other characteristics of the business. The one essential attribute for every entry is the LSAP-SEL (or service address), which is required in order to make a LMP connection to the service.

There are a number of IAS operations defined under the IrLMP standard. But, the most used and only required operation is called GetValueByClass. With this operation, the inquiring party gives the class name (for example, Printer) and the name of the attribute it wants (for example, the LSAP-SEL). The inquiring party then receives a response that consists of one or more answers (for example, the LSAP-SELs for any printing services in the responding party's information base) or an indication that the service or attribute does not exist.

Final Note
This ends the first part of the overview of IrDA specifications. In part 2, we'll examine the optional layers of IrDA and the IrDA Lite specification.

Patrick Megowan, President, David Suvak, Chief Technical Officer, and Charles Knutson, Vice President of Research and Development, Counterpoint Systems Foundry, 800 NW Starker Avenue, Corvallis, OR 97330. Phone: 541-758-6123; Fax: 541-758-6120.