IrDA: Past, Present and Future

8/11/2019 IrDA: Past, Present and Future

http://slidepdf.com/reader/full/irda-past-present-and-future 1/911

he Infrared Data Associat ion(IrD A) was formed in J une 1993 and has worked steadily toestablish specifications for a low-cost, interoperable, and easy-to-use wireless communicat ions t echnology . Toda y , theinfrared da ta communicat ion technologies defined by theIrD A ship in over 40 million new devices each yea r rangingfrom personal computers, personal digital a ssistants (PD As),digital cameras, mobile phones, pagers, porta ble informationgathering appliances, and printers.

It is a remarkable a chievement for a new communications

technology to establish such widespread deployment in such awide range of devices in such a relatively short time. The coreInternet platform technologies existed for a full 10 years priorto the explosive growth brought about by the introduction ofthe Web.

IrDA is a communication technology for the appliance era.This is an era that , whi le not excluding the PC , l ibera tesdevices that have long been viewed as peripherals. It enablesthem to engage in useful interactions with each other withouthaving to mediate their communications through some com-mon control point.

End users have remarkably high expectations of wirelesscommunications. In the wired world there is general accep-tance of the mechanical constraints imposed by the variousplugs and sockets that, at least in part, a void mismatched con-

nections. There is acceptance of the cognitive load required tosort out the connectivity and clutter of cabling at the rear of ah i-f i se tup or the back of a PC . H owever , in the wirelessworld, there is an expectation that communications and con-nectivity will just work, and work simply. In t he wired wo rldshort-range connectivity between d evices is established byexplicit actions on the pa rt of the end user. In the wirelessworld there is an expecta t ion tha t connect iv ity betweendevices will be established as required without explicit inter-vention by the end user. The expectat ion is that if the userat tempts to print , the “ system” will seek out and establishconnectivity to a nearby printer.

The author regularly finds it remarkable tha t he ca n usethe same infrared port to:

• Simply “squirt” files between devices

• Connect to the local LAN• Dial in f rom a portable PC or PD A via an I rDA-enabled

cell phone• Print to an IrD A-enabled printerAll of this is achieved without reconfiguring between actionsand in most cases merely by placing the appropriate devices inproximity to one another.

The work of IrD A has sought to go far beyond mere cablereplacement, and provide a communications platform andapplication services fit for t he era o f informa tion a ppliances

and which excel in the area of ease of use.

A Br ief History of IrDA-Data

The IrD A was formed in June 1993 to d evelop an interopera-ble, low-cost and easy-to-use, short-range, infra red, wirelesscommunications technology. The inaugural meeting wasatt ended by 70+ companies which recognized the consider-able value of defining a single family of specifications for thecommunication of data over infrared.

P rior to June 1993, a number of no ninteroperable single-vendor proprietary schemes for infrared data communicationsexisted. There was considerable risk that the marketplace forshort-range w ireless infrared communications wo uld fra gmentaround a number of proprietary schemes, all of which would

individually fa il to a chieve critical mass. For system a nd periph-eral vendors eager to deploy short-range wireless solutions intheir information appliances, the absence of a dominant, com-mon connectivity technology represented a void. Without adominant technology, the risk of choosing the wrong propri-eta ry technology was significant. Thus, there was considerableshared interest in the generation of common specifications, andthis set the tone for the ea rly years of the IrD A.

The original requirements can be summarized as:• Marginal cost to add infrared to a product , under $5• D ata r at es of up to 115 kb/s• Range from contact (0 m) through at least 1 m• Angular coverage defined by a 15–30 degree half-angle cone

By t he end of September, IrD A had selected one of 3 pro-

posed approaches for defining its physical layer [1] defined by

IEEE Personal Communications • February 2000 1070-9916/00/$10.00 © 2000 IE EE

T

IrDA: Past, Present and Future

St uar t Wi l l i ams, HP Labor a t or ies

Abstract

The core Internet 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 a s a place to find informat ion, access service, and tra de. The Infra red D ata Association has been in existence for over six

years. Prod ucts embedding the communication technolo gy IrD A defines have been around fo r over five years, star ting with printers and port able

P Cs. IrD A is cheap to embed, uses unregulated spectrum, and is increasingly pervasive in a wide range of devices. From its root s in porta ble PC s

and printers, IrDA 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 a ppliance age, and Ir D A is playing a significant role in enabling the intera ction between

information appliances, between information appliances and the information infrastructure, and between appliances communicating across the

informat ion infrastructure. This article discusses IrD A’s communications model. It charts the evolution of the IrD A-D at a (1.x) plat form architec-

ture, and the early applications and application services now in common use. It considers the present day and the explosion in device categories

embedding the IrDA platform. It broadens its horizons to consider other emerging appliances technologies and to consider communications

models that might a rise from a blend of IrD A short-range wireless communications and mobile object technologies. Finally, it briefly considers

future directions for the IrD A platform itself.

Williams0



Hewlett-Packard. All three approaches assumed the presenceof a UART that could be used to modulate the infrared trans-missions. The silicon cost of U AR T devices was well under-stood, and in many cases the system design of many productsincluded redundant U AR Ts; thus, the marginal cost of add ingIrDA could amount to just the components of the infrared

transceiver.So fa r, 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,bu t , a s we sh a l l s ee l a te r , th e q u est io n o f wh ic h cab leremained.

The natural abstraction of a half-duplex, asynchronouscharacter-oriented transmission was too poor an abstractionfor building interactions that were self-organizing and easy touse. In addit ion, there were freq uent discussions of how toselect data rate, how media access control was to function,and how, in the con text of a 115 kb/s link, reasona bly efficientuse could be made of the available bandwidt h.

B y November 1993 IrD A had sett led on a t oken-passingapproach , or ig ina ted by IB M [2] and der ived f rom high-

