www.ausystem.com
`
`BluetoothTM
`Whitepaper
`
`Samsung Exhibit 1040
`Samsung v. Affinity
`IPR2014-01181
`Page 00001
`
`

`
`Summary
`
`The number of computing and telecommunications devices is increasing and
`consequently, the focus on how to connect them to each other. The usual solution
`is to connect the devices with a cable to make file transfer and synchronisation
`possible. File transfer is required so that the user is able to type a document in, for
`instance, a PDA and move it later to the PC. There is also a need for synchronisa-
`tion of events in the calendars of the various devices. The solution to these
`requirements has been to connect the devices with a cable, or sometimes to
`connect them using infrared light.
`
`The cable solution is often complicated since it may require a cable specific to the
`devices being connected as well as configuration software. The infrared solution
`eliminates the cable, but requires line of sight. To solve these problems a new
`technology, Bluetooth, has been developed. Bluetooth provides the means for a
`short-range radio link solution. It is the result of a co-operative effort among a
`number of companies all working for a cheap, simple, and low power-consuming
`solution with broad market support.
`
`With Bluetooth, users will be able to connect a wide range of computing and
`telecommunications devices easily and simply, without the need for connecting
`cables. The technology defines how units can communicate up to 10 meters from
`each other. It also defines how certain applications should be mapped onto the
`hardware to be compatible with Bluetooth. If this is achieved, the concept ensures
`that devices can operate with other Bluetooth applications and devices regardless
`of manufacturer. The concept can also act as a way to avoid cable solutions.
`Furthermore, it can also be used to enable communication between several units,
`such as small radio LANs. This results in a multitude of possible future user
`scenarios.
`
`The strength of the Bluetooth concept is that Bluetooth chips can be made very
`small; they are cheap and they are low power-consuming. Furthermore, there is
`support for the technique from a vast variety of companies. It is supported not
`only in the PC and mobile phone industries, but also in several other industries as
`well.
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`1
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:19)(cid:21)
`
`

`
`Introduction
`
`This Bluetooth white paper aims to give a good overview of the Bluetooth
`concept. It strives to cover technical aspects, regarding hardware, software and
`Bluetooth applications. It also deals with marketing aspects in relation to
`competing techniques. Furthermore, it describes some of the companies behind
`Bluetooth and some of their motives.
`
`The document begins with an introduction where the Bluetooth background and
`the Bluetooth standardisation organisation are described. What benefits and
`possibilities the technology can provide to users are handled in the section
`Bluetooth – Cable replacement, and more. This section also gives a view of the
`marketing position that the Bluetooth technology enters. The Bluetooth protocol
`layers and their configuration is described in the section Bluetooth architecture. It
`A section describing the Bluetooth air interface follows it. Competing techniques
`and the strengths with the Bluetooth concept is then handled in the section Why
`Bluetooth − Technical aspects. Finally, a brief look at the near Bluetooth future is
`done in the last section.
`
`Background
`Bluetooth technology and standards provide the means for the replacement of
`cable that connects one device to another with a universal short-range radio link.
`The technology was initially developed for replacing cables, but has now evolved
`into not only being a cable replacement technique but also a technique to
`establish connection between several units. For instance, it shows how to create
`small radio LANs.
`
`A study was initiated at Ericsson Mobile Communications in 1994 to find a low
`power and low cost radio interface between mobile phones and their accessories.
`The requirements regarding price, capacity and size were set so that the new
`technique would have the potential to outdo all cable solutions between mobile
`devices. Initially a suitable radio interface with a corresponding frequency range
`had to be specified. A number of criteria for the concept were defined regarding
`size, capacity and global uniformity. The radio unit should be so small and
`consume such low power that it could be fitted into portable devices with their
`limitations. The concept had to handle both speech and data and finally the
`technique had to work all around the world.
`
`The study soon showed that a short-range radio link solution was feasible. When
`designers at Ericsson had started to work on a transceiver chip, Ericsson soon
`realised that they needed companions to develop the technique. The associates
`strove not only to improve the technical solutions but also to get a solid and broad
`market support in the business areas of PC hardware, portable computers and
`mobile phones. Fear for a market situation with a multitude of non-standard cable
`solutions, where one cable is designed specifically for one pair of devices, was
`one of the motives that made competing companies join the project.
`
`Ericsson Mobile Communications, Intel, IBM, Toshiba and Nokia Mobile Phones
`formed a Special Interest Group (SIG) in 1998. This group represented the
`diverse market support that was needed to generate good support for the new
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`2
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:19)(cid:22)
`
`

`
`technology. In May of the same year, the Bluetooth consortium announced itself
`globally. The intention of the Bluetooth SIG is to form a de facto standard for the
`air interface and the software that controls it. The purpose is to achieve
`interoperability between different devices from different producers of portable
`computers, mobile phones and other devices.
`
`The name Bluetooth comes from a Danish Viking and King, Harald Blåtand
`(Bluetooth in English), who lived in the latter part of the 10th century. Harald
`Blåtand united and controlled Denmark and Norway.
`
`Bluetooth SIG
`In February 1998, the Bluetooth Special Interest Group, SIG, was founded. At the
`start, it consisted of the five companies mentioned above. Today more than 1300
`companies have joined the SIG to work for an open standard for the Bluetooth
`concept. By signing a zero cost agreement, companies can join the SIG and
`qualify for a royalty-free licence to build products based on the Bluetooth
`technology.
`
`To avoid different interpretations of the Bluetooth standard regarding how a
`specific type of application should be mapped to Bluetooth, the SIG has defined a
`number of user models and protocol profiles. These are described in more detail
`in the section entitled Bluetooth Usage Models and Profiles.
`
`The SIG also works with a Qualification Process. This process defines criteria for
`Bluetooth product qualification that ensures that products that pass this process
`meet the Bluetooth specification.
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`3
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:19)(cid:23)
`
`

`
`Bluetooth – Cable replacement, and more
`
`Why Bluetooth −−−− Marketing aspects
`The removal of the cable connections between the mobile phone and its
`accessories was the origin of the Bluetooth concept. A computer connected to a
`keyboard, a mouse, a pair of loudspeakers, a PDA and so on, is a situation where
`a cordless solution would be useful. The need for different devices to be placed
`beside each other can also be eliminated. Instead, the location of devices is
`suddenly only limited by where to get the power supply.
`
`Another motive for the Bluetooth technology is the problems with connecting and
`configuring mobile devices. To connect a new device a cable is needed, often
`specific to the brand of the device. When the physical connection is established a
`complicated configuration of the connection often follows. With existing cable
`replacement techniques, the security of the data transmission is insufficient.
`These difficulties are also addressed in the development of the Bluetooth
`technique.
`
`The introduction of the Nokia Communicator 9000 has also been described as an
`event that increased interest in Bluetooth development. The Communicator
`reduced the complexity of connecting a mobile phone with a computer by
`building a two-in-one unit to solve the problem. It showed that one of the
`simplest ways to run data traffic via GSM was to buy a Communicator and not to
`buy a GSM Data interface card with cables matching both the phone and the
`portable computer. The combination of two devices in one was seen as a threat to
`the major manufacturers of portable PCs [1]. What if people started to buy
`communicators from mobile phone manufacturers instead of portable PCs from
`IBM or Toshiba? Furthermore, the introduction of Communicators "would impact
`sales of central processors for chip supplier Intel which dominates the PC market
`but doesn't have a competitive product for the likes of intelligent phones or
`handheld PCs" [1]. Hence, a development where the strong market position for
`portable PCs is maintained, is essential for the PC industry.
`
`Other motives for a new cable replacement technique are [2]:
`
`• The number of users of portable PCs is increasing. This implies a larger
`market for cordless connection of devices.
`
`• The constant shrinking of portable PCs has led to solutions where devices,
`e.g. CD-ROM drives, are external and need to be connected smoothly to the
`PC.
`
`•
`
`"Mobile computers now rival desktop systems in performance" [2]. The need
`for a stationary PC at the office and a portable PC for travelling is decreasing.
`
`The Bluetooth technique provides a solution to the problems described above.
`The solution eliminates the annoying cable and its limitations regarding
`flexibility (often specific for a brand or pair of devices) and range. But, Bluetooth
`implies more than that. The technique provides the means for connecting several
`units to each other such as setting up small radio LANs between any types of
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`4
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:19)(cid:24)
`
`

`
`Bluetooth devices. A number of user scenarios are described. They highlight
`more possibilities that reach far beyond just an elimination of the point-to-point
`cable.
`
`Bluetooth −−−− The future is now
`Alex, sales and marketing manager at Sysau Inc., is working on an important
`document on a PC. Sysau Inc. is a software consultant company outside London.
`In Alex's office, there are no cables except for the power supply to the electronic
`devices. Telephone, keyboard, loudspeakers, PC screen, and the PC itself, are all
`interfaced through Bluetooth. The removal of signalling cables has led to new
`ways of furnishing an office, as the CPU no longer needs to be next to the
`keyboard and monitor. When Mr Miller calls, Alex answers with the Bluetooth
`headset by tapping the answer button on the headset. Mr Miller is one of the
`organisers of an exhibition in New York. He asks if Alex can speak at the
`exhibition and present Sysau's view of new small LAN techniques. When
`checking the calendar, Alex notices that this is at the same time as a meeting she
`is scheduled to attend at the same exhibition. Still, Alex agrees to do the presenta-
`tion and while heading to the travel agent, which is a few doors down the hall, the
`chairman of the meeting calls to remind Alex of some of the items that will be
`discussed at the meeting. During the call, the travel agent has finalised the air
`reservation and Alex instructs the travel agent to send the ticket later on as an
`"electronic ticket". After finishing the work and checking that the presentation is
`in order, Alex pockets the computer and heads for the car.
`
`While driving, the e-ticket to New York arrives on Alex's smartphone. When
`Alex arrives at Heathrow's parking garage, her credit card ID is transmitted via
`Bluetooth to the parking system. Naturally, Alex will pay wirelessly with the
`WAP browser and wireless-PKI services in the smartphone when parking the car
`at Heathrow, and renting a car in New York.. At the check-in counter, identi-
`fication and check-in is done via Bluetooth. After check-in, Alex strolls to the
`business lounge. The doors open automatically when the Bluetooth equipment in
`the lounge doors detects Alex's electronic boarding pass. In order to get a map of
`the exhibition area, Alex connects to the Internet through the lounge LAN using
`Bluetooth.
`
`On the plane, Alex and an old friend are seated apart from each other, so they
`start chatting using their portable PCs. They talk about a computer game that
`Alex has not tried and after sending the game to Alex, they start playing. After a
`bland aeroplane dinner, Alex writes an e-mail to send home. It will be transmitted
`when the plane has landed and Alex's smartphone can be switched on again.
`
`At the exhibition area, Alex finds hall two, where the speakers have congregated.
`The organiser gives Alex and the other speakers a password that enables them to
`use the main video projector. As usual, the speakers use cordless Bluetooth
`microphones for their presentations and the convention goes as planned.
`Afterwards, Alex meets with Mr Scott and four others participating in a joint
`venture. She and the others exchange vCards via their smartphones using
`Bluetooth. Everyone attending the meeting is using the new Bluetooth technique
`where all participants form a network with their PCs so that they can work on the
`same document at the same time. After some minor discussions, they finish their
`work with the Multimedia over Bluetooth specification and Alex can dash for the
`plane back home.
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`5
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:19)(cid:25)
`
`

`
`An Introduction to the Bluetooth air interface
`To meet the requirements for the air interface a frequency band between 2.400
`and 2.500 GHz was selected. Thus, the requirements regarding operating world
`wide, support for both data and speech and the limitations regarding physical
`characteristics (size and power consumption) were covered. This radio frequency
`band is the Industrial-Scientific-Medical, ISM band and ranges in Europe and the
`USA from 2.400 to 2.4835 GHz (in France and Spain only parts of this range are
`available). As a result, Bluetooth devices must be able to act in the range from
`2.400 to 2.500 GHz and be able to select a segment in the ISM band within which
`they can act. The ISM band is open to any radio system. Cordless telephones,
`garage door openers and microwave ovens operate in this band, where microwave
`ovens are the strongest source of interference.
`
`Bluetooth units connect to each other forming a so-called piconet, consisting of
`up to eight active Bluetooth units. This and the way interference due to other
`units acting in the ISM band is handled, is described in the section on The
`Bluetooth air interface.
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`6
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:19)(cid:26)
`
`

