IrDA Link Management Protocol

By Mike Rodbell

Here, we discuss multiplexing and application management services within the Infrared Data interface specifications.

Over the past few months, we've been reviewing the Infrared Data Association's (IrDA) interface specifications, including the physical and link layers. Moving up the protocol stack, this month and next I'll cover the IrDA link management protocol, or IrLMP (Ir lump) for short. The IrLMP protocol can be conveniently divided into two separate protocols: a multiplexing service (link management multiplexer, also referred to as LM-MUX), and a set of link management information access services (LM-IAS). LM-IAS allows applications running on different IrDA devices to advertise their capabilities and discover the capabilities of connected machines. LM-MUX provides a set of mechanisms to support multiple-application data link connections over a single IrDA link access protocol (IrLAP) connection. This month, I'll cover the services and mechanisms employed in the LM-MUX portion of the protocol. Next month, we can spend some more time on the LM-IAS services.

Figure 1 shows the role of the two general elements of the link management subsystem and how they fit into IrDA. LM-MUX, this month's topic, sits directly above the IrLAP and provides generic information-transfer services for both the LM-IAS, as well as the IrDA applications. Depending on the specific application, a range of transport mechanisms can be employed. When sending information, it is important to note that LM-MUX does not provide flow control mechanisms beyond those provided by IrLAP. Depending on the implementation, LM-MUX may monitor the queues of individual applications, and may drop excessive transmissions in an attempt to balance the load generated through IrLAP.

Figure 2 shows a generic example of the relationship between assorted IrDA components. Note that this picture (and the IrLMP design) assumes that multiple connections can be supported. This requires that either two separate physical ports are available (and don't interfere with one another) or that the device can support multidrop connections. These features are not in the version of IrLAP that we covered in the last few months, but are under investigation in future improvements to the IrDA protocol and interface standards.

In general, the purpose of the LM-MUX is to allow several client applications to simultaneously share a single IrLAP connection. Additionally, connections can be made between clients operating on the same device (without using IrLAP). For the purposes of this month's discussion, I'll focus on the services provided over IrLAP. Referring back to Figure 2 , each station can contain several objects. These include service access points (SAP), which represent the point at which a particular protocol provides a logical attachment to its services. Each SAP can supply one or more connection endpoints, which provide the information transfer and control services to the adjacent layer protocol or application. Each SAP is represented by a selector (SEL). Looking at the LM-SAP (LSAP) with SEL = Y, connections can be made to one of four other SAPs in the system: SEL = X (same device), SEL = P or Q (station B), or SEL = I in station C. The inner workings of the LM-MUX layer provide the necessary services to track the state of the IrLAP connections, and tag and route the data information.

Focusing in on the actual contents of the LM-MUX services, the IrLMP standards provide a view of an LM-MUX engine ( Figure 3 ). As can be seen by this representation presented in the standard, the LM-MUX provides a number of types of upwards facing interfaces and manages the activities of the link through a single interface. The mechanisms employed in providing the LM-MUX services can be divided into three separate state machines. The LSAP-connection finite state machine (FSM) tracks the relationship between pairs of clients communicating over the IrDA interface. The IrLAP connection control FSM provides general oversight of the operation of the link connection between the local device and its adjacencies. The station control FSM coordinates the overall services of the LSAP connection FSM and the IrLAP-connection control FSM. Let's now take a look at the services provided by each of these functional areas, starting with the LSAP connection control mechanisms:

• Data transfer frames are for the exchange of client application information between LM-MUX clients.
• Link control frames are for the control and sequencing of connections between peer LM-MUX processes.

Given that a good bit of the operations of the LM-MUX state machines involve the exchange of control and status information with the adjacent protocol layers, the LM-MUX to LM-MUX information exchanges are relatively simple. The generic frame header, shown in Table 1 , contains four fields. The DLSAP-SEL indicates the address of the destination connection point (client application). The SLSAP-SEL identifies the source of the message. The C bit indicates whether or not the frame is a control frame. Finally, the r bit is reserved for future use.

The data transfer frames are relatively simple. They contain the header with the C bit set to zero, followed by the client data.

Link-control frame formats are a bit more involved, with several types of information being carried. The basic format of these frames is shown in Table 2. In addition to the header, three new fields are included in the link control frames:

• A bit defines the type of the frame. When clear (0), the frame is a command request originating from the source. When set (1), the frame is a command response.
• Opcode defines the type of frame. The various types of frames are shown in Table 3. For a complete dictionary of the reason, status, and mode parameters, refer to the IrLMP specifications. These codes communicate the various causes of a disconnect (reason), operating mode (can be either multiplexed or exclusive), and operation success or failure (status).

The LSAP connection control state machine
As you can see from the table, there are a number of control frames, largely intended to support the establishment of connections between LSAPs. These are used to support the most public of the three primary LM-MUX functions, LSAP connection control. A separate instance of this state machine is maintained for each connection between a pair of IrDA applications. The functions of this FSM are dependent on three primary resources:

• The client application supporting the connection. Each client can either request or accept a connection from the peer machine. If no client is available to process the connection, then inbound connection requests are rejected.
• The IrLAP connection-control mechanisms. If no connection is available to support a request, the IrLAP FSM is used to support the establishment of a link connection prior to completing an LSAP connection process. If no connection can be made, a local client's connection request is locally rejected. If a connection is already established and available, the connection processing can continue as if over a dedicated link.
• The peer LSAP connection-control FSM. As a balanced peer-to-peer protocol, the LM-MUX services assume that the remote machine includes an implementation of the similar state machine. It is the responsibility of the remote station's LSAP FSM to respond in kind to requests once the IrLAP connection is established.

In addition to these primary players in the LSAP connection process, the state machines are able to handle situations where a different machine has assumed exclusive control of the IrLAP services. While the link has been taken over for "exclusive mode," all other connections are considered to be unable to use the link connection. This mechanism is normally employed in situations where application demands for throughput or predictable signal latency are absolute requirements. Once the connection between two LSAP endpoints is completed (known as the data transfer ready, or DTR state), the participating stations can exchange data.

IrLAP connection control
While the IrLAP protocol incorporates the basic mechanisms for station discovery and link connection management, LM-MUX must include a separate state machine to track the behavior of the link protocol. The IrLAP connection-control FSM helps to ensure that when applications require a connection, a connection is available, and when no applications require a connection, the IrLAP connection is deactivated. A fairly simple machine, the IrLAP FSM includes three states:

• Standby means no link connection exists.
• U_Connect refers to a user-based request that has been initiated. One of the local LSAP clients requires a connection to complete its operations.
• Active is a link connection that is active and can support LSAP connection services.

The functions of this state machine are offered primarily as a recommended approach to managing the IrLAP link.

Station control
The final FSM in LM-MUX, the station control FSM is primarily responsible for oversight of the major processes handled within the station. It monitors and controls address resolution and discovery operations, LM-MUX exclusive/multiplexed mode transitions, primary/secondary role management, and, for lower power devices, sniffing. As in the case of the connection control machine, the operations performed by the station control FSM are entirely a result of internal stimuli, with no additional protocol or external interface requirements.

The IrLMP specification contains a wealth of information detailing each of the state machines we've covered this month. For more details, refer to version 1.1 of this document. Next month, I'll move on to the second major portion of IrLMP, the LM-IAS.

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.

---