level da ta l ink contro l (HD LC ) [3] opera t ing in normalresponse mode (NRM). As with other proposals, this was apacket ized scheme. However , in contras t to content ion-based schemes that were also considered, the H D LC -SIR(later renamed Infrared Link Access Protocol, IrLAP [3])approa ch y ie lded content ion-free a ccess to the med iumonce initial communication had been established. IrLAPdefines a fixed-rate slotted contention-mode device discov-ery scheme that enables initial contact to be established.Critical communication parameters such as connection datarate, maximum packet sizes, and certain minimum and ma x-imum gap timings are negotiated during connection estab-lishment. Following IrLAP connection establishment, thetwo dev ic es en gaged in c o m m u n ic a t io n a re deem ed t o

“ ow n” the spatia l region which they both illuminate — nom-

inally the union of t wo overlapping1 m c o n es , e ac h w i th a 15–30degree half-angle.

I t so o n bec am e ap p aren t th a tthe definition of I rLAP would notbe suff ic ient to meet IrD A ’s ease-o f -u se go a l s . Cer ta in ly , I rL APwould provide a reliable connec-

tion- oriented communication ser-vice between two devices , bu t i tp ro v ided n o m ean s to iden t i f yprospec t ive c l ien ts o f the I rLAPcommunication services. The year1993 wa s a “ ho t ” per iod wi th theem ergen c e o f n u m ero u s PDAs ,notebook, and sub-notebook PCs. Itwas apparent tha t a model whichturned over the infra red communi-cation facilities to a single applica-t io n wo u ld be in adeq u a te . T h eemerging multithreaded consumerc o m p u t ing p la t fo rm s req u i red amultiplexing communications modelthat enabled several a pplications toshare access to the infrared commu-nications resources within a device.In t his way, multiple applicationscould passively listen for appropri-ate peer application entities to con-nect. Thus, in D ecember 1993 theactivity to define the Infrared Link

Management Protocol (IrLMP) [5] was born.IrLMP provides a connection-oriented multiplexer, LM-

MU X, a nd a lookup service, LM-IAS, that ena bles multipleIrLMP clients to claim a “ port” a bove the multiplexer a ndadvertise their availability by placing critical conta ct infor-mat ion in to the lo okup service . The namespace fo r the

lookup service is designed to be self-administering in orderto a vo id th e bu reau c rac y o f m a in ta in in g adm in ist r a t iverecords about namespace registrations and to ensure “ fairaccess” to make use of the namespace.

B y June 1994, just 12 months after t he inaugural IrD Ameeting, version 1.0 of t he core IrD A platfo rm specifications,IrPH Y, IrLAP , and IrLMP , was released [4–6].

Work continued to define a per-connection flow controlscheme to operate within IrLM P connections. When multi-plexing above a reliable connection, unless there is a means ofindependent flow control for each derived channel, the deliv-ery property o f the der ived channel is reduced to “ best-effort.” Per-channel flow control restores a “ reliable” deliveryproperty. This work led to the d efinition o f t he Tiny Trans-port Protocol (Tiny TP or TTP) [7].

I rP H Y , I rL AP, I rL MP , an d Tin yTP a re th e c u r ren t lyaccepted specifications that define the core of the IrD A plat-form, often referred to as the IrDA-Data or 1.x platform.The platform has been extended three times to accommo-date:• The addit ion of 1.152 Mb/s and 4 Mb/s da ta ra tes• The inclusion of a short-range, low-power option primarily

for use in devices such as mobile phones where battery lifeis paramount

• The addition o f a 16 Mb/s data ra teIt was not enough merely to define a communications plat-

form. In order to promote interoperability between applica-t io n s , i t wa s e s sen t i a l to deve lo p sp ec if i c a t io n s fo r t h eapplication services and the application protocols that support

them. H ence, work has also progressed to d efine application

Figure 1.The I rDA protocol architecture.

Physical

IrLM P LM -IASservicesPlatform Tiny TP services

IrLM P LM-M UX services

IrLLAP services

Appl icat ion and communicat ion services

Networkedappl icat ions

Legacynetw ork stack

Legacycomm apps

"Appliance"appl icat ions

IrLAN IrCOM

IrTRAN-P

IrOBEX Jet Send

IA S

IrLM P

IrLAP

Tiny TP

SIR M IR FIR

IEEE Personal Communications • February 2000



protocols and services that reside abovethe IrD A 1.x platform, most nota bly:• IrCOMM [8], which provides for serial

and pa rallel port emulation over theIrD A platfo rm. This allows legacy com-municat ions applications to operat eunchanged over IrDA and a lso providesfor wireless access to external modems.

The most novel example of the latter isNTT’s deployment of I rD A-enabledintegrated services digital network(ISDN) payphones.

• IrLAN [9], which provides wireless access to IEEE 802 styleLANs.

• IrOBEX [10], which provides for the exchange of simpledat a objects and could be considered the IrD A analog ofHTTP. IrOBEX delivers on the notion of “ squirting” infor-mat ion objects such as business card s, phone lists, calenda rentries, and binary files between devices.

• IrTRAN-P [11]: which provides for the exchange of imagesbetween digital still image cameras, photo printers, and PCs.

• IrMC [12], which defines a profile of relevant I rD A specifi-cations for inclusion in cell phones. Much of this work isbeing leveraged by the Bluetoot h community. IrMC pro-vides for vendor independent interactions with common cellphone feat ures such as phone list synchronizat ion, calendarsynchronization, and wireless modem a ccess. It also pro-vides for third-generation smart phones.

• IrJ etSend [13, 14]: which describes how to bind Hewlett-Packards JetSend protocol for networked appliance interac-tion to the IrD A platform.Figure 1 below summarizes the IrD A-D ata platform and

application services defined to date.The discussion so far has focused on the history of the

standa rds development process. Table 1 below shows keymilestones in terms of the introduction of classes of productsimplementing various mixes of a pplications services.

Ir DA 1.x Pla tform Architectu re

In this section we describe the layered protocol architecture ofthe IrD A-D at a 1.x platf orm, the services provided at its layerboundaries, its connection model, and the information modeland philosophy of its device and service discovery processes.

Figure 1 shows the layering of the IrDA protocol architectureand many of the application services mentioned in the previoussection. The upper boundary of each of the boxes represents aninterface where the services of that layer are abstracted.

The segmented physical layer provides packet transmissionand reception service for individual packets, and the mea ns todetermine when the infrared medium is busy.

