11

he I nfrared Data Associ ati on

(I rDA) was formed i n June 1993 and has worked steadi l y to
establish specifications for a low-cost, interoperable, and easy-
to-use wi r el ess communi cati ons technol ogy. Today, the
i nfrared data communi cati on technol ogi es defi ned by the
I rDA shi p i n over 40 mi l l i on new devi ces each year rangi ng
from personal computers, personal digital assistants (PDAs),
digital cameras, mobile phones, pagers, portable information
gathering appliances, and printers.
I t is a remarkable achievement for a new communications
technology to establish such widespread deployment in such a
wide range of devices in such a relatively short time. The core
I nternet platform technologies existed for a full 10 years prior
to the explosive growth brought about by the introduction of
the Web.
I rDA is a communication technology for the appliance era.
Thi s i s an era that, whi l e not excl udi ng the PC, l i berates
devices that have long been viewed as peripherals. I t enables
them to engage in useful interactions with each other without
havi ng to medi ate thei r communi cati ons through some com-
mon control point.
End users have remarkabl y hi gh expectati ons of wi rel ess
communi cati ons. I n the wi red worl d there i s general accep-
tance of the mechani cal constrai nts i mposed by the vari ous
plugs and sockets that, at least in part, avoid mismatched con-
nections. There is acceptance of the cognitive load required to
sort out the connectivity and clutter of cabling at the rear of a
hi -fi setup or the back of a PC. However, i n the wi rel ess
world, there is an expectation that communications and con-
necti vi ty wi l l just work, and work si mpl y. I n the wi red worl d
short-range connecti vi ty between devi ces i s establ i shed by
expl i ci t acti ons on the part of the end user. I n the wi rel ess
wor l d ther e i s an expectati on that connecti vi ty between
devi ces wi ll be establi shed as requi red wi thout expli ci t i nter-
venti on by the end user. The expectati on i s that i f the user
attempts to pri nt, the system wi l l seek out and establ i sh
connectivity to a nearby printer.
The author regul arl y fi nds i t remarkabl e that he can use
the same infrared port to:
Simply squirt files between devices
Connect to the local LAN
Di al i n from a portabl e PC or PDA vi a an I rDA-enabl ed
cell phone
Print to an I rDA-enabled printer
All of this is achieved without reconfiguring between actions
and in most cases merely by placing the appropriate devices in
proximity to one another.
The work of I rDA has sought to go far beyond mere cable
repl acement, and provi de a communi cati ons pl atform and
appl i cati on servi ces fi t for the era of i nformati on appl i ances
and which excel in the area of ease of use.
A Brief History of IrDA-Data
The I rDA was formed in June 1993 to develop an interopera-
bl e, l ow-cost and easy-to-use, short-range, i nfrared, wi rel ess
communi cati ons technol ogy. The i naugural meeti ng was
attended by 70+ compani es whi ch recogni zed the consi der-
able value of defining a single family of specifications for the
communication of data over infrared.
Pri or to June 1993, a number of noni nteroperabl e si ngl e-
vendor proprietary schemes for infrared data communications
existed. There was considerable risk that the marketplace for
short-range wireless infrared communications would fragment
around a number of propri etary schemes, al l of whi ch woul d
individually fail to achieve critical mass. For system and periph-
eral vendors eager to deploy short-range wireless solutions in
their information appliances, the absence of a dominant, com-
mon connecti vi ty technol ogy represented a voi d. Wi thout a
domi nant technol ogy, the ri sk of choosi ng the wrong propri -
etary technology was significant. Thus, there was considerable
shared interest in the generation of common specifications, and
this set the tone for the early years of the I rDA.
The original requirements can be summarized as:
Marginal cost to add infrared to a product , under $5
Data rates of up to 115 kb/s
Range from contact (0 m) through at least 1 m
Angular coverage defined by a 1530 degree half-angle cone
By the end of September, I rDA had selected one of 3 pro-
posed approaches for defining its physical layer [1] defined by
I EEE Personal Communications February 2000 1070-9916/00/$10.00 2000 I EEE
T
IrDA: Past, Present and Future
St uar t Wi l l i ams, HP Labor at or i es
A b stra ct
The core I nternet technologies were in the hands of the research community 10 or more years before the World Wide Web happened and popu-
larized the I nternet as a place to find information, access service, and trade. The I nfrared Data Association has been in existence for over six
years. Products embedding the communication technology I rDA defines have been around for over five years, starting with printers and portable
PCs. I rDA is cheap to embed, uses unregulated spectrum, and is increasingly pervasive in a wide range of devices. From its roots in portable PCs
and printers, I rDA technology is present in virtually all new PDAs, it is emerging in mobile phones, pagers, digital cameras, and image capture
devices. We are sitting on the cusp of the information appliance age, and I rDA is playing a significant role in enabling the interaction between
information appliances, between information appliances and the information infrastructure, and between appliances communicating across the
information infrastructure. This article discusses I rDAs communications model. I t charts the evolution of the I rDA-Data (1.x) platform architec-
ture, and the early applications and application services now in common use. I t considers the present day and the explosion in device categories
embedding the I rDA platform. I t broadens its horizons to consider other emerging appliances technologies and to consider communications
models that might arise from a blend of I rDA short-range wireless communications and mobile object technologies. Finally, it briefly considers
future directions for the I rDA platform itself.
Williams00
12
Hewlett-Packard. All three approaches assumed the presence
of a UART that could be used to modulate the infrared trans-
mi ssi ons. The si l i con cost of UART devi ces was wel l under-
stood, and in many cases the system design of many products
included redundant UARTs; thus, the marginal cost of adding
I rDA coul d amount to just the components of the i nfrared
transceiver.
So far, these requirements have little to say about the func-
tional model of communication. There was an implicit require-
ment that the infrared medium serve as a cable replacement,
but, as we shal l see l ater , the questi on of whi ch cabl e
remained.
The natural abstracti on of a hal f-dupl ex, asynchronous
character-ori ented transmi ssi on was too poor an abstracti on
for building interactions that were self-organizing and easy to
use. I n addi ti on, there were frequent di scussi ons of how to
sel ect data rate, how medi a access control was to functi on,
and how, in the context of a 115 kb/s link, reasonably efficient
use could be made of the available bandwidth.
By November 1993 I rDA had settl ed on a token-passi ng
approach, ori gi nated by I BM [ 2] and deri ved from hi gh-
l evel data l i nk contr ol (HDLC) [ 3] oper ati ng i n nor mal
response mode (NRM). As wi th other proposal s, thi s was a
packeti zed scheme. However, i n contrast to contenti on-
based schemes that were al so consi dered, the HDLC-SI R
(l ater renamed I nfrared Li nk Access Protocol , I rLAP [3])
approach yi el ded contenti on-free access to the medi um
once i ni ti al communi cati on had been establ i shed. I rLAP
defi nes a fi xed-rate sl otted contenti on-mode devi ce di scov-
ery scheme that enabl es i ni ti al contact to be establ i shed.
Cri ti cal communi cati on parameters such as connecti on data
rate, maxi mum packet si zes, and certai n mi ni mum and max-
i mum gap ti mi ngs are negoti ated duri ng connecti on estab-
l i shment. Fol l owi ng I rLAP connecti on establ i shment, the
two devi ces engaged i n communi cati on ar e deemed to
own the spatial region which they both illuminate nom-
inally the union of two overlapping
1 m cones, each wi th a 1530
degree half-angle.
I t soon became appar ent that
the defi ni ti on of I rLAP woul d not
be suffi ci ent to meet I rDAs ease-
of-use goal s. Cer tai nl y, I r LAP
woul d provi de a rel i abl e connec-
ti on- ori ented communi cati on ser-
vi ce between two devi ces, but i t
pr ovi ded no means to i denti fy
pr ospecti ve cl i ents of the I r LAP
communi cati on servi ces. The year
1993 was a hot peri od wi th the
emer gence of numer ous PDAs,
notebook, and sub-notebook PCs. I t
was apparent that a model whi ch
turned over the i nfrared communi -
cati on faci l i ti es to a si ngl e appl i ca-
ti on woul d be i nadequate. The
emergi ng mul ti threaded consumer
computi ng pl atfor ms r equi r ed a
multiplexing communications model
that enabled several applications to
share access to the infrared commu-
nications resources within a device.
I n thi s way, mul ti pl e appl i cati ons
coul d passi vel y l i sten for appropri -
ate peer application entities to con-
nect. Thus, i n December 1993 the
acti vi ty to defi ne the I nfrared Li nk
Management Protocol (I rLMP) [5] was born.
I rLMP provi des a connecti on-ori ented mul ti pl exer, LM-
MUX, and a l ookup servi ce, LM-I AS, that enabl es mul ti pl e
I rLMP cl i ents to cl ai m a port above the mul ti pl exer and
adverti se thei r avai l abi l i ty by pl aci ng cri ti cal contact i nfor-
mati on i nto the l ookup ser vi ce. The namespace for the
l ookup servi ce i s desi gned to be sel f-admi ni steri ng i n order
to avoi d the bur eaucr acy of mai ntai ni ng admi ni str ati ve
records about namespace regi strati ons and to ensure fai r
access to make use of the namespace.
By June 1994, just 12 months after the i naugural I rDA
meeting, version 1.0 of the core I rDA platform specifications,
I rPHY, I rLAP, and I rLMP, was released [46].
Work conti nued to defi ne a per-connecti on fl ow control
scheme to operate wi thi n I rLMP connecti ons. When mul ti -
plexing above a reliable connection, unless there is a means of
independent flow control for each derived channel, the deliv-
ery property of the deri ved channel i s reduced to best-
effort. Per-channel flow control restores a reliable delivery
property. Thi s work l ed to the defi ni ti on of the Ti ny Trans-
port Protocol (Tiny TP or TTP) [7].
I r PHY, I r LAP, I r LMP, and Ti nyTP ar e the cur r entl y
accepted specifications that define the core of the I rDA plat-
form, often referred to as the I rDA-Data or 1.x pl atform.
The pl atform has been extended three ti mes to accommo-
date:
The addition of 1.152 Mb/s and 4 Mb/s data rates
The inclusion of a short-range, low-power option primarily
for use in devices such as mobile phones where battery life
is paramount
The addition of a 16 Mb/s data rate
I t was not enough merely to define a communications plat-
form. I n order to promote i nteroperabi l i ty between appl i ca-
ti ons, i t was essenti al to devel op speci fi cati ons for the
application services and the application protocols that support
them. Hence, work has also progressed to define application
IFigure 1.The IrDA protocol architecture.
Physi cal
IrLM P LM -IAS
servi ces
Pl at f orm
Ti ny TP servi ces
IrLM P LM -M UX servi ces
IrLLAP servi ces
Appl i cat i on and communi cat i on servi ces
Net w orked
appl i cat i ons
Legacy
net w ork st ack
Legacy
comm apps
"Appl i ance"
appl i cat i ons
IrLAN IrCOM
IrTRAN-P
IrOBEX Jet Send
IAS
IrLM P
IrLAP
Ti ny TP
SIR M IR FIR
I EEE Personal Communications February 2000
13
protocol s and servi ces that resi de above
the I rDA 1.x platform, most notably:
IrCOMM[8], which provides for serial
and paral l el port emul ati on over the
I rDA platform. This allows legacy com-
muni cati ons appl i cati ons to operate
unchanged over I rDA and also provides
for wireless access to external modems.
The most novel example of the latter is
NTTs depl oyment of I rDA-enabl ed
i ntegrated servi ces di gi tal network
(I SDN) payphones.
IrLAN[9], which provides wireless access to I EEE 802 style
LANs.
IrOBEX [10], whi ch provi des for the exchange of si mpl e
data objects and coul d be consi dered the I rDA anal og of
HTTP. I rOBEX delivers on the notion of squirting infor-
mation objects such as business cards, phone lists, calendar
entries, and binary files between devices.
IrTRAN-P[11]: which provides for the exchange of images
between digital still image cameras, photo printers, and PCs.
IrMC [12], which defines a profile of relevant I rDA specifi-
cati ons for i ncl usi on i n cel l phones. Much of thi s work i s
bei ng l everaged by the Bl uetooth communi ty. I rMC pro-
vides for vendor independent interactions with common cell
phone features such as phone list synchronization, calendar
synchroni zati on, and wi rel ess modem access. I t al so pro-
vides for third-generation smart phones.
IrJ etSend[13, 14]: whi ch descri bes how to bi nd Hewl ett-
Packards JetSend protocol for networked appliance interac-
tion to the I rDA platform.
Fi gure 1 bel ow summari zes the I rDA-Data pl atform and
application services defined to date.
The di scussi on so far has focused on the hi story of the
standards devel opment process. Tabl e 1 bel ow shows key
milestones in terms of the introduction of classes of products
implementing various mixes of applications services.
IrDA 1.x Platform Architecture
I n this section we describe the layered protocol architecture of
the I rDA-Data 1.x platform, the services provided at its layer
boundaries, its connection model, and the information model
and philosophy of its device and service discovery processes.
Figure 1 shows the layering of the I rDA protocol architecture
and many of the application services mentioned in the previous
section. The upper boundary of each of the boxes represents an
interface where the services of that layer are abstracted.
The segmented physical layer provides packet transmission
and reception service for individual packets, and the means to
determine when the infrared medium is busy.
The I rLAP layer provides for the discovery of devices with-
i n r ange and the establ i shment of r el i abl e connecti ons
between devices.
The I rLMP layer provides connection-oriented multiplexing
services with both sequenced and unsequenced delivery prop-
erties (LM-MUX services) and the service information access
servi ce (LM-I AS). LM-MUX provi des for mul ti pl e l ogi cal l y
independent channels between application entities within the
communicating devices. Note that the absence of per-channel
flow control in LM-MUX channels means that they may only
safely be regarded as best-effort delivery channels.
Ti ny TP mi rrors the LM-MUX servi ces; however, i t aug-
ments them with the inclusion of per-connection
fl ow control . Thi s restores the rel i abl e del i very
properties for sequenced data. Tiny TP provides
a null pass-through for unsequenced data whose
delivery properties remain best-effort.
LM-I AS provi des query/response servi ces on
an i nformati on base that contai ns essenti al con-
tact information that enables prospective service
users (clients) to identify and bind to service pro-
viders (servers).
These four protocol l ayers, I rPHY, I rLAP,
I rLMP, and Ti ny TP, form the core of the I rDA
platform.
IrDA Connection Model
The I rDA 1.x connecti on model i s establ i shed
primarily by the I rLAP and I rLMP layers. There
i s a 1:1 correspondence between I rLMP LM-
MUX service access points (LSAPs) and Tiny TP
service access points (TSAPs). Thus, the Tiny TP
l ayer does not contr i bute to the connecti on
model, it merely alters the delivery properties of
the channel from best-effort to reliable.
Within each I rDA device (or station) (Fig. 2),
I rLAP servi ces are accessed vi a a si ngl e I rLAP
servi ce access poi nt (I SAP). The archi tecture
al l ows mul ti pl e I rLAP connecti on endpoi nts to
exi st wi thi n the I SAP; however, i n practi ce the
I rLAP protocol defines only single point-to-point
connecti vi ty. There are no known research or
I EEE Personal Communications February 2000
IFigure 2.Service access pointsand connection endpoints.
ISAP
St at i on
IrLAP connect i on
endpoi nt s
LSAP
LSAP connect i on
endpoi nt s
Connect i onl ess
LSAP
XID_di scovery
service access point
LM -M UX servi ce
boundary
IrLAP servi ce
boundary
LSAP
LSAP connect i on
endpoi nt s
ITable 1. Product categroy introductions.
Lat e1994 115.2 kb/s Opt i cal Transcei ver Component s
Earl y 1995 115.2 kb/s Personal Laser Pri nt ers
Seri al Port Adapt ors
Pri nt er Adapt ors
M i d 1995 115. kb/s Port abl e PCs
Wi ndow s 95
Port abl e Ink Pri nt ers
Lat e 1995 4 M b/s Opt i cal Transcei vers
M i d 1996 4 M b/s Port abl e PCs
4 M b/s LAN (Et hernet ) Access Devi ces
Noki a 9000 Communi cat or
Wi ndow s CE
4 M b/s Personal Laser Pri nt ers
Lat e 1997 Di gi t al Cameras
M obi l e Phones
M i d 1998 Pal m Compt i ng Pl at f orm (Pal m III)
Casual Capt ure and Share Inf ormat i on Appl i ance
Earl y 1999 IrDA/Li nux Impl ement at i on
Sony Pocket St at i on
Approximat e Device Cat egory
Int roduct ion Dat e
14
commerci al I rDA stacks that support poi nt-to-mul ti poi nt
connectivity. However, one commercially available implemen-
tati on suppor ts mul ti pl e I r LAP i nter faces and gi ves the
impression of multipoint operation through multiple indepen-
dent instances of I rLAP and I rPHY.
Likewise, I rLMP LM-MUX services are accessible via mul-
ti pl e LSAPs. Typi cal l y, an appl i cati on enti ty wi l l bi nd to an
LSAP and, in general, will support multiple I rLMP LM-MUX
connections (or Tiny TP connections). Thus, each LSAP may
contai n mul ti pl e LM-MUX connecti on endpoi nts. LSAP
addresses are formed by the concatenati on of an 8-bi t LSAP
selector and the device address of the device where the LSAP
resides.
Fi gure 3 i l l ustrates the I rDA 1.x connecti on model i n the
case of point-to-multipoint connectivity.
I rLAP connections are labeled by the (unordered) pair of
32-bit device addresses of the devices involved in the connec-
ti on. Fol l owi ng connecti on establ i shment, a temporary 7-bi t
connecti on address i s used i n the packets as an al i as for thi s
concatenated device address.
Likewise, I rLMP LM-MUX connections are labeled by the
(unordered) pai r of LSAP addresses at each end of the LM-
MUX connecti on. A corol l ary of thi s i s that at most onl y a
single LM-MUX connection may be established between any
two LSAPs.
Thi s connecti on model i s i denti cal to that offer ed by
TCP/I P where, semantically, I P addresses may be substituted
for I rDA device addresses and TCP/I P port numbers are sub-
stituted for I rLMP LSAP selectors.
Device and Service Discovery
I rLAP provi des a basi c devi ce di scovery mechani sm. Func-
tionally, the result of invoking the I rLAP discovery process is
a list of records that encode:
Device Address: A 32-bit semi-permanent device identifier
of the discovered device.
Ni ckname: A short mul ti l i ngual name for the di scovered
devi ce that may be presented i n user i nterfaces to ai d i n
selection.
Hi nts: A bi t mask gi vi ng nonauthori tati ve hi nts as to the
servi ces that may be avai l abl e on the di scovered devi ce.
This may be used to order deeper queries into the I AS to
authoritatively establish the presence or absence of a partic-
ular service.
The device discovery process is further abstracted through
I rLMP by defining procedures for the resolution of conflicting
device addresses, and hiding such issues from the LM-MUX
user.
Devi ce di scovery enabl es enti ti es wi thi n one devi ce to
establish the presence of other devices. However, for a system
to be l argel y autoconfi guri ng and to operate wi th mi ni mum
unnecessary intervention from the end user, it is essential that
application entities within one device be capable of identifying
and establishing contact with peer entities. These peer entities
share a common i nterface (or appl i cati on protocol ) that
enabl es them to i nteract. Contrast thi s wi th the si tuati on
where an end user is faced with the problem of ensuring that
the ri ght appl i cati ons are bound to the ri ght seri al ports, or
that the correct seri al ports are connected together and the
appropriate pin-pin mappings have been installed in the cable
depending on whether the connection is DTE-DCE or DTE-
DTE and on parti cul ar i di osyncrasi es i n the devi ces seri al
port implementation.
LM-I AS defines:
A set of operati ons that an I AS cl i ent may i nvoke on an
I AS server
The behavior of an I AS server
An information model for representing the application ser-
vices accessible at a given device
Starting with the information model, each application ser-
vice is represented by a named I AS object class. The name of
the object cl ass refl ects the name of the servi ce and may be
up to 60 octets in length. A hierarchical naming convention is
used to avoid name space clashes and to minimize the admin-
istrative burden on the I rDA office. I t also in effect provides
open and equitable access to the class namespace. Thus, class-
names that start I rDA: are defi ned by I rDA, whi l e cl ass-
names that star t Hewl ett-Packar d: ar e defi ned by the
Hewlett-Packard Company, and so forth.
An obj ect cl ass acts as a contai ner for a l i st of
attribute/value pairs. Attributes are named, and in general the
attribute namespace is scoped by the enclosing class. Howev-
I EEE Personal Communications February 2000
IFigure 3.Connection model.
LSAP-SEL= Q
LSAP-SEL= I LSAP-SEL= J
LSAP-SEL= P
LM -M UX
l ayer
St at i on A
mul t i poi nt
pri mary
LM -M UX
l ayer
LM -M UX
cl i ent s
LM -M UX
cl i ent s
LM -M UX
l ayer
IrLAP
l ayer
IrLAP
Layer
IrLAP
l ayer
St at i on B
secondary
St at i on C
secondary
LSAP-SEL= X
LM -M UX cl i ent s
LSAP-SEL= Y
Key
IrLAP-connect i on
LSAP-connect i on
IrLAP servi ce
access poi nt (LSAP)
Li nk servi ce access
poi nt (LSAP)
Connect i on endpoi nt
15
er, by conventi on some attri butes are of such gl obal uti l i ty
that they are deemed to have the same semantics in all scopes.
Such attributes carry hierarchically structured names that fol-
l ow the same syntacti c conventi ons as the I AS cl assname.
Thus, I rDA:I rLMP:LsapSel and I rDA:TinyTP:LsapSel are the
names of globally scoped attributes that carry the LSAP selec-
tor porti on of the address of the enti ty represented by an
instance of the object. I rDA:I rLMP:I nstanceName is a global-
l y scoped attri bute used to carry a di sti ngui shi ng name that
may be used in user interfaces to aid in selection when multi-
ple instances of a given service are found on a single device.
There are three attribute value types:
I nteger: A 32-bit signed integer.
User strings: I ntended for presentation via a user interface;
up to 255 octets in length with multilingual support.
Octet sequence: An opaque sequence of up to 1024 octets
of information. The attribute may impose further structure
on the contents of the sequence. This is a good way to clus-
ter a body of information under one attribute.
I rLMP defi nes a number of operati ons for traversi ng and
retrieving information from an I AS information base; howev-
er, only the GetValueByClass operation is mandatory. A pos-
sible C function prototype for the client operation would be:
AttributeValueList
GetValueByClass(ClassName class,
AttributeName attribute);
where the resul t type, Attri buteLi st, encapsul ates a possi bl y
empty l i st of object i nstance i ds and attri bute val ues from
objects that match gi ven object and attri bute names. Thus, a
si ngl e i nvocati on may resul t i n responses for mul ti pl e object
instances, and further attributes, such as instance names, may
need to be sought i n order for an appropri ate choi ce to be
made.
The I rDA pl atform provi des a space for the defi ni ti on of
new applications and application services above the platform.
I n defining new services it places three obligations on the ser-
vice designer:
The definition of an I AS object class
The definition of a hints mask that indicates the strong like-
lihood that an instance of that service exists on the discov-
ered device
The defi ni ti on of the semanti cs of the appl i cati on l evel
i nteracti on and the communi cati on stack profi l e(s) that
provides the channel for the interaction
IrDA-Data, 1.x Platform Summary
Before moving on to consider some of the application services
defi ned above the I rDA pl atform, a bri ef recap of what we
have described so far is whorthwhile.
The I rDA platform provides a connection model identical to
that provided by TCP/I P. The semantics of the Tiny TP trans-
port service are sufficiently close to those of TCP that in practi-
cal implementations they can be provided through an application
programming interface (API ) based on Berkeley sockets.
Naming and addressing in I rDA differs from TCP/I P nam-
ing and addressing. Device addresses are flat and dynamically
assi gned. Whi l e devi ce addresses change i nfrequentl y, auto-
mated processes do force change when confl i cts ari se. Both
the names and addresses of devices are explicitly discovered.
Nei ther are assumed to be known a pri ori . Servi ces i n the
I rDA envi ronment are named usi ng I AS cl assnames. These
names are dynamically mapped to I rLMP LSAPs and/or Tiny
TP TSAPs thr ough I AS quer i es. Thi s dynami c mappi ng
reduces the admi ni strati ve burden i mposed on the I rDA
office. With the limited 7-bit port address space of the LM-
MUX, i t al so removes the probl em of organi zati ons maki ng
unfair claims on address space real estate.
Device discovery and LM-I AS provide the pivotal ease-of-
use features in the platform that enable application entities to
locate and establish contact with peer entities which support a
given interaction protocol (i.e., the semantics of the message
set exchanged between appl i cati on enti ti es vi a the channel
established through the I rDA platform).
Advanced Infrared
The I rDA-Data 1.x architecture has some obvious limitations.
First, although the architecture can accommodate a point-
to-multipoint mode of operation, the I rLAP specification has
never been extended to defi ne the protocol machi nery to
enable that functionality. From an end-user point of view it is
also questionable whether such extension of the 1.x platform is
even desi rabl e. Vi ewed as a si ngl e poi nt-to-poi nt l i nk, the
behavior of an I rLAP connection is largely symmetric, and the
differences in behavior between an I rLAP primary station and
an I rLAP secondary stati on are l argel y moot. However, the
i ntroducti on of poi nt-to-mul ti poi nt operati on woul d si gni fi -
cantly disturb this symmetry in ways that would become incon-
veni ent for the end user. Consi der a portabl e computer that
needs to access both a LAN access point and a desktop print-
er. I t woul d be natural for the portabl e computer to become
the I rLAP primary and establish I rLAP connections with the
LAN access poi nt and the pri nter, each of whi ch acts as an
I rLAP secondary stati on. However, i t i s al so reasonabl e that
the LAN access point (or the printer for that matter) is capa-
ble of serving multiple clients, but in order for it to do that
it would itself have to take on the I rLAP primary role. I f the
connection to the LAN access point were established first and
the access poi nt were to cease the pri mary rol e (possi bl y
through role reversal), the portable computer would be unable
to establi sh a second I rLAP connecti on to the pri nter. I f the
portable computer retained the primary role, it could establish
that second connecti on, but the LAN access poi nt (and the
printer) would be prevented from establishing connections to
other potential clients. What the user could achieve would
not onl y depend on the set of concurrent i nteracti ons they
were attempti ng to i ni ti ate, but al so on the order i n whi ch
those interactions were initiated. This would lead to inconsis-
tent behavi or whi ch woul d become frustrati ng for end users.
Thus, I rDA so far has chosen not to expand the I rLAP defini-
tion to encompass point-to-multipoint operation.
Second, within some given field of view, the establishment
of an I rLAP connecti on between a si ngl e pai r of devi ces
inhibits the establishment of connections between other inde-
pendent devi ces whose fi el ds of vi ew i ntersect that of the
establ i shed connecti on. Thus, use of the medi um becomes
dedicated to a single pair of devices. An important subclass of
general mul ti poi nt communi cati on i n a shared medi um i s to
enable multiple independent pairs of devices to establish inde-
pendent communi cati on rel ati onshi ps. I f two devi ces are i n
view of each other, it is reasonable that they should be able to
establ i sh communi cati ons and share access to the medi um
with other users of the space.
Thus, members of the I rDA communi ty sought to extend
the I rDA-Data architecture to enable true multipoint connec-
ti vi ty whi l e at the same ti me preservi ng the i nvestment i n
upper l ayer appl i cati ons and servi ces by ensuri ng that the
semantics of the service definitions at the upper layers of the
platform are maintained.
I t i s i mportant to be aware of a few di fferences between
the goal s of the I rDA communi ty and the goal s of those
defining wireless LAN specifications. The I EEE 802 medium
access control (MAC) servi ce defi nes a best-effort ordered
del i very servi ce wi th at most oncedel i very semanti cs. I t al so
I EEE Personal Communications February 2000
16
assumes a transi ti ve communi cati ons rel ati onshi p. At the
MAC layer:
I F A can communicate with B
AND B can communicate with C
THEN A can communicate with C.
I n the world of short-range i nfrared wi reless communi cati on
this is not the case. I t may even be the case that the communi-
cation relationship is asymmetric: A may be heard by B, but
B cannot be heard by A. With the wired LAN medium the
notion of belonging to a particular LAN segment is strongly
associated with a physical attachment to that segment. Arrivals
and departures, infrequent in most wired cases, can be noted
by both the arriving/departing node, and potentially the wired
i nfrastructure and the other devi ces attached to that i nfra-
structure. I n the wi rel ess case, the bounds of a gi ven LAN
segment are l ess wel l defi ned, and arri val and departure are
much more the norm.
Thus, the primary goals in extending I rDA-Datas connec-
tion model were:
To enable devices in view of one another to establish com-
muni cati on rel ati onshi ps uni nhi bi ted by the connecti on
state of nearby devices.
To enabl e an advanced i nfrared (AI R) devi ce to establ i sh
communi cati ons wi th at most one I rDA 1.x devi ce. Thi s
enables AI R devices to interoperate with legacy 1.x devices
i n a way that i s wel l under stood by user s of l egacy 1.x
devices.
For AI R devi ces to respect establ i shed I rDA 1.x connec-
tions with which they could interfere. This is a coexistence
requi rement i ntended to ensure that AI R devi ces do not
disrupt active I rDA 1.x connections
From an architectural point of view it is relatively simple to
introduce multi-access communication. I t requires that I rLAP
be partitioned into a MAC layer (I rMAC) [14] and a link con-
trol layer (I rLC) [16]. I n fact, as illustrated in Fig. 4, the AI R
protocol archi tecture adds an I rLC pro-
tocol enti ty, whi ch provi des mul ti poi nt
l i nk l ayer connecti vi ty al ongsi de an
I rLAP protocol enti ty, whi ch provi des
l egacy connecti vi ty to I rDA 1.x devi ces.
The l i nk manager (I rLM) l ayer [17] i s a
thi n l ayer that mul ti pl exes the use of
I rLAP and I rLC over thei r respecti ve
physi cal l ayers. At the upper bound of
the l i nk control l ayer, I rLC and I rLAP
provi de i denti cal servi ces to the I rLMP
l ayer. Thus, wi thi n an AI R devi ce, the
I rLAP, I rLC, and I rLM protocol entities
may be regarded as a single logical entity,
wi th a si ngl e devi ce address whi ch sup-
ports an i ntegrated di scovery process,
and both I rLAP and I rLC connecti ons.
The particular use of I rDA 1.x I rLAP or
AI R I rLC procedures for establ i shi ng
devi ce-to-devi ce connecti ons becomes
transparent to I rLMP entities and above.
I rMAC defi nes a burst reservati on
carri er sense mul ti pl e access wi th col l i -
si on avoi dance (CSMA/CA) MAC pro-
tocol . Such MAC protocol s rel y on the
exchange of Request-To-Send, Clear-to-
Send MAC protocol data uni ts (PDUs).
For such a mechanism to function prop-
erl y, i t i s i mportant that the reservati on
MAC PDUs be decoded, not onl y by
devi ces capabl e of engagi ng i n commu-
ni cati ons, but al so by devi ces capabl e of
i nterferi ng wi th communi cati ons. I n some radi o frequency
(RF) systems usi ng thi s style of MAC protocol, the range of
the reservati on messages i s extended by boosti ng the trans-
mi ssi on power for the rel ated MAC PDUs. AI R makes use
of a variable rate (VR) coding technique known as repetition
codingto robustl y code the headers of al l AI R MAC PDUs.
The use of thi s techni que was pi oneered by I BM Research
i n Zuri ch [18], and full detai ls are gi ven i n the AI R physi cal
l ayer speci fi cati on [19]. Repeti ti on codi ng trades si gnal -to-
noi se rati o (SNR) (range) for transmi ssi on rate by repeti -
ti on of physi cal l ayer symbol s. Repeti ti on decoder s
average the repeated symbol s recei ved pri or to maki ng a
deci si on on what symbol was encoded. I n theory, successi ve
halving of the data rate by successively doubling the number
of symbol repeti ti ons yi el ds approxi matel y a 19 percent
range i ncrease at each reducti on step. Cumul ati vel y, the
effect of a 16-fold rate reduction (four doublings of the rep-
eti ti on r ate) yi el ds a doubl i ng of the effecti ve r ange of
transmi ssi on. Key fi el ds of the AI R I rMAC [17] PDUs are
coded with 16x repetition.
Thi s VR physi cal layer deli vers two benefi ts. Fi rst, i t pro-
vi des a means of robustly codi ng the medi a reservati on mes-
sages defi ned by the CSMA/CA bur st r eser vati on MAC
protocol defi ned i n the I rMAC speci fi cati on so that they
reach more potential sources of interference.
Second, by actively monitoring the symbol error rates at an
AI R decoder, it is possible it estimate the SNR for the chan-
nel between the source and si nk of a packet. Thi s SNR esti -
mate can then be used to compute a rate recommendati on
that can be fed back to the sendi ng stati on i n order to mai n-
tain a good-quality channel. AI Rs base rate is 4 Mb/s, reduc-
i ng through successi ve hal vi ng of data rates to 256 kb/s to
yield a doubling of range. AI R prototypes have been demon-
strated that have a 4 Mb/s range of 5 m doubl i ng to 10 m at
256 kb/s.
I EEE Personal Communications February 2000
IFigure 4.IrDA data advanceIR protocol architecture.
Pl at f orm
Appl i cat i on and communi cat i on servi ces
Legacy
comm apps
Net w orked
appl i cat i ons
Legacy
net w ork st ack
IrPPP IrLAN IrCOM
"Appl i ance"
appl i cat i ons
IrTRAN-P
IrO BEX Jet send
Physi cal
IrDA1.x AIR
LAS
SIR FIR VFTR M IR
IrLM P
IrLAP
TTP
LAS
IrLM P
IrLap IrLC
IrDA 1.x VR-PHY
IrLM
IrM AC
TTP
17
The AIR Connection Model
Fi gure 5 i l l ustrates the extended AI R connecti on model
regarding the I rLAP, I rLC, and I rLM entities within a station
as si ngl e protocol enti ty, wi th a si ngl e servi ce access poi nt
(I SAP), capable of supporting multiple connection endpoints.
LSAP addresses, as before, are formed by the concatenation of
an I rLAP/I rLC device address and an I rLMP LM-MUX LSAP
selector. I rLMP LM-MUX connections, as before, are labeled
by pai ri ng the LSAP addresses from each end of the LM-
MUX connecti on. As before, there i s a 1:1 correspondence
between Tiny TP connections and LM-MUX connections.
IrDA Legacy
Communications Services
Seri al port emul ati on and LAN access were regarded as two
forms of cabl ed connecti on that I rDA coul d repl ace. Whi l e
serial port communication is acceptable at link rates of up to
115.2 kb/s, LAN access provi ded one of the pri mary moti va-
tions to push the data rate to 4 Mb/s and beyond.
IrCOMM
Ther e wer e two key moti vator behi nd the defi ni ti on of
I rCOMM [8].
Fi rst, there was the percei ved need to provi de a seri al
cabl e repl acement for l egacy appl i cati ons. Thus, tradi ti onal
communi cati ons appl i cati ons, such as Kermi t, coul d be used
over an emul ated seri al port connecti on. At fi rst gl ance thi s
may appear a little odd. However, the I R medium, at least as
used by the I rDA, i s a hal f-dupl ex medi um. Data can onl y
flow in a single direction at a time. The I rDA platform impos-
es a media access discipline that shields platform clients from
the need to be aware of the l i mi tati ons of the medi um and
abstracts multiple duplex channels. I n addition, many commu-
ni cati ons appl i cati ons make use of fl ow control and modem
control l i nes. There i s a need to communi cate the vi rtual
state of these si gnal s i n addi ti on to the char acter data
exchanged between devices.
Second, there was a need in the telecommunications com-
munity to enable infrared access to the telephony network.
I rCOMM provides for both DTE-DTE (null modem) com-
muni cati ons and DTE-DCE communi cati ons. I n addi ti on,
unlike in the wired equivalent of these scenarios, the end user
is completely unaware of the difference.
I rCOMM i s typi cal l y i mpl emented as a seri al port dri ver
which, rather than interacting with real serial port hardware,
i mpl ements the I rCOMM protocol to i nteract wi th a peer
I rCOMM enti ty to transfer data between thei r respecti ve
clients.
I rCOMM supports 3- and 9-wire modes of operation. The
9-wire case includes modem control lines. The relative timing
of modem control line state changes can be maintained to the
level of the boundaries between characters.
Appl i cati ons runni ng over I rCOMM do not benefi t from
all the ease-of-use features the I rDA platform provides. This
occurs because of the very nature of serial communications.
The open/cl ose operati ons i n most seri al API s are about
local resource allocation, typically a local serial port resource.
They are not about (physi cal ) connecti on establ i shment.
I ndeed, i t becomes obvi ous after a few moments that seri al
API s cannot be expected to provi de for physi cal connecti on
establ i shment. That i s somethi ng that the user does... wi th a
cable! Therefore, there i s no way at the seri al port API level
for an application to express anything through the API about
the nature or identity of the remote peer with which it wishes
to establish communication.
I n the same way as it is possible for an application to open
a real seri al port when there i s no cabl e pl ugged i nto i t, i t i s
possible for an application to open an I rCOMM virtual serial
port when there is no device in the vicinity with which to com-
muni cate. Once opened, an I rCOMM vi rtual seri al port wi l l
acti vel y seek out peer enti ti es wi th whi ch to communi cate.
Typi cal l y, i nstances of I rCOMM wi l l renew efforts to fi nd a
peer as applications continue to pump data into the virtu-
I EEE Personal Communications February 2000
IFigure 5.IrDA-data AI connection model.
LM -M UX cl i ent s
LM -M UX l ayer
St at i on C
IrDA1 .x secondary
LM -M UX l ayer
IrLAP
l ayer
LM -M UX cl i ent s
IrLAP
LSAP-SEL= P LSAP-SEL= Q
LSAP-SEL= X
LSAP-SEL= I LSAP-SEL= J
LSAP-SEL= Y
LSAP-SEL= R
LM -M UX cl i ent s
LM -M UX cl i ent s
LM-MUX layer
LM-MUX layer
St at i on B
IrDA-AIR
St at i on D
IrDA-AIR
IrLAP-connect i on
LSAP-connect i on
Servi ce access poi nt (SAP)
Connect i on poi nt
St at i on A
IrDA-AIR
(al so act s as IRDA 1.x pri mary)
18
al seri al port. The presence of buffered data may sti mul ate
periodic discovery processes. Semantically, data pumped into
a disconnected serial port can be lost.
As wi th real seri al ports, the end user needs to expl i ci tl y
control which applications are bound to the virtual serial port.
I t i s possi bl e for a gi ven devi ce to support mul ti pl e vi rtual
seri al ports. However, a devi ce encounteri ng another devi ce
with multiple virtual serial ports is faced with a problem. This
problem is similar to that of encountering a device with multi-
ple real serial ports where the labeling next to the serial ports
has been rubbed out, and where the mapping between operat-
i ng-system-speci fi c l ogi cal devi ce names (/dev/tty0, COM1,
etc.) and physical ports is unknown.
This is an ugly problem for real serial communications and
remains an ease-of-use challenge for legacy applications in the
world of short-range wireless communications.
Nevertheless, I rCOMM has found widespread application
in mobile phones, and there has been significant deployment
i n I SDN payphones i n the Tokyo area. Such depl oyment
allows relatively trouble-free dialup access to the internet.
IrLAN
I rLAN [9] adopts a si mi l ar phi l osophy to I rCOMM i n order
to support legacy networking applications.
Typi cal l y, I rLAN operates i n access-poi nt mode where
the combi nati on of the I rLAN protocol operati ng over the
I rDA stack to an I rLAN LAN access point is equivalent to a
regul ar LAN card and provi des 802 LAN MAC servi ce. Just
as I rCOMM i s typi cal l y i mpl emented as a seri al port dri ver,
I rLAN is typically implemented as a LAN card driver.
I rLAN can operate in a peer-to-peer mode that effectively
model s a stub-LAN wi th just two devi ces attached. Legacy
networking protocols such as classic NetBios can establish ad
hoc network communications file and print sharing in such an
environment.
However, peer-to-peer I rLAN operation is of little use for
most TCP/I P implementations since it fails to provide the infra-
structure such as DHCP for autoconfiguration, Domain Name
Service (DNS) for name-address resolution, or any of the other
infrastructure services whose existence is generally assumed by
applications programmed for the TCP environment.
I rLAN has proved controversial. I ts sustained deployment
in operating systems is in question and is likely to be superced-
ed by a model based on Point-to-Point Protocol (PPP) which
leverages superior access controls, autoconfiguration, encryp-
tion, and header compression facilities from PPP.
IrDA Application Services
IrOBEX
I rOBEX [10] seeks to be regarded as the HTTP of I rDA.
Like HTTP, it precedes the transfer of some data object with
a set of headers that carry meta-data about the object such as
i ts name, si ze, and type. I rOBEX supports both PUT and
GET operations.
Currently, the dominant use of I rOBEX is for the transfer
of file-like objects such as document files, electronic business
cards (vCards), and appointments (vCalendar). Content typing
and nami ng conventi ons can be used to l aunch appl i cati ons
appropriated for the content type being transferred. HTTP is
used typi cal l y usi ng a PULL model , whereas the domi nant
usage model for I rOBEX is a PUSH model. A user squirts
information from one device to another. The premier example
is that of the exchange of business cards between PDAs. The
author has also used a commercially available I rOBEX imple-
mentation to transfer the accumulated 2 Gbytes of files built
up on one congested por tabl e PC to i ts successor one
eveni ng i n the li vi ng room. That si ngle i nstance of use alone
coul d, for many, justi fy the $35 cost the i ncl usi on of I rDA
adds to a portable PC.
I r OBEX i s defi ni ng semanti cs for sequences of PUT
and/or GET operations to achieve such objectives as address
book and di ar y synchr oni zati on between phones, smar t
phones, PDAs, portable PCs, and pagers.
IrTRAN-P
I rTRAN-P [11] is an image transfer protocol defined by mem-
bers of I rDA for the exchange of images between digital cam-
eras, PCs, PDAs, and photo-printers.
I rTRAN-P cameras can be used in conjunction with PDAs,
mobile phones, and smart phones to accomplish such things as
gathering data, and e-mailing or faxing it back to the office. A
more soci al vari ati on of thi s noti on mi ght be dubbed the
I nstant Postcard.
I rTRAN-P saw widespread deployment in digital cameras
i n the Asi an marketpl ace pri or to the 1998 Nagano Wi nter
Olympics. These cameras have been used in conjunction with
the previously mentioned I SDN payphones and street kiosks.
These kiosks either generate small printed address book stick-
ers or enable the images to be uploaded to Web sites so that
they can be shared more widely.
IrJetSend
JetSend [14] is an open appliance interaction protocol defined
by Hewl ett-Packard. JetSend-based appl i ance i nteracti ons
embody the strong principle that the participating appliances
do not model each other. JetSend devi ces share a model of
the structure of i nformati on, e-materi al , and can engage i n
mul ti l evel negoti ati on over the encodi ng used to exchange
i nformati on. A mandatory encodi ng exi st for ALL defi ned
content types, ensur i ng a base l evel of i nter oper abi l i ty
between JetSend appliances. JetSend also provides a control
protocol such that appl i ances may render UI arti facts on
behalf of appliances with which they are connected.
Underlying all JetSend interactions is an object interaction
model based on surface interaction. This is an unconventional
obj ect model . Consi stency of obj ect state i s mai ntai ned
through the application of internal rules. Some portion of an
objects state i s exposed at i ts surface. The surfaces of con-
nected objects are impressed on one another (simple equiva-
lence between connected surface artifacts). Dynamic behavior
ari ses from di sturbance of state and the appl i cati on of the
internal rules until the overall state becomes stable or cyclic.
I nteraction policies enable interactions to be structured to
represent the transfer of a document, or the dynamic status of
a device to be monitored.
JetSend was ori gi nal l y depl oyed i n i magi ng and hardcopy
devices connected to the I nternet. More recently, a means of
binding JetSend to the I rDA platform has been defined [13].
A number of commerci al devi ces exi st that both source and
sink JetSend eMaterial over the I rDA platform.
IrDA Futures
I rDA has grown up late i n the era of the PC and at the start
of the information appliance age. Today it is exciting to see its
adopti on i n such di verse devi ces as mobi l e phones, PDAs,
pagers, digital cameras, portable scanners, access points, and
printers. I t is exciting to consider the device and service inter-
acti on possi bi l i ti es that a pervasi ve short-range communi ca-
ti on technol ogy enabl es. The range of devi ce categori es that
embed the I rDA communi cati on pl atform i s expandi ng. The
means by which such devices can gain access to infrastructure
over an initial short-range hop is expanding. This leads to an
I EEE Personal Communications February 2000
19 I EEE Personal Communications February 2000
expl osi on i n the potenti al for devi ces to i nteract wi th one
another, ei ther i n the i mmedi ate vi ci ni ty or remotel y across
i nfrastructure. I t l eads to an expl osi on i n the potenti al for
devices to interact with entities and services embedded within
the infrastructure.
However, with all this potential there is massive challenge.
Do we aggregate functionality into ever more complex appli-
ances, or do we separate functionality into devices focused on
doing one thing well? Can we find methods of interaction that
enable the functions of a collection of single-function devices
and i nfrastructure-based servi ces to be composed to achi eve
some larger end-user goal which we might regard as a dynam-
ically composed application? Can we do this in ways that are
i ntui ti ve for end users, where the outcome of an i nteracti on
needs to be both predictable and useful? I f I send an electron-
ic business card from an organizer to a mobile phone, what is
the mobile phone expected to do? I t could dial the number on
the card, fi l e i t away i n i ts address book, fax i t to some
remote recipient, and in the not too distant future it might e-
mail it somewhere else. What is that same phone expected to
do wi th a photograph sent from a di gi tal camera? Both of
these interactions are possible with off-the-shelf I rDA-enabled
products today.
The i nformati on exchanged between devi ces need not be
static, either. Financial transactions between electronic wallets
are being accomplished over I rDA [20]. The advent of virtual
machi ne envi ronments and mobi le objects such as Java/RMI
and di stri buted computi ng frameworks such as Ji ni provi de
the opportunity to apply these technologies in an I rDA envi-
ronment. Thi s l eads to the possi bi l i ty of exchangi ng acti ve
objects, perhaps representi ng goal -dri ven agents, between
devices and between devices and infrastructure.
At some point as we go up through these layers of abstrac-
tion, it is no longer appropriate to confine those abstractions
to the I rDA environment. They become of much broader util-
i ty, and another si gni fi cant chal l enge wi l l be to del i ver these
capabilities through upper-layer application services in consis-
tent ways across a range of l ower-l ayer short-range wi rel ess
technologies.
I n I rDA AI R i s i n the fi nal stages of bei ng adopted. I t
offers to improve the freedom of movement available to I rDA
devices that adopt the technology. They will be freed from the
restri cti ve 1 m,1530 degree hal f-angl e coverage profi l e of
I rDA 1.x, and enabl ed to operate over greater range and
wi der angl e. Just as wi th RF wi rel ess technol ogi es, thi s wi l l
present new user i nterface chal l enges too, si nce, i n general ,
the target of a gi ven i nteracti on can no l onger be resol ved
merely by pointing.
I rDA offers a flexible, globally pervasive short-range wire-
l ess communi cati ons pl atform for appl i ance bui l ders. I ts
wi despread adopti on I n devi ces to date greatl y reduces the
ri sks associ ated wi th embeddi ng i t i n new devi ce categori es.
I ts range of appl i cati on wi l l conti nue to grow wel l i nto the
new millennium.
Acknowledgments
The author woul d l i ke to thank the I rDA presi dent, Mi ke
Watson of Calibre-I nc., and Parviz Kermani of I BM Research,
as wel l as the Hewl ett-Packard Company for thei r support,
encouragement, and review of this article.
References
[ 1] P. D. Brow n, L. S. M oore, and D. C. York, Low Pow er Opt i cal Transcei v-
er f o r Po r t ab l e Co m p u t i n g Dev i ces, U. S. Pat en t No . 5 , 0 7 5 , 7 9 2 ,
Assi gnee: Hew l et t -Packard Company, Dec. 24, 1991.
[ 2] T. F. Wi l l i am s, P. D. Ho r t en si u s, an d F. No vak, Pr o p o sal f o r : In f r ar ed
Dat a Associ at i on Ser i al Inf r ar ed Li nk Pr ot ocol Speci f i cat i on, v. 1.0, IBM
Corp., Aug. 27, 1993.
[ 3] ISO, Hi gh Level Dat a Li nk Cont r ol (HDLC) Pr ocedur es - El ement s of Pr o-
cedures, ISO/IEC 4335, Sept . 15, 1991.
[ 4] IrDA, Seri al Inf rared Li nk Access Prot ocol (IrLAP), v. 1.1, June 1996.
[ 5] IrDA, Li nk M anagement Prot ocol , v. 1.1, Jan. 1996.
[ 6 ] I r DA, Ser i al I n f r ar ed Ph ysi cal Layer Li n k Sp eci f i cat i o n , v. 1 . 3 , Oct .
1998.
[ 7] Ir DA, Ti n yTP: A Fl o w -Co n t r o l M ech an i sm f o r Use w i t h Ir LM P, v. 1. 1,
Oct . 1996.
[ 8] IrDA, IrCOM M : Seri al and Paral l el Port Emul at i on over IR (Wi re Repl ace-
ment ), v. 1.0, Nov. 1995.
[ 9] Ir DA, LAN Access Ext ensi ons f or Li nk M anagement Pr ot ocol Ir LAN, v.
1.0, Jul y 1997.
[ 10] IrDA, Obj ect Exchange Prot ocol , v. 0.1a, Jan. 4, 1995.
[ 11] Ir DA, Ir Tr an - P (In f r ar ed Tr an sf er Pi ct u r e) Sp eci f i cat i o n , v. 1. 0, Oct .
1997.
[ 1 2 ] Ir DA, Sp eci f i cat i o n s f o r Ir M o b i l e Co m m u n i cat i o n s (Ir M C), v. 1 . 1 ,
M ar. 1999.
[ 13] Ir DA, Jet Sen d (t m) Pr o t o co l o n Ir DA Ap p l i cat i o n No t e, v. 1. 0, Sep t .
1998.
[ 14] Hew l et t -Packar d , HP Jet Sen d Co mmu n i cat i o n s Tech n o l o g y Pr o t o co l
Speci f i cat i on, v. 1.0, Jul y 1997
[ 15] IBM Co r p . , Ad van ced In f r ar ed (AIr ) M AC Sp eci f i cat i o n , v. 0. 3, Jan .
1999; avai l abl e at IrDA M embers FTP Si t e.
[ 16] IBM Co r p . , Ad van ced In f r ar ed Lo g i cal Li n k Co n t r o l (Ai r LC) Sp eci f i ca-
t i on, v. 0.1, Jan. 1999; avai l abl e at IrDA M embers FTP Si t e.
[ 17] IBM Cor p ., Ad vanced Ir Li nk M anager . (Ai r LM ) Sp eci f i cat i on, v. 0.3,
June 1999; avai l abl e at IrDA M embers FTP si t e.
[ 1 8 ] F. Gf el l er et al . , Wi r el ess I n f r ar ed Tr an sm i ssi o n : Ho w t o Reach Al l
Of f i ce Space, Proc. VTC 96, vol . 3 pp. 15359.
[ 1 9 ] Ir DA, Ir DA Ad van ced In f r ar ed Ph ysi cal Layer Sp eci f i cat i o n , v. 1 . 0 ,
Sept . 1998.
[ 20] Conf i ni t y Inc., ht t p://w w w .paypal .com
Biography
STUART WILLIAM S (skw @hp l b . hp l . hp . com) r ecei ved Bachel or of Sci ence and
Ph.D. degrees i n el ect ri cal and el ect roni c engi neeri ng f rom t he Uni versi t y of
Bat h , Un i t ed Ki n g d o m i n 1981 an d 1986. He i s a t ech n i cal co n t r i b u t o r at
Hew l et t -Packar d Labor at or i es, Br i st ol , Engl and. Bet w een 1994 and 1998 he
w as r esp o n si b l e f o r m an ag i n g a r esear ch t eam f o cu sed o n t h e u se o f
f r eesp ace i n f r ar ed f o r sh o r t -r an g e w i r el ess d at a co mmu n i cat i o n s. Du r i n g
t hi s p er i od he mad e numer ous t echni cal cont r i b ut i ons t o t he w or k of t he
I n f r ar ed Dat a Asso ci at i o n (I r DA) an d h as ser ved as co - ch ai r o f t h e I r DA
Techni cal Commi t t ee. Pr i or t o j oi ni ng Hew l et t -Packar d i n 1992, he w or ked
f o r seven year s o n LAN an d r o u t i n g t ech n o l o g i es at Br i t i sh Tel eco m s
M art l esham Heat h Laborat ori es.