Issue
139 February 2002
What
Good is IrD, Eh?
Part
2: Wireless Communication
IrCOMM
Sitting atop
the IrLMP layer are a host of transport services that
provide a way for various resources to make use of the
IrDA stack for wireless infrared data communications (e.g.,
IrCOMM, IrTINYTP, IrLAN, IrOBEX, IrMC, IrTRAN-P, IrWW).
Let’s look at how IrCOMM uses the IrLMP/IrLAP stack. IrCOMM
is the emulation of a serial or parallel connection (legacy).
Take HyperTerminal (the PC terminal program) for instance.
Sending a file over a serial link would require a null
modem cable connected between two computers (or modem
pairs connected by a phone line). By choosing a virtual
serial port (installed when IrDA hardware is installed),
you can fool HyperTerminal into thinking it’s hardwired
while it is actually using the IrDA port. A HyperTerminal
file transfer will use all four IrCOMM services, which
are IrCOMM_CONNECT, IrCOMM_CONTROL, IrCOMM_DATA, and IrCOMM_DISCONNECT
(see Table 2).
| Table
2—Four services are available to applications
using the IrCOMM layer. |
When the IrCOMM
requests a connection to some device in the log, the IrLAP
generates a request using the 32-bit device address from
the log as the destination address. The request assigns
a random 7-bit connection address, which will be used
as a shortcut to the device, to the connection link. This
request also asks for the operating parameters of the
secondary device. This will allow the two devices to take
advantage of any performance enhancers (e.g., faster data
rate). The request to connect is handled using the SNRM
frame, as shown in Figure 5.
 |
| Figure 5—Within the
SNRM frame, the primary device reveals its optimal
parameters to the secondary device. |
Any parameter
that is not exchanged is implied to be the default. Default
parameters should be used while in Normal Disconect mode
and prior to any negotiations. The default parameters
are 9600 bps, 500-ms maximum turnaround time, 64-byte
data size, one buffer window size, and 12 additional BOFs
(which exceeds the 10-ms minimum turnaround time.) The
secondary device would reply with a UA frame (notice the
new address in Figure 6).
 |
| Figure 6—The UA response
of the secondary discloses its own optimum parameters. |
At this point,
both devices know about the parameters of the other device
and have initiated Normal Response mode. With the RR command,
the primary device tells the secondary device it’s ready
(using the enhanced parameters just negotiated), and the
secondary device responds. If no data is immediately ready
to be sent by the IrLMP layer (from IrCOMM), the link
can remain open only if the devices continue talking with
one another. This is all handled automatically without
direction from above. Unless this continuous banter takes
place, the link will close. Figure 7 demonstrates a conversation
that keeps the link alive.
 |
| Figure 7—A continuous
conversation is necessary to keep an established link
open. This is accomplished automatically. |
When the IrPHY
layers have a link among them, the IrCOMM can get its
request for a connection handled. An information frame
(one with an even control byte) is used to pass IrCOMM
data within its Information field of the frame’s payload
(see Figure 8). IrCOMM data in the Information field of
the frame comes in two varieties—data transfer frame and
link control frame.
The negotiated
parameters thus far dealt strictly with the IrPHY layer.
The IrCOMM protocol has its own parameters because it
emulates a serial or parallel port. There are four types
of emulation, a three-wire raw, three-wire cooked, nine-wire
cooked serial connection, and a Centronics parallel connection.
Three-wire raw emulation has no flow control. The latter
three connections support some kind of flow control. Flow
control may be hardware (RTS/CTS) or software (XON/XOFF).
I’ll stop here with this topic because further discussion
of flow control is beyond the scope of this article.
IrCOMM parameter
exchange is a way for each device to find out what types
of emulation are supported by each other and to agree
on which one to use. Presumably both devices are now happy
with all aspects of the connection, therefore, data can
be sent. Exchanging data is uneventful as opposed to the
work required to establish a connection. Information frames
carry the data and the TINY-TP layer handles the break
down of the file into packet-sized chunks. Lower layers
autonomously confirm packets and handle resending errors.
Finally, an IrCOMM disconnect service breaks the connection
after the application is finished with the link.