The IrLAP layer provides for the discovery of devices with-in r an ge an d th e e s tab l i sh m en t o f re l i ab le c o n n ect io n sbetween devices.

The IrLMP layer provides connection-oriented multiplexingservices with both sequenced and unsequenced delivery prop-erties (LM-MU X services) and t he service information a ccessservice (LM-IAS). LM -MU X provides for multiple logicallyindependent channels between application entities within thecommunicating devices. Note that the absence of per-channelflow control in LM-MUX channels means that t hey may onlysafely be regarded as best-effort delivery channels.

Tiny TP mirrors the LM -MU X services; however, it aug-

ments them with the inclusion of per-connectionflow control. This restores the reliable deliveryproperties for sequenced data. Tiny TP providesa null pass-through for unsequenced da ta whosedelivery properties remain best-effort.

LM -IAS provide s query/response services onan information base that contains essential con-tact information t hat enables prospective serviceusers (clients) to identify and bind to service pro-viders (servers).

These four pro tocol layers, I rP HY , I rLAP ,IrLMP , and Tiny TP, form the core of the I rD Aplatform.

IrDA Connection Model

The IrD A 1.x connection mo del is establishedprimarily by the IrLAP and I rLMP layers. Thereis a 1 :1 correspondence between I rLM P LM-MU X service access points (LSAP s) and Tiny TPservice access po ints (TSAPs). Thus, the Tiny TPlay e r do es n o t c o n t r ibu te to t h e c o n n ect io nmodel, it merely alters the delivery properties ofthe channel from best-effort to reliable.

Within each IrDA device (or station) (Fig. 2),IrLAP services are a ccessed via a single IrLAPservice access point (ISAP ). The a rchitectureallows multiple IrLAP connection endpoints toexist within the ISAP ; however, in practice theIrLAP protocol def ines only single point-to-point

connectivity . There are no known research o r


Figure 2.Service access pointsand connection endpoi nts.

ISAP

Stat ion

IrLAP connect io nendpo in t s

LSAP

LSAP conn ect ionendpo in t s

Connect ionlessLSAP

XID_discoveryservice access point

LM -M UX serviceboundary

IrLAP serviceboundary

LSAP

LSAP conn ect ionendpo in t s

Table 1. Product categroy introductions.

Lat e1994 115.2 kb /s Op t ical Tran sceiver Com pon en t s

Early 1995 115.2 kb /s Personal Laser Prin t ersSerial Port AdaptorsPr inter Adapt ors

M id 1995 115. kb /s Port ab le PCsW i ndows ’ 95Portable Ink Printers

Lat e 1995 4 M b /s Op t ical Transceivers

M id 1996 4 M b /s Port ab le PCs4 M b/s LAN (Eth ernet) A ccess DevicesNokia 9000 Com mu nicatorWindow s CE4 M b/s Personal Laser Printers

Lat e 1997 Dig it al Cam erasMobi le Phones

M id 1998 Palm Co m p t ing Plat f o rm (Palm III)Casual Captu re and Share Inform at ion App l iance

Early 1999 IrDA/Linux Im p lem ent at ionSony PocketStation

Approxim ate Device CategoryIntroduction Date



commercial I rD A sta cks that support point-to-multipointconnectivity. H owever, one commercially available implemen-ta t ion supports mult ip le I rL AP in ter f aces and g ives theimpression of multipoint operation through multiple indepen-dent instances of IrLAP and IrPHY.

Likewise, IrLMP LM-MU X services are a ccessible via mul-tiple LSAPs. Typically, an application entity will bind to anLSAP and, in general, will support multiple IrLMP LM-MUXconnections (or Tiny TP connections). Thus, each LSA P mayconta in mult ip le LM -MU X connect ion endpoin ts . LSAPadd resses are formed by the concatena tion of a n 8-bit LSAP

selector and the device address of the device where the LSAPresides.

Figure 3 illustra tes the I rD A 1.x connection model in thecase of point-to-multipoint connectivity.

IrLAP connections are labeled by the (unordered) pair of32-bit d evice a ddresses of t he devices involved in the connec-tion. Fo llowing connection establishment, a t emporary 7-bitconnection add ress is used in the pa ckets as a n alias for thisconcatena ted device a ddress.

Likewise, IrLMP LM-MUX connections are labeled by the(unordered) pair of LSAP addresses at each end of the LM-MUX connection. A corollary of this is that at most only asingle LM-MU X connection may be established between a nytwo LSAPs.

This connec t ion model is ident ica l to t ha t o f fered by

TC P /IP where, semant ically, IP a ddresses may be substitutedfor I rD A device addresses and TCP /IP port numbers are sub-stituted for IrLMP LSAP selectors.

Device and Service Di scovery IrLAP provides a ba sic device discovery mechanism. Func-tionally, the result of invoking the IrLAP discovery process isa list of records that encode:• D evice Address: A 32-bit semi-permanent device identifier

of the discovered device.• Nickname: A short multilingual name for the discovered

device that ma y be presented in user interfaces to aid inselection.

• Hints: A bit mask giving nonauthoritative hints as to the

services that may be available on the discovered device.

This may be used to order “ deeper” queries into the IAS toauthorita tively establish the presence or a bsence of a partic-ular service.The device discovery process is further a bstracted through

IrLM P by defining procedures for the resolution of conflictingdevice addresses, and “ hiding” such issues from the LM -MU Xuser.

D evice discovery enables entities within one device toestablish the presence of other d evices. H owever, for a systemto be la rgely autoconfiguring and to o perate with minimumunnecessary intervention from the end user, it is essential that

application entities within one device be capable of identifyingand establishing contact with peer entities. These peer entitiesshare a common in ter face (or a pplica t ion pro tocol) tha tenables them to in terac t . Contra s t th is wi th the s itua t ionwhere an end user is faced with the problem of ensuring thatthe right a pplications are bound t o the right serial ports, orthat the correct serial ports are connected together and t heappropriate pin-pin mappings have been installed in the cabledepending on whether the connection is DTE-D CE or D TE-D TE and on part icular idiosyncrasies in the device’s serialport implementation.