`
`Bluetooth architecture overview
`
`This section describes the Bluetooth architecture. The complete protocol stack
`comprises, as seen in Figure 1, of both Bluetooth specific protocols and non-
`Bluetooth specific protocols. In the figure, non-Bluetooth specific protocols are
`shaded.
`
`AT-
`Commands
`
`SDP
`
`TCS
`
`Audio
`
`vCard/
`vCalendar
`
`OBEX
`
`WAE
`
`WAP
`
`UDP TCP
`
`IP
`
`PPP
`
`RFCOMM
`
`HCI
`
`L2CAP
`
`LMP
`
`Baseband
`
`Figure 1 The Bluetooth Protocol Stack
`
`The Bluetooth architecture strategy
`A number of profiles have been defined by the Bluetooth standardisation
`organisation. These profiles have been developed in order to describe how imple-
`mentations of user models are to be accomplished. The user models describe a
`number of user scenarios where Bluetooth performs the radio transmission. These
`profiles specify how applications and devices shall be mapped onto the Bluetooth
`concept.
`
`A profile defines a selection of messages and procedures from the Bluetooth
`specifications and gives an unambiguous description of the air interface for
`specified services and use cases. A profile can be described as a vertical slice
`through the protocol stack. It defines options in each protocol that are mandatory
`for the profile. It also defines parameter ranges for each protocol. The profile
`concept is used to decrease the risk of interoperability problems between different
`manufacturers' products.
`
`The profile defined for exchanging of vCard information is illustrated in Figure 2,
`where an application, vCard, is defined to operate over a certain subset (OBEX,
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`7
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:19)(cid:27)
`
`

`
`RFCOMM and so on) of the Bluetooth protocol stack. Some of the user models
`and their profiles are described in section Bluetooth Usage Models and Profiles.
`
`vCARD
`
`OBEX
`
`RFCOMM
`
`SDP
`
`TCS Binary
`
`L2CAP
`
`LMP
`
`Base Band
`
`HCI
`
`Figure 2 The Object Push Profile
`
`There are four general profiles defined, on which some of the highest prioritised
`user models and their profiles are directly based on. These four models are; the
`Generic Access Profile (GAP), the Serial Port Profile, the Service Discovery
`Application Profile (SDAP) and the Generic Object Exchange Profile (GOEP).
`
`Protocols such as OBEX and UDP have been included in the protocol
`architecture to facilitate the adaptation of applications using such existing
`protocols. This gives for instance a number of existing applications supporting
`UDP an interface to the Bluetooth technology.
`
`Bluetooth Usage Models and Profiles
`In this section, four general profiles GAP, the Serial Port Profile, SDAP and
`GOEP are defined. A number of usage models are identified by the Bluetooth
`SIG as fundamental, and are therefore, highlighted in the Bluetooth documenta-
`tion. Some of these user models and their relative profiles are also described in
`this section. Note that for every user model there is one or more corresponding
`profiles. The Bluetooth profiles and how they are related is illustrated in Figure 3.
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`8
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:19)(cid:28)
`
`

`
`Generic Access Profile
`TCS Binary profiles
`Cordless
`Telephony Profile
`
`Service Discovery
`Profile
`
`Intercom Profile
`
`Serial Port Profile
`Dial up Network-
`ing Profile
`
`Generic Object
`Exchange Profile
`
`Fax Profile
`
`Headset Profile
`
`LAN Access
`Profile
`
`File Transfer
`Profile
`
`Object Push
`Profile
`
`Synchronisation
`Profile
`
`Figure 3 The Bluetooth Profiles
`The four general Bluetooth profiles
`
`The four profiles described in this section form the basis for the user models and
`their profiles. The profiles also provide the foundation for future user models and
`profiles.
`Generic Access Profile, GAP
`
`The Generic Access Profile, GAP, defines how two Bluetooth units discover and
`establish a connection with each other. GAP handles discovery and establishment
`between units that are unconnected. The profile defines operations that are
`generic and can be used by profiles referring to GAP and by devices
`implementing multiple profiles.
`
`GAP ensures that any two Bluetooth units, regardless of manufacturer and
`application, can exchange information via Bluetooth in order to discover what
`type of applications the units support. Bluetooth units not conforming to any
`other Bluetooth profile must conform to GAP to ensure basic interoperability and
`co-existence [3].
`Service Discovery Application Profile, SDAP
`
`The Service Discovery Application Profile, SDAP, defines the investigation of
`services available to a Bluetooth unit. The profile handles the search for known
`and specific services as well as a general service search.
`
`SDAP involves an application, the Service Discovery User Application, which is
`required in a Bluetooth unit for locating services. This application interfaces the
`Service Discovery Protocol that sends and receives service inquiries to and from
`other Bluetooth units. Hence, SDAP describes an application that interfaces with
`a specific Bluetooth protocol to take full advantage of it for the direct benefit of
`the end-user.
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`9
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:20)(cid:19)
`
`

`
`The SDAP is dependent on the GAP, i.e. SDAP re-uses parts of the GAP [4].
`Serial Port Profile
`
`The Serial Port Profile defines how to set-up virtual serial ports on two devices
`and connecting these with Bluetooth. Using this profile provides the Bluetooth
`units with an emulation of a serial cable using RS232 control signalling (RS232
`is a common interface standard for data communications equipment). The profile
`ensures that data rates up to 128 kbit/s can be used.
`
`The Serial Port Profile is dependent on the GAP, i.e. just as SDAP, Serial Port
`Profile re-uses parts of the GAP [5].
`Generic Object Exchange Profile, GOEP
`
`The Generic Object Exchange Profile, GOEP, defines the set of protocols and
`procedures to be used by applications handling object exchanges. A number of
`usage models, described in the section Bluetooth Usage Models, are based on this
`profile, e.g. File Transfer and Synchronisation. Typical Bluetooth units using this
`profile are notebook PCs, PDAs, mobile phones and smart phones.
`
`Applications using the GOEP assume that links and channels are established, as
`defined by the GAP. The GOEP describes the procedure for pushing data from
`one Bluetooth unit to another. The profile also describes how to pull data between
`units.
`
`The GOEP is dependent on the Serial Port Profile [6].
`Bluetooth Usage Models
`
`In this section a number of Bluetooth usage models are described. For each usage
`model there is one or more corresponding profiles defining protocol layers and
`functions to be used. The profiles are not described in detail in this document, for
`more information refer to the Bluetooth standardisation documents.
`File Transfer
`
`The File Transfer usage model offers the capability to transfer data objects from
`one Bluetooth device to another. Files, entire folders, directories and streaming
`media formats are supported in this usage model. The model also offers the
`possibility of browsing the contents of the folders on a remote device.
`Furthermore, push and exchange operations are covered in this usage model, e.g.
`business card exchange using the vCard format. The File Transfer model is based
`on GOEP.
`Internet Bridge
`
`The Internet Bridge usage model describes how a mobile phone or cordless
`modem provides a PC with dial-up networking capabilities without the need for
`physical connection to the PC. This networking scenario requires a two-piece
`protocol stack, one for AT-commands to control the mobile phone and another
`stack to transfer payload data.
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`10
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:20)(cid:20)
`
`

`
`LAN Access
`
`The LAN Access usage model is similar to the Internet Bridge user model. The
`difference is that the LAN Access usage model does not use the protocols for AT-
`commands. The usage model describes how data terminals use a LAN access
`point as a wireless connection to a Local Area Network. When connected, the
`data terminals operate as if it they were connected to the LAN via dial-up
`networking.
`Synchronisation
`
`for automatic
`the means
`The synchronisation usage model provides
`synchronisation between for instance a desktop PC, a portable PC, a mobile
`phone and a notebook. The synchronisation requires business card, calendar and
`task information to be transferred and processed by computers, cellular phones
`and PDAs utilising a common protocol and format.
`Three-in-One Phone
`
`The Three-in-One Phone usage model describes how a telephone handset may
`connect to three different service providers. The telephone may act as a cordless
`telephone connecting to the public switched telephone network at home, charged
`at a fixed line charge. This scenario includes making calls via a voice base
`station, and making direct calls between two terminals via the base station. The
`telephone can also connect directly to other telephones acting as a “walkie-talkie”
`or handset extension i.e. no charging needed. Finally, the telephone may act as a
`cellular telephone connecting to the cellular infrastructure. The cordless and
`intercom scenarios use the same protocol stack.
`Ultimate Headset
`
`The Ultimate Headset usage model defines how a Bluetooth equipped wireless
`headset can be connected, to act as a remote unit’s audio input and output
`interface. The unit is probably a mobile phone or a PC for audio input and output.
`As for the Internet Bridge user model, this model requires a two-piece protocol
`stack; one for AT-commands to control the mobile phone and another stack to
`transfer payload data, i.e. speech. The AT-commands control the telephone
`regarding for instance answering and terminating calls.
`
`Bluetooth core protocols
`Baseband
`
`The Baseband and Link Control layer enables the physical RF link between
`Bluetooth units forming a piconet. This layer controls the Bluetooth unit's
`synchronisation and transmission frequency hopping sequence. The two different
`link types defined in Bluetooth, Synchronous Connection Oriented, SCO, and
`Asynchronous Connectionless, ACL, described in the section Link types, are also
`managed by this layer.
`
`The ACL links, for data, and the SCO links, mainly for audio, can be multiplexed
`to use the same RF link [7].
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`11
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:20)(cid:21)
`
`

