Introduction

Overview

The internal workings of an Infrared Data Organization (IrDA) stack is covered in sufficient depth to allow each of the stack layers to be understood, a stack dump to be analyzed and a stack to be implemented in software.

This information complements and elaborates on the IrDA specifications with particular emphasis on concepts, practical considerations for software implementation, missing details and interaction with existing stacks.

Also described is the ANSI C source code for both a minimal primary and secondary stack each of which conform to IrDA lite specifications - the 'Microlite-IrDA' stack. This may be used directly or as a basis for the implementation of further IrDA functionality as necessary.

Resources

The reader must have the IrDA specifications covering IrLAP, IrLMP, IrTTP and IrCOMM - these documents are in the public domain.

Using the Microlite-IrDA Stack

If you want to use or experiment with the Microlite-IrDA stack, you will need a suitable host, an ANSI C compiler for that host, an IrDA port on that host and another IrDA compliant device.

The Microlite-IrDA stack is supplied as ANSI C source code. The C compiler used must support 'flexible array members' which is part of ANSI C99. As confirmation, the following code must compile:

typedef struct IrLMP_Ctl
{
   uint8_t  opcode;
   uint8_t  info[];
}
IrLMP_Ctl;

To communicate with another IrDA device, some form of physical IrDA port is needed. This typically takes the form of either a built-in port or an external dongle.

To exercise the Microlite-IrDA primary stack, as well as an associated IrDA port, an IrDA secondary device such as a mobile phone is needed.

To exercise the Microlite-IrDA secondary stack, as well as an associated IrDA port, an IrDA primary device such as a PDA or Windows PC is needed.

A convenient target is a PC running Microsoft Windows with Visual C++ v6 SP4+ and either an ACTiSYS IR220L/IR220L+ or Extended Systems JetEye PC ESI-9680 dongle plugged into COM1 and a null-modem cable between COM1 and COM2. Incidentally, this was the development environment used to develop the Microlite-IrDA stack.

Scope

The scope is limited to the minimum that is required for a legal, compliant IrDA lite stack that is capable of establishing a link and communicating using 9-wire IrCOMM. Specifically, these items are in scope:

• Two node interaction, ie point-to-point link between one primary and one secondary
• IrDA lite
• IrCOMM, 9-wire cooked
• IrLMP IAS get-value-by-class
• IrLAP 1 slot discovery
• IrPHY SIR speeds

A full implementation of an IrDA stack is a large undertaking. These items are out of scope:

• Three or more node interaction
• IrCOMM, 3-wire raw
• IrTTP segmentation and reassembly (SAR)
• IrLAP sniffing
• IrLAP device address conflict resolution
• IrLAP frame abort
• IrLAP 6 or 8 slot discovery
• IrLAP discovery clashes
• IrPHY FIR and faster speeds

Terms

Conventions

For multi-bit fields, the MSb bit is listed first, the LSb is listed last.

For message sequence charts, the primary node is on the left, the secondary node is on the right.

For convenience and simplicity, data within stack dumps is listed prior to IrPHY byte-stuffing, ie BOF and EOF flags may appear in the payload data.

Definitions

There are several common key concepts and definitions that are crucial to the understanding of IrDA.

Primary / Secondary Node Types

An IrDA connection, in its basic form, consists of a point-to-point link between a primary and a secondary node.

One node must act as the primary node which:

• Acts as the master
• Must initiate the establishment of a connection
• Must issue commands, ie command frames
• May request the disconnection of an established link

The other node must act as the secondary node which:

• Acts as the slave
• Must allow a connection to be established
• Must issue responses, ie response frames
• May request the disconnection of an established link

As part of setting up the link, the primary node must discover the secondary node and negotiate all link parameters with that remote node. As part of maintaining the link, the primary must keep the link alive, typically by initiating the exchange of RR frames.

To enable a link to be set-up, the secondary must respond promptly to commands and allow interrogation of any service(s) offered.

The primary node is in control of the link and each command frame solicits a response frame from the secondary node - the secondary node must not initiate an un-solicited response frame.

Within the bounds of frame exchanging, either node may initiate the transfer of payload data typically by the sending of an I frame, ie payload data flow may be bi-directional even though the link is half-duplex.

In addition to point-to-point connections, IrDA supports point-to-multipoint links - this is out of scope.

Frame Types

Command / Response Frames

A command frame is sent by primary node, ie where the C/R bit is 1.

A response frame sent by secondary node, ie where the C/R bit is 0.