LM-IAS defines:• A set of operations that an I AS client may invoke on an

IAS server• The behavior of an IAS server

• An information model for representing the application ser-vices accessible at a given deviceStart ing with the information model, each a pplication ser-

vice is represented by a named IAS object class. The name ofthe object class reflects the name of the service and may beup to 60 octets in length. A hierarchical naming convention isused to avoid name space clashes and to minimize the admin-istrative burden on the IrD A office. It a lso in effect providesopen and equitable access to the class namespace. Thus, class-names that start “ I rDA:” are defined by IrD A, while class-n am es th a t s t a r t “ Hewle t t -Pac k ard : ” a re d e f in ed by th eHewlett-Packard Company, and so forth.

An o b jec t c l a s s a c t s a s a c o n ta in e r fo r a l i s t o fatt ribute/value pairs. Attributes are na med, a nd in general t he

attribute namespace is scoped by the enclosing class. Howev-


Figure 3.Connection model.

LSAP-SEL= Q LSA P-SEL= I LSA P-SEL= JLSAP-SEL= P

LM-MUXlayer

Stat ion Amul t ipo intpr imary

LM-MUXlayer

LM-MUXcl ients LM-MUX

cl ients

LM-MUXlayer

IrLAPlayer

IrLAPLayer

IrLAPlayer

Stat ion Bsecondary

Stat ion Csecondary

LSAP-SEL= X

LM-M UX cl ients

LSAP-SEL= Y

Key

IrLAP-connection

LSAP-connection

IrLAP service

access po int (LSAP)

Link service access

po int (LSAP)

Connect ion endp oint



er, by convention some at tributes are of such global utilitythat they are deemed t o ha ve the same semantics in all scopes.Such attributes carry hierarchically structured names that fol-low the same syntactic conventions as the IAS classname.Thus, IrDA:IrLMP:LsapSel and IrDA:TinyTP:LsapSel are thenames of globally scoped attributes that carry the LSAP selec-tor portion of the ad dress of the entity represented by aninstance of the object. IrDA:IrLMP:InstanceName is a global-

ly scoped att ribute used t o carry a distinguishing name thatmay 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:• Integer: A 32-bit signed integer.• U ser strings: I ntended for presentation via a user interface;

up to 255 octets in length with multilingual support.• Octet sequence: An opaq ue sequence of up to 1024 octets

of information. The attribute may impose further structureon the cont ents of the sequence. This is a go od wa y to clus-ter a body of information under one attribute.IrLMP defines a number of operations for traversing and

retrieving information from a n IAS information base; howev-er, only the G etValueByClass operation is mandatory. A pos-sible C function prototype for the client operation would be:

AttributeValueList

GetValueByClass(ClassName class,

AttributeName attribute);

where the result type, Att ributeList, encapsulates a possiblyempty list of object instance ids and att ribute values fromobjects tha t ma tch given object and at tribute names. Thus, asingle invocation may result in responses for multiple objectinstances, and further attributes, such as instance names, mayneed to be sought in order for an appropriate choice to bemade.

The IrD A platform provides a space for the definition ofnew applications and application services above the platform.In d efining new services it places three obligat ions on the ser-vice designer:

• The definition of an IAS 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 definition of the semantics of the application levelinteraction and the communication stack profile(s) tha tprovides the channel for the interaction

IrDA-Data, 1.x Platform Summary Bef ore moving on to consider some of the a pplication servicesdefined above the IrD A platform, a brief recap of what wehave described so far is whorthwhile.

The IrDA platform provides a connection model identical totha t provided by TCP/IP . The semant ics of the Tiny TP t rans-port service are sufficiently close to those of TCP that in practi-

cal implementations they can be provided through an applicationprogramming interface (API) based on Berkeley sockets.

Naming and a ddressing in IrD A differs from TCP /IP nam-ing and add ressing. Device addresses are fla t and d ynamicallyassigned. While device addresses change infrequently, a uto-mated processes do force change when conflicts arise. Boththe names and addresses of devices are explicitly discovered.Neither are assumed t o be known a priori . Services in theIrD A environment are na med using IAS classnames. Thesenames are d ynamically mapped to I rLM P L SAP s and/or TinyTP TSAP s through I AS q uer ies . This dynamic mappingreduces the ad ministra t ive burden imposed on t he I rD Aoffice. With the limited 7-bit “ port” address space of the LM-MU X, it also removes the problem of orga nizations making

unfair claims on address space real esta te.

D evice discovery and L M-IAS provide the pivotal ea se-of-use features in the platform that enable application entities tolocate a nd establish contact with peer entities which support agiven interaction protocol (i.e., the semantics of the messageset exchanged between a pplication ent ities via the cha nnelestablished through the IrDA platform).

Advanced Inf ra red

The IrD A-D at a 1.x architecture has some obvious limita tions.First, although the architecture can accommodate a point-

to-multipoint mode of operat ion, the IrL AP specification hasnever been extended t o define the prot ocol machinery toenable that functionality. From an end-user point of view it isalso questionable whether such extension of the 1.x platform iseven desirable. Viewed as a single point-to-point link, thebehavior of a n IrLAP connection is largely symmetric, and thedifferences in behavior between an IrLAP primary station andan IrL AP secondary station are largely moot. H owever, theintroduction of point-to-multipoint operation would signifi-cantly disturb this symmetry in ways that would become incon-venient for the end user. Consider a portable computer thatneeds to access both a LAN access point and a desktop print-er. It would be natural for the portable computer to becomethe IrLAP primary and establish IrLAP connections with theLAN a ccess point and t he printer, each of which acts as anIrLAP secondary station. However, it is also reasonable thatthe LAN a ccess point (or the printer for that matter) is capa-ble of “ serving” multiple “ clients,” but in order for it to do thatit would itself have to take on the IrLAP primary role. If theconnection to the L AN access point were esta blished first andthe a ccess point were to cea se the primary role (possiblythrough role reversal), the portable computer would be unableto establish a second IrLAP connection to the printer. If theportable computer reta ined the primary role, it could esta blishthat second connection, but the LAN a ccess point (and theprinter) would be prevented from establishing connections to

