Articles

RSS

The IrDA protocol stack is broken into required and optional layers. Part 2 of this two-article set focuses on the optional protocol layers.

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

Infrared Data Association (IrDA) regulations are a guiding force behind the development of many short-range, low-cost point-to-point infrared (IR) systems. Similar to other communication protocols, the IrDA standard is broken down into layers. In Part 1 of this series, we examined the required protocol layers of the IrDA specification. In this part, we will focus on IrDA's optional layers and the IrDA Lite specification.

Under IrDA specifications, the optional protocol layers include the TinyTP transfer protocol, an object exchange protocol (IrOBEX), a serial and parallel emulation protocol (IrCOMM), and a local-area network (LAN) protocol (IrLAN).

Even though the TinyTP transportation protocol (TTP) is an optional IrDA layer, it is so important that engineers should consider it a required layer (except in the case of current printing solutions). TTP provides two functions:

1. Flow control on a per-LMP-connection (per-channel) basis;

2. Segmentation and re-assembly (SAR).

Per-channel flow control is currently the most important use of TTP. As discussed in Part 1, IrLAP offers flow control. But another flow control is still needed. To illustrate this need, suppose that a LAP connection is established and two LMP connections are made on top of the LAP connection using the LMP multiplexing capability. If one LMP connection turns the LAP flow control on, the flow of data on the LAP connection (which carries all the LMP connections) is completely cut in that direction. As a result, the second LMP connection side cannot get the data it wants until LAP flow control is turned off. This may seriously disrupt the work of the second LMP connection (especially if timers are involved).

If flow control is applied on a per-LMP-connection basis using TTP (or other mechanisms), the first LMP connection can stop to digest information without negatively affecting the second LMP connection.

TTP uses a credit-based flow control scheme. It works as follows:

1. At connection, some credit is extended by each side. One credit corresponds to permission to send one LMP packet. If you send a credit, you must be able to accept a maximum-sized packet. As an engineer can see, the number of provided credits depends entirely on how much buffer space an IR system has available. As long as the IR system has buffers, it can send anywhere from 1 to 127 credits.

2. Sending data causes credit to be used up (1 unit of credit per packet sent).

3. Periodically, the receiver issues more credit. Although this issuing policy is entirely at the receiver's discretion, it can make a big difference in the performance of the link. If the sender is constantly running out of credit and having to wait for more, throughput will suffer.

4. If a sender does not have credit, data movement cannot occur.

5. A credit-only packet can always be sent. This packet is not subject to flow control.

Although the above description talks about the sender and receiver as if those roles are fixed, it is common for both sides of a LMP connection to send and receive. Thus, both sides will be issuing and using credit. Note that the credit byte normally travels as part of a LMP data packet, so LMP packets are not needed just for sending credit as long as there is data to send and credit to send with.

Segmentation and Re-Assembly
The TTP is also responsible for segmentation and re-assembly (SAR). Basically, TTP breaks large data into pieces (segmentation) and puts it back together on the other side (re-assembly). The entire piece of data being chopped up and re-constituted is called a service data unit (SDU). The maximum SDU size is negotiated when the TTP/LMP connection is first made.

Tiny TP Service Primitives
As with the IrLAP and IrLMP layers, TTP operations are characterized as service primitives:

1. Connect -- Negotiate maximum SDU size.

2. Disconnect

3. Data -- Reliable sequenced data.

4. Local Flow Control -- Stop data delivery.

5. Udata -- Unreliable, unsequenced (pass through to IrLMP).

TTP service primitives focus on the core of the LMP primitives -- connect, send, and disconnect. The only difference is that TTP service primitives offer a course for low control.

IrOBEX Object Exchange Protocol
The optional object exchange protocol layer (IrOBEX) allows systems of all sizes and types to exchange a wide variety of data and commands in a resource-sensitive standardized fashion. This protocol layer takes an arbitrary data object (a file, for instance) and sends it to whomever the IR device is pointing. IrOBEX also provides tools that enable the object to be intelligently recognized and handled on the receive side.

The potential range of objects is wide, encompassing not only traditional files, but also pages, phone messages, digital images, electronic business cards, database records, handheld instrument results, and machinery diagnostics. The common thread is that the application doesn't need or want to get involved in managing connections or dealing with the communications process at all. The application simply wants to take an object and ship it to the other side with the least amount of hassle.