`
`Audio
`
`Audio transmissions can be performed between one or more Bluetooth units,
`using many different usage models. Audio data do not go through the L2CAP
`layer (described below) but go directly, after opening a Bluetooth link and a
`straightforward set-up, between two Bluetooth units.
`Host Controller Interface, HCI
`
`The Host Controller Interface, HCI, provides a uniform interface method for
`accessing the Bluetooth hardware capabilities. It contains a command interface to
`the Baseband controller and link manager and access to hardware status. Finally,
`it contains control and event registers [8].
`Link Manager Protocol, LMP
`
`The Link Manager Protocol, LMP, is responsible for link set-up between
`Bluetooth units. It handles the control and negotiation of packet sizes used when
`transmitting data. The Link Manager Protocol also handles management of power
`modes, power consumption, and state of a Bluetooth unit in a piconet. Finally,
`this layer handles generation, exchange and control of link and encryption keys
`for authentication and encryption [9].
`Logical Link Control and Adaptation Protocol, L2CAP
`
`The Bluetooth logical link control and adaptation protocol, L2CAP, is situated
`over the Baseband layer and beside the Link Manager Protocol in the Bluetooth
`protocol
`stack. The L2CAP
`layer provides connection-oriented and
`connectionless data services to upper layers.
`
`The four main tasks for L2CAP are:
`
`• Multiplexing – L2CAP must support protocol multiplexing since a number of
`protocols (e.g. SDP, RFCOMM and TCS Binary) can operate over L2CAP.
`
`• Segmentation and Reassembly – Data packets exceeding the Maximum
`Transmission Unit, MTU, must be segmented before being transmitted. This
`and the reverse functionality, reassemble, is performed by L2CAP.
`
`• Quality of Service – The establishment of an L2CAP connection allows the
`exchange of information regarding current Quality of Service for the
`connection between the two Bluetooth units.
`
`• Groups – The L2CAP specification supports a group abstraction that permits
`implementations for mapping groups on to a piconet.
`
`An L2CAP implementation must be uncomplicated and implying low overhead
`since it must be compatible with the limited computational resources in a small
`Bluetooth unit [10].
`Service Discovery Protocol, SDP
`
`The Service Discovery Protocol, SDP, defines how a Bluetooth client's
`application shall act to discover available Bluetooth servers' services and their
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`12
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:20)(cid:22)
`
`