other potential “ clients.” What the user could achieve wouldnot only depend on the set of concurrent interactions theywere att empting to initiate, but also on t he order in whichthose interactions were initiated. This would lead to inconsis-tent beha vior which would become frustra ting for end users.Thus, IrDA so far has chosen not to expand the IrLAP defini-tion to encompass point-to-multipoint operation.

Second, within some given field of view, the establishmento f a n I rLAP connect ion between a s ingle pa ir o f devicesinhibits the establishment of connections between other inde-pendent devices whose f ields of view intersect that of t heestablished connection. Thus, use of the med ium becomesdedicated to a single pair of d evices. An important subclass ofgeneral multipoint communication in a shared medium is toenable multiple independent pairs of devices to establish inde-

pendent communication relat ionships. I f t wo devices are inview of each other, it is reasonable that they should be able toestablish communications and share access to the mediumwith other users of the space.

Thus, members of t he IrD A community sought t o extendthe IrD A-D ata architecture to enable true multipoint connec-tivity while a t t he same t ime preserving the investment inupper layer applications and services by ensuring that thesemantics of the service definitions at the upper layers of theplatform are maintained.

It is important to be aware of a few differences betweenthe goals o f the I rD A community and the goa ls o f thosedefining wireless LAN specifications. The IEEE 802 mediumaccess control (M AC) service defines a best-effort ord ered

delivery service with at most once delivery semant ics. It also




assumes a tra nsitive communications relationship. At theMAC layer:

IF A can communicate with BAND B can communicate with CTH EN A can communicate with C .

In t he world of short-range infrared wireless communicationthis is not the ca se. It may even be the case that the communi-cation rela tionship is asymmetric: A may be “ heard” by B, butB cannot be “ heard” by A. With the wired LAN medium thenotion of “ belonging” to a particular LAN segment is stronglyassociated with a physical att achment to t hat segment. Arrivalsand departures, infrequent in most wired ca ses, can be notedby both t he arriving/departing nod e, and potentially the wiredinfrastructure and the other devices attached to that infra-structure. In the wireless case, the bounds of a given LANsegment are less well defined, and arrival and departure aremuch more the norm.

Thus, the primary goals in extending IrD A-D at a ’s connec-tion model were:• To enable devices in view of one another to establish com-

munication relationships uninhibited by the connectionstate of nearby devices.

• To enable an advanced infrared (AIR) device to establishcommunications with a t most o ne IrD A 1.x device. Thisenables AIR devices to interoperate with legacy 1.x devicesin a wa y tha t is wel l unders tood by users o f legacy 1 .xdevices.

• For AI R devices to respect esta blished IrD A 1.x connec-tions with which they could interfere. This is a coexistencerequirement intended to ensure that AI R devices do notdisrupt active IrD A 1.x connectionsFrom an architectural point of view it is relatively simple to

introduce multi-access communication. It requires that IrLAPbe partitioned into a MAC layer (IrMAC ) [14] and a link con-

trol layer (IrLC) [16]. In fact, as illustrated in Fig. 4, the AIR

protocol architecture adds an IrLC pro-tocol ent ity, which provides multipointl ink layer connec t ivi ty a longs ide anIrL AP prot ocol entity , which provideslegacy connectivity to I rD A 1.x devices.The link mana ger (I rLM ) layer [17] is a“ thin” layer t hat multiplexes the use ofI rLAP and I rLC over their respec t ive

physical layers. At t he upper bound ofthe link control layer, IrLC a nd IrLAPprovide identical services to the I rLMPlayer. Thus, within an AIR device, theIrLAP, I rLC, a nd IrLM protocol entitiesmay be regard ed a s a single logical entity,with a single device ad dress which sup-ports an int egrat ed discovery process,and both IrLAP and IrLC connections.The particular use of IrD A 1.x IrLAP orAIR I rLC procedures for es tabl ish ingdevice-to-device connections becomestransparent to IrLMP entities and above.

I rMAC def ines a burst reserva t ioncarrier sense multiple access with colli-sion avoidance (C SMA/CA) M AC pro-tocol. Such MAC protocols rely on theexchange of Request-To-Send, Clear-to-Send MAC protocol data units (PDUs).For such a mechanism to function prop-erly, it is important that the reservationM A C P D U s b e d e c o d e d , no t o n l y b ydevices capable of engaging in commu-nications, but a lso by devices capable of

interfering with communications. In some radio frequency(RF) systems using this style of MAC protocol, the range ofthe reservation messages is extended by boosting the trans-mission power for the related MAC PDUs. AIR makes useof a variable rate (VR) coding technique known as repetition

coding to robustly code the headers of all AIR MAC PDUs.The use of this technique wa s pioneered by IBM R esearchin Zurich [18], and full details are given in the AIR physicallayer specification [19]. R epetitio n coding tra des signal-to-noise rat io (SNR) (range) for tra nsmission rate by repeti-t i o n o f p h y s i c a l l a y e r s y m b o l s . R e p e t i t i o n d e c o d e r s“ average” the repeated symbols received prior to making adecision on what symbol was encoded. In t heory, successivehalving of the data rate by successively doubling the numberof symbol repetitions yields approximately a 19 percentrange increase at each reduction step. Cumulatively , theeffect of a 16-fold ra te reduction (four doublings of the rep-e t i t io n r a t e ) y ie lds a d o u b l ing o f t h e e f f ec t ive r an ge o ftra nsmission. Key fields of the AIR IrM AC [17] P D U s arecoded with 16x repetition.

This VR physical layer delivers two benefits. First, it pro-vides a means of ro bustly coding the media reservat ion mes-sages def ined by the C SMA/CA burs t reserva t ion MACprotocol def ined in the I rMAC spec if ica t ion so tha t theyreach more potential sources of interference.

Second, by actively monitoring the symbol error rates at anAIR decoder, it is possible it estimate the SNR for the chan-nel between the source and sink of a pa cket. This SNR esti-mate can then be used to compute a rate recommendationthat can be fed back to the sending station in order to main-tain a good-quality channel. AIR ’s base r at e is 4 Mb/s, reduc-ing thro ugh successive halving of d at a rat es to 256 kb/s toyield a doubling of ra nge. AIR prototypes have been demon-strat ed tha t ha ve a 4 Mb/s range of 5 m doubling to 10 m at