Control / Data Frames

Each layer has the concept of control and data frame types.

A control frame is associated with connection, disconnection and maintenance for a link.

A data frame is associated with payload data.

Typically, the data frame for a lower layer is used for both control and data frames of a higher layer, eg the I frame for IrLAP is used for link connection and payload data for IrLMP.

Frame Header Types

IrLAP Header

This is a 2-byte field that immediately follows the BOF, which consists of:

• Connection address (7 bits), C/R (1 bit)
• Control (8 bits)

This is used in all IrLAP frames.

IrLMP Header

This is a 2-byte field that immediately follows the IrLAP header, which consists of:

• Control/Data (1 bit), DLSAP-SEL (7 bits)
• Reserved (zero) (1 bit), SLSAP-SEL (7 bits)

This is used in all IrLAP I frames, ie IrLMP, IrTTP & IrCOMM frames.

IrCOMM Header

This is a 2-byte field that immediately follows the IrLMP header, which consists of:

• Delta credit (7 bits), More (1 bit)
• Control channel length (8 bits)

This is used in all IrCOMM I frames.

The More bit (M) is always '0' - this is used for SAR which is out of scope.

Address Types

Device Address

This is a 32-bit field and is the first of two address types used in IrLAP. This is the physical, hardware address that uniquely identifies each node in the network. This is used in the info fields of XID and SNRM frames.

There are two reserved device addresses:

• 0x00000000: the null address, not used
• 0xFFFFFFFF: the broadcast address, used by the primary node during the discovery phase.

During the discovery phase, where the connection address is not yet been allocated, the device address is used as the only means of node identification.

Each IrDA node should be allocated a unique device (physical) address. For a clash, where both the primary and the secondary node have the same device address, the secondary must change to a different address as part of address conflict resolution. In practice, duplicates rarely occur.

The primary node must have a hard-coded device address and the secondary should have a main and a backup device address. In practice, as clashes are rare, the secondary may also have a hard-coded device address.

Connection Address

This is a 7-bit field and is the second of two address types used in IrLAP. This is the logical, 'session' address of a connection. This is used in all IrLAP frames as the first byte of the IrLAP header. Additionally, it is also contained in the info field of SNRM frames.

There are two reserved connection addresses:

• 0x00: the null address, not used
• 0x7F: the broadcast address, used during the discovery phase

All other values are valid 'session' connection addresses.

During the discovery phase, the broadcast address is used in the IrLAP header. Once the secondary has been discovered, the primary determines a new 'session' address that is sent as part of the info field of the post-discovery SNRM frame. On receipt of the SNRM, the secondary node must store the new connection address and for all subsequent frames, both the primary and secondary nodes must use this session connection address.

During the discovery phase, in addition to the broadcast connection address, both primary and secondary nodes must use the pair of device addresses. After discovery, the primary node essentially maps the primary and secondary device address pair to a connection address that is used for the duration of this session. From this point onwards, frames no longer need the device addresses with the excessive 8-byte overhead but only the 1-byte 'session' connection address.

In practice, it is sufficient for the primary node to have a hard-coded connection address that is used for all sessions.

Logical Service Access Point Selector (LSAP-SEL)

This is a 7-bit field and is the means of identifying multiple IrLMP or other high level services that may be present over a single, low-level IrLAP link.

There are two reserved LSAP-SELs:

• 0x00: the IAS LSAP selector value, must be used when accessing the IAS service
• 0x70...0x7F: reserved

All other values are valid device LSAP selector values.

For each IrDA node, the LSAP-SEL values for each service available are contained in the IAS of that node which may be accessed as part of the IrLMP layer.

Typically, the secondary node has a hard-coded list of LSAP-SEL values, one for each high level service available, eg 0x01 for IrCOMM, 0x02 for OBEX etc.

Link Connection Hierarchy

There are two tiers of IrDA link connection:

• At the IrLAP level, ie after the SNRM / UA frame exchange
• At the IrLMP/IrTTP level, ie after the IrLMP/IrTTP connect I frame exchange

The IrLAP connection, ie NRM, must be achieved first. Once in NRM, the link must be kept alive with continuous RR frame exchanges.

Higher level connects at the IrLMP/IrTTP level may only be made once the link has reached NRM, ie IrLMP/IrTTP connects are additional sub-states within NRM.

On an IrLMP/IrTTP disconnect, ie after an IrLMP/IrTTP disconnect I / RR frame exchange, the link reverts back to basic NRM mode.