`
`characteristics. The protocol defines how a client can search for a service based
`on specific attributes without the client knowing anything of the available
`services. The SDP provides means for the discovery of new services becoming
`available when the client enters an area where a Bluetooth server is operating.
`The SDP also provides functionality for detecting when a service is no longer
`available [11].
`
`Cable replacement protocol
`RFCOMM
`
`The RFCOMM protocol is a serial port emulation protocol. The protocol covers
`applications that make use of the serial ports of the unit. RFCOMM emulates RS-
`232 control and data signals over the Bluetooth baseband. It provides transport
`capabilities for upper level services, e.g. OBEX that use a serial line as the
`transport mechanism.
`
`Telephony control protocol
`Telephony Control – Binary
`
`The Telephony Control protocol – Binary, TCS Binary or TCS BIN, is a bit-
`oriented protocol, which defines the call control signalling for the establishment
`of speech and data calls between Bluetooth units. The protocol defines the
`signalling for establishment and release of calls between Bluetooth units. As well
`as signalling to ease the handling of groups of Bluetooth units. Furthermore, TCS
`Binary provides functionality to exchange signalling information unrelated to
`ongoing calls.
`
`Establishment of a voice or data call in a point-to-point configuration as well as
`in a point-to-multipoint configuration is covered in this protocol (note, after
`establishment, the transmission is from point to point). The TCS Binary is based
`on the ITU-T Recommendation Q.931.
`Telephony Control – AT Commands
`
`A number of AT-commands are supported for transmitting control signals for
`telephony control. These use the serial port emulation, RFCOMM, for
`transmission.
`
`Adopted protocols
`This section describes a number of protocols that are defined to be adopted to the
`Bluetooth protocol stack. Note some of these adaptations are at the moment
`incomplete.
`PPP
`
`The IETF Point-to-Point Protocol (PPP) in the Bluetooth technology is designed
`to run over RFCOMM to accomplish point-to-point connections. PPP is a packet-
`oriented protocol and must therefore use its serial mechanisms to convert the
`packet data stream into a serial data stream.
`
`Bluetooth White Paper 1.1, © AU-System, January 2000
`
`13
`
`(cid:51)(cid:68)(cid:74)(cid:72)(cid:3)(cid:19)(cid:19)(cid:19)(cid:20)(cid:23)
`
`

`
`TCP/UDP/IP
`
`The TCP/UDP/IP standards are defined to operate in Bluetooth units allowing
`them to communicate with other units connected, for instance, to the Internet.
`Hence, the Bluetooth unit can act as a bridge to the Internet. The TCP/IP/PPP
`protocol configuration is used for all Internet Bridge usage scenarios in Bluetooth
`1.0 and for OBEX in future versions. The UDP/IP/PPP configuration is available
`as transport for WAP.
`OBEX Protocol
`
`IrOBEX, shortly OBEX, is an optional application layer protocol designed to
`enable units supporting infrared communication to exchange a wide variety of
`data and commands in a resource-sensitive standardised fashion. OBEX uses a
`client-server model and is independent of the transport mechanism and transport
`API. The OBEX protocol also defines a folder-listing object, which is used to
`browse the contents of folders on remote device. RFCOMM is used as the main
`transport layer for OBEX
`Content formats
`
`The formats for transmitting vCard and vCalendar information are also defined in
`the Bluetooth specification. The formats do not define transport mechanisms but
`the format in which electronic business cards and personal calendar entries and
`scheduling information are transported. vCard and vCalendar is transferred by
`OBEX.
`Wireless Application Protocol, WAP
`
`The Wireless Application Protocol (WAP) is a wireless protocol specification
`that works across a variety of wide-area wireless network technologies bringing
`the Internet to mobile devices. Bluetooth can be used like other wireless networks
`with regard to WAP, it can be used to provide a bearer for transporting data
`between the WAP Client and its adjacent WAP Server. Furthermore, Bluetooth’s
`ad hoc networking capability gives a