256 kb/s.


Figure 4. I rDA data advanceIR protocol architecture.

Platform

Appl icat ion and communicat ion services

Legacycomm apps

Networkedappl icat ions

Legacynetwork stack

IrPPP IrLANIrCOM

"Appliance"appl icat ions

IrTRAN-P

IrO BEX Jet sen d

Physical

IrDA1 .x AIR

LAS

SIR FIR VFTRM IR

IrLM P

IrLAP

TTP

LAS

IrLM P

IrLap IrLC

IrDA 1.x VR-PHY

IrLM

I rMAC

TTP



The AIR Connection M odel

Figure 5 il lustra tes the ex tended AIR connec t ion modelregarding the IrLAP , IrLC , and I rLM entities within a stationas single protoco l entity, wit h a single service access point(ISAP), capable of supporting multiple connection endpoints.LSAP addresses, as before, are formed by the concatenation ofan IrLAP /IrLC device address and an I rLMP LM-MU X LSAP

selector. IrLMP LM-MUX connections, as before, are labeledby pairing the LSAP ad dresses from each end of the LM -MU X connection. As before, t here is a 1:1 correspondencebetween Tiny TP connections and LM -MU X connections.

Ir DA Legacy

Commun icati ons Ser vices

Serial port emulation and LAN access were regarded as twoforms of cabled connection that IrD A could replace. Whileserial port communication is acceptable a t link rates of up to115.2 kb/s, LAN a ccess provided one o f t he prima ry mot iva-tions to push the dat a ra te to 4 Mb/s and beyond.

IrCOMM Th ere were two k ey mo t iva to r beh in d th e de f in i t io n o fIrCOMM [8].

First, there wa s the perceived need to provide a serialcable replacement for legacy applications. Thus, traditionalcommunicat ions applications, such a s Kermit, could be usedover an emulated serial port connection. At first glance thismay appear a little odd. However, the IR medium, at least asused by the IrD A, is a half-duplex medium. Da ta can onlyflow in a single direction at a time. The IrD A platform impos-es a media access discipline that shields platform clients fromthe need to be a ware of t he limitations of the medium andabstracts multiple duplex channels. In a ddition, ma ny commu-nications applications make use of flow control and modem

control lines. There is a need to communicate the “ virtual”

s ta te o f t h ese sign a l s in add i t io n to th e c h a rac te r da taexchanged between devices.

Second, there was a need in the telecommunications com-munity to enable infrared access to the telephony network.

IrCOMM provides for both DTE-DTE (null modem) com-munications and D TE-DC E communications. In ad dition,unlike in the wired equivalent of these scenarios, the end useris completely unaware of the difference.

IrC OM M is typically implemented as a serial port driverwhich, rather t han interacting with real serial port hardwa re,implements the IrC OM M protocol to interact with a peerI rCO MM enti ty to trans fer da ta between their respec t iveclients.

IrCOMM supports 3- and 9-wire modes of operation. The9-wire case includes modem control lines. The relative timingof modem control line state changes can be maintained to thelevel of the boundaries between chara cters.

Applications running over IrCO MM do not benefit fromall the ea se-of-use feat ures the IrD A platf orm provides. Thisoccurs because of the very nature of serial communications.

The open/close operat ions in most serial AP Is a re a boutlocal resource allocation, t ypically a loca l serial port resource.They are not a bout (physical) connection establishment.

Indeed, it becomes obvious after a few moments that serialAPIs cannot be expected to provide for physical connectionestablishment. That is something tha t the user does... with acable! Therefore, there is no way a t the serial port AP I levelfor a n application t o express anything through the API aboutthe nature or identity of the remote peer with which it wishesto establish communication.

In the same way as it is possible for an application to opena real serial port when there is no cable plugged into it, it ispossible for a n application t o open an IrCO MM virtual serialport when there is no device in the vicinity with which to com-municate. O nce opened, an IrCO MM virtual serial port willactively seek out peer ent ities with which to communicat e.Typically, instances of IrCOMM will renew efforts to find a

peer as applications continue to “ pump” data into the “ virtu-


Figure 5. I rDA-data AI connection model.

LM-M UX cl ients

LM -MUX layer

Stat ion CIrDA1 .x secondary

LM-M UX layer

IrLAPlayer

LM -MUX cl ients

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 ients

LM-M UX cl ients

LM-M UX layer

LM-MUX layer

Stat ion BIrDA-AIR

Stat ion DIrDA-AIR

IrLAP-connection

LSAP-connection

Service access poi nt (SAP)

Connect ion p oint

Stat ion AIrDA-AIR(also acts as IRDA 1 .x prim ary)



a l” serial port. The presence of buffered data may stimulateperiodic discovery processes. Semantically, data pumped intoa disconnected serial port can be lost.

As with real serial ports, the end user needs to explicitlycontrol which applications are bo und to t he virtual serial port.It is possible for a given device to support multiple virtualserial ports. However, a device encountering another devicewith multiple virtual serial port s 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 portshas been rubbed out, and where the mapping between operat-ing-system-specific logica l device na mes (/dev/tt y0, CO M 1,etc.) and physical ports is unknown.

This is an ugly problem for real serial communications andremains an ease-of-use challenge for legacy applications in theworld of short-range wireless communications.

Nevertheless, IrCO MM has found widespread applicationin mobile phones, and there has been significant deploymentin ISD N payphones in the Tokyo area . Such deploymentallows relatively trouble-free dialup access to the internet.

IrLAN IrLAN [9] adopts a similar philosophy to IrCOMM in orderto support legacy networking applications.

Typically, Ir LAN o perates in “ access-point” mode wherethe combination of the IrLAN protocol operating over theIrDA stack to an IrLAN LAN access point is equivalent to aregular LAN card a nd provides 802 LAN M AC service. Justas IrCOMM is typically implemented as a serial port driver,IrLAN is typically implemented as a LAN card driver.