IrOBEX was created to package an IrDA communications transaction as completely as possible in order to dramatically simplify the development of communications-enabled applications. It was further engineered to meet the following criteria:

1. Simple: Supports most-needed operations/applications.

2. Compact: Under 1K code on a small system.

3. Flexible: Supports data handling for both industry standard and custom types.

4. Extensible and Debug-able.

5. Works on IrDA, but is transport independent.

The IrOBEX standard consists of a session model, an object model, guidelines for use and extension, as well as IAS entry for a default OBEX server and suggestions for its capabilities. The object model provides a flexible and extensible representation for objects and information describing the object. The guidelines for use and extension define new session operations and new object types.

The session model offers the rules of conversation governing the exchange of objects. This model supports optional negotiation during connection and a set of operations such as Put and Get. The session model also allows IrDA systems to terminate the transfer of an object without closing the connection.

IrCOMM
When the IrDA standards were developed, there was a strong desire to allow existing PC applications that use serial and parallel ports to operate via IR without change. These applications, collectively known as legacy applications, include printing, file transfer applications, and modem communications.

In the past, providing IR connectivity to legacy applications caused headaches for design engineers. IR communications differ significantly from serial and parallel communications. For instance, both serial and parallel cables have individual circuits over which signals can be sent independently and concurrently. By contrast, IR has a single beam of light. All information must fit into LMP or higher layer packets in a serial stream.

The IrCOMM standard allows legacy applications to be used over IR with a minimum hassle. The key feature of IrCOMM is the definition of a so-called control channel to carry the non-data circuit information.

IrCOMM is an optional IrDA protocol that applies only to certain applications. In general new applications are better served if they avoid IrCOMM and directly use other IrDA applications protocols such as IrOBEX, IrLAN, or TTP. New applications should avoid IrCOMM because it masks some of the useful features built into the lower protocols. After all, IrCOMM's job is to make IrDA look like serial and parallel media that do not offer handy features like automatic negotiation of best common parameters and a yellow pages of available services.

Since different applications use the non-data circuits of serial and parallel communications to varying degrees, four service types are defined in IrCOMM:

1. Three-Wire Raw (Parallel and Serial Emulation): Sends data only without the need for non-data circuit information and a control channel. Runs directly on IrLMP.

2. Three-Wire (Parallel and Serial Emulation): Minimal use of control channel. Uses TTP.

3. Nine-Wire (Serial emulation only): Uses a control channel for status of standard RS-232 non-data circuits. Uses TTP.

4. Centronics (Parallel emulation only): Uses control channel for status of Centronics non-data circuits. Uses TTP.

Engineers should choose an IrCOMM service type based on the requirements of their individual IR system requirements.

IrLAN
The final optional protocol discussed is IrLAN. It is mentioned only briefly because it is not an approved standard at this time. In addition, IrLAN is not widely used in embedded systems throughout the world.

IrLAN primarily serves as an extremely convenient connection between portable PCs and office LANs. It provides three levels of operation. This protocol layer enables a computer to attach to a LAN via an Access Point Device (sometime called an IR LAN Adapter). Secondly, it allows two computers to communicate as though they are attached to a LAN. In effect this functionality creates an instant LAN between a pair of machines, with access to the other machines' directories and other LAN capabilities. Finally, IrLAN lets a computer attach to a LAN through a second computer already attached.

IrDA Lite
Until now, we've discussed the layers that make up the IrDA protocol stack. This section briefly describes a specification that modifies the protocol layers already discussed without creating a new layer.

The IrDA Lite specification describes a set of design and implementation strategies that together yield the smallest possible IrDA implementation. Naturally, the ultimate size of the stack will depend heavily on the hardware, the software tools available, and the experience and skills of the development team. But Counterpoint's experience suggests that IrDA Lite systems can achieve primaries under 10 kB code size and secondaries under 5 kB when running on common CISC processors in embedded systems.

The IrDA Lite specification is composed of a number of strategies. A developer may choose to implement all of the strategies or only the ones appropriate for a particular device.

Author's Note: Engineers can obtain standards documents and additional information about IrDA at http://www.irda.org.

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.