`
`
`
`Abstract
`The core Tnterllet technologies were in the hands of' the research community it) or more years before the World Wide Web happened and popu—
`larized the Internet as a place to find information, access service, and trade, The Infrared Data Association has been in existence for over six
`years. Products embedding the cmumunication technology irDA defines have been around for over five years, starting with printers and portable
`PCs. IrDA is cheap to embed, rises unregulated spectrum, and is increasingly pervasive in a wide range of devices. li'rom its tools in portable l‘Cs
`and printers, IrDA technology is present in virtually all new l’DAs, 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 IrDA is playing a significant role in enabling the interaction between
`information appliances, between information appliances and the information infrastructure, and between appliances conltliunicating across the
`information infrastructure. This article discusses lr])A’s communications model. It charts the evolution of the lI'DAilhta (1.x) platform 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 erA platform. ll broadens its horizons to consider other emerging appliances technologies and to consider communications
`models that might arise from a blend of erA short—range wireless communicatkms and mobile object technologies. li‘inally, it briefly considers
`future directions for the Trl)/\ platform itself.
`
`er/l: Past, Present and Future
`
`
`
`STUART WILLIAMS, HP LABORATORIES
`
`
`
`([rl)A) was formed in June I993 and has worked steadily to
`establish specifications for a low-cost, interoperable, and easy—
`to—use wireless communications technology. Today, the
`infrared data cmnmunication technologies defined by the
`IrDA ship in over 40 million new devices each year ranging
`from personal computers, personal digital assistants (l’DAs),
`digital cameras, mobile phones, pagers, portable information
`gathering appliances, and printers.
`[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
`Internet platform technologies existed for a full 10 years prior
`to the explosive growth brought about by the intrmluction of
`the Web.
`IrlJA is a communication technology for the appliance era.
`’l‘his is an era that, while not excluding the PC, liberates
`devices that have long been viewed as peripherals. It enables
`them to engage in useful interactions with each other without
`having to mediate their communications through some com—
`mon control point.
`ind users have remarkably high expectations ofwirclcss
`communications In the wired world there is general accep—
`tance of the mechanical constraints imposed by the various
`plugs and sockets that, at least in part, avoid mismatched con—
`nections. There is acceptance of the cognitive toad required to
`sort out the connectivity and clutter of cabling at the rear of a
`hi~fi setup or the back of a PC. llowcvcr, in the wireless
`world, there is an expectation that communications and cou~
`nectivity will just work, and work simply. In the wired world
`short-range connectivity between devices is established by
`explicit actions on the part of the end user. In the wireless
`world there is an expectation that connectivity between
`devices will be established as required without explic‘it inter—
`vention by the end user. The expectation is that if the user
`attempts to print, the “system” will seek out and establish
`corrnectivity to a nearby printer.
`The author regularly finds it remarkable that he can use
`the satire infrared port to:
`' Simply “squirt” files between devices
`
`' Connect to the local LAN
`' Dial in from a portable i‘(_) or I’DA via an MBA-enabled
`cell phone
`' l’rint to an lrl)A-cnabled 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 Irt)/\ has sought to go far beyond mere cable
`replacement, and provide a connnunications platform and
`application services fit for the era of information appliances
`and which excel in the area of case of use.
`
`A Brief History of er/l—l'Mta
`'l'hc lrl)/\ was formed in .lune |‘)93 to develop an interopera-
`ble, low—cost and casytoaise, short~rangc, infrared, wireless
`communications technology. The inaugural meeting was
`attended by 70+ companies which recognized the consider—
`able value of defining a single family of specifications for [he
`comnnmication of data over infrared.
`Prior to June 1993, a number of noninteroperalde single-
`vcndor 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 proprietary schemes, all of which would
`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 connectivity technology represented a void. Without a
`dominant technology, the risk of choosing the wrong propri»
`ctary 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 erA.
`The original requirements can be summarized as:
`' Marginal cost to add infrared to a product , under $5
`' Data rates of up to l 15 kb/s
`. Range from contact (fl In) through at least I m
`- Angular coverage defined by a |5—3tl degree half—angle cone
`By the end of September, erA had selected one of 3 pro—
`posed approaches for defining its physical layer | 1] defined by
`
`[But Personal Conununications - February Ztltltt
`
`imagine/oursuroa (ID Ziltltl [FF]?
`
`[1
`
`1
`
`Exhibit 1040
`Apple, et al. v. Uniloc
`|PR2019—00251
`
`1
`
`Exhibit 1040
`Apple, et al. v. Uniloc
`IPR2019-00251
`
`

`

`
`
`
`
`
`
`
`’Av' .iiarcs’l'.
`.
`Legacy
`
`
`
`comm apps
`._ applications -_
`_ "
`
`
`
`Application and communication services
`
`
`
`
`
`
`Platform
`
`IrLMP LM—lAS
`services
`
`.
`Tiny TP serwces
`
`IrLMP LM-MUX services
`
`lrLLAP services
`
`lliritIIII
`IIIII
`III
`III
` emergence of numerous PDAs,
`IIII:
`
`
`
`
`
`i
`
`inally the union of two overlapping
`1 m cones, each with a 15~30
`degree half-angle.
`It soon became apparent that
`the definition of lrl.Al’ would not
`be sufficient to meet IrDA’s ease"
`of—usc goals. Certainly, “LAP
`would provide a reliable connec-
`tiorr oriented communication ser~
`vice between two devices, but it
`provided no means to identify
`prospective clients of the lrLAP
`communication services. The year
`1993 was a “hot” period with the
`
`I
`
`
`
`notebook, and sub-notebook PCs. it
`was apparent that a model which
`turned over the infrared communi-
`cation facilities to a single applica-
`tion would be inadequate. The
`emerging multithreaded consumer
`computing platforms required a
`multiplexing communications model
`that enabled several applications to
`share access to the infrared commu-
`nications resources within a device.
`[11 this way, multiple applications
`could passively listen for appropri-
`ate peer application entities to con-
`nect. Thus, in December 1993 the
`activity to define the Infrared Link
`Management Protocol (lrl.MP) [5] was born.
`lrLMl‘ provides a connection—oriented multiplexer, LM—
`MU X, and a lockup service, LM—IAS, that enables multiple
`lrLMP clients to claim a “port” above the multiplexer and
`advertise their availability by placing critical contact infor-
`mation into the lookup service. The namcspacc for the
`lookup service is designed to he self—administering in order
`to avoid the bureaucracy of maintaining administrative
`records about namespace registrations and to ensure “fair
`access” to make use of the namcspacc.
`By June 1994, just 12 months after the inaugural erA
`meeting, version 1.0 of the core erA platform specifications,
`erl—lY, IrLAP, and lrIMP, was released [4—6].
`Work continued to define a per—connection flow control
`scheme to operate within lrLMP connections. When multi-
`plexing above a reliable connection, unless there is a means of
`independent flow control for each derived channel, the deliv—
`ery property of the derived channel is reduced to “best-
`effort.” Per—channel flow control restores a “reliable” delivery
`property. This work led to the definition of the Tiny Trans—
`port Protocol (Tiny 'l‘P or 'l'TP) [7].
`erHY, lrLAl’, erVlP, and TinyTP are the currently
`accepted specifications that define the core of the [rDA plat-
`form, often rel’errcd to as the lrl)A~T)ata or 1.x platform.
`The platform has been extended three times to accommo—
`date:
`- The addition of 1.152 Mh/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 In MD/‘s data rate
`it was not enough merely to define a communications plat-
`form. in order to promote interoperability between applica—
`tions, it was essential to develop specifications for the
`application services and the application protocols that support
`them. Hence, work has also progressed to define application
`
`Physical
`
`
`I Figure 1. The IrDA protocol architecture.
`
`Hewlett-Packard. All three approaches assumed the presence
`of a UAR’l‘ that could he used to modulate the infrared trans-
`missions. The silicon cost of UART devices was well antler-
`stood, and in many cases the system design of many products
`included redundant UAR'l‘s; thus, the marginal cost of adding
`[IDA could amount to just the components of the infrared
`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 shall see later, the question of which cable
`remained.
`The natural abstraction of a half-duplex, asynchronous
`character—oriented transmission was too poor an abstraction
`for building interactions that were selllorganizing and easy to
`use. In addition, there were frequent discussions of how to
`select data rate, how media access control was to function,
`and how, in the context of a 115 kb/s link, reasonably efficient
`use could be made of the available bandwidth.
`
`By November 1903 II‘DA had settled on a tokcnrpassing
`approach, originated by 13M [2] and derived from high-
`level data link control (HDLC) [3! operating in normal
`response lnodc (NRM). As with other proposals, this was a
`packeiized scheme. ilowevcr, in contrast to contention—
`hascd schemes that were also considered, the HDLC-SIR
`(later renamed Infrared Link Access Protocol, lrLAt’ [3])
`approach yielded contention—free access to the medium
`once initial communication had been established. Irl.AP
`defines a fixed-rate slotted contention-mode device discov-
`ery scheme that enables initial contact to be established.
`Critical communication parameters such as connection data
`rate, maximum packet sizes, and certain minimum and max-
`imum gap timings are negotiated during connection estab—
`lishment. Following lrLAl’ connection establishment, the
`two devices engaged in communication are deemed to
`“own” the Spatial region which they both illuminate # nom—
`
`12.
`
`IEEE Personal Communications - February 2001]
`
`2
`
`

`

`LSAP connection
`LSAtJ connection Connectionless XlDrdiscovery
`endpoints
`endpoints
`LSN‘
`sconce access point
`t
`t
`.
`,
`1," . ‘7} " i.’ "'5 °
`LSAP
`LSAP
`
`'
`
`Noumea;
`boundary
`
`lrLAP connection
`endpoints
`~. to T7"
`IrLAP service
`,x’iSAP
`boundary
`
`Station
`
`figure 2. Service access pointsmid connection endpoints.
`
`irD/l 1.x Platform Architecture
`
`[ lI
`
`protocols and services that reside above
`the erA 1.x platform, most notably:
`' II'COMM |8], which provides for serial
`and parallel port emulation over the
`
`erA platform.This allowslegacyeom-
`
`nmnieations applications to operate
`unchanged over erA and also provides
`for wireless access to external modems.
`Tire most novcl example of the latter is
`N'I'T’s deployment of lr])/\-enab|ed
`integrated services digital netWork
`(lSDN) paypliones.
`0 IrLAN [91, which provides wireless access to IliliL“ 802 style
`LANs.
`- IrOBEX l, [0], which provides for the exchange of simple
`data objects and could be considered the erA analog of
`HTTP. erBEX delivers on the notion of “squirting” infor—
`mation objects such as business cards, phone lists, calendar
`entries, and binary files between devices.
`- Ir’l‘RAN-l’ [l l]: which provides for the exchange of images
`betwoen digital still image cameras, photo printers, and PCs.
`- IrMC [12], which defines a profile of relevant IrDA specifi-
`cations for inclusion in cell phones. Much of this Work is
`being leveraged by the Bluetooth community. irMC pro-
`vides for vendor independent interactions with common cell
`phone features such as phone list synchronization, calendar
`synchronization, and wireless modem access. it also pro-
`vides for third—generation smart phones.
`- IrJetSentl [13, 14]: which describes how to bind llewictt-
`Paekards .letSend protocol for networked appliance interac~
`tion to the MM. platform.
`Figure l below summarizes the RDA—Data platform and
`application services defined to date.
`The discussion so far has focused on the history of the
`standards development process. Table 1 below shows key
`milestones in terms of the introduction of classes of products
`implementing various mixes of applications services.
`
`Approximate _
`. Introduction Date
`
`Device Category
`
`In this section we describe the layered protocol architecture of
`the erA-Data l.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 I shows the layering of the II'I)A protocol architecture
`and many of the application services mentioned in the previous
`section. The upper boundary of each of the boxes represents air
`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 lrLAl’ layer provides for the discovery of devices with—
`in range and the establishment of reliable connections
`between devices.
`The lrLMl‘ layer provides connection-orientcd multiplexing
`services with both sequenced and unsequenced delivery prop—
`erties (LMwMUX services) and the service infm'mation access
`service (l.M~l/\S). LM—MUX provides for multiple logically
`independent channels bcthen 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.
`Tiny '|.'|’ mirrors the l.M-MUX services; however, it aug
`ments them with the inclusion of perueonnection
`flow control. This restores the reliable delivery
`properties for sequenced data. Tiny 'l‘l’ provides
`a null pass-through for unsequcnced data whose
`delivery properties remain best—effort.
`LM-JAS provides query/response services on
`an information base that contains essential con—
`tact ini'ornratitm that enables prospective service
`users (clients) to identify and bind to service pro-
`viders (servers).
`'l‘hese four protocol layers, IrPHY, lrLAl’,
`it'llMl’, and Tiny 'l‘l’, form the core of the ir'])/\
`platform.
`erfl Comicclion Model
`The IrDA 1.x connection model is established
`primarily by the lrl .AP and Irl.MP layers. There
`is a l:l correspondence between lrl.Ml’ LM—
`MUX service access points (LS/\l’s) and ’l‘iny 11‘
`
`service access points (’l‘SAl’s). Thus, the Tiny 'l'P layer does not contribute to the connection
`
`
`
`
`
`
`2i
`' 4
`
`b.
`
`r. snares
`_LA (Eth' at
`
`model, it merely alters the delivery properties of
`the channel from best—effort to reliable.
`
`Within each Irl)/\ device (or station) (Fig. 2),
`Partri-
`)f-
`lrLAP services are accessed via a single lrlAl’
` allows multiple lrl./\P connection endpoints to
`
`
`' nformatron 'pp once; if 'I I
`service access point (lSAl’). The architecture
`
`
`exist within the lSAl’; however, in practice the
`Irl .Al’ protocol defines only single point~to~point
`connectivity. There are no known research or
`
`IEFF. Personal (Ionnnnnicaiions ' February 2am
`
`13
`
`3
`
`

`

`
`
`Station A
`multipoint
`primary
`
`Key
`
`i——-y irLAP—connection
`LSAP-SEL:
`LiVl-MUX
`
`1-~w-—4> LSAP-connection
`
`m lrLAP service
`access point (LSAP)
`
`
`
`
`
`
`
`
`
`
`Station B
`secondary
`
`
`
`Link service access
`point (LSAP)
`
`Connection endpoint
`
`0
`
`r-"'“ . .......
`
`‘~\LSAP—SEL=|
`LM-MUX
`,.
`
`unnclients
`
`.1
`
`I Figure 3. Connection model.
`
`This may be used to order “deeper” queries into the IAS to
`authoritatively establish the presence or absence of a partic—
`ular service.
`The device discovery process is further abstracted through
`lrliMP by defining procedures for the resolution oi? conflicting
`device addresses, and “hiding” such issues from the LM-MUX
`user.
`
`commercial TrDA stacks that support point—tormultipoint
`connectivity. However, one commercially available implemen—
`tation supports multiple [rLAP interfaces and gives the
`impression of multipoint operation through multiple indepen-
`dent instances of IrLAP and lrl’l-IY.
`Likewise, Irl,M1J LM-MUX services are accessible via mul—
`tiple LSAI’s, Typically, an application entity will bind to an
`iSAP and, in general, will support innltiple II‘LMP LMlMUX
`connections (or ’l‘iny TP connections). Thus, each LSAl‘ may
`contain multiple l.M-MUX connection endpoints. LSAP
`addresses are formed by the concatenation of an 8—bit LSAl‘
`selector and the device address of the device where the LSAP
`resides.
`Figure 3 illustrates the erA 'l ,X connection model in the
`case of point-to-multipoint connectivity.
`lrLAP connections are labeled by the (unordered) pair oi"
`32nbit device addresses of the devices involved in the cornice-
`tion. Following connection establishment, a temporary 7—bit
`connection address is used in the packets as an alias for this
`concatenated device address.
`Likewise, lrLMi’ llM-MUX connections are labeled by the
`(unordered) pair of LSA ’ addresses at each end of the LM—
`MUX connection. A corollary of this is that at most only a
`single LMsMUX connection may be established between any
`two LEAFS.
`This connection model is identical to that offered by
`TCP/Il’ where, semantically, IP addresses may be substituted
`for erA device addresses and 'l‘CP/ll’ port numbers are sub—
`stituted for lrtMl.’ LSAP selectors.
`
`Device discovery enables entities within one device to
`establish the presence of other devices. However, for a system
`to be largely autoconfiguring and to operate with minimum
`unnecessary intervention from the end riser, it is essential that
`application entities within one device be capable of identil’ying
`and establishing centact with peer entities. These peer entities
`share a common interface (or application protocol) that
`enables them to interact. Contrast this with the situation
`where an end user is faced with the problem of ensuring that
`the right applications are bound to the right serial ports, or
`that the correct serial ports are connected together and the
`appropriate pin—pin mappings have been installed in the cable
`depending on whether the connection is UTE-DC]? or UTIL-
`l)’l'l3 and on particular idiosyncrasies in the device’s serial
`port implementation.
`lM—lAS defines:
`- A set of operations that an IAS client may invoke on an
`lAS server
`- The behavior of an [AS server
`- An information model for representing the appiication ser-
`vices accessible at a given device
`Starting with the informatirm model, each application ser»
`vice is represented by a named [AS object class. Tire name of
`Device and Service Discovery
`the object class reflects the name of the service and may be
`li‘unc-
`lrLAl’ provides a basic device discovery mechanism.
`up to (if) octets in length. A hierarchical naming convention is
`used to avoid name space clashes and to minimize the admin—
`tionally, the result of invoking the 1rL/\P discovery process is
`a list of records that encode:
`istrative burden on the lrl)/\ office. it also in effect provides
`open anti equitable access to the class namespacc. Thus, class—
`° Device Address: A 32—bit semi—permanent device identifier
`
`of the discovered device.
`names that start “erA:” are defined by erA, while ct: ‘s—
`names that start “Hewlett-Packardz” are defined by the
`- Nickname: A short multilingual name for the discovered
`Hewlett-Packard Company, and so forth.
`'
`device that may be presented in user interfaces to aid in
`selection.
`list of
`An object class acts as a container for a
`attribute/value pairs. Attributes are named, and in general the
`' Hints: A bit mask giving nonauthoritativc hints as to the
`services that may be available on the discovered device.
`attribute namespace is scoped by the enclosing class. Howev—
`
`
`l4
`
`lljl‘lli Personal Communications ' I-‘ebruary 200i)
`
`4
`
`

`

`er, by convention some attributes are of such global utility
`that they are deemed to have the Same semantics in all scopes.
`Such attributes carry hierarchically structured names that fol?
`low the same syntactic conventions as the IAS classnanic.
`Thus, lrl)A:lrl.Ml‘:lsapSel and li'l)A:Tiiiy'l‘P:l rsapScl are the
`names of globally scoped attributes that carry the LSAI’ selecv
`tor portion of the address of the entity represented by an
`instance of the object. lrl')A:lr[.Ml’dnstanceName is a global—
`ly seoped attribute tised to carry a distinguishing mime 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:
`' Integer: A 32—bit signed integer.
`' User strings: Intended for presentation Via a user interface;
`up to 255 octets in length with multilingual support,
`- ()ctct sequence: An opaque sequence of up to lfl24 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.
`li'LMl‘ defines a number of operations for traversing and
`retrieving information from an [AS information base; howev—
`er, only the GetValueByClass operation is mandatory A pos—
`sible C function prototype for the client operation would be:
`AttLIibuteVaiucttist
`GoliValuelEyCiass (ClassNauie cl ass,
`At;t;ributeNarno attribute) ,-
`Whei‘e the result type, AttributeList, encapsulates a possibly
`empty list of object instance ids and attribute values from
`objects that match given object and attribute names. Thus, a
`single invocation may result in responses for multiple object
`instances, and further attributes, such as iiistauee names, may
`need to be sought in order for an appropriate choice to be
`made.
`The lrl)A platform provides a space for the definition of
`new applications and application services above the platform.
`In defining new services it places three obligations on the scr~
`vice designer:
`° The definition of an lAS object class
`° The definition of a hints mask that indicates the strong like~
`liliood that an instance of that service exists on the discov»
`cred device
`- The definition of the semantics of the application level
`interaction and the communication stack profile(s) that
`provides the channel for the interaction
`
`f.X Platform Sumiiiaiy
`it‘lJ/iDtiltt,
`Before moving on to consider some of the application services
`defined above the erA platform, a brief recap of what we
`have described so far is whorthwhilc.
`The lrl)/\ platform provides a connection model identical to
`that provided by 'l'Cl’ill’. The semantics of the Tiny 'l'l’ trans—
`port scrvicc are snffieieiitly close to those of 'l‘Cl’ that in practi—
`cal implenientations they can be provided through an application
`programming interface (API) based on Berkeley sockets.
`Naming and addressing in ”DA differs from TCP/II‘ nam-
`ing and addressing. Device addresses are flat and dynamically
`assigned. While device addresses change infrequently, auto—
`mated processes do force change when conflicts arise. Both
`the names and addresses of devices are explicitly discovered.
`Neither are assumed to be known a priori. Services in the
`[rl)/\ environment are named rising IAS classnanies. These
`names are dynamically mapped to lrl .Ml’ LSAPs and/or Tiny
`'l‘P TSAl‘s through [AS queries. This dynamic mapping
`reduces the administrative burden imposed on the lrl)A
`office. With the limited 77bit “port” address space of the LM4
`MUX, it also removes the problem of organizations making
`unfair claims on address space real estate.
`
`117.1317, Personal Communications ‘ February Ztltlll
`
`Device discovery and IMEIAS provide the pivotal easesoli '
`use features in the platform that enable application entities to
`locate and establish contact with peer entities which support a
`given interaction protocol (i.c., the semantics of the message
`sct exchanged between application entities via the channel
`established through the erA platform).
`
`Advanced Infrared
`
`The lrl)/\-Data 'l .x architecture has some obvious limitations.
`liirst, although the arehitCCtui‘e can accommodate a point—
`to-multipoint mode of operation, the li'lAl’ specification has
`never been extended to define the protocol machinery 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 desirable. Viewed as a single point-to-point link, the
`behavior of an lrLAl' connection is largely symmetric, and the
`differences in behavior between an lrl AP primary station and
`an lrl .Al’ secondary station are largely moot. llowever, the
`introduction of point-to—niultipoint operation would signifi-
`cantly disturb this symmetry in ways that would become incon-
`venient for the end user. Consider a portable computer that
`needs to access both a LAN access point and a desktop print—
`er. it would be natural for the portable computer to become
`the lrl./\P primary and establish lrlAf’ connections with the
`LAN access point and the printer, each of which acts as an
`lrLAl’ secondary station. llowever, it is also reasonable that
`the IAN 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 lrLAP primary role. If the
`connection to the LAN access point were established first and
`the access point were to cease the primary role (possibly
`through role reversal), the portable computer would he uiiahlc
`to establish a second lrl./\P connection to the printer. If the
`portable computer retained the primary role, it. could establish
`that second connection, but the LAN access point (and the
`printer) would be prevented from establishing connections to
`other potential “clients.” What the user could achieve would
`not only depend on the set of concurrent interactions they
`were attempting to initiate, but also on the order in which
`those interactions were initiated. This would lead to inconsis—
`tent behavior which would become frustrating for end users.
`Thus, lrl)/\ so far has chosen not to expand the lrLAP defini-
`tion to encompass poiiitato-niultipoint operation.
`Second, within some given field of view, the establishment
`of an lrLAl' connection between a single pair of devices
`inhibits the establishment of connections between other inde—
`pendent devices whose fields ofvicw intersect that of the
`established connection. Thus, Lise of the medium becomes
`dedicated to a single pair of devices. An important subclass of
`general imiltipoint communication in a shared medium is to
`ctiable multiple independent pairs of devices to establish inde-
`pendent communication relationships If two devices are in
`view of each other, it is reasonable that they should be able to
`establish communications and share access to the medium
`with other users of the space.
`Thus, members of the lrl)/\ community sought to extend
`the [I'D/\rlklltl architecture to enable true niiiltipoiiit connec-
`tivity while at the same time preserving the investment in
`upper layer applications and services by ensuring that the
`semantics of the service definitions at the upper layers of the
`platform are maintained.
`It is important to be aware of a few differences between
`the goals of the IrDA community and the goals of those
`defining wireless LAN specifications. The llilili 802 medium
`access control (MAC) service defines a best—effort ordered
`delivery service with at most once delivery semantics. It also
`
`5
`
`

`

`
`
`Legacy
`comm apps
`
`appIcations
`
`
`
`Platform
`
`:3 [7d
`
`
`
`
`
`
`protocol architecture adds an ll‘LC pro-
`tocol entity, which provides multipoint
`link layer connectivity alongside an
`IrLAP protocol entity, which provides
`legacy connectivity to IrDA 1.x devices.
`The link manager (IrIIM) layer [17] is a
`“thin” layer that multiplexes the use of
`I1LAP and 11] C over their respective
`physical layers At the uppei bound ol
`the link control layer, lrIC and IILAP
`provide identical services to the IrI.MP
`layer. Thus, within an AIR device, the
`IrLAI’, INC, and lrI.lVI protocol entities
`may be regarded as a single logical entity,
`with a single device address which sup,
`ports an integrated discovery process,
`and both IrI.AP and IrIcC connections.
`The particular use of IrDA l.x II‘IIAIJ or
`AIR IrI,C procedures for establishing
`device-to—device connections becomes
`transparent to IrLMI’ entities and above.
`IerIAC defines a burst reservation
`carrier sense multiple access with collis
`
` "Appliance"
`
` sion avoidance (CSMA/CA) MAC pro-
`
`
`
`
`Physical
`Irma ll.
`erAl .x
`
`
`
`AIR
`
`3
`'
`
`tocol. Such MAC protocols rely on the
`exchange of: Request—'I‘o-Send, Clear—to—
`Send MAC protocol data units (I’DUs).
`For such a mechanism to function prop«
`crly, it is important that the reservation
`MAC I‘DUs be decoded, not only by
`devices capable of engaging in commu—
`nications, but also by devices capable of
`interfering with communications. In some radio frequency
`(RF) systems using this style of MAC protocol, the range of
`the reservation messages is extended by boosting the trans-
`mission powcr for the related MAC PDUs. AIR makes use
`of a variable rate (VR) coiling technique known as repetition
`coding to robustly code the headers of all AIR MAC PDUs.
`The use of this technique was pioneered by IBM Research
`in Zurich [I It], and full details are given in the AIR physical
`layer specification [l9]. Repetition coding trades signal-to-
`noise ratio (SNR) (range) for transmission rate by repeti-
`tion of physical
`layer symbols. Repetition decoders
`“average“ the repeated symbols received prior to making a
`decision on what symbol was encoded. In theory, successive
`halving of the data rate by successively doubling the number
`01 symbol Icpctitions yields approximately a 19 percent
`range increase at each reduction step. Cumulatively, the
`effect of a .IG-fold rate reduction (four doublings of the GC~
`etition rate) yields a doubling of the effective range of
`transmission. Key fields of the AIR II'MAC [l7] I’DUs are
`coded with st repetition.
`This VR physical layer delivers two benefits. First, it pro-
`vides a means of robustly coding the media reservation Ines—
`sages defined by the CSMA/CA burst reservation MAC
`protocol defined in the II‘MAC specification so that they
`reach more potential sources of interference.
`Second, by actively monitoring the symbol error rates at an
`AIR decoder, it is possible it estimate the SNR for the chain
`nel between the source and sink of a packet. This SNR esti-
`mate can then be used to compute a rate recommendation
`that can be fed back to the sending station in order to maiir
`tain a goodnquality channel. AIR’s base rate is 4 Mb/s, reduc~
`ing through successive halving of data rates to 256 kb/s to
`yield a doubling of range. AIR prototypes have been demon-
`strated that have a 4 Mb/s range of 5 In doubling to It) In at
`256 lib/5.
`
`I figure 4. LID/1 dam {IdWIiIreIR protocol aIc/I.ifcc'.ILIrc
`
`assumes a transitive communications relationship, At the
`MAC layer:
`III‘ A can communicate with B
`AND R can communicate with C
`'I‘I-IEN A can communicate with C.
`In the world of shortwrange infrared wireless communication
`this is not the case. It may even be the case that the communi—
`cation relationship is asymmetric: A may be “heard” by B, but
`I} 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/dcparting node, and potentially the wired
`infrastructure and the other devices attached to that infra~
`structure. In the wireless case, the bounds of a given IIAN
`segmen