IrLAN can operate in a peer-to-peer mode that effectivelymodels a stub-LAN with just two d evices att ached. Lega cynetworking protocols such as classic NetBios can establish adhoc network communicat ions file and print sharing in such anenvironment.

However, peer-to-peer IrLAN operation is of little use formost TCP /IP implementat ions since it fa ils to provide the infra -

structure such as D HC P for autoconfiguration, Domain NameService (DNS) for name-address resolution, or any of the otherinfrastructure services whose existence is generally assumed byapplications programmed for the TCP environment.

IrLAN has proved controversial. Its sustained deploymentin operating systems is in question and is likely to be superced-ed by a model based on Point-to-Point Protocol (PPP) whichleverages superior a ccess controls, aut oconfigurat ion, encryp-tion, and hea der compression facilities from PP P.

Ir DA Appl icati on Ser vices

IrOBEX I rOB EX [10] seeks to be regarded as the H TTP of I rD A.Like HTTP, it precedes the transfer of some data object with

a set of headers that carry meta-data about the object such asi ts name, size , and type . I rOB EX supports bo th P U T andG ET operations.

Currently, the dominant use of IrO BE X is for the transferof file-like o bjects such a s document files, electronic businesscards (vCa rds), and appointments (vCa lendar). Content typingand naming conventions can be used to launch applicationsappropriated for the content type being transferred. HTTP isused typically using a PULL model, whereas the dominantusage model for IrOBE X is a P U SH model. A user “ squirts”information from one device to another. The premier exampleis that o f the exchange of business cards betw een P D As. Theauthor has also used a commercially available IrOBEX imple-mentation to transfer the a ccumulated 2 G bytes of files built

up on one “ congested ” por tab le PC to i ts successor one

evening in the living room. That single instance of use alonecould, for many, justify the $3–5 cost t he inclusion of I rD Aadds to a portable PC.

I rO B E X i s de f in ing seman t ic s f o r seq u en c es o f P U Tand /or G E T opera tions to a chieve such objectives as ad dressbo o k an d d i a ry sy n ch ro n iza t io n be tween p h o n es, sm ar tphones, PDAs, portable PCs, and pagers.

IrTRAN-P IrTRAN-P [11] is an image transfer protocol defined by mem-bers of IrDA for the exchange of images between digital cam-eras, PCs, PDAs, and photo-printers.

IrTR AN-P cameras can be used in conjunction with PD As,mobile phones, and smart phones to accomplish such things asgathering data, and e-mailing or faxing it back to the office. Amore soc ia l var ia t ion o f t h is no t ion might be d ubbed the“ Instant P ostcard.”

IrTR AN-P saw widespread deployment in digital camera sin the Asian ma rketplace prior to t he 1998 Naga no WinterOlympics. These camer as ha ve been used in conjunction w iththe previously mentioned ISD N 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 tha tthey can be shared more widely.

IrJetSend JetSend [14] is an open appliance interaction protocol definedby H ewlett-Pa ckard. JetSend-based appliance interactionsembody the strong principle that the participating appliancesdo not model each other. J etSend devices share a mod el ofthe structure of information, e-material, and can engage inmultilevel negotiat ion over the encoding used to exchangeinformation. A mandatory encoding exist for ALL definedcontent types , ensur ing a base level o f in teroperabi l i tybetween JetSend appliances. JetSend also provides a controlpro tocol such tha t a ppliances may render U I a r t i fac ts onbehalf of appliances with which they are connected.

U nderlying all JetSend intera ctions is an object interactionmodel ba sed on surface intera ction. This is an unconventionalobjec t model . Consis tency o f object s ta t e is main ta inedthrough the application o f internal rules. Some portion of anobject ’s state is exposed at its surface. The surfaces of con-nected objects are impressed on one another (simple equiva-lence between connected surface artifacts). Dynamic behaviorarises from disturbance of stat e and the application of theinternal rules until the overall state becomes stable or cyclic.

Interaction policies enable interactions to be structured torepresent the transfer of a document, or the dynamic status ofa d evice to be monitored.

JetSend was originally deployed in imaging and hardcopydevices connected to the Int ernet. More recently, a mea ns ofbinding JetSend to the IrD A platform ha s been defined [13].

A number of commercial devices exist that both source andsink JetSend eMaterial over the IrDA platform.

I rDA Futu res

IrD A has grown up late in the era of the PC and at the startof the information appliance age. Today it is exciting to see itsad option in such diverse devices as mobile phones, P D As,pagers, digital cameras, portable scanners, access points, andprinters. It is exciting to consider the device and service inter-action possibilities that a pervasive short-range communica-tion technology enables. The range o f device categories tha tembed the I rD A communication pla tform is expanding. Themeans by which such devices can ga in access to infra structure

over an initial short-range hop is expanding. This leads to an



http://slidepdf.com/reader/full/irda-past-present-and-future 9/919IEEE Personal Communications • February 2000

explosion in the pot ential for devices to interact with oneanother, either in the immediate vicinity or remotely acrossinfrastructure. It leads to an explosion in the potential fordevices to intera ct with ent ities and services embedded wit hinthe infrastructure.

However, with all this potential there is massive challenge.D o 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 thatenable the functions of a collection of single-function devicesand infrastructure-based services to be composed to achievesome larger end-user goal which we might regard as a dynam-ically composed application? C an we do this in ways that areintuitive for end users, where the outcome of an interactionneeds to be both predictable and useful? If I send a n electron-ic business card from an organizer to a mobile phone, what isthe mobile phone expected to do? It could dia l the number onthe card , “ file ” i t awa y in its add ress book, fa x it to someremote recipient, a nd in the not too distant future it might e-mail it somewhere else. What is that same phone expected todo with a photograph sent from a digital camera? B oth ofthese interact ions are possible with off-the-shelf IrD A-enabledproducts today.

The informa tion exchanged between d evices need not bestatic, either. Financial tra nsactions between electronic walletsare being accomplished over I rD A [20]. The a dvent of virtualmachine environment s and mobile objects such as J ava /R MIand distributed computing fra meworks such as J ini providethe opportunity to a pply these technologies in an I rD A envi-ronment. This leads to the possibility of exchanging a ctiveobjects, perhaps representing goal-driven agents, bet weendevices 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 abstractionsto t he IrD A environment. They become of much broader ut il-ity, and anot her significant challenge will be to deliver thesecapabilities through upper-layer application services in consis-

tent ways across a range of lower-layer short-range wirelesstechnologies.

In I rD A AIR is in the f ina l s tages o f be ing adopted . I toffers to improve the freedom of movement available to IrDAdevices that adopt the technology. They will be freed from therestrict ive 1 m,15–30 degree ha lf-angle coverage profile ofI rD A 1.x, and enabled to o pera te over grea ter range andwider angle. J ust as with R F wireless technologies, this willpresent new user interface challenges too, since, in general,the target of a given interaction can no longer be resolvedmerely by pointing.

IrDA offers a flexible, globally pervasive short-range wire-less communications platform for appliance builders. I tswidespread a doption In d evices to da te great ly reduces therisks associated wit h embedding it in new device categories.

Its range of application will continue to grow well into thenew millennium.

Acknowledgments The author would like to thank the I rD A president, M ikeWatson of Calibre-Inc., and Parviz Kermani of IBM Research,as well as the Hewlett-Pa ckard Compa ny for their support,encouragement, a nd review of t his article.

References [1] P. D. Brown , L. S. M oor e, and D. C. York, “ Low Pow er Optical Transceiv-

e r f o r Po r t a b l e C o m p u t i n g D e v ic e s, ” U . S. Pa t e n t N o . 5 , 0 7 5 , 7 9 2 ,Assignee: Hewlet t-Packard Com pan y, Dec. 24, 1991.

[2] T . F . Wi l l iams, P. D. Hortens ius , and F. Novak, “ Proposa l f o r : I n f ra redData Associat ion Serial Infrared Link Protocol Specif icat ion, ” v. 1.0, IBMCorp. , Aug. 27, 1993 .

[3] ISO, “ High Level Data Link Control (HDLC) Procedures - Elements of Pro-cedures,” ISO/IEC 4335, Sept. 1 5, 19 91.

[4] I rDA, “ Serial Infrared Link Access Protocol (IrLAP),” v. 1.1, June 1996.[5] I rDA, “ Link M anagement Protocol ,” v. 1.1, Jan. 1996.[ 6 ] I r D A , “ Ser ia l I n f r a red Phys ica l Layer L ink Spec i f i ca t i on , ” v . 1 . 3 , Oc t .

1998 .[7] I rDA, “ T inyTP: A F low-Cont ro l M echan ism f o r Use w i t h I rLMP,” v . 1.1,

Oct . 1996.[8] I rDA, “ I rCOM M : Serial and Parallel Port Emulat ion o ver IR (Wire Replace-

ment ) ,” v . 1.0, Nov. 1995.[9] I rDA, “ LAN Access Extens ions for L ink M anagem ent Proto col I rLAN, ” v .1.0, July 1997.

[10] IrDA, “ Object Exchange Protocol,” v. 0.1a, Jan. 4, 1995.[ 11 ] I rDA, “ I rTran-P ( Inf rared Transfer Pic ture) Spec i f icat ion,” v . 1.0, Oct .

1997 .[ 12 ] I rDA, “ Spec i f i ca t i on s f o r I r Mo b i l e Com mu nica t ion s ( I rMC) ,” v . 1 . 1 ,

M ar . 1999 .[ 13 ] I rDA, “ Je t Send( t m ) Pro t o co l on I rDA Ap p l i ca t i on Not e ,” v . 1.0, Sept .

1998.[ 14 ] Hew le t t -Packard , “ HP Je t Send Comm unica t ions Techno logy Pro t oco l

Specif icat ion,” v. 1.0, July 1997[ 15 ] I BM Corp . , “ Advanced I n f ra red (A I r ) MAC Speci f i ca t i on , ” v . 0.3, Jan.

199 9; available at I rDA M emb ers FTP Site.[ 16 ] I BM Corp . , “ Advanced Inf rared Logical L ink Cont rol (Ai rLC) Spec i f ica-

t i on ,” v. 0.1, Jan. 199 9; available at I rDA M emb ers FTP Site.[17] IBM Corp. , “ Advanced I r L ink Manag er. (Ai rLM) Spec i f icat ion ,” v . 0.3,

June 1 999 ; available at I rDA M emb ers FTP site.[ 18 ] F. Gf e l l e r e t a l . , “ Wire less I n f ra red T ransm ission : How t o Reach A l l

Off ice Space,” Proc. VTC ’96 , vol . 3 pp. 153 5 –9.[ 19 ] I rDA, “ I rDA Ad vanced I n f ra red Phys ica l Layer Spec i f i ca t i on , ” v . 1 . 0 ,

Sept . 1998 .[20] Conf in i ty Inc ., ht tp : //ww w.paypal .com

Biography STUART W ILLIAMS (skw @h plb .hpl .h p.com ) received Bachelor of Science andPh.D. degrees in electrical and electronic engineering from the University ofBa t h , Un i t ed K ingd om in 1981 and 1986 . He i s a t echn ical con t r i bu t o r a tHewlet t -Packard Laborator ies , Br isto l , England. Betw een 1994 and 1 998 h ew a s r e sp o n s ib l e f o r m a n a g i n g a r e s ea r c h t e a m f o c u se d o n t h e u s e o ff reespace in f ra red f o r shor t - rang e w i re less da t a comm un ica t ions . Dur ingt h i s per iod he made numerous t echn ica l con t r i bu t i ons t o t he work o f t heI n f ra red Dat a Assoc ia t i on ( I rDA) and has served as co-cha i r o f t he I rDATechnical Commit tee. Pr ior to jo in ing Hewlet t -Packard in 1992, he workedf o r s e v e n y e a r s o n L A N a n d r o u t i n g t e c h n o l o g i e s a t B r i t i s h Te l e c o m ’ sM art lesham Heath Laborator ies.

Documents

IrDA: Past, Present and Future