Bluetooth revealed 0130902942, 9780130902948

Citation preview

Bluetooth Revealed , By Brent A. Miller, Chatschik Bisdikian

Foreword My work wit h t he Bluet oot h wireless t echnology, which began long before it becam e Bluet oot h, has been a privilege and an ext rem ely rewarding experience. I n 1997, when a few m aj or players in t he t elecom m unicat ions and port able com put ing indust ries engaged in som e init ial discussions, no one could even dream of t he unprecedent ed success t he program was t o enj oy a few years down t he road. We all knew t hat t here was a great need for a low- power, low- cost , short - range cable replacem ent , but from t here t o t he overwhelm ingly favorable indust ry and m edia response was a quant um leap. The Bluet oot h SI G m anaged from t he beginning t o focus on consum er requirem ent s rat her t han j ust designing t he t echnically best possible radio. A zero- cost license, good m arket ing ( of course) and a bit of luck wit h t he t im ing are always useful, t oo, when you want t o est ablish a worldwide de fact o st andard. Predict ions from m any independent sources, such as Frost & Sullivan, Cahners I n- St at , Merrill Lynch and m any ot her research inst it ut es, indicat e t hat indeed t he Bluet oot h wireless t echnology will becom e a sm ashing success, wit h as m any as 1.5 billion or m ore devices being equipped wit h Bluet oot h wireless t echnology in t he year 2005. Wit h t ens of t housands of engineers around t he world working on im plem ent at ions and perhaps even hundreds of t housands of ot her people such as st udent s and professionals becom ing int erest ed in t his t echnology, it is easy t o underst and t he need for t he publicat ion you have in your hands. Writ t en by people involved from t he beginning in key roles t o develop t he Bluet oot h specificat ion, you will find t he book t o be m ost aut horit at ive. Perhaps even m ore im port ant ly, it is writ t en in an easy- t o- underst and way, explaining a lot of t he t hinking behind t he developm ent of m any chapt ers in t he specificat ion. I n short , Bluet oot h Revealed: The I nsider's Guide t o an Open Specificat ion for Global Wireless Com m unicat ions provides an im port ant source of easy- t o- access inform at ion about t his new and excit ing t echnology. I look forward t o seeing you in m y " piconet " soon! Anders Edlund Market ing Direct or, Bluet oot h Product Unit Ericsson Mobile Com m unicat ion

1

Preface The convergence of com put ing and com m unicat ions has been predict ed for m any years. Today's explosion of a m yriad of new t ypes of personal com put ing and com m unicat ions devices— not ebook com put ers, personal digit al assist ant s, " sm art " phones, t wo- way pagers, digit al cam eras and so on—has result ed in new ways for people t o com m unicat e and gain access t o dat a. The advent of t his pervasive com put ing, especially via wireless com m unicat ions, enables t hese devices t o be used in new set t ings: not only can people m ake voice calls from t heir aut om obile using a m obile phone, but also t hey can access t he World Wide Web from a wireless not ebook or handheld com put er while at t he airport or a shopping m all. We are rapidly m oving t oward a world where com put ing and com m unicat ions becom e ubiquit ous—not only at work but also in t he hom e, in public places and in personal surroundings. Unt il recent ly, enabling all of t hese devices t o com m unicat e wit h each ot her has been cum bersom e, oft en involving t he use of special cables t o connect t he devices t oget her along wit h device- specific soft ware t hat m ight use propriet ary prot ocols. To exchange inform at ion am ong all of her personal devices, a person m ight need t o carry as m any cables as devices and st ill lack assurance t hat all t he devices could int erconnect . The inabilit y t o share inform at ion am ong devices or t he difficult y in doing so lim it s t heir usefulness. The Bluet oot h™ t echnology enables devices t o com m unicat e seam lessly wit hout wires. While Bluet oot h wireless com m unicat ion is first and forem ost a m eans for cable replacem ent , it also enables m any new applicat ions—t he use of a single m obile t elephone as a cellular phone, cordless phone or int ercom and t he use of a not ebook com put er as a speakerphone, j ust t o nam e t wo. The Bluet oot h Special I nt erest Group ( SI G) was form ed in early 1998 by Ericsson® , I nt el® , I BM® , Nokia® and Toshiba® t o develop an open specificat ion for globally available short - range wireless radio frequency com m unicat ions. The SI G has published a specificat ion for t he Bluet oot h radio and baseband along wit h a set of com m unicat ion prot ocols com prising a soft ware st ack used wit h t he Bluet oot h radio hardware. The Bluet oot h radio m odule design is opt im ized for very low power consum pt ion, low cost , sm all foot print and use anywhere in t he world. I n addit ion t o t he core specificat ion, t he SI G has also published Bluet oot h profiles t hat describe how t o use t he soft ware prot ocols such t hat int eroperabilit y am ong all kinds of devices can be achieved, regardless of who m anufact ures t hese devices. Version 1.0 of t he specificat ion was published in July 1999. Today t he Bluet oot h Special I nt erest Group consist s of nine prom ot er com panies ( j oining t he five founding com panies not ed above in t he SI G's core group are 3Com ® , Lucent ® , Microsoft ® and Mot orola® ) and well over 1,800 adopt er com panies from around t he world, represent ing a diverse set of indust ries. The specificat ion and profiles cont inue t o evolve as t he SI G develops new ways t o use t he Bluet oot h t echnology. The first product s wit h Bluet oot h wireless com m unicat ions arrived in 2000 led by developm ent t ools, m obile t elephones, audio headset s, not ebook com put ers, handheld com put ers and net work access point s. A great deal of int erest , t alent and energy has m arshaled around t his excit ing new t echnology. Unt il now m ost of t he inform at ion available about Bluet oot h wireless com m unicat ions has been from t he SI G's official web sit e ( ht t p: / / www.bluet oot h.com ) or from brief press art icles or newslet t ers. This book aim s t o be at once aut horit at ive and accessible. Besides discussing background, hist ory and pot ent ial fut ure developm ent s, Bluet oot h Revealed: The I nsider's Guide t o an Open Specificat ion for Global Wireless Com m unicat ions delivers pract ical explanat ions of t he specificat ion by people who helped t o develop it . I t is a broad discussion of t he t opic, cont aining inform at ion t hat should be of value t o indust ry pract it ioners, professionals, st udent s and any ot hers who are int erest ed in t his t opic. No m at t er what your part icular int erest is, Bluet oot h Revealed is int ended t o give you t he inform at ion you need t o becom e a " Bluet oot h I nsider."

2

Acknowledgements We already knew t hat developing t he Bluet oot h t echnology was a t rem endous undert aking, and we now have discovered t hat writ ing a book is a lot of work. The fun part is being able t o include a short list of people who support ed, encouraged or ot herwise aided in t he developm ent of t his book or of t he Bluet oot h t echnology t hat m akes t his book relevant . At t he risk of om it t ing t hose who deserve m ent ion, bot h aut hors acknowledge all of t he m em bers of t he Bluet oot h SI G who worked passionat ely and t irelessly as a t eam t o m ake t he t echnology possible, especially our Air and Soft ware Working Group colleagues who m ade a m aj or difference: Jon I nouye of I nt el; Thom as Muller, St ephane Bouet and Riku Met t älä of Nokia; Johannes Elg, Jaap Haart sen and Tobias Melin of Ericsson; Dale Farnswort h of Mot orola; Shaun Ast arabadi of Toshiba; Paul Moran and Ned Plasson of 3Com ; and m ost of all our I BM colleagues around t he globe who worked t o advance t he Bluet oot h t echnology, m ost not ably our t eam m at es Pet er Lee, Mahm oud Naghshineh, Nat han Lee, Parviz Kerm ani, Brian Gaucher and Toru Aihara and form er I BM colleague Pravin Bhagwat . We are also indebt ed t o Bouet , Elg and Aihara- san, along wit h Gabriel Mont enegro of Sun Microsyst em s, for t heir exem plary and valuable t echnical review of t he book. We also acknowledge Mary Franz and her t eam at Prent ice Hall PTR, whose support , expert ise and responsiveness m ade it possible t o carry out t his proj ect . Brent Miller t hanks Sandeep Singhal for his experienced aut hor advice; his co- aut hor Chat schik Bisdikian, who wrot e all t he hard part s; his wife Laurie and sons Benj am in and Andrew for t heir encouragem ent and support ; and God who m akes t his and all t hings possible. Dr. Chat schik Bisdikian t hanks co- aut hor Brent for invit ing him t o cont ribut e t o t his proj ect and pat ient ly rewrit ing in plain English what he wrot e; his m anager Mahm oud Naghshineh for encouraging him ( rat her st rongly and persist ent ly) t o get involved wit h t he Bluet oot h wireless t echnology from t he out set ; and last but not least his wife Teresa and sons Eugene and Theodore for t heir uncondit ional encouragem ent and support t hrough long night s and weekends of working on t his proj ect .

Trademark List •

• • • • • • • •

• • • • •

•

Bluet oot h is a t radem ark owned by Telefonakt iebolaget L M Ericsson, Sweden and licensed t o prom ot ers and adopt ers of t he Bluet oot h Special I nt erest Group. Ericsson is t he t radem ark or regist ered t radem ark of Telefonakt iebolaget LM Ericsson. I nt el is a regist ered t radem ark of I nt el Corporat ion. Microsoft , Windows and Universal Plug and Play are t radem arks or regist ered t radem arks of Microsoft Corporat ion in t he Unit ed St at es and/ or ot her count ries. Mot orola is a regist ered t radem ark of Mot orola I ncorporat ed. I rDA is a regist ered t radem ark of t he I nfrared Dat a Associat ion. Linux is a regist ered t radem ark of Linus Torvalds. Sym bian is a t radem ark of Sym bian, Lt d. Jini is a regist ered t radem ark of Sun Microsyst em s I ncorporat ed in t he Unit ed St at es, ot her count ries, or bot h. Salut at ion is a regist ered t radem ark of t he Salut at ion Consort ium , I ncorporat ed. PUMATECH is a t radem ark or regist ered t radem ark of Pum a Technology, I ncorporat ed, also dba PUMATECH, I nc. Ext ended Syst em s is a t radem ark of Ext ended Syst em s I ncorporat ed. Hom eRF is a t radem ark of t he Hom eRF Working Group Hewlet t - Packard is a t radem ark or regist ered t radem ark of Hewlet t - Packard Com pany in t he Unit ed St at es and/ or ot her count ries. Philips is a t radem ark or regist ered t radem ark of Koninklij ke Philips Elect ronics N.V.

3

4

Part 1: Introduction to Bluetooth Wireless Communication This book begins wit h background inform at ion about Bluet oot h wireless com m unicat ion. The t echnology is described at t he highest level and it s origins and hist ory are explored, including t he st ory of how t his t echnology cam e t o be nam ed Bluet oot h. The Bluet oot h Special I nt erest Group is described from t he aut hors' own perspect ive as part icipat ing m em bers. Chapt er 1 cont ains a reader's guide for t he rem ainder of t he book. I n Chapt er 2 t he basics of wireless com m unicat ions are covered, including spread spect rum radio frequency com m unicat ions in t he 2.4 gigahert z spect rum and infrared com m unicat ions, bot h of which influence t he Bluet oot h specificat ion. The fundam ent al principles of Bluet oot h com m unicat ion, including m ast er and slave roles, baseband m odes and com m unicat ion t opology are present ed. Chapt er 3 describes m ost of t he well- known usage m odels in which Bluet oot h wireless com m unicat ion can be em ployed. I n t hese usage scenarios t he end user's viewpoint and derived benefit s are em phasized. Finally Chapt er 4 provides an int roduct ion t o t he Bluet oot h core specificat ion and profiles t hat are explored in det ail in Part s 2 and 3 of t he book, respect ively. Part 1 is designed t o aid readers who are not already fam iliar wit h Bluet oot h wireless com m unicat ion in underst anding t he fundam ent als of t he t echnology and how t hat t echnology cam e t o be. At t he sam e t im e, readers already fam iliar wit h Bluet oot h wireless com m unicat ion m ay discover new inform at ion or perspect ives t hat will furt her t heir underst anding of t his im port ant new t echnology.

Chapter 1. What Is Bluetooth? The t erm Bluet oot h™[ 1] refers t o an open specificat ion for a t echnology t o enable short - range wireless voice and dat a com m unicat ions anywhere in t he world. This sim ple and st raight forward descript ion of t he Bluet oot h t echnology [ 2] includes several point s t hat are key t o it s underst anding: [1] Bluetooth is a trademark owned by Telefonaktiebolaget L M Ericsson, Sweden and licensed to promoters and adopters of the Bluetooth Special Interest Group.

[2]

The Bluetooth Brand Book contains guidelines for the use of the term Bluetooth. To be consistent with those guidelines, we will henceforth use the term as an adjective, not as a standalone noun.

Ope n spe cifica t ion : The Bluet oot h Special I nt erest Group ( SI G) has produced a specificat ion for Bluet oot h wireless com m unicat ion t hat is publicly available and royalt y free. To help fost er widespread accept ance of t he t echnology, a t ruly open specificat ion has been a fundam ent al obj ect ive of t he SI G since it s form at ion. Sh or t - r a n ge w ir e le ss: There are m any inst ances of short - range digit al com m unicat ion am ong com put ing and com m unicat ions devices; t oday m uch of t hat com m unicat ion t akes place over cables. These cables connect t o a m ult it ude of devices using a wide variet y of connect ors wit h m any com binat ions of shapes, sizes and num ber of pins; t his plet hora of cables can becom e quit e burdensom e t o users. Wit h Bluet oot h t echnology, t hese devices can com m unicat e wit hout wires over a single air- int erface, using radio waves t o t ransm it and receive dat a. Bluet oot h wireless t echnology is specifically designed for short - range ( nom inally 10 m et ers) com m unicat ions; one

5

result of t his design is very low power consum pt ion, m aking t he t echnology well suit ed for use wit h sm all, port able personal devices t hat t ypically are powered by bat t eries. Voice a n d da t a : Tradit ional lines bet ween com put ing and com m unicat ions environm ent s are cont inually becom ing less dist inct . Voice is now com m only t ransm it t ed and st ored in digit al form at s. Voice appliances such as m obile t elephones are also used for dat a applicat ions such as inform at ion access or browsing. Through voice recognit ion, com put ers can be cont rolled by voice, and t hrough voice synt hesis, com put ers can produce audio out put in addit ion t o visual out put . Som e wireless com m unicat ion t echnologies are designed t o carry only voice while ot hers handle only dat a t raffic. Bluet oot h wireless com m unicat ion m akes provisions for bot h voice and dat a, and t hus it is an ideal t echnology for unifying t hese worlds by enabling all sort s of devices t o com m unicat e using eit her or bot h of t hese cont ent t ypes. An yw he r e in t h e w or ld: The t elecom m unicat ions indust ry is highly regulat ed in m any part s of t he world. Telephone syst em s, for exam ple, m ust com ply wit h m any governm ent al rest rict ions, and t elephony st andards vary by count ry. Many form s of wireless com m unicat ions are also regulat ed; radio frequency spect rum usage oft en requires a license wit h st rict t ransm ission power obligat ions. However, som e port ions of t he available radio frequency spect rum m ay be used wit hout license, and Bluet oot h wireless com m unicat ions operat e wit hin a chosen frequency spect rum t hat is unlicensed t hroughout t he world ( wit h cert ain lim it at ions and rest rict ions t hat are discussed lat er in t he book) . Thus devices t hat em ploy Bluet oot h wireless com m unicat ion can be used unm odified, no m at t er where a person m ight be. The Bluet oot h short - range wireless t echnology is ideally suit ed for replacing t he m any cables t hat are associat ed wit h t oday's pervasive devices. The Bluet oot h specificat ion ( [ BTSI G99] , hereaft er referred t o as t he specificat ion) explicit ly defines a m eans for wireless t ransport s t o replace serial cables, such as t hose used wit h m odem s, digit al cam eras and personal digit al assist ant s; t he t echnology could also be used t o replace ot her cables, such as t hose associat ed wit h com put er peripherals ( including print ers, scanners, keyboards, m ice and ot hers) . Moreover, wireless connect ivit y am ong a plet hora of fixed and m obile devices can enable m any ot her new and excit ing usage scenarios beyond sim ple cable replacem ent . I n t his book we explore various applicat ions of t he t echnology. I m port ant charact erist ics and applicat ions of Bluet oot h wireless com m unicat ions are exam ined in det ail in t his book. The Bluet oot h specificat ion is explained in easy- t o- underst and t erm s wit h t he benefit of t he aut hors' experiences gained while part icipat ing in it s developm ent . I f Bluet oot h wireless t echnology succeeds in t he m arket place t o t he ext ent predict ed by m any analyst s, it has t he pot ent ial t o change people's lives and t he way t hat people t hink about and int eract wit h com put ing and com m unicat ion devices. Underst anding t his em erging t echnology can benefit not only indust ry professionals but also consum ers who can use and obt ain value from it .

The Bluetooth Special Interest Group As described above, Bluet oot h wireless com m unicat ion is em bodied as a t echnology specificat ion. This specificat ion is a result of t he cooperat ion of m any com panies wit hin an organizat ion called t he Bluet oot h Special I nt erest Group, or SI G. There is no " Bluet oot h headquart ers" nor is t here any " Bluet oot h corporat ion" nor any sort of legally incorporat ed ent it y. The SI G is governed by legal agreem ent s am ong t he m em ber part ies but it is not a com pany unt o it self. The SI G should not be const rued as a form al st andards body; rat her it is an organizat ion chart ered t o define and prom ot e t he t echnology. I n fulfilling t his chart er t he SI G is dependent upon t he cont ribut ions and part icipat ion of it s m em ber com panies. Clearly a m aj or t ask of t he SI G has been t o develop t he specificat ion, but ot her SI G act ivit ies include j oint work wit h ot her consort ia and st andards and regulat ory bodies, educat ional and prom ot ional event s such as developers conferences and t he definit ion of a t est ing and cert ificat ion process.

6

Technology and SIG Origins Bluet oot h wireless t echnology was conceived by engineers at Swedish t elecom m unicat ions m anufact urer Telefonakt iebolaget LM Ericsson ( hereaft er, Ericsson) who realized t he pot ent ial of global short - range wireless com m unicat ions. I n 1994 Ericsson had begun a proj ect t o st udy t he feasibilit y of a low- power and low- cost radio int erface t o elim inat e cables bet ween m obile phones and t heir accessories. I n t oday's com put ing and com m unicat ions indust ries, propriet ary new t echnologies rarely succeed; cust om ers clearly prefer t o purchase and deploy t echnologies based upon indust ry st andards. By creat ing a level playing field, st andards give cust om ers great er freedom t o choose from am ong com pet ing plat form s and solut ions, t o prot ect t heir invest m ent s as t echnologies evolve and t o leverage ( and in som e cases, also influence) m ult icom pany skills and organizat ions devot ed t o developing t he st andards. I n t his indust ry environm ent , t he Ericsson invent ors underst ood t hat t he t echnology was m ore likely t o be widely accept ed, and t hus could be m ore powerful, if it was adopt ed and refined by an indust ry group t hat could produce an open, com m on specificat ion. I n early 1998, leading com panies in t he com put ing and t elecom m unicat ion indust ries form ed t he Bluet oot h SI G t o focus on developing exact ly such an open specificat ion. The founding com panies of t he SI G are Ericsson, I nt el Corporat ion, I nt ernat ional Business Machines Corporat ion ( I BM) , Nokia Corporat ion and Toshiba Corporat ion. These com panies form ed t he original core group ( known as prom ot er com panies) of t he SI G. The SI G was publicly announced in May 1998 wit h a chart er t o produce an open specificat ion for hardware and soft ware t hat would prom ot e int eroperable, cross- plat form im plem ent at ions for all kinds of devices. While open st andards can be quit e advant ageous, one pot ent ial disadvant age of st andards bodies, consort ia, special int erest groups and sim ilar organizat ions is t hat t hey t end t oward inherent inefficiencies as com pared t o single- com pany effort s. Wit hin a single com pany t here is oft en one overriding obj ect ive for developing new t echnology; in a m ult i- com pany effort each part icipant m ay have different , perhaps even com pet ing goals. Even wit h m odern ways t o exchange inform at ion, such as elect ronic m ail, group int eract ions are st ill likely t o be m ore efficient wit hin a single organizat ion t han t hroughout a group com posed of m any organizat ions ( especially when t hose organizat ions are geographically diverse, as is t he case for t he m em bers of t he SI G—t elephone calls, for exam ple, have t o t ake int o account t he fact t hat t he people involved reside in t im e zones wit h lit t le or no overlap of t ypical working [ or even waking] hours) . To overcom e som e of t hese pot ent ial drawbacks, t he SI G int ent ionally was creat ed wit h a sm all num ber of com panies com m it t ed t o t he rapid developm ent of t he specificat ion who were willing t o expend t he resources necessary t o accom plish t his.

SIG Progression As t he specificat ion evolved and awareness of t he t echnology and t he SI G increased, m any ot her com panies j oined t he SI G as adopt ers; adopt ers are ent it led t o a royalt y- free license t o produce product s wit h Bluet oot h wireless com m unicat ion based upon t he specificat ion and can receive and com m ent upon early versions of SI G publicat ions. Today t here are over 1,800 adopt er m em bers of t he SI G, represent ing academ ia and indust ries such as consum er elect ronics, aut om ot ive, silicon m anufact uring, consult ing, t elecom m unicat ions and m any ot hers. The original SI G's obj ect ive was t o develop, as rapidly as possible, an open specificat ion t hat was sufficient ly com plet e t o enable im plem ent at ions. By carefully organizing t he SI G and m aking use of frequent in- person m eet ings supplem ent ed by even m ore frequent conference calls and e- m ail exchanges, t he SI G produced a t horough specificat ion ( t oget her, t he volum e 1 core specificat ion and volum e 2 profiles num ber over 1,500 pages) in about one and one- half years ( version 1.0 of t he specificat ion, including profiles, was published in July 1999) .

7

The SI G organized it self int o several working groups, each wit h a focus on a specific part of t he t echnology or on som e support ing service. These working groups included: • • • •

• •

t he air int erface working group, which focused on t he radio and baseband layers; t he soft ware working group, which developed t he specificat ion for t he prot ocol st ack; t he int eroperabilit y working group, which focused on profiles; t he com pliance working group, which defined t he t est ing, com pliance and cert ificat ion process; t he legal working group, which m anaged t he legal affairs of t he SI G such as m em bership and int ellect ual propert y agreem ent s; and t he m arket ing working group, which prom ot ed t he t echnology and helped t o generat e t he m arket ing requirem ent s t hat t he specificat ion was t o address.

Som e of t he larger working groups, such as t he soft ware working group, were furt her divided int o t ask forces focusing on a part icular layer of t he Bluet oot h prot ocol st ack. Coordinat ing all of t hese working groups and governing t he overall SI G was a program m anagem ent com m it t ee com posed of vot ing represent at ives from each of t he prom ot er com panies. During t he one and one- half years t hat t he SI G was developing t he specificat ion, working groups and t ask forces m et and conduct ed t heir business bot h t oget her and separat ely. Full working group ( and som et im es com plet e SI G) m eet ings were held every few weeks, oft en host ed by prom ot er com panies in locat ions where m any of t heir involved personnel worked—t hese included Ericsson's Lund, Sweden facilit y; I nt el's Chandler, Arizona soft ware laborat ory; I BM's sit es in Research Triangle Park, Nort h Carolina and Hawt horne, New York; and Nokia's Tam pere, Finland locat ion. Most working groups and t ask forces also held weekly conference calls. I n addit ion, em ail dist ribut ion list s were used liberally and in fact were a prim ary m et hod for conduct ing working group business. Because of t he geographic diversit y of t he people involved, it was difficult t o find m ut ually convenient t im es for frequent voice conversat ions; [ 3] t hus elect ronic m ail quickly becam e a convenient and heavily used m eans of com m unicat ion ( in m any respect s it allowed specificat ion developm ent around t he clock) . I ndeed, t he official rat ificat ion of t he final versions of t he specificat ion, profiles and errat a was conduct ed using t he e- m ail reflect ors. [3] When it was 9:00 a.m. on the west coast of the United States, where many involved parties worked and lived, it often (depending upon daylight-saving time observance) was 7:00 p.m. in Finland and 2:00 a.m. the following morning in Japan).

I n Decem ber 1999, four new prom ot er com panies ( 3Com Corporat ion, Lucent Technologies I nc., Microsoft Corporat ion and Mot orola, I nc., som e of whom had m ade cont ribut ions t o t he original specificat ion as adopt er com panies) j oined t he SI G. The group rem ains very act ive t oday in m aint aining t he exist ing docum ent at ion and in creat ing enhancem ent s t o t he specificat ion, along wit h new profiles. This work is discussed in furt her det ail in Part 4 of t his book. I t easily can be seen t hat it t ook an enorm ous effort t o develop over 1,500 pages of com plex and det ailed inform at ion in j ust over a year's t im e. For m any in t he SI G t his becam e t heir full- t im e j ob or at least a prim ary responsibilit y. I ssues, bot h t echnical and non- t echnical, inevit ably arose and were handled t hrough discussion and vot ing when necessary, but in general t he developm ent and refinem ent of specificat ions and profiles progressed in an exem plary m anner. A spirit of cooperat ion, fost ered by t he com m on obj ect ive of producing an open specificat ion for t his im port ant new t echnology, usually carried t he day ( at least in t he aut hors' experience in t he soft ware and int eroperabilit y working groups) .

The Bluetooth Name and History Bluet oot h is not able in t he high- t echnology indust ry in several respect s, but in part icular it s nam e garners m uch at t ent ion. Most new indust ry init iat ives are known by a nam e which describes t heir

8

associat ed t echnology or it s applicat ion and oft en t hey quickly becom e known by an acronym describing t he full nam e. Why wasn't t he t echnology called, for exam ple, " Short - Range Wireless Radio," or SRWR, or som e ot her descript ive nam e? The answer lies in t he herit age ( and perhaps t he whim sy) of t he original invent ors. There are num erous hist ories and account s of t he Bluet oot h nam esake and how t hat nam e cam e t o be chosen; t he generally accept ed st ory and fact s are cit ed here. Harald Blåt and was King of Denm ark from approxim at ely A.D. 940 t o 985. During his reign King Harald is report ed t o have unit ed Denm ark and Norway and t o have brought Christ ianit y t o Scandinavia. Apparent ly " Blåt and" t ranslat es, at least loosely, t o " Blue Toot h." The origins of t his nam e are uncert ain, alt hough it was relat ively com m on during t his t im e for kings t o have a dist inguishing nam e ( som e hist ories say t hat t he nam e is at t ribut ed t o Harald's dark com plexion; som e account s even indicat e t hat King Harald was known for t eet h of a bluish hue result ing from his fondness for blueberries, alt hough t his is probably folklore) . For a t echnology wit h it s origins in Scandinavia, it seem ed appropriat e t o t he SI G founders t o nam e t he organizat ion t hat was int ended t o unify m ult inat ional com panies aft er a Scandinavian king who unit ed count ries. Thus was born t he Bluet oot h nam e, which init ially was an unofficial code nam e for t he proj ect but t oday has becom e t he t radem ark nam e ( see foot not e 1 on page 3) of t he t echnology and t he special int erest group. Figure 1.1 shows t he Bluet oot h logo, inspired by t he init ials " H B" for Harald Bluet oot h.

Figur e 1 .1 . The Blue t oot h logo, a t r a de m a r k ow n e d by Te le fon a k t ie bola ge t L M Er icsson , Sw e de n a n d lice n se d t o pr om ot e r s a n d a dopt e r s of t h e Blu e t oot h Spe cia l I n t e r e st Gr ou p.

Bluet oot h wireless com m unicat ion has engendered t rem endous int erest since t he SI G's form at ion was announced. Art icles in m any leading com put er- indust ry t rade press publicat ions and in quit e a few of t he m ainst ream m edia have appeared wit h som e frequency. Many analyst s such as t he Cahners I n- St at Group and t he Gart ner Group Dat aQuest now include Bluet oot h wireless com m unicat ions in t heir st udies and forecast s. Bet ween Novem ber 1998 and June 2000 at least nine m aj or Bluet oot h developers conferences were held in cit ies including At lant a, Tokyo, London, Am st erdam , Geneva, Los Angeles and Mont e Carlo. The SI G- sponsored conference in Decem ber 1999 in Los Angeles at t ract ed over 2,000 developers from diverse geographies and indust ries.

Reader's Guide to This Book This chapt er has int roduced t he Bluet oot h Special I nt erest Group, t he t echnology, it s chief charact erist ics and t he hist ory of it s developm ent . The rem aining chapt ers of Part 1 provide addit ional background int ended t o aid in underst anding t he t echnology and what it can do. Ch a pt e r 2 discusses wireless com m unicat ion t echnologies in general and t he Bluet oot h radio frequency wireless solut ion in part icular, including requirem ent s and design choices for use of t he

9

2.4- gigahert z spect rum , radio power consum pt ion, " m ast er/ slave" radio relat ionship, adapt ive audio range, " piconet " and " scat t ernet " t opologies and global radio use. Ch a pt e r 3 describes t he significance of developing usage m odels for Bluet oot h wireless com m unicat ion and how t hese usage m odels relat e t o Bluet oot h profiles. Each of t he usage m odels is described, focusing on t he benefit s and value for a product 's end user. Dist inct ions are drawn bet ween t hose usage m odels enabled wit h version 1.0 of t he specificat ion and t hose int ended for fut ure use. Ch a pt e r 4 briefly explains t he purpose, scope, st ruct ure and relat ionships of t he Bluet oot h specificat ion and profiles, serving as an int roduct ion t o Part s 2 and 3 where t hese t opics are covered in det ail. " Pa r t 2 : The Blu e t oot h Spe cifica t ion Ex a m in e d" int roduces t he Bluet oot h prot ocol st ack in Chapt er 5, part it ioning t he st ack int o t ransport , m iddleware and applicat ion prot ocol groups. I n Ch a pt e r 5 t he relat ionships am ong t he various layers of t he st ack are exam ined, and each of t he rem aining chapt ers in Part 2 t hen covers one or m ore of t hese layers in det ail. The int ent is not j ust t o reit erat e inform at ion already available in t he specificat ion but rat her t o provide inform at ion t hat supplem ent s t he specificat ion and aids in it s underst anding. Wherever possible we include inform at ion about t he hist ory, rat ionale and j ust ificat ion of t he t echnical cont ent s of t he specificat ion based upon our part icipat ion in it s developm ent . Ch a pt e r 6 describes t he radio hardware, link cont roller, baseband, and link m anager layers of t he prot ocol st ack. Toget her t hese layers com prise t he lower layers of t he t ransport group of t he prot ocol st ack. Topics covered include t he m ot ivat ion and design t radeoffs behind t he radio and baseband specificat ions, including t he choice of t he 2.4 gigahert z I SM frequency band; t he reasons behind som e of t he radio and baseband param et ers; t he choice of t he m ast er/ slave baseband m odel; t he basis for t he piconet and scat t ernet t opologies; and t he m ot ivat ion and design t radeoffs for securit y feat ures such as pairing and encrypt ion. Ch a pt e r 7 describes t he logical link cont rol and adapt at ion prot ocol ( L2CAP) and host cont roller int erface ( HCI ) layers of t he prot ocol st ack. We call t hese t he upper layers of t he t ransport group of t he prot ocol st ack, and t hey form t he basis for t he rem ainder of t he soft ware st ack, including any new prot ocols t hat m ay be int roduced in t he fut ure. Topics covered include t he m ot ivat ion and design t radeoffs leading t o t he developm ent of t he HCI and t he sit uat ions in which t his layer is relevant ; issues wit h flow cont rol and it s archit ect ural placem ent wit hin t he st ack; and how higher- layer elem ent s of t he st ack can use and benefit from L2CAP. Ch a pt e r 8 present s t he RFCOMM and service discovery prot ocol ( SDP) layers of t he prot ocol st ack. These are m iddleware layers t hat provide abst ract ions in t he form of logical int erfaces and m essage t ransact ions t hat can be used by applicat ion layers. Topics covered include t he m ot ivat ion and design t radeoffs for specifying a logical serial int erface and it s result ing benefit s; how legacy applicat ions could use Bluet oot h wireless com m unicat ion via RFCOMM; t he m ot ivat ion and design t radeoffs for specifying a new discovery prot ocol; and how SDP m aps t o ot her discovery prot ocols. Ch a pt e r 9 describes t he I rDA® I nt eroperabilit y layers of t he prot ocol st ack. These are layers of t he prot ocol st ack t hat incorporat e prot ocols and obj ect form at s specified by t he I nfrared Dat a Associat ion ( I rDA) int o t he Bluet oot h specificat ion. Topics covered include t he m ot ivat ion and design t radeoffs for reusing exist ing I rDA prot ocols and obj ect form at s; how exist ing I rDA applicat ions could use Bluet oot h wireless com m unicat ions; and sim ilarit ies and differences bet ween I rDA and Bluet oot h wireless com m unicat ions. Ch a pt e r 1 0 discusses t he t elephony cont rol specificat ion ( TCS) layer of t he prot ocol st ack and also describes how voice and audio com m unicat ions are m anaged. Toget her audio and TCS

10

provide full t elephony support for bot h voice and dat a calls. Topics covered include t he m ot ivat ion and design t radeoffs for specifying separat e voice and dat a channels; reasons for t he select ion of voice encoding t echniques, including t radeoffs of qualit y and efficiency; and alt ernat ive form s of t elephony cont rol prot ocols and why TCS was chosen. I n " Pa r t 3 . Th e Blue t oot h Pr ofile s Ex a m ine d" we look int o volum e 2 of t he Bluet oot h specificat ion, com m only known as t he Bluet oot h profiles, in t he sam e m anner in which we covered t he core specificat ion in Part 2. Cha pt e r 1 1 exam ines t he m ot ivat ion for, developm ent of and relat ionships am ong t he various profiles, which define how t o use t he prot ocol st ack t o achieve int eroperable solut ions. Each of t he rem aining chapt ers in Part 3 t hen covers one or m ore of t hese profiles in det ail. Just as in Part 2, t he int ent of t hese chapt ers is not sim ply t o reit erat e inform at ion already available in t he profile specificat ion but rat her t o provide inform at ion t o supplem ent t he specificat ion and aid in it s underst anding. Ch a pt e r 1 2 describes t he generic access profile ( GAP) and t he service discovery applicat ion profile ( SDAP) . These profiles define fundam ent al principles used t o est ablish connect ions am ong devices wit h Bluet oot h wireless com m unicat ion capabilit y and provide a basis upon which t he rem aining profiles are built . Topics covered include t he m ot ivat ion and design t radeoffs for securit y feat ures such as pairing and encrypt ion; t he various possibilit ies for devices t o be discovered; and how applicat ions could access and m ake use of t he service discovery prot ocol for service locat ion and browsing. Ch a pt e r 1 3 discusses t he t elephony class of profiles, including cordless t elephony, int ercom and headset . These profiles define various ways t o use voice com m unicat ion and call cont rol for t elephony applicat ions. Topics covered include t he m ot ivat ion and design t radeoffs for select ion of t he version 1.0 t elephony profiles; 10- m et er versus 100- m et er radio range wit h respect t o t he int ercom profile; and current and fut ure applicat ions for voice headset s developed according t o t he headset profile. Ch a pt e r 1 4 present s t he serial port - based class of profiles, including generic obj ect exchange, obj ect push, file t ransfer and synchronizat ion in addit ion t o t he com m on serial port profile it self. These profiles all define ways t o use t he RFCOMM virt ual serial port t o exchange and synchronize dat a bet ween t wo peer devices. Topics covered include t he serial port profile " fam ily t ree" ; configurat ion of t he serial port profile and t he relevance of t ypical serial param et ers in Bluet oot h wireless com m unicat ions; why t he dist inct ion bet ween obj ect exchange, obj ect push and file t ransfer is im port ant ; and current and fut ure possibilit ies for dat a synchronizat ion. Ch a pt e r 1 5 describes t he net working class of profiles t hat includes dial- up net working, LAN access and fax. These profiles all deal wit h som e variat ion on dat a net working bet ween t wo or m ore peer devices. Topics covered include lim it at ions of Bluet oot h wireless com m unicat ions relat ive t o som e fax requirem ent s; t he relevance and value of audio feedback for dial- up net working; and t he m any possibilit ies for net working wit h Bluet oot h wireless com m unicat ions and why LAN Access using PPP was chosen for version 1.0. " Pa r t 4 . The Fu t u r e of Blu e t oot h W ir e le ss Com m u n ica t ion s" looks at where t he t echnology is headed. Ch a pt e r 1 6 discusses fut ure possibilit ies for t he t echnology, including t hose t hat t he SI G is current ly developing: aut om ot ive, im aging, print ing, ext ended service discovery, associat ion wit h t he I EEE 802.15 st andards organizat ion and ot hers. This chapt er discusses how new usage cases m ight be realized using Bluet oot h wireless com m unicat ion and how indust ry innovat ors m ight go about developing new Bluet oot h wireless com m unicat ion solut ions. I n addit ion, t he product landscape for Bluet oot h wireless t echnology is explored, including t he current and proj ect ed m arket place. Ch a pt e r 1 7 sum m arizes t he book and offers concluding rem arks about t he fut ure of Bluet oot h wireless com m unicat ion, including a short discussion of int eroperabilit y and t he opport unit ies t hat t he t echnology present s.

11

Chapter 2. Technology Basics Com m unicat ion can t ake m any form s—audio, visual, writ t en, elect ronic and so on. I n t he realm of elect ronics, analog and digit al com m unicat ions are so pervasive in m odern societ y t hat t hey are largely t aken for grant ed. The exchange of dat a using t hese form s of com m unicat ion has led t o t he use of t erm s such as " t he inform at ion indust ry" and " t he inform at ion age." From t elephones t o com put ers t o t elevisions, com m unicat ion in m any respect s " m akes t he world go around." Bluet oot h wireless t echnology is one form of elect ronic com m unicat ion, and in t his chapt er we exam ine som e of it s fundam ent al and specific charact erist ics, including relat ionships t o ot her form s of com m unicat ion. We begin wit h a brief general discussion of wireless com m unicat ions and t hen progress t hrough m ore specific form s relevant t o t he Bluet oot h t echnology. There are m any ot her t ypes of wireless com m unicat ion; our int ent here is t o t ouch upon t hose t hat provide background for t he Bluet oot h t echnology rat her t han t o provide a prim er on wireless t echnologies in general.

Wired and Wireless Communications A great deal of dat a is carried over wired net works—m any t elephones, coaxial cable syst em s, local area net works and part s of t he I nt ernet com m unicat e via wires and cables. Many t elevisions are connect ed t o cable syst em s, m ost net worked com put ers are connect ed t o t elephone lines or wired net works such as Et hernet net works, and even cordless and m obile t elephones rely on wired " landline" t elephone syst em s t o carry and rout e calls bet ween endpoint s. Com m unicat ing wit hout wires is not a new concept . Broadcast radio and t elevision are t wo com m on exam ples of wireless com m unicat ions; ot hers include sat ellit es, cordless and cellular t elephones and rem ot ely cont rolled t elevisions, garage door openers and aut om obile door locks. While m ost of t hese exam ples em ploy com m unicat ion via radio waves, t he use of infrared, a nonvisible spect rum of light , is also relat ively com m on. Bluet oot h wireless com m unicat ion em ploys radio frequency ( or RF) t echnology, using radio waves t o com m unicat e t hrough t he air in a m anner fundam ent ally sim ilar t o broadcast radio or t elevision.

Radio Frequency Wireless Communications RF t echnologies em ploy t ransm it t ers and receivers t uned t o produce and consum e, respect ively, radio waves of a given frequency range. The t ransm it t er's power and t he receiver's sensit ivit y help t o det erm ine t he dist ance over which t hey can com m unicat e. High t ransm ission power out put is used for long- range com m unicat ions such as broadcast t elevision while short - range com m unicat ions generally require m uch less power; t hus t echnologies t hat are designed t o com m unicat e across only a few m et ers could be em ployed in sm all, m obile bat t ery powered devices. Anot her charact erist ic t hat is relevant for com m unicat ion applicat ions is t he abilit y of radio waves t o penet rat e m any obj ect s. Obst acles reflect light waves used in t echnologies such as infrared, but radio waves used in RF t echnologies in general can ( wit h cert ain lim it at ions) penet rat e m any obst acles ( alt hough in som e cases radio waves can diffract or go around obj ect s t oo) . Thus RF t echnologies can perm eat e m any obst acles such as clot hing, bodies, walls, doors and t he like. This m eans t hat t here is no requirem ent for a " line of sight " bet ween t he t ransm it t er and t he receiver. RF t echnologies use frequency m odulat ion t o generat e radio waves wit hin a cert ain frequency spect rum , which encode inform at ion and can be int ercept ed by receivers t uned t o t he corresponding frequency. FM radio broadcast s, for exam ple, operat e in t he 88 m egahert z ( MHz) t o 108 MHz frequency spect rum ; som e cordless t elephones operat e in t he 900 MHz frequency spect rum ; Bluet oot h wireless com m unicat ions and ot her t echnologies operat e in t he 2.4

12

gigahert z ( or GHz; one gigahert z equals one billion cycles per second) spect rum . Because t he usable radio frequency space is finit e, m ost governm ent s regulat e it s use, part it ioning frequency ranges and grant ing licenses t o t ransm it at t hose frequencies at specified power levels. I n t he Unit ed St at es, for exam ple, a federal license is required t o t ransm it in t he FM radio frequency spect rum except at ext rem ely low power levels t hat lim it t he range t o no m ore t han about 30 m et ers. Som e frequencies are reserved for use wit hout a license under cert ain condit ions. For exam ple, in t he Unit ed St at es unlicensed operat ion is perm it t ed, wit h som e rest rict ions, in t he 900 MHz and 2.4 GHz frequency ranges ( t he lat t er being where Bluet oot h wireless com m unicat ion operat es) . I n fact , t hrough m ult inat ional agreem ent , t he 2.4 GHz spect rum requires no license for it s use anywhere in t he world. [ 1] The SI G t oget her wit h ot her organizat ions such as t he I EEE 802.11 st andards body is working wit h regulat ory aut horit ies in som e count ries t o pursue harm onizat ion of t he frequency assignm ent s for unlicensed use wit hin t he 2.4 GHz spect rum and of t he approval process for wireless com m unicat ions. I n general t he chosen frequency spect rum can be used globally wit hout license so long as t he rules for operat ing wit hin t his spect rum are followed. [1]

In some countries there are restrictions and only part of this spectrum is available for unlicensed use; these restrictions are discussed elsewhere in the book, notably in Chapter 6.

RF Communications in the 2.4 GHz Frequency Spectrum While t he 2.4 GHz spect rum is globally unlicensed, t here are regulat ory requirem ent s and ot her considerat ions for it s use. These include: • • • •

The spect rum is divided int o 79 channels ( alt hough in som e count ries, not ably Spain and France, only 23 channels were available for use in t he year 2000. Japan began using all 79 channels in 2000) . Bandwidt h is lim it ed t o 1 MHz per channel. Frequency hopping spread spect rum com m unicat ions ( described below) m ust be em ployed. I nt erference m ust be ant icipat ed and appropriat ely handled.

Ot her RF com m unicat ions t echnologies also use t his spect rum ; not able am ong t hem are Hom eRF™ ( an open indust ry specificat ion for RF com m unicat ions in hom e environm ent s; see ht t p: / / www.hom erf.org) and t he I nst it ut e of Elect rical and Elect ronics Engineers ( I EEE) 802.11 specificat ion for wireless local area net works ( see ht t p: / / www.ieee.org) . Microwave ovens also operat e wit hin t his frequency range. Because t his spect rum is unlicensed, new uses for it are t o be expect ed ( for exam ple, a new generat ion of cordless t elephones also uses t he 2.4 GHz frequency) and as t he spect rum becom es m ore widely used, radio int erference is m ore likely. Thus t he requirem ent t o ant icipat e and address int erference in t he 2.4 GHz range is im port ant for all t echnologies t hat operat e in it . Each t echnology using t his spect rum has m ade design choices wit hin t he spect rum 's const raint s t hat opt im ize t hat t echnology for part icular applicat ions or dom ains. Bluet oot h wireless com m unicat ion is designed t o t ake m axim um advant age of t he available channel bandwidt h and t o m inim ize RF int erference and it s effect s while operat ing at very low power.

Spread Spectrum RF Communications Wit hin RF com m unicat ions, spread spect rum refers t o dividing t he available spect rum based upon frequency, t im e, a coding schem e or som e ot her m et hod. Messages t o be sent are t hen divided int o various part s ( packet s) t hat are t ransm it t ed across t he divided spect rum . Frequency division spread spect rum ( or frequency hopping) , which is t he m et hod em ployed wit h Bluet oot h wireless com m unicat ion, divides t he spect rum int o different frequencies, or channels. [ 2] A single m essage packet is t ransm it t ed on a select ed channel, t hen t he radio select s a new channel ( a process

13

called hopping t o a new frequency) t o t ransm it t he next packet , and t he process repeat s, t hereby spreading t he m essage across t he available frequency spect rum . Each t echnology specifies it s own m et hod for est ablishing t he frequency hopping pat t ern. Obviously t he receiver( s) of t he m essage m ust know t he hopping pat t ern t o t une t o t he correct channels in succession t o receive each packet and assem ble t he com plet e m essage. This process is called frequency hopping spread spect rum , or FHSS. [2] Contrast frequency hopping spread spectrum with direct sequence spread spectrum, which is not examined here. Direct sequence is another form of spread spectrum RF communication employed in other technologies such as wireless LANs and is outside the scope of this book.

FHSS int roduces addit ional com plexit y as com pared t o using a single st at ically select ed frequency, yet it also supplies som e benefit s. First , RF int erference can be reduced since all radios hop ( oft en random ly or at least pseudorandom ly, and oft en rapidly) from one frequency t o anot her. When all of t he part icipant s in t he spect rum em ploy FHSS, int erference caused by colliding t ransm issions on t he sam e frequency is less likely t han it would be if each radio used a single channel for a long durat ion. I n addit ion, when collisions do occur, t heir effect s are lessened, since only a single packet is lost and t hat packet could be ret ransm it t ed at a new frequency, where again it is less likely t o encount er int erference. Second, FHSS can provide a degree of securit y for com m unicat ions in t hat only a receiver t hat knows t he frequency hopping pat t ern can receive and assem ble all t he packet s of a m essage. Because t he hopping pat t ern for a given spect rum could be const ruct ed in a num ber of ways, it could be difficult t o deduce and follow an unknown hopping pat t ern, especially when t he spect rum is heavily ut ilized wit h m any radios. Thus FHSS can be em ployed t o hinder eavesdropping. I n fact , t his lat t er charact erist ic led t o t he invent ion of FHSS, usually at t ribut ed t o George Ant heil and Hedy Lam arr ( t he lat t er is m ore fam ous as an Am erican act ress) . Their 1942 pat ent of t he frequency hopping concept was m ot ivat ed by an at t em pt t o find a " secret com m unicat ion syst em " using radio waves t o cont rol t orpedoes during World War I I . [ 3] [3]

The complete story of this invention is fascinating but is outside the scope of this book. Interested readers are referred to, for example, [IAL99] or other accounts easily found via World Wide Web search engines. Furthermore, any rationale or implications of the choice of naming the Bluetooth technology after a Danish king rather than an American actress are not explored here.

As previously not ed, t he use of spread spect rum is required in t he 2.4 GHz range, largely t o m inim ize int erference problem s because t he spect rum is unlicensed. The design for Bluet oot h wireless com m unicat ion em ploys relat ively rapid frequency hopping ( nom inally 1,600 t im es per second) and is described m ore fully below and in Chapt er 6.

Infrared Wireless Communication RF is not t he only form of wireless com m unicat ion. I nfrared t echnology is used wit h devices such as not ebook com put ers, personal digit al assist ant s and elect ronic rem ot e cont rols. I nfrared wireless com m unicat ion m akes use of t he invisible spect rum of light j ust beyond red in t he visible spect rum . I n part icular, one st andard m et hod for infrared com m unicat ion is specified by t he I nfrared Dat a Associat ion ( I rDA; see ht t p: / / www.irda.org) ; t his m et hod is com m only used wit h m obile phones and not ebook and handheld com put ers. I rDA t echnology is relevant when discussing Bluet oot h t echnology because I rDA is also designed for short - range, low- power unlicensed com m unicat ions. I rDA also defines a physical layer and a soft ware prot ocol st ack designed t o prom ot e int eroperable com m unicat ions, as does t he Bluet oot h specificat ion. Despit e t he differences bet ween I rDA and Bluet oot h wireless com m unicat ions, such as dat a t ransm ission speeds and signal pat hs ( infrared largely requires line- of- sight pat hs while RF can penet rat e m any obj ect s) , t he sim ilarit ies are such t hat t he SI G worked wit h t he I rDA in

14

developing t he specificat ion. Because t here is overlap in t he applicat ion spaces of I rDA and Bluet oot h wireless com m unicat ions, t he specificat ion includes an I rDA int eroperabilit y layer in which som e prot ocols defined by I rDA are incorporat ed. This helps t o prom ot e int eroperabilit y am ong wireless applicat ions no m at t er which com m unicat ions t ransport is being used. I rDA int eroperabilit y in t he Bluet oot h specificat ion is furt her det ailed in Chapt er 9.

The Bluetooth RF Communications Solution The preceding discussion form s t he basis for underst anding t he Bluet oot h design, which: • • •

in t he lower layers cent ers around wireless RF com m unicat ions in t he 2.4 GHz spect rum ; is opt im ized for short - range com m unicat ion, low power consum pt ion and low cost ; and in t he higher layers reuses t ransport and applicat ion prot ocols already developed for sim ilar dom ains such as t hose used wit h infrared wireless com m unicat ion.

The result is a wireless com m unicat ion t echnology t hat is especially appropriat e for cable replacem ent and for use wit h port able devices in pervasive com put ing applicat ions. Som e of t he fundam ent al principles for Bluet oot h RF com m unicat ion are described here; det ails of t he radio and baseband operat ion are given in Chapt er 6.

Master and Slave Roles At t he baseband level, when t wo devices est ablish a Bluet oot h link, one act s in t he role of m ast er and t he ot her in t he role of slave. The specificat ion perm it s any Bluet oot h radio t o assum e eit her role, and a device m ay act as a m ast er for one com m unicat ion link and as a slave for anot her link. [ 4] The role of m ast er does not im ply special privileges or aut horit y; inst ead it governs t he synchronizat ion of t he FHSS com m unicat ions bet ween t he devices. The m ast er device det erm ines t he frequency hopping pat t ern ( based upon it s Bluet oot h device address) and t he phase for t he hopping sequence ( based upon it s clock) . All slaves com m unicat ing wit h a given m ast er hop t oget her in unison wit h t he m ast er. The m ast er role generally is assum ed by t he device t hat init iat es t he com m unicat ion. [ 5] Part 2 of t his book provides m ore det ails about est ablishing com m unicat ions links. [4] Some devices might be configured to act in only one role, but most Bluetooth devices are expected to include radios that can assume either role, depending upon the usage case being performed.

[5] The device initiating communication assumes the master role at the outset, although the master and slave roles can be switched, as detailed in Chapter 6.

A given m ast er m ay com m unicat e wit h m ult iple slaves—up t o 7 act ive slaves and up t o 255 parked slaves[ 6] ( act ive and parked slaves are described m ore fully below) ; all slaves com m unicat ing wit h a single m ast er form what t he specificat ion calls a piconet ( also described m ore fully below) . There can be only one m ast er in a single piconet . [6] Actually more than 255 parked slaves are possible. The Bluetooth specification defines "direct" addressing for up to 255 parked slaves via a parked slave address but also permits "indirect" addressing of parked slaves by their specific Bluetooth device address, thus effectively allowing any number of parked slaves, although from a practical perspective it would be unusual to have more than 256 devices in a single piconet. This topic is explored more fully in Chapter 6.

The m ast er- slave relat ionship is necessary in Bluet oot h low level com m unicat ions but in general devices operat e as peers. When one device est ablishes a point - t o- point link wit h anot her device, t he role t hat each device assum es ( m ast er or slave) is oft en unim port ant and is irrelevant t o higher- level prot ocols and t o t he user of t he device. I n som e usage scenarios it m ay be advant ageous or even necessary for a given device t o assum e a part icular role, but in m any cases it is not crit ical t o est ablish a single specific role for each device; som e scenarios work

15

equally well wit h device roles reversed. I t is im port ant t o underst and t he m ast er- slave relat ionship for low- level com m unicat ions while at t he sam e t im e underst anding t hat in general devices operat e as peers t o each ot her. Figure 2.1 shows t he m ast er and slave roles in a sim ple piconet .

Figu r e 2 .1 . M a st e r a n d sla ve r ole s in a sim ple picon e t .

Baseband Modes and Energy-Conserving Features As not ed above, a piconet can include up t o seven act ive slaves and m any m ore parked slaves. The specificat ion includes a definit ion for t his parked baseband m ode, as well as for ot her m odes called sniff and hold. The various baseband m odes facilit at e energy conservat ion by allowing t he radios t o ent er low- power st at es. These low- power m odes are really j ust t hree different m et hods for ent ering and exit ing a low- power st at e, and t he m ode applies t o a given Bluet oot h connect ion ( rat her t han t o t he device as a whole) . These baseband m odes also perm it a great er num ber of devices t o be co- locat ed in t he sam e proxim it y sphere, since not all devices need t o have act ive com m unicat ion links at t he sam e t im e. All four of t hese baseband m odes ( act ive, sniff, hold and park) apply when t he baseband is in a connect ion st at e; when not connect ed, t he baseband is in a st andby st at e, which should not be confused wit h any of t he connect ed st at e m odes. That is, t he baseband st at es are connect ed and st andby; wit hin t he connect ed st at e t here are four m odes ( act ive, sniff, hold and parked) . These st at es and m odes are described in m ore det ail in Chapt er 6. I n act ive m ode a slave essent ially always list ens for t ransm issions from t he m ast er. Act ive slaves receive packet s t hat enable t hem t o rem ain synchronized wit h t he m ast er and t hat inform t hem when t hey can t ransm it packet s back t o t he m aster. An act ive slave m ust list en for all packet s com ing from t he m ast er, alt hough one opt im izat ion is perm it t ed in which act ive slaves need not

16

list en for ent ire packet s ( rat her, j ust t he packet headers) com ing from t he m ast er when it is known t hat som e ot her act ive slave is com m unicat ing wit h t he m ast er during t hat t im e. The act ive st at e t ypically provides t he fast est response t im e but also t ypically consum es t he m ost power, since it is always receiving packet s and is always prepared t o t ransm it packet s. Sniff m ode is one m et hod for reducing power consum pt ion. I n sniff m ode a slave essent ially becom es act ive periodically. The m ast er agrees t o t ransm it packet s dest ined for a part icular slave only at cert ain regular int ervals ( alt hough it m ay not t ransm it packet s at every int erval) . The slave t hen needs t o list en for packet s from t he m ast er only at t he st art of each int erval ( subj ect t o som e t im ing t olerances) . I f t he slave receives packet s at t he st art of t he int erval it cont inues t o list en and receive packet s; ot herwise it can " sleep" unt il t he next int erval. Sniff m ode could perm it reduced power consum pt ion by reducing t he average dut y cycle of t he radio but is likely t o be less responsive t han act ive m ode. The power consum pt ion and responsiveness in sniff m ode depend upon t he lengt h of t he sniff int erval. I n hold m ode a slave m ay st op list ening for packet s ent irely for a specified t im e int erval. [ 7] The m ast er and slave agree upon a hold t im e, and t he com m unicat ion link is quiesced for t hat am ount of t im e. During t he hold t im e t he slave need not list en for packet s from t he m ast er and could be doing ot her t hings such as est ablishing links t o ot her devices, or t he slave could j ust sleep during t he hold t im e. At t he end of t he hold period t he slave resum es list ening for packet s from t he m ast er. Hold m ode m ay be less responsive t han sniff m ode and could perm it great er power savings t han sniff m ode, alt hough t his depends upon t he hold t im e durat ion and upon what t he slave does during t he hold t im e ( sleeps versus com m unicat es on ot her links) . [7] Or at least certain types of packets. Since packet types have not yet been introduced, this section describes the fundamental concept of hold mode. A more complete description can be found in Chapter 6.

I n parked m ode a slave m aint ains synchronizat ion wit h t he m ast er but is no longer considered act ive ( slaves in act ive, sniff and hold m odes are considered act ive) . Since t here can be only seven act ive slaves in a piconet at one t im e, t he use of parked m ode allows t he m ast er t o orchest rat e com m unicat ions wit hin a piconet of m ore t han seven devices by exchanging act ive and parked slaves t o m aint ain up t o seven act ive connect ions while t he rem aining slaves in t he piconet are parked. A parked slave st ill needs t o m aint ain synchronizat ion wit h t he m ast er and does so by list ening t o t he m ast er periodically, using a beaconing schem e described in Chapt er 6. Parked m ode is t ypically t he least responsive of t he connect ed m odes, since t he slave m ust m ake t he t ransit ion t o becom e an act ive m em ber of t he piconet before resum ing general com m unicat ions, but parked m ode m ay perm it great er power conservat ion. Figure 2.2 shows a t ypical relat ionship of t he connect ed st at e m odes in t erm s of t heir relat ive responsiveness versus power consum pt ion. However, bot h power consum pt ion and responsiveness in t hese m odes is highly dependent upon fact ors such as t he am ount of com m unicat ions t raffic and t he hold and sniff periods, which can affect t he dut y cycle of t he radios. As a general rule, act ive slaves will consum e t he m ost power but will be t he m ost responsive, while parked slaves will t ypically be t he least responsive. The figure illust rat es t he general t rend, alt hough t hese relat ionships m ay vary in specific cases.

17

Figu r e 2 .2 . Typica l r e la t ive r e spon sive n e ss ve r su s pow e r con su m pt ion for con n e ct e d st a t e ba se ba n d m ode s ( ge ne r a lize d; m a y n ot a pply in a ll ca se s) .

I n addit ion t o t he baseband m odes which perm it energy conservat ion, anot her power- saving feat ure is adapt ive t ransm ission power. This feat ure allows slaves t o inform t he m ast er when t he m ast er's t ransm ission power is not appropriat e, so t hat t he m ast er can adj ust it s t ransm ission power. This is accom plished t hrough t he use of a received signal st rengt h indicat or ( RSSI ) . When t he RSSI value is out side som e det erm ined boundaries, t he slave can ask t he m ast er t o adj ust t he power. This is especially useful when t wo devices are in close proxim it y and m axim um t ransm ission power is not required ( analogous t o t wo people st anding next t o each ot her, wit h one person shout ing and t he second person asking t he shout er t o speak m ore quiet ly) . Of course t he converse is also t rue: t ransm ission power increases also could be request ed when t he RSSI value indicat es t oo weak a signal but t he prim ary m ot ivat ion for adapt ive t ransm ission power is t o reduce power consum pt ion when a lower t ransm ission power is sufficient . The m ast er m aint ains t ransm ission power set t ings for each slave so t hat a change in t ransm ission power for one slave does not affect ot her slaves in t he piconet . Like ot her energy- conservat ion feat ures, adapt ive t ransm ission power could also allow a great er num ber of devices t o be co- locat ed in t he sam e proxim it y sphere, since it could furt her reduce t he possibilit y of RF int erference wit h ot her devices.

Communications Topology The Bluet oot h net work m odel is one of peer- t o- peer com m unicat ions based upon proxim it y net working. When t wo devices com e wit hin range of each ot her, [ 8] t hey could aut om at ically est ablish a com m unicat ions link. Devices will not necessarily begin t o com m unicat e spont aneously when t hey encount er each ot her, as t he baseband could be configured t o accept only cert ain connect ions, or even none at all. The process of init iat ing com m unicat ions links is explored in det ail in Chapt ers 6 and 7. [8]

Nominal range for the standard 0 dBm Bluetooth radio is approximately 10 meters; power-amplified 20 dBm radios with a range of about 100 meters are also possible. The Bluetooth version 1.0 specification focuses primarily on the standard radio and thus deals mostly with communication within a 10-meter range.

Proxim it y net working wit hout wires enables t he form at ion of personal area net works, or federat ions of personal devices such as m obile t elephones, pagers, not ebook com put ers and personal digit al assist ant s. When t hese devices can com m unicat e seam lessly, t heir overall ut ilit y is enhanced. Anot her applicat ion for proxim it y net working is t he int eract ion of m obile devices wit h fixed devices such as kiosks, print ers, net work access point s and vending m achines—a person could est ablish com m unicat ion bet ween his personal device and a fixed device j ust by approaching it . This t opology enables ot her usage m odels, t oo; t hese are explored m ore fully in Chapt er 3.

18

Piconet t opology, int roduced earlier, can now be furt her explored given t he foregoing discussion of m ast er and slave roles and baseband m odes. A piconet consist s of a single m ast er and all slaves in proxim it y t hat are connect ed t o ( in com m unicat ion wit h) t hat m ast er. The slaves m ay be in act ive, sniff, hold or park m odes at any given t im e. All of t he devices in t he piconet are synchronized, all hopping t oget her. There m ay be ot her devices in proxim it y t hat are not connect ed t o ( not in com m unicat ion wit h) t he m ast er and t hus are not part of t he piconet , including devices in st andby st at e. Figure 2.3 shows t his m ore general view of a piconet ; not e t hat t here could be up t o seven act ive slaves and any num ber of parked slaves and st andby devices ( alt hough m ost t ypical piconet s, especially t hose t hat are form ed t o support t he version 1.0 profiles, are expect ed t o have only a few devices) .

Figur e 2 .3 . Ge ne r a l Blue t oot h picone t in clu din g a ct ive a n d pa r k e d sla ve s. St a n dby de vice s w h ich a r e in pr ox im it y but a r e not pa r t of t he picon e t a r e a lso illu st r a t e d.

As described and illust rat ed above, a device m ay be an act ive or parked part icipant in a piconet or it m ay not be part of any piconet . I n addit ion, it is possible for a device t o t ake part in m ore t han one piconet . When t wo or m ore piconet s at least part ially overlap in t im e and space a scat t ernet is form ed. All of t he sam e principles of piconet s also apply for scat t ernet s; each piconet has a single m ast er and a set of slaves which m ay be act ive or parked. Each piconet has it s own hopping pat t ern det erm ined by it s m ast er. A slave could part icipat e in m ult iple piconet s by in t urn est ablishing connect ions wit h and synchronizing t o different m ast ers in proxim it y. I n fact , a single device m ight act as a slave in one piconet but assum e t he m ast er role in anot her piconet . The scat t ernet t opology provides a flexible m et hod by which devices could m aint ain m ult iple connect ions. This could be especially useful for m obile devices which frequent ly m ove int o and out of proxim it y t o ot her devices. Figure 2.4 shows one exam ple of a scat t ernet using t he sam e represent at ions as in Figure 2.3; ot her exam ples of scat t ernet s are possible. I n t his exam ple slave A2/ B3 is a m em ber of bot h piconet A and piconet B as an act ive slave.

19

Figu r e 2 .4 . Sca t t e r n e t e x a m ple . Sla v e A2 / B3 pa r t icipa t e s a s a n a ct ive sla ve in bot h picon e t A a n d picon e t B.

20

Chapter 3. Bluetooth Usage Models While m uch of t he focus of Bluet oot h wireless com m unicat ion is on t he specificat ion of t he t echnology- which is explored in dept h in Part 2 of t his book- t he specificat ion is act ually root ed in a set of usage m odels ( som et im es also called usage scenarios or usage cases) . Long before t here was a specificat ion, t he official Bluet oot h web sit e included descript ions of several of t hese usage m odels t hat t he t echnology m akes possible. The specificat ion it self was preceded by a m arket ing requirem ent s docum ent ( int ernal t o t he SI G) ; included in t hose m arket ing requirem ent s were usage scenarios t hat were an int egral part of t he obj ect ives t hat t he init ial specificat ion was t o address. These scenarios were not int ended t o cover all possible funct ions achievable wit h t he t echnology but rat her t o set t he init ial focus for t he version 1.0 specificat ion. Bluet oot h usage m odels are form ally specified in profiles, which are exam ined in Part 3. This chapt er focuses on describing t he usage m odels in a general fashion, em phasizing an end user's view of t he scenarios and t he benefit s t hat Bluet oot h wireless com m unicat ion offers in t hose scenarios. Not all of t he usage cases described in t his chapt er have a corresponding profile, alt hough all of t he scenarios have at one t im e or anot her been discussed, present ed or published by t he SI G, and t hey are represent at ive of t hose usage cases t hat drove t he developm ent of t he specificat ion. I f a usage m odel described here has no corresponding profile, it sim ply m eans t hat t he SI G has not form ally specified t hat scenario wit h version 1.0 of t he specificat ion. I n m any inst ances such usage scenarios could be realized wit h Bluet oot h t echnology as defined in t he current specificat ion, but t he SI G has not ( yet ) form alized an int eroperable definit ion for doing so. The usage m odels described here are j ust an init ial set of scenarios t hat could be accom plished wit h Bluet oot h wireless com m unicat ion. [ 1] New applicat ions of t he t echnology will undoubt edly cont inue t o be invent ed, and it is expect ed t hat new scenarios and new profiles will em erge from t he SI G over t im e ( Part 4 discusses som e fut ure possibilit ies) . [1] Some scenarios could also be accomplished with other technologies, and the usage models are not necessarily unique to Bluetooth wireless communication.

The Cordless Computer At it s heart , Bluet oot h wireless com m unicat ion is all about replacing cables. One place where m any cables exist , and where t hese cables are som et im es unwieldy, is t he t ypical deskt op com put er. The cordless com put er usage m odel is not specifically addressed in version 1.0 of t he specificat ion, but it is expect ed t hat t his scenario could be realized in a st raight forward m anner in t he fut ure. As depict ed in Figure 3.1, m any of t he cables associat ed wit h com put er peripherals could be replaced by wireless links. Keyboards, m ice, j oyst icks, speakers, print ers, scanners and t he like m ight all em ploy Bluet oot h wireless com m unicat ions. While not shown in t he figure, ot her com put er- relat ed wires such as personal digit al assist ant cradles, digit al cam era cables and net work connect ion cables could also be replaced by wireless connect ions ( t hese t hree exam ples are discussed below in " The Aut om at ic Synchronizer," The I nst ant Post card and The I nt ernet Bridge usage m odels, respect ively) .

21

Figu r e 3 .1 . The Blu e t oot h cor dle ss com pu t e r u sa ge m ode l.

I n addit ion t o t he direct ly evident benefit s of not having t o deal wit h cables during inst allat ion and operat ion of t he com put er, wireless devices offer m ore freedom in placem ent and use. Speakers, print ers and scanners, for exam ple, could be placed in t he m ost appropriat e locat ion for t he environm ent , unrest rict ed by connect ors and cable lengt h. User int erface devices such as keyboards, m ice and j oyst icks could be used wherever it is convenient t o do so and could m ove wit h t he user rat her t han being fixed in a cert ain locat ion where t hey would be const rained by a cable. Device sharing is m uch easier in t his configurat ion t han in a cabled environm ent . A j oyst ick, for exam ple, need not be used exclusively wit h t he com put er but m ight also be used wit h a video gam e. Even m ore im port ant for m any people, t hough, is t he capabilit y t o share peripherals such as print ers or scanners. Today sharing t hese devices oft en requires a net worked environm ent where t he com put er t hat host s t he peripheral act s as a server; if ot her devices need t o use t he peripheral t hey do so via t he host ing com put er which is cabled t o t he peripheral. Wit h t he cordless com put er, ot her devices using Bluet oot h wireless com m unicat ion could direct ly access peripherals in peer- t o- peer fashion.

The Ultimate Headset Support for voice in Bluet oot h wireless com m unicat ion fost ers t his usage m odel. Telephone headset s are increasingly com m on for use wit h bot h fixed and m obile t elephones. I n environm ent s such as call cent ers ( help desks, cent ralized reservat ions offices, and so on) headset s m ight be used wit h st andard t elephones t o keep a person's hands free t o use a com put er. Headset s are also available for use wit h m any m obile t elephones, also for hands- free

22

operat ion for sit uat ions such as driving or walking while carrying it em s. Bluet oot h wireless com m unicat ion rem oves t he cable bet ween t he headset and t he t elephone. A call could be placed using t he t elephone keypad, wit h t he audio port ion of t he call being carried t hrough t he headset 's m icrophone and speaker. Figure 3.2 illust rat es various inst ances of t he ult im at e headset usage m odel, including t he use of t he headset wit h nont elephony devices, described m ore fully below.

Figur e 3 .2 . The Blue t oot h ult im a t e h e a dse t u sa ge m ode l.

One advant age of t he ult im at e headset is t hat it support s m obilit y. The user of t he headset is not physically t ied t o t he audio device and t hus is free t o roam about t he area while keeping t he connect ion int act . Anot her advant age is t he abilit y t o use t he sam e headset wit h m ult iple devices. Because t he specificat ion offers a st andard int erface, t he sam e headset used wit h a t elephone m ight also be used wit h a fixed voice access point , such as a cordless t elephone base st at ion, and could also be used for audio int eract ion wit h com put ers. I n t he fut ure it also m ay be possible t o use such a headset wit h st ereos, port able CD players and recording devices. As wit h t he cordless com put er, t he ult im at e headset allows devices t o be placed wherever it m ay be convenient , which for m obile devices m ight be in a pocket or briefcase. Wit h appropriat e speech t echnologies it indeed m ay be possible, t hrough t he use of voice recognit ion, t o place t elephone calls using only t he headset as t he user int erface.

The Three-in-One Phone Today m any people use m ult iple t elephones: a phone in t he office, one or m ore t elephones at hom e ( som e wired, som e cordless) , a m obile ( cellular) t elephone, public t elephones, and so on. A single phone using Bluet oot h wireless com m unicat ion could be used in place of m any of t hese ot her t elephones. The t hree- in- one phone usage m odel allows a m obile t elephone t o be used as a cellular phone in t he st andard m anner, as a cordless phone connect ing t o a voice access point ( cordless phone base st at ion) , and as an int ercom or " walkie- t alkie" for direct phone- t o- phone com m unicat ions wit h anot her device in proxim it y. Figure 3.3 shows all t hree uses of t he t hree- inone phone.

23

Figur e 3 .3 . The Blue t oot h t hr e e - in - on e ph on e u sa ge m ode l.

A key benefit of t he t hree- in- one phone is t hat a single t elephone could becom e t he only one t hat a person needs. I f m ult iple voice access point s using Bluet oot h wireless com m unicat ion becom e available in environm ent s such as t he hom e, office and public areas, a single personal t elephone t hat is usable alm ost anywhere becom es realist ic. The need for separat e t elephones and separat e t elephone num bers in t he office, at hom e and while t raveling could be reduced. Anot her benefit t hat derives from t he use of such voice access point s is t he possibilit y for reduced cellular airt im e charges. When t he handset is used as a cordless phone, com m unicat ing wit h a st andard " landline" t elephone service via an access point , no cellular airt im e charges need be incurred. The direct t elephone- t o- t elephone, or " walkie- t alkie" funct ion of t he t hree- in- one phone usage m odel is m ost useful wit h t he 20 dBm power am plified radio, wit h it s range of 100 m et ers. When t wo part ies are wit hin range of each ot her using st andard Bluet oot h radios ( 10 m et ers) , it is likely t hat t hey could shout at each ot her rat her t han use t elephone radio com m unicat ion ( aside from sit uat ions where a physical obst acle m ight separat e t he part ies) . Because a direct phone- t ophone com m unicat ion scenario across only a 10- m et er range m ight have lim it ed ut ilit y, t he SI G indeed debat ed whet her or not t his walkie- t alkie funct ion should be included in t he usage m odel, since t he focus of t he version 1.0 specificat ion is on a st andard 0 dBm Bluet oot h radio ( t here was som e discussion of rem oving t his use of t he t elephone and calling t his usage m odel t he t wo- inone phone) . However, even wit h t he st andard radio wit h it s 10- m et er range t here are sit uat ions where t he direct phone- t o- phone com m unicat ion m ight be useful. These m ight include cases such as people com m unicat ing across different floors of a building, from wit hin confined spaces or when nonint rusive com m unicat ion is desired even when bot h part ies m ight be able t o see each ot her ( for exam ple, video and sound cont rol workers in a crowded audit orium ) .

24

The Interactive Conference (File Transfer) One of t he m ost fundam ent al and useful applicat ions for any t ype of dat a net working, including sim ple point - t o- point links ( like t hose of Bluet oot h wireless com m unicat ion) , is t o exchange files and ot her dat a obj ect s. File t ransfer using floppy disks or cables is com m on; wireless com m unicat ion rem oves t he need for cables, m aking it m uch easier t o form t em porary links bet ween devices t o quickly exchange files and ot her dat a obj ect s. For exam ple, as infrared dat a port s becom e m ore widely used wit h not ebook com put ers, m obile t elephones and personal digit al assist ant s, it is not uncom m on for users t o est ablish a t em porary infrared link t o exchange elect ronic business cards and ot her dat a. This sam e sort of file and obj ect t ransfer is possible wit h Bluet oot h wireless com m unicat ion. I n an int eract ive conference room scenario, business cards and files could be exchanged am ong t he part icipant s of t he m eet ing. Figure 3.4 illust rat es t he Bluet oot h file t ransfer usage case; as shown, not only could files be t ransferred bet ween t wo com put ers but obj ect s also could be t ransferred bet ween any t wo devices using Bluet oot h wireless com m unicat ions.Chapt er 14 discusses t he det ails of t he various m odes and t ypes of file and obj ect t ransfer.

Figu r e 3 .4 . The Blu e t oot h int e r a ct ive con fe r e n ce ( file a n d obj e ct t r a n sfe r ) u sa ge ca se .

A prim ary benefit of wireless file t ransfer is t he convenience t hat it offers. Dat a could be exchanged easily bet ween t wo or m ore devices wit hout t he use of cables ( which, as point ed out in t he int roduct ion, are likely t o be cum bersom e, propriet ary and incom pat ible bet ween t wo given devices) and wit hout t he need t o set up and configure a full- blown net work am ong t he devices. Files and ot her obj ect s could be exchanged im m ediat ely in a conference room set t ing, rat her t han deferring t he t ransm ission of t he files unt il aft er a m eet ing is over when a com put er or ot her device can be connect ed t o a net work.

25

The Internet Bridge There are t wo sim ilar yet different m et hods for using Bluet oot h com m unicat ion as a wireless " bridge" [ 2] t o est ablished net works like t he I nt ernet or cam pus or corporat e int ranet s. The first m et hod is dial- up net working using a t elephone as a wireless dat a m odem ; t he second is direct local area net work ( LAN) access using a dat a access point . [2] The term bridge is used here since it is consistent with the nomenclature used by the SIG. The function described here is similar to a traditional network bridge, which is distinct from a router. While no Bluetooth "Internet router" usage case exists in version 1.0, such a function is not beyond the realm of possibility.

Dial-Up Networking This form of t he I nt ernet bridge is no different from t he m et hod m any people use t o access t he I nt ernet t oday. A convent ional arrangem ent involves connect ing a com put er t o t he I nt ernet using a t elephone t o dial an I nt ernet service provider t hrough a m odem . What Bluet oot h com m unicat ion adds t o t his scenario is t he abilit y t o accom plish t his usage m odel ent irely wit hout wires. Today's usage m odels for dial- up net working t ypically require a cable bet ween t he com put er and t he t elephone; even when a m obile t elephone is used, a cable bet ween t he com put er and t he m obile t elephone is usually required. Wit h a com put er and a t elephone t hat bot h support t he dial- up net working profile, t he end- t o- end connect ion t o t he I nt ernet ( or ot her net work) could be wireless, as illust rat ed in Figure 3.5.

Figu r e 3 .5 . Th e in t e r n e t br idge u sa ge ca se 1 : w ir e le ss dia l- u p n e t w or k in g.

Direct Network Access While dial- up net working is a popular way t o access t he I nt ernet , especially from hom es or ot her environm ent s where t elephone lines ( or in som e cases, cable or high- speed dat a connect ions) are t he prim ary com m unicat ions bridge, direct access t o LANs is com m on in ent erprises, on cam puses, and in ot her sim ilar environm ent s. The direct ly accessed local area net work oft en

26

provides a gat eway t o t he I nt ernet , enabling t he I nt ernet t o be accessed from t he LAN wit hout a dial- up connect ion. Direct net work access via Bluet oot h wireless com m unicat ion is possible using dat a access point s. A dat a access point allows devices t o connect t o it wirelessly; t he dat a access point in t urn connect s t o t he local area net work. Once again t his is not funct ionally different from t he sam e sort of connect ion in a wired environm ent , such as a t radit ional Et hernet net work where com put ers connect t o net work access point s using cables. A dat a access point wit h Bluet oot h wireless com m unicat ion sim ply provides a " wireless plug" t o connect t o t he net work as illust rat ed in Figure 3.6.

Figu r e 3 .6 . The Blu e t oot h int e r n e t br idge u sa ge ca se 2 : dir e ct loca l a r e a n e t w or k a cce ss t h r ou gh a da t a a cce ss poin t .

The I nt ernet bridge is one case where Bluet oot h wireless com m unicat ion can be used t o replace cables, m aking a com m on t ask easier and m ore convenient . Dial- up net working, for exam ple, is com m on t oday wit h wired m odem s and t elephones. Many business t ravelers have experienced searching a hot el room for t he t elephone j ack so as t o plug in t heir not ebook com put er's m odem for dial- up net working. Wit h Bluet oot h wireless com m unicat ion, no cable connect ion is required; a hot el room t elephone or a person's own m obile phone could be used as a wireless dat a m odem . The use of a m obile t elephone as a wireless dat a m odem is not uncom m on t oday, but in m ost cases t he m obile phone st ill needs t o be cabled t o t he not ebook com put er; Bluet oot h wireless com m unicat ions could furt her im prove upon t his scenario by rem oving t he cable bet ween t he com put er and t he phone. Direct net work access using Bluet oot h wireless com m unicat ion offers advant ages over t he equivalent wired scenario. I n addit ion t o obviat ing t he need t o provide an in- building wired infrast ruct ure wit h endpoint connect ions at every access point , a wireless dat a access point also offers t he possibilit y for devices t o share t he access point . Mult iple devices in proxim it y of a single dat a access point could access t he net work wirelessly rat her t han requiring each device t o have a separat e cabled connect ion t o it s own access point . Moreover, dat a access point s could be designed such t hat t hey could plug int o exist ing net work wiring infrast ruct ure and t hus allow " t he last hop" t o be wireless, wit h it s associat ed conveniences, while m aking use of and prot ect ing t he invest m ent in t he exist ing wired net work.

27

The Speaking Laptop The speaking lapt op is one of t he usage m odels t hat is not advert ised in version 1.0 of t he specificat ion, perhaps because it could be considered a st raight forward ext ension of t he headset profile already described. [ 3] The concept behind it is t hat a lapt op ( or not ebook) com put er's m icrophone and speaker could be used as t he audio input and out put for a voice call placed on a m obile t elephone. As an exam ple, suppose som eone places a call on a m obile phone during a m eet ing. As t he conversat ion progresses, it becom es evident t hat ot hers in t he m eet ing would benefit from t aking part in t he call. Bluet oot h wireless com m unicat ion could be used t o rout e t he voice t raffic t o a not ebook com put er in t he conference room , allowing t he com put er t o be used as a speakerphone. The call is st ill being carried over t he m obile phone's wide area voice net work but t he audio source and sink are now at t he not ebook com put er. Figure 3.7 illust rat es t he speaking lapt op scenario. [3] The technical underpinnings of routing voice traffic between a telephone and another device are similar, although the speaking laptop has some distinct end-user considerations that merit its independent discussion here.

Figu r e 3 .7 . The Blu e t oot h spe a k in g la pt op u sa ge m ode l.

The speaking lapt op usage m odel is an exam ple of ext ending t he funct ions of one device by allowing it t o " borrow" t he capabilit ies of som e ot her device. Speakerphone capabilit y becom es available, using t he speaker and m icrophone of t he not ebook com put er, even if t he m obile phone does not have it s own speakerphone capabilit y. Ext ensions t o t he speaking lapt op scenario m ight enable ot her sim ilar usage m odels where exist ing audio input and out put could be used t o supplem ent t hat of a m obile t elephone. For exam ple, t he audio port ion of a call could also be rout ed t o a car's audio syst em in a vehicle wit h Bluet oot h wireless com m unicat ions.

The Automatic Synchronizer The aut om at ic synchronizer is an exam ple of using proxim it y net working t o add value by m aking an exist ing t ask easier t o do. Personal port able devices em power people t o have quick and easy access t o inform at ion t hey can use in t heir daily lives. For t hat inform at ion t o be m ost useful it needs t o be kept up t o dat e, but t his personal inform at ion m anagem ent dat a m ight be dist ribut ed across t he m any devices t hat a person could use. For exam ple, new calendar ent ries or t o- do list it em s m ight be ent ered on any of a not ebook com put er, personal digit al assist ant or sm art phone; or t hese ent ries m ight be ent ered on a deskt op com put er and st ored on a server in a

28

net work. Synchronizat ion is t he process of m erging t he dat a from t wo different sources based upon som e set of rules such t hat t he result ing dat a set s are ident ical ( or at least reflect ident ical inform at ion) . A com m on exam ple is synchronizing a personal digit al assist ant wit h a deskt op or not ebook com put er. Today t his oft en is perform ed using special serial cables and soft ware t hat m ay be unique t o t he device. St andard prot ocols and obj ect form at s in t he specificat ion allow dat a on one device t o be synchronized wit h dat a on any ot her device, whet her t hey be PDAs, not ebook com put ers, sm art phones or even net worked dat a accessed t hrough a dat a access point . The " aut om at ic" part of t his usage m odel is enabled by proxim it y net working. Today synchronizat ion is alm ost always a conscious effort - it involves connect ing a serial cable and pushing a but t on, or point ing t wo infrared- capable devices at each ot her and launching an applicat ion. Wit h Bluet oot h wireless com m unicat ions it is possible for t wo devices t o aut om at ically synchronize whenever t hey com e wit hin range of each ot her. For exam ple, a personal digit al assist ant carried in a person's pocket could aut om at ically synchronize wit h t hat person's deskt op com put er whenever she walked int o her office. Clearly it should be possible t o configure t he devices as t o when and how t o aut om at ically synchronize, and t o ensure t hat devices synchronize only wit h ot her known devices and dat a sources and not wit h j ust any random device; t he specificat ion does offer m echanism s t hat could be used t o do t his. Figure 3.8 shows exam ples of t he aut om at ic synchronizer. The figure illust rat es how different devices in a personal area net work ( such as t he m obile t elephone and PDA shown) m ight aut om at ically synchronize. The figure also shows how one of t hose devices ( here, t he PDA in t he briefcase) m ight also synchronize wit h a deskt op com put er when t hose devices com e wit hin range of each ot her ( in t his case, when t he PDA's owner walks int o her office) .

Figu r e 3 .8 . The Blu e t oot h a u t om a t ic syn ch r on ize r u sa ge m ode l.

I n addit ion t o t he convenience afforded by aut om at ic synchronizat ion, Bluet oot h wireless com m unicat ion rem oves t he requirem ent for cables. By specifying a st andard prot ocol and obj ect form at s for synchronizat ion ( t hese are adopt ed from I rDA, as det ailed in Chapt ers 9 and 14) , Bluet oot h wireless com m unicat ion m akes it easier for any device t o synchronize wit h any ot her device. This m ult idevice synchronizat ion enables a person t o use any convenient device t o ent er new appoint m ent s, t o- do list it em s or ot her dat a.

The Instant Postcard The inst ant post card is anot her usage m odel t hat was discussed early in t he developm ent of t he specificat ion but is not form ally part of t he version 1.0 profiles. This is one of t he few scenarios t hat involves a device ot her t han a m obile phone or com put ing plat form , alt hough it is expect ed

29

t hat over t im e m any new usage m odels and profiles will be developed for addit ional device classes. The underlying concept is t hat of having a digit al cam era which can wirelessly t ransfer a phot o im age t o som e ot her device which could t hen e- m ail t he im age t o a recipient , t hus creat ing a digit al " post card." Today m any digit al cam eras use a serial cable t o t ransfer phot o im ages t o a com put er where t hey can be st ored, cat alogued, m anipulat ed and dist ribut ed. As wit h t he ot her version 1.0 usage m odels, Bluet oot h wireless com m unicat ion rem oves t he need for a cable which in t urn present s new ways t o use a device, as point ed out below. Figure 3.9 shows how t he inst ant post card m ight be realized.

Figu r e 3 .9 . Th e in st a n t post ca r d.

This scenario is useful not only for sending " post card" t ype pict ures t o friends and relat ives but also for com m ercial applicat ions, such as real est at e ( t ransferring phot os of newly list ed hom es t o a cent ral dat abase) , law enforcem ent ( t ransferring phot os of suspect s or st olen vehicles, for exam ple) and insurance ( t ransferring phot os of aut om obile dam age result ing from accident s) . I n addit ion t o replacing cables, Bluet oot h t echnology also could change t he way a digit al cam era is used, since phot os need not necessarily be t ransferred t o a com put er. Many phot os m ight be t ransferred direct ly from t he cam era t o a m obile phone and t hen sent as an e- m ail at t achm ent wit hout using a com put er as an int erm ediary. I n addit ion, t he t ransfer of phot os from t he cam era t o a dat abase or library could be accom plished in m ore of a real- t im e fashion, since no cabling is required.

Ad Hoc Networking This usage m odel could be considered t o be an ext ension of t he int eract ive conference ( file t ransfer) scenario. I t is not specifically addressed in t he version 1.0 specificat ion but it does provide an illust rat ion of usage cases t hat could be enabled in t he fut ure. Ad hoc net works are net works t hat form spont aneously; Bluet oot h wireless com m unicat ion is an enabling t echnology for t hese sort s of applicat ions. The int eract ive conference usage m odel showed how obj ect s such as elect ronic business cards or files could be exchanged in a conference room set t ing. When ad hoc net works can be form ed am ong t he m eet ing part icipant s, addit ional applicat ions becom e possible. Am ong t hese are collaborat ive applicat ions such as real- t im e viewing and group edit ing of present at ions and inst ant m essaging am ong t he m eet ing part icipant s.

30

Ad hoc net works consist ing of diverse t ypes of devices present m any new and excit ing possibilit ies for usage scenarios. While m ore work is required t o est ablish int eroperable m et hods for general net working, [ 4] Bluet oot h wireless com m unicat ion is posit ioned t o be an enabling t echnology for ad hoc net working scenarios. [4] For example, issues with routing, name serving, address assignment and other topics all need to be addressed for effective ad hoc networking. Such issues are also relevant in forming Bluetooth scatternets, discussed inChapter 6.

Hidden Computing Hidden com put ing ( som et im es called unconscious com put ing) is one of t he m ost excit ing fut ure applicat ions for Bluet oot h t echnology. While not direct ly addressed in t he version 1.0 specificat ion, hidden com put ing has been discussed at SI G event s in t he past and is an area ripe for fut ure explorat ion. The fundam ent al elem ent s required for som e form s of hidden com put ing already exist in t he current specificat ion, alt hough t he SI G has not developed profiles t hat describe how t he various hidden com put ing applicat ions m ight be accom plished in a st andard and int eroperable m anner. Hidden com put ing involves a class of applicat ions in which devices t hat are not overt ly being used by a person can st ill perform t asks on t hat person's behalf. We have already seen one exam ple t hat could be considered a hidden com put ing applicat ion: t he aut om at ic synchronizer. I n t hat usage m odel, a PDA " hidden" in a pocket or purse could synchronize wit h anot her device wit hout user int ervent ion. Several ot her exam ples have been described in t he cont ext of Bluet oot h wireless com m unicat ion. Am ong t hese are: •

•

A not ebook com put er " hidden" in a briefcase in a " sleeping" m ode could be configured t o awake periodically, receive new e- m ail and send inform at ion such as new e- m ail alert s ( and possibly a short clip of t he e- m ail cont ent ) t o a m obile phone. The user m ight t hen decide t o browse e- m ail using t he m obile phone or process e- m ail on t he not ebook com put er. A m obile t elephone " hidden" in a pocket or purse could be used by an appropriat ely configured not ebook com put er " hidden" in a briefcase t o access a net work in t he m anner described for t he I nt ernet bridge ( dial- up net working) scenario. Once t he com put er is connect ed t o a net work in t his fashion, net work synchronizat ion or t ransm ission and recept ion of e- m ail could be init iat ed, all wit hout conscious user int eract ion wit h eit her device.

I n early st ages of t he developm ent of t he specificat ion, such applicat ions were called " t he briefcase t rick." Wit h proxim it y net working enabled by Bluet oot h wireless com m unicat ion, hidden com put ing applicat ions abound. Ot her fut ure possibilit ies m ight include t he use of a hidden device t hat cont rols environm ent al set t ings ( such as hom e clim at e and light ing, m usic, aut om obile driver's seat and m irror adj ust m ent s and so on) based upon t he personal preferences of t he user, aut om at ic cust om er discount s applied at point s of sale based upon a device t ucked away in a pocket or suit case, and aut om at ed ident ificat ion and aut hent icat ion when a person checks in wit h an airline or a hot el. These sort s of scenarios are alm ost lim it less. While hidden com put ing applicat ions m ay not be fully realized for som e t im e, t he Bluet oot h t echnology does offer a basis upon which indust ry innovat ors could build t hem .

31

Chapter 4. Introduction to the Bluetooth Specification Any good t echnical specificat ion should answer several quest ions of " what ?" for it s readers. Som e t opics t hat a specificat ion ought t o address are: • • • •

what what what what

is t he product or t echnology? is it designed t o do? is it com posed of? st andards and m et rics m ust an im plem ent er m eet ?

Quest ions of " how?" t ypically are not addressed in a specificat ion but rat her are left t o t he j udgm ent and ingenuit y of t he im plem ent ers. A specificat ion usually does not address exact ly how an inst ance of t he t echnology or product is const ruct ed using hardware or soft ware m odules or describe t he precise m et hods used t o ensure t hat st andards and requirem ent s are m et . The Bluet oot h specificat ion is no different from ot hers in t his respect . Even in it s great m agnit ude ( over 1,500 t ot al pages in version 1.0B) t he specificat ion st ill focuses prim arily on what an im plem ent er needs t o know t o creat e product s t hat use Bluet oot h t echnology. One reason for t he enorm it y of t he specificat ion is t he breadt h of t he t opics t hat it covers. The specificat ion is not one t hat addresses only a radio or j ust a single layer of a soft ware st ack or a solit ary int erface; rat her it addresses a com binat ion of hardware and soft ware t hat includes all of t hese facet s and m ore, wit h broad applicat ions and a diverse audience. The SI G deem ed t his approach necessary, given t he m any new concept s int roduced wit h Bluet oot h t echnology. However, t he SI G adopt ed exist ing prot ocols where feasible; large port ions of t he specificat ion deal wit h adapt ing t hese prot ocols t o Bluet oot h environm ent s. The SI G involved dozens, if not hundreds of people who spent over a year developing t he first version of t he specificat ion. Rat her t han publish a first edit ion t hat was inform at ional only, t he SI G chose t o ensure t hat t he version 1.0 specificat ion was sufficient ly correct and com plet e t o enable im plem ent at ions t o begin. While t he init ial publicat ion was unsurprisingly im perfect ( num erous errat a have been published) and arguably can never be t ruly com plet e( since new applicat ions of t he t echnology will cont inue t o evolve) , t his approach t o producing a com prehensive first version of t he specificat ion was appreciat ed by m any Bluet oot h adopt er com panies. This chapt er explains t he purpose, scope and st ruct ure of t he specificat ion and t he relat ionships am ong it s const it uent part s. Because t he specificat ion is so broad and volum inous it seem s unlikely t hat all readers will read it from cover t o cover wit h equal int erest in all of it s diverse part s. Since t he m ain body ( Part s 2 and 3) of t his book deals wit h t he specificat ion, it s st ruct ure logically m irrors t he specificat ion's st ruct ure t o a great ext ent . By explaining how t he specificat ion is organized, t his chapt er is designed t o direct readers t oward t he chapt ers of t his book, and hence t oward t he chapt ers of t he specificat ion, t hat are likely t o be of m ost int erest and relevance based upon t he t asks t hey wish t o accom plish or t he knowledge t hey hope t o gain.

Purpose of the Specification Like m ost t echnical specificat ions, t he Bluet oot h specificat ion is a response t o m arket ing requirem ent s. As previously not ed, t he SI G's Market ing working group originally generat ed a m arket ing requirem ent s docum ent ( MRD) , which is int ernal t o t he SI G and includes obj ect ives and usage m odels which were t he genesis of t he specificat ion. A core purpose of t he specificat ion

32

is t o define com ponent s t hat can be used t o develop solut ions t hat address t hese m arket ing requirem ent s. Am ong t he obj ect ives set fort h in t he MRD were t hose t hat now are key at t ribut es of Bluet oot h wireless com m unicat ions: an open specificat ion, unlicensed global use, low cost and int eroperable solut ions regardless of device m anufact urer. I n fact , each of t he fundam ent al charact erist ics of t he t echnology in t he list in Chapt er 1 has som e basis in t he m arket ing requirem ent s docum ent . I n m any cases, port ions of t he specificat ion can be t raced back t o an MRD obj ect ive. For exam ple, t he obj ect ive of an open specificat ion is realized wit h it s public availabilit y and royalt yfree license; unlicensed global com m unicat ions are achieved t hrough t he use of t he 2.4 GHz spect rum ; m any of t he radio's param et ers ( described in m ore det ail in Chapt er 6) are a result of design t radeoffs t o specify a robust radio while m eet ing t he obj ect ive of low cost ; and t he obj ect ive of int eroperabilit y is direct ly addressed in t he m ore t han 400 pages of profiles ( volum e 2 of t he specificat ion) . Many of t he usage m odels and t echnical charact erist ics reviewed in Chapt er 3 also were recorded first as m arket ing requirem ent s. Most of t hese scenarios are described in t he MRD and m any of t hese survive largely unchanged t oday, alt hough t hey have been refined and expanded. I nit ial out lines for t he int eract ive conference ( file t ransfer) , synchronizat ion, I nt ernet bridge, t hree- inone phone, ult im at e headset and ot hers all are included wit hin t he original MRD, alt hough som e of t hese scenarios originally were known by different nam es.

Scope The SI G int ent ionally began t he specificat ion developm ent by focusing first on cable replacem ent usage m odels and a basic prot ocol fram ework t o support t hem . This philosophy result ed in t he specificat ion version 1.0, which defines a prot ocol st ack t hat enables m any im port ant profiles, but t he SI G has not st opped t here. There is int erest in m any new applicat ions and profiles; t hese will cont inue t o be developed by t he SI G and are likely t o be published in fut ure edit ions of t he specificat ion. Part 4 explores t hese possibilit ies furt her. By st art ing wit h t he sim plest and m ost fundam ent al usage m odels, t he SI G was able t o bound t he version 1.0 specificat ion scope. The specificat ion does not sim ply describe som e exist ing im plem ent at ion. Great care was t aken during it s developm ent t o ensure t hat anyone who has or can obt ain sufficient skills and resources should be able t o im plem ent t he specificat ion. Recall t hat t he specificat ion was developed by a m ult icom pany special int erest group wit h a shared and st at ed obj ect ive t o produce a t ruly open specificat ion. The elem ent s of t he specificat ion were developed t o m eet t he obj ect ives for t he t echnology in a pract ical m anner, not t o m at ch preconceived ideas nor a single com pany's viewpoint , experience or im plem ent at ions. I n fact , for m ost port ions of t he specificat ion quit e t he opposit e was t rue: t he process was t o draw upon t he collect ive wisdom and experience of t he com pany represent at ives t o produce an init ial version of som e part of t he specificat ion. Hypot heses in t he draft specificat ion could t hen be t est ed at one or m ore com panies via prot ot yping or som e ot her m eans, wit h t he result s t hen fed back int o t he refinem ent process. The m any independent im plem ent at ions of Bluet oot h hardware and soft ware by m ult it udes of vendors, m any of whom were not part of t he SI G's prom ot er group, seem t o indicat e t hat t he SI G has perform ed well in producing a sufficient ly com plet e specificat ion. I t is encouraging t hat m any product s wit h Bluet oot h wireless com m unicat ion are being produced on t he basis of t he version 1.0 specificat ion. I n any work t his large, of course, som e errors and opport unit ies for m isint erpret at ion are likely t o arise. The Bluet oot h specificat ion is no except ion. Following publicat ion of t he version 1.0 ( or m ore properly, 1.0A) specificat ion, num erous com m ent s from adopt ers and ot hers were received. Many of t hese com m ent s dealt wit h port ions of t he specificat ion t hat were unclear or for which

33

m ult iple int erpret at ions could reasonably be const rued. I n addit ion, m inor errors t hat had slipped t hrough even t he diligent review of t he SI G m em bers were discovered. For each of t hese it em sand t here were dozens if not hundreds- t he responsible working group wit hin t he SI G considered t he com m ent and, if accept ed, prepared an errat um docum ent and correct ed t he error or clarified t he wording in a corresponding change t o t he specificat ion. The result was t he publicat ion in Decem ber 1999 of t he specificat ion version 1.0B, which is what m ost people m ean when t hey refer t o version 1.0 of t he specificat ion ( and indeed t his is what is m eant by such references t hroughout t his book) . Of course even as new versions of t he specificat ion are generat ed, docum ent m aint enance m ust cont inue, and t he SI G st ill deals wit h errat a t o t he init ial specificat ion while developing new m at erial for new versions.

The Specification's Structure At t he highest level t he specificat ion is split int o t wo volum es: volum e 1 is t he core specificat ion, which deals prim arily wit h t he prot ocol st ack but also includes descript ions of relat ed it em s such as t est ing and com pliance; volum e 2 is t he profile specificat ion. I n t his book t hese t wo volum es are exam ined in Part s 2 and 3, respect ively. For version 1.0, t he core specificat ion is by far t he larger of t he t wo volum es, weighing in at nearly 1,100 t ot al pages. Volum e 2, t he profiles, is about 440 pages in version 1.0. The set of profiles is expect ed t o grow m ore rapidly t hough, as new usage cases are form alized. A m aj or port ion of t he SI G's work following release of t he version 1.0 specificat ion is focused on creat ing new profiles. So as Bluet oot h wireless t echnology becom es m ore widely used in new indust ries wit h new applicat ions, t he cont inued creat ion of addit ional profiles is expect ed.

Volume One Structure Wit hin volum e 1 t he prot ocols are present ed largely in a bot t om - t o- t op organizat ion. The specificat ion begins wit h a short discussion of t he radio followed by t he baseband, link m anager and L2CAP layers. Next are t he higher layers: RFCOMM, SDP, TCS and I rDA int eroperabilit y prot ocols. The Host Cont roller I nt erface ( HCI ) is an int erface t o t he baseband cont roller and link m anager, but in t he specificat ion t he HCI is discussed aft er all of t he higher- level prot ocol sect ions ( t he HCI is a com m and int erface rat her t han a prot ocol per se and it s use m ay differ depending upon an im plem ent at ion's design; t hus it is discussed separat ely in t he specificat ion) . Addit ional chapt ers t hat do not deal specifically wit h prot ocols include WAP int eroperabilit y, t est m ode, t est cont rol and com pliance discussions. Finally t he m iscellaneous m at erial is included in t he appendices, alt hough m uch of t his m at erial is im port ant for m any im plem ent ers and should not be overlooked. Am ong t he t opics covered in t he appendices of volum e 1 of t he specificat ion are audio ( also discussed Chapt er 10 of t his book) and Bluet oot h assigned num bers. Appendix VI I I of volum e 1 of t he specificat ion, Bluet oot h Assigned Num bers, is a cent ral area in which values defined by t he SI G are recorded. This im port ant part of t he specificat ion is not det ailed elsewhere in t his book, so we briefly discuss it here. The Bluet oot h Assigned Num bers sect ion of t he specificat ion defines values t hat are expect ed t o change or evolve over t im e and m ust be relied upon and t herefore regist ered. I ncluded are t he part icular values assigned t o key fields or st ruct ures t hat m ust be well known in several prot ocols. Exam ples include inquiry access codes and bit definit ions for fields t hat describe device and service classes, used when est ablishing connect ions; channel and prot ocol values used in L2CAP; and several specific values defined for use wit h SDP. I n t his lat t er case t hese values represent part icular services and at t ribut es associat ed wit h t hose services t hat are required t o accom plish t he usage m odels ( as described in t he profiles) for version 1.0. This list is expect ed t o grow over t im e as new usage m odels are adopt ed. Because it is difficult t o predict what new services will be available, it is difficult t o pre- assign values for all services; t hus t he values are isolat ed in t he assigned num bers

34

regist ry so t hat t he prot ocol specificat ion it self need not be m odified when inst ances of new services are developed.

Volume Two Structure The organizat ion of t he profiles in volum e 2 of t he specificat ion is quit e st raight forward. Each chapt er is a single profile. For t he m ost part , relat ed profiles are grouped t oget her, alt hough t he serial port profile seem s t o be oddly insert ed in t he m iddle of t he t elephony- based profiles. As in volum e 1, t he profile specificat ion begins st raight away wit hout any int roduct ory or background m at erial t o set t he st age. I n Part 3 of t his book we provide som e cont ext for t he profile specificat ion. Part 3 of t his book m ost ly follows t he st ruct ure of volum e 2 of t he specificat ion, grouping t oget her t he GAP and SDAP profiles, t elephony- relat ed profiles, serial port - relat ed profiles and net working- relat ed profiles. Alt hough t hese profiles are not form ally grouped t his way in t he specificat ion, t his approach is int ended t o aid underst anding and is discussed furt her in Chapt er 11.

Relationships While init ially it m ay not be evident t hat t here is som e coupling bet ween t he t wo volum es of t he specificat ion, t here is in fact a correspondence bet ween m any layers of t he prot ocol st ack and one or m ore profiles. Because t he profiles are int ended t o inform t he reader about how t o apply t he prot ocols defined in volum e 1 t o realize an int eroperable im plem ent at ion of a part icular usage case, t hese profiles t end t o m ap t o prot ocol layers in som e fashion, alt hough it is not always a one- t o- one m apping. Each profile describes t he associat ed prot ocol st ack t hat it requires, as well as how t o use and configure t he appropriat e prot ocol layers. Many profiles are som ewhat at t uned t o cert ain prot ocols. For exam ple, t he generic access profile prim arily defines how t o use t he baseband, link m anager and L2CAP layers of t he prot ocol st ack. The service discovery applicat ion profile is t ight ly coupled wit h t he SDP layer of t he st ack; t he t elephony- based profiles ( int ercom , headset [ 1] and cordless t elephony) principally relat e t o t he TCS prot ocol and audio t raffic. The serial port - based profiles[ 2] ( including obj ect and file t ransfer and t he serial port profile it self) and net working- based profiles ( LAN access, fax and dial- up net working) have som e affinit y wit h t he RFCOMM layer of t he st ack, wit h t he serial port - based profiles also being t ight ly coupled t o t he I rDA int eroperabilit y prot ocols. [1]

The headset profile does not directly use TCS; see the discussion in Chapter 13.

[2]

We group the serial port profiles as listed here; Chapter 11 further describes profile family grouping.

So while t here is not a direct m apping of t he chapt ers of volum e 1 of t he specificat ion t o t hose of volum e 2, t he subj ect m at t er of corresponding part s of t hese t wo volum es does include relat ed m at erial. Therefore it is usually insufficient t o read or writ e about j ust one port ion of t he specificat ion in isolat ion. This is why t his book covers bot h volum es of t he specificat ion in it s m ain body; t his is also why t his book st rives t o explain t he m ot ivat ion for and relat ionships am ong t he various part s of t he specificat ion. The following sect ion suggest s som e m et hods t hat m ight aid in underst anding t hose port ions of t he specificat ion t hat are of m ost int erest ; if using t his book as a guide t o t he specificat ion, t hese sam e m et hods m ay be used t o det erm ine t he focus areas herein, since t he st ruct ure of Part s 2 and 3 of t he book largely m irrors t hat of version 1.0 of t he specificat ion.

35

Guide to Understanding the Specification The specificat ion version 1.0 does not include any int roduct ory inform at ion about it s purpose, scope, st ruct ure or com ponent relat ionships ( aside from a t able of cont ent s) . I t s readers will find a t it le page, som e not ices and a m ast er t able of cont ent s abrupt ly followed by t he radio specificat ion and rem aining chapt ers. Readers will find no preface, no foreword and no organized background inform at ion. This is not necessarily a bad t hing; [ 3] it prim arily result s from t he specificat ion's t echnical nat ure and direct approach t o it s subj ect m at t er. This chapt er is int ended t o supply som e of t he inform at ion t hat is not found ( or at least not explicit ly called out ) in t he specificat ion, t hus m aking t he specificat ion m ore accessible and bet t er preparing it s readers t o get t he m ost from it . [3]

After all, it helps to create a market for books such as this one.

While t he m ost st raight forward way t o read t he specificat ion is t o st art wit h page 1 of volum e 1 and cont inue reading all t he way t o t he last page of volum e 2, and while it is not our int ent t o discourage t his m et hod of reading, t his m ay be im pract ical in m any cases. We expect t hat m any readers would have difficult y absorbing t he t rem endous det ail cont ained in t he m ore t han 1,500 pages of t he com plet e version 1.0 specificat ion. Furt herm ore, m any people probably do not need t o learn all of t he det ails of every prot ocol and profile, and even t hose who do m ay find it helpful t o digest t hese det ails in logical groupings, one at a t im e. The specificat ion is quit e broad, covering everyt hing from low- level radio det ails t o applicat ion soft ware considerat ions. The proj ect ed Bluet oot h m arket place is expect ed t o be j ust as broad, offering opport unit ies for m any specialized product s and skills as well as for general- purpose ones. Thus, depending upon int erest , it m ay be beneficial t o develop an individualized plan for delving int o t he specificat ion ( and int o t he m ain body of t his book) . The suggest ions offered here are int ended t o aid in doing j ust t hat . As part ial rem edy t o t he lack of int roduct ory m at erial in t he specificat ion, t he SI G has published several whit e papers in addit ion t o t he specificat ion. One of t hose whit e papers, Bluet oot h Prot ocol Archit ect ure [ Met t älä99] , is a useful overview of t he cont ent s of t he specificat ion and we recom m end it as supplem ent al reading. This paper covers som e of t he sam e t opics as Chapt ers 5 and 11 of t his book and m ay serve as a good com panion t o t hat m at erial. Once int roduct ory m at erial ( such as Part 1 and Chapt ers 5 and 11 of t his book along wit h t he cit ed whit e paper) is underst ood, m any readers m ay wish t o branch out t o part icular sect ions of t he specificat ion depending upon t heir int erest s and obj ect ives. I t is unrealist ic t o devise a reading plan t o fit every audience's need, but t his sect ion suggest s som e general guidelines. I t is hoped t hat m ost readers will be able t o use one or m ore of t hese general classificat ions t o achieve an underst anding of Bluet oot h wireless t echnology t hat is appropriat e for t heir own sit uat ion.

For General Knowledge Many readers, perhaps including st udent s, t eachers, consult ant s and ot hers who have general int erest in t he Bluet oot h t echnology and who wish t o underst and t hat t echnology in t he cont ext of t heir profession, m ay wish t o read t his book and t he specificat ion t o gain general knowledge. Such readers m ay not need t o read t he specificat ion from cover t o cover since t hey do not need t o learn every det ail of t he specificat ion t hat m ight be required by som eone im plem ent ing t he specificat ion. Our suggest ed reading plan for general knowledge is t o st udy t he profiles aft er a general overview of t he prot ocol st ack as out lined below.

36

1. Read Part 1 and Chapt er 5 of t his book and t he SI G prot ocol archit ect ure whit e paper ( cit ed above) . This m at erial helps t o put t he prot ocol st ack in cont ext . 2. Review or skim volum e 1 of t he specificat ion using Chapt ers 6 t hrough 10 of t his book as an explanat ory guide t o t he corresponding specificat ion sect ions. 3. Aft er reading Chapt er 11 as an int roduct ion t o t he profiles, st udy each profile in volum e 2 of t he specificat ion, using Chapt ers 12 t hrough 15 as an aid in underst anding t he r elat ed profiles.

From a Device Perspective A great deal of t he int erest in t he Bluet oot h t echnology com es from t hose who are concerned prim arily wit h im plem ent ing t hat t echnology in devices. Device m anufact urers, soft ware developers and original equipm ent m anufact urers who build device com ponent s need t o underst and t he det ails of t he prot ocol st ack. Readers who plan t o im plem ent Bluet oot h wireless com m unicat ion in devices, in whole or in part , should be prepared t o st udy t he core specificat ion. For t hese readers we suggest st udying t he core specificat ion ( volum e 1) aft er becom ing fam iliar wit h t he t echnology basics, and t hen reviewing t hose profiles t hat are m ost relevant for t he class of device being considered. An out line for t his reading plan is: 1. Becom e fam iliar wit h t he t echnology basics by reading Part 1 and Chapt er 5 of t his book and t he SI G whit e paper already cit ed, along wit h ot her available Bluet oot h t echnology overviews. 2. Read Chapt ers 6 t hough 10 of t his book as a group in preparat ion for st udying t he core specificat ion. 3. Thoroughly read all of volum e 1 of t he specificat ion ( or at least all of t hose sect ions t hat pert ain t o t he im plem ent at ion at hand) . 4. Read Chapt er 11 of t his book t o det erm ine which profiles are relevant t o t he device or devices being creat ed and t hen review t hose corresponding profiles in volum e 2 of t he specificat ion in t andem wit h t he corresponding chapt ers of Part 3 of t his book. Soft ware developers in part icular m ay need t o underst and one or m ore profiles for use in cert ificat ion and t est ing. The generic access profile and t he service discovery applicat ion profile m ay be of int erest t o all im plem ent ers; ot her profiles m ay apply only for cert ain im plem ent at ions. [ 4] [ 4]

For exam ple, cam era or key board developers are unlikely t o be int erest ed in t elephony profiles, and developers of a sim ple pager m ay not be int erest ed in fax or dial- up net working profiles.

From a Solutions Perspective Bluet oot h wireless t echnology present s opport unit ies for m any new solut ions- not only t hose described by exist ing or planned usage m odels and profiles but also m any sort s of new applicat ions of t he t echnology which will undoubt edly be invent ed in t he fut ure. I nnovat ors who are driving t hese new solut ions ( especially, alt hough not exclusively soft ware developers and syst em archit ect s) m ay need t he fullest understanding of t he Bluet oot h t echnology. Those who are developing Bluet oot h applicat ions and solut ions oft en will need t o underst and t he det ails of exist ing profiles and also are likely t o require a t horough underst anding of t he prot ocol st ack. Knowing t he capabilit ies and lim it at ions of prot ocols is im port ant for anyone set t ing out t o invent new usage m odels. While t he reading plan for t hose who wish t o be t horoughly im m ersed in t he Bluet oot h t echnology, including solut ions developers, m ight be sum m arized sim ply as " read everyt hing," a m ore pract ical out line m ay be:

37

1. St art wit h t he t ypical background inform at ion already not ed, nam ely Part 1 and Chapt er 5 of t his book, t he SI G prot ocol archit ect ure whit e paper and any ot her aut horit at ive overview inform at ion. 2. Read t he rem ainder of Part 2 of t his book as a prelude t o a st udy of volum e 1 of t he specificat ion. 3. Thoroughly read and underst and t he core specificat ion, referring back t o t he corresponding chapt ers of t his book where necessary. 4. Read all of Part 3 of t his book in preparat ion for scrut inizing volum e 2 of t he specificat ion. 5. St udy t he profile specificat ions ( volum e 2) wit h Part 3 of t his book at hand. Solut ions developers especially will want t o keep abreast of new developm ent s in Bluet oot h wireless com m unicat ion. For t hese people, cont inued reading of current art icles in t rade and professional j ournals is advisable, as is t aking advant age of addit ional learning opport unit ies such as developers conferences.

38

Part 2: The Bluetooth Specification Examined This book cont inues wit h an explorat ion of volum e 1 of t he Bluet oot h specificat ion, called t he core specificat ion. Chapt er 5 present s t he overall Bluet oot h prot ocol st ack and describes t he relat ionships am ong it s layers. The rem aining chapt ers of Part 2 exam ine each layer of t he st ack in t urn, from t he lowest layers t o t he higher layers. Chapt er 6 discusses t he Bluet oot h radio, baseband, link cont roller and link m anager layers. Chapt er 7 explores t he logical link cont rol and adapt at ion prot ocol ( L2CAP) layer and host cont roller int erface ( HCI ) . Chapt er 8 discusses t he RFCOMM and Service Discovery Prot ocol ( SDP) layers, while Chapt er 9 exam ines t he prot ocols associat ed wit h applicat ion int eroperabilit y wit h t he I nfrared Dat a Associat ion ( I rDA) st andard. Finally Chapt er 10 describes t he t elephony cont rol and audio prot ocols. Part 2 is int ended t o m ake im port ant inform at ion from t he Bluet oot h specificat ion m ore accessible and underst andable while explaining t he m ot ivat ion and rat ionale for key elem ent s of t he specificat ion. Drawing upon our experience in helping t o develop t he specificat ion, we at t em pt here t o reveal it s im port ant elem ent s rat her t han sim ply echoing inform at ion already available t o specificat ion readers.

Chapter 5. The Bluetooth Protocol Stack The core port ion of t he Bluet oot h specificat ion cont ains t he prot ocol st ack. This st ack allows devices t o locat e, connect t o and exchange dat a wit h each ot her and t o execut e int eroperable, int eract ive applicat ions against each ot her. I n t his sect ion we present t he m aj or com ponent s of t he Bluet oot h prot ocol st ack, highlight ing t he relat ionships am ong t he various layers. The prot ocols are present ed in m ore det ail in following chapt ers.

The Protocol Stack Components Figure 5.1 depict s t he high- level com ponent s of t he Bluet oot h prot ocol st ack. The elem ent s of t he st ack ( prot ocols, layers, applicat ions, and so on) are logically part it ioned int o t hree groups: • • •

t he t ransport prot ocol group; t he m iddleware prot ocol group; and t he applicat ion group. Figure 5.1. A high-level view of the Bluetooth stack.

39

Tr a n spor t pr ot ocol gr ou p: This group is com posed of t he prot ocols designed t o allow Bluet oot h devices t o locat e each ot her and t o creat e, configure and m anage bot h physical and logical links t hat allow higher layer prot ocols and applicat ions t o pass dat a t hrough t hese t ransport prot ocols. The prot ocols in t his group include t he radio, baseband, link m anager, logical link and adapt at ion and t he host cont roller int erface. [ 1] [1] Strictly speaking, the host controller interface is not a communications protocol. However, the host controller interface specification defines formats for packets that cross a host interface and associations between these packets. For example, when packet A is transmitted, then packet B is expected in return. These formats and associations of packets are key elements of a protocol specification; hence, we group HCI with the transport protocols.

M iddle w a r e pr ot ocol gr oup: Addit ional t ransport prot ocols needed for exist ing and new applicat ions t o operat e over Bluet oot h links com prise t his group. The m iddleware prot ocol group includes bot h t hird- part y and indust ry st andard prot ocols and prot ocols developed by t he SI G specifically for Bluet oot h wireless com m unicat ion. The form er includes I nt ernet - relat ed prot ocols ( PPP, I P, TCP, and so on) , wireless applicat ion prot ocols, obj ect exchange prot ocols adopt ed from I rDA and t he like. The lat t er includes t hree prot ocols wit h a designed awareness of Bluet oot h com m unicat ions t hat facilit at e a large num ber of ot her applicat ions t o run over Bluet oot h links. A serial port em ulat or prot ocol called RFCOMM enables legacy applicat ions t hat norm ally would int erface wit h a serial port t o operat e seam lessly over Bluet oot h t ransport prot ocols. A packet based t elephony cont rol signaling prot ocol provides for advanced cont rol of t elephony operat ions, such as group m anagem ent and m obilit y support for cordless handset s and base st at ions. Finally, a service discovery prot ocol perm it s devices t o discover each ot her's services and t o obt ain inform at ion on how t o access t hose services. Applica t ion gr ou p: This group consist s of t he act ual applicat ions t hat m ake use of Bluet oot h links. These applicat ions could be legacy applicat ions t hat are unaware of Bluet oot h t ransport s, such as a m odem dialer applicat ion or a web- browsing client ; or t hey m ight be aware of Bluet oot h wireless com m unicat ion, for inst ance, applicat ions t hat use t he t elephony cont rol prot ocol for cont rolling t elephony equipm ent . Chapt ers 6 and 7 present in m ore det ail t he prot ocols in t he t ransport prot ocol group. Chapt ers 8 t hrough 10 discuss t he m iddleware prot ocols developed and adopt ed by t he SI G. Finally all of Part 3 of t his book is dedicat ed t o t he various applicat ions t hat t he profiles define. Before m oving t o t he det ails of t he various prot ocols and applicat ions, we first discuss t he key prot ocols in t he t ransport and m iddleware groups and t heir relat ionships t o each ot her.

The Transport Protocol Group Figure 5.2 shows t he organizat ion of t he prot ocols in t he t ransport group. These are t he t ransport prot ocols developed by t he SI G t o carry audio and dat a t raffic bet ween devices. I n t his chapt er, t he present at ion of t hese prot ocols is m ade in " t op- down" order, or from t he point of view of a t ransm it t ing device where t raffic passes from t he upper t ransport layers t o t he lower layers. Clearly, t raffic follows t he reverse pat h in receiving devices. This illust rat es an end- t o- end dat a flow t hrough t he prot ocols of t he t ransport group. I n subsequent chapt ers, t hese prot ocols are present ed in a " bot t om - up" order, or from t he point of view of a receiving device; t his is t he order follow ed in t he specificat ion as well.

40

Figu r e 5 .2 . Th e t r a n spor t pr ot ocol gr ou p st a ck .

The t ransport prot ocols support bot h asynchronous t ransm issions, for dat a com m unicat ions, and synchronous ( or periodic) t ransm issions, for t elephony- grade ( 64 Kbps) voice com m unicat ions. To m aint ain t he high qualit y of service expect ed for audio applicat ions, t he audio t raffic is t reat ed wit h high priorit y. Audio t raffic bypasses all of t he int erm ediary prot ocol layers and is funneled direct ly from t he audio applicat ion t o t he baseband layer, which t hen t ransm it s it in sm all packet s direct ly over t he Bluet oot h air- int erface. Before cont inuing our discussion of t he t ransport prot ocol group, we observe t hat t he prot ocols in t he t ransport prot ocol group do not belong t o t he t ransport layer ( layer 4) of t he seven- layer OSI prot ocol m odel! Wit h respect t o t he lat t er m odel, t he prot ocols in t he t ransport prot ocol group would fit best wit hin t he dat a link layer ( layer 2) and t he physical layer ( layer 1) . Collect ively, t he set of prot ocols in t he " t ransport prot ocol group" form a virt ual pipe t hat is used t o t ransport dat a from one device t o anot her across t he Bluet oot h air- int erface. These prot ocols in principle define t ransport s bet ween com m unicat ing devices; hence, t he nam ing choice for t his prot ocol group. The t erm " group of Bluet oot h t ransport prot ocols" is also used t o furt her em phasize t hat reference is m ade t o t he t ransport prot ocols developed by t he Bluet oot h SI G rat her t han t o a t ransport layer ( OSI layer 4) prot ocol. Not e t hat all of t he prot ocols in t his group are always needed t o support t he com m unicat ion bet ween Bluet oot h devices. This is not t rue for any ot her prot ocol out side t his group, even t he ones t hat have been developed by t he SI G, like RFCOMM.

The L2CAP Layer Traffic from dat a applicat ions is first rout ed t hrough t he logical link cont rol and adapt at ion prot ocol ( L2CAP) layer. The L2CAP layer shields higher- layer prot ocols and applicat ions from t he det ails of t he lower- layer t ransport prot ocols. Thus, higher layers need not be aware of t he frequency hops occurring at t he radio and baseband level nor t he specific packet form at s used for t ransm ission over t he Bluet oot h air- int erface. L2CAP support s prot ocol m ult iplexing, allowing m ult iple prot ocols and applicat ions t o share t he air- int erface. I t also enables segm ent at ion of large packet s used by higher layers int o sm aller packet s for baseband t ransm ission and t he corresponding reassem bly of t hose packet s by t he receiving device. Furt herm ore, t he L2CAP layers in t wo peer devices facilit at e t he m aint enance of t he desired grade of service by negot iat ing an accept able level of service. Based on t he request ed level of service, an L2CAP

41

layer im plem ent at ion m ay t hen exercise adm ission cont rol for new incom ing t raffic and coordinat e wit h lower layers t o m aint ain t he desired level of service. The L2CAP layer and it s over- t he- air prot ocol are described in m ore det ail in Chapt er 7.

The Link Manager Layer Link m anagers in each device negot iat e t he propert ies of t he Bluet oot h air- int erface bet ween t hem using t he link m anager prot ocol ( LMP) . These propert ies include bandwidt h allocat ion t o support a desired grade of service for dat a ( L2CAP) t raffic and periodic bandwidt h reservat ion t o support audio t raffic. Bluet oot h link m anagers in com m unicat ing devices use a challengeresponse approach for aut hent icat ing t he devices. They supervise device pairing ( creat ion of a t rust relat ionship bet ween t he devices by generat ing and st oring an aut hent icat ion key for fut ure device aut hent icat ion) and encrypt ion of t he dat a flowing over t he air- int erface bet ween t he devices whenever needed. I f aut hent icat ion fails, t he link m anagers m ay sever t he link bet ween t he devices, t hus prohibit ing any com m unicat ion bet ween t he devices. Link m anagers also support power cont rol by negot iat ing low act ivit y baseband m odes of operat ion ( int roduced in Chapt er 2 and det ailed in Chapt er 6) t hrough t he exchange of inform at ion about param et ers such as t he durat ion of t he low- act ivit y baseband m ode. Link m anagers m ay request adj ust m ent s t o t he t ransm ission power level for furt her power conservat ion as described in Chapt ers 2 and 6. The link m anager layer and it s over- t he- air prot ocol are described in m ore det ail in Chapt er 6.

The Baseband and Radio Layers The baseband layer det erm ines and inst ant iat es t he Bluet oot h air- int erface. [ 2] I t defines t he process by which devices search for ot her devices and how t hey connect t o t hem . The baseband layer defines t he m ast er and slave roles ( described in Chapt er 2) for devices—t he device t hat init iat es a connect ion process becom es t he m ast er of t he link, while t he ot her device becom es a slave. The baseband also defines how t he frequency hopping sequences used by com m unicat ing devices are form ed. I t defines t he rules for sharing t he air- int erface am ong several devices; t hese rules are based upon a t im e division duplex ( TDD) , packet - based polling schem e. I t furt her defines how synchronous and asynchronous t raffic can share t he air- int erface. For exam ple, in synchronous t ransm issions, t he m ast er t ransm it s t o and/ or polls a slave device periodically. The baseband defines t he various packet t ypes support ed for synchronous and asynchronous t raffic, as well as various packet processing procedures including error det ect ion and correct ion, signal whit ening, [ 3] encrypt ion, packet t ransm ission and ret ransm issions. The baseband layer and it s over- t he- air prot ocol are described in m ore det ail in Chapt er 6. [2]

To make an analogy to a cabled environment, it might be said that the baseband determines the "shape" and "pin configuration" of the interface. [3]

Whitening refers to signal scrambling and is discussed more fully in Chapter 6.

Not e t hat t he concept of m ast er and slave devices does not propagat e higher t han t he link m anager. At t he L2CAP layer and above, com m unicat ion is based upon a peer- t o- peer m odel and no special provisions are m ade for different act ions in a m ast er device or in a slave device. Over- t he- air packet t ransm issions are m eaningless unless properly m at ched radio t ransm it t ers and receivers, or t ransceivers, are em ployed. The Bluet oot h radio design includes several param et ers designed t o m ake it opt im al for use wit h t he Bluet oot h prot ocol st ack in short range wireless com m unicat ions. The radio sect ion of Chapt er 6 gives det ails of t he Bluet oot h radio.

HCI Layer

42

The radio, baseband and link m anager m ay be packaged t oget her int o a Bluet oot h m odule. The m odule t hen at t aches t o a host device, enabling t hat device wit h Bluet oot h wireless com m unicat ion. I n t his configurat ion, t he host cont ains t he L2CAP layer and any appropriat e port ions of t he higher layers of t he st ack. The m odule at t aches t o t he host via som e physical int erface, called t he host t ransport , such as Universal Serial Bus ( USB) , an RS- 232 port or a UART. To enable t he developm ent of int eroperable Bluet oot h m odules by different vendors, t he specificat ion defines a com m on int erface for accessing t he lower layers of t he st ack t hat reside in t he m odule, independent ly of t he part icular physical int erface t hat connect s t he host t o t he m odule. The host cont roller int erface ( HCI ) allows higher layers of t he st ack, including applicat ions, t o access t he baseband, link m anager and ot her hardware regist ers t hrough a single st andard int erface. Through HCI com m ands t he m odule m ay ent er cert ain m odes of operat ion in which, say, an aut hent icat ion operat ion or a device paging st at e m ay be perform ed. Through HCI event s, higher layers of t he st ack can be inform ed of t he result s of a device inquiry operat ion, read t he set t ings for t he audio codec residing in t he baseband, read t he signal st rengt h of incom ing t ransm issions, and so on. Of course t raffic, bot h synchronous and asynchronous, passes t hrough t he HCI as it is t ransm it t ed or received by t he host , as well. While t he HCI layer t ypically resides below t he L2CAP layer, it is not a required part of t he specificat ion. I t has been developed for t he sole purpose of enabling int eroperabilit y am ong host devices and Bluet oot h m odules, eit her of which could com e from a variet y of developers. Product im plem ent at ions need not com ply wit h t he HCI specificat ion t o support a fully com pliant Bluet oot h air- int erface. For exam ple, in a t ight ly int egrat ed, em bedded syst em , an HCI m ay not exist at all or it m ay exist at a different point of t he st ack, perhaps above L2CAP, and it m ight have a form ot her t han t he one described in t he specificat ion. The HCI and t he various host t ransport prot ocols are present ed in m ore det ail in Chapt er 7. The cont rol pat h shown in Figure 5.2 is used t o com m unicat e cont rol inform at ion bet ween layers. For exam ple, t he L2CAP layer m ight not ify t he link m anager of it s qualit y of service expect at ions, or an applicat ion could com m unicat e an end user's request for a lower power consum pt ion m ode. Typically, alt hough not exclusively, t he cont rols t hat are exposed t o t he higher layers ( including t o an end user) are for set t ing a m ode of operat ion for t he device t hat persist s unt il t hat m ode is again explicit ly alt ered t hrough an act ion t hat originat es at a higher layer. For exam ple, one m ay m anually enable or disable aut hent icat ion or encrypt ion for a given device. A high- layer ent it y, like an applicat ion or a user, could place a device in a reduced power consum pt ion m ode, which would be t ranslat ed t o a cont rol signal t hat a link m anager underst ands and support s so it can act accordingly. Sim ilarly, a device could also be placed in a discoverable m ode, where t he device responds t o inquiries sent by ot her devices, or t he device could be set t o a privat e m ode, in which t he device responds only t o connect ion request s from specific known devices, which also m ust be aut hent icat ed. The cont rol pat h is not explicit ly described in t he specificat ion, but it is int erwoven am ong t he various prot ocols in t he st ack. Nevert heless, t he HCI specificat ion includes t he bulk of t he inform at ion t hat t he cont rol pat h carries. We honor t his sam e approach, discussing t he cont rol signals carried t hrough t he cont rol pat h via t he HCI and t he various prot ocols and m odes of operat ion t hat t hese signals affect .

The Middleware Protocol Group Figure 5.3 depict s t he m iddleware prot ocol group. The m iddleware prot ocols m ake use of t he underlying t ransport prot ocols and present t o t he applicat ion layers st andard int erfaces t hat m ay be used for com m unicat ing across t he t ransport s. Each of t he m iddleware layers defines a st andard prot ocol t hat allows applicat ions t o use a higher level of abst ract ion t han would direct com m unicat ions wit h t he lower- layer t ransport prot ocols. The m iddleware prot ocols consist of:

43

• •

•

•

RFCOMM, a serial port abst ract ion; Service discovery prot ocol ( SDP) , used t o describe available services and t o locat e needed services; a set of I rDA int eroperabilit y prot ocols adopt ed from t he I rDA st andard t hat enables int eroperable use of I rDA- enabled applicat ions; and a t elephony cont rol prot ocol ( TCS) , used for cont rolling t elephone calls t hat m ight be used eit her for audio or for dat a.

Each of t hese prot ocols, along wit h Bluet oot h audio com m unicat ion ( which is not a prot ocol per se but is considered part of t he soft ware st ack) is described separat ely below and in det ail in t he corresponding chapt ers t hat follow.

Figu r e 5 .3 . Th e m iddle pr ot ocol gr ou p st a ck .

RFCOMM Layer Serial port s are one of t he m ost com m on com m unicat ions int erfaces used wit h com put ing and com m unicat ions devices t oday. Most serial com m unicat ion involves a cable for t ransferring dat a across serial port s. Since Bluet oot h wireless com m unicat ion is aim ed at replacing cables, support for serial com m unicat ions and relat ed applicat ions is an im port ant feat ure for t he init ial set of cable- replacem ent usage m odels. Peer- t o- peer file and obj ect t ransfer, dat a synchronizat ion and dial- up net working are som e applicat ions t hat com m only use serial com m unicat ions ( and associat ed cables) . To facilit at e t he use of serial com m unicat ions over Bluet oot h wireless links, t he prot ocol st ack defines a serial port abst ract ion called RFCOMM. RFCOMM present s a virt ual serial port t o applicat ions; t his facilit at es t he easy m igrat ion of applicat ions m odeled for cabled serial com m unicat ions t o t he realm of wireless serial com m unicat ions. An applicat ion can use RFCOMM very m uch like a st andard wired serial port t o accom plish scenarios such as synchronizat ion, dialup net working and ot hers wit hout significant changes ( if any) t o t he applicat ion. Thus t he int ent of t he RFCOMM prot ocol is t o enable legacy, serial port - based applicat ions t o use Bluet oot h t ransport s. RFCOMM is m odeled on t he European Telecom m unicat ions St andards I nst it ut e ( ETSI ) TS 07.10 st andard. This st andard defines m ult iplexed serial com m unicat ions over a single serial link. The Bluet oot h specificat ion adopt s a subset of t he ETSI 07.10 st andard and also defines som e adapt at ions designed specifically for Bluet oot h com m unicat ion.

44

Because serial com m unicat ions are so prevalent in digit al devices, t he serial port capabilit ies t hat RFCOMM provides t o applicat ions m ake it an im port ant part of t he prot ocol st ack, especially for enabling legacy applicat ions based upon version 1.0 of t he specificat ion. Det ails of t he RFCOMM layer can be found in Chapt er 8.

SDP Layer I n som e respect s, inst ant iat ing any of t he Bluet oot h usage m odels m ight be viewed as m aking use of som e set of services. A prim ary m ot ivat ion for form ing net works of devices is t o allow t hose devices t o com m unicat e wit h each ot her and t hus avail t hem selves of each ot her's services. I n t radit ional net works such as Et hernet LANs, services such as file serving, print serving, nam e serving, bridges and gat eways are provided by som e set of devices ( usually considered " servers" ) in t he net work so t hat ot her devices ( usually considered " client s" ) can use t hem . I n m any cases t he client s locat e t hese net work services t hrough som e st at ic configurat ion; t his configurat ion is oft en est ablished and m aint ained by a syst em adm inist rat or who configures t he client devices ( or gives t he necessary configurat ion inform at ion t o t he users of t hose devices, who in t urn configure t hem ) . For dynam ic ad hoc net works such as t hose t hat could be enabled by Bluet oot h wireless com m unicat ions, t hough, t his sort of st at ic configurat ion is insufficient . Any t wo or m ore devices m ight begin com m unicat ing over Bluet oot h links on t he spur of t he m om ent , and if t hese devices are t o be able t o m ake use of each ot her's services t hey require a m ore dynam ic m eans of locat ing t hose services. Once a com m unicat ion channel has been est ablished, a next logical st ep in device com m unicat ions m ight be t o find out about services t hat are available t o t he device. This is what t he Bluet oot h service discovery prot ocol ( SDP) addresses. SDP defines a st andard m et hod for Bluet oot h devices t o discover and learn about t he services offered by ot her devices; sym m et rically, it defines a way for devices t o describe t hose services offered t o ot her devices. Service discovery is a key com ponent in enabling end- user value in dynam ic net works. The Bluet oot h service discovery prot ocol is designed specifically t o enable t his funct ion in an efficient and opt im ized m anner wit hin environm ent s t hat exploit Bluet oot h wireless com m unicat ion. SDP is described in det ail in Chapt er 8.

IrDA Interoperability Protocols Chapt er 2 described infrared wireless com m unicat ion and it s resem blance in som e respect s t o Bluet oot h wireless com m unicat ion. The I nfrared Dat a Associat ion ( I rDA) has defined prot ocols for exchanging and synchronizing dat a in wireless environm ent s. The SI G has chosen t o adopt several of t he I rDA prot ocols and dat a m odels because I rDA and Bluet oot h wireless com m unicat ion share som e im port ant at t ribut es, usage scenarios and applicat ions. A fundam ent al requirem ent for exchanging dat a am ong devices is t o define t he form at , bot h synt ax and sem ant ics, of t hat dat a. The infrared obj ect exchange ( I rOBEX or oft en, j ust OBEX) prot ocol developed by t he I rDA is a session prot ocol for peer- t o- peer com m unicat ion. Am ong t he applicat ions in which OBEX can be used is t he exchange of well- defined obj ect s. Dat a obj ect s such as elect ronic business cards ( vCard form at ) , e- m ail or ot her m essages ( vMessage form at ) , calendar ent ries ( vCal form at ) and ot hers can all be exchanged using t he OBEX prot ocol. OBEX is t he fundam ent al building block upon which t he usage m odels of file t ransfer ( obj ect exchange) and obj ect push are built . Addit ionally, infrared m obile com m unicat ions ( I rMC) , anot her I rDAdefined prot ocol, enables t he synchronizat ion of t hese sam e obj ect s. The I rDA int eroperabilit y layers of t he prot ocol st ack are int ended t o prom ot e int eroperabilit y at t he applicat ion layer. They are described m ore fully in Chapt er 9.

45

Networking Layers Bluet oot h wireless com m unicat ion uses a peer- t o- peer net work t opology rat her t han a LAN st yle t opology. Nevert heless, t he t echnology does m ake allowances for net working, in part icular connect ing t o larger net works t hrough a dial- up connect ion or via a net work access point . The specificat ion also discusses int eroperabilit y wit h t he Wireless Applicat ion Prot ocol ( WAP) , a specificat ion for wireless net working used by devices such as m obile t elephones. Dial- up net working uses t he AT com m and layer of t he m iddleware prot ocol st ack, which is discussed below, t o est ablish a connect ion t o a net work. I n m any cases, t he net work being accessed is one t hat uses t he I nt ernet Prot ocol, referred t o as an I P net work. Once a dial- up connect ion t o an I P net work is est ablished, st andard I nt ernet prot ocols ( such as TCP, UDP, HTTP and so on) can be used by t he device ( perhaps a not ebook or handheld com put er) t hat init iat ed t he net work connect ion t o int eract wit h t he net work. A device m ight also connect t o an I P net work via a net work access point as described in t he LAN Access Using PPP Profile. I n t his case, a Bluet oot h link connect s t he device t o a net work access point ; t he net work access point is in t urn connect ed t o t he larger ( m ost likely, but not necessarily wired) net work. The I nt ernet point - t o- point prot ocol ( PPP) is used over t he Bluet oot h link t o connect t o t he access point . As wit h dial- up net working, once t he PPP connect ion is est ablished, st andard I nt ernet prot ocols can be used t o int eract wit h t he net work. Access t o a WAP net work using a WAP gat eway works sim ilarly; t he sam e sort of PPP connect ion is est ablished t o an I P net work access point over which st andard WAP prot ocols can be used t o int eract wit h t he net work. I t is wort h not ing t hat release 1.0 of t he specificat ion does not define a profile or an inst ance of t he prot ocol st ack t hat support s t he use of I nt ernet prot ocols such as TCP/ I P direct ly over Bluet oot h links. The only m eans of I P net work access defined in version 1.0 of t he specificat ion is t hrough t he use of PPP as described above. While it cert ainly should be possible t o direct ly operat e an I P prot ocol st ack using Bluet oot h wireless com m unicat ion as t he bearer, t he SI G has not defined an int eroperable m anner ( t hat is, a profile) for such operat ion. I n all likelihood, fut ure revisions t o t he specificat ion will address t he direct use of I nt ernet prot ocols wit h Bluet oot h wireless com m unicat ion.

TCS Layer and Audio As previously not ed, one key advant age of Bluet oot h wireless com m unicat ions is it s abilit y t o carry voice t raffic as well as dat a. While t he prot ocol layers discussed t o t his point exist prim arily for use wit h dat a t raffic, t he Bluet oot h t elephony cont rol specificat ion ( TCS) layer is designed t o support t elephony funct ions, including call cont rol and group m anagem ent . These operat ions are oft en associat ed wit h voice calls in which TCS is used t o set up t he call param et ers; once a call is est ablished, a Bluet oot h audio channel can carry t he call's voice cont ent . TCS m ight also be used t o set up dat a calls, such as would be used wit h t he dial- up net working profile; in t his case, t he call cont ent is t hen carried as st andard dat a packet s over L2CAP. The TCS prot ocols are com pat ible wit h t he I nt ernat ional Telecom m unicat ions Union Telecom m unicat ion ( I TU- T) Q.931 specificat ion. Because t hey use a binary encoding, t hese prot ocols are referred t o in t he specificat ion as TCS- BI N. During developm ent of t he specificat ion, t he SI G also considered a second TCS prot ocol called TCS- AT. TCS- AT defined a m odem cont rol prot ocol ( oft en called AT com m ands) t hat flowed t hrough t he RFCOMM layer. While AT com m ands over RFCOMM are indeed used for som e applicat ions, t he specificat ion does not define a separat e prot ocol for TCS- AT. TCS- BI N is appropriat e for som e of t he release 1.0 t elephony- based profiles; applicat ions t hat need t o use AT com m ands over t he RFCOMM serial int erface are free t o do so ( as shown in Figure 5.3) , but t he specificat ion does not define t hese AT com m ands as a separat e

46

prot ocol. Several of t he version 1.0 profiles, including headset , fax, and dial- up net working, all use AT com m ands over RFCOMM rat her t han t he TCS- BI N prot ocol. The TCS- BI N prot ocol includes call cont rol funct ions, group m anagem ent funct ions and a m et hod for devices t o exchange call signaling inform at ion wit hout act ually placing a call or having a call connect ion est ablished. Each of t hese facet s of TCS is det ailed in Chapt er 10. Audio, especially voice audio, is t reat ed uniquely in Bluet oot h com m unicat ion. Because audio t raffic is isochronous, m eaning t hat it has a t im e elem ent associat ed wit h it , voice audio t raffic t ypically is rout ed direct ly t o and from t he baseband layer; it does not go t hrough upper layers such as L2CAP. [ 4] Special baseband packet st ruct ures, called synchronous connect ion- orient ed ( or SCO) packet s are defined for use wit h t ypical audio t raffic. Bluet oot h com m unicat ion allows for up t o t hree audio channels at one t im e ( wit h som e bandwidt h left over for dat a t raffic) . [4] Packetized digital audio could be carried as standard data packets using L2CAP, but this case would be treated as data traffic. In general, when we refer to voice or audio throughout this book we are speaking of the Bluetooth audio traffic carried directly over the baseband link in SCO packets.

Bluet oot h audio com m unicat ion t akes place at a rat e of 64 kilobit s per second ( Kbps) using one of t wo dat a encoding schem es: 8- bit logarit hm ic pulse code m odulat ion ( PCM) or cont inuous variable slope delt a ( CVSD) m odulat ion. Com pression t echniques called A- law and µ- law are applied for PCM audio. Since voice is a prim ary applicat ion of audio com m unicat ion ( especially in devices such as sm art phones t hat use Bluet oot h wireless com m unicat ion) , audio is oft en equat ed wit h voice. Of course, voice is not t he only sort of audio t raffic t hat can be carried by t he Bluet oot h baseband. So long as t he audio st ream can be sufficient ly rendered at 64 Kbps, it can be t ransm it t ed and received over Bluet oot h links. Thus, in addit ion t o voice, Bluet oot h audio channels could carry ot her form s of audio, such as som e m usic[ 5] or short audio clips. [5] Bluetooth audio, being optimized for voice traffic, is not designed to carry music of high quality, such as CD-quality music. Support of music is likely to require the use of compression techniques.

Because voice is an int egral part and key at t ribut e of Bluet oot h wireless com m unicat ion, it m ay be som ewhat surprising t hat only a few pages of t he specificat ion deal direct ly wit h audio. This is not because audio is unim port ant ; rat her it is m ost ly because audio t raffic is carried direct ly over t he baseband in packet s designed for t hat purpose. Thus it is not necessary t o include lengt hy explanat ions of audio t raffic - t he form at of t he audio dat a is specified using exist ing st andards and t hat , for t he m ost part , is t hat . I t is, however, quit e im port ant t o underst and t he baseband SCO packet st ruct ure and usage t o achieve a fuller underst anding of Bluet oot h audio com m unicat ion. Thus, while audio is explained in m ore det ail in Chapt er 10, it is also indirect ly det ailed in t he baseband discussion of Chapt er 6.

The Application Group While som e of t he prot ocols t hat we refer t o here as m iddleware prot ocols ( especially I rDA int eroperabilit y prot ocols like I rOBEX or I rMC) m ight be considered by som e t o be applicat ionlevel prot ocols, t his is not what we m ean when we writ e about t he applicat ion group. The applicat ion group here refers t o soft ware t hat resides above t he prot ocol st ack as defined by t he SI G. This is soft ware t hat is supplied by device m anufact urers, independent soft ware vendors or ot hers which exercises t he prot ocol st ack t o accom plish som e funct ion t hat benefit s t he user of a Bluet oot h device. Applicat ion soft ware as defined here is depict ed in Figure 5.4, which illust rat es several possibilit ies for t he organizat ion of Bluet oot h applicat ion soft ware.

47

Figu r e 5 .4 . Ge n e r a l vie w of t h e a pplica t ion gr ou p, w it h possible a pplica t ion or ga n iza t ion, in clu din g a da pt a t ion la ye r a n d com m on a pplica t ion se r vice s.

Of m ost int erest wit hin t he applicat ion group are t hose applicat ions t hat inst ant iat e t he Bluet oot h profiles. That is, given a Bluet oot h prot ocol st ack in a device, som eone st ill needs t o writ e applicat ion soft ware t o drive t hat st ack t o accom plish funct ions such as dial- up net working, file t ransfer, headset com m unicat ions and so on. The SI G defines only t he m iddleware and t ransport prot ocols for t he st ack; it does not define applicat ion prot ocols per se nor does it define applicat ion program m ing int erfaces ( API s) . Yet applicat ions clearly are needed t o accom plish t he usage scenarios t hat are envisioned for Bluet oot h wireless com m unicat ions. To realize a Bluet oot h profile, it is t he added applicat ion code t hat uses t he underlying prot ocol st ack t o supply value t o an end user. While a profile defines how int eroperable applicat ions t hat address various usage cases are t o be built , t he look and feel of t hese applicat ions is not defined in t he specificat ion. Applicat ion soft ware developers have sufficient lat it ude t o different iat e t heir product s wit h added feat ures or user int erfaces, wit hout violat ing t he int eroperabilit y guidelines spelled out in t he profiles. I t m ight be t he case t hat som e exist ing ( " legacy" ) soft ware t hat was designed for use wit h t ransport s ot her t han Bluet oot h wireless com m unicat ion can be em ployed using Bluet oot h links. Because t he SI G has defined layers of t he prot ocol st ack, such as t he I rDA int eroperabilit y and RFCOMM layers, t o support such legacy soft ware, it could be possible for t hese exist ing applicat ions t o t ake advant age of Bluet oot h links wit h lit t le or no change. Exam ples include exist ing I rDA applicat ions for obj ect exchange or synchronizat ion and dial- up net working applicat ions. These applicat ions all use exist ing prot ocols which are support ed in Bluet oot h environm ent s, and t ypically t hey are designed t o work over a serial port . Since t he prot ocol st ack includes t he RFCOMM serial port abst ract ion, m any exist ing applicat ions of t hese and ot her t ypes should be able t o be m apped from I rDA or serial cable environm ent s t o Bluet oot h environm ent s in a st raight forward m anner, wit h m inor ( if any) changes t o t hose applicat ions. One way t o accom plish t his on som e plat form s m ight be t o develop a t hin layer of Bluet oot h adapt at ion soft ware t hat m aps exist ing serial and ot her com m unicat ions for t he plat form t o t he corresponding Bluet oot h com m unicat ions st ack, as illust rat ed in Figure 5.4.

48

Anot her opt ion is t o develop new applicat ions specifically designed t o operat e in Bluet oot h environm ent s. I n cases where no exist ing applicat ion accom plishes a Bluet oot h usage case, or when it is desirable t o include applicat ion feat ures t hat exploit unique capabilit ies in t he prot ocol st ack, a new applicat ion m ay be a good approach. When applicat ions are developed specifically t o leverage Bluet oot h wireless com m unicat ion for som e plat form , oft en it m ay be advant ageous t o develop com m on services for t hose applicat ions. Such com m on services m ight include securit y services, connect ion m anagem ent services, SDP services, and so on. These com m on applicat ion services m ight be realized wit h applicat ion- level code such as a securit y m anager ( see [ Muller99] for a discussion of t his t opic) , a Bluet oot h m anagem ent console ( perhaps wit h associat ed user int erface t hat allows a user t o select devices and services in a piconet wit h which he wishes t o int eract ) , a com m on SDP client and server ( again perhaps wit h a user int erface for service searching and browsing) , and so on. Figure 5.4 includes a represent at ion of t hese com m on applicat ion services. I f t he specificat ion does not define API s, how can st andard applicat ions for Bluet oot h usage cases be developed? The answer lies in t he profiles. Recall t hat profiles are developed t o est ablish a base point for use of t he prot ocol st ack t o accom plish a given usage case in an int eroperable m anner. Because Bluet oot h wireless com m unicat ion is expect ed t o be support ed in a plet hora of device t ypes, on various plat form s, t he specificat ion of a single st andard API t hat would be appropriat e for t he full range of devices and plat form s could be quit e difficult , t o say t he least . But since t he SI G has chosen profiles as t he m eans t o est ablish int eroperabilit y am ong all of t hese devices, it seem s t hat t hese sam e profiles can provide guidance for developing applicat ions on t he m any plat form s t hat are relevant for Bluet oot h t echnology. As not ed above, bot h legacy applicat ions and applicat ions developed specifically t o use Bluet oot h links could realize Bluet oot h profiles. When a t echnology is incorporat ed int o a plat form and result s in t he need for new API s, t hose API s are oft en best developed by expert s on t hat plat form rat her t han by expert s on t he t echnology. Thus t he SI G has chosen not t o specify Linux® API s, Windows® API s, Sym bian™ API s or any ot her API s; inst ead t he profiles define t he necessary funct ion t o enable plat form expert s t o develop appropriat e API s for use wit h Bluet oot h applicat ions on relevant plat form s. So, even t hough API s are not included in t he specificat ion, t he profiles do indeed give direct ion t o applicat ion developers. Som e profiles do t his m ore direct ly t han ot hers. The service discovery applicat ion profile, for exam ple, describes pot ent ial applicat ion program m ing m odels and defines service discovery prim it ives t hat could in a st raight forward m anner m ap t o API s on a given plat form . Applicat ion developm ent is not lim it ed t o soft ware t hat inst ant iat es profiles. As wit h devices, t he landscape for applicat ions is broad, perhaps even virt ually unlim it ed. While t he release 1.0 profiles define a base set of int eroperable applicat ions, and while new profiles will undoubt edly cont inue t o be developed, t hese are not t he only usage cases for which applicat ions are expect ed t o be writ t en. I ndust ry innovat ors are likely t o develop m any new uses for t he Bluet oot h t echnology and t o creat e t he applicat ion soft ware t o support t hese new usage scenarios. As m ore soft ware cont inues t o be developed t o enable t he exist ing profiles on m ult iple plat form s, t he API s developed for and experience gained in t hat soft ware developm ent should provide a foundat ion for new applicat ions. The opport unit y for t hese new applicat ions is t rem endous.

49

Chapter 6. The Lower Protocols of the Transport Group This chapt er and t he following one present t he prot ocols in t he t ransport prot ocol group, from t he radio up t o and including L2CAP. I n t he Bluet oot h specificat ion, t hese prot ocols are det ailed in over 600 pages. I t is not wit hin t he scope of t his book t o recreat e t he algorit hm ic and im plem ent at ion det ails of t he specificat ion. I nst ead, t he key com ponent s of t he prot ocols are highlight ed. Readers who m ay want t o learn about t he prot ocols in m ore det ail should supplem ent t his reading wit h t he st udy of t he corresponding part s of t he specificat ion. This chapt er focuses on t he lower- level funct ions ( including t he over- t he- air prot ocols and inform at ion processing) in a Bluet oot h syst em , which t ypically are perform ed wit hin t he Bluet oot h hardware/ firm ware m odule as shown in Figure 6.1. The host I / O port ion is covered in t he next chapt er in t he present at ion of t he host cont roller int erface.

Figu r e 6 .1 . H igh - le ve l fu n ct ion a l com posit ion of a Blu e t oot h m odu le .

As shown in Figure 6.1, a Bluet oot h device [ 1] represent s t he com plet e physical ent it y ( such as a not ebook com put er, a digit al phone, an inform at ion appliance, and so on) t hat cont ains applicat ions t hat can com m unicat e using t he Bluet oot h wireless t echnology incorporat ed in t hat device. Here we assum e t hat a device is associat ed wit h one and only one t ransport prot ocol group im plem ent at ion and air- int erface. However, as m ent ioned in t he previous chapt er and furt her elaborat ed in t he next one, t he L2CAP layer support s t he m ult iplexing of several higherlayer prot ocols, like RFCOMM, SDP, and so on, and hence m iddleware prot ocol st acks and applicat ions, as well. [1] The terms unit, node, station, and so on may (and have) also been used instead of the term device. Insofar as possible, however, the use of these other terms is avoided. The reason for this choice will become apparent later.

The design point of t he Bluet oot h t ransport prot ocols is dict at ed prim arily by low m anufact uring com plexit y, associat ed low cost and fast t im e t o m arket . For t his reason, a low- cost , easy- t oim plem ent , frequency- hopping spread- spect rum radio solut ion was select ed. I n addit ion, t he select ion of a m ast er/ slave archit ect ure for t he baseband t ransm ission was dict at ed by t he ad hoc nat ure of t he syst em s considered. I n part icular, Bluet oot h piconet s can form spont aneously am ong disparat e devices wit h vast ly different power and com put ing capabilit ies, unlike wireless LAN syst em s which are designed prim arily t o support a wireless ext ension of LAN connect ivit y services t o relat ively " power- unconscious" personal com put ers. To support ad hoc connect ivit y wit h m inim al ( if any) st at e m aint ained by t he Bluet oot h devices, piconet s are dynam ically form ed in isolat ion wit hout t he support of t hird- part y ( infrast ruct ure) cont rol signaling. For as long as needed, t he m ast er of a piconet serves as t he cont rol point for t he com m unicat ions on t he piconet . For t he durat ion of t he exist ence of a piconet , t he operat ion

50

of a m ast er resem bles t hat of a base st at ion of a picocellular syst em . Thus, t he Bluet oot h t echnology perm it s t he spont aneous creat ion of a t em porary picocellular syst em , where t raffic is regulat ed by a spont aneously creat ed base st at ion, t he m ast er, t hat regulat es t he t raffic t o and from t he ot her m em ber of t he picocell, t he slaves. Recall from previous chapt ers t hat t he Bluet oot h t echnology perm it s t he creat ion of m ult iple, ad hoc picocellular syst em s t hat rem ain operat ional even in cases of t em poral and spatial overlapping. The use of m ast er and slaves reduces t he com plexit y of t he design and t hus t he cost of deploying t he Bluet oot h t echnologies. The rest of t his chapt er highlight s t he Bluet oot h radio; t he link cont roller and t he baseband funct ions it cont rols, like piconet creat ion and t he m edium access prot ocol; and t he link m anager t hat configures and m anages t he links bet ween devices. I n t he reference im plem ent at ion of a Bluet oot h m odule, t he radio and t he link cont roller t ypically are im plem ent ed in hardware while t he link m anager is in firm ware. As such, t he radio and t he link cont roller ( wit h it s baseband funct ions) were t he first part s of t he specificat ion t o m at ure, providing a st able enough hardware specificat ion for chip designers t o use in designing t heir early Bluet oot h chipset s. The link m anager specificat ion originally was focused prim arily on securit y- relat ed t ransact ions. The SI G's furt her work on t he link m anager specificat ion has enriched it over t im e t o t ake full advant age of t he capabilit ies available in t he baseband specificat ion.

The Bluetooth Radio The Bluet oot h syst em operat es in t he 2.4 GHz indust rial, scient ific, and m edical ( I SM) band. The I SM bands are license- free bands set aside for use by indust rial, scient ific and m edical wireless equipm ent . Regulat ory aut horit ies around t he world have opened t he I SM bands for use by lowpower syst em s t hat can be operat ed wit hout t he need for a license but nevert heless under st rict regulat ions. I n t he Unit ed St at es, t hese regulat ions are set by t he Federal Com m unicat ions Com m ission ( FCC) and are det ailed in t he Code of Federal Regulat ions part 15 [ FCC99] ; sect ion 15.247 of t he FCC regulat ions deals wit h t he operat ional rules of int ent ional radiat ors operat ing in t he various I SM bands including t he 2.4 GHz band. The 2.4 GHz I SM band is a globally available radio band, albeit not frequency harm onized. Table 6.1 shows t he I SM frequency availabilit y in t he m aj orit y of count ries around t he globe.

Ta ble 6 .1 . Lice n se - fr e e fr e qu e n cy a lloca t ion in t he 2 .4 GH z ba n d. 2 .4 GH z I SM ba nd ( M H z) 2,400.0 – 2,483.5

Fr e qu e n cy ch a n ne ls ( M H z) k = 0 , 1 , …, m - 1 2,402 + k; m = 79

[1]

1. "LGB" stands for "lower guard band."

[2]

2. "UGB" stands for "upper guard band"

LGB [ 1 ] ( M H z) 2.0

UGB [ 2 ] ( M H z) 3.5

The radio part of t he specificat ion consist s m ost ly of a series of design specificat ions for Bluet oot h t ransceivers, like in- band and out - of- band spurious em issions, frequency accuracy, co- channel and adj acent - channel int erference, out - of- band blocking, int erm odulat ion charact erist ics, and so on. The select ion of t he radio design specificat ions is driven by t he requirem ent t o allow t he developm ent of high- qualit y, low- cost t ransceivers t hat com ply wit h t he various 2.4 GHz I SM band regulat ions around t he world. The num erous design param et ers plus t he radio t est ing condit ions are not repeat ed here. Readers int erest ed in t he Bluet oot h radio design can find an abundance of inform at ion in t he corresponding part of t he specificat ion. Since no new dat a- exchange prot ocols nor dat a-

51

processing algorit hm s were developed for t he Bluet oot h radio, t he radio part of t he specificat ion was t he first t o be com plet ed. The errat a t o t his port ion of t he specificat ion are m inim al, and t he few t hat surface pert ain m ost ly t o t he accom m odat ion of new regulat ions or refinem ent of t he radio t est ing procedures. The Bluet oot h t ransceiver is a frequency- hopping spread- spect rum ( FHSS) radio syst em operat ing over a num ber m of 1 MHz- wide channels. While for t he m aj orit y of count ries m = 79, as shown in Table 6.1, regulat ions in cert ain count ries m ay furt her const rain t he license- free frequency spect rum for t he 2.4 GHz I SM band. Thus, t he Bluet oot h radio ( and t he baseband described in t he next sect ion) design can accom m odat e t wo alt ernat ives t hat operat e over 79 or 23 channels, each one of which is 1 MHz wide. For frequency- hopping syst em s operat ing in t he 2.4 GHz I SM band, t he FCC part 15.247 regulat ions rest rict t he m axim um peak out put power of t he radiat or t o no m ore t han 1 wat t ( 30 dBm ) . Moreover, at least 75 out of t he 79 frequency channels m ust be used pseudo- random ly wit h a t ot al residence t im e in each of t he frequencies not t o exceed 0.4 seconds wit hin a 30- second period. A Bluet oot h radio ut ilizes t he m axim um num ber of channels available, 79 in t he Unit ed St at es, and it hops at a high rat e, 1,600 hops per second, pseudo- random ly across all t hese frequencies t o achieve high noise resilience. The use of direct - sequence spread- spect rum ( DSSS) syst em s, which are also perm it t ed in t he 2.4 GHz I SM band, m ay be prohibit ively cost ly for t he low- cost requirem ent of Bluet oot h radios. Figure 6.2 sum m arizes t he key operat ions in t he Bluet oot h radio. The figure also shows a pair of logical int erfaces for carrying dat a and cont rol inform at ion bet ween t he radio and t he rest of t he Bluet oot h syst em . Here dat a relat es t o all inform at ion t hat is t ransm it t ed or received over t he air. The cont rol inform at ion cont rols t he behavior of t he radio. On t he t ransm it side, t his includes t he carrier frequency t o which t he t ransm it t er needs t o t une prior t o t ransm ission of a bit st ream of inform at ion over t he air and t he power level t hat is t o be used for t his t ransm ission. On t he receive side, t his includes t he carrier frequency t o which t he receiver m ust t une for receiving a bit st ream of inform at ion and ( opt ionally) t he st rengt h of t he signal being received. Power- supply and t im e- signaling lines are not shown in t he figure. A st andardized set of int erfaces for t he dat a and cont rol inform at ion is not provided in t he specificat ion. Thus, chip designers and m anufact urers can choose t o int egrat e t he radio com ponent wit h t he rest of t he com ponent s of a Bluet oot h m odule in t he way t hey believe is best for a low- cost , power- efficient syst em . Table 6.2 sum m arizes som e of t he key operat ional param et ers of t he Bluet oot h radio.

Figu r e 6 .2 . Th e Blu e t oot h r a dio ope r a t ion s.

52

Ta ble 6 .2 . Ke y ope r a t iona l pa r a m e t e r s of t h e Blu e t oot h r a dio spe cifica t ion . M odula t ion

Gaussian frequency- shift keying ( GFSK)

BT product [ 3] 0.5; m odulat ion index: 0.28 – 0.35

Sym bol r a t e

1 Msym bol per second

using t he binary GFSK, t his t ranslat es int o 1 Mbps raw link speed; bit t ransm ission t im e: 1 µsec

Fr e qu e n cyh opping r a t e

1,600 hops per second, t ypical 3,200 hops per second for inquiries and pages

Tr a n sm it pow e r

Re ce ive r se n sit ivit y

residence t im e: 625 µsec per hop

residence t im e: 312.5 µsec per hop

Class 3: 0 dBm ( 1 m W)

a t ypical Bluet oot h radio; opt ional power cont rol t o below –30 dBm

Class 2: 4 dBm ( 2.5 m W)

opt ional power cont rol as above

Class 1: 20 dBm ( 100 m W)

required power cont rol t o at least 4 dBm ; opt ional power cont rol as above

a Bluet oot h receiver m ust at t ain a raw bit error rat e ( BER) of 0.1% wit h an input signal level of –70 dBm or lower

t he –70 dBm sensit ivit y level shall be at t ained for any input signal generat ed by any com pliant Bluet oot h t ransm it t er

[3] The term "BT product" is not short for "Bluetooth product." It is a parameter describing the quality of transmitted waveforms expressed as the product of the bandwidth of the modulation filter and the bit time.

The t ransm it power and receiver sensit ivit y values are exam ples of design decisions t hat were m ade t o reduce cost and power requirem ent s for t he Bluet oot h radio. An I EEE 802.11 wireless local area net work ( WLAN) m ay use up t o 30 dBm ( 1000 m W) of t ransm it power in t he Unit ed St at es ( lower power- levels in ot her part s of t he world) and not less t han 0 dBm ( 1 m W) . Hence, an 802.11 wireless solut ion m ay not be suit able for m any power- const rained personal, port able devices. The sensit ivit y level is also m uch lower t han t hat of an 802.11 radio receiver [ 2] . This m eans t hat a sim pler Bluet oot h radio can be built at a reduced cost as com pared t o an 802.11 radio. [2] The receiver sensitivity for an IEEE 802.11b radio receiver, which uses DSSS, is specified to be –80 dBm for a frame error rate of 8% for a 1024-byte MAC protocol data unit when a 2 Mbps DQPSK modulation is used. For more information on the IEEE 802.11 WLANs see [IEEE99]

The Link Controller and Baseband As discussed in t he previous sect ion, t he radio deals wit h t he act s of sending and receiving dat a over t he air. Out side t he scope of t he radio's responsibilit ies are considerat ions such as what dat a t o t ransm it and when, what dat a t o wait for and when, and which carrier frequency and t ransm it power t o use. These are t he responsibilit ies of t he Bluet oot h link cont roller, described lat er in t his chapt er, t hat execut es t he baseband com m unicat ion prot ocol and relat ed processes. Figure 6.3 sum m arizes t he key funct ions of t he Bluet oot h baseband. These include piconet and device cont rol funct ions like connect ion creat ion, frequency- hopping sequence select ion and t im ing; m odes of operat ion such as power cont rol and secure operat ion; and m edium access funct ions like polling, packet t ypes, packet processing and link t ypes. These it em s are det ailed lat er in t he chapt er as we proceed t hrough t he operat ional phases of a Bluet oot h device. The figure also shows a set of logical int erfaces for carrying dat a and cont rol inform at ion bet ween t he

53

baseband and t he rest of t he Bluet oot h syst em . For t he sam e reasons m ent ioned in t he radio sect ion, t he specificat ion avoids specifying any st andardized set of int erfaces for t he dat a and cont rol inform at ion. Nevert heless, t heir presence, even on a " logical" plane, aids t his present at ion, since it allows us t o concent rat e on t he baseband operat ions in isolat ion from t he rest of t he Bluet oot h syst em .

Figu r e 6 .3 . The ba se ba n d fu n ct ion s.

Due t o t he vast and diverse areas covered by t he baseband specificat ion, t he rem ainder of t his sect ion t ries t o com bine t he inform at ion flow in t he specificat ion wit h t hat of m ore t radit ional com m unicat ion prot ocol st andards and relat ed art icles. The discussion progresses st epwise, ident ifying t he key com ponent s over which Bluet oot h com m unicat ions act ually occur. We begin wit h t he definit ion of a piconet over which Bluet oot h devices can exchange inform at ion packet s. We t hen describe fundam ent al helper elem ent s t hat assist in t he creat ion and m aint enance of t he piconet , such as t he Bluet oot h clock and frequency- hopping select ion process. Using t hese helper elem ent s, t he present at ion cont inues wit h t he descript ion of t he procedures t hat Bluet oot h devices follow t o creat e and j oin a piconet . Finally, wit h a piconet in place, we focus on prot ocols and processes like m edium access cont rol, error cont rol, securit y, power- saving operat ion and so on, t hat are exercised on t he Bluet oot h devices and on inform at ion packet s sent and received over t he piconet .

The Piconet For devices t o com m unicat e wit h each ot her using Bluet oot h wireless t echnology, t hey need t o be part of a piconet . Sim ply st at ed, a piconet com prises a shared com m unicat ions channel t hrough which m em bers of t he piconet com m unicat e. I n t he FHSS space in which Bluet oot h radios operat e, t his com m unicat ion channel consist s of a well- defined sequence of frequency hops pseudo- random ly select ed from t he set of frequencies in Table 6.1 at a nom inal rat e of 1,600 hops per second. The m em bers of t he piconet are able t o follow t he successive hops of t he frequency- hopping sequence in a synchronized m anner. Piconet s are form ed as needed and

54

endure for as long as part icipat ing devices need t o com m unicat e. The baseband operat ions define how a frequency- hopping sequence for a piconet is creat ed, how devices learn how t o follow it and hence j oin t he piconet , and how t o send and receive inform at ion packet s com m unicat ed in a coordinat ed m anner bet ween devices in t he piconet . Bluet oot h piconet s are form ed in a rat her ad hoc m anner. They are form ed on dem and am ong devices t hat want t o com m unicat e wit h each ot her wit hout relying on t he services of a dedicat ed support ent it y, such as a base st at ion in a cellular net work or a corporat e or hom e WLAN. The baseband prot ocol est ablishes t he rules according t o which t hese ad hoc connect ions are est ablished such t hat devices com m unicat e in a coordinat ed and efficient m anner. The frequency- hopping sequences t hat define t he com m unicat ion channels in piconet s are highly uncoordinat ed, or, t o be m ore precise, t hey are creat ed in a m anner t hat m akes t hem appear highly uncoordinat ed. Thus, owing t o t he frequency- hopping nat ure of t ransm issions in a piconet , m ult iple piconet s m ay exist in t im e and space wit h m inim al int erference am ong t hem selves. Mult iple piconet s overlapping, at least part ially, in t im e and space are referred t o as scat t ernet s. This opens t he possibilit y of int erpiconet com m unicat ions when devices becom e m em bers of m ult iple piconet s. Each piconet has one and only one m ast er and one or m ore slaves. These roles are t em porary ones and t hey are m eaningful only while Bluet oot h devices are m em bers of a piconet . Cert ainly, Bluet oot h devices m ay be built t o operat e only as m ast ers or only as slaves, but t his is a host applicat ion and usage scenario issue rat her t han a Bluet oot h specificat ion issue. The specificat ion generally assum es t hat a Bluet oot h device is capable of act ing bot h as a m ast er and as a slave, depending upon t he role required t o accom plish a given usage case. I n t he case of a scat t ernet , a device t hat part icipat es in m ore t han one piconet can be t he m ast er of at m ost one of t hese piconet s, while it can be a slave in several of t hem . Through a det ailed process, described lat er in t his chapt er, a m ast er and a slave m ay exchange t heir roles. I t is also possible for an " old" piconet based around an original m ast er t o be m igrat ed t o a new piconet wit h a new m ast er. Piconet m igrat ion as well as com m unicat ion across scat t ernet s are not discussed in det ail here, because t hey are not very m at ure processes in t he version 1.0 specificat ion, which does not define any usage scenarios t hat address com m unicat ion across piconet s. Nevert heless, t he specificat ion cont ains necessary considerat ions t hat could allow t hese processes t o be accom plished. The prim ary role of a m ast er for a piconet is t o define: • •

• •

which frequency- hopping sequence t he m em bers of t his piconet shall follow; when frequency hops shall occur, t hus defining t he t im ing foundat ion for t im ed event s in t he piconet ; which part icular frequency is t he " current " frequency; and which slave will be t ransm it t ed t o and/ or which slave will be perm it t ed t o t ransm it next ( recall t hat t ransm ission on t he Bluet oot h air- int erface is t hrough polling of t he slaves) .

The first t hree it em s are st rongly associat ed wit h how a piconet is form ed and m aint ained and how devices j oin it . The last it em is associated wit h how t ransm issions occur in a piconet . Figure 6.4 shows t he operat ional st at es for a Bluet oot h device. I n t he connect ed st at e, t he device is a m em ber of a piconet . On t he ot her hand, when a device is not associat ed wit h any piconet or part icipat es in no act ion t hat could result in it s form ing or j oining a piconet , it is said t o be in t he st andby st at e. The st andby st at e is t he default operat ional st at e for a Bluet oot h device. I n t his st at e, a device t ypically idles wit h only it s nat ive clock operat ing in a low- power m ode. To m ove t o t he connect ed st at e, a device goes t hrough t he inquiry and page st at es, which are inst ant iat ed different ly but in a com plem ent ary m anner wit hin a pot ent ial m ast er and a pot ent ial

55

slave. I n t he inquiry st at e, a device learns about t he ident it y of ot her devices in it s vicinit y; t hese ot her devices m ust be in an inquiry scan st at e t o list en for and subsequent ly respond t o inquiries. I n t he page st at e, a device explicit ly invit es anot her device t o j oin t he piconet whose m ast er is t he invit ing device; t he ot her device m ust be in t he page scan st at e t o list en for and subsequent ly respond t o pages. As Figure 6.4 shows, a device m ay bypass t he inquiry st at e if t he ident it y of a device t o be paged is already known. The figure also im plies t hat while a device is a m em ber of a piconet , it m ay st ill perform inquiries and pages for addit ional devices t o j oin t his or som e ot her piconet . I n t he lat t er case, a scat t ernet ( m ult iple piconet s overlapping in t im e and space as discussed in Chapt er 2) event ually could be creat ed. Figure 6.4. Operat ional st at es of a Bluet oot h device.

To becom e a m em ber of a piconet , a Bluet oot h device needs t o know how t o recreat e t he frequency- hopping sequence t hat defines t hat piconet and which frequencies from t his sequence will be visit ed and when. Also, t o part icipat e in com m unicat ions over t he piconet , t he device needs t o know how t o form ulat e, read and writ e inform at ion packet s on t he piconet . All of t hese operat ions, as well as nearly every ot her operat ion in a Bluet oot h device, are relat ed t o t he following t wo fundam ent al elem ent s: • •

t he Bluet oot h device address t he Bluet oot h device ( or nat ive) clock

Any process in t he Bluet oot h baseband is int im at ely relat ed t o t hese t wo elem ent s. Two baseband processes are not able and we refer t o t hem as t he fundam ent al processes, which are t hose t hat generat e: • •

t he frequency- hopping sequence, and t he access code.

These fundam ent al elem ent s and fundam ent al processes are det ailed below.

The Bluetooth Device Address (BD_ADDR) The Bluet oot h device address ( BD_ADDR) [ 3] is t he m ost st at ic ent it y of a Bluet oot h device. The BD_ADDR is a single 48- bit address elect ronically " engraved" on each device. A device's BD_ADDR is globally unique am ong Bluet oot h devices. To guarant ee uniqueness, a num bering aut horit y assigns BD_ADDRs. The BD_ADDR is an I EEE 48- bit address, sim ilar t o t he m edium access cont rol ( MAC) address of I EEE 802.xx LAN devices. [3]

The use of the notation BD_ADDR in the specification is the main reason for choosing the term "device" in Figure 6.1 over any of the other legitimate alternatives identified in footnote 1 of this chapter.

56

The 48- bit address field, shown in Figure 6.5 from t he least significant bit ( LSB) t o t he m ost significant bit ( MSB) , is part it ioned int o t hree part s: t he lower address part ( LAP) , t he upper address part ( UAP) , and t he non- significant address part ( NAP) . The 24 bit s of t he UAP and t he NAP const it ut e t he organizat ion unique ident ifier ( OUI ) part of t he address t hat is assigned by t he num bering aut horit y t o different organizat ions. The LAP is assigned int ernally by various organizat ions. The various part s of t he BD_ADDR are involved in nearly every operat ion of t he baseband from piconet ident ificat ion, t o packet header error checking, t o aut hent icat ion and encrypt ion key generat ion. These it em s are discussed in m ore det ail lat er in t his chapt er. Figure 6.5. The Bluet oot h 48- bit device address ( BD_ADDR) .

The Bluetooth Clock Each Bluet oot h device has a free- running 28- bit ( nat ive) Bluet oot h clock. The Bluet oot h clock is never adj ust ed and is never t urned off. The clock t icks 3,200 t im es per second or once every 312.5 µsec, represent ing a clock rat e of 3.2 KHz. Not ice t hat t his is t wice t he nom inal frequencyhopping rat e of 1,600 hops per second. The clock has an accuracy of ± 20 ppm [ 4] I n low- power m odes like st andby, hold, and park ( int roduced in Chapt er 2 and det ailed lat er in t his chapt er) , lower power consum pt ion can be achieved by using a low- power oscillat or t o drive t he clock at a reduced accuracy of ± 250 ppm . The Bluet oot h clock is illust rat ed in Figure 6.6. [4] The abbreviation "ppm" stands for "parts per million" and it is a metric of clock accuracy, where the smaller the value the more accurate the clock.

Figure 6.6. The Bluet oot h nat ive clock.

The Bluet oot h clock wraps around j ust short of once per day. The Bluet oot h clock plays a fundam ent al role in deciding when a device can or cannot t ransm it or list en for a t ransm ission, and at which frequency and for what t ypes of inform at ion packet s it t ransm it s or list ens. A slave device uses t he value of t he Bluet oot h clock of a m ast er t o accom plish piconet com m unicat ions as discussed below. The significance of t he t im e int ervals shown in Figure 6.6 will becom e apparent as we proceed t hrough t he rest of t his chapt er.

The Frequency-Hopping Sequences For devices t o com m unicat e wit h each ot her, t hey m ust t ransm it and receive on t he sam e frequency at t he sam e t im e. The frequency- select ion m odule ( FSM) cont ains t he procedure for select ing t he next frequency t o be used under various operat ing condit ions. The algorit hm ic and im plem ent at ion det ails of FSM are beyond t he scope of t his book. They are covered ext ensively in chapt er 11 of t he Baseband part of t he specificat ion.

57

Figu r e 6 .7 . The fr e qu e n cy- se le ct ion m odu le ( FSM ) .

I n Figure 6.7, t he not at ion ( x y) m eans t hat t here are t wo perm issible alt ernat ives, x or y, only one of which is ent ered int o t he m odule based upon t he circum st ances. The not at ion V[ m : n] , m n, denot es t he use of bit s m t hrough n of t he bit field V; m is t he least significant bit ( LSB) of t he t wo. Depending upon t he count ry of use, t he FSM is set by t he m anufact urer t o operat e in a 23- or 79- channel frequency hop m ode as explained in t he radio sect ion of t his chapt er. Given t he count ry frequency- hop m ode, t he clock input det erm ines which frequency from t he current frequency- hopping sequence is t o be used, and when. I n ot her words, t he clock input det erm ines t he phase of t he frequency- hopping sequence. The act ual frequency- hopping sequence is det erm ined t hrough t he address input . I n each of t he t hree act ive operat ional st at es shown in Figure 6.4, a different com binat ion of clock and address input s is supplied t o t he FSM, as explained im m ediat ely below. Normal Piconet Operation During norm al piconet operat ion, t he channel- hopping sequence is used. For t he channel- hopping sequence, t he address input t o t he FSM for all devices in t he piconet consist s of t he 28 least significant bit s, BD_ADDR[ 0: 27] , of t he m ast er's Bluet oot h device address. The channel- hopping sequence has a very long period, but t he ( 23 or 79) hop frequencies are dist ribut ed equally over short periods of t im e t o sat isfy t he regulat ory requirem ent s for t he frequency- hopping sequence described earlier in t his chapt er. During norm al piconet operat ion, a new frequency from t he channel- hopping sequence is select ed every 625 µsec. This int erval is t he period for bit c 1 of t he Bluet oot h clock shown in Figure 6.6; in t his case, t he LSB of t he clock, c 0 , is not used. The t im e, 625 µsec, bet ween t wo successive t icks of bit c1 of t he clock is referred t o as a slot . For devices in t he connect ed st at e, t he slot boundaries coincide wit h t he t icks of bit c1 of t he m ast er's clock. Furt herm ore, all t he devices in t he piconet ut ilize t he current value of t he m ast er's clock t o drive t heir FSMs. During t he residence t im e at a frequency, a device m ay t ransm it a single packet ized piece of inform at ion, referred t o as a baseband packet dat a unit ( BB_PDU) [ 5] BB_PDUs are st rict ly const rained wit hin t he residence t im e at a frequency. However, t he residence t im e at a frequency m ay occupy m ult iple slot s, t hus perm it t ing m ult i- slot BB_PDU t ransm issions t o occur as discussed below. Following a m ult i- slot t ransm ission, t he next frequency select ed is t he one t hat would have been used if single- slot t ransm issions had occurred inst ead. That is, t he frequencies from t he channel- hopping sequence are select ed on a slot basis, alt hough t he frequency hops t hem selves occur on a BB_PDU basis.

58

[5] The specification refers to the baseband PDUs as such or simply as packets. The BB_PDU nomenclature is introduced here for consistency with use of the terms PDU and packet elsewhere. Nevertheless, the term packet is used whenever appropriate for ease of reading.

Page Operation One device " invit es" anot her device t o j oin it s piconet t hrough t he use of a page. The device issuing t he page is called a paging device, and t he device list ening ( or scanning) for pages is called t he paged device. A paging device select s a new frequency at which t o t ransm it a page every 312.5 µsec, which is t he period of bit c0 of a Bluet oot h clock. During page scans, when a device list ens for t ransm it t ed pages, a new list ening frequency is select ed every 1.28 seconds, which is t he period of bit c12 of t he clock. Not e t hat a paging device changes frequencies at a m uch higher rat e t han a paged device. While t he paged device uses it s own clock t o drive it s FSM, t he paging device uses it s best est im at e of t he clock of t he paged device t o drive it s own FSM. The paging device est im at es t he clock value of t he paged device based upon t he m ost recent com m unicat ion bet ween t he devices. I n t he worst case, t he paging device could use it s own clock. During t he page operat ion, t he page- hopping sequence is used. To generat e t his sequence, t he paging and paged devices use t he 28 least significant bit s of t he address of t he paged device— t hat is, t he LAP and part of t he UAP of t he address shown in Figure 6.5—as t he address input t o t heir respect ive FSMs. For each device, it s page- hopping sequence is a well- defined, periodic sequence com posed of 32 ( resp. [ 6] 16) frequencies uniform ly dist ribut ed over t he 79 ( resp. 23) frequency channels perm issible in t he 2.4 GHz band in various count ries. The period of t he pagehopping sequence is 32 ( resp. 16) hops. [6]

The abbreviation "resp." stands for "respectively."

Inquiry Operation Through inquiries a device " searches" for ot her devices in it s vicinit y. Just as in page operat ion, an inquiring device select s a new frequency at which t o t ransm it an inquiry every 312.5 µsec. I nquired devices, execut ing inquiry scans, select a new list ening frequency every 1.28 seconds. Not e t hat an inquiring device changes frequencies at a m uch higher rat e t han an inquired device. Bot h t he inquiring and inquired devices use t heir own clock t o drive t heir FSMs. During t he inquiry operat ion, t he inquiry- hopping sequence is used. To generat e t his sequence, t he inquiring and inquired devices use t he 28 least significant bit s of t he " inquiry address," referred t o as t he general inquiry access code ( GI AC) LAP, as t he address input t o t heir respect ive FSMs. The inquiry address is a known, reserved 24- bit field equivalent t o t he 24- bit LAP of a Bluet oot h address. The rem aining four bit s of t he inquiry address ( UAP[ 0: 3] ) are equal t o hexadecim al '0x0'. The GI AC LAP is '0x9E8B33' and no Bluet oot h device is allowed t o have an address whose LAP coincides wit h t he GI AC LAP. The inquiry- hopping sequence is a well- defined periodic sequence com posed of 32 ( resp. 16) frequencies uniform ly dist ribut ed over t he 79 ( resp. 23) frequency channels perm issible in t he 2.4 GHz band in various count ries. The period of t he inquiry- hopping sequence is 32 ( resp. 16) hops.

The Access Code The access code is a 68- or 72- bit field prepended t o each BB_PDU prior t o it s t ransm ission over t he Bluet oot h air- int erface. The access code serves a m ult it ude of purposes including ident ifying t he piconet , synchronizing on t he incom ing bit st ream , aiding in est ablishing t he proper DCoffset , and ot hers. The focus here is t he role of t he access codes in ident ifying t he st at e classificat ion ( inquiry, page, or connect ed) of t ransm it t ed BB_PDUs. The algorit hm ic and im plem ent at ion det ails of t he access code generat or are beyond scope of t his book. They are

59

covered ext ensively in chapt er 13 of t he Baseband part of t he specificat ion. Figure 6.8 depict s an overview of t he funct ions relat ed t o t he access code. Figure 6.8. The access code funct ions; t he " + " sym bol above im plies t he prefixing of t he access code in front of t he t ransm it t ed packet .

To receive a t ransm ission, a device uses a correlat or, as shown in Figure 6.8, at it s receiving end. The correlat or can be t uned t o part icular access codes. I f t he correlat or m at ches t he access code of an incom ing t ransm ission sufficient ly well, t he receiver will cont inue receiving t he incom ing bit st ream and pass it t o higher layers for processing. Not e t hat t o conserve power, t hese higher layers m ay not be fully powered unt il t he correlat or inform s t hem of an incom ing m essage t hat has t he proper access code prefixed t o it . As before, t here are t hree classes of access codes t hat t he device ut ilizes; each is described below. Normal Piconet Operation During norm al piconet operat ion, each t ransm ission on a given frequency of t he channel- hopping sequence is preceded by t he channel access code ( CAC) generat ed using t he LAP of t he address of t he piconet m ast er. Only t ransm issions t hat cont ain t he proper channel access code are received by a device. Page Operation During page operat ion, each paging t ransm ission on a given frequency of t he page- hopping sequence and each response t o it are preceded by t he device access code( DAC) generat ed using t he LAP of t he paged device's address. Inquiry Operation During inquiry operat ion, each inquiry t ransm ission on a given frequency of t he inquiry- hopping sequence and each response t o it are preceded by an inquiry access code( I AC) . There are 64 I ACs, including t he GI AC, associat ed wit h 64 reserved LAPs. Excluding t he GI AC, t he rem aining 63 I ACs are referred t o as dedicat ed I ACs ( DI ACs) . The I AC LAPs belong t o t he set { '0x9E8B00', …, '0x9E8B3F'} . No device can have an address whose LAP m at ches any of t hese reserved LAPs. Not e t hat no m at t er which I AC is used, t he inquiry- hopping sequence over which t his I AC is t ransm it t ed is generat ed using t he GI AC. This is done t o allow devices wit h m ult iple receiver

60

correlat ors, as highlight ed in Figure 6.8, t o follow a single inquiry- hopping sequence but st ill be able t o list en t o m ult iple classes of inquiries sim ult aneously. While t he specificat ion does not define how I ACs are t o be used, t hey are int ended t o be used prim arily as a filt ering m echanism for ident ifying well- defined subset s of t he devices t hat m ay receive inquiries. While all devices t hat execut e inquiry scans use t he GI AC t o generat e t he inquiry- hopping frequency, only t hose devices whose receiver correlat ors are t uned t o a part icular I AC will receive and respond t o inquiries t hat cont ain t hat part icular I AC. Table 6.3 sum m arizes t he various param et ers relat ed t o t he fundam ent al processes for each of t he t hree operat ional st at es of a Bluet oot h device. Table 6.3. The FSM input s and t he access codes used during t he various act ive st at es of a device. D e vice st a t e

Fr e qu e n cy- h op m odule

Acce ss code

Connect ed

clock: m ast er's; address: m ast er's

channel access code ( CAC) ; it coincides wit h t he m ast er's device access code ( DAC)

I nquiry

clock: own; address: GI AC

general or dedicat ed inquiry access code ( GI AC or DI AC)

Page

clock: ( est im at e of) paged device's; address: paged device's

paged device's device access code ( DAC)

As discussed earlier, t he Bluet oot h clock and t he BD_ADDR of t he m ast er of a piconet fully ident ify t he frequency- hopping sequence and phase of t he channel used in t he piconet . Since com m unicat ion bet ween a slave and a m ast er can occur only wit hin a piconet , it follows t hat each slave in a piconet m ust know t he m ast er's clock and BD_ADDR. Alt ernat ively, for a pot ent ial m ast er t o efficient ly invit e a pot ent ial slave, it needs t o know t he slave's clock and address. The exchange of address and clock inform at ion bet ween devices occurs during inquiries, when t he m ast er collect s operat ional inform at ion about t he prospect ive slaves, and during pages, when t he m ast er com m unicat es t o a slave it s own operat ional inform at ion. The operat ional inform at ion of a device, which includes it s BD_ADDR and clock value, is sent in a frequency- hopping sequence ( FHS) BB_PDU described in det ail lat er in t his chapt er. Assum ing t hat t he fundam ent al elem ent s ( address and clock) of t he devices involved are known, t he connect ed st at e is highlight ed first in t he next sect ion. The inquiry and page st at es are present ed aft erward.

The Connected State While in t he connect ed st at e, devices can exchange dat a under t he cont rol of t he m ast er t hat defines which device t ransm it s when. To m aint ain piconet synchronizat ion, each slave adds an offset t o it s nat ive clock t hat account s for t he difference of it s own clock from t hat of t he m ast er. Thus, t he clock of t he m ast er becom es t he regulat or of t im ed event s in t he piconet . I n addit ion, t he LAP of t he m ast er is used for t he access code generat ion. Wit h a com m on clock reference am ong all devices in a piconet , t he t ransm ission t im e on t he piconet is divided int o m ast er and slave t ransm ission slot s. A m ast er st art s it s t ransm issions on even- num bered slot s ( c 1 = 0) exclusively. Likewise, a slave st art s it s t ransm issions on oddnum bered slot s ( c 1 = 1) exclusively. A part icular slave t ransm it s if and only if t he last m ast er t ransm ission was dest ined exclusively t o t his slave. Thus, t he m edium access prot ocol for Bluet oot h com m unicat ions is a packet - based, t im e- division duplex ( TDD) [ 7] polling schem e.

61

Typically, m ast er and slave t ransm it slot s alt ernat e every 625 µsec, t he residence t im e at a frequency, alt hough as m ent ioned earlier, m ult i- slot t ransm issions are possible. However, m ult islot t ransm issions are lim it ed t o an odd num ber of slot s ( one, t hree or five) , which guarant ees t hat m ast er t ransm issions always st art on even slot s and slave t ransm issions on odd slot s. [7] TDD refers to a time-division multiplexing technique where the transmission time on a single communication channel is divided into successive, non-overlapping intervals, every other of which is used for transmissions in one of two opposing directions. The transmission direction alternates between the two directions with each successive interval.

Figu r e 6 .9 . Th e BB_ PD U for m a t .

Baseband BB_PDU Types Figure 6.9 depict s t he general form at of a BB_PDU t ransm it t ed on a piconet . No frequency hops occur during a BB_PDU t ransm ission and at m ost one BB_PDU is t ransm it t ed during t he residence t im e at a frequency. Over- t he- air t ransm issions st art wit h t he LSB and proceed t o t he MSB ( lit t leendian t ransm ission ordering) . Every BB_PDU t ransm it t ed st art s wit h t he access code t hat , for t he discussion here, serves as t he piconet ident ifier, t hus filt ering out t ransm issions t hat m ight be received from ot her piconet s ( see Figure 6.8) . The access code t ypically is 72 bit s long, which includes a 4- bit t railer field. I f t he BB_PDU does not cont ain a header ( and hence a payload) , t he t railer is not used and t he BB_PDU consist s of t he 68- bit access code only. The 68- bit BB_PDUs are used exclusively for t ransm it t ing inquiries or pages as described in t he corresponding sect ions lat er in t his chapt er. The header of t he BB_PDU cont ains link cont rol dat a t o aid m edium access cont rol. The header cont ains a m ere 18 bit s of inform at ion for low overhead, but it is encoded wit h a forward errorcorrect ing( FEC) code wit h rat e 1/ 3 for high t ransm ission reliabilit y. I n part icular, every bit of t he header is t ransm it t ed t hree t im es in sequence. Table 6.4 sum m arizes t he fields of BB_PDU header.

Ta ble 6 .4 . Th e ba se ba n d BB_ PD U h e a de r . Fie ld nam e

Size

Com m e n t s

AM_ADDR

3 bit s

act ive m em ber address assigned t o an act ive slave when devices exchange paging inform at ion, such as during t he paging of a device

TYPE

4 bit s

defines 16 BB_PDU/ payload t ypes

FLOW

1 bit

st op/ go flow cont rol swit ch set by a receiving device in it s response t o t he sender

ARQN

1 bit

used for acknowledging successfully t ransm it t ed BB_PDUs; BB_PDUs for which an acknowledgem ent is not received are ret ransm it t ed

SEQN

1 bit

sim ple ( odd/ even) sequence num ber for filt ering duplicat e t ransm issions

HEC

8 bit s

header error check ( HEC) generat ed by t he generat or polynom ial G 8 + x 7 + x 5 + x 2 + x + 1

HEC( x)

= x

62

During t he paging process, t he m ast er assigns a 3- bit act ive m em ber address ( AM_ADDR) t o t he new slave. AM_ADDR t akes on t he values 1 t hrough 7 and it is unique for each act ive slave in a piconet . The reserved value of AM_ADDR = 'b000' is used t o signify broadcast t ransm issions from t he m ast er t o all t he slaves in a piconet . [ 8] The AM_ADDR is included in t he sam e FHS BB_PDU sent by t he m ast er t o t he slave t hat also contains t he m ast er's address and clock inform at ion. [8] Due to the TDD polling scheme used for medium access control in a piconet, only the master can directly broadcast data to the other piconet members (its slaves). Slaves in a piconet can only unicast (a point-to-point transmission) to the master of the piconet.

The various BB_PDU t ypes are dist inguished by t heir roles: purely signaling or payload- carrying packet s; t heir link designat ion: asynchronous connect ionless ( ACL) dat a or synchronous connect ion- orient ed ( SCO) dat a; t heir size: 1, 3 or 5 slot s; and t heir FEC encoding: no FEC, 2/ 3 rat e FEC encoding, and 1/ 3 rat e FEC encoding. The 2/ 3 rat e FEC is a ( 15,10) short ened Ham m ing code generat ed by t he generat or polynom ial G FEC( x) = x 5 + x 4 + x 2 + 1. The HEC is im plem ent ed t hrough an 8- bit linear feedback shift regist er ( LFSR) circuit whose init ial value is UAP[ 0: 7] of t he m ast er of t he piconet . Hence, even in t he case where t ransm issions from m ult iple m ast ers wit h overlapping LAPs ( t hus generat ing t he ident ical access code as shown in Figure 6.8) were accept ed, t he corresponding BB_PDU would be rej ect ed because t he BB_PDU header would fail it s header error check. I n ot her words, bot h t he LAP and t he UAP of t he m ast er of a piconet are needed t o fully ident ify and accept a BB_PDU t ransm ission on t he piconet . The link cont rol packet s include: • • • •

t he I D packet , used in inquiries and pages, t hat consist s of only t he access code; t he NULL packet t hat is used prim arily for slave acknowledgm ent and flow cont rol inform at ion t ransm ission when t he slave does not have anyt hing else t o t ransm it ( NULL packet s t hem selves are not acknowledged) ; t he POLL packet t hat is sent from a m ast er t o a slave t o poll it for a t ransm ission when t he m ast er does not have any payload inform at ion t o send t o t he slave ( t he POLL packet requires a response) ; and t he FHS packet used in inquiries and pages.

The ACL packet s are designat ed as D( M H) ( 1 3 5) , where " DM" st ands for m edium speed dat a t hat use a 2/ 3 FEC encoding for t he payload; " DH" st ands for high speed dat a where no FEC is used for t he payload. The size qualifier 1, 3 or 5 refers t o t he num ber of slot s occupied by t he packet . For m ult i- slot packet s, t he frequency does not change unt il t he packet finishes it s t ransm ission. The next frequency t o be used is t he one t hat would have been used if single- slot t ransm issions were used in t he m eant im e inst ead. Not e t hat t he size of an ACL packet is odd because a m ast er's t ransm ission m ust always st art at even- num bered slot s while slave t ransm issions m ust st art at odd- num bered slot s. Using five- slot packet s in one direct ion and oneslot packet s in t he opposing direct ion, t he m axim um achievable rat e for ACL t raffic is 723.2 Kbps in t he first direct ion and 57.6 Kbps in t he opposit e direct ion. Knowledge of t he t ype of a BB_PDU and hence it s size facilit at es power conservat ion in a slave. I n part icular, as a slave in a piconet inspect s an incom ing t ransm ission and finds t hat t he t ransm ission is not int ended for t hat slave ( t hat is, it s AM_ADDR does not m at ch t he address in t he BB_PDU header) , t he slave could go t o " sleep" for a durat ion of t im e dict at ed by t he packet t ype field. The SCO packet s are one slot long and are designat ed as HV( 1 2 3) . All t hree variant s can support 64 Kbps in each direct ion over periodically reserved slot s using different encoding for t he payload dat a. I n part icular, HV st ands for high- qualit y voice, and t he encoding qualifier 1, 2 or 3 refers t o t he encoding used for t he payload dat a:

63

• • •

1 is for 1/ 3 rat e FEC; a device t ransm it s a single- slot packet every 2 slot s 2 is for 2/ 3 rat e FEC; a device t ransm it s a single- slot packet every 4 slot s 3 is for no FEC; a device t ransm it s a single- slot packet every 6 slot s

I n addit ion t o t he above packet t ypes t here is a DV packet t hat com bines bot h ACL, wit h 2/ 3 FEC, and SCO, wit h no FEC, dat a in a single- slot packet . A device could t ransm it a DV packet every 2 slot s. Figure 6.10 depict s t he low- level baseband operat ions t hat occur during t he t ransm ission and recept ion of baseband packet s. Not e t hat different operat ions t ake place for t he packet header versus t he payload; t he operat ions for t he header and t he payload occur serially rat her t han in parallel as t he figure m ight im ply. I n t he figure, whit ening refers t o t he process of scram bling t he t ransm it t ed dat a t o random ize t hem and t o reduce t he DC bias in t he t ransm it t ed dat a. The dat a are whit ened t hrough t he use of t he whit ening word generat ed by t he polynom ial G WHI TE ( x) = x 7 + x 4 + 1. Securit y feat ures in Bluet oot h piconet s, including device aut hent icat ion and link encrypt ion, are discussed in t he following LMP sect ion. The CRC operat ion pert ains only t o ACL packet s, det ailed im m ediat ely below.

Figure 6.10. Low- level baseband operat ions during t ransm ission and recept ion of baseband packet s.

Asynchronous Connectionless (ACL) Packets The payload port ion of t he DM packet s and t he ACL port ion of a DV packet is furt her st ruct ured wit h it s own ACL packet header and payload along wit h a t wo- byt e cyclic redundancy check( CRC) field. Table 6.5 sum m arizes t he fields of t he ACL packet s, from t he LSB t o MSB.

Ta ble 6 .5 . Th e ACL pa ck e t for m a t . Fie ld nam e

Size

L_CH ( logical channel)

2 bit s

Com m e n t s 'b00': not defined

64

Ta ble 6 .5 . Th e ACL pa ck e t for m a t . Fie ld nam e

Size

Com m e n t s 'b01': cont inuat ion segm ent of an L2CAP PDU 'b10': st art of an L2CAP PDU 'b11': LMP PDU

FLOW

1 bit

for flow cont rol on t he ACL link

LENGTH

( 5 9) bit s

lengt h of ACL payload in oct et s ( excludes header and CRC) for eit her single- or m ult i- slot packet s in t he case of a 9- bit lengt h field, a 4- bit undefined padding is used t o m ake t he header an int eger m ult iple of byt es ( 2 byt es t ot al)

Payload

0–339 byt es

ACL packet payload spanning 1 t o 5 slot s

CRC

2 byt es

t he cyclic redundancy check prot ect s t he payload and is generat ed by t he CRC- CCI TT generat or polynom ial G 16 + x 12 + x 5 + 1 CRC( x) = x

There is one ext ra one- slot ACL packet , AUX1, which does not cont ain a CRC. The use of t his packet is not defined in t he specificat ion. Possibly, it could be used for t est ing and developm ent purposes; however, it is out side t he scope of t he version 1.0 specificat ion and t his discussion. The Baseband Link Types As m ent ioned earlier, t he Bluet oot h baseband support s t wo t ypes of links over a piconet . ACL links are used for carrying asynchronous dat a. The m ast er schedules asynchronous t ransm issions in slot s not already reserved for synchronous ( SCO) t ransm issions. I n ot her words, SCO t raffic is of high priorit y and cannot be preem pt ed for asynchronous t ransm issions. For each and every slave in it s piconet , a m ast er est ablishes exact ly one ACL link t hat represent s a physical pipe bet ween t he m ast er- slave pair over which ACL dat a are exchanged. Point - t o- point ACL BB_PDU exchanges are all acknowledged and ret ransm it t ed as appropriat e. Broadcast ( AM_ADDR = 'b000') ACL t ransm issions from a m ast er t o it s slaves are not acknowledged but m ay be repeat ed several, N BC, t im es for increased reliabilit y. Not e t hat , since it is im possible for m ult iple slaves t o acknowledge a t ransm ission sim ult aneously, it is also im possible t o acknowledge a broadcast t ransm ission. I n part icular, t here exist s no sim ple and reliable m et hod t o dynam ically designat e a single slave t o acknowledge on behalf of all slaves in t he piconet t hat t he broadcast t ransm ission has been successfully received by all slaves. SCO links carry t elephony- grade voice audio t hrough a priori periodically reserved pairs of slot s. I n a piconet , following a request from a slave or t he m ast er, a m ast er m ay est ablish up t o t hree SCO links in t ot al bet ween it and all of it s slaves. Each SCO link represent s a physical pipe bet ween t he m ast er and one of it s slaves over which SCO dat a are exchanged. To m aint ain t he high qualit y of service expect ed for SCO t raffic, t he lengt h of t he baseband slot , 625 µsec, is select ed t o m inim ize t he packet izat ion delay for audio t raffic and t he effect s of noise int erference. For exam ple, an HV1 BB_PDU carries t he equivalent of 10 byt es of audio inform at ion, which at 8,000 sam ples per second and 8 bit s per sam ple t akes 1.25 m sec ( = 2* 625 µsec) t o accum ulat e.

65

This is t he sam e as t he period of t ransm issions of HV1 BB_PDUs from a device. Unlike ACL t ransm issions, SCO BB_PDUs are not acknowledged. Not e t hat prior t o est ablishing an SCO link, an ACL link m ust already exist t o carry, at a m inim um , t he SCO connect ion cont rol inform at ion. Bluet oot h links bet ween devices can be aut hent icat ed, encrypt ed, operat ed in low- power m ode, and in general, qualified based upon applicat ion or user requirem ent s. The operat ion of t he baseband in t hese cases is highlight ed in t he following link m anager prot ocol sect ion since it is link m anager involvem ent t hat init iat es t hese sort s of changes in link behavior. For com m unicat ion in a piconet t o occur, a slave needs t o know it s m ast er's clock and address. The following sect ions discuss t he inquiry and page m echanism s by which t his inform at ion is acquired. As Figure 6.4 shows, t his t wo- st ep process can be t rim m ed t o one st ep when connect ing t o known devices.

Inquiry State The purpose of device inquiries is t o collect inform at ion about ot her Bluet oot h devices in proxim it y. This prim arily involves obt aining t heir fundam ent al elem ent s: BD_ADDR and clock value. The inquiry st at e is com posed of several subst at es execut ed by " pot ent ial" m ast ers and slaves. These are t he inquiry subst at e execut ed by a pot ent ial m ast er and t he inquiry scan and inquiry response subst at es execut ed by a pot ent ial slave. I n t he inquiry subst at e, a m ast er [ 9] t ransm it s inquiry packet s, which are received by slaves in t he inquiry scan subst at e. The lat t er devices t hen ent er t he inquiry response subst at e and schedule t he t ransm ission of t heir fundam ent al elem ent s t o t he m ast er. [9]

For brevity, the qualifier "potential" for masters and slaves will be omitted unless it is required for clarifying the context.

While in t he various inquiry subst at es, devices ut ilize t he inquiry- hopping sequence t o t ransm it and receive packet s. The inquiry packet sent by an inquiring m ast er is a BB_PDU t hat cont ains only an appropriat e I AC, t ypically t he GI AC, as described in t he preceding sect ion on access codes. This packet is referred t o as t he inquiry I D packet . The inquiry I D packet sim ply not ifies slaves t hat a m ast er is looking for slaves. I n responding t o an inquiry, a slave t ransm it s an FHS packet cont aining, am ong ot her inform at ion, t he slave's BD_ADDR and clock value at t he t im e of t ransm ission of t he FHS packet . Table 6.6 depict s t he cont ent s of t he FHS packet . Since eit her a m ast er or a slave can send an FHS packet , [ 10] t he fields in t he FHS packet are int erpret ed wit h respect t o t he device t hat sent t he packet . The fields and t he bit s wit hin t hem are provided in t he t ransm ission order from t he LSB t o t he MSB. [10]

A master sends an FHS packet during a page operation as described in the following section.

Ta ble 6 .6 . Th e FH S pa ck e t . Fie ld n a m e

Size

Com m e n t s

parit y bit s

34 bit s

used for building t he device access code ( DAC) for paging t he device sending t his packet

LAP

24 bit s

t he lower address part of t he BD_ADDR of t he device sending t his packet

Reserved

2 bit s

set t o 'b00'

Paging int erval

4

t wo 2- bit subfields defining t he period of t he successive page scans and

66

Ta ble 6 .6 . Th e FH S pa ck e t . Fie ld n a m e

Size

Com m e n t s

param et ers

bit s

t he durat ion of t he m andat ory page scan period for t he device sending t his packet

UAP

8 bit s

t he upper address part of t he BD_ADDR of t he device sending t his packet

NAP

16 bit s

t he non- significant address part of t he BD_ADDR of t he device sending t his packet

CoD

24 bit s

class of device field cont aining inform at ion regarding t he device sending t his packet

AM_ADDR

3 bit s

for inquiry responses, it is set t o 'b000'; for a m ast er response following a page response by a ( pot ent ial) slave, it is set t o t he act ive m em ber address assigned t o t he new act ive slave

CLOCK[ 2: 27]

26 bit s

t he current t im e ( updat ed wit h each ret ransm ission of t he packet ) of t he Bluet oot h clock of t he device sending t his packet

Page scan m ode

3 bit s

t he default page scan m ode of t he device; one m andat ory page scan m ode and up t o t hree opt ional ones are support ed in version 1.0

The header of t he BB_PDU carrying t he FHS packet as payload has t he AM_ADDR field set t o 'b000' wit hout m eaning t hat t his is a broadcast packet . The FHS packet is prot ect ed by a 2- byt e CRC and encoded wit h an FEC wit h rat e 2/ 3. The size of t he FHS packet is 240 bit s of payload and 126 bit s of packet header and access code. The operat ions of a m ast er, t he inquiring device, and a slave, t he list ening device, are highlight ed in Figure 6.11. The num bers shown in t he figure are t ypical num bers, which can be changed t hrough int ervent ion from applicat ions as needed. I n sum m ary, a m ast er t ransm it s it s inquiry I D packet s on different frequencies of t he inquiryhopping sequence, changing t he t ransm ission frequency rapidly in t he hope of t ransm it t ing as soon as possible on one of t he frequencies t hat slaves are list ening t o. This would ult im at ely happen, given enough t im e, as slaves perform ing inquiry scans change t heir list ening frequency from t he inquiry- hopping sequence at a m uch slower rat e. Since a m ast er does not know when a slave list ens for inquiries, t he m ast er repeat s it s inquiry t ransm issions a num ber of t im es. When " cont act " finally occurs, t he slave responds wit h it s FHS packet t hat includes vit al paging inform at ion. SCO t ransm issions scheduled in any of t he inquiring or list ening devices t ake precedence over t he inquiry procedures. A device will forego an inquiry act ion t o t ransm it and receive scheduled SCO packet s. The inquiry- hopping rat e is 3,200 hops per second, double t he nom inal frequency- hopping rat e. The m ast er will t ransm it and list en for responses over 16 different frequencies of t he inquiryhopping sequence ( t rain A in Figure 6.11) over a period of 10 m sec ( 8 t ransm it and 8 receive slot s alt ernat ing wit h each ot her) . I f an insufficient num ber of responses is gat hered, t he m ast er will repeat t he sam e process over t he sam e set of 16 frequencies at least 256 t im es, or 2.56 seconds. Following t his int erval and assum ing operat ion in a 79 channel count ry, t he m ast er m ay also search t hrough t he rem aining 16 frequencies of t he inquiry- hopping sequence ( t rain B in Figure 6.11) an addit ional 256 t im es. The whole inquiry process m ay t hen be repeat ed from t he beginning.

67

Figure 6.11. Fast frequency scanning for inquiries in a 79 channel count ry; f t [ .] I denot es t he m ast er t ransm it frequencies from t he inquiry- hopping sequence.

To avoid collisions from m ult iple slaves responding t o t he sam e inquiry I D packet , a rare event in it s own right , a back- off m echanism is used and it works as follows. Upon receipt of an inquiry I D packet , t he slave ent ers t he inquiry response subst at e. I t t hen random ly select s a num ber RN ( 1,023) and suspends it s inquiry response operat ions for at least t hat m any slot s; t he slave m ay m ove int o t he st andby, connect ed or page st ates as necessary. When t he slave resum es t he inquiry response subst at e, it will respond wit h an FHS packet following t he first inquiry I D packet it receives again. The det ailed descript ion of t he inquiry procedures can be found in sect ion 10.7 of t he Baseband part of t he specificat ion. Responding im m ediat ely aft er receiving an inquiry I D packet is not prudent , as t he m ast er m ay not have swit ched t o t he m ode in which it list ens for responses. To guarant ee t hat t his does not occur, t he slave responds wit h it s FHS packet 625 µsec aft er t he receipt of t he inquiry I D packet , as shown in Figure 6.12. The figure shows t wo slaves, not ed as i and j , responding t o inquiry I D packet s. Slave I heard t he inquiry I D packet in t he first half of a m ast er t ransm it slot . Slave j heard t he inquiry I D packet in t he second half of a t ransm it slot from t he m ast er. I n eit her case, even t hough t he slave is unaware exact ly when t he m ast er will swit ch t o t he proper list ening frequency, it is guarant eed t hat t he corresponding FHS packet from a slave is sent at t he right t ransm it frequency at t he t im e t hat t he m ast er is list ening at t hat sam e frequency.

68

Figure 6.12. I nquiry t ransm ission sequences; f r [ .] I denot es t he m ast er receive frequencies from t he inquiry- hopping sequence corresponding t o f t [ .] I .

Not e t hat t he inquiry I D packet is 68 µsec long and it is t ransm it t ed t wice over t wo different frequencies wit hin a 625 µsec t im e int erval. Therefore, closely observing t he figure, one m ay deduce t hat t he t ransm it frequency synt hesizer has 244.5 µsec in which t o swit ch t o a new frequency. Act ually, account ing for a ± 10 µsec t olerance for clock drift , t he synt hesizer m ust set t le t o a new t ransm it frequency wit hin 224.5 µsec. Adm it t edly t his num ber is large com pared t o st at e- of- t he- art synt hesizer design. However, it allows t he use of less com plex and less precise circuit ry t hat result s in t he desired low cost syst em design point . For m ore inform at ion on t his subj ect , see [ Haart sen00] .

Page State The purpose of a device page is t o invit e a specific paged device t o j oin a piconet whose m ast er is t he paging device. The paging device uses t he paged device's BD_ADDR and clock est im at e t o send it s pages as discussed earlier. The page st ate is com posed of several subst at es execut ed by pot ent ial m ast ers and slaves. These are t he page and m ast er response subst at es execut ed by a m ast er and t he page scan and slave response subst at es execut ed by a slave. I n t he page subst at e, a m ast er t ransm it s page BB_PDUs, which are received by t he slave when it is in t he page scan subst at e. The paging t ransm ission cont ains only t he slave's DAC. This BB_PDU is referred t o as t he slave I D packet . I n it s page response, t he slave also sends t he slave I D packet t hat sim ply not ifies t he m ast er t hat t he slave has received t he page. Finally, t he m ast er ent ers t he m ast er response subst at e during which t he m ast er t ransm it s t o t he slave it s fundam ent al elem ent s and t he slave's AM_ADDR, which allows t he slave t o j oin and part icipat e in com m unicat ions in t he m ast er's piconet . These fundam ent al elem ent s and AM_ADDR are t ransm it t ed wit hin an FHS packet ( see Table 6.6) . The slave responds wit h one m ore slave I D packet s, and t hen ent ers t he connect ed st at e and readies it self t o st art piconet com m unicat ions. The operat ion of t he m ast er and t he slave in t he page and page scan subst at es, respect ively, is quit e sim ilar t o t hat of t he inquiry and inquiry scan operat ions discussed earlier. I n part icular, t he illust rat ion of Figure 6.11 for inquiries can also be used for pages as well by replacing t he t erm s relat ed t o inquiries wit h corresponding t erm s relat ed t o pages. The t ypical value for TpageScan is 1.28 seconds; subsequent ly, t he t ypical value for Npage is 128. These t ypical values correspond t o t he so- called R1 paging m ode. The paging m ode, and hence t he corresponding param et ers TpageScan and Npage, are com m unicat ed t o t he m ast er during t he slave FHS t ransm ission in an inquiry, or during link m anager inform at ion exchange during regular com m unicat ions.

69

For a 79- channel count ry, t rains A and B cont ain 16 frequencies each from t he page- hopping sequence, while for 23- channel count ries t here is only one t rain containing all 16 frequencies. I n t he form er case, t rain A cont ains t he 16 frequencies closest t o t he frequency on which t he slave list ens for pages as est im at ed by t he m ast er using it s knowledge of ( t he est im at e of) t he slave's nat ive clock. Train B cont ains t he rem aining frequencies from t he page- hopping sequence. Yet , since t rain B is used 1.28 seconds aft er t ransm it t ing pages on frequencies from t rain A, t he m ast er knows t hat t he frequency on which t he slave list ens will also m ove by one. Hence, t rains A and B have one com m on frequency. For exam ple, if t rain A cont ains frequencies f t [ 0] P t hrough f t [ 15] P, t hen when t rain B is used, it will cont ain frequencies f t [ 17] P t hrough f t [ 0] P, in t hat order. A device t hat perform s page scans in t he R1 paging m ode can be locat ed wit hin no m ore t han 1.28 seconds m ost of t he t im e. When t he est im at e of t he slave's nat ive clock deviat es m ore t han –8* 1.28 seconds or + 7* 1.28 seconds from t he act ual value of t he slave's clock, t he search t im e can be as m uch as t wice t he nom inal value, or 2.56 seconds. The sequence of t ransm issions during paging operat ions is sum m arized in Figure 6.13, where a m ast er pages a slave denot ed as i. Following t he paging operat ion, t he slave shall be able t o part icipat e in piconet com m unicat ions. Hence, t he slave not only needs t o learn about t he m ast er's BD_ADDR and clock value but also m ust have an AM_ADDR assigned t o it and m ust know exact ly when a m ast er t ransm it slot st art s. The AM_ADDR is included in t he FHS packet t ransm ission t o slave i. The t im e of t ransm ission of t his packet is used t o ident ify t he st art of t he m ast er t ransm it slot s in t he piconet . The m ast er t ransm it s it s FHS packet t o slave i at t he beginning of it s t ransm it slot , regardless of whet her t he slave sends it s previous slave I D packet in t he first or second half of t he slot during which t he m ast er list ens for t he slave response t o it s pages. I n t he exam ple of Figure 6.13, since t he m ast er receives t he slave response t o t he m ast er's pages in t he second half of t he m aster's receive slot , t he m ast er t ransm it s t he FHS packet 312.5 µsec aft er it receives t he slave I D packet . Thus, by t he t im e t hat t he slave receives and processes t he FHS packet , t he slave has all t he inform at ion needed t o part icipat e in t he piconet com m unicat ions, st art ing wit h a m ast er t ransm ission 1.25 m sec from t he st art of recept ion of t he FHS packet .

Figure 6.13. Page t ransm ission sequence. f t [ .] P and f r [ .] Pdenot e t he corresponding m ast er t ransm it and receive frequencies, respect ively, from t he page- hopping sequence and f t [ .] C denot es a m ast er t ransm ission frequency from t he channel- hopping sequence.

As wit h inquiries, SCO t ransm issions scheduled in any of t he paging or paged devices t ake precedence over t he paging procedures. A device will forego a page act ion t o t ransm it and

70

receive scheduled SCO packet s. This case is not elaborat ed furt her here. The det ailed descript ion of t he page procedures can be found in sect ion 10.6 of t he Baseband part of t he specificat ion.

71

The Link Manager and Link Manager Protocol Link m anager ent it ies, or sim ply link m anagers, in com m unicat ing devices exchange m essages t o cont rol t he Bluet oot h link bet ween t hose devices. The com m unicat ion prot ocol bet ween link m anagers is called t he link m anager prot ocol( LMP) and t he m essages exchanged bet ween com m unicat ing link m anagers are not ed as LMP_PDUs. Figure 6.14 sum m arizes t he funct ions of a link m anager. LMP does not carry applicat ion dat a. Based upon cont rol dat a it receives from higher layers, LMP eit her com m unicat es wit h t he link m anager in anot her device using LMP_PDUs or it sends cont rol signals t o it s own device's baseband and radio layers. I t should be not ed t hat , cont rary t o baseband processes t hat are execut ed in real t im e, link m anager int eract ions are not . Albeit infrequent ly, com m unicat ing link m anagers m ay t ake up t o 30 seconds t o react t o each ot her's request s.

Figu r e 6 .1 4 . The lin k m a n a ge r fu n ct ion s.

As discussed earlier ( see Table 6.5) , LMP_PDUs are carried in t he payload of ACL packet s whose header has an L_CH field wit h t he value 'b11'. LMP_PDUs are t ransm it t ed on single- slot DM1 packet s or on DV packet s. LMP_PDUs have very high priorit y and, if needed, t hey can preem pt even an SCO t ransm ission t o t ransm it cont rol inform at ion t o anot her device. Table 6.7 sum m arizes t he LMP_PDU packet form at ; not e t hat LMP_PDU packet form at .

Ta ble 6 .7 . Th e LM P_ PD U for m a t . 72

Fie ld n a m e

Size

t ransact ionI D 1 bit

Com m e n t s 'b0': ident ifies link m anager t ransact ion init iat ed by t he m ast er 'b1': ident ifies link m anager t ransact ion init iat ed by a slave

OpCode

7 bit s

ident ifies t he LMP_PDU and t he t ype of cont ent s it carries

payload

0–17 byt es

t he LMP_PDU fit s in DM1 BB_PDU; if t he LMP_PDU payload is less t han 9 byt es t hen, when support ed, DV BB_PDUs m ay also be used

When a link m anager in a device init iat es an LMP_PDU t ransact ion wit h t he link m anager in anot her device, t he lat t er link m anager will respond wit h t he next LMP_PDU in t he t ransact ion sequence ( for exam ple, respond wit h t he request ed inform at ion) . Alt ernat ively, t he receiving link m anager responds wit h an LMP_accept ed or LMP_not _accept ed PDU t hat signifies whet her t he link m anager request from t he t ransact ion init iat or is or is not accept ed, respect ively. When an LMP_not _accept ed PDU is sent , t he reason for not accept ing t he t ransact ion is provided. Figure 6.15 shows t wo t ypical t ypes of LMP_PDU t ransact ions. I n t he first , eit her one of t he com m unicat ing link m anagers init iat es a t ransact ion wit h a request . The receiving link m anager eit her will accept t he request and act accordingly ( perhaps providing t he request ed inform at ion) or will rej ect t he request wit h an LMP_not _accept ed PDU. I t m ight also send it s own corresponding request LMP_PDU init iat ing a negot iat ion phase for t he original request . I n t he second t ransact ion t ype, t he m ast er sends a com m and t o be execut ed by t he slave in an LMP_PDU, wit hout t he opport unit y for t he slave t o rej ect t he com m and or negot iat e it s param et ers. An exam ple of t he lat t er case is forcing a slave t o go int o a power- saving m ode, like t he hold m ode, or request ing a link det achm ent , which is t he only operat ion t hat a slave m ay also force on a m ast er. Figure 6.15. Typical LMP_PDU t ransact ions: ( a) a request / response t ransact ion and negot iat ion; ( b) m ast er dem ands link adj ust m ent .

73

There are m any link m anager t ransact ions from a sim ple device nam e exchange t o elaborat e aut hent icat ion and encrypt ion t ransact ions, but not all of t hem are m andat ory. However, t he receiving link m anager m ust be able t o respond t o all link m anager t ransact ion request s, even if t he response is an LMP_not _accept ed PDU, wit h t he reason for non- accept ance being " feat ure not support ed." The following sect ions focus on a few of t he m ore im port ant link m anager t ransact ions. The int erest ed reader can find a m ore det ailed present at ion in t he LMP part of t he specificat ion.

Security Management Securit y has been part of t he specificat ion from t he out set of it s developm ent . I t was recognized early on t hat in ad hoc, wireless, and especially RF environm ent s securit y is of param ount im port ance. The baseband defines securit y algorit hm s and procedures needed t o aut hent icat e devices, and if needed t o encrypt t he dat a flowing on t he link bet ween t hem . Sect ion 14 of t he baseband part of t he specificat ion includes algorit hm s for t he generat ion of aut hent icat ion and encrypt ion keys and t he operat ions for verifying t he aut hent icit y of a device. Even t hough securit y is present ed m ost ly in t he baseband part of t he specificat ion, it is discussed here in t he link m anager sect ion, since it ult im at ely relat es t o t he configurat ion of a link bet ween devices, t he responsibilit y for which lies wit h t he link m anagers. Device aut hent icat ion is a m andat ory feat ure support ed by all Bluet oot h devices. Link encrypt ion is opt ional. Device Authentication Aut hent icat ion of Bluet oot h devices is based on a challenge- response t ransact ion. I n t his t ransact ion, a verifier challenges a claim ant by sending t o t he lat t er a 16- byt e random num ber in an LMP_au_rand PDU. The claim ant operat es on t he random num ber and ret urns t he result of t he operat ion t o t he verifier in an LMP_sres PDU. I f t he result is t he one expect ed by t he verifier, t he

74

verifier considers t he claim ant an aut hent icat ed device. Opt ionally, t he t wo devices m ay t hen exchange t heir roles as verifier and claim ant and perform aut hent icat ion in t he opposit e direct ion. The above procedure occurs when t he t wo devices have a com m on link key, which is used t o operat e on t he random num ber. A device m ay m aint ain ident ical or separat e link keys for every ot her device t hat it want s t o aut hent icat e. I f a link key does not exist for a device, when an LMP_au_rand PDU is sent , t he claim ant will respond wit h an LMP_not _accept ed PDU, giving t he reason t hat t he key is m issing. When a link key is m issing, t he devices need t o be paired first . Wit h t he pairing process, an init ializat ion key is generat ed and used t o aut hent icat e t he devices and event ually t o creat e a perm anent link key for t hem . The init ializat ion key is generat ed by ent ering a com m on personal ident ificat ion num ber ( PI N) in bot h of t he pairing devices, which generat es a t em porary key. Not e t hat neit her keys nor t he PI Ns t hat generat e t hem are ever sent in clear form over t he air. Using t he t em porary key generat ed by t he PI N, t he t wo devices m ay proceed wit h t he aut hent icat ion process as if t hey had a link key. The only difference is t hat pairing is init iat ed using an LMP_in_rand PDU inst ead of t he LMP_au_rand PDU. Cert ain devices wit hout a user int erface m ay have a fixed, non- changeable PI N. I n t his case, t he PI N ent ered in a device wit h a user int erface m ust m at ch t his fixed PI N; ot herwise aut hent icat ion is not possible. Aut hent icat ion of Bluet oot h devices depends upon a shared secret . Com m only used public key and cert ificat e schem es are not appropriat e for ad hoc net works of personal devices. These ot her schem es require t he support of t rust ed aut hent icat ion agencies and ot her t hird- part y m eans of com m unicat ion t hat cannot be assum ed t o be available in ad hoc net works. Aut hent icat ion keys are 128 bit s long and are const ruct ed using t he PI N ( only for t he init ial aut hent icat ion) , a 128- bit random num ber, and a device's BD_ADDR. Bluet oot h devices m ay st ore link keys for fut ure aut hent icat ion wit hout t he need t o ent er a PI N each t im e. The t wo prim ary t ypes of link keys are t he unit keys and t he com binat ion keys. The form er are derived from input param et ers available in only one device, while t he lat t er are derived by com bining input param et ers available in each of t he t wo devices. The use of com binat ion keys is preferred, as it provides for a st ronger " bonding" bet ween pairs of devices; a device m ust st ore a separat e com binat ion key for each ot her device it want s t o aut hent icat e using a st ored link key. However, devices of lim it ed st orage capacit y m ay st ore and use j ust a single link key for aut hent icat ion of ot her devices. Link Encryption To prot ect t he privacy of t he dat a flowing over a Bluet oot h link, t he link can be encrypt ed. Encrypt ion in Bluet oot h wireless t echnology is based on a 1- bit st ream cipher, whose im plem ent at ion is included in t he specificat ion. The size of t he encrypt ion key, which changes wit h each BB_PDU t ransm ission, is negot iable t o m at ch applicat ion requirem ent s. The encrypt ion key is derived from t he link key used t o aut hent icat e t he com m unicat ing devices. This im plies t hat prior t o using encrypt ion t wo devices m ust have aut hent icat ed t hem selves at least once. The m axim um key size is 128 bit s, but regulat ory aut horit ies in various count ries m ay lim it t he perm issible m axim um key size. Encrypt ion applies only t o t he payload of BB_PDUs and it is sym m et ric, in t hat bot h direct ions of com m unicat ion are encrypt ed. Encrypt ion is a link propert y in t hat bot h SCO and ACL packet s over t his link are encrypt ed. A request for encrypt ion st art s wit h t he LMP_encrypt ion_m ode_req PDU wit h an encrypt ion m ode param et er t hat dist inguishes encrypt ion of a link bet ween t wo devices ( point - t o- point encrypt ion) , or encrypt ion of broadcast packet s as well. I n t he lat t er case, a m ast er key is creat ed t hat is t o be used for encrypt ion by m ult iple devices in t he piconet . I f t he request for encrypt ion is accept ed, t he devices t hen negot iat e t he size of t he encrypt ion key exchanging

75

LMP_encrypt ion_key_size_req PDUs. I f t he negot iat ion succeeds, t he devices can init iat e encrypt ion by sending an LMP_st art _encrypt ion PDU. Encrypt ion st art s by: ( a) t he m ast er becom ing ready t o receive encrypt ed dat a; ( b) a slave becom ing ready t o t ransm it and receive encrypt ed dat a; and ( c) t he m ast er becom ing ready t o t ransm it encrypt ed dat a.

Power Management and Power-Managed States Devices in a connect ed st at e can regulat e t heir associat ion wit h t he piconet ( s) t o which t hey are connect ed t o preserve power or t o at t end t o ot her business such as part icipat ion in a scat t ernet . There are t hree low- power m odes: sniff, hold, and park; all are opt ional. Apart from m odifying t he propert y of t he link bet ween devices, a device opt ionally m ay request it s com m unicat ing part ner t o adj ust it s t ransm ission power depending on t he qualit y of t he link, as m easured by t he received signal st rengt h of incom ing t ransm issions. Power cont rol for t his case is discussed in Chapt er 2 and is not discussed furt her here. Sniff Mode Typically a slave m ust list en at t he beginning of each even- num bered slot t o see whet her t he m ast er will t ransm it t o t he device. I n t he sniff m ode, a slave m ay relax t his requirem ent for it s ACL link. The m ast er will t ransm it t o t he slave at a reduced dut y cycle by st art ing it s t ransm issions every T sniff slave list ening opport unit ies ( m ast er t ransm it slot s) . I n part icular every, say, T sniff [ j ] list ening opport unit ies, slave j will list en for N sniffAt t em pt [ j ] slot s for a t ransm ission t o it . I f dat a is received, t he slave will cont inue list ening unt il t he t ransm issions st op. The slave will cont inue list ening for an addit ional N sniffTim eout [ j ] list ening opport unit ies for addit ional t ransm issions t o it . While a slave is in t he sniff m ode, any ongoing SCO t ransm issions will st ill occur as scheduled. A m ast er m ay force a slave int o sniff m ode wit h an LMP_sniff PDU. Alt ernat ively, a m ast er or a slave m ay request t hat t he slave ent er int o sniff m ode wit h an LMP_sniff_req PDU. Bot h of t hese LMP_PDUs carry t he t im ing param et ers defining t he slave operat ion in sniff m ode. These LMP_PDUs also carry an offset param et er D sniff t hat det erm ines t he t im e of t he first sniff inst ance. Subsequent sniff inst ances are separat ed by t he period T sniff . I n t he case of a request t o ent er t he sniff m ode, t he m ast er and t he slave m ay negot iat e t he t im ing param et ers for t his m ode. Hold Mode While sniff m ode com m unicat ions are periodic, in hold m ode ACL com m unicat ions wit h a slave are suspended in single inst allm ent s for a t im e int erval referred t o as t he hold t im e. While a slave is in hold m ode, any ongoing SCO t ransm issions will st ill occur as scheduled. A m ast er m ay force a slave int o hold m ode wit h an LMP_hold PDU. Alt ernat ively, a m ast er or a slave m ay request t hat t he slave ent er int o hold m ode wit h an LMP_hold_req PDU. Bot h of t hese LMP_PDUs carry t he init ial value of t he hold t im e. I n t he case of a request t o ent er t he hold m ode, t he m ast er and t he slave m ay negot iat e t he t im ing param et ers for t his m ode. Park Mode I n t he sniff and hold m odes, a slave is st ill considered a fully qualified act ive m em ber of t he piconet and as such it m aint ains it s AM_ADDR t hat was assigned t o it when it j oined t he piconet . Not e t hat while in t hese t wo m odes, SCO t ransm issions wit h t he slave are not int errupt ed.

76

To furt her reduce power consum pt ion during periods of no act ivit y, a slave m ay ent er t he park m ode during which it disassociat es it self from t he piconet , while st ill m aint aining t im ing synchronizat ion wit h t he piconet . By doing so, it can rej oin t he piconet relat ively quickly wit hout having t o perform inquiry and paging procedures. A slave t hat ent ers t he park m ode gives up it s AM_ADDR. On t he ot her hand, t o m anage it s fast and orderly readm ission t o t he piconet , t he m ast er assigns t o t he slave t wo t em porary 8- bit addresses, t he parked m em ber address ( PM_ADDR) and t he access request address ( AR_ADDR) . PM_ADDR is used t o dist inguish up t o 255 parked devices ( act ually, slaves) ; t he address '0x00' is a reserved PM_ADDR. Parked devices could be recalled using t heir 48- bit BD_ADDR if needed, but t he use of t he m uch short er PM_ADDR allows for increased efficiency in recalling m ult iple parked devices. [ 11] AR_ADDR is used in scheduling t he order of readm ission of parked devices in a way t hat m inim izes t he possibilit y of collisions. [11] When the value of PM_ADDR = '0x00'; is assigned to a device, this device can only be unparked using its BD_ADDR. This could be the case when there are at least 255 parked devices in a single piconet, which is a rather exceptional case.

To m aint ain synchronizat ion wit h t he piconet and t o facilit at e t he readm ission of parked devices in t he piconet , t he m ast er defines a low- bandwidt h beacon channel, which consist s of t he periodic t ransm ission of broadcast packet s. Prior t o ent ering park m ode, slaves are not ified of t he t im ing param et ers of t he beacon t ransm issions, and thus t hey know when t hey can wake t o receive possible t ransm issions from t he m ast er. Beacon t ransm issions dest ined t o t he parked st at ions are broadcast t ransm issions ( BB_PDUs wit h AM_ADDR = 'b000') , for t he sim ple reason t hat parked devices don't have an AM_ADDR and t hus t hey cannot be addressed explicit ly. The t im ing param et ers for beacon int ervals are num erous. They include an offset param et er denot ing t he t im e of t he first beacon t ransm ission and t he period of t he beacon inst ances. They also include t he broadcast repet it ion param et er, t he int erval following a beacon inst ant before t he m ast er gives t he opport unit y t o parked devices t o request t o rej oin t he piconet , t he lengt h of t im e t hat t he m ast er will cont inue giving t his opport unit y, and so on. Just as in t he sniff and hold m odes, t he m ast er m ay force a slave int o park m ode wit h an LMP_park PDU. Alt ernat ively, a m ast er or a slave m ay request t hat t he slave ent er int o park m ode wit h an LMP_park_req PDU. When a slave is t o rej oin t he piconet , t he m ast er broadcast s in t he beacon slot s an LMP_unpark_BD_ADDR_req or an LMP_unpark_PM_ADDR_req PDU, depending upon whet her t he parked device is addressed wit h it s 48- bit BD_ADDR or it s 8- bit PM_ADDR. Mult iple parked devices can be invit ed wit h a single unpark LMP_PDU. I n t he unpark LMP_PDUs, t he m ast er also includes t he new AM_ADDR t o be assigned t o t he parked device when it rej oins t he piconet as a slave. Not e t hat a parked device cannot be invit ed t o rej oin a piconet when t here are already seven act ive slaves in t he piconet . I n t he lat t er case, t he m ast er m ay have t o park som e act ive devices and free t he corresponding AM_ADDRs prior t o unparking a parked device.

Bandwidth-Conscious Communications Bluet oot h devices have several opt ions available for m anaging t he bandwidt h t hat is allocat ed bet ween t hem . As m ent ioned earlier, devices m ay use SCO links whose high- priorit y periodic t ransm issions provide for t elephony- qualit y voice com m unicat ions. Transm issions on ACL links can also be provided wit h bandwidt h guarant ees t hrough polling int erval rest rict ions. Support for SCO links is opt ional, while support for ACL polling int erval t ransact ions is m andat ory. Furt herm ore, t o increase t he efficiency of t he t ransm ission and t hus increase t he bandwidt h support ed on an ACL link, link m anagers m ay negot iat e t he use of larger BB_PDUs. Support for t his link m anager t ransact ion is m andat ory; t he act ual use of larger BB_PDUs needs t o be coordinat ed wit h addit ional LMP t ransact ions described below. Finally, devices m ay dynam ically

77

change t he encoding schem es of t he t ransm issions t o t ake bet t er advant age of t he link qualit y condit ions. Support for t his link m anager t ransact ion is opt ional. The lat t er t wo t ransact ions are not discussed furt her. SCO Links A piconet support s up t o t hree SCO links for t elephony- qualit y ( 64 Kbps) voice com m unicat ions. SCO packet s t ransm it t ed on t he SCO links are of high priorit y and can preem pt any ot her act ivit y t hat t he device m ay be involved wit h, like pages and inquiries, holds, and so on. A device request s t he est ablishm ent of an SCO link wit h an LMP_SCO_link_req PDU. This LMP_PDU cont ains t he audio param et ers like t he period T SCO, t he SCO BB_PDU t ype and t he air- m ode, which represent s t he voice codec t ype. Support ed codec t ypes are: 64 Kbps µ- law or A- law PCM form at , or 64 Kbps CVSD ( cont inuous variable slope delt a) m odulat ion form at . Wit h such a high resolut ion of voice t raffic, cellular phone conversat ions carried t o, say, a headset t hat is connect ed wit h a cellular phone over a Bluet oot h SCO link should not degrade in qualit y. When t he m ast er responds posit ively t o a slave's LMP_SCO_link_req PDU or sends it s own LMP_SCO_link_req PDU, it supplies t he offset D SCO t hat ident ifies t he t im e of t he first t ransm ission for t he new SCO link, and an SCO link unique ident ifier, or handle. Eit her t he m ast er or t he slave can subsequent ly request t o change t he param et ers of t he SCO link, using t he LMP_SCO_link_req PDU again, or t o rem ove t he link alt oget her, using an LMP_rem ove_SCO_link_req PDU. The lat t er t ransact ions m ake use of t he SCO link handle t o ident ify t he part icular SCO link whose param et ers or st at us is t o be changed. Quality of Service (QoS) for ACL Links To cont rol t he m inim um bandwidt h assignm ent for ACL t raffic bet ween t wo devices, or equivalent ly t he m axim um access delay of ACL BB_PDUs, t he m axim um polling int erval [ 12] for a slave can be adj ust ed as needed. A m ast er can enforce a new m axim um polling int erval using an LMP_qualit y_of_service PDU. I n t his case, t he slave cannot rej ect t he adj ust m ent of t he polling int erval det erm ined by t he m ast er. On t he ot her hand, a m ast er or a slave m ay request a change in t he polling int erval wit h an LMP_qualit y_of_service_req PDU. I n t his case, t he request can be eit her accept ed or rej ect ed by t he ot her part y. [12] Recall that a master polls a slave either explicitly through the use of a POLL BB_PDU or implicitly by simply transmitting any payload carrying BB_PDU.

Bot h of t hese LMP_PDUs also carry t he num ber of t im es, N BC, t hat each broadcast packet is t o be repeat ed. Since t his param et er relat es t o t he operat ion of t he ent ire piconet , and not j ust t o t he ACL link bet ween a slave and t he m ast er, N BC is m eaningful only when it is sent from t he m ast er. When t his param et er is included in a request LMP_PDU from a slave, it is ignored.

Link Controller Management The t ransact ions in t his sect ion apply t o negot iat ion of param et ers relat ed t o t he link cont roller and t he baseband prot ocols, such as negot iat ion of t he paging schem e, t im ing accuracy, m ast erslave role swit ch and so on. Paging Scheme When t wo devices have already com m unicat ed wit h each ot her, t hey m ay subsequent ly reconnect wit h each ot her m ore rapidly, since t hey can bypass t he inquiry process. However, during an inquiry response, a slave provides paging inform at ion t o t he m ast er in an FHS packet . When bypassing t he inquiry process, t his FHS packet is also bypassed. Thus, if a device has

78

m odified it s paging param et ers, perhaps t o swit ch t o an opt ional paging schem e or t o change it s T pageScan int erval, t he m ast er will not becom e aware of t he change. Wit h t he paging schem e LMP_PDU t ransact ion, devices can announce or even negot iat e t he paging schem e t o be used t he next t im e t hese devices page each ot her. Wit h an LMP_page_m ode_req PDU, t he request ing link m anager suggest s t o t he ot her link m anager t he paging schem e t o be used when t he request ing device pages t he ot her. Likewise, wit h an LMP_page_scan_m ode_req PDU, t he request ing link m anager suggest s t o t he ot her link m anager t he paging schem e t o be used when t he ot her device pages t he request ing device. Rej ect ing any of t hese request LMP_PDUs im plies t hat t he current paging schem e is not t o be changed. However, a request t o change t o t he m andat ory paging schem e cannot be rej ect ed. Support for t his t ransact ion is opt ional. Master-Slave Role Switch A paging device becom es t he default m ast er of t he result ing piconet , alt hough circum st ances m ay necessit at e t hat t he roles of t he m ast er and t he slave be exchanged. For exam ple, such an exchange is needed t o im plem ent t he LAN access profile using PPP ( described in Chapt er 15) . To init iat e t he process of m ast er- slave role swit ch, a device sends an LMP_swit ch_req PDU, which upon accept ance will init ialize t he role swit ch. The swit ch basically com prises t he process of m igrat ing from t he m ast er/ slave t ransm it t im ing sequence in t he piconet of t he old m ast er ( t he new slave) t o t he m ast er/ slave t ransm it t im ing sequence in t he piconet of t he new m ast er ( t he old slave) . Support for a m ast er- slave role swit ch is opt ional. Clock and Timer Information A device can request updat ed clock inform at ion from anot her device t o opt im ize various link cont roller operat ions. An LMP_clock_offset _req [ 13] PDU sent by a m ast er result s in a slave ret urning t he m ost current offset bet ween t he nat ive clocks of t he slave and t he m ast er as regist ered by t he slave. This inform at ion can be used t o opt im ize t he paging t im e when t he m ast er pages t he slave again in t he fut ure. Support for t his t ransact ion is m andat ory. [13]

The name of this LMP_PDU is actually LMP_clkoffset_req.

An LMP_slot _offset PDU carries wit h it t he slot offset , in m icroseconds, bet ween t he st art of t he t im e of a t ransm it slot from t he m ast er and t he corresponding t ransm it slot from t he slave, if t he slave were t o be a m ast er. This inform at ion is used t o opt im ize a m ast er- slave role swit ch. Support for t his LMP_PDU is opt ional. An LMP_t im ing_accuracy_req PDU result s in ret urning t he long- t erm j it t er, in m icroseconds, and drift , in part s per m illion ( ppm ) , of t he receiving device's clock. This inform at ion is used t o opt im ize t he wake t im e for a device aft er a long period of inact ivit y while st ill being associat ed wit h a piconet , such as waking aft er hold m ode, or waking prior t o a m ast er's t ransm ission at a sniff slot or a beacon slot for a parked device. Support for t his LMP_PDU is opt ional; when it is not support ed t he j it t er and accuracy are assum ed t o be at t heir m axim um value of 10 µsec and 250 ppm , respect ively. An LMP_supervision_t im eout PDU sent by a m ast er includes t he link supervision t im eout value used by a link cont roller t o det ect t he loss of a Bluet oot h link bet ween t he m ast er and a slave. Support for t his LMP_PDU is m andat ory. Information Exchange

79

Link m anagers t ypically exchange inform at ion about each ot her t o bet t er coordinat e t heir int eract ion. The LMP_version_req PDU cont ains t he LMP version support ed by t he sender of t his PDU. The receiver of t his LMP_PDU ret urns t he LMP_version_res PDU which cont ains it s own support ed LMP version. The version num ber is provided as a t riplet [ versionNo: com panyI D: subVersionNo] . The version num ber part of t he t riplet is a version of LMP as defined by t he SI G. The subversion num ber is relat ive t o a com pany t hat m ay have it s own part icular im plem ent at ion of t he prot ocol. Support for t his LMP_PDU t ransact ion is m andat ory. The LMP_feat ures_req PDU cont ains t he opt ional radio, baseband, and link m anager feat ures support ed by t he sender of t his LMP_PDU. The receiver of t his LMP_PDU ret urns t he LMP_feat ures_res PDU, which cont ains it s own support ed feat ures. These feat ures include t he support ed packet t ypes, ot her t han t he m andat ory FHS, NULL, POLL, DM1 and DH1; support ed power cont rol m odes, voice codecs, encrypt ion, role swit ch, opt ional paging schem es and so on. Support for t his LMP_PDU t ransact ion is m andat ory. Wit h t he LMP_nam e_req PDU, t he request ing link m anager request s t he user- friendly nam e of t he device t hat receives t his LMP_PDU. The user- friendly nam e is t he nam e t hat a user of a device assigns t o it . Wit hin a device a nam e is encoded in UTF- 8 and it can be up t o 248 byt es long. Since t he nam e of a device can be longer t han a single DM1 packet , when a device request s t he user- friendly nam e of anot her device it also provides an offset param et er t hat t he responding device can use t o t ransm it t he proper segm ent of it s nam e, using t he LMP_nam e_res PDU. The UTF- 8 encoding [ I ETF96] for device nam es has been select ed for it s support of int ernat ional languages because t he Bluet oot h wireless t echnology is t arget ed for worldwide use. UTF- 8 charact ers are encoded using sequences of 1 t o 6 byt es. For com pat ibilit y wit h t he widely used ASCI I charact er set , ASCI I charact ers are encoded using a one- byt e UTF- 8 charact er, which has t he sam e value as t he corresponding ASCI I charact er. Hence, t he user- friendly nam e of a Bluet oot h device can be up t o 248 ASCI I charact ers long. Connection Establishment and Link Detachment LMP is a t ransport prot ocol for cont rol inform at ion bet ween link m anagers in devices. LMP does not encapsulat e PDUs of any higher com m unicat ion layer. As such, LMP t ransact ions m ay occur wit hout involvem ent of any higher layer, such as L2CAP or t he host it self. When a host applicat ion in a device want s t o com m unicat e wit h one in anot her device, t he first device sends an LMP_host _connect ion_req PDU which t he receiving device will eit her accept or not . I f t he connect ion request is accept ed, t he t wo link m anagers will negot iat e t he param et ers of t he link, like aut hent icat ion and QoS. When link m anagers finish negot iat ing, each sends an LMP_set up_com plet e PDU. Only aft er bot h link m anagers have issued t he LMP_set up_com plet e PDU can com m unicat ion t hat does not involve LMP_PDUs com m ence bet ween t he devices. When any device want s t o t erm inat e it s link wit h anot her device, it issues an LMP_det ach PDU wit h a reason param et er explaining why t he link is t o be t erm inat ed. The LMP_det ach PDU cannot be cont est ed and t he link bet ween t he t wo devices will be t erm inat ed im m ediat ely. Support for t he LMP_PDUs in t his sect ion is m andat ory.

80

Summary I n t his chapt er we have highlight ed t he lower Bluet oot h t ransport prot ocols: radio, baseband, and link m anager. These prot ocols define t he operat ional charact erist ics of t he Bluet oot h wireless t echnology and inst ant iat e t he Bluet oot h air- int erface. Bluet oot h devices use relat ively high rat e frequency- hopping spread- spect rum t ransceivers operat ing over 79 ( or 23) 1 MHz channels in t he 2.4 GHz I SM RF band. Devices find ot hers in t heir vicinit y using inquiries and request connect ions t o t hose devices by explicit ly paging t hem . Com m unicat ing devices are organized in piconet s com posed of a m ast er and one or m ore slave devices. Device t ransm issions are organized over a TDD t ransm ission t im e axis, wit h t he slaves t ransm it t ing only when t hey have been first addressed by t he m ast er. Bluet oot h links bet ween devices can support bot h asynchronous and synchronous t ransm issions, and t hey can be aut hent icat ed, encrypt ed, and condit ioned based on QoS dem ands. The next chapt er present s t he upper t ransport prot ocols, which aim t o conceal t he det ails of t he lower t ransport prot ocols from higher layers and applicat ions. This allows t he higher layers t o use t he Bluet oot h links in a m anner t hat is agnost ic of t he way t hat connect ions and t ransm issions bet ween devices are organized and m anaged over t he Bluet oot h air- int erface.

81

Chapter 7. The Upper Protocols of the Transport Group The lower t ransport prot ocols are opt im ized t o deal wit h t he host ilit y of t he RF t ransm ission m edium , user requirem ent s for low cost and power consum pt ion, securit y concerns, regulat ory issues, and so on. These design point s have led t o, am ong ot her t hings, select ion of t he TDD, polling- based m edium access prot ocol at t he baseband. While t his approach is suit able for operat ion of Bluet oot h syst em s in t he 2.4 GHz I SM band, t he sm all size of a BB_PDU does not fare so well wit h t he m uch larger packet sizes t ypically encount ered wit h I nt ernet and ot her sim ilar t raffic. I t was t hus recognized early on t hat an adapt at ion layer was needed t o m ove larger upper- layer PDUs and sm aller lower- layer PDUs back and fort h am ong t he prot ocol st ack layers. This adapt at ion layer was originally called level 2 m edium access cont rol ( MAC- 2) , at a t im e when MAC- 1 represent ed t he m edium access cont rol prot ocol at t he baseband level. But t he nam e MAC- 1 never prevailed, and so MAC- 2 did not apply eit her. I t was t herefore decided lat e in t he sum m er of 1998 t o change t he nam e from MAC- 2 t o a m ore descript ive one, and t he nam e logical link cont rol and adapt at ion prot ocol ( L2CAP) cam e int o being. I ncident ally, short ly aft er t he first L2CAP draft specificat ion was produced in Sept em ber 1998, a port ion of t hat specificat ion was split out int o it s own independent docum ent , spawning a brand- new act ivit y in t he SI G. Specifically, t he Bluet oot h discovery prot ocol ( BDP) sect ion of t he MAC- 2 and early L2CAP specificat ions grew in scope and result ed in t he service discovery prot ocol ( SDP) specificat ion highlight ed in t he next chapt er. This chapt er describes L2CAP, which is cert ainly one of t he m ost im port ant layers in t he st ack. I n t he reference im plem ent at ion shown in Figure 6.1 in t he previous chapt er, t he L2CAP layer [ 1] is a soft ware com ponent t hat resides wit hin a host . To perm it L2CAP and higher prot ocol layers and applicat ions t o t ransfer and receive cont rol and applicat ion dat a t o and from any vendor's Bluet oot h m odule in a st andardized way, t he SI G has developed a prot ocol t hat allows t he host t o com m unicat e t o t he m odule in an int eroperable m anner. This prot ocol is t he host cont roller int erface ( HCI ) , supplem ent ed wit h a series of HCI t ransport prot ocols, which are m echanism s used t o t ransfer HCI dat a across various physical connect ors, like USB port s, RS- 232 port s, and so on. This chapt er also discusses HCI and it s t ransport prot ocols. [1] This layer is more appropriately called "L2CA layer" or "L2CAL," but since L2CAP is phonetically more pleasing than either L2CA or L2CAL, the technically inappropriate usage of the term "L2CAP layer" or even just "L2CAP" has tacitly prevailed. Here, the use of the term "L2CAP" as a noun is reserved primarily for the protocol used to communicate between L2CAP layers in different devices.

Figure 7.1 is a refinem ent of Figure 6.1 and depict s t he placem ent of t he t ransport prot ocols in a reference im plem ent at ion of a Bluet oot h device. Not e t hat t he link m anager and host I / O block in Figure 6.1 has been separat ed int o t wo logical com ponent s, which m ay nevert heless run on t he sam e firm ware plat form . The host cont roller int eract s wit h bot h t he host and t he Bluet oot h m odule hardware and firm ware com ponent s t o t ransfer dat a bet ween t hem . On t he host side, t he HCI layer execut es t he HCI com m unicat ions prot ocol t o carry dat a t o and from t he m odule ( t hrough t he host cont roller) and t he host it self.

82

Figu r e 7 .1 . Th e t r a n spor t pr ot ocol gr ou p pla ce m e n t in a Blu e t oot h r e fe r e n ce im ple m e n t a t ion .

The L2CAP Layer The prim ary role of t he L2CAP layer is t o hide t he peculiarit ies of t he lower- layer t ransport prot ocols from t he upper layers. By doing so, a large num ber of already developed higher- layer t ransport prot ocols and applicat ions can be m ade t o run over Bluet oot h links wit h lit t le, if any, m odificat ion. The L2CAP layer concerns it self only wit h asynchronous inform at ion ( ACL packet ) t ransm ission. I t s packet s, referred t o as L2CAP_PDUs, are carried on ACL BB_PDUs whose L_CH field in t he payload header has t he value 'b10', denot ing t he st art of an L2CAP_PDU, or 'b01', denot ing t he cont inuat ion of an L2CAP_PDU ( see Table 6.5 in t he previous chapt er) . Even t hough L2CAP_PDUs are closely associat ed wit h ACL BB_PDUs, t he lower t ransport prot ocol concept s of m ast er, slave, polling, frequency hopping sequences, nat ive clocks, and so on are m eaningless at t he L2CAP layer. The lower t ransport layers provide t he equivalent of a packet int erface t o L2CAP over which L2CAP sends and receives it s dat a and cont rol m essages, but L2CAP and higher layers are ot herwise insulat ed from t he lower t ransport prot ocols. The L2CAP layer support s higher- layer prot ocol m ult iplexing, com pensat ing for t he lack of such support at t he lower t ransport layers. Furt herm ore, it facilit at es t he segm ent at ion and reassem bly of larger- size, higher- layer packet s t o and from t he sm aller baseband packet s. Since no knowledge of BB_PDUs exist s at t he L2CAP layer, not t o m ent ion knowledge of t heir t ransm ission size, t he L2CAP layer it self does not perform segm ent at ion and reassem bly of lowerlayer PDUs. However, it facilit at es t hese operat ions by providing L2CAP_PDU lengt h inform at ion in it s PDUs, allowing a reassem bly engine t o verify t hat it has reconst ruct ed t he PDU correct ly. Moreover, t he L2CAP layer export s m axim um - packet - size inform at ion t o higher layers t hat inform s t hem of t he largest packet size t hat L2CAP layers in ot her devices can handle. I t is t he responsibilit y of t he higher layer t o fragm ent it s inform at ion int o packet s t hat do not violat e t he L2CAP m axim um packet size. I n addit ion, t he L2CAP layer support s t he exchange of qualit y- of- service ( QoS) inform at ion, which aids in cont rolling t he t ransm ission resources in a way t hat support s t he expect ed QoS. Finally, t he L2CAP layer also provides a group abst ract ion t o higher layers. This allows m apping groups of higher- layer prot ocol addresses int o piconet s wit hout exposing t he concept of a piconet t o t he higher layers. The L2CAP layer assum es t hat t he underlying t ransm ission facilit ies ( t hat is, t he lower t ransport prot ocols) provide a full- duplex com m unicat ion channel t hat delivers L2CAP_PDUs in an orderly m anner. L2CAP it self does not provide any m echanism s for securing t he reliable t ransm ission of

83

it s PDUs. I nst ead, it relies upon t he ret ransm ission process at t he baseband layer t o support a sufficient ly reliable com m unicat ion channel for higher layers.

L2CAP Channels Com m unicat ion bet ween L2CAP layers is based on logical links, called channels, t hrough which L2CAP t raffic flows bet ween endpoint s wit hin each device. Each endpoint of a channel is assigned a unique channel ident ifier ( CI D) . A CI D is a 16- bit ident ifier t hat is locally adm inist ered. An L2CAP layer assigns a different CI D t o every channel endpoint used t herein. [ 2] [2]

Strictly speaking, "local" CIDs assigned by an L2CAP layer need to be unique only within the set of channels that this L2CAP layer establishes with a single "remote" L2CAP layer.

Figu r e 7 .2 . L2 CAP ch a n n e ls; a lt h ou gh n ot show n , e ve r y e n dpoin t is a ssocia t e d w it h a pa yloa d r e cipie n t e n t it y.

Figure 7.2 shows t he L2CAP layers in t hree devices exchanging inform at ion using L2CAP channels. Each channel t erm inat es at an endpoint wit hin t he L2CAP layer. Each L2CAP endpoint is uniquely associat ed wit h a payload recipient ent it y t o which t he payload of t he L2CAP_PDU is direct ed for addit ional processing. The payload recipient ent it y m ay reside wit hin t he L2CAP layer it self and be used for signaling purposes bet ween com m unicat ing L2CAP layers. The payload recipient ent it y m ay also reside above t he L2CAP layer, in which case it represent s t he higher layer whose PDUs are t ransport ed across Bluet oot h links by t he L2CAP layer. The figure ident ifies t he various t ypes of L2CAP channels current ly defined. There are persist ent connect ion- orient ed ( CO) channels t hat are used for bidirect ional com m unicat ions; t hese require a connect ion signaling exchange prior t o being est ablished. There are ephem eral connect ionless ( CL) channels t hat are unidirect ional and can be used for broadcast t ransm issions t o groups of devices. Since t hese channels are unidirect ional, a device t hat needs t o respond t o a

84

connect ionless L2CAP t ransm ission m ust use anot her channel t o do so. Finally, t here are signaling channels t hat are used prim arily t o exchange cont rol inform at ion t hat is used t o est ablish and configure CO channels. Signaling channels borrow feat ures from bot h CO and CL channels. Just like CL channels, t hey do not require an explicit connect ion est ablishm ent prior t o com m encing com m unicat ions over t hem , but t hey are persist ent and bidirect ional in t hat inform at ion flows in bot h direct ions over t he sam e signaling channel. A num ber of CI Ds are reserved for well- defined, globally known channels, while t he rem aining CI Ds are adm inist ered as needed. Table 7.1 sum m arizes t he various CI D t ypes. Bet ween t wo devices t here can be m any CO and m any CL channels, but only one signaling channel, since t here exist s only one CI D t hat can be assigned t o bot h endpoint s of t he signaling channel. Owing t o t his rest rict ion, each signaling channel can be viewed as a CO channel whose connect ion phase has been elim inat ed because t he CI D inform at ion defining t hat channel is already known t o t he devices; t hus t he channel is preconfigured wit h fixed param et ers.

Ta ble 7 .1 . Th e CI D a ssign m e n t t ype s. CI D

Com m e n t s

'0x0000'

null ident ifier, not t o be assigned

'0x0001'

CI D for bot h endpoint s of an L2CAP signaling channel

'0x0002'

CI D for t he dest inat ion endpoint of a CL L2CAP channel

'0x0003'– '0x003F'

range of reserved CI Ds

'0x0040'– '0xFFFF'

range of CI Ds allocat ed on dem and by a device t o it s local endpoint s for eit her CL or CO L2CAP channels

At t he out set t he MAC- 2 prot ocol ( L2CAP's predecessor) was t o provide only connect ionless services t o t he upper layers. Over t im e it was recognized t hat for t his layer t o be ext ensible and t o rem ain relevant and am enable t o fut ure enhancem ent s ( such as support for qualit y of service) , it needed t o provide configurable t raffic services. The lat t er need led t o t he developm ent and inclusion of configurable connect ion- orient ed services in t he L2CAP layer. Today t his connect ionorient ed service is t he prim ary one provided by t he L2CAP layer. I n version 1.0, only t he TCSbased t elephony profiles ( described in Chapt er 13) require t he use of CL L2CAP channels.

L2CAP_PDU Types There are t wo t ypes of L2CAP_PDUs: t he first is used wit h CO channels and t he second wit h CL channels. Signaling L2CAP_PDUs are form ed according t o t he form er t ype. The Connectionless (CL) L2CAP_PDU Type Table 7.2 sum m arizes t he fields of a CL L2CAP_PDU in t he order of t ransm ission. Not e t hat each header field uses a lit t le- endian byt e order wit h t he least significant byt e t ransm it t ed first ; all fields in t he L2CAP_PDU headers follow t his lit t le- endian t ransm ission convent ion.

Ta ble 7 .2 . Th e for m a t of a con n e ct ion le ss L2 CAP_ PD U. fie ld

size

com m e nt s

L2 CAP_ PD U_ CL_ H e a de r

85

Ta ble 7 .2 . Th e for m a t of a con n e ct ion le ss L2 CAP_ PD U. fie ld Lengt h

size 2 byt es

com m e nt s t ot al lengt h in byt es of t his L2CAP_PDU excluding t he Lengt h and CI D fields 2)

Dest inat ion_CI D 2 byt es

indicat es t he CI D of t he dest inat ion endpoint of t he L2CAP channel used for t his t ransm ission: has fixed value '0x0002'

PSM

prot ocol and service m ult iplexer

2 byt es

L2 CAP_ PD U_ CL_ Pa yloa d Payload

( Lengt h – PSM_field_size) byt es

CL L2CAP_PDU payload dat a; t he m axim um possible size is 65,535 byt es m inus t he size of t he PSM field, which t ypically is 2 byt es

The PSM field provides t he m eans for ident ifying t he higher- layer recipient of t he payload of t his connect ionless L2CAP_PDU. I t is discussed in m ore det ail below along wit h t he signaling L2CAP_PDUs for CO channels. The m inim um support ed value for m axim um t ransm ission unit ( MTU) for payloads in CL L2CAP_PDUs is MTU CL = 670 byt es, unless explicit ly st at ed ot herwise, say, in a profile specificat ion. [ 3] [3] The various L2CAP MTUs discussed in this chapter apply only to the payload section of the corresponding L2CAP_PDUs. Thus, the MTU information is used by the payload recipient entities at the endpoints of an L2CAP channel, see Figure 7.2, to adjust the maximum size of PDUs that they can send or receive over this L2CAP channel.

The Connection-Oriented (CO) L2CAP_PDU Type Table 7.3 sum m arizes t he fields of a CO L2CAP_PDU in t he order of t ransm ission. As m ent ioned earlier, each header field uses a lit t le- endian byt e order wit h t he least significant byt e t ransm it t ed first .

Ta ble 7 .3 . The for m a t of a con n e ct ion - or ie n t e d L2 CAP_ PD U. fie ld

size

com m e nt s

L2 CAP_ PD U_ CO_ H e a de r Lengt h

2 byt es

Dest inat ion_CI D 2 byt es

t ot al lengt h of t his L2CAP_PDU excluding t he L2CAP_header(

0)

indicat es t he CI D of t he dest inat ion endpoint of t he L2CAP channel used for t his t ransm ission

L2 CAP_ PD U_ CO_ Pa yloa d Payload

Lengt h byt es

CO L2CAP_PDU payload dat a; t he m axim um possible size is 65,535 byt es

Com paring t he headers of t he CL and CO L2CAP_PDUs, one m ay not ice a subt le difference in t he definit ion of t he corresponding Lengt h fields. The PSM field in a CL L2CAP_PDU is t reat ed as if it were part of t he payload, hence it s size is account ed for when calculat ing t he Lengt h field. This difference is int ended t o m axim ize code reuse when processing L2CAP_PDUs of eit her t ype.

86

The MTU for payloads in CO L2CAP_PDUs, MTU CO, as well as ot her param et ers of a CO channel, are negot iat ed during t he connect ion est ablishm ent phase using t he L2CAP signaling discussed in t he following sect ion.

L2CAP Channel Management: The L2CAP Signaling Connect ion- orient ed, point - t o- point L2CAP channels use signaling t o becom e est ablished, t o be configured, and t o be t erm inat ed. During t he connect ion est ablishm ent phase, t he payload recipient ent it y in an upper layer of L2CAP_PDUs is ident ified and t he endpoint CI Ds for t he newly form ed channel are exchanged bet ween t he t wo com m unicat ing L2CAP layers. During t he connect ion est ablishm ent phase, t he propert ies for each direct ion of t ransm ission on t he channel are negot iat ed and agreed upon. These propert ies include t he payload MTUs, t he reliabilit y level of t ransm issions bet ween t he involved devices, and QoS. L2CAP signaling consist s of request and response PDU t ransact ions carried over t he signaling channel whose endpoint s bot h have t he reserved CI D value '0x0001'. A device, referred t o as t he local device, sends an L2CAP signaling request PDU ( for exam ple, t o creat e or configure a channel) t o a rem ot e device, and t he rem ot e device responds t o t he local device's request wit h a corresponding L2CAP signaling response PDU. Each t ransact ion is ident ified by a t ransact ionI D t hat m at ches a request from a local device wit h t he subsequent response from t he rem ot e device. Cont rary t o ot her L2CAP_PDU t ransm issions, L2CAP signaling t ransact ions are reliable in t hat a local device m ay ret ransm it a request if a response is not received wit hin a t im eout period. The decision about whet her or not t o ret ransm it a request , as well as t he value of t he t im eout period, are im plem ent at ion dependent . The t im eout period is at least 1 second and can be up t o 60 seconds. A local device m ay wait up t o an addit ional 300 seconds t o receive t he final response if t he rem ot e device has responded indicat ing t hat it has received an init ial request but needs addit ional t im e t o com plet e it s processing. For exam ple, a request for connect ion m ay require a device aut hent icat ion t o occur first , which in t urn, m ay require t he device t o ent er a PI N as discussed in Chapt er 6.

Figu r e 7 .3 . Th e m a n a ge m e n t a n d da t a - e x ch a n ge ph a se s of a CO ch a n n e l a n d t h e loca l/ r e m ot e de vice r ole s.

87

Figure 7.3 shows a t ypical sequence of L2CAP signaling t ransact ions bet ween a local and a rem ot e device. This sequence st art s wit h t he L2CAP layer of t he local device t ransm it t ing a request for t he creat ion of a channel bet ween t he devices. The rem ot e device responds by eit her accept ing or rej ect ing t he request . Upon accept ance of t he request and est ablishm ent of t he channel, t he local device init iat es configurat ion of t he channel for one direct ion of com m unicat ion. The configurat ion param et ers are dict at ed by t he im plem ent at ion lim it at ions of t he L2CAP layer, including t he L2CAP MTU t hat can be used on t his channel and t he QoS requirem ent s of t he applicat ions t hat will be using t his channel. The rem ot e device responds posit ively or negat ively t o t he local device's configurat ion param et ers. A negat ive response causes a configurat ion negot iat ion phase bet ween t he devices unt il t hey bot h agree upon t he configurat ion param et ers. Following t he t erm inat ion of configurat ion in one direct ion, t he devices exchange t heir local and rem ot e roles and t he configurat ion process cont inues likewise in t he opposit e direct ion. Upon t erm inat ion of t he configurat ion phase, t he channel is ready t o receive and t ransport PDUs from higher layers over t he newly est ablished channel. Subsequent channel reconfigurat ion could happen at any t im e t hat t he channel is act ive and could be init iat ed by eit her device. The L2CAP channel t erm inat es when eit her device init iat es t he t erm inat ion phase. The header of t he L2CAP signaling PDUs resem bles t hat of a CO L2CAP_PDU, wit h t he dest inat ion endpoint CI D field having t he reserved CI D value '0x0001'. The payload of t he signaling PDUs consist s of a collect ion of signaling com m ands. All L2CAP im plem ent at ions m ust be able t o accept signaling PDUs wit h an MTU SI G of 48 byt es. Table 7.4 sum m arizes t he fields of a signaling com m and.

Ta ble 7 .4 . Th e for m a t of a n L2 CAP sign a lin g com m a n d. fie ld

size

com m e nt s

L2 CAP_ Sign a ling_ Com m a nd_ H e a de r

88

Ta ble 7 .4 . Th e for m a t of a n L2 CAP sign a lin g com m a n d. fie ld Code

size 1 byt e

com m e nt s ident ifies t he com m and t ype

I dent ifier 1 byt e

ident ifies t he signaling t ransact ion, t ransact ionI D, for m at ching responses t o corresponding request s; ret ransm it t ed com m ands use t he sam e ident ifier

Lengt h

t ot al lengt h of t he payload port ion of t his com m and (

2 byt es

0)

L2 CAP_ Sign a ling_ Com m a nd_ Pa yloa d Payload

Lengt h byt es

signaling com m and payload dat a ( collect ion of signaling com m ands)

Signaling com m ands wit h an unsupport ed code result in an L2CAP_Com m and_Rej ect com m and ( Code = '0x01') being t ransm it t ed in t he reverse direct ion. The L2CAP_Connection_Request Signaling Command When a local device want s t o est ablish a CO L2CAP channel wit h a rem ot e device, it form s and sends an L2CAP_Connect ion_Request signaling com m and ( Code = '0x02') t o t he rem ot e device. The significant fields of t he com m and are sum m arized in Table 7.5; not e t hat t he t able does not show all t he fields of t he com m and and m ust be int erpret ed wit h respect t o t he signalingcom m and form at in Table 7.4.

Ta ble 7 .5 . Th e L2 CAP_ Con n e ct ion _ Re qu e st sign a lin g com m a n d. fie ld

size

com m e nt s

L2 CAP_ Con n e ct ion _ Re qu e st _ Com m a n d_ Pa yloa d PSM

2 byt es

ident ifies t he dest inat ion payload processing ent it y for t he L2CAP_PDUs t ransm it t ed t o t he rem ot e device over t he request ed channel

Source_CI D 2 byt es t he CI D for t he request ed channel endpoint in t he local device I f and when t he channel is est ablished, t he rem ot e device will use t he value in t he Source_CI D field as t he Dest inat ion_CI D ( see Table 7.3) t o send L2CAP_PDUs t o t he local device over t his CO channel. The PSM ( prot ocol and service m ult iplexer) field is a variable- size field wit h a m inim um ( and t ypical) size of 2 byt es. I t is used for m ult iplexing several prot ocols over t he L2CAP layer. I n part icular, t he local device uses t he PSM field t o inform t he rem ot e device about where t o direct t he payload of t he L2CAP_PDU t ransm issions over t his channel. Alt hough t he PSM field is used for m ult iplexing m iddleware prot ocols t hat use L2CAP's t ransport services, like SDP, RFCOMM, TCS, and so on, it goes a st ep furt her. PSM could also ident ify one of m any im plem ent at ions of a prot ocol layer, or even an ent ire prot ocol st ack, t hat reside above L2CAP. For exam ple, a m anufact urer could im plem ent t wo independent RFCOMM layers wit hin a single device. I n t his case, m ult iplexing sim ply on t he nam e of t he RFCOMM prot ocol would not be very helpful. The PSM field aids in dist inguishing t he t wo RFCOMM im plem ent at ions by assigning a different PSM value t o each of t hem .

89

The range of values for t he PSM field is divided int o t wo regions. The first region covers t he PSM values up t o '0x1000' and consist s of reserved values t hat represent est ablished, well- known prot ocols t hat direct ly use L2CAP, such as SDP ( PSM = '0x0001') or RFCOMM ( PSM = '0x0003') . [ 4] The region of PSM values above '0x1000' is used t o ident ify m ult iple im plem ent at ions of a given prot ocol above L2CAP ( as described above) , prot ocols not yet st andardized, experim ent al prot ocols under developm ent , and so on. The PSM value for a given connect ion can be ret rieved from service discovery records using SDP as described in t he next chapt er. [4]

The values of the PSM field are always odd, thus providing a simple means for extending the PSM field beyond its typical size of 2 bytes.

Originally, t he PSM field was j ust a Prot ocol field, used t o ident ify a specific prot ocol t hat could be m ult iplexed over t he L2CAP layer. The L2CAP working group in t he SI G realized t hat enhanced syst em securit y requires t he abilit y t o ident ify not j ust t he prot ocol used but also t he applicat ion associat ed wit h t he connect ion request . I n t his respect , t he L2CAP layer was recognized as t he nat ural choice in which t o add any securit y safeguards. But an L2CAP connect ion request using j ust t he Prot ocol field could not ident ify t he applicat ion t hat would ult im at ely use t he connect ion. Thus, t he PSM field was int roduced t o ident ify a prot ocol st ack from t he L2CAP layer all t he way up t o t he service provided by t he applicat ion t hat would use t he newly form ed channel. Event ually, t he group consensus about securit y at t he L2CAP layer t ook a m ore general pat h and is highlight ed in [ Muller99] . However, t he PSM field did not revert back t o t he Prot ocol field. I t was recognized t hat t he added m ult iplexing flexibilit y t hat t he PSM field int roduced was t oo powerful t o ignore. Thus, t he use of t he PSM field has persist ed in t he specificat ion, alt hough it s nam e is now som ewhat out dat ed, and it can be used t o m ult iplex not only prot ocols, but m ult iple st ack im plem ent at ions as well. This feat ure is t ruly unique t o t he L2CAP layer. The L2CAP_Connection_Response Signaling Command Following t he receipt of an L2CAP_Connect ion_Request com m and, t he rem ot e device ret urns an L2CAP_Connect ion_Response com m and ( Code = '0x03') t o inform t he local device whet her or not it accept s t he connect ion request . The rem ot e device could also ret urn a connect ion pending response t o inform t he local device t hat t he connect ion request has been received but no decision has been m ade yet ; t he rem ot e L2CAP layer could, for exam ple, await t he result of an aut hent icat ion procedure before deciding t o accept or rej ect t he connect ion. I f a connect ion is refused, t he rem ot e device provides t he reason( s) for doing so, which could include securit y issues, resources not available, or PSM value not support ed. Finally, t he rem ot e device also ret urns t he Dest inat ion_CI D t hat ident ifies t he CI D of t he channel endpoint locat ed in t he rem ot e device. This CI D is m eaningful only if t he connect ion is accept ed, and it is used as t he Dest inat ion_CI D field of t he CO L2CAP_PDUs t hat t he local device subsequent ly sends t o t he rem ot e device over t his CO channel. The L2CAP_Configuration_Request Signaling Command Following channel est ablishm ent , t he channel needs t o be configured. The channel configurat ion t ransact ion is m andat ory; however, em pt y configurat ion com m ands m ay be sent when not hing needs t o be configured. Configurat ion t ransact ions for a channel m ay occur again at a lat er t im e aft er norm al com m unicat ions have com m enced for t he channel. The key fields of t he L2CAP_Configurat ion_Request com m and ( Code = '0x04') are sum m arized in Table 7.6.

Ta ble 7 .6 . Th e L2 CAP_ Con figur a t ion _ Re qu e st sign a lin g com m a n d. fie ld

size

com m e nt s

L2 CAP_ Con figu r a t ion _ Re que st _ Com m a nd_ Pa yloa d

90

Ta ble 7 .6 . Th e L2 CAP_ Con figur a t ion _ Re qu e st sign a lin g com m a n d. fie ld

size

com m e nt s

Dest inat ion_CI D 2 byt es

for t he channel t o be configured, ident ifies t he CI D of t he channel endpoint in t he device t hat receives t his com m and ( t he rem ot e device)

Flags

2 byt es

in version 1.0, only t he LSB is used t o signify t hat addit ional configurat ion opt ions are t o follow in a subsequent configurat ion com m and from t he local device

Config_Opt ions

variable configurat ion opt ions for t he channel t o be configured

The LSB of t he Flags field, referred t o as t he C bit , is used as a cont inuat ion flag for addit ional configurat ion opt ions t o follow in subsequent configurat ion com m ands. Segm ent at ion of t he configurat ion opt ions in m ult iple configurat ion com m ands m ay be necessit at ed by t he sm all MTU SI G value. Before exam ining t he configurat ion opt ions, we discuss t he corresponding response com m and from t he rem ot e device, which also cont ains a sim ilar set of configurat ion opt ions. I n t he L2CAP_Configurat ion_Response com m and ( Code = '0x05') t hat corresponds t o an L2CAP_Configurat ion_Request com m and sent from a local device, [ 5] t he responding ( rem ot e) device st at es whet her or not it agrees wit h t he values of t he various configurable param et ers in t he L2CAP_Configurat ion_Request com m and. I f a configurat ion opt ion in an L2CAP_Configurat ion_Request com m and is not support ed by t he rem ot e device, it rej ect s t he request and includes in it s response a copy of t he unsupport ed opt ion( s) . [5] Recall that we have defined a local device to be the device that originates an L2CAP signaling transaction, which starts with the transmission of a request command. The responding device is the remote device.

When an L2CAP_Configurat ion_Request com m and is rej ect ed due t o disagreem ent wit h t he values of any of t he configurable param et ers, t he rem ot e device m ay eit her t erm inat e t he configurat ion process or provide t he values of t he param et ers t hat could have been accept able t o it . I n t his case, t he local device m ay subm it a new L2CAP_Configurat ion_Request com m and wit h t he configurat ion param et er values readj ust ed; t he num ber of successive resubm issions of L2CAP_Configurat ion_Request com m ands is im plem ent at ion dependent . I f no agreem ent is reached bet ween t he local and rem ot e devices, t he current configurat ion param et ers rem ain in effect , or t he channel is t erm inat ed. The durat ion of configurat ion negot iat ions is im plem ent at ion dependent , but t he m axim um t im e is 120 seconds. Not e t hat any response from t he rem ot e device regarding a configurat ion opt ion is exclusively for t he direct ion of t raffic flow im plied by t he L2CAP_Configurat ion_Request com m and. For exam ple, if t he configurable param et er in an L2CAP_Configurat ion_Request com m and refers t o t raffic leaving t he local device, an out going t raffic param et er, any reference t o t his param et er by t he rem ot e device will refer t o t he sam e t raffic param et er arriving at t he rem ot e device, an incom ing t raffic param et er. Following t erm inat ion of configurat ion t ransact ions in one direct ion, t he role of t he local and rem ot e devices is reversed once and configurat ion of t he channel param et ers in t he opposit e direct ion m ay com m ence. This gives t he ot her device ( t he form er rem ot e device) t he opport unit y t o configure it s t raffic param et ers as well. The Configuration Options Table 7.7 list s t he com m unicat ions param et ers t hat can be adj ust ed t hrough configurat ion. The int erpret at ion of t hese param et ers is relat ive t o t he local device—t hat is, t he device t hat

91

originat es t he L2CAP_Configurat ion_Request com m and and cont ains t he configurat ion opt ion relat ed t o t hese param et ers.

Ta ble 7 .7 . Th e con figur a t ion opt ion s. pa r a m e t e r MTU

com m e nt s ident ifies t he m axim um L2CAP_PDU payload, in byt es, t hat t he local device can accept over t his channel; m inim um MTU CO = 48 byt es, default MTUCO = 672 byt es[ 1]

CO

Flush_Tim eout ident ifies t he am ount of t im e, in m ult iples of 1.25 m illiseconds, during which t he link m anager of t he local device will cont inue at t em pt ing t o t ransm it t he baseband segm ent s from an L2CAP_PDU, prior t o discarding it ; by default t heFlush_Tim eout value indicat es a reliable channel where PDUs are ret ransm it t ed for as long as required, or unt il t he link is declared lost QoS

ident ifies t he t raffic- flow specificat ion for t he local device's t raffic ( out going direct ion) over t his channel [1]

While the minimum MTUCO was chosen to accommodate buffering capabilities of "simple" devices, such as headsets, the default value was chosen so that it can conveniently fit within two DH5 BB_PDUs.

The QoS opt ion includes a Service_Type param et er t hat det erm ines whet her or not t raffic will be sent in t he out going direct ion by t he local device. I f yes, t hen t he Service_Type furt her det erm ines if t he out going t raffic will be t reat ed by t he local device as best effort or guarant eed. Best - effort t raffic is t he default and m andat ory service t ype support ed by any L2CAP- layer im plem ent at ion. Wit h t he guarant eed service t ype, t he local device provides t he QoS param et ers associat ed wit h it s out going t raffic flow. These QoS param et ers consist of a subset of t he ones specified in [ I ETF92] and include: Token_Rat e, Token_Bucket _Size, Peak_Bandwidt h, Lat ency, and Delay_Variat ion. All of t hese param et ers have default values of " not specified." These values are ult im at ely com m unicat ed t o t he link m anager of t he local device, which t hen negot iat es wit h t he link m anager of t he rem ot e device t o det erm ine an appropriat e polling int erval t hat support s t he desired QoS. The QoS param et ers m ust be passed t o t he L2CAP layer from t he upper layers. Following any configurat ion negot iat ion for t hese values, t he L2CAP layer uses t he result ing param et er values t o cont rol t he adm ission of new connect ion request s init iat ed by upper layers of t he st ack. Based on t heir QoS requirem ent s, t he L2CAP layer m ay decide t o rej ect any new connect ion request s if it concludes t hat est ablishing a new L2CAP channel wit h a rem ot e device could com prom ise t he QoS of any exist ing channel. Wit h t he except ion of MTU CO, t he definit ion and use of t he QoS param et ers was a source of m uch debat e wit hin t he SI G's L2CAP t ask force. The QoS discussions cont inued t o t he very day t hat t he specificat ion was finalized for publicat ion in t he sum m er of 1999. Debat e cent ered around t he m eaning of t he QoS param et ers, t heir applicabilit y, im plem ent at ion effort required, t he way t hey should be negot iat ed, and so on. No version 1.0 profile support s anyt hing but best effort t raffic; hence, t he QoS param et ers easily could have been om it t ed from t he version 1.0 specificat ion. While proposals t o do j ust t hat were circulat ed, it was finally decided t hat including QoS param et ers in t he specificat ion was preferable. Having a st andardized set of QoS param et ers enables experim ent at ion wit h t hem ; t his could help soft ware developers gain QoS experience such t hat whenever t he need arises in any fut ure profiles for t he use of QoS guarant ees, a solid foundat ion of knowledge and im plem ent at ion experience will exist t o efficient ly address t he problem . I nclusion of t he QoS param et ers is an exam ple of t he SI G addressing fut ure flexibilit y of t he specificat ion rat her t han an im m ediat e requirem ent of a version 1.0 usage m odel.

92

Other Configuration Commands The m ost com m only used signaling t ransact ions pert ain t o t he L2CAP_Connect ion_Request and L2CAP_Configurat ion_Request signaling com m ands, t oget her wit h t heir corresponding response com m ands, and a channel t erm inat ion request and response t ransact ion using t he L2CAP_Disconnect ion_Request / _Response signaling com m ands. L2CAP signaling also provides t wo addit ional exchanges used for t est ing and inform at ion gat hering. The L2CAP_Echo_Request and L2CAP_Echo_Response com m and t ransact ion is used t o t est t he connect ion t o a rem ot e device, in a m anner sim ilar t o t he ping com m and in I P net works. The echo com m ands cont ain an opt ional payload port ion, which could be used t o pass inform at ion bet ween t he devices in a nonst andard, propriet ary ( vendor- specific) m anner. The L2CAP_I nform at ion_Request and L2CAP_I nform at ion_Re- sponse com m and t ransact ion is used t o request im plem ent at ion- specific inform at ion. Current ly, t he only piece of inform at ion t hat can be request ed in a st andard m anner is t he value of t he connect ionless MTU, MTU CL, t hat t he rem ot e device support s. Nonst andard, vendor- specific inform at ion could also be request ed wit h t his t ransact ion.

The Host Controller Interface (HCI) The Bluet oot h t ransport prot ocols can be im plem ent ed in an int egrat ed fashion, ent irely on t he sam e host ( m ot herboard or processor) t hat runs t he applicat ions t hat use t he t ransport prot ocols. On t he ot her hand, t hey m ay be im plem ent ed independent ly of t he host on a separat e Bluet oot h m odule t hat is t hen at t ached t o t he host as an add- on accessory at t achm ent or a plug- in card, t hrough som e physical int erface on t he host ( such as a USB port or an RS- 232 serial port ) . When im plem ent ed separat ely, t he m odule also cont ains a host cont roller unit whose responsibilit y is t o int erpret t he inform at ion received from t he host and direct it t o t he appropriat e com ponent s of t he m odule, like t he link m anger or t he link cont roller. Likewise, t he host cont roller collect s dat a and hardware/ firm ware st at us from t he m odule and passes it t o t he host as needed. I n t he reference im plem ent at ion of a Bluet oot h m odule considered by t he SI G, t he m odule cont ains t he radio, t he link cont roller, t he link m anager and host int erfaces for at t aching t he m odule t o a host , as depict ed in Figure 7.1. This reference im plem ent at ion does not preclude t he possibilit y of ot her im plem ent at ions built wit h different com ponent s of t he st ack. To perm it t he int eroperable use of nonint egrat ed m odules from different m anufact urers, t he SI G has defined a st andard int erface t o com m unicat e wit h t he m odule's host cont roller in a m anner t hat is independent of t he physical int erface and t ransport m echanism used bet ween t he host and t he host cont roller. The SI G has also defined a t ransact ion- st yle com m unicat ion prot ocol t o carry inform at ion bet ween t he host and t he host cont roller. This st andardized int erface bet ween t he host cont roller and t he host , t oget her wit h t he corresponding com m unicat ion prot ocol bet ween t hem , is collect ively referred t o as t he host cont roller int erface ( HCI ) . The HCI port ion of t he specificat ion is by far t he largest one—nearly 300 pages including t he HCI t ransport sect ions. The SI G's HCI e- m ail list is also t he m ost populat ed and busy one. This should com e as no surprise; in a sense, t he capabilit ies of t he HCI define what can be accom plished wit h t he Bluet oot h t echnology. Since HCI defines t he set of funct ions of a Bluet oot h m odule t hat are accessible t o t he host and it s applicat ions, HCI is t he gat ekeeper of t he services t hat t his m odule can provide t o it s users. Any feat ure of t he m odule t hat is not exposed ( or t hat is not exposed properly) by t he HCI lim it s t he funct ionalit y of t he m odule and ult im at ely t he pot ent ial of Bluet oot h wireless com m unicat ions.

Figu r e 7 .4 . Syst e m a r ch it e ct u r e for a de vice w it h a h ost in t e r fa ce . 93

Figure 7.4 shows a prot ocol st ack wit h an HCI . The HCI part cont ains a set of int erfaces t o t he higher layers, which t he specificat ion defines t hrough a long list of HCI _PDUs. [ 6] There is also a host driver, or HCI driver, which execut es t he com m unicat ion prot ocol for exchanging t he HCI _PDUs wit h t he host cont roller. Finally, t here is t he t ransport prot ocol t hat carries t he HCI _PDUs across t he physical int erface, or HCI t ransport . For t he HCI t ransport , t he SI G has not developed any new prot ocols; inst ead it has reused t hree exist ing ones: t he Universal Serial Bus ( USB) prot ocol, t he RS- 232 serial port prot ocol, and t he universal asynchronous receiver and t ransm it t er ( UART) prot ocol, which is a proper subset of t he RS- 232 prot ocol and can be used if t he m odule at t aches direct ly t o t he UART of a serial port wit hout t he need for serial cables. The HCI t ransport has it s own com plem ent ary driver com ponent s in bot h t he host and m odule. [6]

Once again, this is not the terminology used in the specification, but it is used here for consistency with the rest of the book.

I m plem ent at ion of t he HCI is not m andat ory and in fully int egrat ed syst em s m ay not even be necessary. However, m anufact urers of product s, bot h OEMs and com ponent int egrat ors, m ust provide an HCI - like int erface t o t est t heir product for com pliance wit h t he lower t ransport prot ocol t est specificat ion as described in t he Test Cont rol I nt erface part of t he specificat ion.

The HCI_PDU Packet Classes Three classes of HCI _PDUs are used t o exchange inform at ion bet ween t he HCI layer [ 7] in t he host and t he host cont roller in t he m odule, as shown in Figure 7.5. There are com m and- class HCI _PDUs t hat carry cont rol and m anagem ent inform at ion; t hese are sent from t he HCI layer t o t he host cont roller. There are event - class HCI _PDUs t hat carry cont rol and m anagem ent inform at ion from t he host cont roller t o t he HCI layer. Finally, t here are dat a- class HCI _PDUs t hat carry fragm ent s of L2CAP_PDUs and SCO dat a. The HCI specificat ion split s t he lat t er class int o t wo cat egories, one for asynchronous L2CAP dat a and one for synchronous dat a, but in realit y all

94

dat a- class HCI _PDUs have t he sam e num ber of fields and ident ical field delineat ion. As such, t he t wo cat egories of dat a- class HCI _PDUs are bet t er int erpret ed as t wo different m odes of t he sam e HCI _PDU class. I nform at ion in HCI _PDUs is encoded in lit t le- endian form at . The figure also includes t he physical int erface bet ween t he host and t he m odule. Based on t he t ype of t his int erface, a separat e HCI t ransport prot ocol is used. The figure indicat es t he t hree HCI t ransport s defined in t he specificat ion: RS- 232, UART and USB. [7]

We collectively refer to the HCI and the HCI protocol driver as the HCI layer.

Figu r e 7 .5 . Th e H CI _ PD U cla sse s; H C st a n ds for h ost con t r olle r .

For com plet eness, Figure 7.5 shows t he possible act ive links t hat a device m ight have. Two devices m ay have at m ost one ACL link bet ween t hem . A m ast er m ay have up t o seven act ive ACL links wit h it s slaves ( one per act ive slave) . Also, t here m ay be up t o t hree SCO links bet ween t he m ast er and all it s slaves in a piconet . Not e t hat an ACL link bet ween t wo devices m ust exist prior t o est ablishing any SCO links bet ween t hose devices. Table 7.8 shows t he st ruct ure of a com m and HCI _PDU. I t includes an OpCode field used t o ident ify t he com m and t ype. The payload sect ion of t he com m and consist s of a num ber of param et ers t hat vary by com m and t ype.

Ta ble 7 .8 . The com m a n d H CI _ PD U. fie ld

size

com m e nt s

HCI _Com m and_Header OpCode

2 byt es

OpCode group subfield ( OGF) ( 6 bit s) ident ifies t he group t hat t he OpCode belongs t o: • • •

'b111110' ident ifies a reserved OGF used for Bluet oot h logo t est ing 'b111111' ident ifies a reserved OGF for vendorspecific com m ands used during m odule m anufact ure, such as m odule debugging operat ions Ot her values indicat e ot her groups such as link cont rol link policy baseband and ot hers as described

95

Ta ble 7 .8 . The com m a n d H CI _ PD U. fie ld

size

com m e nt s below and det ailed in t he specificat ion OpCode com m and subfield ( OCF) ( 10 bit s) ident ifies a specific HCI com m and wit hin t he part icular OGF

Payload_Lengt h 1 byt e

lengt h of t he payload of t he com m and HCI _PDU in byt es

HCI _Com m and_Payload Payload

Payload_Lengt h byt es

t he payload of a com m and HCI _PDU is st ruct ured as a sequence of variable- size fields for t he various param et ers relat ed t o t his com m and

Table 7.9 shows t he st ruct ure of an event HCI _PDU. Sim ilarly t o a com m and HCI _PDU, it consist s of an Event _Code field used t o ident ify t he event and a payload sect ion wit h a num ber of param et ers which are relat ive t o t his event HCI _PDU.

Ta ble 7 .9 . Th e e ve n t H CI _ PD U. Fie ld

size

com m e nt s

HCI _Event _Header Event _Code

1 byt e

ident ifies t he event • •

Payload_Lengt h 1 byt e

'0xFE' is reserved for Bluet oot h logo specific event s '0xFF' is reserved for vendor- specific event s used during m odule m anufact uring, such as m odule t est ing and debugging operat ions

lengt h of t he payload of t he event HCI _PDU in byt es

HCI _Event _Payload Payload

Payload_Lengt h byt es

t he payload of an event HCI _PDU is st ruct ured as a sequence of variable- size fields for t he various param et ers relat ed t o t his event

A host uses t he com m and HCI _PDUs for t hings like: • • •

set t ing operat ional param et ers of t he m odule, such as providing a link key for aut hent icat ion; configuring t he m odule's operat ional st at us and relat ed param et ers, for inst ance causing it t o act ivat e and set t he relat ed param et ers for a low power m ode; reading and writ ing regist er ent ries, like t he num ber of broadcast packet repet it ions, N BC, and so on.

Depending upon t he com m and, m odule regist ers will be read or set , t he link m anager will execut e an LMP t ransact ion, t he link cont roller will change st at e and execut e, say, a page, and so on. The host cont roller not ifies t he host of t he out com e of t he com m and wit h an event HCI _PDU

96

eit her soon aft er t he com m and is sent from t he host or at a lat er t im e when appropriat e—for exam ple, following t he t erm inat ion of an LMP t ransact ion. The reason t hat host cont roller HCI _PDU t ransm issions t o t he host are called event s and not responses is t hat t he host cont roller m ay init iat e it s own request ( for inst ance, request ing a m issing link key from t he host ) or send a t ransm ission t o t he host wit hout t he host 's prior act ion ( perhaps not ifying it of a connect ion request com ing from a rem ot e device) . Act ually, som e of t he com m and HCI _PDUs sent from t he host are sim ply responses t o event HCI _PDUs t hat originat ed from t he host cont roller. For exam ple, t he HCI _Accept _Connect ion_Request com m and is sent by t he host t o t he host cont roller inst ruct ing t he lat t er t o accept an incom ing connect ion request from a rem ot e device. Before t he host t ransm it s t he HCI _Accept _Connect ion_Request com m and, t he host cont roller not ifies t he host of t he incom ing connect ion request wit h a Connect ion_Request event . Table 7.10 shows t he st ruct ure of a dat a HCI _PDU.

Ta ble 7 .1 0 . Th e da t a H CI _ PD U. fie ld

size

com m e nt s

HCI _Dat a_Header Connect ion_Handle 12 bit s

ident ifies t he baseband link over which t hese dat a are t ransm it t ed or received; connect ion handles in t he range '0xF00' t o '0xFFF' are reserved for fut ure use

Flags

ACL t ransm issions: com posed of t wo subfields:

4 bit s

•

•

Packet _Boundary_Flag: ident ifies t he beginning or cont inuat ion of an upper- layer ( L2CAP) PDU Broadcast _Flag: ident ifies t he " spread fact or" for t he ACL t ransm ission: point - t o- point , broadcast t o act ive slaves, or broadcast t o all slaves including any parked ones

SCO t ransm issions: reserved field Payload_Lengt h

2 byt es

lengt h of t he payload of t he dat a HCI _PDU in byt es

HCI _Dat a_Payload Payload

Payload_Lengt h byt es

dat a t o be carried over t he ACL or SCO baseband link ident ified by t he cont ent s of t he Connect ion_Handle field

Transm ission of dat a HCI _PDUs across t he physical int erface is regulat ed by t he buffer sizes available on t he receiving side of t he PDU. Bot h t he host and t he host cont roller inquire about t he buffer size available for receiving dat a HCI _PDUs on t he opposit e side of t he int erface and adj ust t heir t ransm issions accordingly. This im plies t hat a large L2CAP_PDU m ay need t o be fragm ent ed wit hin t he HCI layer prior t o sending it t o t he host cont roller. On t he receiving side, t he HCI layer could reconst ruct L2CAP_PDUs based on t he packet boundary flag inform at ion wit hin t he received dat a HCI _PDUs. Transm ission of HCI _PDUs across t he physical int erface is in first - in- first - out order wit hout preem pt ion. Com m ands are processed by t he host cont roller in t heir order of arrival, but t hey m ay com plet e out of order since each m ight t ake a different am ount of t im e t o execut e. Sim ilarly, event s are processed by t he host in order of arrival, but t heir processing m ay t erm inat e out of order.

97

Not e t hat none of t he fields in any of t he HCI _PDUs ident ifies t he HCI _PDU class: com m and, event or dat a. I dent ificat ion of t he HCI _PDU class is left t o t he HCI t ransport prot ocol t hat act ually carries t he PDUs bet ween t he host and t he host cont roller. St rict ly speaking, t his is a violat ion of prot ocol layering. However, it allows t he HCI t o t ake advant age of t he capabilit ies of t he underlying t ransport prot ocol, which m ay provide it s own m eans for dist inguishing t he t hree HCI _PDU classes wit h m inim al overhead. Purist s m ay wish t o consider t hat t he HCI layer in t he host and it s com plem ent ary part in t he host cont roller consist of a t ransport - independent sublayer, and a t ransport dependent convergence sublayer ( which execut es t he HCI t ransport prot ocol) t hat adapt s t he HCI _PDUs t o t he part icular t ransport m et hod used t o carry t hem across t he physical int erface.

The HCI_PDUs There are m any com m and HCI _PDUs organized int o several groups ident ified by t he OGF subfield in t he header of t he com m and HCI _PDU. For m any of t hese com m and HCI _PDUs t here exist s a corresponding event HCI _PDU t hat carries t he out com e and ret urn param et ers relat ed t o t he com m and. For several com m ands, inform at ion relat ed t o t heir st at us and execut ion result s is carried by t wo special event s: Com m and_St at us_Event and Com m and_Com plet e_Event . The form er t ypically is sent im m ediat ely aft er a com m and is received by t he host cont roller t o indicat e t he st at us of t he com m and, such as com m and pending execut ion, com m and not underst ood, and so on. This provides a sort of acknowledgem ent of t he com m and along wit h an indicat ion of it s processing st at us. The lat t er is used t o indicat e t he com plet ion of execut ion of a com m and and t o ret urn relat ed param et ers, including whet her or not t he request ed com m and was execut ed successfully. Observe t hat m ult iple event s m ight be generat ed in response t o a single com m and. There are com m and HCI _PDUs relat ed t o link cont roller act ions, policy- set t ing com m ands, t he host cont roller it self, and m any ot hers. Com m and and event HCI _PDUs num ber over 100; som e of t hese are highlight ed in t he following sect ions. These select ed HCI _PDUs are illust rat ive of t he t ype of inform at ion and t he level of det ail t hat is com m unicat ed bet ween t he host and t he host cont roller. For t he full set of HCI _PDUs, refer t o t he specificat ion. Link Control HCI_PDUs The com m ands in t his group are ident ified via t he OGF subfield wit h t he value 'b000001'. This group cont ains com m ands t hat allow inquiries t o be sent t o discover ot her devices in t he vicinit y. There are com m ands t o creat e and t erm inat e ACL and SCO connect ions and t o accept or rej ect incom ing connect ion request s. There are com m ands for init iat ing aut hent icat ion and encrypt ion procedures as well as for t ransport ing aut hent icat ion keys and PI Ns from t he host t o t he link cont roller. There are inform at ion com m ands in t his group t o request t he user- friendly nam e of t he rem ot e device, t he link m anager opt ions t hat it support s and t he clock offset regist ered in t he rem ot e device. Following are som e exam ples of HCI _PDUs in t his group. The HCI _I nquiry com m and PDU inst ruct s t he m odule t o ent er t he inquiry m ode, using a given inquiry access code, for a specified am ount of t im e or unt il a specified num ber of responses is collect ed. This com m and is sum m arized in Table 7.11.

Ta ble 7 .1 1 . Th e H CI _ I n quir y com m a n d H CI _ PD U. Com m a nd_ N a m e

H CI _ I n qu ir y

OCF

'b0000000001'

Param et ers

LAP

3 byt es

lower address part used for generat ing t he inquiry access code

98

Ta ble 7 .1 1 . Th e H CI _ I n quir y com m a n d H CI _ PD U. Com m a nd_ N a m e

H CI _ I n qu ir y I nquiry_Lengt h

1 byt e indicat es t he m axim um durat ion for t his inquiry: 1.28 sec - 61.44 sec

Num _Responses 1 byt e indicat es t he m axim um num ber of responses t o be collect ed The inquiry m ode originat ed by t his com m and t erm inat es eit her when I nquiry_Lengt h t im e has elapsed or when t he num ber of responding devices reaches Num _Responses, whichever occurs first . The host cont roller ret urns inform at ion collect ed from inquiries t o t he host wit h t he I nquiry_Result _Event [ 8] sum m arized in Table 7.12; t he param et ers of t he event are derived from t he FHS BB_PDUs ( det ailed in t he previous chapt er) t hat are received from t he devices responding t o t he inquiries. A brief descript ion of t he param et ers below is given in Table 7.13, which present s t he com m and t hat uses t hese param et ers. [8] This event is actually called "Inquiry Result" event. Once again we take liberty in the naming convention for consistency purposes with other PDUs.

Ta ble 7 .1 2 . Th e I n qu ir y_ Re su lt _ Eve n t e ve n t H CI _ PD U; t h e in de x i ide n t ifie s e a ch of t h e N u m _ Re spon se s r e spon din g de vice s. Event _Nam e

I nquiry_Result _Event

Event _Code

'0x02'

Param et ers

Num _Responses

1 byt e

BD_ADDR[ i]

6* Num _Responses byt es

Page_Scan_Repet it ion_Mode [ i]

1* Num _Responses byt e( s)

Page_Scan_Period_Mode[ i]

1* Num _Responses byt e( s)

Page_Scan_Mode[ i]

1* Num _Responses byt e( s)

Class_of_Device[ i]

3* Num _Responses byt es

Clock_Offset [ i]

2* Num _Responses byt es

The HCI _Creat e_Connect ion com m and PDU inst ruct s t he m odule t o creat e a connect ion wit h a specified device, using a given set of BB_PDU t ypes for t he ACL link. Since t he connect ion process requires t hat t he " local" device page t he " rem ot e" device, t his com m and also provides inform at ion used t o accelerat e t he paging process. The paging inform at ion becom es available t o t he host of a local device via an earlier I nquiry_Result _Event PDU, shown in Table 7.12. The HCI _Creat e_Connect ion com m and is sum m arized in Table 7.13.

Ta ble 7 .1 3 . Th e H CI _ Cr e a t e _ Con n e ct ion com m a n d H CI _ PD U. Com m and_Nam e HCI _Creat e_Connect ion OCF

'b0000000101'

99

Ta ble 7 .1 3 . Th e H CI _ Cr e a t e _ Con n e ct ion com m a n d H CI _ PD U. Com m and_Nam e HCI _Creat e_Connect ion Param et ers

[1]

BD_ADDR

6 ident ifies t he rem ot e device wit h which t o byt es est ablish a connect ion

Packet _Type

2 indicat es which BB_PDU t ypes can be byt es used by t he link m anager for t he ACL link

Page_Scan_Repet it ion_Mode 1 byt e

indicat es t he page scan repet it ion m ode, t hat is, how frequent ly t he rem ot e device ent ers t he page scan m ode, last report ed by t he rem ot e device

Page_Scan_Mode

1 byt e

indicat es t he page scan m ode support ed by t he device

Clock_Offset

2 indicat es t he difference bet ween t he byt es slave and m ast er clocks, as calculat ed in t he last com m unicat ion bet ween t hem

Allow_Role_Swit ch

1 byt e

indicat es whet her t his ( t he paging) device will be t he m ast er or will allow t he paged device t o becom e t he m ast er if request ed [ 1]

Master-slave role switching is described in the previous chapter.

Upon successful creat ion of t he connect ion, a Connect ion_Com plet e_Event is sent t o t he host s on bot h sides of t he connect ion. The event s cont ain t he Connect ion_Handles for ident ifying t he connect ion. The connect ion handles are assigned by each host cont roller independent ly and t heir scope is lim it ed t o t he local device only. Link Policy HCI_PDUs The com m ands in t his group are ident ified via t he OGF subfield wit h t he value ` b000010'. This group cont ains com m ands t hat allow a device t o set a power- m anagem ent policy t hrough t he hold, sniff, and park baseband m odes and t o define t he param et ers for t hose m odes. Also, t here are com m ands t hat pass QoS param et ers from t he L2CAP layer t o t he link m anager, learn about t he role ( m ast er or slave) t hat t he device[ 9] plays for a part icular connect ion and request a role swit ch if needed. [9] Recall that information regarding the role that a device plays in a particular connection does not propagate through the stack beyond the link manager layer. A host needs to explicitly request this information from the host controller.

Table 7.14 sum m arizes t he HCI _PDU com m and t hat request s t he host cont roller t o inst ruct t he link m anager and t he baseband t o ent er hold m ode wit h t he param et ers provided. Sim ilar com m ands exist for sniff and park m odes.

Ta ble 7 .1 4 . Th e H CI _ H old_ M ode com m a nd PD U. Com m a nd_ N a m e

H CI _ H old_ M ode

OCF

'b0000000001'

Param et ers

Connect ion_Handle

2 byt es

ident ifies t he connect ion ( act ually t he ACL link) t o be placed in hold m ode; only t he

100

Ta ble 7 .1 4 . Th e H CI _ H old_ M ode com m a nd PD U. Com m a nd_ N a m e

H CI _ H old_ M ode 12 LSBs are used Hold_Mode_Max_I nt erval 2 byt es

indicat es t he m axim um negot iable hold int erval ( 0.625 m sec – 40.9 sec)

Hold_Mode_Min_I nt erval

indicat es t he m inim um negot iable hold int erval ( 0.625 m sec – 40.9 sec)

2 byt es

The host cont roller not ifies t he host when hold m ode is ent ered or is t erm inat ed using t he Mode_Change_Event . Host Controller and Baseband HCI_PDUs The com m ands in t his group are ident ified via t he OGF subfield wit h t he value 'b000011'. This group cont ains com m ands t hat allow t he host t o access and configure various hardware regist ers t hat m aint ain operat ional param et ers. Am ong t he operat ions t hat can be perform ed are det erm ining t he t ypes of event s t hat t he host cont roller can generat e; reading, writ ing, and delet ing st ored keys; reading and writ ing t he user- friendly device nam e; act ivat ing and deact ivat ing inquiry and/ or page scans; reading and writ ing t he aut hent icat ion and/ or encrypt ion act ivit y flag for a link; reading and writ ing t he inquiry access codes used t o list en during inquiry scans; forcing t he flushing of ACL packet s for a connect ion handle; reading and writ ing t he audio codec param et ers and so on. Table 7.15 sum m arizes t he HCI _PDU com m and t hat set s t he inquiry scan param et ers; a sim ilar com m and exist s for page scans as well. I nquiry scans occur only when t he host has already sent an HCI _Writ e_Scan_Enable com m and PDU t o enable inquiry scans.

Ta ble 7 .1 5 . Th e H CI _ W r it e _ Pa ge _ Sca n _ Act ivit y com m a n d PD U. Com m a nd_ N a m e

H CI _ W r it e _ I n qu ir y_ Sca n_ Act ivit y

OCF

'b0000011100'

Param et ers

I nquiry_Scan_I nt erval 2 byt es

det erm ines t he int erval bet ween successive st art s of inquiry scans11.25 m sec – 2.56 sec ( t ypically, 1.28 sec)

I nquiry_Scan_Window 2 byt es

det erm ines t he durat ion of a single cont inuous scan operat ion11.25 m sec – 2.56 sec ( t ypically, 11.25 m sec)

When t he host cont roller finishes updat ing t he relat ed regist ers it ret urns a Com m and_Com plet e_Event t o t he host . Informational Parameters HCI_PDUs The com m ands in t his group are ident ified via t he OGF subfield wit h t he value 'b000100'. This group includes com m ands t hat request st at ic inform at ion about t he hardware and firm ware t hat is elect ronically " engraved" on t he device at m anufact ure t im e. There is a com m and t o request t he version of t he various prot ocols ( LMP, HCI , and so on) t hat t he m odule support s; a com m and t o request a list of feat ures support ed by t he link m anager; a com m and t o request t he count ry of operat ion of t he m odule; a com m and t o request t he BD_ADDR of t he m odule; [ 10] and a com m and

101

t o request t he host cont roller buffer inform at ion for ACL and SCO packet s, used t o execut e effect ive flow cont rol at t he host . The request ed inform at ion is ret urned in a Com m and_Com plet e_Event . [10]

Recall that the BD_ADDR is hardwired and cannot be modified.

Status Parameters HCI_PDUs The com m ands in t his group are ident ified via t he OGF subfield wit h t he value 'b000101'. This group includes com m ands t hat request inform at ion t hat is dynam ically updat ed, like t he value of t he cont act count er t hat m easures t he num ber of successive inst ant s during which t he rem ot e device does not respond t o local t ransm issions, causing t he local link m anager t o flush any PDUs wait ing t o be t ransm it t ed. There is also a com m and HCI _PDU t o ret rieve inform at ion relat ed t o t he qualit y of t he link and t he RSSI ( received signal st rengt h indicat or) value. The request ed inform at ion is ret urned in a Com m and_Com plet e_Event . Testing HCI_PDUs The com m ands in t his group are ident ified via t he OGF subfield wit h t he value 'b000110'. These com m ands, which all result in Com m and_Com plet e_Event event s, are used for t est ing t he Bluet oot h m odule and are not discussed furt her here.

Summary I n t his chapt er we have highlight ed t he upper t wo Bluet oot h t ransport prot ocols: L2CAP and HCI . The lat t er is a t ransport prot ocol int ernal t o a device, rat her t han an over- t he- air prot ocol as are L2CAP and t he ot her prot ocols discussed in Part 2 of t he book. The prim ary purposes of t hese prot ocols are bot h t o hide, in t he case of L2CAP, and t o expose, in t he case of HCI , t he int ernal operat ion of t he lower t ransport prot ocols. L2CAP is used t o m ult iplex and t ransport higher prot ocol layers while shielding t hem from t he peculiarit ies of t he lower t ransport prot ocols, like t he baseband. The HCI provides a st andardized int erface t o t he services and capabilit ies provided by t he lower t ransport prot ocols. I n t his and t he previous chapt ers we have present ed t he prot ocols t hat t he SI G has developed for t ransport ing dat a across Bluet oot h devices. These prot ocols have been developed ent irely by t he SI G specifically for Bluet oot h wireless com m unicat ion. They reflect t he SI G's obj ect ives t o develop sim ple, cost - effect ive com m unicat ion syst em s t hat can operat e at low power in noisesuscept ible places. I n t he next chapt er we int roduce t he m iddleware prot ocols t hat are used t o t ake advant age of t he dat a- t ransport services of t he t ransport prot ocols t o enable a plet hora of applicat ions, including legacy applicat ions, t o operat e sm oot hly over Bluet oot h links.

102

Chapter 8. The RFCOMM and SDP Middleware Protocols We now m ove from t he t ransport prot ocol layers t o a det ailed discussion of t he m iddleware prot ocols. I n t his chapt er we discuss RFCOMM, t he Bluet oot h serial port em ulat ion prot ocol, and t he Bluet oot h Service Discovery Prot ocol, or SDP. Version 1.0 of t he core specificat ion ( volum e 1) devot es nearly 90 pages t o t hese t wo prot ocols. As wit h t he ot her det ailed discussions of port ions of t he specificat ion, t his chapt er at t em pt s t o reveal t he m ot ivat ion and t hought process behind t he developm ent of t hese prot ocols. While t he im port ant elem ent s of RFCOMM and SDP are exam ined here, t his m at erial focuses on t he design basis for t he prot ocols and t hus is not a subst it ut e for t he specificat ion it self. Bot h RFCOMM and SDP reside direct ly above t he L2CAP layer ( discussed in t he previous chapt er) and use L2CAP connect ions t o accom plish t heir respect ive funct ions. Bot h of t hese prot ocols provide a prot ocol dat a unit ( PDU) st ruct ure for use by higher layers ( eit her applicat ions or ot her m iddleware prot ocols) in t he st ack. PDUs allow t he higher layers of t he st ack t o work wit h logical dat a elem ent s at a higher level of abst ract ion t han t hat of t he packet form at used by t he t ransport prot ocols. Bot h RFCOMM and SDP are prot ocols developed specifically for use wit h Bluet oot h wireless com m unicat ions, alt hough RFCOMM borrows heavily from an exist ing st andard. Figure 8.1 illust rat es t he posit ion of RFCOMM and SDP in t he prot ocol st ack. As shown in t he figure, RFCOMM is used by higher layer m iddleware prot ocols and by applicat ions for net working, I rDA int eroperabilit y and t elephony. These sam e applicat ions m ay com m unicat e direct ly wit h RFCOMM as well as wit h t heir associat ed m iddleware prot ocols t hat in t urn com m unicat e wit h RFCOMM. Since service discovery is fundam ent al t o all Bluet oot h profiles, m ost applicat ions will also com m unicat e wit h t he SDP layer.

Figu r e 8 .1 . RFCOM M a n d SD P in t he Blu e t oot h pr ot ocol st a ck .

103

The RFCOMM Protocol Serial int erfaces are ubiquit ous in com put ing and t elecom m unicat ions devices, part icularly t hose devices wit h a high affinit y for Bluet oot h com m unicat ions. Not ebook com put ers have serial port s, personal digit al assist ant s t ypically have serial port s ( oft en used t o synchronize t he PDA wit h som e ot her device) , m any m obile t elephones have serial port s ( oft en used for a wired headset ) , m any digit al cam eras use serial port s t o t ransfer im age dat a t o anot her device, print ers and ot her com put er peripherals oft en use serial port s for com m unicat ion, and so on. Moreover, infrared com m unicat ion, which as previously est ablished has som e t rait s in com m on wit h Bluet oot h wireless com m unicat ion, norm ally uses a serial port t o com m unicat e wit h t he I R t ransceiver. [ 1] [1] In the PC domain, infrared communications are frequently tied to a COM port resource. In commonly used PC operating environments, these COM ports classically have been difficult to configure, especially for infrared communications. This drawback has led to a situation where, while many infrared ports are deployed in products, only a fraction of these ports are actually used, since many users lack the expertise or motivation to perform the necessary configuration process. The rise of infrared ports on PDAs and mobile phones, where the configuration process is much easier, seems to lead to a higher usage rate of infrared in peer-to-peer communications.

Because Bluet oot h t echnology aim s t o replace cables, it seem s clear t hat t here is a large opport unit y t o replace serial cables. To do t his effect ively, t he st ack needs t o support serial com m unicat ion in t he sam e m anner as is done wit h cables, so t hat applicat ions are present ed wit h a fam iliar serial int erface. This perm it s t he cornucopia of legacy applicat ions t hat are unaware of t he Bluet oot h t echnology t o operat e seam lessly over Bluet oot h links. Furt herm ore, applicat ion soft ware developers skilled in developing serial com m unicat ion applicat ions m ay st ill cont inue t o do so, assured t hat t heir applicat ions will operat e over Bluet oot h links. But t he t ransport - layer prot ocols are not m odeled aft er a serial port . L2CAP support s packet dat a st ruct ures, and while t he air- int erface m ay t ransm it bit pat t erns in a serial fashion, t his is not t he sam e as t he com m on RS- 232 t ypes of serial int erfaces used t oday wit h serial cables. Thus t he SI G has chosen t o define a layer in t he prot ocol st ack t hat looks very m uch like a t ypical serial int erface: t he RFCOMM layer. I n t he world of personal com put ers, serial int erfaces are oft en called COM port s. The nam e RFCOMM connot es a wireless ( RF) inst ance of a virt ual COM port . RFCOMM prim arily is int ended t o enable cable- replacem ent scenarios for exist ing applicat ions.

RFCOMM Protocol Development The m ot ivat ion for t he RFCOMM prot ocol layer is root ed in t he requirem ent t o support legacy applicat ions wit h init ial Bluet oot h im plem ent at ions. The need for t his serial com m unicat ion funct ion in t he soft ware st ack was ident ified quit e early in t he SI G's form at ion. Just one m ont h aft er t he SI G was publicly announced, discussions ensued on developing t he specificat ion for t he RFCOMM layer. At t hat t im e, t he ETSI TS 07.10 st andard [ ETSI 99] had already been ident ified as a candidat e for a basis upon which t o build Bluet oot h serial com m unicat ions. Requirem ent s for Bluet oot h serial com m unicat ions include: M u lt iple x e d se r ia l com m u n ica t ion s: There m ay be m any sim ult aneous client s of t he serial int erface in t he st ack, including I rOBEX, t elephony cont rol and net working client s. Thus t he serial port needs t o be shareable t hrough m ult iplexed connect ions ( which in t urn m ight be support ed by t he prot ocol m ult iplexing in t he L2CAP layer, over which dist inct RFCOMM ent it ies in different devices com m unicat e) . RS- 2 3 2 sign a l com pa t ibilit y: RS- 232 is a widely used serial int erface for t he cables wit h which Bluet oot h wireless com m unicat ion needs t o be com pat ible. Many applicat ions are fam iliar wit h RS- 232 int erfaces, including t he various cont rol signals associat ed wit h RS- 232; t hese include com m on signals such as Request t o Send/ Clear t o Send ( RTS/ CTS) , Dat a Term inal Ready/ Dat a

104

Set Ready ( DTR/ DSR) , t he RS- 232 break fram e and ot hers. Em ulat ing t hese signals allows RFCOMM t o present t o it s client s t he appearance of a serial port t hat is virt ually t he sam e as t hat used wit h a serial cable. Re m ot e st a t u s a nd con figu r a t ion : I n a peer- t o- peer environm ent , t he t wo part ies com m unicat ing over t he serial link oft en need t o det erm ine t he st at us and configurat ion of t he rem ot e serial int erface so t hat t he local serial int erface can be configured in a com pat ible m anner. The service discovery prot ocol, discussed in following sect ions, can be used t o obt ain basic inform at ion needed t o est ablish a serial com m unicat ions channel; following connect ion est ablishm ent t he t wo ends of t he serial int erface need t o be able t o negot iat e com pat ible serial com m unicat ion set t ings for t he connect ion. I n t e r na l a n d e x t e r na l se r ia l por t : To support t he various uses of serial com m unicat ions in Bluet oot h applicat ions, RFCOMM needs t o support bot h an int ernal em ulat ed serial port , in which t he serial port param et ers are used only locally ( t he param et ers do not apply across t he airint erface) as well as an ext ernal serial port , where t he serial port param et ers and st at us are t ransm it t ed across t he RF link along wit h t he dat a and m ay be used by t he receiving serial port . These requirem ent s are not unique t o Bluet oot h environm ent s, and t he SI G realized t hat t he aforem ent ioned ETSI TS 07.10 st andard was a good m at ch for t he needs of Bluet oot h serial com m unicat ions, so t he SI G adopt ed m uch of t hat st andard. However, TS 07.10 is not a perfect m at ch for use in t he Bluet oot h prot ocol st ack, so t he SI G added som e of it s own m odificat ions t o adapt t he ETSI st andard for use in Bluet oot h wireless com m unicat ions. Am ong t hese addit ions and changes are: D a t a fr a m e a da pt a t ion s: Since Bluet oot h com m unicat ion has an underlying packet st ruct ure by virt ue of t he use of L2CAP, som e of t he dat a fram e cont ent s specified by TS 07.10 are unnecessary for RFCOMM. For exam ple, t he fram e delim it er flags specified in TS 07.10 are discarded for t he RFCOMM specificat ion. Conn e ct ion e st a blishm e n t a nd t e r m ina t ion: Again, because Bluet oot h com m unicat ion has it s own connect ion m anagem ent in t he t ransport prot ocol layers t hat RFCOMM uses, t he connect ion m anagem ent funct ions of TS 07.10 are superfluous for RFCOMM. The specificat ion det ails how RFCOMM links are m anaged. M u lt iple x in g: RFCOMM uses a subset of t he m ult iplex channels specified for TS 07.10 and specifies t he way in which som e TS 07.10 m ult iplexing cont rol com m ands are used in RFCOMM. Applica bilit y: The RFCOMM specificat ion m andat es support of several feat ures which are opt ional in t he TS 07.10 st andard. These feat ures deal wit h exchanging inform at ion about t he configurat ion and st at us of t he serial connect ion and include negot iat ing t he serial port and individual channel set t ings and ret rieving t he serial port st at us. I n Bluet oot h environm ent s t hese funct ions are quit e useful and in fact can be considered necessary for effect ive use of t he airint erface; t hus t hey are specified as m andat ory t o support in RFCOMM. Flow con t r ol: Typical serial port s pace t he dat a t ransfer using XON/ XOFF pacing or DTR signal pacing. For RFCOMM, t he specificat ion describes flow cont rol m echanism s specific t o t he Bluet oot h prot ocol st ack, including flow cont rol t hat applies t o all m ult iplexed RFCOMM channels as well as per- channel pacing. The rem aining RFCOMM sect ions in t his chapt er review key point s of t he RFCOMM specificat ion, in m any cases highlight ing t he significance of t he design choices for t his prot ocol layer.

The RFCOMM Protocol Examined 105

The relat ively few pages[ 2] devot ed t o RFCOMM in t he specificat ion belie it s im port ance in t he version 1.0 prot ocol st ack. RFCOMM is t he basis for m ost of t he version 1.0 profiles and m ight also be used in som e fut ure profiles, alt hough it s prim ary purpose is t o enable support for legacy applicat ions in sim ple cable- replacem ent scenarios. [ 3] The m ain reason t hat RFCOMM does not require m any dozens of pages of explanat ion is t he SI G's decision t o adopt m uch of t he ETSI TS 07.10 prot ocol ( which it self is over 50 pages of specificat ion) . By specifying TS 07.10 as t he basis for RFCOMM, t he SI G has adopt ed a m at ure st andard prot ocol and t he specificat ion needs t o describe only t he adapt at ion of t his st andard for Bluet oot h environm ent s. Much of t he RFCOMM chapt er of t he specificat ion focuses on describing which part s of TS 07.10 are relevant for RFCOMM, how t hose feat ures are used and t he m odificat ions necessary t o m ap TS 07.10 int o t he Bluet oot h prot ocol st ack. [2] Only about 25 pages, making the RFCOMM portion of the specification a good candidate for beginning-to-end reading for those interested in fully understanding this key layer of the stack.

[3] RFCOMM might become less significant in future usage models as the specification evolves to support general TCP/IP networking. In the meantime, the SIG specified RFCOMM as a solution for serial-cable-replacement usage models.

RFCOMM uses an L2CAP connect ion t o inst ant iat e a logical serial link bet ween t wo devices. I n part icular, an L2CAP connect ion- orient ed channel is est ablished t hat connect s t he t wo RFCOMM ent it ies in t he t wo devices. Only a single RFCOMM connect ion is perm it t ed bet ween t wo devices at a given t im e, but t hat connect ion m ay be m ult iplexed so t hat t here can be m ult iple logical serial links bet ween t he devices. [ 4] The first RFCOMM client est ablishes t he RFCOMM connect ion over L2CAP; addit ional users of t he exist ing connect ion can use t he m ult iplexing capabilit ies of RFCOMM t o est ablish new channels over t he exist ing link; and t he last user t o drop t he final RFCOMM serial link should t erm inat e t he RFCOMM connect ion ( and hence t he underlying L2CAP connect ion) . Each m ult iplexed link is ident ified by a num ber called a Dat a Link Connect ion I dent ifier, or DLCI . Figure 8.2 depict s m ult iplexed serial com m unicat ions links using RFCOMM over L2CAP. I n t he illust rat ion t he various client s of RFCOMM each see t heir own em ulat ed serial port , dist inguished by a DLCI value ( depict ed by t he different line t ypes in t he figure) . These separat e channels are t hen m ult iplexed over t he RFCOMM link, which in t urn is carried over an L2CAP connect ion. [4] Multiple links might be attained either through multiple instances of a single-channel RFCOMM or through a single instance of a multiple-channel RFCOMM (the latter being what the Bluetooth specification defines). While these might be logically equivalent, they are likely to result in real differences in implementations. The RFCOMM specification indicates that a client which requires a serial connection should first check for an already existing RFCOMM connection to the target device; if an RFCOMM connection to that device already exists, the client should just establish a new channel on that existing connection.

Figu r e 8 .2 . M u lt iple x e d RFCOM M logica l se r ia l lin k s ( in dica t e d by diffe r e n t lin e t ype s) ove r a sin gle RFCOM M con n e ct ion , in t u r n ove r a n L2 CAP con n e ct ion .

106

The specificat ion allows for up t o 60 m ult iplexed logical serial links over a single RFCOMM connect ion but does not m andat e t his level of m ult iplexing for RFCOMM im plem ent at ions. I n fact for m ost port able devices it is uncom m on t o have cases in which dozens of sim ult aneous serial links would be required in Bluet oot h environm ent s. Most devices are expect ed t o support a fixed num ber of profiles, which will be a det erm ining fact or in how t he prot ocol st ack for t hose devices is im plem ent ed, including design t radeoffs such as t he num ber of RFCOMM serial links support ed. But consider also devices such as net work access point s t hat allow port able devices t o use Bluet oot h wireless com m unicat ion t o access larger net works ( such as t he I nt ernet ) . The LAN Access profile ( discussed in Chapt er 15) specifies t he use of PPP over RFCOMM, so a LAN access point device m ight indeed need m any sim ult aneous serial connect ions t o m ult iple devices. The RFCOMM specificat ion support s t his sort of usage by allowing m ore t han one m ult iplexer session ( t hat is, m ore t han one inst ance of RFCOMM, in which case t he m ult iplexing is achieved by using L2CAP's m ult iplexing capabilit ies) , alt hough such a capabilit y is not m andat ed. The RFCOMM chapt er of t he specificat ion includes a discussion of t wo different sort s of devices t hat RFCOMM support s: com m unicat ion endpoint ( com put er- or peripheral- st yle devices) and com m unicat ion m idpoint ( m odem - st yle devices) . I n general serial com m unicat ions, t hese are oft en referred t o as dat a t erm inal equipm ent ( DTE) and dat a com m unicat ions equipm ent ( DCE) , respect ively. Aft er m aking t his dist inct ion, t hough, t he discussion concludes by st at ing t hat RFCOMM does not dist inguish bet ween t hese device t ypes at all. I n fact , it is not necessary for RFCOMM t o do so; m uch as a st andard serial cable can be configured for a direct serial connect ion or for null m odem operat ion, RFCOMM also can be used in bot h m anners. RFCOMM has included feat ures t o support DCE ( m odem - st yle) com m unicat ions; t hese feat ures m ay not be applicable for DTE com m unicat ions. RFCOMM support s bot h device st yles wit hout needing t o dist inguish bet ween t hem . Typical cabled serial connect ions have a num ber of signals in t he cable ( usually nine for RS- 232 com m unicat ions, alt hough all nine signals are not necessarily used in all applicat ions) . Bluet oot h wireless com m unicat ion obviously has no such signals because t he t ransm ission m edium is t he air- int erface rat her t han a cable. I n a m ult iplexed environm ent such as is defined by TS 07.10, it is desirable t hat each serial channel be viewed as an independent ent it y, wit h it s own set of cont rol and dat a signals. So even in a cabled environm ent som e schem e is needed for m ult iplexing t he serial signals. TS 07.10, and t hus RFCOMM, do t his by defining a specified cont rol channel across which inform at ion is t ransm it t ed as dat a. That is t o say, rat her t han set t ing and m onit oring signal levels as is done wit h a st andard RS- 232 int erface, RFCOMM uses com m ands and responses t o com m unicat e t he st at e of t he m ult iplexed serial int erface ( t hus virt ualizing t he RS- 232 signals) .

107

RS- 232 defines ot her st at es t hat are not direct ly represent ed by signals. Not able am ong t hese is t he baud rat e, or t he clock frequency used t o t ransm it and receive dat a. I n st andard cabled serial com m unicat ions, a clock governs t he t im e associat ed wit h t he signal t ransit ion t o and from low and high levels, which define t he 0/ 1 bit pat t erns. Obviously bot h sides of t he int erface m ust use t he sam e clock frequency, or baud rat e, t o correct ly int erpret t he dat a t hat is t ransm it t ed across t he wire. For wireless environm ent s, however, t here is no cable and t hus no signal wire t o pulse at a specified frequency. Clearly, t hough, Bluet oot h wireless com m unicat ion does em ploy clock t im ings t o com m unicat e over t he air- int erface at t he baseband level. Since RFCOMM operat es over t he t ransport layers of t he prot ocol st ack, it m akes use of t he packet st ruct ure and t ransm ission m edium used by t hose lower layers. The baud rat e of Bluet oot h wireless com m unicat ion is det erm ined by t he packet t ypes and st ruct ures being sent over t he airint erface. The act ual com m unicat ion will occur at t he rat e det erm ined by t he baseband prot ocol, regardless of what baud rat e m ight be specified at t he RFCOMM layer for serial port em ulat ion. So while an applicat ion or ot her client of RFCOMM can specify a baud rat e ( t his would be a t ypical act ion, especially for legacy applicat ions, and RFCOMM allows it ) , t he specified baud rat e does not det erm ine t he act ual dat a rat e. I n m any cases, t he dat a t ransm ission rat e using Bluet oot h wireless com m unicat ion could be fast er t han for t ypical cabled com m unicat ions.

RFCOMM Protocol Usage Curiously, t he RFCOMM chapt er of t he core specificat ion ( volum e 1) includes a sect ion cont aining t he sort of inform at ion ( applicat ion considerat ions, int eract ions wit h ot her prot ocol st ack layers and SDP service record dat a) t hat is usually found in t he profile specificat ions ( volum e 2) . This is an art ifact of t he developm ent of t he RFCOMM specificat ion. As previously not ed, RFCOMM specificat ion developm ent was underway alm ost from t he beginning of t he SI G's form at ion. Along wit h t he lower- layer t ransport prot ocols, which consum ed m uch of t he SI G's at t ent ion at first , RFCOMM was one of t he first prot ocols t o reach a st able specificat ion level ( t his is due part ly t o t he fact t hat RFCOMM leverages t he TS 07.10 st andard and part ly t o t he hard work applied t o t he RFCOMM specificat ion by it s owners in t he SI G, since t he SI G recognized t hat RFCOMM was a key elem ent of t he version 1.0 prot ocol st ack and a foundat ion upon which ot her prot ocol layers and profiles were t o be built ) . Most of t he profiles were developed aft er t he core specificat ion was st able. The forward- looking aut hors of t he RFCOMM port ion of t he specificat ion had already included som e of t he inform at ion t hat subsequent ly becam e part of t he serial port profile ( covered in Chapt er 14) . So t he RFCOMM chapt er of t he specificat ion gives som e hint s on using t his layer of t he prot ocol st ack. The specificat ion t alks about Port Em ulat ion and Port Proxy ent it ies, t he form er m apping plat form API s t o RFCOMM funct ions and t he lat t er m apping RFCOMM t o a " real" RS- 232 ext ernal int erface. The point , t hough, is t hat t he aut hors of t he RFCOMM specificat ion not only have specified a prot ocol t hat is necessary for m any legacy applicat ions t o m ake use of Bluet oot h wireless com m unicat ions but also have offered a few considerat ions for t he applicat ions t hat use t hat prot ocol. I n fact t he program m ing m odel suggest ed in RFCOMM is a specific inst ance of t he generalized m odel suggest ed in t he sect ion ent it led " The Applicat ion Group" in Chapt er 5 ( refer back t o Figure 5.4) . I n t his case we suggest a t hin layer of Bluet oot h adapt at ion soft ware for legacy applicat ions t hat m aps plat form API s t o specific funct ions of t he Bluet oot h prot ocol st ack. I n t he case of RFCOMM, which provides an em ulat ed serial port , t his adapt at ion soft ware ( which t he specificat ion calls a port em ulat ion ent it y) needs t o m ap t he applicat ion's int eract ions wit h a " real" RS- 232 serial port t o t he equivalent operat ions for t he RFCOMM em ulat ed serial port . For t he m ost part t hese are expect ed t o be init ializat ion operat ions such as act ivat ing and configuring t he serial port and est ablishing a serial connect ion; and finalizat ion operat ions such as t erm inat ing t he serial connect ion. Once a general serial port adapt at ion layer is in place in a syst em , all t hose legacy applicat ions t hat use serial com m unicat ion ought t o be enabled t o use Bluet oot h t ransport s via t he RFCOMM em ulat ed serial port .

108

As point ed out earlier, t he use of serial port s is prevalent in devices and environm ent s where Bluet oot h wireless com m unicat ion is likely t o be used, and t he m aj orit y of t he version 1.0 profiles depend upon serial port com m unicat ions. I n t he absence of a version 1.0 specificat ion for general net working, t he RFCOMM prot ocol provides an im port ant ut ilit y for legacy applicat ions. The im plem ent at ion of t his prot ocol, along wit h adapt at ion soft ware for legacy applicat ions t hat use serial com m unicat ions, perm it s m any sim ple cable replacem ent applicat ions of Bluet oot h wireless com m unicat ion.

The Service Discovery Protocol (SDP) Service discovery is a process by which devices and services in net works can locat e, gat her inform at ion about and ult im at ely m ake use of ot her services in t he net work. I n t radit ional net works such as LANs, t hese services m ight be st at ically configured and m anaged by a net work adm inist rat or. I n t hese environm ent s, t he adm inist rat or or end user perform s t he configurat ion t hat is necessary for one part icipant in t he net work t o use t he services of som e ot her net work m em ber. For exam ple, a PC user m ight specify all of t he inform at ion associat ed wit h a net work em ail service ( including t he m ail server nam e, user and account nam es, e- m ail t ype, capabilit ies and opt ions, and so on) t o t he PC's operat ing syst em and applicat ions; once all t his inform at ion is ent ered int o t he PC and associat ed wit h t hat e- m ail service, t hen t he e- m ail service becom es available t o t he PC user. Adm inist ered net work services of t his sort m ay be fine for m any fixed net works but are really not suit able for t em porary m obile net works ( ad hoc net works) such as t hose t hat m ight be form ed using Bluet oot h wireless com m unicat ion. I n t hese environm ent s a m ore dynam ic, flexible and adapt ive solut ion is needed. Graham , Miller and Rusnak [ Graham 99] observe t he growing incidence of t hese ad hoc net works and t he result ing dem and for self- configuring syst em s: The em ergence of inform at ion appliances and new t ypes of connect ivit y is spurring a new form of net working: unm anaged, dynam ic net works of consum er devices t hat spont aneously and unpredict ably j oin and leave t he net work. Consum ers will expect t hese ad hoc, peer- t o- peer net works t o aut om at ically form wit hin t he hom e, in very sm all businesses and in net worked vehicles.… To achieve t he goals of sim plicit y, versat ilit y and pleasurabilit y, t he appliances and t he net work( s) t hey j oin m ust j ust work right out of t he box. By j ust work we m ean t hat t he part icipant s on t he net work m ust sim ply self configure. By self configure we m ean t hat t hese net work devices and services sim ply discover each ot her, negot iat e what t hey need t o do and which devices need t o collaborat e w it hou t a ny m a n ua l in t e r ve n t ion . [ 5] [5] Reprinted by permission from Discovering Devices and Services in Home Networking, copyright (1999) by International Business Machines Corporation.

Prot ocols for service discovery can help t o enable t his self- configurat ion. Since m uch of t he int erdevice com m unicat ion in Bluet oot h usage scenarios is of a peer- t o- peer, ad hoc nat ure, t he SI G det erm ined t hat a service discovery prot ocol in t he st ack could provide significant value. The result ing prot ocol, known as SDP, is a cent ral com ponent of nearly all of t he profiles and usage cases, bot h exist ing and foreseen. The service discovery concept is not new or unique t o Bluet oot h wireless t echnology. Num erous service discovery t echnologies are available in t he indust ry, som e of t hem well known. As is evident in ot her layers of t he prot ocol st ack, t he SI G is cont ent t o adopt exist ing prot ocols where it m akes sense t o do so. I n t he case of service discovery, t hough, t he SI G developed it s own prot ocol unique t o and opt im ized for Bluet oot h wireless com m unicat ion rat her t han adopt ing

109

som e ot her service discovery prot ocol in t he indust ry. The reasons should becom e evident as we review SDP's developm ent in t he next sect ion.

SDP Development The need for a service discovery com ponent in t he prot ocol st ack was recognized early in t he process of developing t he specificat ion, alt hough direct work on SDP did not com m ence unt il lat er. I n early and m id 1998, m any of t he init ial part icipant s in t he SI G were focusing on t he t ransport prot ocols and key m iddleware prot ocols like RFCOMM. While t he need for ot her prot ocols had been ident ified, t ask forces of expert s t o develop t hese prot ocols had not been assem bled in all cases. I n t he case of SDP, som e prelim inary work had been st art ed at I nt el and Ericsson in t he sum m er of 1998. I n early int ernal versions of t he specificat ion, service discovery was a sect ion wit hin t he L2CAP part of t he specificat ion. I nit ially, L2CAP channels were m odeled aft er a com put er bus, and service discovery was concerned exclusively wit h t he t ransport of Plug and Play param et ers over t his virt ual bus. I n Sept em ber 1998, at a SI G m eet ing in London, [ 6] aut hor Bisdikian suggest ed t hat t he addit ion of a t ransport prot ocol for Plug and Play param et ers unnecessarily com plicat ed t he L2CAP specificat ion, and t hat such a prot ocol m erit ed it s own service discovery port ion of t he Bluet oot h specificat ion. [6] To advance the development of the specification, face-to-face meetings among SIG members have taken place in many different countries reflective of the multinational constituency of the SIG membership.

I n Oct ober 1998 t he SI G held a developers conference in At lant a which aut hor Miller at t ended. Based upon conversat ions during t hat conference, Miller was asked t o chair t he service discovery t ask force of t he SI G's soft ware working group short ly t hereaft er. The following m ont h t he newly const it ut ed group m et for t he first t im e as a form al SDP t ask force. While at t his t im e ( lat e 1998) m any of t he prot ocol layers had been under developm ent for several m ont hs, wit h som e of t hem approaching levels of st abilit y t hat would soon near final st ages, SDP was st ill really in a nascent st at e of form ing t he requirem ent s and t he beginning of a proposal t o address t hose requirem ent s. Am ong t he ident ified obj ect ives for Bluet oot h SDP were: Sim plicit y: Because service discovery is a part of nearly every Bluet oot h usage case, it is desirable t hat t he service discovery process be as sim ple as possible t o execut e. For t he SDP t ask force t his also im plied t he reuse of ot her Bluet oot h prot ocols t o t he ext ent possible. Com pa ct ne ss: As described in previous chapt ers, t he form at ion of Bluet oot h com m unicat ion links bet ween t wo devices can in som e cases be t im e consum ing. Since service discovery is a t ypical operat ion t o perform soon aft er links are est ablished, t he SDP air- int erface t raffic should be as m inim al as feasible so t hat service discovery does not unnecessarily prolong t he com m unicat ion init ializat ion process. Ve r sa t ilit y: The version 1.0 specificat ion includes a num ber of profiles, and fut ure revisions will undoubt edly add t o t he list , which is expect ed t o cont inue t o grow. Since an exhaust ive set of profiles, usage cases and associat ed services cannot be foreseen or accurat ely predict ed, it is im port ant for SDP t o be easily ext ensible and versat ile enough t o accom m odat e t he m any new services t hat will be deployed in Bluet oot h environm ent s over t im e. To support t his obj ect ive t he SDP t ask force chose a very broad definit ion of " service," so t hat t he widest possible spect rum of feat ures ( services) could be support ed in t he fut ure.

110

Se r vice loca t ion by cla ss a n d by a t t r ibu t e : I n t he dynam ic ad hoc net working environm ent it is im port ant t o enable client devices and users t o quickly locat e a specific service when t hey already know exact ly ( or at least largely) what t hey are looking for. I t should be st raight forward t o search for a general class of service ( say, " print er" ) , for specific at t ribut es associat ed wit h t hat service ( for exam ple, " color duplex I BM print er" ) and even for a specific inst ance of a service ( such as a specific physical print er) . Se r vice br ow sin g: I n addit ion t o searching for services by class or at t ribut e, it is oft en useful sim ply t o browse t he available services t o det erm ine if t here are any of int erest . This is a different usage scenario t han is searching for specific services, and in som e respect s it is alm ost a cont rary obj ect ive, but t he SI G agreed t hat bot h usage m odels have m erit , and t hey developed a solut ion t hat uses a consist ent m et hod t o support bot h specific service searching and general service browsing. These obj ect ives led t o t he developm ent of requirem ent s for a sim ple, flexible prot ocol and dat a represent at ion for service discovery in t he prot ocol st ack. Popular indust ry discovery prot ocols were reviewed, but none seem ed t o provide a good m at ch for t he SDP obj ect ives—m any of t hese t echnologies provide robust and com prehensive service discovery and access m et hodologies, but t he SI G was really looking for a fairly low- level, sim ple, narrow- in- scope solut ion t hat m et t he rat her m odest obj ect ives not ed above in a st raight forward m anner. [ 7] At t his point Mot orola® approached t he SI G wit h a proposal t o cont ribut e som e t echnology, suit able for use in Bluet oot h service discovery, t hat Mot orola had had under developm ent for several years. Through a cont ribut ing adopt er agreem ent Mot orola was t hen able t o part icipat e in t he SDP t ask force of t he SI G ( and in fact t he Mot orola represent at ive served as edit or of t he SDP specificat ion) , wit h t heir cont ribut ed t echnology form ing t he basis for SDP. [7] Subsequent to publication of the version 1.0 specification, efforts were begun to map some of the leading industry service discovery technologies to the Bluetooth stack. Chapter 16 gives details of this work.

So wit h t he SDP effort underway in Novem ber 1998, t he SDP requirem ent s and scope were agreed upon and t he specificat ion developm ent ensued, incorporat ing t he ideas cont ribut ed by Mot orola along wit h t he m any cont ribut ions by t he ot her SI G m em ber com panies. Even t hough t he real SDP work st art ed lat er t han for m any ot her prot ocols, t hrough hard work t he SDP specificat ion was com plet ed, rat ified and published along wit h t he bulk of t he ot her prot ocols in t he st ack in July 1999 in t he version 1.0 specificat ion. The following sect ions describe som e of t he key facet s of t he SDP specificat ion, including why t hese elem ent s are significant and t he rat ionale for including t hem in t he specificat ion.

SDP Examined Key t o underst anding t he developm ent of SDP is t o underst and it s m ot ivat ion and requirem ent s. I n fact , t his inform at ion is included at t he beginning of t he SDP port ion of t he specificat ion. As not ed above, SDP is int ended t o allow devices in Bluet oot h environm ent s t o locat e available services. As t he specificat ion st at es, t hese environm ent s are qualit at ively different from t radit ional net works such as LANs or WANs. Devices and services are likely t o com e and go frequent ly in Bluet oot h piconet s. Thus SDP was developed t o sat isfy t he requirem ent s of such environm ent s. Som e of t he not able requirem ent s for SDP are list ed in t he preceding sect ion. These are also m ent ioned and expanded upon in t he specificat ion. Also of int erest are t hose it em s t hat SDP does not at t em pt t o address, at least in version 1.0 of t he specificat ion. [ 8] The " Non- Requirem ent s and Deferred Requirem ent s" port ion of t he SDP specificat ion can be sum m arized largely wit h t he st at em ent t hat SDP is narrow in scope, focusing prim arily on discovery in Bluet oot h environm ent s

111

and leaving m ore sophist icat ed service funct ions and operat ions t o ot her prot ocols which m ight be used in conj unct ion wit h SDP. [8] Of these, the Bluetooth SIG might choose to enhance SDP in the future to address some of the issues. Many, however, are likely to remain outside the scope of Bluetooth SDP, since some of the issues can be and are addressed by industry discovery protocols, which Bluetooth SDP can accommodate, as explained in the main body text.

SDP includes t he not ion of a client ( t he ent it y looking for services) and a server ( t he ent it y providing services) . Any device m ight assum e eit her role at a given t im e, act ing som et im es as a service client and som et im es as a service provider ( server) . The service provider needs t o m aint ain a list of service records t hat describe t he service( s) it provides; t his list is called t he service regist ry. A service record is sim ply a descript ion of a given service in a st andard fashion as prescribed by t he specificat ion. A service record consist s of a collect ion of service at t ribut es cont aining inform at ion about t he class of t he service ( which m ight be print ing, faxing, audio services, inform at ion services, and so on) , inform at ion about t he prot ocol st ack layers t hat are needed t o int eract wit h t he service, and ot her associat ed inform at ion such as hum an- readable descript ive inform at ion about t he service. Figure 8.3 illust rat es t he general st ruct ure of a service regist ry wit h it s const it uent service records. Shown is a set of services, each wit h a service record handle ( depict ed by srvRecHnd[ 0] t hrough srvRecHnd[ j ] ) and a set of at t ribut es per service ( shown as srvAt t ribut e[ 0: a] t hrough srvAt t ribut e[ j : c] ) . Furt her explanat ion of t he cont ent of t hese service records follows.

Figu r e 8 .3 . Ge n e r a l SD P se r vice r e gist r y st r u ct u r e .

Service records consist of bot h universal service at t ribut es and service- specific at t ribut es. The universal service at t ribut es are sim ply t hose part s of t he service record t hat apply t o all t ypes of services, such as t he service class and prot ocol st ack inform at ion not ed above. Service- specific at t ribut es are t hose part s of t he service record t hat are relevant only for a specific class or inst ance of a service. Exam ples of service- specific at t ribut es could include at t ribut es specific t o a print ing service ( such as color, duplex and finishing capabilit ies) , at t ribut es specific t o an audio service ( such as dat a rat e or encoding schem e) or at t ribut es specific t o a dial- up net working service ( such as serial port configurat ion or m odem set up inform at ion) . Volum e 1 of t he specificat ion includes definit ions for a set of universal service at t ribut es ( t hose which could apply t o all t ypes of services) , but it does not include service- specific at t ribut es, since it would be im possible t o specify and predict all of t he at t ribut es for every im aginable t ype of service. Service- specific at t ribut es are defined in profiles ( volum e 2 of t he specificat ion) . Since profiles describe a usage scenario and how t he prot ocol st ack is used, t hey effect ively define a service.

112

So, for exam ple, t he headset profile defines t he service specific at t ribut e " rem ot e audio volum e cont rol" t hat applies t o t he headset service. While t he universal service at t ribut es can apply t o all t ypes of services, t his does not m ean t hat t hey are m andat ory—it is not required t hat every service include every universal service at t ribut e in it s service record. I n fact , only t wo of t he universal service at t ribut es are m andat ory: t he service class at t ribut e, which defines t he class, or t ype of t he service, and t he service record handle, which serves as a point er, or reference t o t he service record and is used by t he client t o access t he server's service record. Each service at t ribut e in a service record consist s of an at t ribut e ident ifier ( at t ribut e I D, a 16- bit unsigned int eger) and an at t ribut e value associat ed wit h t hat at t ribut e I D. Each ent ry of t he service record is one of t hese ( at t ribut e, value) pairs. Because t hese at t ribut es describe all sort s of inform at ion, SDP uses t he concept of a dat a elem ent for t he at t ribut e value. A dat a elem ent is sim ply a self- describing piece of dat a. The first part of a dat a elem ent consist s of a one- byt e header t hat t ells t he act ual t ype and size of t he dat a. The rem ainder of t he dat a elem ent consist s of t he dat a values for t he at t ribut e, of t he form at and size specified by t he dat a elem ent header. Through t he use of dat a elem ent s, SDP allows at t ribut e values t o be of several t ypes, including st rings, Booleans, signed and unsigned int egers of various sizes, and universally unique ident ifiers ( UUI Ds, discussed furt her below) . Moreover, t hese dat a t ypes can be list s of t he scalar elem ent s not ed above, t hus providing a flexible represent at ion for t he m any dat a t ypes of which at t ribut e values m ight be com posed. Discovering a service in Bluet oot h wireless com m unicat ion reduces t o a sim ple operat ion: t he client specifies t he service( s) of int erest and t he server responds, indicat ing any available services t hat m at ch what t he client specified. I n pract ice for SDP t his consist s of t he client 's sending a request in t he form of an SDP prot ocol dat a unit ( SDP_PDU) t hat indicat es what service( s) it is searching for and t he server's sending back a response, also in t he form of an SDP_PDU, t hat indicat es what services m at ch t he request t hat t he client has m ade. To accom plish t his, t he client needs a st andard way t o represent t he service( s) of int erest and t he server needs a st andard m et hod t o m at ch it s available services against t he client 's specificat ion. For t his purpose SDP int roduces universally unique ident ifiers ( UUI Ds) . A UUI D is a concept adopt ed from t he I nt ernat ional Organizat ion for St andardizat ion ( I SO) . UUI Ds are 128- bit values t hat can be creat ed algorit hm ically and, generally speaking, can be virt ually guarant eed t o be ent irely unique—no ot her UUI D ever creat ed anywhere will have t he sam e value. [ 9] One advant age of using UUI Ds is t hat new ident ifiers can be creat ed for new services wit hout requiring a cent ral regist ry of ident ifiers m aint ained by t he SI G, alt hough t he SI G does include a list of " well- known" UUI Ds in t he specificat ion for t hose services relat ed t o t he published profiles. So a client looking for a service j ust specifies t he UUI D associat ed wit h t hat class of service ( or wit h t he specific service) in it s service search request , and t he service provider m at ches t hat UUI D against t hose of t he services it has available t o generat e it s response. [9] This concept is sometimes hard to grasp, but universally unique identifiers can in fact be created. While there is an extremely small chance of duplication, UUIDs as defined by ISO (see [ISO96]) are quite sufficient for the purposes of Bluetooth SDP and turn out to be quite valuable in this context.

The SDP_PDUs exchanged bet ween t he client and server are sim ple t ransact ions. The general SDP prot ocol flow requires only t wo t ransact ions; t he specificat ion defines t hree different SDP t ransact ions, but t he t hird is really j ust a com posit e of t he first t wo. A t ypical SDP t ransact ion consist s of: 1. Client sends a request t o search for service( s) of int erest ; server responds wit h handles t o services t hat m at ch t he request . 2. Client uses t he handle( s) obt ained in st ep 1 t o form a request t o ret rieve addit ional service at t ribut es for t he service( s) of int erest .

113

Following t he above t ransact ion, t he client will presum ably use t he inform at ion obt ained in st ep 2 t o open a connect ion t o t he service using som e prot ocol ot her t han SDP t o access and ut ilize t he service. St ep 1 is called t he ServiceSearch t ransact ion and consist s of t he ServiceSearchRequest SDP_PDU from t he client t o t he server and t he ServiceSearchResponse SDP_PDU in ret urn ( from server t o client ) . As not ed above, t he ServiceSearchResponse SDP_PDU cont ains handles t o one or m ore services t hat m at ch t he request . I n st ep 2, t he client present s one or m ore of t hose handles in a ServiceAt t ribut eRequest SDP_PDU which causes t he server t o generat e a ServiceAt t ribut eResponse SDP_PDU; t his exchange is t he ServiceAt t ribut e t ransact ion. I n t he ServiceAt t ribut eResponse SDP_PDU will be t he at t ribut e values associat ed wit h t he service t hat correspond t o t he at t ribut e I Ds t hat t he client specified in t he ServiceAt t ribut eRequest SDP_PDU. These at t ribut es m ay be a com binat ion of universal service at t ribut es and service- specific at t ribut es, and in m ost cases should provide t he client wit h enough inform at ion t o subsequent ly connect t o t he service. The specificat ion defines a t hird SDP t ransact ion, called t he ServiceSearchAt t ribut e t ransact ion. This t ransact ion consist s of a ServiceSearchAt t ribut eRequest SDP_PDU from t he client t o t he server followed by a ServiceSearchAt t ribut eResponse SDP_PDU from t he server t o t he client . I t is act ually redundant t o t he first t wo t ransact ions described above and is included for efficiency. What t he ServiceSearchAt t ribut e t ransact ion allows is t he com binat ion of st eps 1 and 2. That is, t he client can form a single request t hat specifies not only services t o search for but also t he at t ribut es t o ret urn for m at ching services in t he server's response. The server t hen responds wit h handles t o m at ching services as well as t he request ed at t ribut e values for t hose m at ching services. An im plem ent er t hus has a choice bet ween t he t wo alt ernat ives for SDP t ransact ions. [ 10] More im port ant ly, t hough, t he ServiceSearchAt t ribut e t ransact ion m ay in som e cases be m ore efficient in t erm s of t he num ber of byt es t ransm it t ed over t he air- int erface. The consolidat ed t ransact ion it self requires m ore byt es t han t he individual t ransact ions but could result in fewer t ot al t ransact ions. Especially in cases where m any service records are being accessed, such as in a service browsing applicat ion, t he ServiceSearchAt t ribut e t ransact ion m ight be m ore efficient . [10]

It should be noted, however, that different profiles mandate the use of different SDP transactions, so if a profile is being implemented, the profile will determine which SDP transaction(s) need to be used, and the programming effort to support all three transactions should not be great.

I n a nut shell, t his is m ost of what is needed for SDP t ransact ions. The specificat ion also includes prot ocol definit ions for special cases, including an error response SDP_PDU and a m echanism , called t he cont inuat ion st at e, for dealing wit h server responses t hat cannot fit int o a single SDP_PDU. [ 11] The synt ax of t hese prot ocol t ransact ions and t he dat a elem ent s t hat t hey carry is det ailed in t he specificat ion and is not reproduced here. A unique feat ure of t he SDP chapt er of t he specificat ion is t he inclusion of several det ailed prot ocol exam ples as an appendix t o t he SDP specificat ion. The m em bers of t he service discovery t ask force of t he SI G who developed t he specificat ion felt t hat because t he act ual byt e st ream s generat ed for SDP t ransact ions can be com plex ( even t hough t he t ransact ions t hem selves are concept ually sim ple) , it would be useful t o include t he exam ples as a guide for im plem ent ers. The com plexit y is int roduced m ost ly when com plex dat a elem ent s ( such as Dat aElem ent Sequences, which are list s of dat a elem ent s and which can be nest ed) are carried in t he SDP_PDUs. When t hese com plex dat a t ypes are included in SDP_PDUs, or when SDP_PDUs need t o be split using t he cont inuat ion st at e inform at ion, t he various " count " fields t hat int roduce segm ent s of t he SDP_PDUs need t o accurat ely reflect t he num ber of byt es t hat follow in t hat segm ent . The exam ples in t he specificat ion serve t o clarify t he correct const ruct ion of SDP_PDUs. [ 12] [11]

The client can specify the maximum size for the response to its request SDP_PDU. It is possible for the response that is generated by the server to be larger than this maximum size. In this case, the server includes some continuation state information at the end of its response, which allows the client to initiate another request to obtain the next portion of the response, if desired. [12]

In fact the developers of the specification learned first hand of the need for these examples when they constructed them, since there were some errors in the first internal versions of the examples. There were even some errors in the examples published in the original version 1.0A SDP specification, which were subsequently corrected in version 1.0B.

114

Figure 8.4 sum m arizes t he SDP t ransact ions. Shown in t he figure are represent at ions of t he relevant argum ent s and param et ers passed in t he SDP_PDUs, alt hough t hese are not com plet e list s of all argum ent s and param et ers; t he com plet e synt ax is in t he specificat ion. As Figure 8.3 shows, only services and service at t ribut es t hat are described by UUI Ds are searchable. At t ribut es of a service which are not described by UUI Ds are not searchable and can be ret rieved only aft er a service has been locat ed using a UUI D at t ribut e.

Figu r e 8 .4 . SD P t r a n sa ct ion su m m a r y.

SDP Usage Since SDP was developed prim arily for discovering services in Bluet oot h environm ent s, t he applicat ions m ost likely t o m ake use of SDP will be t hose developed specifically t o be aware of Bluet oot h wireless com m unicat ion ( as opposed t o legacy applicat ions) . One exem plary applicat ion for SDP usage is what we will call t he Bluet oot h Piconet Minder [ 13] ( or BPM applicat ion) . Such an applicat ion is likely t o be included, in one form or anot her, in m any Bluet oot h devices. A BPM applicat ion as we envision it would present a view of available devices and services in proxim it y ( in a piconet ) t o t he user and t o ot her applicat ions. This could include a user int erface; one m ight im agine icons or ot her represent at ions of devices and services. Such an applicat ion could give a user a cent ral point t o m anage t he Bluet oot h connect ions t o ot her devices and t o select and m ake use of t he services offered by t hose ot her devices. To support such funct ions, a BPM applicat ion m ight m ake use of service searching and service browsing and t hus init iat e SDP t ransact ions t o populat e t he service inform at ion t hat is exposed t o t he user and t o ot her applicat ions. [13]

This term is used generically here and is not known to, or intended to, conflict with any actual product names.

Cert ainly ot her applicat ions designed for use in Bluet oot h environm ent s m ight use SDP. Every profile ( or at least every " non- generic" profile t hat involves concret e usage scenarios) includes an

115

SDP service record t o be used when im plem ent ing t hat profile. Applicat ions writ t en specifically t o exercise t he prot ocol st ack will probably need t o execut e SDP t ransact ions t o successfully inst ant iat e t he profiles. First , such applicat ions will need t o execut e SDP t ransact ions wit h anot her device t o det erm ine if t hat device offers t he desired service, and if so, t hose applicat ions will need t o execut e addit ional SDP t ransact ions t o obt ain t he inform at ion from t he service record about how t o access t hat service ( t his can include such inform at ion as t he required prot ocol st ack and associat ed param et ers t hat t he service uses) . I n t he case where m ult iple applicat ions use SDP ( perhaps one or m ore profile applicat ions and a BPM applicat ion) , it m ay be advant ageous t o im plem ent a cent ral SDP client and SDP server t hat are available t o all t he applicat ions t hat need t hem . These SDP " helper applicat ions" could be im plem ent ed as part of t he com m on services layer t hat was described in Chapt er 5. The applicat ions could use t he plat form API s t o access t he com m on SDP services which would generat e t he SDP t ransact ions and pass t he ret rieved inform at ion back t o t he applicat ions. The Service Discovery Applicat ion Profile ( SDAP) det ailed in Chapt er 12 offers guidance for applicat ion int eract ions wit h SDP. While, as previously not ed, t he specificat ion does not define API s, t he SDAP does define prim it ive operat ions t hat could be m apped t o API s and event s on m any plat form s, t hus providing a basis for SDP com m on services. There m ay be legacy applicat ions t hat m ake use of service discovery, but such applicat ions probably use som e ot her indust ry discovery prot ocol ( perhaps Jini™, Universal Plug and Play™, Salut at ion™, Service Locat ion Prot ocol, t he I rDA service discovery prot ocol, or som e ot her prot ocol) . Since SDP was developed for Bluet oot h applicat ions, legacy applicat ions would not be expect ed t o include t his prot ocol wit hout m odificat ion t o t he applicat ion. Even for t hese applicat ions, t hough, SDP does offer som e accom m odat ion. One of t he design point s for SDP was t o ensure t hat ot her popular indust ry discovery prot ocols could be used in conj unct ion wit h it . One of t he t hings t hat can be discovered using SDP is t hat t he service support s one or m ore ot her discovery prot ocols. Thus SDP m ight be used in t he init ial service discovery phase t o locat e t he service; furt her SDP t ransact ions m ight be used t o discover t hat t he service support s, say, Salut at ion; once t his has been det erm ined, t he newly discovered prot ocol ( Salut at ion in t he exam ple) can be used for furt her int eract ion wit h t he service. SDP specifically support s t his sort of operat ion. A SI G whit e paper [ Miller99] describes how Salut at ion can be m apped t o SDP. Sim ilar m appings t o ot her t echnologies should be possible, and t he SI G is working t oward form alizing som e of t hese m appings as profiles, as discussed in Chapt er 16.

116

Chapter 9. IrDA Interoperability Middleware Protocols Cont inuing our exam inat ion of t he m iddleware prot ocols, we now visit t hose prot ocols int ended t o provide int eroperabilit y wit h I rDA applicat ions. I n t his chapt er we exam ine t he prot ocols and convent ions t hat t oget her in t he specificat ion are t erm ed " I rDA I nt eroperabilit y." This t erm does not m ean t hat devices wit h Bluet oot h wireless com m unicat ion can com m unicat e direct ly wit h I rDA devices but rat her it refers t o prot ocols t hat enable com m on applicat ions t o use eit her form of wireless com m unicat ion. The I rDA int eroperabilit y m iddleware includes prot ocols adopt ed from t he I nfrared Dat a Associat ion ( I rDA) , nam ely I rOBEX ( or briefly, j ust OBEX) , it s associat ed dat a obj ect form at s and t he I nfrared Mobile Com m unicat ions ( I rMC) m et hod of synchronizat ion. I rDA int eroperabilit y occupies fewer t han 20 pages in version 1.0 of t he core specificat ion ( volum e 1) , alt hough over 100 pages are devot ed t o t he I rDA- relat ed profiles in volum e 2 ( t his lat t er m at erial is discussed in Chapt er 14 of t his book) . As is t he case wit h RFCOMM, t he m ain reason t hat t he I rDA int eroperabilit y prot ocols t ake up only a relat ively few pages of t he specificat ion is t hat t hey call out exist ing st andard prot ocols t hat are fully described in ext ernal docum ent at ion, in t his case, specificat ions of t he I rDA. I rDA applicat ion int eroperabilit y is a fundam ent al design principle for Bluet oot h wireless com m unicat ion, and t hus t he I rDA int eroperabilit y m iddlew are is a key elem ent of t he prot ocol st ack. These prot ocol layers are t he basis for several profiles which are likely t o becom e som e of t he m ost com m only im plem ent ed and widely deployed scenarios on devices t hat em ploy t he Bluet oot h t echnology. This chapt er exam ines not only t he I rDA int eroperabilit y inform at ion in t he specificat ion ( as usual, at t em pt ing t o reveal t he rat ionale for t hese prot ocols) but also t he sim ilarit ies and differences bet ween I rDA and Bluet oot h wireless com m unicat ion, since t his lat t er t opic is fundam ent al t o t he design basis for t he I rDA int eroperabilit y solut ion adopt ed for t he specificat ion. The I rDA int eroperabilit y prot ocols reside above ot her m iddleware prot ocols. I n part icular OBEX operat es over RFCOMM in t he st andard case and also could operat e over TCP/ I P as an opt ional im plem ent at ion. [ 1] Like RFCOMM and SDP, t he OBEX session prot ocol uses a prot ocol dat a unit ( PDU) st ruct ure, allowing t he higher layers of t he st ack t o work wit h logical dat a elem ent s at a higher level of abst ract ion t han t hat of t he packet form at s used by t he t ransport prot ocols or even by RFCOMM. More im port ant ly, t hough, OBEX prim arily is int ended t o prom ot e applicat ion int eroperabilit y wit h I rDA, so applicat ions using t his prot ocol wit h I rDA wireless com m unicat ion can adapt easily t o t he use of Bluet oot h links. Figure 9.1 depict s OBEX in t he prot ocol st ack. As shown in t he figure, OBEX is used by higher layers of t he st ack, t ypically applicat ions, and OBEX in t urn uses ot her m iddleware prot ocols, nam ely RFCOMM ( and opt ionally, wit hin t he const raint s described above, also m ay use TCP/ I P) . [1] While TCP/IP operation for IrOBEX is described in the Bluetooth specification (volume 1) in the same level of detail as is RFCOMM operation for IrOBEX, there is no SIG-specified end-to-end TCP/IP solution for version 1.0, since the specification does not address the general use of TCP/IP over Bluetooth transport protocols. Thus, even though IrOBEX could work over TCP/IP, and the IrDA Interoperability chapter of the specification describes how to do this, IrOBEX is assumed to operate over RFCOMM throughout volume 2 of the specification because TCP/IP is not fully specified in the version 1.0 Bluetooth protocol stack. As noted elsewhere, though, TCP/IP can operate over PPP links, and general IP networking solutions are in progress within the SIG.

Figure 9.1. OBEX in t he Bluet oot h prot ocol st ack.

117

IrDA and Bluetooth Wireless Communication Compared Before exam ining t he specificat ion in det ail, we first look at t he underlying t echnologies of I rDA and Bluet oot h wireless com m unicat ion. The obj ect ive, aft er all, for including I rDA prot ocols in t he st ack is t o prom ot e int eroperabilit y wit h I rDA applicat ions ( hence t he " I rDA I nt eroperabilit y" in t he t it le of t his chapt er and in t he specificat ion) . Here we m ust clearly st at e t hat t his int eroperabilit y is at t he applicat ion layer, not at t he physical layer. I rDA int eroperabilit y does not im ply t hat Bluet oot h devices can com m unicat e direct ly wit h I rDA devices. I nst ead it is int ended t o prom ot e developm ent of applicat ions t hat can use eit her t ransport . uPrevious chapt ers have t ouched on t he relat ionship of I rDA and Bluet oot h wireless com m unicat ion. Here we com pare and cont rast specific feat ures of t hese t echnologies. Som e excellent background reading on t his t opic can be found in [ Suvak99] , which was writ t en by a SI G and I rDA part icipant . I rDA is a specific use of infrared light as a com m unicat ions m edium ; Bluet oot h t echnology is a specific use of radio waves as a com m unicat ions m edium . Like t he Bluet oot h SI G, t he I nfrared Dat a Organizat ion ( I rDA) specifies hardware and soft ware prot ocols for wireless com m unicat ion int ended t o prom ot e int eroperable applicat ions. While bot h t echnologies are wireless, t hey use different part s of t he elect rom agnet ic spect rum wit h quit e different signal propagat ion charact erist ics. Since infrared uses t he nonvisible infrared light spect rum , I rDA com m unicat ion is blocked by obst acles t hat block light ( such as walls, doors, briefcases and people) . The signal wavelengt h used wit h Bluet oot h com m unicat ion, at about 12.5 cm , is t hree orders of m agnit ude great er t han t hat of I rDA. At t his wavelengt h, 2.4 GHz RF com m unicat ions can penet rat e t hese sort s of obst acles. Recent advances in infrared t echnology have enabled m ore diffuse t ransm ission pat t erns, alt hough m uch of t he I rDA equipm ent in use t oday uses a relat ively narrowly focused beam , which usually requires t hat t he t wo devices engaged in I rDA com m unicat ion be aligned wit h ( point ed at ) each ot her. RF t ransm ission pat t erns are generally spherical around t he radio ant enna, so any t wo devices wit hin range can com m unicat e wit h each ot her whet her or not t hey are " point ed at " each ot her ( in fact , t he second device m ight not be visible at all t o t he user of t he first device, as it could be in anot her room behind doors and walls or even on anot her floor of a building, for exam ple) . The I rDA specificat ion is m ore m at ure t han t he Bluet oot h specificat ion, having been available for several m ore years. I rDA t echnology was already widely deployed when t he Bluet oot h specificat ion was first released. Thus I rDA has already undergone several phases of enhancem ent t hat Bluet oot h wireless t echnology m ight undergo in t he fut ure. Am ong t hese is som e im provem ent in com m unicat ion speed. The init ial I rDA dat a rat e of 115 Kbps has now been enhanced t o 1 Mbps, which is com parable t o t hat of t he first Bluet oot h radios. Today I rDA can achieve dat a rat es of up t o 4 Mbps, wit h even higher rat es already specified. While Bluet oot h RF com m unicat ion has t he pot ent ial for sim ilar increased dat a rat es ( and t he SI G is invest igat ing t hese possibilit ies; see Chapt er 16 for m ore inform at ion) , it is likely t o lag t he I rDA speeds for at least several years. The effect ive range for Bluet oot h wireless com m unicat ion is about 10 m et ers using t he st andard 0 dBm radio. Wit h opt ional power am plificat ion of up t o 20 dBm , range on t he order of 100 m et ers can be achieved. I rDA range is about 1 m et er and, as not ed above, generally requires a line of sight t o est ablish a connect ion. Bluet oot h wireless t echnology is designed for very low power consum pt ion, and as com pared t o ot her RF t echnologies it consum es very lit t le power. I rDA com m unicat ion, however, consum es even significant ly less power t han Bluet oot h t echnology, since far less power is required for infrared t ransceivers t han for RF t ransceivers.

118

I n t erm s of cost , I rDA hardware was significant ly less expensive t han Bluet oot h radio m odules at t he t im e Bluet oot h t echnology was int roduced. This is part ly due t o t he m at urit y and wide deploym ent of I rDA: t he t echnology has been around long enough t hat several it erat ions of cost opt im izat ions have occurred, and inst alled I rDA unit s num ber in t he m illions, so econom ies of scale result ing from high- volum e product ion have been realized. Bluet oot h m odules in t he year 2000 had not realized eit her of t hese form s of cost reduct ion; even so, it is expect ed t hat Bluet oot h hardware is likely t o rem ain m ore expensive t han I rDA hardware[ 2] owing t o t he com plexit y of t he underlying t echnology, alt hough t he cost difference probably will narrow over t im e. [2] Bluetooth radio module costs in the 2003–2005 time frame are variously estimated to approach $5 U.S.; IrDA solutions are already well below this figure.

Table 9.1 sum m arizes t hese feat ure com parisons of I rDA and Bluet oot h wireless com m unicat ion. The t able reflect s t he st at e of t hese t echnologies in t he year 2000 and reflect s consensus forecast s in t he indust ry. The t able is int ended t o be illust rat ive rat her t han aut horit at ive; cert ain param et ers will vary from im plem ent at ion t o im plem ent at ion.

Ta ble 9 .1 . I llu st r a t ive fe a t u r e com pa r ison of I r D A a nd Blu e t oot h w ir e le ss com m u n ica t ion . Est im a t e s a s of 2 0 0 0 ; som e va lu e s a r e im ple m e n t a t ion de pe n de n t . Fe a t u r e

I r D A t e chnology

Blu e t oot h t e ch n ology

Connect ion est ablishm ent

Line of sight

Penet rat es obst acles

Transm ission pat t ern

Relat ively narrow conical

Relat ively spherical

Dat a rat e

4 Mbps

1 Mbps

Range

1 m et er

10–100 m et ers

Power consum pt ion

10 m W ( nom inal)

100 m W ( est im at ed nom inal; product - dependent )

Transceiver m odule cost

< $1.00

$5.00 ( est im at ed, approxim at ely 2003–2005)

As explained in t he specificat ion and in t he following sect ions, I rDA and Bluet oot h wireless com m unicat ion share sim ilar applicat ion dom ains, even t hough t he underlying t echnology used t o achieve scenarios such as obj ect exchange and synchronizat ion is inherent ly different . Feat ure differences m ay cause one t echnology t o be preferred over t he ot her in cert ain environm ent s and applicat ions, alt hough we believe t hat bot h have m erit and bot h are likely t o be deployed in pervasive com put ing devices in t he foreseeable fut ure. Thus t he I rDA int eroperabilit y provisions of t he specificat ion can help t o enable t he best use of eit her or bot h t echnologies as t he sit uat ion warrant s.

119

The IrDA Interoperability Protocols One of t he m ost com m on applicat ions for I rDA t echnology is exchanging files and ot her obj ect s. This includes exchanging elect ronic business cards bet ween t wo devices as well as t ransferring files and ot her dat a obj ect s bet ween t wo devices, all in an ad hoc fashion and wit hout wires. The devices com m only used in t hese scenarios—especially m obile phones, not ebook com put ers and handheld com put ers, but also ot hers[ 3] —are t he sam e set of devices where Bluet oot h t echnology is deployed or is expect ed t o be deployed. Even t hough direct com m unicat ion bet ween an I rDA device and a Bluet oot h device is not feasible, it seem s clear t hat t hese sam e sort s of applicat ions are quit e relevant and useful in Bluet oot h environm ent s. I n fact , profiles exist in t he version 1.0 specificat ion for bot h obj ect push ( which could be used for elect ronic business card exchange) and file t ransfer ( which can include t ransferring several specific obj ect t ypes) . An ext ended applicat ion of t his sort of dat a exchange is synchronizat ion, where t he dat a is not only exchanged but is also replicat ed bet ween t he t wo devices. A profile exist s for t his usage case also, and it t oo is based upon t he I rDA applicat ion and prot ocols. I n volum e 2 of t he specificat ion, all of t he file t ransfer, obj ect push and synchronizat ion profiles are derivat ives of t he generic obj ect exchange profile, and all of t hese are described in furt her det ail in Chapt er 14 of t his book. [3]

Perhaps including digital cameras and computer peripherals such as printers.

The rat ionale for I rDA int eroperabilit y in Bluet oot h wireless com m unicat ion is t o enable t he sam e applicat ions t o operat e over bot h I rDA and Bluet oot h links, and t he m ost st raight forward way t o do t his is t o use t he sam e session prot ocol in bot h environm ent s. Since t he I rDA prot ocols already exist ed and som e were suit able for Bluet oot h applicat ions, t he SI G chose t o adopt OBEX and I rMC in t he Bluet oot h prot ocol st ack in t he sam e relat ive posit ion as in t he I rDA prot ocol st ack. Unlike RFCOMM, t he I rDA int eroperabilit y specificat ion does not include any significant subset s, alt erat ions, adapt at ions or clarificat ions of OBEX, alt hough t here are som e specific considerat ions ( such as calling out t he specific OBEX version 1.2) not ed for it s use in t he prot ocol st ack. Much of t he descript ion in t he specificat ion echoes im port ant elem ent s of OBEX and describes precisely how OBEX is used over ot her m iddleware layers of t he prot ocol st ack.

IrDA Interoperability Protocol Development The reuse of I rDA prot ocols and specifically OBEX was ident ified as t he design direct ion of t he SI G early in t he specificat ion's developm ent . As wit h RFCOMM, work was underway on t he use of OBEX and I rDA prot ocols and dat a form at s at about t he t im e t he SI G was publicly announced. The synchronizat ion usage case was already ident ified at t hat t im e, as were file t ransfer and dat a exchange applicat ions ( t he lat t er scenarios at t hat t im e were part of t he conference t able usage case) . I n early 1999 t he business card exchange scenario had led t o t he beginning of what is now t he obj ect push profile; file t ransfer and synchronizat ion were well defined, and work on profiles for t hese usage m odels was also underway. I t quickly becam e evident t hat a generic fram ework profile t hat applied t o all I rDA int eroperabilit y usage cases ( t hat is, all t hose profiles using OBEX) would be valuable, so t he generic obj ect exchange profile also was init iat ed. Given t he obj ect ive of int eroperabilit y bet ween I rDA and Bluet oot h applicat ions, an init ial goal of t he SI G was t o produce a specificat ion t hat would allow a single applicat ion t o operat e seam lessly over bot h wireless t ransport s. The SI G was ( and is) m ot ivat ed t o reuse exist ing prot ocols where appropriat e. These considerat ions led t o t he select ion of OBEX as t he point in t he I rDA prot ocol st ack t hat could be insert ed int o t he corresponding point in t he Bluet oot h prot ocol st ack t o allow applicat ions t o deal wit h t he sam e prot ocol ( OBEX) in bot h environm ent s. Wit h st udy and discussion in t he SI G it was det erm ined t hat OBEX could operat e bot h over RFCOMM, which was reasonably well defined by t his t im e, and over TCP/ I P ( alt hough t he lat t er is enabled only in cert ain circum st ances in version 1.0, as discussed below) . Ot her t ransport s for OBEX not direct ly

120

applicable t o t he Bluet oot h prot ocol st ack include I rSock ( infrared socket s) , I RCOMM and Tiny TP ( or TTP) , som e of which are m ent ioned in passing in t he specificat ion.

The OBEX Protocol Examined I rDA int eroperabilit y in general, and OBEX and I rMC in part icular, are significant elem ent s of t he prot ocol st ack, yet relat ively few pages[ 4] are devot ed t o t he t opic in volum e 1 of t he version 1.0 specificat ion. OBEX is t he basis for several of t he version 1.0 profiles and I rDA int eroperabilit y is an im port ant obj ect ive and key value of t he Bluet oot h t echnology. The I rDA int eroperabilit y specificat ion can be so com pact because of t he SI G's decision t o adopt exist ing I rDA prot ocols t hat are fully specified by I rDA ( t he I rDA OBEX specificat ion [ I rDA99a] is about 85 pages long while t he full I rMC specificat ion [ I rDA99b] is nearly 200 pages, alt hough only a port ion of t his lat t er specificat ion deals direct ly wit h I rMC synchronizat ion) . [4]

At fewer than 20 pages, the IrDA Interoperability portion of the specification is easy to read from beginning to end, yet it is a fairly complete description of how IrDA protocols are used in the Bluetooth stack.

While t he specificat ion discusses t he use of OBEX over TCP/ I P, it does not define how TCP/ I P should operat e nat ively over Bluet oot h t ransport s. The fact t hat OBEX can operat e over TCP/ I P will becom e m ore im port ant in t he fut ure when t he SI G defines general TCP/ I P operat ion over Bluet oot h links ( as described in Chapt er 16) . Unt il such a definit ion exist s, t he fact t hat OBEX can operat e over TCP/ I P t ransport s is not direct ly relevant for version 1.0 im plem ent at ions. [ 5] Thus TCP/ I P operat ion for OBEX is specified as opt ional. [5] Which is not to say that such a stack could not be implemented; in fact, it could. But like all other implementations not based upon profiles, the risk of noninteroperability exists. Because TCP/IP is such an important protocol, it is safe to assume that TCP/IP over Bluetooth links eventually will be solved (this is being pursued by the SIG), and thus it is good to know that OBEX over TCP/IP is already enabled.

The ot her Bluet oot h prot ocol over which OBEX is designed t o operat e is RFCOMM. RFCOMM ( det ailed in t he previous chapt er) was designed specifically wit h OBEX in m ind as one of t he RFCOMM client s. Since OBEX over TCP/ I P is defined only in t he cont ext of PPP for version 1.0, we focus here on it s use over RFCOMM. The specificat ion describes t he requirem ent s for t he use of OBEX over RFCOMM. These are not new or unique requirem ent s specific t o Bluet oot h environm ent s; rat her t hey define t he boundaries wit hin which a generic OBEX applicat ion should operat e t o ensure t hat it will work over RFCOMM and t hus over Bluet oot h t ransport s. Am ong t he considerat ions for OBEX over RFCOMM are: Clie n t a nd se r ve r fu nct ion s: The specificat ion indicat es t hat bot h client and server funct ions m ust be support ed by devices im plem ent ing t he OBEX I rDA int eroperabilit y prot ocol. When one exam ines t he I rDA int eroperabilit y profiles ( see Chapt er 14) , it becom es evident t hat while it is t echnically possible for a device t o support only a client or only a server role, it is really useful only when a device can support bot h roles. Even obj ect push, which is largely a one- way dat a t ransfer, st ill requires bot h a client role ( in t his case t he client needs t o push t he obj ect ) and a server role ( in t his case t he server needs t o pull t he obj ect ) . This apparent dichot om y is explained in Chapt er 14. RFCOM M m u lt iple x in g: All OBEX t ransact ions m ust use a separat e RFCOMM server channel ( as described in t he previous chapt er, only one RFCOMM connect ion is perm it t ed bet ween t wo devices) ; t hus, m ult iple client s of RFCOMM m ust use it s prot ocol m ult iplexing feat ure. The OBEX server m ust open a separat e RFCOMM channel connect ion wit h a client . Sim ilarly t he RFCOMM connect ion needs t o be t erm inat ed when t he OBEX session t hat uses it is t erm inat ed. The specificat ion also describes how t o parse t he st ream - orient ed com m unicat ions t hat occur over RFCOMM t o delim it t he OBEX packet st ruct ures cont ained t herein.

121

SD P Su ppor t : OBEX applicat ions in Bluet oot h environm ent s need t o be able t o m ake use of SDP. OBEX client s need t o obt ain t he relevant inform at ion about t he OBEX service from it s service record in t he OBEX server. OBEX servers need t o populat e t he service record wit h inform at ion such as t he appropriat e RFCOMM server channel t o use. As described in t he previous chapt er, t his SDP applicat ion enablem ent m ight be obt ained t hrough t he use of com m on SDP applicat ion services; t hese need not be unique t o OBEX applicat ions. OBEX provides a session prot ocol for t ransact ions bet ween t wo devices. The I rDA defines bot h connect ion- orient ed and connect ionless sessions; t he Bluet oot h specificat ion calls for use of only t he connect ion- orient ed sessions, since t his is what best fit s Bluet oot h environm ent s. Like SDP, OBEX t ransact ions consist of a request PDU issued by t he client followed by a response PDU issued by t he server. Wit h OBEX, t he client role norm ally is assum ed by t he device t hat init iat es t he t ransact ion, while t he responding device becom es t he server. Also sim ilar t o SDP, t he OBEX PDUs consist of a header, a size indicat or and t he argum ent s and param et ers associat ed wit h t he part icular t ransact ion. Fundam ent ally, OBEX is a sim ple prot ocol, wit h t he m ain operat ions being connect and disconnect t o init ialize and t erm inat e sessions, along wit h get and put operat ions t o exchange dat a obj ect s wit hin an exist ing session. These operat ions are described in t he Bluet oot h specificat ion and det ailed in t he I rOBEX specificat ion. I n addit ion t o a session prot ocol, OBEX also serves as an obj ect t ransport for t he dat a t hat can be exchanged in OBEX sessions. To support t he I rDA int eroperabilit y profiles, t he specificat ion calls out part icular obj ect form at s as follows: vCa r d: form at m anaged by t he I nt ernet Mail Consort ium [ I MC96a] for represent ing elect ronic business cards. vCa le nda r : form at m anaged by t he I nt ernet Mail Consort ium [ I MC96b] for represent ing elect ronic calendar and schedule ent ries. vM e ssa ge : form at defined by I rMC [ I rDA99b] t hat represent s elect ronic m essages and elect ronic m ail. vN ot e : form at defined by I rMC [ I rDA99b] t hat represent s short elect ronic not es. Volum e 2 of t he specificat ion calls out each specific obj ect form at as it applies t o t he obj ect push, file t ransfer and synchronizat ion profiles. Som e of t hese profiles allow for different versions of t he obj ect t ypes not ed above; som e also allow for ot her generic obj ect t ypes t o be used wit h OBEX.

IrMC Synchronization Examined I n addit ion t o t ransferring dat a obj ect s over OBEX, it is also quit e useful t o synchronize t hese sam e obj ect s. Synchronizat ion, generally, is t he process of com paring t wo set s of dat a and t hen updat ing t hose dat a set s so t hat t hey exact ly reflect ( are synchronized wit h) each ot her at t he point in t im e t hat t he synchronizat ion is perform ed. There are variat ions on t he synchronizat ion process, such as one- way synchronizat ion where a " slave" dat a set is always updat ed t o m at ch a " m ast er" dat a set , or part ial synchronizat ion where only a subset of t he dat a is synchronized, but in general t he idea is t o m erge t he changes m ade in t wo ( or even m ore) dat a set s int o each ot her so t hat t he dat a set s becom e replicas of each ot her ( unt il addit ional changes are m ade t o t hem ) . Synchronizat ion allows dat a ( perhaps calendar ent ries, address books or e- m ail) t o be m anipulat ed at various t im es and places and t hen be replicat ed against som e ot her relat ed dat a set so t hat t he updat es from t he dat a m anipulat ion can be applied. Applicat ions for synchronizat ion include synchronizing address books t o incorporat e new, changed or delet ed ent ries; synchronizing calendar ent ries t o incorporat e new and changed schedule it em s; and replicat ing e- m ail t o send and receive new not es and m essages and incorporat e saved or delet ed

122

m essages. Synchronizat ion can be especially useful when t hese t ypes of dat a are kept on m ore t han one device. Address books, calendars and e- m ail can be replicat ed am ong m obile phones, handheld com put ers, not ebook com put ers and net work reposit ories of dat a so t hat no m at t er which device is used, t he dat a on t hat device can be current and updat es t o t hese dat a can be reflect ed on t he ot her devices t hrough synchronizat ion. Not e t hat t he devices m ent ioned above are som e of t he devices m ost likely t o em ploy Bluet oot h wireless com m unicat ion. Thus it seem s t hat synchronizat ion is a nat ural usage case in Bluet oot h environm ent s. Not e furt her t hat t he t ypes of dat a m ent ioned above as being com m on candidat es for synchronizat ion ( calendar, e- m ail and cont act inform at ion) are t he sam e dat a t ypes defined in t he profiles for obj ect t ransfer over OBEX. Thus it seem s evident t hat it ought t o be valuable and feasible t o em ploy OBEX- based synchronizat ion in t he specificat ion, and indeed t his is precisely what t he SI G has done. Just as wit h obj ect t ransfer, t he SI G has chosen t o adopt t he m et hod defined by t he I rDA, called I rMC synchronizat ion. I rMC synchronizat ion builds upon t he OBEX session prot ocol and cert ain obj ect form at s ( including som e obj ect form at s defined by I rMC it self) t o specify a m et hod of synchronizing t hese obj ect s. As wit h OBEX, t he specificat ion incorporat es I rMC synchronizat ion as a way t o enable I rDA applicat ion int eroperabilit y. The core specificat ion ( volum e 1) includes very lit t le inform at ion about synchronizat ion per se, focusing inst ead on t he use of OBEX in Bluet oot h wireless com m unicat ion. I t does, however, briefly describe Bluet oot h synchronizat ion when discussing t he synchronizat ion profile, which is where t he det ails can be found. Essent ially I rMC provides a fram ework for OBEX- based exchange of dat a; given t his capabilit y t o exchange dat a form at s including t hose not ed above, addit ional logic can be applied t o perform differencing and select ive obj ect t ransfer, t hus accom plishing synchronizat ion using t he I rMC fram ework wit hin OBEX sessions. Chapt er 14 m ore fully explores Bluet oot h synchronizat ion.

IrDA Interoperability Usage The I rDA int eroperabilit y inform at ion in t he core specificat ion ( volum e 1) includes a descript ion of t he relat ed profiles found in volum e 2 of t he specificat ion. I n fact , since I rDA int eroperabilit y is really about applicat ion int eroperabilit y, t here is a larger am ount of inform at ion ( over 100 pages) on t his t opic in t he profiles t han in t he core specificat ion. Recall t hat I rDA int eroperabilit y j ust m akes reference t o exist ing I rDA specificat ions and describes how t o use t hese st andards in Bluet oot h environm ent s. The reuse of I rDA prot ocols, along wit h t he fact t hat t hese prot ocols operat e over RFCOMM ( a serial port abst ract ion) , is int ended t o facilit at e t he use of exist ing I rDA applicat ions in Bluet oot h environm ent s. I rDA applicat ions are fam iliar wit h t he use of serial port com m unicat ions and are likely t o have support for OBEX prot ocols. By accom m odat ing t hese I rDA int eroperabilit y layers in t he Bluet oot h st ack, t he SI G has paved t he way for applicat ions t hat can operat e wit h bot h I rDA and Bluet oot h wireless com m unicat ion.

123

Chapter 10. Audio and Telephony Control Support for voice or, m ore generically, audio is a dist inguishing at t ribut e of Bluet oot h wireless com m unicat ion. Wit h support for bot h voice and dat a, t he t echnology is well posit ioned t o bridge t he dom ains of com put ing and com m unicat ions, as evidenced by t he ent husiast ic support for t he Bluet oot h t echnology wit hin bot h indust ries. Several of t he profiles address scenarios in which bot h a com put ing device and a t elephony device are used. This chapt er, our final in- dept h exam inat ion of t he core specificat ion, deals wit h t he com ponent s of t he prot ocol st ack t hat enable t elephony and voice ( audio) com m unicat ion. The t elephony cont rol prot ocol is em bodied by t he TCS- BI N ( or j ust TCS for short ) layer, while audio can be carried nat ively over t he baseband. TCS is based upon t he exist ing I TU- T Q.931 prot ocol [ I TU98] , but even so it occupies over 60 pages in t he specificat ion. TCS is a binary encoding for packet - based t elephony cont rol and resides above t he L2CAP layer of t he st ack. TCS- BI N is sufficient t o realize t he version 1.0 t elephony profiles, alt hough applicat ions using AT com m ands over t he RFCOMM serial port abst ract ion ( including headset , dial- up net working and fax) m ight also accom plish a form of t elephony cont rol ( t his lat t er form of t elephony cont rol is not included as a separat e ent it y in t he version 1.0 specificat ion; it is discussed furt her in subsequent sect ions here) . Audio is not a layer of t he prot ocol st ack per se but rat her a specific packet form at t hat can be t ransm it t ed direct ly over t he baseband layer. Since audio is frequent ly ( alt hough not exclusively) associat ed wit h t elephony applicat ions, it is discussed t oget her wit h TCS in t his chapt er as a logical convenience. This chapt er exam ines t elephony funct ions, including audio, in Bluet oot h wireless com m unicat ion. As in preceding chapt ers we will not only provide highlight s and int erpret at ions of t he specificat ion but also t ouch upon t he background inform at ion for t hese elem ent s of t he prot ocol st ack, including t he evolut ion of TCS- BI N. Figure 10.1 depict s audio and TCS- BI N in t he prot ocol st ack; it also shows t he com ponent we call AT Com m and Telephony Cont rol. This lat t er com ponent is a rem nant of what was once called TCS- AT and is explored furt her below. I n general, when we refer sim ply t o TCS we m ean t he TCS- BI N layer of t he st ack. TCS- BI N resides above L2CAP; audio com m unicat es direct ly t hrough t he baseband; and AT com m and t elephony cont rol operat es over RFCOMM. Telephony cont rol applicat ions can com m unicat e direct ly wit h TCS- BI N and m ight also use AT com m and t elephony cont rol.

Figure 10.1. Audio and TCS- BI N in t he Bluet oot h prot ocol st ack. Also shown is t he AT com m and based form of t elephony cont rol used by som e applicat ions.

124

Audio and Telephony Control Operation TCS- BI N is used for t he call cont rol aspect s of t elephony, including est ablishing and t erm inat ing calls along wit h m any ot her cont rol funct ions t hat apply t o t elephone calls. TCS can be used t o cont rol bot h voice and dat a calls. When a voice call is m ade t he audio elem ent of t he st ack is used t o carry t he it s cont ent ; in t he case of dat a calls t he dat a cont ent can be carried over t he t ransport layers of t he st ack ( perhaps also involving ot her m iddleware layers) . The call cont rol funct ions provided by TCS- BI N can be used no m at t er what t he call cont ent ( voice or dat a) is; dat a calls like t hose used wit h t he dial- up net working profile are support ed and so is voice t elephony, like t hat used for t he cordless t elephony and int ercom profiles. TCS- BI N also defines a m et hod for devices t o exchange call signaling inform at ion wit hout act ually having a call connect ion est ablished bet ween t hem ; t his is called connect ionless TCS and is described m ore fully below. Anot her aspect of TCS- BI N is t hat of group m anagem ent funct ions. When t here is a group of devices t hat all support t he TCS- BI N prot ocol, t he m em bers of t he group ( called a wireless user group, or WUG) can m ake use of som e special funct ions defined by TCS, including group m em bership m anagem ent , t elephony service " sharing" am ong devices in t he group and a m et hod for a fast direct connect ion bet ween t wo group m em bers. The TCS- BI N call cont rol and ot her funct ions are exam ined m ore fully below. A second form of call cont rol, which we have called AT com m and t elephony cont rol, was int roduced above. While it is not defined as a nam ed prot ocol in t he specificat ion, it is m ent ioned here because it is a well- known m et hod for accom plishing call cont rol, and it is used by several profiles. I n fact , at one t im e t his concept was em bodied as a separat e prot ocol and elem ent of t he st ack called TCS- AT. While TCS- AT is no longer defined as a separat e ent it y ( and indeed, given t he exist ence of TCS- BI N, a separat e SI G- defined TCS- AT prot ocol is unnecessary, as described m ore fully below) , it is wort h acknowledging t hat t his sort of t elephony cont rol does exist in m any Bluet oot h environm ent s. AT com m ands are m odem cont rol com m ands t hat are likely t o be used especially by legacy applicat ions; t hese applicat ions t ypically are configured t o com m unicat e wit h a m odem over a serial port . Wit hin t he Bluet oot h prot ocol st ack t hese applicat ions could use RFCOMM t o com m unicat e wit h a com pat ible m odem service using t he sam e AT com m and call cont rol funct ions as in ot her environm ent s, wit h lit t le or no change t o t he applicat ion ( especially t hrough t he use of a Bluet oot h adapt at ion layer as described in Chapt er 5) . TCS- BI N is t he only t elephony cont rol prot ocol defined as a separat e ent it y in t he specificat ion, and it is t he prot ocol upon which several t elephony profiles are based. However, AT com m andbased t elephony cont rol is also used in t he headset , fax and dial- up net working profiles, even t hough no separat e AT prot ocol is specified by t he SI G. Audio, as already point ed out , is not really a layer of t he prot ocol st ack. I n fact it would not be unreasonable t o consider audio as a specialized sort of t ransport layer, since it is largely em bodied as a part icular packet form at t hat is sent and received direct ly over t he air- int erface using t he baseband prot ocol. I ndeed, out side t he baseband chapt er, t he specificat ion direct ly addresses audio only in an appendix t hat is fewer t han t en pages long! Yet we have est ablished t hat voice support is a key different iat ing value of Bluet oot h wireless com m unicat ions, and clearly audio direct ly support s voice ( voice and audio are oft en equat ed, alt hough voice is not t he only form of audio) . So why does t he specificat ion not cont ain a chapt er on audio wit h a descript ion and page count com m ensurat e wit h t he im port ance of audio for Bluet oot h applicat ions? The answer has already been suggest ed: because Bluet oot h audio is really j ust a specificat ion of a packet form at and an encoding schem e for t he dat a in t hose packet s, it does not require a lengt hy explanat ion. Once t he allowances ( including t im e slot reservat ion and audio packet definit ion, described m ore fully in Chapt er 6) have been m ade at t he baseband layer t o support audio t raffic, lit t le m ore specificat ion is required. I n fact t he act ual bulk of t he audio specificat ion can be found in t he baseband chapt er of t he specificat ion, which even includes a sect ion devot ed ent irely t o audio baseband t raffic. Thus t o fully underst and Bluet oot h audio one should

125

underst and t he baseband prot ocol st ack layer, described in Chapt er 6 of t his book. However, because audio so oft en is associat ed closely wit h voice and t hus wit h t elephony, it is logically consist ent t o discuss it here along wit h t he ot her t elephony- relat ed funct ions.

TCS Protocol Development Telephony cont rol is int ert wined wit h audio funct ions, and in fact it was audio t hat drove t he need for t elephony cont rol rat her t han t he ot her way around. Before t here was a TCS working group, it was agreed t hat t he prot ocol st ack needed t o support audio so t hat voice as well as dat a t raffic could be enabled. At first t he audio requirem ent point ed out t he need for som e cont rol funct ions, which init ially were present ed as " audio cont rol" funct ions. These audio cont rol capabilit ies were needed t o support t he ult im at e headset , speaking lapt op and t hree- in- one phone usage m odels ( described in Chapt er 3) , and init ially j ust a sm all set of sim ple operat ions ( such as m ake a call, answer a call, t erm inat e a call and adj ust volum e) was envisioned. As t he t elephony profiles ( including t hose not ed above along wit h dial- up net working and fax) were furt her developed, it becam e evident t hat a richer set of t elephony cont rol funct ions was desirable and a working group was form ed t o define t hese capabilit ies for t he prot ocol st ack. Wit h t he init ial recognit ion of a need for m inim al audio cont rol funct ions early in t he SI G's hist ory, it was at first supposed t hat t hese sim ple operat ions would be accom plished via AT com m ands using t he RFCOMM serial port abst ract ion ( recall t hat RFCOMM was fairly well defined even at t his early st age) . Thus was born t he TCS- AT specificat ion. This specificat ion was int ended t o describe how st andard AT com m ands could be m apped over t he Bluet oot h prot ocol st ack and t o define any new AT com m ands required for Bluet oot h wireless com m unicat ion. TCS- AT was designed t o support legacy applicat ions t hat send and receive AT com m ands over a serial port ( m ost likely using a serial cable) . TCS- AT of course specified t he use of RFCOMM as t he serial port replacem ent . As t he specificat ion progressed, it becam e apparent t hat t here was very lit t le need for any new AT com m ands specific t o Bluet oot h environm ent s ( only t wo new AT com m and responses were ident ified as being useful enough t o propose specific definit ions for Bluet oot h TCS- AT) . Thus t he TCS- AT specificat ion becam e a short reference t hat described how t o use AT com m ands in t he Bluet oot h prot ocol st ack, and it s definit ion was absorbed int o t he profiles t hat use AT prot ocols ( nam ely headset , fax and dial- up net working) . I n t he m eant im e a binary, packet - based t elephony cont rol prot ocol was also being defined wit hin t he Bluet oot h prot ocol st ack. Called TCS- Binary ( or TCS- BI N) , it was adapt ed from an exist ing I TU- T specificat ion, Q.931 [ I TU98] . As in ot her cases, t he SI G's adopt ion of exist ing st andards provided benefit s for t he prot ocol st ack, in t his case including t he capabilit y for robust t elephony cont rol operat ions in a st andardized m anner. I n early 1999 it was observed t hat t he likely fut ure direct ion for t elephony cont rol applicat ions was along t he lines of t he TCS- BI N ( I TU- T) st yle, and it was furt her observed t hat TCS- BI N provided all of t he funct ions necessary for all of t he t elephony- based profiles. Finally it was also observed t hat t he TCS- AT specificat ion did not provide significant new funct ions specific t o Bluet oot h environm ent s and prim arily specified a m et hod by which legacy applicat ions m ight use st andard AT com m ands over RFCOMM as a m eans of cable replacem ent . Thus TCS- BI N subsum ed TCS- AT as a separat e prot ocol in t he st ack. The SI G decided t o rem ove TCS- AT as a separat e specificat ion, alt hough t he funct ions were not rem oved; only t he nam e was. Thus t he version 1.0 specificat ion does not m ent ion TCSAT, [ 1] alt hough several applicat ions in fact do use RFCOMM as a serial t ransport for AT com m ands in cases where a m odem service support s such a configurat ion. I ndeed, t he headset , fax and dial- up net working profiles use AT com m and t elephony cont rol. Wit h only TCS- BI N being explicit ly m ent ioned in t he specificat ion, all furt her references t o TCS herein im ply TCS- BI N. [1] Actually there is one "leftover" reference to TCS-AT in the Bluetooth Assigned Numbers appendix of the specification, the last remnant of TCS-AT's former existence as a separately described protocol. As defined there, the value could be used to indicate a device's support for AT command telephony control.

126

The TCS Protocol Examined I n addit ion t o what t he specificat ion calls TCS supplem ent al services ( including caller ident ificat ion inform at ion and dual t one m ult i- frequency [ DTMF] t one generat ion) , TCS defines t hree m aj or funct ional areas: • • •

Call cont rol Group m anagem ent Connect ionless TCS

Each of t hese is explored below. The m aj orit y of t he m ore t han 60 pages of specificat ion devot ed t o TCS deals wit h t he det ailed synt ax and sem ant ics of TCS- BI N, which are not reproduced here. I nst ead we highlight som e of t he im port ant feat ures and nuances of TCS- BI N in t he prot ocol st ack. TCS Call Control The TCS call cont rol funct ions serve t o set up calls t hat subsequent ly will carry voice or dat a t raffic. TCS act s as a st at e m achine, perform ing t he operat ions necessary t o progress a call from one st at e t o t he next , and t racking t he result ing st at e. When m aking calls, t hese operat ions m ight include such t hings as set t ing up t he call, including dialing inform at ion; est ablishing and confirm ing a connect ion; and disconnect ing when t he call is com plet e. For received calls, t he st at es and t ransit ions include call presence ( ringing) , call accept ance and connect ion est ablishm ent and t erm inat ion. Much of t he TCS chapt er of t he specificat ion is devot ed t o a full explanat ion of t hese st at es and t heir t ransit ion operat ions; t he appendix t o t he TCS chapt er of t he specificat ion det ails t hese st at es and t ransit ions in com prehensive st at e diagram s. The t elephony cont rol funct ions can operat e not only in a point - t o- point net work t opology but also in a point - t o- m ult ipoint configurat ion. The m ult ipoint environm ent is relevant , as point ed out in t he specificat ion, for incom ing calls when num erous phones all need t o receive t he incom ing ring signal and cont rol inform at ion. I n t his case, TCS uses m ult ipoint signaling t o alert all t he t elephones of t he incom ing call; it can t hen est ablish a single cont ent channel ( where t he voice or dat a t raffic will flow) wit h t he t elephone t hat answers t he call. [ 2] TCS does not deal wit h t he cont ent t hat is subsequent ly st ream ed over t he channel but only wit h t he call cont rol funct ions t hat occur on t he cont rol channel. [2] The need to transmit ring signals simultaneously to multiple telephone handsets was a primary motivation for including group abstraction and management and connectionless channels in L2CAP. These features could certainly be utilized in other future scenarios, but in version 1.0 they are used only in the context of TCS-BIN.

Unlike RFCOMM, in which a single inst ance of t he prot ocol layer is m ult iplexed, t he specificat ion indicat es t hat m ult iple inst ances of TCS m ay be execut ed at t he sam e t im e t o handle m ult iple calls ( recall t hat Bluet oot h wireless com m unicat ion perm it s up t o t hree voice channels sim ult aneously over t he baseband) . Mult iple inst ances of TCS sim ply use m ult iple L2CAP channels. TCS Group Management Group m anagem ent funct ions use t he concept of a wireless user group ( or WUG) . Such a group can use t he TCS group m anagem ent funct ions t o allow for groups of devices t o t ake advant age of som e special funct ions t hat TCS enables. These funct ions include a m et hod for one device t o m ake use of t he t elephony services of anot her device in t he group; a way t o m anage group m em bership ( called configurat ion dist ribut ion) ; and a way for t wo slave m em bers of t he group t o use t he TCS prot ocol t o est ablish a direct connect ion ( called fast int erm em ber access) .

127

Group m anagem ent is useful in t elephony applicat ions t o enable t he provision of t he sort s of t elephony funct ions t hat m any users expect , such as m ult iple t elephone ext ensions, call forwarding and group calls. I n addit ion, group m anagem ent can help t o accom plish part s of t he t hree- in- one phone profile by perm it t ing phones t o j oin a WUG ( t hus enabling a cellular phone t o be used as a cordless phone) and t o direct ly com m unicat e wit h ot her TCS devices ( t hus perm it t ing t he int ercom or " walkie- t alkie" funct ion) . A WUG is j ust a group of devices t hat all support TCS. The specificat ion m akes special provisions for securit y wit hin t he WUG by allowing t he WUG m ast er t o dist ribut e keys used specifically for com m unicat ions wit hin t he WUG, including com m unicat ion wit h t he m ast er and separat e com m unicat ion ( using a different key) wit h ot her WUG m em bers as is done wit h t he fast int erm em ber access described below. One device in a WUG can request t o use t he t elephony services of anot her device in t he WUG; TCS calls t his an access right s request . A handset m ight request t he use of t he t elephony services of a base st at ion t o m ake a call, or an access right s request m ight be used t o t ransfer a call from one TCS device ( such as a handset or headset ) t o anot her. Configurat ion dist ribut ion is t he TCS- BI N m et hod for m anaging t he m em bership of t he WUG. Again using t he concept of a WUG m ast er t hat m aint ains all of t he inform at ion about t he WUG, TCS- BI N defines a prot ocol for t he WUG m ast er t o send updat ed WUG configurat ion inform at ion t o each WUG m em ber, each t im e t hat configurat ion inform at ion changes. For exam ple, t his m ight be used t o inform all WUG m em bers t hat a new m em ber has j oined ( or t hat som e m em ber has left ) t he WUG. Am ong ot her applicat ions, t his feat ure could be used t o support t he t hree- in- one phone profile by advising WUG m em bers ( perhaps st at ionary handset s and base st at ions in a hom e) t hat a new m em ber ( say, a m obile phone brought int o t he hom e) has j oined t he WUG. Thus t he m obile phone's presence is known and it can cont act t he base st at ion ( t o act as a cordless phone) or it could direct ly cont act ot her phones in t he WUG ( t o act as an int ercom ) . Fast int erm em ber access is a facilit y by which any t wo WUG m em bers can quickly est ablish a connect ion wit h each ot her. This feat ure m akes use of t he fact t hat t wo m em bers already belong t o a WUG and have already est ablished connect ions wit h a com m on WUG m ast er. Thus all WUG m em bers are already in a single piconet , all using t he sam e hopping sequence est ablished by t he WUG m ast er's clock. Furt herm ore, via t he configurat ion dist ribut ion not ed above, all WUG m em bers can know about all ot her WUG m em bers. Because all of t his inform at ion is already known, it can be leveraged t o est ablish a connect ion wit h anot her WUG m em ber m ore quickly t han such a connect ion could be est ablished from scrat ch. Wit h fast int erm em ber access, a WUG m em ber uses t he configurat ion inform at ion t o det erm ine anot her m em ber wit h which it wishes t o est ablish cont act . I t forwards t his inform at ion t o t he WUG m ast er, which in t urn cont act s t he t arget WUG m em ber. That m em ber t hen responds t o t he WUG m ast er, includes it s own clock offset inform at ion in t he response, and t hen places it self int o a page scan st at e. The m ast er forwards t he clock offset inform at ion t o t he request ing WUG m em ber, which can t hen very quickly use t his inform at ion t o est ablish a connect ion wit h t he t arget m em ber by paging t hat m em ber ( which is now in page scan st at e t o accept such pages) , t he result being a new piconet , consist ing init ially of t he t wo devices. This schem e t akes advant age of t he ot her feat ures t hat are already in place for a WUG t o enable quick direct connect ion bet ween any t wo devices in t hat WUG t o support , for exam ple, t he " walkie- t alkie" funct ion of t he t hree- in- one phone profile. Connectionless TCS Finally, TCS- BI N also provides a way for devices t o exchange call signaling inform at ion wit hout act ually placing a call or having a TCS call connect ion est ablished. This is called connect ionless TCS. Connect ionless TCS provides a sort of " sideband" in which devices wit hin a WUG can send m essages t o each ot her wit hout having t o have a TCS connect ion est ablished bet ween t hem . What sort of m essages m ight t hese devices want t o send? The specificat ion defines only a single

128

m essage form at for connect ionless TCS called CL I nfo. CL_I nfo m essages in t urn can cont ain only t wo t ypes of inform at ion: audio cont rol, used t o specify inform at ion about m icrophone gain and speaker volum e set t ings, and com pany inform at ion, which is t he com m on TCS way t o allow any inform at ion not specified in a st andardized TCS form at t o be int erchanged. Thus it can be seen t hat connect ionless TCS could be used t o m anage t he audio set t ings of all m em bers of a WUG as well as t o com m unicat e product - specific feat ures, defined by t he m anufact urer, am ong all of t he devices from t hat m anufact urer in t he WUG. Such use of connect ionless TCS m ight allow, for exam ple, advanced t elephony feat ures t o be used bet ween a base st at ion and a handset from t he sam e m anufact urer t hat m ight not be available t o handset s from anot her m anufact urer ( alt hough t hrough st andard TCS operat ions t he basic t elephony funct ions would be expect ed t o work wit hin t he WUG wit h all handset s) .

Bluetooth Audio Development There was no audio working group per se wit hin t he SI G. Audio has been an inherent part of Bluet oot h wireless com m unicat ion since it s incept ion and t hus has always been int egrat ed int o t he fundam ent al design of t he prot ocol st ack. Audio ( voice or ot her audio) is carried over SCO links at t he baseband layer. These basic SCO links were already defined early in t he SI G's hist ory, short ly aft er it was publicly announced ( t he addit ion of m ult iple SCO connect ions t o support m ult iple voice channels was int roduced in m id- 1998) . This evolut ion of Bluet oot h audio m irrors it s sit uat ion wit hin t he st ack: it is not a dist inct prot ocol layer but rat her a fundam ent al part of t he t echnology. Audio essent ially is int egrat ed int o t he baseband. Owing t o a few specific considerat ions for audio in t he prot ocol st ack we discuss it as a separat e t opic. And as not ed above, due t o audio's affinit y wit h t elephony, for pragm at ic reasons we discuss it in t his chapt er.

Bluetooth Audio Examined A quick scan of t he specificat ion searching for audio inform at ion is likely t o locat e only Appendix V, " Bluet oot h Audio." This appendix cont ains inform at ion int erest ing m ost ly t o audio and sound engineers, including such t hings as recom m ended sound pressure, loudness and audio levels. Alt hough im port ant , it is not t he fundam ent al inform at ion about how t o deal wit h Bluet oot h wireless audio t raffic. That inform at ion, as m ight be expect ed from preceding discussions, is act ually found in t he " Bluet oot h Audio" sect ion of t he Baseband chapt er of t he specificat ion. While audio in Bluet oot h wireless com m unicat ion need not be used exclusively for voice, it s design is opt im ized for voice cont ent . Sound t ends t o be cont inuous for periods of t im e and is t hus isochronous, or t im e lim it ed. The t ransm ission rat e for Bluet oot h audio t raffic is set at 64 Kbps, chosen t o be sufficient for norm al voice conversat ions. While t he com m unicat ion of ot her audio m edia ( say, m usic) over Bluet oot h audio links is not precluded, t he design is not based upon such audio t raffic; it clearly is cent ered around voice t raffic. Two t ypes of encoding schem es are specified for Bluet oot h audio. The first is pulse coded m odulat ion ( PCM) wit h eit her of t wo t ypes of logarit hm ic com pression ( called A- law and µ- law) applied. PCM audio wit h t hese com pression t ypes is well known and widely used for general audio, including t hings like short sound clips. The second audio encoding schem e is cont inuous variable slope delt a ( CVSD) m odulat ion. The charact erist ics of t ypical voice conversat ions, which have a m ore predict able cont inuit y t han general audio ( m usic, for exam ple) , m ake a delt a- slope predict ion m ore efficient . CVSD generally is also m ore t olerant of com m unicat ion errors. Thus CVSD, in general, is a m ore effect ive and efficient ( and t hus generally preferred) m et hod t o use for Bluet oot h audio com m unicat ion; we observe once again t hat t his is an opt im izat ion for voice versus ot her form s of audio.

129

The specificat ion says lit t le else about audio as a t opic unt o it self. The rem ainder of what needs t o be specified ( and what im plem ent ers and ot hers m ay wish t o underst and) about audio can be gleaned from a st udy of t he baseband prot ocol, including t he SCO packet st ruct ure and t im ing designed specifically t o support audio t raffic sim ult aneously wit h dat a t raffic. This inform at ion is found in t he baseband chapt er of t he specificat ion and in Chapt er 6 of t his book. One final not e about audio: it should be clear t hat Bluet oot h audio as described here and in t he specificat ion is digit al isochronous ( effect ively st ream ing) audio t raffic t hat operat es direct ly over t he air- int erface using t he baseband prot ocols. Of course audio inform at ion can also be encoded in a digit al packet - based form at [ 3] using local recording and playback. Such digit al audio inform at ion clearly could be t ransm it t ed over Bluet oot h links using t he L2CAP layer of t he prot ocol st ack, but t his is quit e different from what we refer t o here as Bluet oot h audio. [ 4] [3]

Such as WAV and many other fundamentally similar representations.

[4] For one thing, it is not truly isochronous, at least not in a streaming, over-the-air fashion. For another, most encoding schemes for such digital packet audio are designed so that many types of audio (music, sound clips and so on) can be effectively rendered, rather than optimizing the audio content for one primary use such as voice.

Audio and Telephony Control Usage Several fam ilies of t elephony applicat ions are possible. TCS- BI N is int ended t o support applicat ions t hat realize t he Bluet oot h t elephony- based profiles: cordless t elephony and int ercom . These are t he only t wo profiles t echnically classified as t elephony profiles, based upon t heir usage of TCS- BI N. Such applicat ions are expect ed t o use TCS- BI N direct ly, as depict ed in Figure 10.1. Ot her sort s of applicat ions also m ight be considered in som e respect s t o be t elephony applicat ions; t hese include dial- up net working, fax and headset profile applicat ions. I n volum e 2 of t he specificat ion t hese profiles are considered t o be part of t he serial port profile fam ily; t his is because t he t elephony facet s of t hese applicat ions t end t o use t he program m ing m odel of AT com m ands over a serial port ( RFCOMM in t he Bluet oot h wireless com m unicat ion case) , as described earlier in t his chapt er. Alt hough not TCS- BI N based, we also consider t hese applicat ions in general t o be t elephony applicat ions, and t hey are depict ed in Figure 10.1 as such ( t hat figure shows t elephony applicat ions using bot h TCS- BI N and AT com m ands over RFCOMM) . Legacy applicat ions are likely t o use AT com m and t elephony cont rol, since t his is t he t ypical program m ing m odel in t he world of serial cables. New applicat ions developed specifically t o m ake use of Bluet oot h wireless links, t hough, are encouraged via t he specificat ion t o m ake use of t he TCS- BI N prot ocol, which provides a robust set of t elephony cont rol funct ions based upon an exist ing st andard t hat has been adapt ed for t he Bluet oot h st ack. Telephony and audio, part icularly voice audio, play im port ant roles in t he Bluet oot h st ack. Wit h t heir associat ed applicat ions ( which m ay involve bot h com put ing and t elecom m unicat ions devices in som e profiles and usage m odels) , t hey provide a dist inguishing feat ure of Bluet oot h wireless com m unicat ion.

130

Part 3: The Bluetooth Profiles Examined Having exam ined t he Bluet oot h core specificat ion in Part 2, we cont inue in Part 3 wit h an exam inat ion of volum e 2 of t he specificat ion, known as t he profiles. We begin inChapt er 11 wit h an overview of t he profiles and t heir int errelat ionships, including t he rat ionale for our own grouping of t he profiles in t his book. The rem aining chapt ers t hen explore each of t he published profiles in logically relat ed groups.Chapt er 12 discusses t he fundam ent al generic access and service discovery applicat ion profiles.Chapt er 13 explores t he profiles t hat deal wit h t elephony funct ions ( cordless t elephony, int ercom and headset ) , whileChapt er 14 describes t he fam ily of serial port relat ed profiles ( basic serial port , obj ect push, file t ransfer and synchronizat ion) . FinallyChapt er 15 exam ines t he profiles relat ed t o net working, nam ely t he dial- up net working, LAN access and fax profiles. Part 3, like Part 2, is designed t o sum m arize im port ant inform at ion from t he Bluet oot h profile specificat ion, m aking t hat inform at ion m ore accessible and underst andable. Drawing on our experience in t he Bluet oot h SI G, we at t em pt here t o expose t he m ot ivat ion and rat ionale for key elem ent s of volum e 2 of t he Bluet oot h specificat ion.

Chapter 11. The Bluetooth Profiles Volum e 2 of t he specificat ion consist s of t he profiles. These are int ended t o prom ot e int eroperabilit y am ong m any im plem ent at ions of t he prot ocol st ack t hat is specified in volum e 1. I n t his chapt er we discuss t he general nat ure of t he profiles—t he rat ionale for generat ing t hem , t heir hist ory and evolut ion and t he int errelat ionships am ong t hem . Each of t he version 1.0 profiles is t hen exam ined in m ore det ail in subsequent chapt ers.

The Version 1.0 Profiles Profiles spring from usage cases. Chapt er 3 discussed t he usage scenarios t hat were part of t he developm ent of t he version 1.0 specificat ion ( alt hough not all usage cases result ed in a corresponding profile for version 1.0) . Many of t he profiles can be grouped t oget her based upon t he shared elem ent s of t heir usage scenarios; t his is how t he profiles are grouped int o chapt ers in t his part of t he book. The profiles also can be grouped int o fam ilies based upon t heir t echnical underpinnings; in m any cases t hese m ap in a st raight forward m anner t o usage scenario relat ionships, alt hough in ot her cases t he t echnical relat ionship ( for exam ple, of fax t o headset ) is not so obvious. Furt herm ore, t he version 1.0 specificat ion cont ains addit ional profiles t hat do not direct ly em body usage cases. These include t he generic access profile, t he service discovery applicat ion profile, t he generic obj ect exchange profile and t he serial port profile. Each of t hese profiles can be considered a t ransport profile which defines a com m on basis of shared charact erist ics upon which ot her applicat ion profiles can be built ( or, in obj ect - orient ed t erm inology, t hese profiles are classes from which ot her profiles, or subclasses, inherit ) . Figure 11.1 depict s t he version 1.0 profile fam ilies based upon t heir t echnical relat ionships. A sim ilar figure appears in m ult iple places in volum e 2 of t he specificat ion. That figure depict s t hese relat ionships in a " nest ed cont ainer" sort of represent at ion, while Figure 11.1 uses an obj ect hierarchy represent at ion, but bot h diagram s convey t he sam e inform at ion. The abbreviat ions in parent heses in t he figure int roduce t he short hand nom enclat ure t hat is used in t he rem aining chapt ers of Part 3 t o nam e t he profiles. These abbreviat ions are used for convenience; in som e cases ( but not all) t hey are consist ent wit h sim ilar abbreviat ions for t he profiles t hat are used in t he specificat ion.

131

Figure 11.1. The Bluet oot h version 1.0 profile fam ilies, based upon prot ocol st ack relat ionships, in class hierarchy represent at ion.

This chapt er describes each of t he profiles according t o t he relat ionship shown in Figure 11.1. The rem aining chapt ers of t his part of t he book, t hough, exam ine t he profiles in logical groupings based upon t he relat ionships of t he services t hat each profile provides. There are m ult iple ways of viewing several of t he profiles and t hus t here are m ult iple ways t o group t he profiles. This chapt er present s one such grouping, t hat of t he t echnical elem ent s shared am ong profiles ( which is consist ent wit h t he version 1.0 specificat ion, alt hough it does not propose any overt grouping at all ot her t han including a different represent at ion of t he figure shown above) . Figure 11.2 depict s t he logical, service- based grouping t hat we use in discussing t hese profiles in subsequent chapt ers. One exam ple of t hese m ult iple viewpoint s is t hat of t he headset profile. As depict ed in Figure 11.1 in t he profile hierarchy, headset is a derivat ive of t he serial port profile. However, from a funct ional or services point of view t he headset profile could be considered t o be part of t he t elephony profile group, as shown in Figure 11.2, and t hus we include it in Chapt er 13 along wit h cordless t elephony and int ercom . Anot her exam ple is t hat of t he fax profile, which from a t echnical perspect ive is also a serial port profile derivat ive. Our t reat m ent of t he fax profile in t his book, t hough, is alongside t hat of t he dial- up net working and LAN access profiles, as part of what we consider a " net working" cat egory, [ 1] a group which t he specificat ion does not address. [1]

While it may not be obvious how a fax profile fits within a networking category, consider that the fax usage scenario, like dial-up networking and LAN access, uses a Bluetooth device as a "gateway" to a wide area network for data communication. Chapter 15 further elaborates this point.

Figure 11.2. The Bluet oot h version 1.0 profiles, based upon logical service- based groupings.

132

This discussion and t he figures are int ended only t o point out t hat t here are m ult iple ways in which t o cat egorize t he version 1.0 profiles. The choice of which m et hod t o use is probably best m ade depending upon t he purpose and circum st ances surrounding t he need t o group t he profiles in t he first place, and m ost dist inct ions are not likely t o be drast ically different . However, because t he num ber of profiles is expect ed t o grow over t im e, wit h t he SI G already planning t o add quit e a few new ones ( as discussed in Chapt er 16) , t he act of grouping t he profiles becom es m ore advant ageous, and t he different ways of doing so should not be confused. Ge ne r ic Pr ofile s: This group is com posed of t he generic access profile, which is t he root of all profiles, and t he service discovery applicat ion profile, which provides a fram ework for m apping from t he applicat ion layer t o t he SDP layer of t he st ack. Te le ph on y Pr ofile s: I n t he obj ect hierarchy view, t hese are t he profiles t hat im ply t he use of TCS- BI N for t elephony cont rol funct ions. This group includes t he cordless t elephony and int ercom profiles ( in Chapt er 13 we consider t he headset profile in t he t elephony group also, alt hough from t he t echnical perspect ive it is part of t he serial port group) . Se r ia l Por t Pr ofile s: All of t he rem aining profiles are part of t he serial port group. However, t his group is furt her subdivided. Direct derivat ives of t he serial port profile are t he dial- up net working, fax, headset and LAN access profiles; as well as t he ge ne r ic obj e ct e x cha nge pr ofile . The lat t er in t urn is t he parent of t he rem aining obj ect exchange group profiles, nam ely file t ransfer, obj ect push and synchronizat ion. While we t reat t his lat t er group ( t he obj ect exchange profiles along wit h t he basic serial port profile) ident ically in t his book, som e of t he ot her m em bers of t he serial port profile fam ily are cat egorized different ly. Specifically, as already not ed, t he headset profile is exam ined in t he t elephony group, and t he rem aining serial port profile fam ily m em bers—fax, LAN access and dial- up net working—are t reat ed as a net working fam ily, which is exam ined in Chapt er 15.

Part 3 Chapter Organization I n each of t he rem aining chapt ers of Part 3 we exam ine a group of profiles as described above. Each chapt er is organized such t hat it addresses: • • •

t he com m on elem ent s of t he profiles in t hat group; t he hist ory of each profile; and an exam inat ion of each profile, including how it m aps t o t he prot ocol st ack and how applicat ions m ight use it .

I n addit ion, wherever possible, we offer insight about t he rat ionale, design t hought process and fut ure possibilit ies of t he profiles based upon our part icipat ion in t he SI G when t he profiles were being developed.

133

Chapter 12. The Generic Profiles Our exam inat ion of t he profiles begins wit h t wo t hat we call t he generic profiles because t hey are fundam ent al t o Bluet oot h wireless com m unicat ion. The generic access profile, or GAP, is t he basis for all ot her profiles. I t describes t he fundam ent al operat ions necessary for t wo Bluet oot h devices t o est ablish com m unicat ion, including t he discovery of devices, link est ablishm ent and configurat ion and securit y considerat ions. The GAP is t ight ly coupled wit h t he group of Bluet oot h t ransport prot ocols described in Chapt ers 6 and Chapt ers 7. The service discovery applicat ion profile, or SDAP, describes fundam ent al operat ions necessary for service discovery, an operat ion oft en perform ed soon aft er a com m unicat ion link is est ablished. The SDAP m aps direct ly t o t he service discovery prot ocol ( SDP) described in Chapt er 8. Most Bluet oot h devices are not expect ed t o im plem ent all of t he profiles. A dat a access point , for exam ple, probably would not im plem ent t elephony profiles, while a headset device is unlikely t o im plem ent net working profiles. However, nearly all devices are expect ed t o im plem ent bot h t he GAP and SDAP; in fact , it is m andat ory for all devices t o com ply wit h t he GAP. Also, t he use of SDP over t he group of Bluet oot h t ransport prot ocols follows t he corresponding guidelines out lined in SDAP. These t wo profiles do not describe a specific usage case per se but rat her define basic funct ions t hat are necessary ( or at least highly desirable) for all devices.

Relationships The relat ionship bet ween t hese t wo profiles m ay not be evident upon a cursory exam inat ion of t he specificat ion. Each deals wit h considerat ions t hat are m ost ly relevant t o different layers of t he prot ocol st ack. The GAP largely addresses lower- layer prot ocols involved in t he m ost basic Bluet oot h com m unicat ion funct ions, while t he SDAP focuses prim arily on it em s of int erest t o higher- layer applicat ions. However, t hese t wo profiles also share m any t rait s. Neit her t he GAP nor t he SDAP addresses a specific usage case. Many of t he ot her profiles, like synchronizat ion or cordless t elephony, deal wit h specific, concret e end- user scenarios. For t he m ost part , t he t opics covered in t he GAP and SDAP are not visible t o an end user ( wit h som e of t he applicat ion int eract ions except ed) , but t hese profiles define procedures and prot ocol usage t hat are necessary t o accom plish all of t he ot her profiles. I ndeed, t his is why t he GAP is t he basis for all ot her profiles and why it s inclusion in Bluet oot h devices is m andat ory. Sim ilarly, t he SDAP defines m et hods for exercising prot ocols for t he purpose of service discovery, and service discovery is a com ponent of nearly all of t he ot her profiles. I n som e respect s, t he GAP and SDAP bot h define " invisible" operat ions t hat are necessary for all ot her profiles and t hus enable t hose ot her profiles. Even t hough t he GAP and SDAP are concerned prim arily wit h low- level com m unicat ion funct ions, each also has an applicat ion facet and t hus som e degree of visibilit y t o an end user. While m uch of t he int eract ion t hese profiles specify can occur in an aut om at ed fashion, m ost ly hidden from t he user, som e operat ions m ight involve t he end user as well. Exam ples include " browsing" applicat ions[ 1] t hat present inform at ion about devices and services wit hin proxim it y, and t he present at ion t o t he user of various opt ions available, such as t he degree of securit y t o be used for a part icular com m unicat ion link. I n such cases a user int erface or applicat ion program m ing int erface could be associat ed wit h t hese profiles. Nevert heless, t he device and service discovery and connect ion m anagem ent is always perform ed in accordance wit h t he specificat ions of t he GAP and SDAP. [1]

One example is the "Bluetooth Piconet Minder" application described in Chapter 8.

134

The overall profile creat ion process st art ed lat e in t he developm ent of t he specificat ion, when it was realized t hat applicat ion int eroperabilit y could be best achieved t hrough a form ally specified way t o facilit at e it . Moreover, t he GAP and SDAP were t he last profiles t o st art being developed. The reason for t heir lat e st art is t hat t hey bot h est ablish a basis for all ot her profiles, and hence t heir need becam e apparent only aft er com m on pat t erns em erged wit hin t he ot her profiles. The SI G realized t hat t he Bluet oot h com m unit y would be served bet t er if t hese com m on pat t erns and procedures were grouped int o separat e docum ent s for ease of reference. This reasoning led t o t he developm ent of t he serial port and obj ect exchange profiles as well. More det ails on t he developm ent of t he generic profiles are given wit hin each profile present at ion, st art ing wit h t he GAP discussion t hat follows.

The Generic Access Profile The Generic Access Profile, or GAP, form s a com m on basis for all Bluet oot h profiles and hence for t he com m on int eroperable usage of t he group of Bluet oot h t ransport prot ocols. One of it s im port ant cont ribut ions is it s definit ion of a st andard set of t erm inology. Chapt er 8 of t he GAP cont ains four pages of st andard t erm s wit h crisp definit ions. Having t his com m on vocabulary helps t o rem ove am biguit y in all of t he profiles, which is a key elem ent in enabling int eroperable im plem ent at ions- and int eroperabilit y is t he overarching goal of t he profiles in t he first place. Wit h t his com m on t erm inology in place, m ost of t he GAP is devot ed t o defining t he procedures necessary t o est ablish Bluet oot h connect ions. This includes device and nam e discovery, inquiry procedures, pairing and bonding ( explained below) , and link, channel and connect ion est ablishm ent . For all of t hese considerat ions, t he GAP provides com m on and st andard procedures, in som e cases including flowchart s. The im port ance of defining t he fundam ent al com m unicat ion operat ions cannot be overst at ed: wit hout well- defined, int eroperable m et hods for basic com m unicat ion bet ween devices, none of t he ot her profiles could be realized.

GAP Development Because t he GAP is t he root of all of t he profiles, it is nat ural t o assum e t hat it was t he first profile developed. I n fact , t he opposit e is t rue: it was one of t he last t o be defined by t he SI G. To underst and why, one m ust underst and t he hist ory of profile developm ent in t he SI G. As described in Chapt er 1, t he SI G's soft ware working group was organized int o t ask forces t hat focused on developing one prot ocol or a set of relat ed prot ocols. I n January 1999 t he t opic of profiles was first discussed in dept h wit hin t he SI G. Profiles were suggest ed, and lat er adopt ed, as a m eans t o form alize t he Bluet oot h usage scenarios and t o ensure int eroperabilit y am ong m ult iple im plem ent at ions of t he prot ocol st ack. Thus t he init ial set of profiles was based upon t he sam e usage cases t hat drove t he m arket ing requirem ent s docum ent , which in t urn drove t he developm ent of t he prot ocols. The responsibilit y for developing t he profiles init ially fell t o t he sam e t ask forces t hat developed t he corresponding prot ocols. For exam ple, t he headset and cordless t elephony profiles were developed by t hose who defined t he TCS- BI N prot ocol; t he serial port profile was writ t en by t he sam e people who defined RFCOMM; and t he obj ect push and synchronizat ion profiles were developed by t he group t hat specified t he I rDA int eroperabilit y prot ocols. Lat er t he SI G form ed an int eroperabilit y working group, separat e from t he soft ware working group, t o focus exclusively on t he profiles and relat ed issues, alt hough t he part icipant s in t he int eroperabilit y working group in m any cases were st ill t hose who helped t o develop prot ocols in t he soft ware working group. I n t he m ont hs preceding t he creat ion of t he int eroperabilit y working group and t he effort s t o develop usage- scenario- orient ed profiles, an act ivit y began wit hin t he soft ware working group t o develop st andardized m an- m achine int erfaces ( MMI ) . An MMI t ask force, chaired by aut hor Bisdikian, was form ed in Novem ber 1998. I t s goal was t o enhance t he user experience and

135

int eract ion wit h Bluet oot h devices t hrough st andardized usage and connect ivit y procedures, nom enclat ure, and graphic user int erfaces ( where appropriat e) , following t he paradigm of GSM cellular phones. However, t he variet y of devices t hat could be capable of Bluet oot h wireless connect ivit y far exceeds t he variet y of GSM phones; hence t he SI G realized t hat t he developm ent of st andardized procedures for all conceivable Bluet oot h devices could be t oo rest rict ive. Thus, wit h t he creat ion of t he int eroperabilit y working group, t he act ivit ies in t he MMI t ask force m erged wit h t hose of t he int eroperabilit y group. As t he init ial set of profiles progressed and m at ured, it becam e evident t hat each of t he profiles m ade assum pt ions about underlying t ransport prot ocol layers. Because t here was no end- user scenario t hat dealt specifically wit h low- level com m unicat ion issues it was not init ially evident t hat a profile was needed t o address t hose t opics. Meanwhile t he SI G had begun t o discuss securit y issues in earnest . These t wo developm ent s result ed in t he realizat ion by t he SI G t hat a profile was needed t o address t he com m on com m unicat ion elem ent s. By May 1999 t he fram ework of t he generic access profile was in place. Considering t hat t he specificat ion was published t he following July, it should be evident t hat a great deal of work was required in a short am ount of t im e t o com plet e t he GAP.

GAP Examined The GAP is concerned principally wit h t hree it em s: dict ionary, connect ivit y, and personalizat ion. The dict ionary consist s of a collect ion of t erm s and t heir definit ions. These t erm s appear in t he specificat ion, bot h in it s core and profile part s, and t he dict ionary provides t he foundat ion for t heir unam biguous use t hroughout t he specificat ion. Connect ivit y consist s of t he operat ions perform ed by devices t hat allow t hem t o connect , or not , and aut hent icat e, or not , wit h ot her devices. Personalizat ion consist s of t he elem ent s t hat ident ify and cust om ize Bluet oot h devices, like t heir user- friendly nam es and PI Ns. For t he last t wo it em s, t he GAP provides t erm s t hat can be exposed at t he user- int erface ( UI ) level, whenever applicable. This chapt er focuses on t he connect ivit y aspect s of t he GAP, which are used by all ot her profiles. They include t he connect ivit y m odes, t he securit y m odes, and idle m ode procedures. The GAP also has a sect ion on link est ablishm ent procedures t hat sum m arizes t he sequence of operat ions used t o est ablish Bluet oot h links and L2CAP channels; t hese procedures are highlight ed in Chapt ers 6 and 7 and t hus are not discussed furt her here. Connectivity Modes As described in t he baseband port ion of Chapt er 6, a device m ay ent er inquiry scan m ode or page scan m ode, eit her t o be discovered by ot her devices t hat t ransm it inquiries or t o be connect ed wit h ot her devices t hat t ransm it pages t o t he device, respect ively. The baseband specificat ion does not st at e t he condit ions under which a device perform s inquiry and page scans and t hus it does not specify when a device allows it self t o be discovered or connect ed. The HCI specificat ion, described in Chapt er 7, includes HCI com m ands sent by a host t o t he host cont roller, and from t here t o t he link m anager and link cont roller, t hat inst ruct t he lat t er t o ent er t he various inquiry and page st at es. Thus, it becom es a m at t er of a user- level ( or, m ore generally, applicat ion- level) defined policy as t o when a device ent ers any of t hese st at es. Sim ilarly, a user- level defined policy also det erm ines whet her or not devices shall pair ( aut hent icat e) wit h each ot her. This is an im port ant point : user- level decisions det erm ine t he degree t o which a given device can be discovered, connect ed t o and paired. One concern oft en expressed about Bluet oot h t echnology is t hat all Bluet oot h devices will aut om at ically com m unicat e wit h each ot her at any t im e, but t his is a m isconcept ion. Users, or user- level applicat ions, set t he connect ivit y policies t hat det erm ine which devices can com m unicat e wit h each ot her, and when. These policies could be fixed by t he m anufact urers of Bluet oot h devices or could be configurable by t heir users. Thus, device m anufact urers could use t he connect ivit y policies as a way t o different iat e t heir product s.

136

The GAP defines t he policies for device com m unicat ion est ablishm ent and cat egorizes t hem int o discoverabilit y m odes, connect abilit y m odes and pairing m odes. Discoverability Modes A Bluet oot h device is said t o be discoverable if it allows it self t o be discovered by ot her Bluet oot h devices. I n part icular, a discoverable device execut es inquiry scans regularly and responds t o inquiries sent by inquiring devices. There are t hree levels of device discoverabilit y: 1. Ge n e r a l discove r a ble m ode : At t his discoverabilit y level, a device ent ers inquiry scans using t he general inquiry access code ( GI AC) , which is t he inquiry access code ( I AC) generat ed from t he specially reserved lower address part ( LAP) '0x9E8B33' of t he 48- bit Bluet oot h address, as described in Chapt er 6. I n t his m ode, a device responds t o all inquiries and t hus it always can be discovered by all ot her inquiring devices. 2. Lim it e d discove r a ble m ode : At t his discoverabilit y level, a device ent ers inquiry scans using t he lim it ed inquiry access code ( LI AC) , which is t he I AC generat ed from t he specially reserved LAP ` 0x9E8B00'. I n t his m ode, a device m ay respond only t o t he inquiries t hat cont ain t he LI AC and t hus it m ay be discovered only by ot her devices inquiring using t he LI AC. 3. N on discove r a ble m ode : At t his discoverabilit y level, a device does not respond t o inquiries and t hus ot her Bluet oot h devices cannot discover it . When a device is discoverable, it m ust always ent er t he general discoverable m ode, even if it ent ers t he lim it ed discoverable m ode. The lat t er m ode m ay be ent ered in parallel wit h or sequent ially t o t he general discoverabilit y m ode, as described in Chapt er 6. A discoverable device m ust ent er inquiry scans no less frequent ly t han every 2.56 seconds and m ust rem ain in inquiry scan for at least 10.625 m illiseconds. Connectability Modes A Bluet oot h device is said t o be connect able if it allows it self t o creat e Bluet oot h links wit h ot her devices. I n part icular, a connect able device execut es page scans regularly and responds t o pages sent t o it by paging devices. A nonconnect able device does not respond t o pages and t hus it cannot creat e links wit h ot her devices. The discoverabilit y and connect abilit y m odes m ight be set independent ly of each ot her [ 2] ; however, a device t hat is only discoverable and not connect able m ay not be very useful. [2]

There is a host controller interface command that enables inquiry and page scans independently of each other.

Pairing Modes A Bluet oot h device is said t o be pairable if it allows it self t o be aut hent icat ed by anot her Bluet oot h device, m eaning t hat it can play t he role of a claim ant during an aut hent icat ion t ransact ion. Furt herm ore, a pairable device, in addit ion t o accept ing LMP_au_rand PDUs, m ust accept an init ial aut hent icat ion request received from a verifier in an LMP_in_rand PDU, as discussed in t he LMP sect ion of Chapt er 6. A nonpairable device responds t o an LMP_in_rand PDU wit h an LMP_not _accept ed PDU, signifying t hat t he device is not willing t o pair wit h any new devices. Security Modes

137

Securit y operat ions in Bluet oot h devices ult im at ely relat e t o device aut hent icat ion and possibly link encrypt ion. Recall t hat t he form er is a m andat ory feat ure of Bluet oot h devices while t he lat t er is not . [ 3] Three levels of securit y relat e t o t he " dept h" of t he securit y safeguards im posed upon com m unicat ing devices: [3]

However, some profiles do mandate support for and the use of encryption.

1. Se cu r it y m ode 1 : A device t hat operat es in t his m ode does not have any securit y barrier. I n part icular, it never act s as a verifier and t hus never sends LMP_in_rand or LMP_au_rand PDUs. 2. Se cu r it y m ode 2 : A device t hat operat es in t his m ode places a securit y barrier at t he L2CAP layer. I n part icular, it does not init iat e any securit y t ransact ion prior t o receiving a request t o est ablish an L2CAP channel using t he L2CAP_Connect ion_Request signaling com m and, as described in t he L2CAP sect ion of Chapt er 7. This securit y m ode allows a flexible securit y m odel for Bluet oot h devices in which securit y barriers in a rem ot e device can be raised based upon t he part icular service t hat a local device request s from t he rem ot e device. 3. Se cu r it y m ode 3 : A device t hat operat es in t his m ode places a securit y barrier at t he link m anager layer. I n part icular, it does not init iat e dat a com m unicat ions involving t he upper t ransport and higher layers prior t o aut hent icat ing t he device wit h which it is t o com m unicat e. I n ot her words, aut hent icat ion occurs before t he t ransm ission and receipt of t he LMP_set up_com plet e PDU, as discussed in t he LMP sect ion of Chapt er 6. Not e t hat a device m ay be in one and only one securit y m ode at any given t im e. For exam ple, a device in securit y m ode 3 cannot aut hent icat e ot her devices select ively; inst ead it aut hent icat es all devices t hat at t em pt t o est ablish a link wit h it . A flexible securit y archit ect ure for Bluet oot h devices is described in [ Muller99] . I t form s t he basis for t he securit y m odes included in t he GAP. Idle Mode Procedures While t he connect ivit y and securit y m odes are associat ed wit h act ivit ies t hat a Bluet oot h device follows t o react t o incom ing st im uli ( such as inquiries, pages, L2CAP_Connect ion_Request s, and so on) , t he idle m ode procedures relat e t o t he device t hat sends t he st im uli. These procedures include general and lim it ed inquiry, nam e and device discovery and bonding. The general and lim it ed inquiries are used t o discover devices in general or lim it ed discoverable m ode, respect ively. The device discovery process ret urns, am ong ot her t hings, t he user- friendly nam e of discoverable and connect able devices. Not e t hat request ing t he nam e could involve j ust t he LMP layers in t wo devices wit hout involving t he host s. Bonding is a pairing procedure execut ed for t he purpose of creat ing a link key bet ween devices and st oring t hat key for fut ure use. I n general bonding, bonding is com bined wit h addit ional com m unicat ions such as accessing higher- layer services. I n dedicat ed bonding, a device connect s wit h a pairable device wit h t he sole purpose of creat ing a bond bet ween t he devices wit hout involving upper- layer t ransact ions. The GAP concludes wit h a brief descript ion of a service discovery procedure used t o search for services support ed in rem ot e devices. This procedure follows t he guidelines for service discovery found in t he SDAP, which is present ed next .

138

The Service Discovery Application Profile As not ed in Chapt er 8, service discovery is expect ed t o be a key com ponent of m ost Bluet oot h applicat ions. Nearly all of t he profiles include a service discovery elem ent . Like t he GAP, t he Service Discovery Applicat ion Profile, or SDAP, provides a com m on and st andard m et hod for perform ing service discovery using t he Bluet oot h prot ocol st ack. Unlike m ost ot her profiles, t he SDAP describes a st andard service discovery applicat ion m odel and also defines abst ract ions of service prim it ives t hat in som e respect s resem ble applicat ion program m ing int erfaces ( API s) . Even t hough t he SDAP deals wit h t he SDP m iddleware layer prot ocol and t hus addresses som e of t he " invisible" operat ions described earlier, it is aim ed prim arily at applicat ion writ ers. I t is t he only profile wit h " applicat ion" in it s t it le and t he only profile t o suggest API - like prim it ives. As explained in Chapt er 8, t hese prim it ives could be m apped t o plat form API s in a st raight forward m anner.

SDAP Development Bot h aut hors have a special int erest in t he SDAP. Aut hor Bisdikian served as edit or of t he SDAP port ion of t he specificat ion, conceived t he original idea for t he SDAP and cont ribut ed m ost of it s cont ent , and aut hor Miller chaired t he service discovery t ask force responsible for delivering t he SDAP. As wit h t he GAP, t he need for an SDAP was not originally evident , and t hus t he SDAP was also developed lat e in t he specificat ion cycle. Not unt il January 1999, when m ost profiles were already underway, was t he quest ion raised regarding whet her or not a service discovery profile was needed. By March of t hat year t he idea of an applicat ion profile for service discovery was accept ed and t he SDAP developm ent proceeded. The developm ent of t he SDAP is root ed in t he fundam ent al assum pt ions t hat led t o t he form at ion of t he SI G it self: t he diversit y and num ber of devices t hat would be capable of Bluet oot h wireless com m unicat ion and t he diversit y and num ber of services available t hrough t hese devices would st eadily increase. To keep a sem blance of order in t he expect ed sea of devices and services available t o a user, it was recognized t hat a st andardized procedure should be creat ed t hat would allow t he user of a device t o locat e and ident ify services. The SDAP does not describe how t he service discovery it self is perform ed; it relies on SDP for t his t ask. Rat her, SDAP describes how an applicat ion t hat uses SDP should be creat ed and should behave. I n part icular, it defines t he funct ional charact erist ics of such an applicat ion t hrough a set of service prim it ive abst ract ions, det ailed below. Furt herm ore, t he SDAP defines how ot her profiles and applicat ions in general m ust use t he group of Bluet oot h t ransport prot ocols t o carry SDP_PDUs when t hey need t o execut e SDP t ransact ions. This lat t er it em was an expansion of t he SDAP's original scope. All of t he " nongeneric" profiles cont ain an SDP sect ion t hat provides a list of param et ers for t he prot ocol st ack t hat leads t o t he part icular applicat ion covered by t he profile. These prot ocol st ack param et ers include ones like t he RFCOMM dat a link connect ion ident ifier ( DLCI ) needed t o reach, say, t he PPP layer in t he LAN access profile. These param et ers are carried as service at t ribut es wit hin SDP_PDUs. However, t hese ot her profiles do not specify how t he SDP layer could use t he group of Bluet oot h t ransport prot ocols t o carry t hese SDP_PDUs. Since t he lat t er process should be ident ical for all profiles, one idea was t o include it in a generic profile like t he GAP. However, t he GAP does not focus on t he t ransport of dat a wit h a source or sink above t he L2CAP layer. Moreover, t he SDP specificat ion it self does not cont ain t he dependencies of SDP on t he group of Bluet oot h t ransport prot ocols. Even t hough t his m ay seem like an oversight , it was a deliberat e choice. The Bluet oot h service discovery prot ocol, alt hough t ied t o syst em s t hat ut ilize Bluet oot h wireless com m unicat ion, is in principle a t ransport independent prot ocol. Hence, t he SDP specificat ion focuses exclusively on t he SDP t ransact ions

139

t hem selves and t he various SDP_PDUs t hat are used, as well as t he t ype and form of inform at ion t hat is carried in t hem . The SDP specificat ion does not part icularly focus on how t hese t ransact ions are carried over t he Bluet oot h air- int erface. Ult im at ely, SDAP becam e t he only ( and nat ural) point of reference for describing how t he SDP layers use t he group of Bluet oot h t ransport prot ocols t o carry t he SDP_PDUs t o each ot her.

SDAP Examined The SDAP is unique am ong t he applicat ion- orient ed profiles, like t he file t ransfer profile, t he LAN access profile, and so on. These ot her profiles describe how t he com plem ent ary part s of a userlevel applicat ion running on t wo ( or m ore) devices work t oget her t o support a part icular usage scenario. The applicat ion in SDAP needs t o be present in only one device. This applicat ion int eract s wit h t he SDP layer of t he st ack in t he device where it resides t o init iat e SDP int eract ions wit h one or m ore SDP layers in ot her devices, so as t o learn about services in t hose ot her devices. Upon t he arrival of responses from t he ot her devices, t he service discovery applicat ion can m ake t hose result s available t o t he user of t he device t hat init iat ed t he t ransact ion( s) . Oft en, service discovery in non- Bluet oot h environm ent s is perform ed by broadcast ing inquiries for services or inquiries for locat ing direct ories of services. I n t he lat t er case, when a service direct ory is found, it is t hen cont act ed t o find out about services t hat are regist ered t here. I n a Bluet oot h piconet , broadcast s are ent irely unidirect ional in t hat t hey are exclusively direct ed from t he m ast er t o t he slaves of t he piconet . Furt herm ore, broadcast t ransm issions are not recoverable in t hat t hey cannot be ret ransm it t ed following an error in t heir t ransm ission. Thus, service discovery in a Bluet oot h piconet does not use a broadcast m odel. Service discovery in Bluet oot h piconet s is closely associat ed wit h device discovery. Service discovery is execut ed only bet ween fully ident ified pairs of devices and only aft er t hey have discovered each ot her and have creat ed a Bluet oot h link ( up t o and including an L2CAP connect ion) bet ween t hem . According t o t he SDAP, devices part icipat ing in service discovery m ay have eit her of t he following roles: • •

Loca l de vice : This device im plem ent s t he service discovery applicat ion, like t he service browsing applicat ion referred t o in Chapt er 8. I t also im plem ent s t he client port ion of t he SDP layer. A local device init iat es SDP t ransact ions as shown in Figure 8.3. Re m ot e de vice : This device is cont act ed by a local device t o inquire about services. A rem ot e device im plem ent s t he server port ion of t he SDP layer. I t responds t o SDP t ransact ion request s from a local device. To produce it s responses, t he rem ot e device m aint ains, explicit ly or im plicit ly, a dat abase [ 4] t hat cont ains service records for t he services available via t he rem ot e device. [4]

The specification does not define the format of this database, leaving that choice to implementers. Moreover, this need not be a "database" in the classic sense; it is simply a collection of information maintained by the SDP server in a format suitable for the device.

Even t hough som e devices m ay act only as local or as rem ot e devices, t hese device roles are, in general, t em porary and m eaningful only when an SDP t ransact ion bet ween t wo devices is under way. A device can be a local or rem ot e device at different t im es or even at t he sam e t im e, depending upon when it creat es service inquiries or responds t o t hem . The SDAP device roles bear no relat ion t o t he baseband roles of m aster and slave, as t he lat t er roles are m eaningless above t he link m anager layer. A local device could be eit her a m ast er or a slave in it s piconet , as could a rem ot e device. [ 5] [5]

Often a local device acts as master of a piconet, since typically it would be the device that desires to create connections with other devices and search for and use services on them. However, this does not mean that a local device must be a master to perform service inquiries. A slave device could equally well initiate such inquiries.

140

The SDAP is t he only profile t hat uses t he t erm applicat ion in it s t it le. However, t he SDAP does not define any part icular applicat ion. Such a definit ion would be very m uch plat form dependent and possibly t oo rest rict ive for applicat ion developers, neit her of which is a desirable obj ect ive for a specificat ion. However, t he SDAP specifies t he services t hat a service discovery applicat ion should provide t o it s users t o be useful. These services are sum m arized in four service prim it ive abst ract ions. These prim it ives could be m apped t o an appropriat e set of API s based upon t he underlying soft ware and/ or hardware plat form in which an SDAP applicat ion is inst ant iat ed. An exam ple m apping of t hese prim it ives t o t he Salut at ion API s is given in [ Miller99] . These prim it ives are: •

•

•

•

se r vice Br ow se : This service prim it ive is ut ilized when a local device want s t o perform general service searches, referred t o in Chapt er 8 as service browsing. These searches m ight t ake t he form of queries about what services in general or what services of t ype S are available, if any, via a select ed set of rem ot e devices. This applicat ion- level service prim it ive result s in SDP_PDU t ransact ions init iat ed by any one of t he t hree basic request SDP_PDUs present ed in Chapt er 8: SDP_ServiceSearchRequest , SDP_ServiceAt t ribut eRequest , or SDP_ServiceSearchAt t ribut eRequest . Opt ionally, t he LMP_nam e_request PDU could also be sent t o learn t he user- friendly nam e of t he rem ot e device. se r vice Se a r ch : This service prim it ive is ut ilized when a local device want s t o perform searches for a specific t ype of service. The search could t ake t he form of queries about what services of t ype S wit h at t ribut es A1 and A2 are available, if any, via a select ed set of rem ot e devices. Sim ilar t o t he previous prim it ive, t his applicat ion- level service prim it ive result s in SDP_PDU t ransact ions init iat ed by any one of t he t hree basic request SDP_PDUs previously m ent ioned. e n um e r a t e Re m D e v: This service prim it ive is used when a local device want s t o search for rem ot e devices in it s vicinit y. The search can be rest rict ed wit h a class of device ( CoD) qualifier t o search only for devices belonging t o t he specified class. This applicat ion- level service prim it ive result s in t he local device execut ing inquiries t o learn about devices, prim arily any new devices, in it s vicinit y. I f, in t he fut ure, CoD- specific dedicat ed inquiry access codes ( DI ACs) are st andardized, t hen t he inquiries for t his prim it ive could be generat ed according t o t hese DI ACs. Ot herwise, t he generic inquiry access code ( GI AC) is used and t he local device needs t o filt er t he received responses according t o t he inform at ion included in t he CoD field in t he FHS BB_PDUs received from t he responding devices. t e r m in a t e Pr im it ive : This service prim it ive result s in t he t erm inat ion of t he operat ions invoked by t he previous prim it ives.

The first and second prim it ives above relat e direct ly t o t ransact ions involving SDP_PDUs. The t hird prim it ive could be sat isfied m erely by request ing t hat t he device ent er t he inquiry m ode wit h t he sole purpose of searching for any ot her devices in t he inquiry scan st at e ( as described in t he baseband sect ion of Chapt er 6) . The last prim it ive sim ply t erm inat es any ongoing act ions result ing from t he use of any of t he ot her prim it ives. The SDAP requirem ent s on t he Bluet oot h st ack are st raight forward. To im plem ent t his profile one needs t o use not hing beyond t he default set t ings for all t he prot ocol layers below t he SDP layer. I n part icular, devices t hat connect for t he sole purpose of perform ing service discovery do not need t o aut hent icat e each ot her or encrypt t heir Bluet oot h link. [ 6] The SDP t ransact ions are carried over t he ACL baseband link bet ween t he devices. At t he L2CAP layer SDP t ransact ions are carried over connect ion- orient ed channels configured t o carry " best effort " t raffic. [6] This does not imply that device authentication and/or link encryption should not be performed. This statement simply implies that the SDAP imposes no security precautions for its execution. Security is as much a usage scenario requirement as a userlevel settable policy, as discussed in the GAP. Security precautions may still be taken for reasons outside the scope of SDAP.

141

An addit ional dist inct ion of t his profile is t hat it ident ifies t he condit ions under which L2CAP channels carrying SDP t raffic are t orn down. This is so because SDP does not define a session or a t ransport prot ocol for carrying SDP_PDUs. SDP it self is in essence a connect ionless prot ocol. To run t he connect ionless SDP request / response t ransact ions, t he L2CAP layer needs t o m aint ain t he L2CAP channel t hat carries t he t ransact ions at least for t he durat ion of t he t ransact ion. For efficient use of t he t ransm ission resources, t he L2CAP channel bet ween an SDP client and an SDP server should be m aint ained even longer. Ult im at ely, it is t he applicat ion on behalf of which SDP t ransact ions are execut ed t hat should open and m aint ain, for as long as necessary, t he L2CAP channel for SDP t ransact ions bet ween t wo devices.

Summary I n t his chapt er we have highlight ed t he t wo generic Bluet oot h profiles: t he GAP and t he SDAP. The GAP describes t he connect ivit y and securit y m odes of operat ion for a device t hat perm it s it t o discover, be discovered by, and creat e t rust bonds and Bluet oot h links wit h ot her devices. These m odes of operat ion are user- ( or applicat ion- ) set t able device policies t hat specify how t he device should wbehave relat ive t o ot her devices wit h which Bluet oot h com m unicat ion m ight ensue. The SDAP describes t he funct ional charact erist ics of a service discovery applicat ion. Furt herm ore, and equally im port ant ly, t he SDAP describes t he way t hat t he SDP layer m ust use t he group of Bluet oot h t ransport prot ocols t o carry SDP t ransact ions. This aspect of t he SDAP also form s t he basis for execut ing service discovery wit hin t he ot her profiles.

142

Chapter 13. The Telephony Profiles Cont inuing our exam inat ion of t he profiles, we now visit t hose t hat are based upon t elephony funct ions. We include here t he cordless t elephony, int ercom and headset profiles. As described in Chapt er 10, t he fax and dial- up net working profiles also m ake som e use of t elephony prot ocols, but we consider t hese part of t he net working group t hat is covered in Chapt er 15. All t hree t elephony profiles discussed here prim arily address voice t elephony funct ions. They all t arget t elephony devices ( m ost ly m obile phones and headset s) and t hus t hey exist largely for use by t elephones. [ 1] I n fact , t he int ercom and cordless t elephony profiles inst ant iat e t wo different aspect s of t he t hree- in- one phone usage scenario int roduced in Chapt er 3, alt hough t he cordless t elephony and headset profiles explicit ly address t he use of com put er audio in addit ion t o t elephone audio. [1] We suppose that other types of devices could implement these profiles. There is no reason that, say, a computer could not provide intercom profile function if it had the appropriate voice and TCS-BIN support. But in general the telephony profiles center around telephones.

These t elephony profiles, t hen, are expect ed t o be im plem ent ed in m any m obile t elephones and ot her t elephony equipm ent used wit h phones, like headset s and voice access point s. All are int ended t o carry voice t raffic, and in fact it is t his com m on elem ent t hat caused us t o group t hem for t his chapt er's discussion. [ 2] [2] These profiles could have been referred to as "telephony audio" or "voice telephony" profiles but we opted for the briefer yet still descriptive "telephony profiles."

Relationships Voice t elephony is a com m on elem ent shared by t hese t hree profiles, but from a t echnical perspect ive ( refer back t o Figure 11.1) t hey inherit from t wo different profile fam ilies. The cordless t elephony and int ercom profiles are part of ( and indeed all of) t he TCS- BI N fam ily ( even t hough t here is no TCS- BI N profile per se) while t he headset profile derives from t he serial port profile. Yet from an end user's perspect ive, t he m ost visible feat ure of all of t hese profiles is t he abilit y t o rout e and process t elephony- grade audio t raffic using Bluet oot h wireless com m unicat ion. The cordless t elephony and int ercom profiles are bot h part of t he t hree- in- one phone usage case. Recall from Chapt er 3 t hat t he t hree t ypes of usage for a m obile t elephone in t his scenario are as ( 1) a st andard cellular phone; ( 2) an int ercom or " walkie- t alkie" ; and ( 3) a cordless phone using a cordless base st at ion, or voice access point . St andard cellular phone operat ion is addressed by prot ocols like GSM, CDMA, CDPD and ot hers, using a wide area radio in t he handset ; Bluet oot h wireless com m unicat ion is not used for t he st andard cellular phone operat ion. St andard cellular phone usage is not discussed furt her. The profiles for t he rem aining t wo aspect s of t he t hree- in- one phone usage m odel, bot h of which use t he TCS- BI N prot ocol, are unusual am ong t he version 1.0 profiles in t hat t hey define only part of a usage case. Most profiles ( fax, dial- up net working, synchronizat ion and so on) m ap onet o- one t o usage cases. But in t he case of t he t hree- in- one phone usage case, t here are t wo separat e profiles—cordless t elephony and int ercom —t hat define t he t wo separat e part s of t hat single usage case t hat are relevant for Bluet oot h wireless com m unicat ion. I n t his case t here are good reasons t o separat e t he t wo dist inct funct ions. While t hey can be com bined t o realize t he t hree- in- one phone scenario, cordless t elephony and int ercom also can be of value individually, and a robust im plem ent at ion of cordless t elephony is m uch m ore involved and com plex t han is an im plem ent at ion of int ercom . As we will see below, cordless t elephony oft en involves advanced funct ions of TCS- BI N, while int ercom com m unicat ions can be m uch sim pler in com parison.

143

Therefore it could m ake sense in som e devices t o im plem ent j ust an int ercom funct ion wit hout cordless t elephony funct ion. By separat ing t hese funct ions int o individual profiles, such devices can conform t o t he int ercom profile, which is useful in it s own right , wit hout im plem ent ing t he full t hree- in- one phone usage case, which would require addit ional cordless t elephony support . While t he int ercom profile is sim ple in com parison t o cordless t elephony, t he headset profile is int ended t o be even m ore st raight forward and less com plex—it is perhaps t he sim plest of all t he version 1.0 profiles. This is by design, since Bluet oot h headset s are generally expect ed t o be sim ple, low- cost accessory devices; t hus t he requirem ent s of t he headset profile need t o be m inim al t o enable such light weight devices. This is one reason t hat t he headset profile, even t hough it is involved in audio t elephony, belongs t o a different profile fam ily t han do t he cordless t elephony and int ercom profiles. Recall from Chapt er 11 t hat t he headset profile is a derivat ive of t he serial port profile. The SI G felt t hat requiring wireless headset s t o im plem ent t he TCS- BI N prot ocol ( as t he cordless t elephony and int ercom profiles call for) would be t oo burdensom e for headset s. For t he version 1.0 headset funct ion, only audio t ransfer ( which occurs direct ly over t he baseband link) and som e very sim ple cont rol funct ions are needed. TCS- BI N is excessive for t hese sim ple cont rol funct ions for headset s, so a m inim al set of AT com m ands was chosen for headset cont rol. These com m ands can be used over t he RFCOMM virt ual serial port as described in Chapt er 10. Thus headset s need only cont ain a m inim al im plem ent at ion of t he RFCOMM prot ocol, so t here is no requirem ent for t hem t o im plem ent t he TCS- BI N prot ocol. So we see t hat even t hough t hese t hree profiles exist on t wo different branches of t he prot ocolbased " profile fam ily t ree," t heir com m on bond is t hat of support ing som e form of voice t elephony. Each is concerned wit h t he rendering and t ransport ing of audio t raffic ( SCO packet s) over t he Bluet oot h air- int erface.

The Cordless Telephony Profile As already not ed, t he cordless t elephony profile, or CTP, defines t he " cordless phone" facet of t he t hree- in- one phone usage case, but m ore generically it defines cordless t elephony. The CTP not only allows a cellular t elephone t o use Bluet oot h t echnology for short - range wireless voice com m unicat ion, but it also addresses handset s t hat exclusively use Bluet oot h wireless com m unicat ion t o act only as cordless t elephones. These t elephones are not cellular phones; t hey are solely cordless handset s for use wit h a local base st at ion. The CTP also includes com put ers t hat could accom plish cordless t elephony using Bluet oot h wireless com m unicat ion, t hrough support for t he TCS- BI N prot ocol and audio t raffic m anagem ent using t he m icrophone and speakers of t he com put er. The cordless t elephony usage scenario drove m ost of t he requirem ent s for t he Bluet oot h t elephony cont rol prot ocol. Cordless t elephony int roduces t he not ion of t erm inal devices and gat eway devices and hence t he requirem ent for cont rol funct ions for t hese devices, such as group m anagem ent . Furt herm ore, cordless t elephony also int roduces t he need for reasonably sophist icat ed call cont rol funct ions. For exam ple, a base st at ion needs t o com m unicat e call cont rol inform at ion t o and from a rem ot e handset t o enable t he handset t o receive ring t ones for incom ing calls and t o dial t hrough t he base st at ion for out going calls. Finally, advanced feat ures found on m any exist ing cordless t elephones, like m ult iple handset s for a single base st at ion, speed dialing, direct ory and caller ident ificat ion inform at ion and so on drive t he expect at ion t hat t hese sam e sort s of feat ures can be accom m odat ed in Bluet oot h cordless t elephony. Thus t he funct ions required for cordless t elephony helped t o drive t he select ion of TCS- BI N, which is t he prim ary prot ocol used by t he CTP ( recall from Chapt er 10 t hat TCS- BI N provides call cont rol, group m anagem ent and connect ionless TCS funct ions, all of which are im port ant in sat isfying t he requirem ent s out lined above) .

CTP Development 144

Unt il March 1999 t here was only a single t hree- in- one phone profile t hat encom passed bot h cordless t elephony and int ercom funct ions. As t he profile developm ent progressed, t he SI G decided t o split t he cordless t elephony and int ercom funct ions int o t wo profiles because, as we observe above, t hese funct ions m ight be im plem ent ed independent ly. Bot h profiles t oday st ill st at e t hat t hey apply for devices im plem ent ing t he t hree- in- one phone usage case, but t hey also acknowledge t hat each addresses one specific funct ion of t hat usage case. Even t hough it is one of t he m ore involved profiles, t he CTP, at least in it s incarnat ion as t he t hree- in- one phone profile, was one of t he first t o be st art ed and t hus one of t he first t o m at ure and reach com plet ed st at us. [ 3] This is due at least part ly t o t he fact t hat t he t hree- in- one phone scenario requirem ent s had been st udied for quit e som e t im e and had result ed in t he select ion of TCS- BI N as t he t elephony cont rol prot ocol for t his scenario. Thus t he m apping of cordless t elephony funct ions back t o TCS- BI N ( which is what t he vast m aj orit y of t he CTP deals wit h) was rat her st raight forward. [3] Technically, nearly all of the profiles were completed, or formally ratified, at about the same time. But at that point some profiles had already been largely completed for some time while others were still being finalized.

CTP Examined The t hree- in- one phone usage scenario heavily influenced t he developm ent of TCS- BI N in t he prot ocol st ack, and t herefore t he CTP m akes heavy use of TCS- BI N. Most of t he CTP is devot ed t o TCS- BI N int eract ion. A st udy of t he TCS- BI N prot ocol is useful in underst anding bot h t he CTP and t he int ercom profile ( described below) . The CTP cont ains a det ailed descript ion of procedures and TCS- BI N m essages used in cordless t elephony applicat ions; t hese are not repeat ed here. I nst ead we highlight som e of t he key aspect s of t he CTP, including t he rat ionale for t hose design point s. The CTP first m akes t he im port ant dist inct ion of device roles, as eit her gat eway or t erm inal devices. Nearly all of t he rem ainder of t he CTP is based upon t his dist inct ion. I n general t he gat eway device can be viewed as t he " server" of a piconet ( and in fact is defined t o be t he piconet m ast er in m ost cases) , wit h various ot her devices, including cellular handset s, specialized cordless handset s and perhaps even com put ers or advanced headset s, [ 4] as " client s" of t he local voice net work ( piconet ) . Figure 13.1 illust rat es a cordless t elephony piconet ; a sim ilar figure exist s in t he profile specificat ion, but we include our own version, as we elaborat e on t he concept s and t erm inology shown here in following sect ions. [4]

In this case, such headsets would not be the same as those developed to comply with the headset profile, which is based upon the serial port profile. Cordless telephony headsets would functionally resemble handsets and would need to comply with the cordless telephony profile (instead of or in addition to the headset profile).

Figu r e 1 3 .1 . Cor dle ss t e le ph on y picon e t w it h ga t e w a y de vice a n d t e r m in a l de vice s.

145

Not e t hat because t he voice t elephony net work is a piconet , only seven slaves, or t erm inal devices, can be act ive at one t im e. This is st ill an im provem ent over m any of t oday's cordless t elephone syst em s, which oft en associat e only one handset wit h a single base st at ion. As t he CTP point s out , m ore t han seven t erm inal devices are possible; as one m ight expect , t his is accom plished t hrough t he use of parked slaves. Since t he gat eway is t he m ast er of t he piconet , it would be responsible for m anaging up t o seven act ive slaves versus som e num ber of parked slaves in t he case where t here are m ore t han seven t erm inal devices. To allow t he developm ent of gat eways wit h varying feat ures and com plexit y, m anaging m ore t han seven t erm inal devices is not m andat ed ( it is an opt ional capabilit y and t hus need not be im plem ent ed in every gat eway device) . The CTP is one case in which t he m ast er- slave role swit ch described in Chapt er 6 is used. The gat eway device is t he m ast er of t he piconet . New t erm inal devices ( perhaps a m obile phone t hat is brought int o t he hom e) are added t o t he piconet when t he new t erm inal device pages t he gat eway device ( base st at ion) . Once t he gat eway device accept s t he page, t he t erm inal device t hen, by default , becom es t he m ast er of t hat link. However, t his is t he opposit e of what is needed for norm al operat ion of t his voice piconet , so a m ast er- slave swit ch ( role reversal) m ust be perform ed im m ediat ely. One alt ernat ive t hat m ight have been used, which could have rem oved t he need for a m ast er- slave swit ch, is a m odel in which t he gat eway device pages t he t erm inal devices. For well- known t erm inal devices ( say, t hose handset s t hat are always associat ed wit h t he base st at ion) , t his m ight be a reasonable m et hod t o use. However, for t ransient devices t hat m ight need only t em porary access t o t he gat eway ( consider visit ors t o a hom e or office who m ight be grant ed t em porary use of t he gat eway, or a public voice access point t hat perm it s devices in proxim it y t o connect t o it ) , t he SI G chose a m odel in which t he client , or t erm inal device, init iat es a request t o connect t o a gat eway device. This m odel t akes int o account t he needs and desires of t he user of t he client device and seem s preferable t o a schem e in which a gat eway at t em pt s t o com m unicat e wit h every pot ent ial t erm inal device t hat m ight wander int o proxim it y; m any such devices m ight have no desire or even capabilit y t o part icipat e in t he voice net work. Thus t he process of j oining t he cordless t elephony piconet is client init iat ed and t herefore necessit at es a m ast er- slave role swit ch aft er a new m em ber j oins. An im port ant aspect of cordless t elephony is securit y. The CTP requires t hat all devices in t he voice piconet be aut hent icat ed. While one m ay wish t o allow a t rust ed friend t o have access t o one's own gat eway via t he friend's handset , one cert ainly wouldn't want t o offer t his capabilit y t o

146

any device t hat happened t o be in range, since access t o t he gat eway im plies t he abilit y t o m ake t elephone calls t hrough it . The CTP allows for only t rust ed t erm inal devices t o connect t o t he gat eway. [ 5] The CTP also calls for encrypt ion of all t he t raffic wit hin t he piconet . A com m on short com ing of very early cordless t elephone syst em s[ 6] was t he abilit y of ot hers t o easily eavesdrop on t he voice t raffic t ransferred over t he air. As not ed in Chapt er 1, t he FHSS nat ure of Bluet oot h com m unicat ions adds one degree of prot ect ion from eavesdropping, but t he use of t he encrypt ion inherent in t he t echnology enables even m ore secure com m unicat ion. [5]

Here is but one of many examples of the value of the common vocabulary of the GAP, discussed in the previous chapter. The CTP states that only trusted devices can connect to a gateway; without the GAP, which defines a trusted device, this term might be interpreted in different ways.

[6]

In the United States, 900 MHz cordless telephones (and similar systems such as baby monitors) without any encryption or spread spectrum capabilities were quite popular. With these systems it was easy to eavesdrop (intentionally or not) on conversations of neighbors. While many newer systems use spread spectrum, which can mitigate the eavesdropping problem, many older systems still remain in use.

When a CTP piconet is form ed, t here exist s a group of devices t hat all im plem ent t he TCS- BI N prot ocol ( since t his is necessary for conform ance t o t he CTP) . Recall from Chapt er 10 t hat when such a group of devices is form ed, a WUG ( wireless user group) can also be form ed t o m ake use of t he TCS- BI N prot ocol t o provide addit ional feat ures enabled by t he prot ocol. I n t he case of t he CTP, t he WUG is em ployed t o facilit at e use of cordless t elephony feat ures in a secure m anner. As would be expect ed, t he gat eway device act s as t he WUG m ast er ( in addit ion t o being m ast er of t he piconet ) . Because WUGs allow all part icipat ing devices t o be known t o and t o int eract wit h each ot her ( an addit ional capabilit y beyond t he point - t o- point m ast er- slave com m unicat ion) , cordless t elephony piconet s have som e unique advant ages. For exam ple, once a new device has been aut hent icat ed wit h t he gat eway ( m ast er) device, it need not aut hent icat e individually wit h every ot her WUG m em ber, since t he m ast er will by proxy aut hent icat e t he new device when it inform s all t he WUG m em bers t hat t he new device has j oined. This could be useful if t he device lat er init iat ed an int ercom conversat ion ( described below) wit h anot her m em ber of t he WUG. Not only would t he device know about all of t he ot her devices in t he WUG, it could easily est ablish direct com m unicat ion wit h any of t hem . When a t erm inal device connects t o t he gat eway, it est ablishes and m aint ains an L2CAP connect ion for as long as it rem ains in t he piconet . So, when a call is m ade or received, it is not necessary t o incur t he overhead involved t o est ablish a t ransport layer connect ion, which in som e cases could t ake up t o several seconds, t o process t he call. Only t he TCS- BI N prot ocol needs t o be init iat ed over t he already exist ing L2CAP connect ion.

CTP Usage Clearly t he sort s of applicat ions t hat im plem ent t he CTP would be t elephony applicat ions t hat m anage t elephone calls. While t he specificat ion does not define API s, TCS- BI N est ablishes a welldefined funct ional int erface for m aking and receiving calls and for t ransferring inform at ion like DTMF t ones or caller ident ificat ion dat a. Because TCS- BI N is based upon t he ETSI Q.931 st andard [ I TU98] , exist ing t elephony API s on m any plat form s should m ap easily t o t hose of TCS- BI N. The CTP adds m ore guidance t o t he t elephony applicat ion developer by specifying which of t hese call prim it ives are m andat ory and which are opt ional for Bluet oot h cordless t elephony. Applicat ions on devices claim ing t o conform t o t he CTP m ust at least im plem ent t he basic set of funct ions described in sect ion 2 of t he CTP ( t hese include on- hook, connect ion m anagem ent , out going and incom ing call m anagem ent and ot hers) . Som e m ore advanced feat ures are opt ional. And like all profiles, vendors can add t heir own different iat ing feat ures beyond t hose specified in t he profile. This is especially t rue in t he case of t he CTP, since it uses TCS- BI N, which includes t he connect ionless TCS feat ure described in Chapt er 10. This feat ure direct ly enables vendor- specific feat ures and ext ensions.

147

The Intercom Profile For convenience, we will cont inue our cust om of short hand not at ion for t he profiles. I n t he case of t he int ercom profile we use t he t erm I nt P ( rat her t han I P, which m ight be confused wit h I nt ernet Prot ocol and I P net working) . The I nt P is t he ot her profile t hat is based upon TCS- BI N, and it also defines t he final aspect of t he t hree- in- one phone scenario. I nt ercom , or " walkiet alkie" operat ion, generally is an easily underst ood concept , since it is a direct voice connect ion bet ween t wo devices t hat m any people have experienced. The int ercom profile is t hus unsurprisingly sim ple and st raight forward. Wit h t he int ercom profile, t wo devices t hat bot h support TCS- BI N can m ake a direct voice connect ion using t he Bluet oot h air- int erface, wit hout any t hird- part y carrier required. I n t he specificat ion t he I nt P includes a figure t hat shows such a connect ion bet ween t wo cellular phones. While t his is t he m ost obvious ( and probably m ost com m on) sit uat ion, ot her devices t hat have audio and TCS- BI N support could also part icipat e in t he int ercom usage m odel. As shown in Figure 13.1, specialized cordless handset s, CTP- com pliant advanced headset s and com put ers m ight all include audio and TCS- BI N prot ocols and t herefore could im plem ent t he I nt P. I n fact , one could build a t rue Bluet oot h walkie- t alkie t hat is dedicat ed solely t o t he int ercom scenario. [ 7] [7]

Although this is possible, it seems unlikely, since even with the optional radio the range of Bluetooth wireless communication is limited to 100 meters, which is less than that of existing walkie-talkies using other radio frequencies. The value of the intercom usage case is the utility it provides by adding another function to an existing device rather than enabling a new class of device.

IntP Development As not ed in t he preceding discussion of t he cordless t elephony profile, t he CTP and I nt P were split from a single t hree- in- one phone profile during profile developm ent . The I nt P is really a special case of cordless t elephony, and int ercom calls are st ill referenced in t he CTP, alt hough in t hese cases t hey refer t o t he I nt P for det ails. When t he hist ory of t hese profiles is known, it becom es quit e evident t hat t he CTP and t he I nt P are closely relat ed. From a st ruct ural point of view, t he t wo profiles m irror each ot her alm ost exact ly. Like t he CTP, t he I nt P was one of t he first profiles t o be st art ed and t hus one of t he first t o be com plet ed, or at least t o reach a level of st abilit y such t hat it was declared ready for publicat ion.

IntP Examined For t he int ercom usage case, t he I nt P indicat es t hat t here are no prescribed device roles. Unlike t he CTP, where it is im port ant t o define a m ast er ( gat eway) and slave ( t erm inal) device, t he devices in t he int ercom scenario are peers. Eit her device could be m ast er of t he piconet . There could have been m ult iple ways t o est ablish a direct voice link wit h Bluet oot h wireless com m unicat ion. The I nt P chooses t o m ake use of TCS- BI N for t his scenario, so t he int ercom funct ion is st ill very m uch a " t elephone call" sort of operat ion. Dat a flows as SCO packet s, which is t he norm for voice t raffic, and cont rol is provided via TCS- BI N. This cont rol m ight have been provided t hrough som e ot her m eans, but because TCS- BI N is used in t he CTP, which is also part of t he t hree- in- one phone usage m odel, t he use of TCS- BI N for t he I nt P is nat ural. Furt herm ore, TCS- BI N's group m anagem ent funct ions provide an environm ent in which it is relat ively easy t o est ablish an int ercom call. Through t he WUG enabled by TCS- BI N, each device in t he voice piconet is aware of every ot her device. I n addit ion, as a result of t heir aut hent icat ion wit h t he m ast er, all of t he devices are t rust ed by each ot her. Thus it is a st raight forward operat ion for one device t o locat e and est ablish a com m unicat ion link wit h any ot her device in t he WUG ( which overlaps ent irely wit h t he piconet ) t o perform an int ercom call. The m ast er need not be

148

involved; [ 8] any device can direct ly page any ot her device t o set up an int ercom call. Not e t hat t his m eans t hat t hese devices t em porarily leave t he exist ing piconet t o form t heir own new piconet , but rej oining t he original piconet is also m ade easier t hrough t he WUG/ TCS- BI N group m anagem ent funct ions. [8]

Except to set up the intercom paging scenario, as described in Chapter 10.

One im port ant aspect of t he int ercom usage case not addressed by t he I nt P is t hat of 10- m et er versus 100- m et er operat ion. As point ed out in Chapt er 3, t he int ercom scenario wit h t he st andard 0 dBm Bluet oot h radio is som ewhat unint erest ing. Wit h t he st andard radio's range of about 10 m et ers, t wo part ies who m ight use t he int ercom funct ion are likely t o be close enough t o each ot her t hat t hey can t alk wit hout t he benefit of radios. However, t here cert ainly are sit uat ions in which int ercom com m unicat ions are useful even wit h a 10- m et er range. Consider, for exam ple, t he part ies being on different floors of a house or an office, or perhaps needing t o com m unicat e wit h t he benefit of radios even when t hey have a line of sight bet ween t hem ( one exam ple of t he lat t er case given in Chapt er 3 is t hat of audio/ video t echnicians in a crowded audit orium during a conference present at ion) . However, int ercom com m unicat ions becom e even m ore int erest ing when t he 20 dBm opt ional radio wit h it s 100- m et er range is em ployed. The abilit y t o m ake a direct call t o anot her device wit hout using any t hird- part y carrier, and t hus wit hout incurring any airt im e usage charges, is quit e at t ract ive. Think about being able t o use your m obile phone t o cont act your spouse or friend in t heir seat at a crowded sport s arena while you are at t he concession st and, wit hout having t o dial t hrough your service provider. Ot her applicat ions could include t hose where m edium - range wireless voice com m unicat ion is used t oday—securit y and m aint enance workers, for exam ple, who need t o st ay in com m unicat ion wit hin a local area such as a hot el or sm all cam pus area. I n t hese cases, Bluet oot h wireless com m unicat ion m ight be used in place of ot her RF solut ions, one benefit being t hat a single device could be used bot h for t he local m edium - range RF voice com m unicat ion and for som e ot her funct ion ( such as a cellular phone or com put er usage) , obviat ing t he need t o carry anot her device j ust for wireless voice com m unicat ion.

IntP Usage An I nt P applicat ion is likely t o be part of a general cordless t elephony applicat ion. As previously not ed, it seem s unlikely t hat Bluet oot h devices dedicat ed exclusively t o funct ioning as int ercom s or walkie- t alkies will be prevalent . Thus it would seem unlikely t hat a separat e applicat ion dedicat ed t o int ercom funct ion would be developed. Since t he I nt P uses TCS- BI N, as does t he CTP, we would expect t hat a cordless t elephony applicat ion t hat im plem ent s t he CTP could be easily ext ended t o also incorporat e t he I nt P. I n fact , while t hese t wo profiles need not be im plem ent ed t oget her ( recall t hat t he SI G overt ly chose t o split t hem ) , in m any cases, such as in support of t he t hree- in- one phone usage m odel, it would m ake sense t o do so. As wit h t he CTP, t he I nt P provides guidelines for applicat ion developers, including opt ional versus m andat ory funct ions. As would be expect ed, t he int ercom funct ion specified by t he I nt P is relat ively sim ple and st raight forward, and in fact for t he m ost part is a subset of t he TCS- BI N funct ion t hat is needed t o realize t he CTP. This is anot her reason t o expect t he I nt P t o be im plem ent ed alongside t he CTP in m any cases—once t he CTP applicat ion is com plet e, nearly all of t he work required t o realize t he I nt P would also already have been com plet ed.

149

The Headset Profile For reasons previously st at ed, we consider t he headset profile, or HSP, t o be part of t he t elephony group of profiles, alt hough it should be reit erat ed t hat t he HSP is not direct ly relat ed t o t he I nt P or CTP. The HSP is a derivat ive of t he serial port profile; it is not one of t he TCS- BI Nrelat ed profiles. Nevert heless, t he HSP also addresses voice t raffic and it s cont rol. I n t he CTP discussion we not ed t hat one possibilit y for a cordless t elephony device was a headset . Such an advanced headset would need t o com ply wit h t he CTP, including support for all of t he required part s of TCS- BI N. I t would t end t o resem ble a t elephone handset from a funct ional point of view and would probably be m ore sophist icat ed t han t he t ype of headset t hat t he HSP deals wit h. A headset conform ing t o t he HSP need not im plem ent TCS- BI N at all; t he sim ple t elephony cont rol funct ions needed for an HSP headset are accom plished using AT t elephony cont rol over RFCOMM. Thus t he HSP defines a device t hat prim arily serves as an audio peripheral t o som e ot her device ( m ost popularly, but not exclusively, a t elephone) .

HSP Development Like t he ot her t elephony profiles, t he HSP was one of t he first t o be st art ed and t hus one of t he first t o reach st abilit y for version 1.0 publicat ion. The wireless headset , or ult im at e headset as it is called in t he Bluet oot h usage m odel ( see Chapt er 3) , has always been an im port ant scenario. The use of wireless headset s wit h m obile t elephones was one of t he driving forces behind t he invent ion of t he Bluet oot h t echnology. Even t hough t he HSP is not direct ly relat ed t o t he CTP and I nt P, it is evident from t he st ruct ure of t hese profiles t hat all were developed by t he sam e group of people. Once t he fundam ent al case of headset use wit h a m obile t elephone had been covered, t he profile was expanded t o cover t he com put er device class. A Bluet oot h headset could easily be used as t he source and dest inat ion for a Bluet oot h com put er's audio t raffic in t he sam e m anner as it is used wit h a phone, and t he profile acknowledges t his usage case. There was som e discussion of t he use of a headset wit h ot her devices ( as not ed in Chapt er 3, fut ure devices could include not only ot her t ypes of phones but also ot her t ypes of audio devices such as st ereos, port able m usic players and so on) . I n version 1.0, t he HSP does not address any headset usage ot her t han wit h a m obile t elephone or a com put er; but since t he specificat ion defines a st andard m et hod for audio t ransfer and cont rol, it is not expect ed t hat significant ly different operat ion would be required for ot her t ypes of devices. There is no part icular t echnical obst acle t hat prevent s t he use of a Bluet oot h headset wit h Bluet oot h devices ot her t han com put ers and t elephones, but t he HSP addresses j ust t hese lat t er t wo classes of devices in version 1.0 of t he specificat ion.

HSP Examined Of all t he version 1.0 profiles, t he HSP t arget s t he sim plest sort of device. I n fact , t he driving requirem ent s behind t he HSP included t he capabilit y t o develop a low- cost , sim ple and light weight headset . I f such a device is overburdened wit h funct ional requirem ent s t hat need sophist icat ed soft ware ( which in t urn requires m ore processing power and/ or on- board m em ory along wit h t he associat ed increase in power consum pt ion) , t hen a low- cost device becom es m ore difficult t o realize. This is one reason t hat t he HSP is based upon t he serial port profile rat her t han t he TCS- BI N prot ocol—TCS- BI N is robust and quit e useful for t elephony applicat ions, but a rich and full TCS- BI N im plem ent at ion could be relat ively expensive as com pared t o a sim ple RFCOMM im plem ent at ion. Moreover, TCS- BI N includes m uch m ore funct ion t han is needed for a headset as defined by t he HSP. Not e t hat t he headset device of t he HSP is quit e different from t he hypot het ical CTP- com pliant advanced headset depict ed in Figure 13.1. The HSP describes a

150

m uch sim pler headset t hat uses AT com m ands over an RFCOMM link, and t he HSP- st yle headset is expect ed t o be t he m ore prevalent device. Figure 13.2 illust rat es t ypical HSP operat ion.

Figu r e 1 3 .2 . Typica l h e a dse t pr ofile ope r a t ion .

The HSP does not prescribe any part icular role for t he headset or it s associat ed ( phone or com put er) device—eit her can be m ast er. [ 9] I t defines a gat eway device and a headset device, but unlike t he CTP it does not designat e eit her as m ast er. There are only a very few cont rol funct ions, including m aking a call ( it is assum ed t hat t he headset has som e m inim al user int erface, perhaps a but t on, t o init iat e a connect ion wit h t he associat ed gat eway device) , receiving a call and ( opt ionally) cont rolling volum e. Unlike t he I nt P and CTP, t hese funct ions are cont rolled via AT com m ands ( list ed in t he HSP) over RFCOMM rat her t han t hrough TCS- BI N PDUs. While t hey m ay overlap funct ionally, t hey are ent irely different m eans t o sim ilar ends. [9] There was a significant amount of debate in the SIG about this design choice. There are good arguments for denoting the headset both as master and as slave, depending upon the specific usage—either the headset or the associated device could initiate the communication; consider both outgoing and incoming calls. The final resolution was to leave the master/slave roles unspecified in the profile, leaving them to the choice of the implementers.

The HSP does not m andat e any level of securit y, leaving it up t o t he im plem ent at ion as t o whet her or not a secure connect ion ( including aut hent icat ion and encrypt ion) is used.

HSP Usage The headset is a specialized usage case. Most headset applicat ions are expect ed t o be em bedded in headset equipm ent . Wit hin a com put er or a t elephone, an applicat ion m ight support a headset peripheral, including t he capabilit y t o rout e audio for incom ing and out going calls t o and from t he headset and t o rem ot ely cont rol t he volum e, if t hat feat ure exist s. While t he HSP considers only headset funct ion, t he audio cont rol and rout ing used for headset s probably could be generalized t o ot her cases which are sim ilar but use different hardware—t hings like t he speaking lapt op usage case described in Chapt er 3 or audio rout ing t o ot her ext ernal syst em s like t hose in an aut om obile.

151

Chapter 14. The Serial and Object Exchange Profiles We call t his group t he serial profile fam ily, and it is com posed of t he serial port profile ( SPP) it self along wit h t he obj ect exchange class of profiles. The obj ect exchange group consist s of t he generic obj ect exchange profile, t he obj ect push profile, t he file t ransfer profile and t he synchronizat ion profile. To be sure, m any ot her profiles use t he SPP; in fact , m ost of t he version 1.0 profiles do. We include one such group in t his chapt er; ot her profiles t hat inherit from t he SPP are t reat ed in ot her chapt ers as part of ot her funct ional cat egories. I n fact , each of t he final t hree chapt ers of Part 3 includes at least one SPP- based profile. I n t his chapt er we discuss t he obj ect exchange profile fam ily and t he serial port profile it self. The SPP m aps direct ly t o t he RFCOMM prot ocol and t hus is used in m any cable- replacem ent usage scenarios. Because so m any of t he version 1.0 usage cases em ploy RFCOMM, t he SPP could be t he m ost widely im plem ent ed and used profile of all in early Bluet oot h device im plem ent at ions. Even t hough t he SPP it self does not em body a specific usage scenario, it enables m any of t hem . The obj ect exchange profiles ( generic obj ect exchange, obj ect push, file t ransfer and synchronizat ion) are likely t o be im plem ent ed in bot h com put ing and t elephony devices. Wherever I rDA devices are used, t he sam e applicat ions are likely t o apply in Bluet oot h environm ent s. Bluet oot h t echnology provides a convenient way for devices like not ebook com put ers t o exchange files, and obj ect exchange applicat ions like elect ronic business card exchange are likely t o be found wherever an elect ronic address book is kept —on PDAs, m obile phones and not ebook com put ers, for exam ple.

Relationships As shown in Figure 11.1 in Chapt er 11, t he serial port profile is t he root of m any profiles. Wit hin t he group of five profiles discussed here are t wo abst ract , or " parent " profiles, from which ot hers inherit . One of t hese is t he SPP, t he ot her t he GOEP, wit h t he lat t er descending from t he form er. The obj ect push, file t ransfer and synchronizat ion profiles all derive from t he abst ract GOEP, which addresses t he com m on use of OBEX operat ions t hat apply t o t hese t hree profiles. This group of profiles m aps t o t he I rDA int eroperabilit y layers of t he prot ocol st ack. I n t his chapt er we discuss only a subset of t he SPP fam ily, but t he RFCOMM serial port abst ract ion is also used for AT com m and t elephony cont rol in t he dial- up net working and fax profiles ( described in t he next chapt er) as well as in t he headset profile ( described in t he previous chapt er) ; t he serial port is also used t o enable a form of I P net working in t he LAN access profile ( also described in t he next chapt er) .

The Serial Port Profile The serial port profile, or SPP, is a t ransport prot ocol profile t hat defines t he fundam ent al operat ions necessary t o est ablish RFCOMM com m unicat ions bet ween t wo peer devices. Such a link is required for m any of t he concret e usage scenario profiles. I n t his respect t he SPP is som ewhat like t he GAP, in t hat it describes how t o est ablish necessary com m unicat ion links t hat are in t urn needed by ot her profiles. The SPP serves as a profile " building block."

152

SPP Development We observed in Chapt er 8 t hat t he RFCOMM specificat ion cont ains som e elem ent s t hat t ypically are found in profiles, so it seem s as t hough t he SPP was at least concept ually in developm ent since near t he beginning of t he SI G's exist ence. I t s com plet ion was neit her part icularly early nor part icularly lat e in t he profile developm ent cycle. The SPP was not always by design t he basis for so m any ot her profiles. Like t he SDAP and GAP, it was not im m ediat ely evident t hat a profile relat ing t o t he RFCOMM prot ocol layer was m erit ed. Even aft er it was creat ed, t he SPP originally was not t he basis for all ot her profiles t hat m ight use t he RFCOMM prot ocol. For inst ance, in March 1999 t here was st ill debat e as t o whet her or not t he obj ect exchange profiles discussed in t his chapt er would use t he SPP. At t hat t im e t he GOEP ( and it s derivat ives) all specified t heir own use of RFCOMM. The serial port profile exist ed but focused m ost ly upon t ransport ing AT com m ands for t he headset , fax and dial- up net working profiles and serving as a conduit for PPP for t he LAN access profile. When it was observed wit hin t he SI G t hat t he SPP m ight be a good basis for t he GOEP, t he differences bet ween t he GOEP and t he SPP, in t erm s of specificat ion and usage of t he RFCOMM prot ocol and relat ed st ack layers, were ident ified. The SPP was t hen updat ed t o accom m odat e t he GOEP usage of t he serial port abst ract ion as well. This is how t he SPP cam e t o be t he foundat ion for so m any ot her profiles.

SPP Examined SPP defines peer device roles for serial com m unicat ion. I t does not define a specific device role for m ast er or slave, nor does it define device roles for DTE/ DCE devices ( analogous t o t ypical wired serial com m unicat ion) . The devices are peers, and it does not m at t er which is m ast er and which is slave. I n fact , t he SPP j ust calls t hem " Device A" and " Device B," t he only dist inct ion being t hat Device A init iat es t he serial com m unicat ion link. The SPP furt her st at es t hat even t his dist inct ion is of lit t le consequence as far as t he profile is concerned. The SPP out lines t he st eps necessary t o est ablish an RFCOMM em ulat ed serial port connect ion; t hese are illust rat ed in Figure 14.1. I nt erest ingly, t hese are t he sort s of funct ions t hat one m ight expect t o find in a Bluet oot h adapt at ion layer of soft ware as described in Chapt er 5. That is, t he SPP describes precisely how t o use t he Bluet oot h prot ocols t o est ablish a virt ual serial connect ion; once t his connect ion is est ablished, serial dat a can flow across it . Thus for a legacy applicat ion t hat uses a serial port , t he funct ions described in t he SPP are j ust what is needed t o replace a wired serial int erface wit h a wireless one. Once t he procedure out lined in t he SPP is com plet ed, t he fact t hat a Bluet oot h em ulat ed serial connect ion is being used rat her t han a t radit ional wired serial connect ion should be t ransparent t o an applicat ion. I n fact , in t he SDP service record of t he SPP, t he exam ple service nam e shown is " COM5," an indicat ion t hat t he SPP could be used t o set up em ulat ed serial links for applicat ions expect ing t o use " COM" port - st yle int erfaces.

Figu r e 1 4 .1 . Typica l se r ia l por t pr ofile ope r t ion .

153

I n addit ion t o t he link m anager operat ions necessary t o est ablish a baseband link bet ween devices, SPP m akes specific m ent ion of t wo ot her prot ocol st ack layers needed t o est ablish t he RFCOMM link. The first , L2CAP, has already been m ent ioned. RFCOMM com m unicat es over L2CAP, and an L2CAP connect ion using t he RFCOMM PSM value m ust first be est ablished. The ot her prot ocol needed t o est ablish an RFCOMM channel is SDP. SDP is used in set t ing up an RFCOMM link, t o find t he appropriat e RFCOMM server channel [ 1] t o use. Server channels are used t o m ult iplex RFCOMM connect ions. SDP is used t o choose t he appropriat e server channel, which m ight correspond t o a given service ( som ewhat like " well- known port num bers" in TCP/ I P) . I n any case, t he service of int erest m ust specify t he appropriat e server channel num ber t o use t o connect t o t hat service. This channel is t he one used in t he result ing RFCOMM connect ion over which t he SPP operat es. Aft er t he server channel num ber is known, set t ing up t he RFCOMM connect ion is st raight forward: an L2CAP connect ion is est ablished, over which t he RFCOMM connect ion is est ablished. Opt ionally, t he devices m ight require som e degree of aut hent icat ion, and perhaps also encrypt ion, prior t o est ablishing t he links bet ween t hem . The SPP specifies t hat t hese securit y considerat ions are opt ional, because t he SPP is a generic profile upon which ot hers are built . Som e applicat ions t hat use t he SPP m ay require aut hent icat ion or encrypt ion ( which in t urn requires aut hent icat ion) while ot hers m ay not . The SPP leaves it t o t he m ore specific profiles t o describe securit y requirem ent s. [1]

Server channels are constructed using the DLCI values described in Chapter 8.

SPP Usage As an abst ract profile, t he SPP is m ore likely t o be used by m iddleware t han direct ly by applicat ions. Bluet oot h adapt at ion soft ware m ight use t he SPP t o inst ant iat e a virt ual serial connect ion for an applicat ion t hat expect s t o use serial com m unicat ions. The applicat ion need not know t hat t he serial port is an em ulat ed wireless one, so long as t he em ulat ion is sufficient ly accurat e. Thus applicat ions m ost likely will im plem ent som e ot her profile t hat m akes use of t he SPP— perhaps headset or dial- up net working. A device m ight support t he SPP generically in m iddleware. But an applicat ion is likely t o follow t he st andard procedures for a given plat form t o open, configure, m ake use of and close a serial connect ion, as opposed t o specifically following t he Bluet oot h prot ocol st ack m et hods for perform ing t hese funct ions. Thus it seem s likely t hat som e sort of plat form m iddleware will t ransform t he plat form API s int o t he corresponding funct ions of t he SPP necessary t o use RFCOMM over Bluet oot h t ransport s.

154

The Generic Object Exchange Profile Like t he SPP, t he generic obj ect exchange profile, or GOEP, is an abst ract profile upon which concret e usage case profiles can be built . I n t his case t he rem ainder of t he GOEP fam ily is t he set of I rDA int eroperabilit y profiles, nam ely file t ransfer, synchronizat ion and obj ect push, each of which is exam ined below. The GOEP defines all of t he elem ent s com m on t o t hese ot her t hree usage cases, including device roles, securit y considerat ions and how t he OBEX prot ocol is used in general.

GOEP Development The origin of what cam e t o be known as t he GOEP was t he synchronizat ion usage m odel. Since early in t he SI G's hist ory, synchronizat ion was t he driving force behind t he use of t he OBEX prot ocol and it s relat ed scenarios. I ndeed, synchronizat ion was one of t he original usage m odels, and t he group t hat produced t he I rDA int eroperabilit y prot ocols and profiles in t he SI G was called t he synchronizat ion working group during m ost of it s exist ence. The synchronizat ion usage case drove t he use of OBEX and I rMC; t he use of t hese prot ocols in t urn drove t he addit ional usage cases of elect ronic business card exchange ( represent ed in t he obj ect push profile) and obj ect t ransfer ( represent ed in t he file t ransfer profile) . Once t he I rDA OBEX m odel was chosen for synchronizat ion, it was evident t hat t he ot her usage m odels enabled by t he I rDA prot ocols applied t o t he Bluet oot h prot ocol st ack as well, so t he relevant ones were adopt ed ( result ing in t he t wo addit ional profiles described in t he sect ions t hat follow) . Furt her, t his select ion spawned t he whole idea of I rDA int eroperabilit y, which becam e t he cent ral t hem e of t his fam ily of profiles. So in t his case t he evolut ion was from t he specific cat egory of synchronizat ion t o t he broader cat egory of I rDA int eroperabilit y, including obj ect push and file t ransfer. During t his generalizat ion process t he GOEP was developed. As t he synchronizat ion, file t ransfer and obj ect push profiles progressed, it was evident t hat t hey shared a foundat ion of com m on elem ent s, especially t hose relat ed t o t he use of OBEX. These com m on elem ent s were gat hered int o t he GOEP.

GOEP Examined The GOEP defines very specific device roles for all OBEX- relat ed profiles. Unlike m any of t he ot her profiles, where t he devices act as peers and t here is lit t le dist inct ion bet ween t hem , t he GOEP and it s derivat ives define a client role and a server role. The client device is t he one t hat pushes or pulls obj ect s t o a server, while t he server is t he one t hat provides t he obj ect exchange service, which allow s t hose obj ect s t o be pushed t o and pulled from it . At one level, t his dist inct ion m ight not seem clear: if obj ect s are being exchanged, bot h sides m ay be pushing and pulling obj ect s from t he ot her, so a client or server role becom es som ewhat am biguous. However, in t he OBEX m odel, t here is a dist inct ion. While bot h devices can indeed push and pull obj ect s, it is t he client t hat init iat es t he operat ion and locat es a server wit h t he desired obj ect exchange service. Hence, t he client and server roles are significant in t he GOEP m odel. However, t his does not im ply any m ast er or slave role. The client and server roles are relevant at t he OBEX prot ocol layer, but t hey have no specified relat ionship t o a device m ast er or slave role; t he GOEP client could be eit her a m ast er or a slave device, as could t he GOEP server. The GOEP assum es a form of aut hent icat ion called bonding ( as defined in t he GAP) . To accom plish any of t he obj ect exchange usage m odels, t he t wo devices engaging in t he t ransact ions m ust be known t o and t rust ed by each ot her. All of t he obj ect exchange profiles

155

assum e t his t rust relat ionship. Addit ional form s of securit y, such as encrypt ion or applicat ionlevel aut hent icat ion ( beyond t hat done at t he Bluet oot h t ransport level) are opt ional. The GOEP defines t he prim it ives for obj ect exchange, t wo im port ant ones being obj ect push and obj ect pull. These operat ions are used in different com binat ions under different set s of circum st ances in all of t he obj ect push, file t ransfer and synchronizat ion profiles. The sim plest form of generic obj ect exchange, one- way dat a t ransfer, is inst ant iat ed in t he obj ect push profile. [ 2] Bidirect ional dat a exchange occurs in t he file t ransfer profile, which can be considered t o be a user- init iat ed obj ect exchange, and in t he synchronizat ion profile, which act s as a rules- based obj ect exchange. I n addit ion t o t he fundam ent al OBEX operat ions, t he GOEP defines how t o est ablish and t erm inat e OBEX connect ions and how t o use com m on OBEX funct ions. [2] As noted in the OPP discussion below, this is not always strictly one-way transfer but it is based upon a model of pushing data.

GOEP Usage Like t he SPP, t he GOEP is not expect ed t o be used direct ly by m ost applicat ions. I nst ead, it provides a foundat ion for ot her profile applicat ions. I n fact , t he set of I rDA int eroperabilit y prot ocols and profiles are int ended t o prom ot e int eroperabilit y at t he applicat ion layer for applicat ions t hat can use bot h I rDA and Bluet oot h t ransport s. Thus t here could be m any exist ing applicat ions t hat already im plem ent file t ransfer, obj ect push or synchronizat ion funct ions using OBEX. These applicat ions should run wit h lit t le or no change from I rDA t o Bluet oot h environm ent s. New applicat ions or m iddleware layers m ight im plem ent t he GOEP in support of accom plishing t he m ore concret e obj ect exchange profiles; however, it would be of lit t le value t o im plem ent j ust t he GOEP it self wit hout at least one ot her concret e profile. The GOEP is a set of com m on elem ent s t hat enable t he ot her obj ect exchange profiles, not a usage m odel unt o it self.

The Object Push Profile The obj ect push profile, or OPP, is t he sim plest of t he obj ect exchange profiles. As it s t it le im plies, it essent ially defines a one- way obj ect t ransfer, alt hough t his is som ewhat m isleading. The prim ary m ot ivat ion behind t he OPP is t hat of exchanging elect ronic business cards. OPP uses OBEX, as do all of t he obj ect exchange profiles. The vCard obj ect form at m ent ioned in Chapt er 9 can be used t o represent a business card t hat can be exchanged using t he OBEX prot ocol. Cert ainly ot her t ypes of obj ect s besides vCards ( including not es, m essages, calendar ent ries and in fact any obj ect t hat could be exchanged using OBEX) can be used wit h t he OPP, but t he rat ionale behind t he OPP is t he business card exchange usage m odel. The OPP assum es com pliance wit h t he GOEP and t hen furt her det ails t he scenarios, funct ions and applicat ion considerat ions associat ed wit h obj ect push. While it m akes allowances for pushing ( and in cert ain circum st ances pulling) generic obj ect s bet ween a client and a server, t he OPP focuses on pushing business card obj ect s.

OPP Development The OPP was t he last of t he obj ect exchange profiles t o be defined. Synchronizat ion and file t ransfer are fundam ent al usage m odels t hat have exist ed since t he SI G was form ed; t hus t hey were obvious profile candidat es. Originally only t hese t wo profiles were defined wit hin t he obj ect exchange fam ily. I t was not unt il January 1999 t hat t he SI G m ade a dist inct ion bet ween t wo t ypes of obj ect exchange: a sim ple obj ect push m odel and a folder- based browse, push and pull m odel. The form er support s a " business card exchange" usage scenario, and t his concept of

156

unidirect ional [ 3] obj ect t ransfer event ually grew t o becom e t he OPP, alt hough it was not originally called obj ect push. The folder- based file t ransfer m odel is em bodied in t he file t ransfer profile, discussed below. [3]

The previous footnote applies here also. The OPP can generally be thought of as a unidirectional object push, although limited object pulling is also possible, as explained in following sections.

One key difference bet ween t he OPP and t he file t ransfer profile is t hat t he OPP inst ant iat es a usage case in which dat a obj ect s m ight be offered in an unsolicit ed fashion. File t ransfer ( and synchronizat ion t oo) norm ally are m ot ivat ed by a desire of at least one part y t o acquire new or updat ed inform at ion, and t hey oft en involve user int ervent ion. Pushing obj ect s is a different m odel: at least one part y m ight offer dat a wit hout being asked, and t hat dat a is sim ply pushed t o a st at ic locat ion ( t hink of an in- box) wit hout any applicat ion knowledge of file or direct ory st ruct ure. I n som e sit uat ions, [ 4] a user m ight configure her device t o offer her elect ronic business card t o any ot her device t hat com es wit hin proxim it y and has t he abilit y t o t ake t he business card. [ 5] This aspect is unique t o t he OPP and was one of t he m ain reasons t hat business card exchange, or obj ect push in general, was developed as a separat e profile. [4]

Consider, for example, meetings and trade shows where business cards are xchanged; or any event at which a person miht register herself by providing information typically contained in a business card (name, address, telephone number and so on). [5] The OPP does warn against automating the object push operation, though, and suggests that user intervention should be required to initiate the object push and pull functions.

OPP Examined I nherit ing from t he GOEP, t he OPP defines a client and a server role, but furt her refines t hese roles t o t hose of a push client and a push server. Just as in t he GOEP, t he push server is t he device t hat provides t he obj ect exchange service, while t he client is t he device t hat does t he pushing ( and perhaps pulling) of obj ect s. Of course t hese operat ions can be viewed as sym m et ric, in t hat if one device is pulling an obj ect t he ot her device m ight be considered t o be pushing t hat sam e obj ect . As explained for t he GOEP, however, t he OBEX m odel does dist inguish bet ween a client and a server, and t he OPP m aint ains t his dist inct ion. As in t he GOEP, t he client and server roles do not im ply anyt hing about t he underlying baseband m ast er and slave roles. One of t he first concept s int roduced in t he OPP is t hat of pulling business cards, which for a profile dealing wit h pushing obj ect s m ight seem unusual. I ndeed, t he OPP t alks about push client s t hat can bot h push and pull obj ect s t o and from push servers; t his apparent dichot om y m erit s furt her explorat ion. The key is found in t he unique aspect of t he OPP, not ed above, t hat involves offering ( pushing) unsolicit ed dat a obj ect s. From t he viewpoint of t he push client , obj ect s are always being pushed t o a push server. I n fact , during t he errat a process of t he version 1.0 specificat ion, a clarificat ion was added t o t he OPP ( present in t he version 1.0B specificat ion) explicit ly st at ing t hat t he push operat ion involves t he client pushing an obj ect t o t he server. Yet t he sam e push client can also pull cert ain obj ect s, as described below, from t he push server. This concept is root ed in t he OBEX t ransact ion m odel, which has fundam ent al elem ent s of pushing and pulling obj ect s as well as t he not ion of a client and a server. One way t hat obj ect s m ight be exchanged only t hrough pushing is for a client t o push an obj ect t o a server, t hen have t he devices exchange roles, t hen have t he new client ( old server) push an obj ect t o t he new server ( old client ) . This would m aint ain a " push- only" purit y but seem s unnecessarily com plex, given t hat t he underlying prot ocol support s bot h push and pull operat ions. Thus OBEX and t he OPP allow a " push cent ric" usage m odel t hat also includes an opt im izat ion for pulling cert ain obj ect s from a push server, alt hough push servers are not required t o support t his feat ure. This opt im izat ion rem oves t he need for a client - server role swit ch while st ill perm it t ing t he idea of a push- based usage m odel.

157

The OPP defines t hree funct ions: obj ect push, business card pull and business card exchange. Obj ect push is, of course, t he fundam ent al operat ion and t he only m andat ory funct ion wit hin t he OPP. The ot her t wo funct ions are opt im izat ions of t he t ype not ed above, whereby t he underlying OBEX pull operat ion is used t o ext ract a specific obj ect , nam ely t he owner's business card, from t he push server. The pull operat ion is opt ional for push servers t o support ; not e t hat t he pull operat ion in t he OPP is rest rict ed t o pulling only owner business cards and not ot her obj ect s, while t he push operat ion can push any obj ect ( t he file t ransfer profile, discussed below, provides a m ore general bidirect ional obj ect exchange) . The business card exchange funct ion is really j ust a com posit ion of a business card obj ect push and a business card pull funct ion; t hus it t oo is opt ional. Figure 14.2 illust rat es t he t ypical operat ion of t he OPP.

Figu r e 1 4 .2 . Obj e ct pu sh pr ofile t ypica l ope r a t ion . N ot e t h a t bu sin e ss ca r d e x cha n ge is j u st a bu sin e ss ca r d pu sh a lon g w it h a bu sin e ss ca r d pull.

Wit hin t he OPP are t he procedures necessary t o accom plish each of t he obj ect push, business card pull and business card exchange funct ions. The obj ect push operat ion allows several t ypes of obj ect s t o be pushed from t he push client t o t he push server: vCard ( version 2.1 of vCard is required) , vCal, vMessage and vNot e. The SDP service record of t he OPP also allow s a value for " any t ype of obj ect ," which would perm it t wo devices t o exchange obj ect s ot her t han t hose not ed above, assum ing t hat bot h devices underst and t he obj ect form at t o be exchanged. The business card pull and business card exchange funct ions t ake advant age of t he OBEX default get obj ect , which is an obj ect t hat can be pulled by t ype rat her t han by nam e. By specifying t hat t he default get obj ect cont ains t he device owner's business card, t he special case of pulling t he default get obj ect allow s t he business card pull and exchange operat ions t o be accom plished wit hin t he cont ext of t he OPP. The final point discussed here about t he OPP is t hat of securit y. While exchanging obj ect s bet ween devices can be very useful, it also could be dangerous when one considers securit y exposures like viruses, violat ion of privacy and denial of service. All of t hese could be concerns if devices exchanged obj ect s wit hout any precaut ions. The OPP discusses at least t wo t ypes of securit y precaut ions: t he use of underlying Bluet oot h t ransport securit y and user int eract ion. The OPP indicat es t hat aut hent icat ion and encrypt ion at t he baseband level m ust be support ed, alt hough t hey need not be used for every t ransact ion. I n addit ion, bonding ( described in t he GAP) , which requires a t rust relat ionship bet ween t he t wo involved devices, m ust be support ed, but again need not be used for every t ransaction. I f used, t hese securit y feat ures can significant ly reduce t he exposures not ed above, since obj ect s can be exchanged securely, and only wit h devices t hat are known and t rust ed. Beyond t his, t he OPP m ent ions num erous t im es t hat user int ervent ion is recom m ended for m any of t he st eps required t o accom plish obj ect push and pull operat ions. The procedures in t he OPP t hat out line each of t he push, pull and exchange

158

funct ions all include st eps where it is recom m ended t hat t he user decide whet her or not t o accept an obj ect being pushed or t o allow an obj ect t o be pulled.

OPP Usage As discussed in t he GOEP sect ion above, m iddleware t hat im plem ent s t he GOEP can provide a foundat ion for applicat ions t hat im plem ent t he ot her obj ect exchange profiles. Since all of t hese profiles share t he com m on elem ent s of t he GOEP, it would not be uncom m on t o im plem ent synchronizat ion, file t ransfer and obj ect push all in t he sam e device. Much of t he code—t hat which inst ant iat es t he GOEP—could likely be reused in each of t he rem aining profiles. I n fact , t he OPP, from an applicat ion perspect ive, can be considered t o be a special case of file t ransfer. Like file t ransfer ( discussed below) , t he OPP pushes ( and perhaps pulls) obj ect s bet ween a client and a server. The OPP rest rict s t he t ypes of obj ect s t hat can be pushed and t he circum st ances under which specific obj ect s can be pulled, so in som e respect s[ 6] it is a subset or rest rict ed case of file t ransfer. Synchronizat ion ( also discussed below) could require significant addit ional logic beyond t he obj ect t ransfer funct ions, but file t ransfer and obj ect push, in m any cases, m ight be im plem ent ed in t he sam e applicat ion ( alt hough t he funct ions m ight be present ed t o t he user as t wo separat e applicat ions) . [6]

At least from an implementer's view, although perhaps not from an end user's view.

Applicat ion considerat ions for OPP include t he provision of a user int erface t o allow t he required user int ervent ion t o occur. The user is t he final arbit er of which obj ect s are perm it t ed t o be pushed ont o and pulled from his device, so t he applicat ion needs t o perm it t his sort of user int eract ion. Som e of t hese funct ions m ight be candidat es for int egrat ion wit h a general device cont rol applicat ion such as t he Bluet oot h piconet m inder applicat ion described in Chapt er 8.

The File Transfer Profile The file t ransfer profile, or FP, [ 7] is t he second of t he t hree profiles in t he obj ect exchange fam ily. Like synchronizat ion and obj ect push, t he FP uses OBEX t o exchange obj ect s, in t his case files and direct ories ( or folders) . During t he early phases of t he specificat ion developm ent , t he definit ion of TCP/ I P over Bluet oot h links was invest igat ed ( see t he discussion of OBEX over TCP/ I P in Chapt er 9) and t hus t he I ETF file t ransfer prot ocol ( FTP) was a candidat e for a file t ransfer profile. I n t he end, t he version 1.0 specificat ion did not address generic I P net working over Bluet oot h links, so FTP is not a part of t he version 1.0 file t ransfer profile, alt hough in t he fut ure t his alm ost cert ainly will be an alt ernat ive m et hod for file t ransfer. Wit hin t he version 1.0 realm , t hough, file and obj ect t ransfer is via OBEX. [7]

We use FP rather than FTP to remove any confusion with the Internet file transfer protocol.

The FP can be considered t o be a less rest rict ive, m ore robust form of t he OPP in t hat it support s full bidirect ional pushing and pulling of obj ect s, yet it support s only t wo obj ect t ypes: file and folder. The FP does not direct ly address exchanging ot her obj ect t ypes like vCard, vCal and so on, alt hough t hose obj ect t ypes could cert ainly be packaged as files and could be t ransferred using t he FP.

FP Development The OBEX prot ocol was originally adopt ed from t he I rDA t o support t he synchronizat ion usage m odel. But OBEX also support s general file t ransfer, which has been used in I rDA for som e t im e. File t ransfer has been a fundam ent al Bluet oot h usage scenario since t he SI G was form ed,

159

alt hough it originally fell under t he conference room scenario. As not ed in t he OPP discussion above, t he FP originally was an all- encom passing profile for obj ect exchange but event ually was split int o t he t wo dist inct applicat ions of obj ect push, covered in t he OPP, and folder- based browsing, pushing and pulling t hat rem ains in t he FP.

FP Examined Client and server roles are defined by t he FP in a m anner sim ilar t o t he ot her obj ect exchange profiles. I n t his case, t he client is t he device t hat init iat es t ransact ions and presum ably will be pulling files from t he server, alt hough t he client m ight also push obj ect s t o t he server as described below. The server is t he device t hat export s a folder t o t he client , which t he client can browse t o init iat e request s t o pull files ( or ot her folders) from t he server. The server also accept s ot her dat a from t he client , including files t hat t he client m ight push and request s t o creat e or delet e obj ect s on t he server. While t he client and server role definit ions are im port ant for execut ion of t he profile, m any of t he operat ions are sym m et ric, and it t herefore seem s likely t hat m any devices can and will im plem ent bot h client and server funct ions of t he FP. I ndeed, t he FP not es t hat a device can support eit her role or bot h. The operat ions defined by t he FP are t ypical file m anipulat ion operat ions, and t hey include: • • • • •

Pulling files and folders Pushing files and folders Browsing and navigat ing folders Delet ing files and folders Creat ing new files and folders

Each of t hese operat ions is described from t he client 's viewpoint . Server operat ions occur in response t o t he client operat ions, and include supplying request ed files and folders and responding t o request s t o delet e and creat e obj ect s. The folder browsing and file t ransfer ( pushing and pulling) operat ions are m andat ory for bot h client and server, and t hese allow t he sim plest form of file t ransfer, consist ing of pulling a folder ( t he descript ion, not t he ent ire cont ent s of all files in t he folder) , select ing one or m ore files in t hat folder, and pulling t hose files. Ot her operat ions t hat provide m ore advanced funct ions are opt ional; t hese include t he abilit y t o pull ent ire folder cont ent s ( which could be accom plished wit h an it erat ion t hat pulls all files in a folder, using j ust t he basic folder browsing and file pulling operat ions) and t he abilit y t o creat e and delet e obj ect s. The FP includes procedures t o follow for bot h client and server t o accom plish t hese operat ions, along wit h t he corresponding OBEX operat ions of t he GOEP used in t hose procedures. Figure 14.3 depict s t ypical FP operat ion; t wo different t ypes of devices are shown t o illust rat e t hat t his usage scenario is not rest rict ed only t o t radit ional com put ers. Any t wo devices wit h com pat ible file represent at ions could use t he FP for file t ransfer. [ 8] [8] Consider also devices such as digital cameras with distkette drives. Today pictures are transferred as files using the diskette. Since the camera must have a file system, the diskette drive could be removed and the files could be transferred using the Bluetooth FP.

Figu r e 1 4 .3 . Typica l file t r a n sfe r pr ofile ope r a t ion .

160

The FP assum es user int eract ion for all file t ransfer operat ions. I n addit ion t o m andat ory support ( but opt ional use) of aut hent icat ion and encrypt ion, t he FP m andat es user int ervent ion t o init iat e file t ransfers. As in t he OPP, securit y exposures could surface when files are m oved t o a new device. Therefore t he FP also requires user int ervent ion t o accept files from anot her device and t o pull files from ot her devices. The FP assum es t hat a user int erface will be present ed on a device as a result of pulling a folder descript ion. That user int erface allows t he user t o browse and select files t o pull; sim ilarly, local files can be browsed and select ed for pushing t o anot her device. So while t he prot ocol st ack includes securit y feat ures t hat can be used in file t ransfer operat ions, t he FP leaves t o t he end user t he ult im at e choice of which files t o accept .

FP Usage As described in t he OPP sect ion, it seem s likely t hat bot h OPP and FP m ight be im plem ent ed t oget her in m any devices. Once t he GOEP support is in place, t he addit ions needed t o support OPP and FPP are sim ilar, and indeed m ight use t he sam e code. As not ed in Chapt er 3, file t ransfer is one of t he m ost fundam ent al and useful funct ions of dat a net working. Many device m anufact urers believe t hat t ransferring files and ot her obj ect s is one of t he m ost im port ant scenarios t o support in wireless com m unicat ion, since m ost users are likely t o expect and m ake use of t his funct ion. Thus t he FP plays an im port ant role in helping t o ensure t hat file t ransfer can be accom plished in an int eroperable fashion using Bluet oot h t echnology. Most devices t hat are likely t o support t he FP already have a file syst em and som e sort of user int erface for t hat file syst em ; in addit ion t hey probably already include som e not ion of t ransferring files. While t he m echanism used m ay or m ay not include OBEX file t ransfer, im plem ent at ions of OBEX t hat m eet t he requirem ent s of t he GOEP can probably be procured or developed in a st raight forward m anner. Wit h GOEP- com pliant OBEX support in place, and wit h a Bluet oot h adapt at ion layer in t he device's soft ware st ack t hat perm it s t he use of Bluet oot h links, it should be possible in m ost cases t o link ( or perhaps adapt ) exist ing file syst em user int erfaces for use wit h t he Bluet oot h FP. An int egrat ed user int erface for FP ( and also for OPP) m ight include a Bluet oot h piconet m inder applicat ion like t hat described in Chapt er 8 t hat allows users t o select devices and services in proxim it y. One opt ion for a device t hat is select ed in t his way could be t o obt ain file folders from t hat device and init iat e file t ransfer ( or business card exchange in t he case of OPP as discussed above) . This seem s t o provide an easy, st raight forward and int uit ive m et hod for ext ending t he exist ing funct ions of a given device or plat form t o t ake advant age of Bluet oot h wireless com m unicat ion bet ween t wo cooperat ing devices.

161

The Synchronization Profile Synchronizat ion is a popular dat a com m unicat ions applicat ion and it has been one of t he Bluet oot h usage m odels since t he SI G was form ed. The final m em ber of t he obj ect exchange fam ily of profiles is t he synchronizat ion profile, or SP. The SP also builds upon t he GOEP and uses t he I rMC prot ocol t o synchronize obj ect s. Synchronizat ion can be considered t o be a special case of obj ect t ransfer in which program m at ic decisions about which obj ect s t o t ransfer in which direct ion are m ade by synchronizat ion soft ware logic. The act ual synchronizat ion process can range from very sim ple ( unidirect ional pushing or pulling of a group of obj ect s wit hout any special t reat m ent of t hose obj ect s) t o very involved ( select ive exchange of obj ect s or even part ial obj ect s using principles like differencing and conflict resolut ion) . Bluet oot h synchronizat ion as defined in t he SP t ends t o m ore closely resem ble t he form er, alt hough applicat ion logic can be added t o t he basic operat ions of t he SP t o achieve m ore sophist icat ed synchronizat ion m odels. Dat a can be synchronized bet ween any t wo [ 9] ent it ies, including devices and net works. [9]

In fact it is possible to synchronize data among more than two device, but we focus here on synchronizing between a pair of devices, which most closely matches the Bluetooth communication model.

SP Development Even t hough synchronizat ion is probably t he m ost com plex of t he obj ect exchange scenarios, t he developm ent of t he SP preceded t hat of t he FP and OPP. The group t hat developed t he I rDA int eroperabilit y prot ocols and t heir corresponding obj ect exchange profiles was known wit hin t he SI G as t he synchronizat ion group. Since t he SI G's beginnings, synchronizat ion am ong m any classes of devices ( phones, PDAs, not ebook com put ers and ot hers) has been a key usage case. I n m id- 1998, short ly aft er t he SI G's form at ion, t he possibilit ies for aut om at ed synchronizat ion ( described m ore fully in Chapt er 3) had already been ident ified and t he use of OBEX t o accom plish t hese scenarios had already been proposed. The incorporat ion of OBEX int o t he Bluet oot h prot ocol st ack was prim arily int ended t o support synchronizat ion but , as we have seen, it also perm it s business card exchange, file t ransfer and ot her obj ect t ransfer usage cases. A fundam ent al requirem ent was t o be able t o synchronize at least calendar and address book ent ries, alt hough we will see t hat ot her dat a t ypes can be synchronized as well. The synchronizat ion t ask force wit hin t he SI G was unusual ( alt hough not unique) in t hat , in addit ion t o t he five prom ot er com panies, ot her cont ribut ing adopt er com panies ( nam ely PUMATECH™ and Ext ended Syst em s™, bot h of whose prim ary business is in t he area of dat a synchronizat ion) part icipat ed in t he specificat ion's developm ent . Because synchronizat ion from t he out set was one of t he m ain usage m odels, t he SP was one of t he first profiles t o be developed. I t was not com plet ed any sooner t han m ost ot her profiles, t hough, owing m ost ly t o t he fact t hat new enhancem ent s t o t he profile ( like provision for aut om at ed synchronizat ion and t he addit ion of new and updat ed obj ect form at s) were added aft er it reached an init ial level of st abilit y. One int erest ing aspect of t he SP's developm ent is t hat it , along wit h t he ot her obj ect exchange profiles, was t he first t o add a sect ion on service discovery, wit h service record and SDP t ransact ion inform at ion. I n t his respect it served as a m odel for t he ot her profiles, all of which ( except for t he " generic" ones) cont ain such inform at ion in t he version 1.0 specificat ion.

SP Examined 162

The SP first defines device roles, which once again derive from t he GOEP and consist of a client and a server role. The client is t he device t hat pulls dat a from t he server, synchronizes t hat dat a against it s own local obj ect s, and pushes t he result ing synchronized dat a back t o t he server. The server m ust support an obj ect exchange service based upon t he GOEP. As wit h t he ot her obj ect exchange profiles, t hese roles have no bearing on t he underlying baseband m ast er and slave roles. The SP indicat es t hat t he server is usually a phone or a PDA, wit h t he client usually being a PC. This is curious, since servers t radit ionally are considered t o be t he m ore robust and capable m achines. For t he SP, it is t he client t hat m ust cont ain t he synchronizat ion logic t hat det erm ines how t o process t he obj ect s t o achieve a synchronized version of t hem . Thus t he SP describes a PC as a t ypical client , since a PC is m ore likely t o have available st orage and processing power t o operat e a synchronizat ion engine. However, t his need not be t he case—any device could t ake on t he role of client or server, as appropriat e. But t oday's t ypical synchronizat ion m odels usually synchronize a " sm all" server, such as a PDA or phone, against a " large" client like a PC or even a net work synchronizat ion service. This m odel is preserved in t he t ypical SP operat ion, which is illust rat ed in Figure 14.4.

Figu r e 1 4 .4 . Typica l syn ch r oniza t ion pr ofile ope r a t ion .

The SP does not direct ly address t he rules and processes necessary for a synchronizat ion engine t o act ually synchronize t he obj ect s wit h each ot her. I nst ead it defers t o t he I rMC specificat ion [ I rDA99b] for t hat level of det ail, since t here is no part icular reason t o m odify t hese aspect s of synchronizat ion for use in Bluet oot h environm ent s. I nst ead t he SP focuses on t he procedures needed t o init iat e and cont rol t he synchronizat ion process. The SP discusses bot h client - and server- init iat ed synchronizat ion and provides procedures t o follow for t hese. I n t he form er case t here are t wo dist inct scenarios: one for when t he t wo devices are not yet known t o each ot her and anot her for when t he devices have already bonded ( t hat is, are known t o and t rust ed by each ot her) . The second case is an opt im izat ion t hat t akes advant age of t he fact t hat t he devices have already bonded. Anot her procedure is supplied for aut om at ed synchronizat ion, which is a special case of client - init iat ed synchronizat ion t hat is st art ed wit hout user int ervent ion. Only bonded devices can synchronize aut om at ically. Several different obj ect t ypes can be synchronized using t he SP; t he profile does not m andat e which obj ect t ypes m ust be support ed. I nst ead it m andat es t hat at least one of t he defined obj ect t ypes—phonebook ( or address book) , calendar, not es and m essages—be able t o be synchronized. SDP is used t o discover t he support ed obj ect t ype( s) for t he synchronizat ion service. The SP relies heavily on t he GOEP and GAP, m aking use of several of t he definit ions and funct ions in each. I n part icular, som e of t he feat ures defined in t he GAP and GOEP are used for securit y. The SP m andat es one of t he highest securit y levels am ong all of t he version 1.0 profiles. I t rest rict s synchronizat ion t o bonded, or paired, devices and requires t he use of aut hent icat ion and encrypt ion. Furt her, t he OBEX- level aut hent icat ion discussed in t he GOEP opt ionally m ay also be

163

used. Unlike t he FP and OPP, t he SP does not call for user int ervent ion as a securit y m easure. A user m ay init iat e t he synchronizat ion t ransact ion ( alt hough in t he case of aut om at ed synchronizat ion, even t his user int eract ion is unnecessary) and m ay be inform ed of t he st at us and result s of t he synchronizat ion operat ion, and m ight even be consult ed about desired act ions ( say, for conflict resolut ion) during synchronizat ion. But t he user t ypically does not aut horize individual pushes and pulls of obj ect s as in t he FP and OPP ( alt hough t he user m ight ident ify a set or class of obj ect s t hat are t o be synchronized) . Since t he SP does not rely on t he user as a securit y arbit er, it specifies a relat ively high level of ot her securit y funct ions from t he prot ocol st ack.

SP Usage Synchronizat ion is a som ewhat specialized applicat ion, alt hough a popular one. I t is a bit different from file t ransfer and obj ect push, alt hough t he SP uses m any of t he sam e underlying const ruct s and funct ions t hat t he FP and OPP use. Since t he SP builds upon t he GOEP, an SP im plem ent at ion could reuse OBEX m iddleware t hat is also used for FP and OPP. But unlike FP and OPP, which could be very sim ilar ( if not t he sam e) applicat ions, SP would not necessarily be expect ed t o be im plem ent ed on all of t he devices where FP and OPP are im plem ent ed. A digit al cam era, for exam ple, m ight im plem ent a file t ransfer funct ion, as described in foot not e 94 above, but t he synchronizat ion funct ion on a cam era seem s less likely. As t he SP not es, t he devices m ost likely t o use synchronizat ion are not ebook com put ers, phones and PDAs; t hese are devices t hat t ypically cont ain address books, appoint m ent s and ot her inform at ion ( oft en called " PI M" or personal inform at ion m anagem ent funct ions) . The SP does not provide any det ailed descript ion of t he synchronizat ion process it self; applicat ions m ust look t o t he I rMC specificat ion for guidance. Even beyond what is specified by I rMC, t hough, t here is room for applicat ion different iat ion. Synchronizat ion applicat ions can add value t hrough enhanced user int erfaces, opt im ized m et hods for exchanging and synchronizing obj ect s and t he like. I n t he case of aut om at ed synchronizat ion t hat is enabled by Bluet oot h proxim it y net working, an applicat ion is st ill required, even t hough it m ay not be visible t o t he user at t he t im e synchronizat ion is perform ed. First , a user presum ably will wish t o configure his device for aut om at ed synchronizat ion ( j ust because t his funct ion is possible does not m ean t hat every user will wish t o t ake advant age of it ; som e users m ight want t o use t his feat ure select ively) . I n addit ion, som e applicat ion soft ware is needed on bot h t he client and t he server t o discover t he aut om at ed synchronizat ion capabilit y and t o st art and carry out t he synchronizat ion operat ion. I n m any sit uat ions it is also advisable t o provide som e sort of indicat ion t o t he user t hat t he aut om at ed synchronizat ion is underway ( t his probably should at least be a user- configurable opt ion, because m any users are uncom fort able having t heir personal devices engage in nont rivial com m unicat ions wit h ot her devices wit hout t heir knowledge) . A final applicat ion considerat ion in t he case of aut om at ed synchronizat ion [ 10] is how t o deal wit h a device t hat leaves t he proxim it y range before t he synchronizat ion operat ion com plet es. Consider a case where a user walks int o an office wit h a PDA in a pocket or purse. I f appropriat ely configured, t he PDA m ight begin synchronizat ion wit h a PC in t he office wit hout t he user being aware of it . The user m ight leave t he office in t he m iddle of t he synchronizat ion process. Thus t he synchronizat ion applicat ion needs t o som ehow account for t his possibilit y, perhaps t hrough a checkpoint and rest art process of part ial synchronizat ion or som e ot her m eans. [10] This consideration also applies for user-initiated synchronization, but less so. When a user initiates synchronization, she is probably likely to ensure that the devices being synchronized remain in range of each other until the operation completes. When the synchronization is started automatically, however, a user might not even be aware that it is occurring (see "Hidden Computing" in Chapter 3) and thus might very well walk into and then back out of proximity range before synchronization completes.

164

Chapter 15. The Networking Profiles The final group of version 1.0 profiles is what we t erm t he net working profiles. This group consist s of t he LAN access, dial- up net working and fax profiles. As not ed in t he preceding chapt ers, each profile includes t he aspect of a serial port , and t he dial- up net working and fax profiles include an elem ent of t elephony. But t o our way of t hinking t he prim ary focus of t hese profiles is on m ult ihop ( long- haul) dat a com m unicat ions and net working. Clearly bot h dial- up net working and LAN access are int ended t o facilit at e dat a net working, and t he fax profile seem s t o have m ore in com m on wit h dat a net working ( especially of t he dial- up kind) t han it does wit h voice t elephony. All of t he profiles in t his group include an elem ent of access t o a wide area net work for dat a com m unicat ion. All t hree of t hese profiles are int ended t o t ake advant age of Bluet oot h wireless com m unicat ion t o m ake a well- known exist ing t ask easier by rem oving t he need for cables. Using a fax or accessing a net work, eit her direct ly or t hrough a dial- up connect ion, are com m on t asks for m any people. The profiles exam ined here define how t o do t hese t asks in Bluet oot h environm ent s, wit hout wires. Each of t hese profiles, being m ore orient ed t o dat a t han t o voice, t ends t o be cent ered m ore around a com put er of som e sort t han around a phone. However, j ust as t he t elephony profiles were applicable m ost ly t o phones but also had aspect s relevant t o com put ers, t he net working profiles are m ost ly for com put ers but also have aspect s relevant for phones. I ndeed, t he dial- up net working and fax profiles can include bot h a com put er and a m obile t elephone, wit h t he phone being used as a fax or dat a m odem . So t hese profiles are expect ed t o be m ost useful for, and m ost oft en im plem ent ed by, com put ers ( st at ionary as well as m obile) , but m obile t elephones can provide services t hat gain t hem a key role in som e inst ances of t hese profiles.

Relationships As shown in t he profile relat ionships diagram ( refer back t o Figure 11.1) , all t hree of t hese profiles derive from t he serial port profile, or SPP, t hat was described in t he previous chapt er. This is not surprising, since t he SPP and it s associat ed RFCOMM prot ocol are int ended t o allow legacy applicat ions t o m ake use of Bluet oot h wireless t ransport s, and all t hree of t hese profiles inst ant iat e legacy applicat ions ( t hat is, t hey define how t o do exist ing t asks wit hout wires) . So t hese profiles are a logical fit as m em bers of t he SPP fam ily, which is t he basis for t he version 1.0 cable- replacem ent scenarios. They are also a good fit wit h t he SPP t echnically, since all t hree profiles involve applicat ions t hat m ost likely will include t he not ion of com m unicat ing over a serial port . I n t he case of dial- up net working and fax, t he use of a serial int erface is obvious, since bot h use a m odem ( or at least t he abst ract ion of a m odem ) t o com m unicat e over a t elephony net work, and t he m ost prevalent way t o access nearly all m odem s is via a serial port . I n t he case of LAN access, t he use of t he serial int erface m ight not be direct ly evident , since a direct net work access cable is not necessarily m odeled on a serial port . However, since t he version 1.0 LAN access profile uses t he point - t o- point prot ocol ( PPP) , t his sort of LAN access t ends t o resem ble dial- up net working, and PPP m aps well t o a serial com m unicat ion layer. Thus all t hree of t he profiles derive from t he SPP and use a serial port com m unicat ion m odel. The dial- up net working and LAN access profiles t oget her m ake up t he I nt ernet bridge usage m odel. As described in Chapt er 3, t wo sim ilar yet different m et hods are defined for using Bluet oot h links as a bridge t o a larger net work like t he I nt ernet . Those t wo m et hods are defined by t he dial- up net working and LAN access profiles, respect ively. Curiously, t he fax profile has no specific publicized usage m odel behind it . So in a way t he fax profile is not relat ed t o any of t he ot her version 1.0 profiles except in being part of t he SPP fam ily t ree. I ndeed t he fax profile is an exam ple of t he SI G's defining a form al specificat ion for t he use of Bluet oot h links t o perform

165

easily underst ood usage m odels. I n t his respect t he fax profile m ight be m ore sim ilar t o a print ing or scanning profile, neit her of which exist s in t he version 1.0 specificat ion alt hough t hey m ight be generat ed in t he fut ure. Since it does not derive from a com m on usage case, t he fax profile is relat ed only indirect ly t o any ot her version 1.0 profiles. I t does, t hough, have som e sim ilarit ies wit h t he ot her t wo net working profiles discussed in t his chapt er, which is why we include it here.

The Dial-Up Networking Profile The dial- up net working profile, or DUNP, specifically calls for bot h com put ing and t elephony devices. I ndeed, dial- up net working is an area where com put ing and com m unicat ions overlap. I n t his case t elephony devices access t elephone net works so t hat com put ing devices can use t hat connect ion t o access dat a net works. As com pared t o a t ypical wired scenario, t he use of Bluet oot h wireless com m unicat ion could enable t wo kinds of cables t o be replaced: one bet ween t he com put er and t he t elephone and one bet ween t he t elephone and t he t elephone line ( assum ing t he use of a cellular m obile phone in t he DUNP) . Dial- up net working is possible wit h m any m obile t elephones t oday, wit hout t he use of Bluet oot h t echnology, but norm ally a cable is needed bet ween t he com put er and t he t elephone, even t hough t he wide area net work access via t he m obile phone is wireless. The use of Bluet oot h wireless com m unicat ion rem oves t he need for t his last cable in dial- up net working, enabling a com plet ely wireless[ 1] solut ion. [1]

No cables are needed for communications. We ignore wires that may be needed to supply electrical power, since most mobile devices can operate for some period of time untethered from an electrical power supply.

Dial- up net working involves t he use of a t elephone—in t his case a m obile phone wit h Bluet oot h t echnology—as a dat a m odem . The com put er uses t he m odem service of t he t elephone ( probably unaware t hat a physical wired m odem is not present ) along wit h net work dialing soft ware t o reach t he net work's access point t hat is connect ed t o t he ( probably wired) t elephone net work. The DUNP even explicit ly addresses t he use of a physical m odem , rat her t han a m obile t elephone wit h a m odem service, t o perform dial- up net working. I n t his case such a m odem would presum ably be connect ed t o a wired t elephone line while providing a wireless Bluet oot h link t o it s client ( s) . I n t his respect such a m odem would resem ble a voice or dat a access point ( as are used in t he cordless t elephony and LAN access profiles, respect ively) in t hat it offers a specific t ype of wireless access t o som e back- end net work. Regardless of t he physical device used, t he com put er is using a m odem service t o access a t radit ional t elephone net work t hat in t urn offers access t o a dat a net work such as t he I nt ernet .

DUNP Development The evolut ion of t he DUNP ( and it s associat ed profile, t he LAN access profile) is int erest ing. Originally t here was a single I nt ernet bridge profile, j ust as t here is an I nt ernet bridge usage m odel. As t he m arket ing requirem ent s docum ent ( MRD) was refined and addit ional t hought was given t o t he t opic of net work access, t wo t ypes of net work access dist inguished t hem selves. The MRD defined t he concept of dat a access point s and split t hese int o t wo t ypes: wide area net work access, using m odem s, sat ellit es, cellular net works and t he like; and local area net work access, using an access point t o direct ly connect t o an Et hernet , t oken- ring or sim ilar LAN. At first t he I nt ernet bridge profile at t em pt ed t o cover bot h of t hese t ypes of dat a net work access. I t lat er becam e clear t hat t he t wo scenarios, while sim ilar from an end- user perspect ive ( and t hus bot h considered t o be part of t he I nt ernet bridge usage case) , had different t echnical underpinnings and would probably require quit e different im plem ent at ions in devices. Thus t he I nt ernet bridge profile ( like t he t hree- in- one phone profile discussed in Chapt er 13) was split int o it s t wo const it uent part s: dial- up net working ( now t he DUNP) and LAN access ( discussed below) . The DUNP was developed by t he t elephony cont rol t ask force wit hin t he SI G, since m uch of t he profile dealt wit h t elephone call cont rol ( recall t hat at t his t im e a t elephony cont rol prot ocol called

166

TCS- AT st ill exist ed—Chapt er 10 discusses t his t opic furt her—and m uch of t he DUNP deals wit h AT com m ands over RFCOMM t o set up and m anage t he m odem service) . The LAN access profile, on t he ot her hand, was developed by t he SI G's net working t ask force, since t elephony was not really relevant t o t hat profile. Even t hough bot h of t hese profiles spring from a com m on usage m odel and t hey do have som e t echnical sim ilarit ies, t hey also have som e differences at t he im plem ent at ion level.

DUNP Examined The DUNP defines device roles for a gat eway device and a dat a t erm inal device. The gat eway is t he device t hat offers a m odem service t o allow connect ion t o t he net work t hat is being accessed; gat eways t ypically are m odem s or m obile t elephones. The dat a t erm inal is t he device, usually a com put er of som e sort , t hat is using t he m odem service of t he gat eway device t o access a dat a net work. While dial- up net working is usually t hought of from t he viewpoint of t he dat a t erm inal device accessing a net work, t he DUNP also not es t hat t he reverse sit uat ion t hat allows t he dat a t erm inal device t o be dialed up via t he m odem device is also support ed. Norm ally t he dat a t erm inal device wishes t o obt ain access t o a net work, rat her t han t o perm it dial- up access t o it self, alt hough t here are cases where t he DUNP m ight be used for incom ing connect ions. These gat eway and dat a t erm inal device roles have no im plicat ions for t he baseband m ast er or slave roles. Recall t hat while we consider t he DUNP t o be part of a net working group of profiles, it is a derivat ive of t he serial port profile. The RFCOMM prot ocol is used t o t ransport m odem AT com m ands bet ween t he dat a t erm inal ( com put er) device and t he gat eway ( phone or m odem ) device t o est ablish and m anage t he connect ion t o t he net work. The DUNP ident ifies a sm all subset of st andard AT com m ands as defined in t he I TU- T V.250 st andard [ I TU99] t hat are used t o set up and m anage t he m odem funct ions of t he gat eway device. The DUNP addresses opt ional support for audio feedback. While it s prim ary purpose is t o support dat a calls, t he audio capabilit ies of Bluet oot h wireless com m unicat ion perm it a richer em ulat ion of a wireline m odem call by allowing for audio feedback. I f audio feedback is support ed, t he m odem t ones associat ed wit h t he call can be t ransm it t ed back t o t he dat a t erm inal device for playback t hrough it s audio out put channel. Audio feedback can provide inform at ion t o t he end user about t he call's progress, allowing t he " squeaks and squawks" t hat m any users have becom e accust om ed t o wit h dial- up net working also t o be present , if desired, when using Bluet oot h wireless links. The service record of t he gat eway's m odem ( dial- up net working) service indicat es whet her or not audio feedback is support ed, so SDP can be used t o det erm ine whet her or not t his feat ure is available when t he connect ion bet ween t he gat eway and dat a t erm inal is est ablished. Typical DUNP operat ion, including opt ional audio feedback, is depict ed in Figure 15.1.

Figu r e 1 5 .1 . Typica l dia l- u p n e t w or k in g pr ofile ope r a t ion . N ot e t h a t t h e ga t e w a y de vice a lso cou ld be a w ir e le ss m ode m a cce ss poin t con n e ct e d t o a w ir e d t e le ph on e n e t w or k .

167

Securit y in t he DUNP is handled at several levels. Support for baseband pairing is m andat ory, alt hough it need not be used for every connect ion. However, since t he m ost com m on case of dialup net working wit h Bluet oot h t echnology is likely t o be a com put er using a m obile phone t o access t he net work, charges are likely t o be incurred from t he phone service provider for t he wide- area cellular connect ion of t he phone call. Thus pairing is advisable, since it can rest rict use of t he phone's m odem service t o known and t rust ed devices. A phone's owner m ay wish t o m ake his phone's m odem service available t o his own com put er( s) but probably not t o anyone else's com put er t hat happens t o be in range. The DUNP also calls for t he use of baseband aut hent icat ion and encrypt ion funct ions. At an applicat ion level, addit ional aut hent icat ion such as a user ident ifier and password are likely t o be required t o access t he net work, once a connect ion t o it is est ablished.

DUNP Usage The int ent of t he DUNP, like t hat of m ost ot her serial profile fam ily m em bers, is t o enable legacy applicat ions t o t ake advant age of Bluet oot h wireless links for exist ing funct ions. Dial- up net working is a com m on usage scenario, wit h m any applicat ions available for using m odem s t o access net works. Through t he use of RFCOMM serial port em ulat ion and a m inim al subset of wellknown and st andard AT com m ands, t he DUNP provides dialer applicat ions wit h a funct ional int erface t hat is virt ually ident ical t o t hat which t hey use in t he wired world. Wit h t he use of Bluet oot h adapt at ion soft ware, as described in Chapt er 5, it should be possible for legacy applicat ions t o conform t o t he DUNP wit h lit t le, if any, change. Once dialing soft ware has est ablished t he connect ion t o t he net work, m ult it udes of applicat ions t hat use st andard net working prot ocols ( like TCP/ I P, HTTP, FTP and so on) can execut e using t he dial- up net work link and t he services available in t he net work. Hence t he DUNP enables ot her applicat ions such as browsers, e- m ail and t he like. For m ore inform at ion about how t he DUNP is used and how it relat es t o t he LAN access profile, discussed below, see t he following sect ion " DUNP and LAP Com pared."

168

The LAN Access Profile The LAN access profile, or LAP, is t he second profile t hat , along wit h t he DUNP, inst ant iat es t he I nt ernet bridge usage case. Like t he DUNP, it uses est ablished net working prot ocols over a Bluet oot h wireless link t o enable a com put ing device t o obt ain access t o a dat a net work. I n t he case of t he LAP, a net work dat a access point is used t o connect t o t he net work rat her t han a phone or m odem used wit h a dial- up connect ion. Use of t he LAP is analogous t o direct ly connect ing t o a dat a net work wit h an Et hernet ( or sim ilar) cable, alt hough t he usage is rest rict ed t o t he use of t he I ETF point - t o- point prot ocol, or PPP, over t he Bluet oot h link. Like t he DUNP, t he LAP is based upon t he SPP and is aim ed at cable replacem ent . I n t his case t he net work access is local area, rat her t han wide area as in t he DUNP. The LAP not es t hat t his version 1.0 profile defines j ust one m et hod for accessing net works via dat a access point s, wit h ot hers likely in t he fut ure ( Chapt er 16 describes som e ot her Bluet oot h LAN access possibilit ies) . The m ost com m only described usage case for t he LAP is for a com put er t o access a LAN, alt hough t he LAP does enable t he developm ent of dat a access point s t hat could be used sim ult aneously by m ult iple Bluet oot h client s. A specialized case of t he LAP is it s use t o direct ly connect t wo devices for PPP com m unicat ion bet ween t hem rat her t han t o access a larger net work.

LAP Development As not ed in t he DUNP discussion, t he LAP was originally part of a single I nt ernet bridge profile. When t hat profile was split , t he LAP was developed by t he SI G's net working t ask force. Even t hough t he LAP and t he DUNP bot h describe a m et hod of realizing t he I nt ernet bridge usage case, t hey have som e t echnical differences, because dial- up net working is a bit different from direct LAN access using PPP. [ 2] [2] Although, as the LAP notes, once a PPP connection is established between two devices, further interaction can occur much as it does for dial-up networking, which in turn often uses PPP internally.

The net working t ask force in t he SI G was at one t im e called t he TCP/ I P t ask force, since it s original m ission was t o define m et hods for t radit ional I P net working in Bluet oot h environm ent s. The group lat er decided t hat a m ore appropriat e nam e for t he t ask force was Bluet oot h net working, since not all of t he net working considerat ions were relat ed t o TCP/ I P, alt hough clearly I P net working is especially im port ant . Unlike m ost ot her t ask forces, t his group did not define any prot ocols in t he st ack but rat her invest igat ed ways t o use t radit ional net working prot ocols, such as t hose defined by t he I ETF, over Bluet oot h links. Thus t here is no corresponding prot ocol st ack layer in t he core specificat ion for t he LAP. I t is only t his profile t hat defines LAN access wit h Bluet oot h wireless com m unicat ion, and it uses t he RFCOMM prot ocol and t he I ETF's PPP. The LAP form s an im port ant foundat ion for m ore robust fut ure net working profiles, and it has always been considered t o be an init ial solut ion, but not an exclusive solut ion, for Bluet oot h net working. At first glance, it m ight appear t hat t he solut ion developed by t he net working group for LAN access is not as robust as m ight be expect ed, especially for peer- t o- peer com m unicat ion in LAN environm ent s. However, t he group's choice was not m ade light ly. This direct ion was chosen aft er long deliberat ions t hat considered t he feasibilit y of ot her solut ions, t he t im e t o m arket , and t he t im e const raint s for developing and publishing t he version 1.0 specificat ion. Peer- t o- peer com m unicat ion in purely ad hoc, wireless net works is an area t hat is not yet m at ure. While m any indust ry and academ ic effort s are underway, t here is no robust , fully t est ed, widely accept ed m et hod for achieving it , especially one t hat is suit able for resource- const rained devices like m any of t hose used in Bluet oot h wireless com m unicat ion.

169

The SI G's net working group seriously cont em plat ed I P net working issues like address assignm ent , nam e resolut ion, default rout er assignm ent , and so on. I n an ad hoc net work wit h no infrast ruct ure services such as DNS and DHCP, t hese and ot her necessary net work support operat ions present unique problem s. I t becam e apparent t hat a solut ion t o t hese problem s could have a scope larger t han j ust Bluet oot h piconet s. Had t he SI G at t em pt ed t o develop a general solut ion, it very likely would not have aligned wit h ot her indust ry act ivit ies t hat are proceeding t oward m at urit y; furt herm ore, any such solut ion would have required prohibit ive t im e invest m ent s in developm ent and t est ing. Thus, a general solut ion t hat addresses t he difficult issues associat ed wit h ad hoc I P net working ( and t hat would enable several aspect s of t he conference t able usage case described in Chapt er 3) was deferred unt il aft er version 1.0. I nst ead, t he net working group focused on developing t he PPP- based LAN access solut ion—for t wo reasons: ( 1) PPP is a widely used I nt ernet st andard t hat addresses host configurat ion and preparat ion for I P com m unicat ions; and ( 2) m any devices, including popular PDAs, t oday support I P com m unicat ions over PPP for dial- up access t o I P net works. Hence, a large num ber of com put ing devices can support t he Bluet oot h LAN access profile wit hout m odificat ion t o t heir inst alled net working st ack—a considerat ion t hat should not be overlooked. Support for m ore general ad hoc peer- t o- peer net working is an issue revisit ed by t he SI G, as discussed in Chapt er 16.

LAP Examined The LAP defines device roles of a LAN access point and a dat a t erm inal. The LAN access point ( which is j ust different t erm inology for a dat a access point ; we use t he lat t er t erm ) is t he device t hat export s PPP server funct ion and is connect ed t o a LAN, which m ight be Et hernet , t oken- ring or som e ot her t ype of LAN. [ 3] The dat a access point is t ypically envisioned as a sm all " wireless plug" [ 4] connect ed t o t he wiring infrast ruct ure of t he LAN, and t hus oft en m ount ed on a wall very m uch like a cabled dat a access point would be, perhaps in an office, a conference room , an audit orium or even in a hom e. The dat a t erm inal is t he client of t he dat a access point and t hus cont ains PPP client funct ion, which is used t o est ablish t he connect ion wit h t he dat a access point t hat in t urn perm it s access t o t he LAN. I n t he m ost general case, t here is an associat ion bet ween t hese device roles and t he baseband m ast er and slave roles. Much as a cordless t elephony gat eway m ust be a piconet m ast er ( as described in Chapt er10 and Chapt er13) , a dat a access point m ust also assum e t he m ast er role if it support s m ore t han one dat a t erm inal client . I n t he case of only one dat a t erm inal client ( for exam ple, when t he dat a access point is dedicat ed t o a single client or when t he LAP is used for PPP net working bet ween t wo com put ers) , it does not m at t er which device assum es t he m ast er role, but in general t he dat a access point is assum ed t o be t he m ast er in LAP applicat ions. [3] The LAP generally assumes the scenario of wireless access to a wired LAN, although access to a wireless LAN, such as one that uses 802.11 technology, is at least conceivable but might present some technical challenges.

[4]

Often informally called a dongle.

The use of PPP is key t o t he LAP. PPP is ideally suit ed for t he connect ion bet ween t he dat a access point and t he dat a t erm inal. I P net work t raffic ( as well as ot her net work prot ocols) can flow over t he PPP link. PPP is also designed for use over serial connect ions, and t hus wit hin t he LAP, PPP operat es over RFCOMM. The LAP is essent ially a procedure for est ablishing a PPP connect ion bet ween t he dat a access point and t he dat a t erm inal. Once t he PPP connect ion is est ablished, convent ional I P solut ions can be em ployed for net working funct ions such as obt aining an I P address. St andard I ETF prot ocols can t hen flow over t he PPP connect ion t o access services on t he LAN, m uch as in dial- up net working. Unlike dial- up net working, t hough, t he PPP connect ion in t he LAP is est ablished direct ly over a packet - orient ed dat a link and t hus does not require m odem funct ions and

170

associat ed AT com m ands t o est ablish t he connect ion. Typical LAP operat ion wit h a single dat a t erm inal is shown in Figure 15.2; not e t hat t here could be m ult iple dat a t erm inals if support ed by t he dat a access point ( in t his case, each has it s own separat e Bluet oot h t ransport and PPP connect ion t o t he dat a access point , and t he dat a access point m ust be t he piconet m ast er) . Figure 15.3 shows t he special case of t he LAP bet ween t wo individual com put ers.

Figu r e 1 5 .2 . Typica l LAN a cce ss pr ofile ope r a t ion . N ot e t h a t da t a a cce ss poin t s opt ion a lly m a y su ppor t m u lt iple da t a t e r m in a l clie n t s.

Figu r e 1 5 .3 . LAN a cce ss pr ofile ope r a t ion for n e t w or k in g be t w e e n t w o de vice s. Eit h e r de vice ca n a ssu m e e it h e r r ole ( da t a t e r m in a l or da t a a cce ss poin t ) .

The LAP has an int erest ing at t ribut e t hat m erit s discussion. The service record associat ed wit h t he PPP/ RFCOMM service m akes use of t he ServiceAvailabilit y at t ribut e defined by SDP. The LAP is t he only version 1.0 profile t hat specifies use of t his at t ribut e, alt hough as a universal service at t ribut e, it could be used by any service. A dat a access point could support m any dat a t erm inal client s, and t he ServiceAvailabilit y at t ribut e is used t o indicat e t he degree of ut ilizat ion of t he dat a access point ( how " busy" it is wit h current client s) . Thus in t he case where m ult iple dat a access point s exist for a given LAN ( perhaps in an audit orium or large conference room ) , a dat a t erm inal can perform SDP t ransact ions wit h each dat a access point t o locat e one t hat has capacit y t o handle addit ional client s. The SDP specificat ion defines t he ServiceAvailabilit y at t ribut e generically wit hout specifying part icular values t o indicat e degrees of ut ilizat ion. The LAP specifically defines values for ServiceAvailabilit y for dat a access point s, [ 5] wit h a percent age range t hat roughly corresponds t o t he num ber of possible act ive slaves in a piconet of which t he dat a access point is m ast er. [5]

The actual values are found in the Bluetooth Assigned Numbers portion of the core specification (volume 1).

171

Securit y is a significant considerat ion of m ost net works; hence t he LAP defines a high degree of securit y for t he PPP connect ion t hat perm it s access t o t hose net works. The LAP m andat es aut hent icat ion using device pairing, which can help t o ensure t hat only aut horized devices gain access t o t he net work. This is im port ant for corporat e and ot her privat e net works; t he net work owner m ay not wish t o grant net work access t o any device t hat happens t o be wit hin range of a dat a access point ( t hat device m ight belong t o a visit or who is not aut horized t o access t he privat e net work) . PI N- based aut hent icat ion is required t o aut hent icat e wit h a dat a access point , so net work access could be grant ed by divulging t he PI N t o t he prospect ive dat a access point client . For m ore public dat a access point s where it m ay be desirable t o allow alm ost anyone t o use t he LAN, t he PI N could be publicized t o all persons who ought t o have access, or—as t he LAP specifies—a default , zero- lengt h PI N could be used, effect ively perm it t ing universal adm ission t o t he dat a access point and hence t o t he LAN. I n t his lat t er case, addit ional securit y m easures could be necessary t o rest rict access t o services on t he LAN or t o ot her net works t hat m ay be accessible from t he LAN. The LAP also insist s upon t he use of encrypt ion of all t he t raffic on t he Bluet oot h wireless link bet ween t he dat a t erm inal( s) and t he dat a access point . I n addit ion, ot her higher- layer securit y m echanism s, including various PPP aut hent icat ion schem es m ent ioned in t he LAP, m ay be used t o aut hent icat e and aut horize users of net work resources.

LAP Usage As wit h t he DUNP, t he m ot ivat ion for t he LAP is t o access net works, prim arily ( but not exclusively) I P net works. So if m iddleware exist s for PPP, along wit h a requisit e I P st ack, t he sam e sort s of applicat ions not ed for t he DUNP can execut e over t he LAP's PPP link: browsers, em ail, FTP file t ransfers and so on. I P net working st acks and applicat ions t hat use t hem are com m on in m any devices, and t hese legacy applicat ions are enabled for use wit h Bluet oot h wireless com m unicat ion via t he PPP link defined by t he LAP. Furt herm ore, ot her prot ocols can operat e over t he PPP link. Not able am ong t hese is WAP. The specificat ion does not include a WAP profile; however, t he use of a Bluet oot h PPP/ I P connect ion as a bearer for WAP t raffic is described in volum e 1 of t he specificat ion, and t hat part of t he specificat ion cont ains som e inform at ion sim ilar t o t hat found in profiles. I n part icular, SDP service records are defined for WAP int eroperabilit y, and t he PPP connect ion as defined by t he LAP for I P t raffic is exact ly what is used for WAP net work access. I n t he next sect ion we offer addit ional inform at ion on how t he LAP is used as well as a com parison of t he LAP usage versus t hat of t he DUNP.

DUNP AND LAP COMPARED Because t he m et hods used t o access I P- based services in t he DUNP and LAP are sim ilar, we assert t hat a dat a t erm inal device t hat im plem ent s bot h profiles could be developed wit h lit t le m ore effort t han would be required t o im plem ent j ust one. Moreover, t he user experience for bot h of t he profiles on such a device could be quit e sim ilar, wit h applicat ions providing t he sam e user int erface and procedures for bot h t he DUNP and t he LAP. This is an added benefit t o t he user, who t hus can be concerned wit h only t he t ask at hand ( perhaps browsing or accessing a corporat e applicat ion) , rat her t han wit h t he underlying m et hod used t o connect t o t he dat a net work. For eit her of t hese t wo net working profiles, t he ult im at e obj ect ive is t o enable a connect ion bet ween t he PPP client funct ion in t he dat a t erm inal device and a PPP server funct ion residing at t he edge of an I P net work. [ 6] The prim ary difference in t he t wo profiles is t he role t hat t he Bluet oot h link plays in enabling t his connect ion. Figures Figure 15.4 and Figure15.5 highlight t he differences and sim ilarit ies in support ing I P com m unicat ions using t hese t wo profiles, showing a t ypical prot ocol st ack used in each. To connect , log in, and aut hent icat e oneself t o a PPP service, one m ay use a dialer applicat ion, like t hose used t o connect t o an I nt ernet service provider over

172

t elephone net works. I n t he case of t he DUNP, a m odem connect ion is required t o access t he PPP server, and t he Bluet oot h link replaces a serial cable bet ween t he dat a t erm inal device and t he gat eway device t hat cont ains t he m odem service. I n t he case of t he LAP no m odem s are involved, but t he Bluet oot h link is used as a subst it ut e for a direct serial connect ion bet ween t he PPP client in t he dat a t erm inal and t he dat a access point t hat export s t he PPP server funct ion. Apart from t his difference regarding t he role of t he Bluet oot h link in t he t wo profiles, t he sam e applicat ions and processes used t o achieve I P connect ivit y wit h t he DUNP can be reused in t he LAP. [6] Note that other protocols besides IP can be multiplexed over PPP. Thus the IP discussion here applies for other protocols, too, but we focus on IP as the most commonly used networking protocol.

Figure 15.4. Use of a Bluet oot h link in t he dial- up net working profile ( DUNP) .

Figu r e 1 5 .5 . Use of a Blu e t oot h lin k in t h e LAN Acce ss Pr ofile ( LAP) .

173

Even t hough sim ilar applicat ions can be used wit h bot h profiles, one int erest ing usage scenario t hat differs bet ween t he LAP and t he DUNP is t he aspect of m obilit y. I n t he t ypical case of t he DUNP, t he Bluet oot h link is bet ween t he com put er and t he phone, while t he net work connect ion is carried over t he phone's wide- area cellular connect ion. Since cellular net works use handoff t echnology t o deal wit h changing locat ions of t he phone, t he net work connect ion can be m aint ained even when t he user is m obile, so long as t he com put er and t he phone st ay wit hin proxim it y t o each ot her ( which is likely, since bot h are personal devices presum ably kept wit h t heir user) . Wit h t he LAP, t hough, t he Bluet oot h link is t he net work connect ion. So long as a user rem ains in proxim it y t o t he sam e dat a access point ( as m ight occur in a conference room or audit orium ) , t he net work connect ion can be m aint ained. But if t he user is m obile, t he PPP connect ion t o a given dat a access point could be t erm inat ed, requiring a new connect ion t o be est ablished t o a new dat a access point in t he new vicinit y, even if bot h dat a access point s are connect ed t o t he sam e LAN. The specificat ion does not address any sort of handoff schem e for t his scenario. Solut ions do exist , but t hey m ust be im plem ent ed at t he applicat ion layer of t he client and/ or in net work m iddleware ( which m ight or m ight not be direct ly associat ed wit h t he dat a access point ) .

The Fax Profile The fax profile, or FaxP, [ 7] m ight be considered a special case of t he DUNP ( and in fact t he DUNP m ent ions fax calls when it describes t he dat a calls necessary for dial- up net working, but it st at es t hat fax is not part of t he DUNP and inst ead is addressed in t he FaxP) . I n m any respect s fax and dat a t ransm issions are sim ilar: bot h m odulat e and dem odulat e com m ands and dat a bet ween t wo endpoint s over a t elephone line. Yet t here are differences, m uch as a dat a m odem is dist inguished from a fax m odem , and t here are special considerat ions for faxing over Bluet oot h wireless links. Thus fax funct ion is addressed in a separat e profile, and even wit hout a specific fax usage m odel, it is an assum ed scenario due t o it s sim ilarit y t o dat a calls. [7]

We use the term FaxP to distinguish it from the file transfer profile that we call FP.

FaxP Development None of t he published Bluet oot h usage scenarios address fax funct ion. The MRD [ 8] m akes only t wo passing references t o fax usage cases. So rat her t han having an associat ed usage m odel wit h a cat chy nam e, t he FaxP sim ply t ells how t o do wireless faxing using Bluet oot h links. While we t reat t he FaxP here as a net working profile, it s herit age is in t he t elephony- based profiles. As already not ed, t he DUNP and LAP were originally part s of a single I nt ernet bridge profile. When t he DUNP was m ade int o it s own separat e profile, it init ially included fax scenarios as well as dialup dat a net working ( t his is evident from t he m any sim ilarit ies in t he st ruct ure and cont ent of t he t wo profiles, as well as t he references t o fax calls t hat rem ain in t he DUNP) . Soon t hereaft er, t he FaxP was also split int o it s own profile based upon t he considerat ions above t hat m ake fax it s own dist inct ive usage case. [8] Recall from Chapter 4 that the marketing requirements document preceded the specification and defined the usage models that drove the requirements for protocols and profiles.

At about t he sam e t im e t hat t he FaxP was split int o a separat e profile, t here was significant debat e about t he fax classes t hat could and should be support ed over Bluet oot h links. We do not present a det ailed discussion of fax t echnology here, [ 9] but we do describe enough about fax classes t o fram e t he issue regarding fax in Bluet oot h wireless com m unicat ion. I n what is called Group 3 fax, [ 10] t here are t hree prot ocols of int erest wit hin t he FaxP cont ext : class 1, class 2.0 and class 2. The form er t wo are I TU- T st andards while t he lat t er is an indust ry de fact o st andard, and indeed class 2 and class 2.0 are different ( alt hough sim ilar, and m uch of t he following discussion of class 2.0 generally applies t o class 2 also) . The debat e about fax class support in Bluet oot h environm ent s cent ers around t im ing requirem ent s of t hese fax classes. A difference

174

bet ween class 1 and class 2.0 fax is t he funct ional split of t wo m aj or com ponent s of fax t ransm ission: call cont rol and im age processing. I n t he t ypical FaxP usage case, a com put er works wit h a m obile phone t o send and receive fax inform at ion, sim ilar t o t he t ypical DUNP case. I n t his t ypical configurat ion, bot h im age processing and call cont rol funct ions are perform ed by t he com put er for class 1 fax; whereas for class 2.0 t he phone m anages call cont rol wit h t he com put er handling im age processing. There was som e concern wit hin t he SI G t hat t he Bluet oot h link bet ween t he com put er and t he phone could cause delays sufficient t o violat e som e fax t im ing requirem ent s. These concerns are m ost pronounced wit h class 1, where t he com put er m ust m anage t he call cont rol funct ions over t he Bluet oot h link in addit ion t o t he im age- processing load ( t he division of funct ion bet ween devices in class 2.0 m akes it som ewhat less suscept ible t o t hese t im ing violat ions) . There was a proposal wit hin t he SI G t o m ake support for class 1 fax opt ional based upon t hese concerns. Aft er m uch st udy and debat e, t he SI G finally chose t o m andat e support for at least one of t he t hree classes ( 1, 2 or 2.0) , wit hout specifying any part icular one as m andat ory t o support , and wit hout direct ly addressing t he issue of t im ing requirem ent s wit h regard t o t hese classes ( t hese considerat ions are left t o t he im plem ent er, wit h t he guidance of t he Bluet oot h specificat ion and fax st andards) . [9] Interested readers can refer to, for example, [ITU96] as well as the standards listed in the "References" section of the Fax Profile chapter of the Bluetooth specification [BTSIG99], volume 2.

[10]

More properly, Group 3 facsimile, but we will continue to use the common term "fax."

FaxP Examined I t is not surprising, given t he hist ory of profile developm ent , t hat t he FaxP is quit e sim ilar t o t he DUNP. The exam inat ion of t he FaxP here is abbreviat ed, since m uch of t he DUNP discussion also applies t o t he FaxP. The FaxP defines t he sam e device roles as t he DUNP, nam ely a gat eway device ( t ypically a m obile phone or a fax m odem ) and a dat a t erm inal device ( t ypically a com put er) . These device roles have no bearing on t he baseband m ast er and slave device roles. Like in t he DUNP, bot h out going calls ( fax send) and incom ing calls ( fax receive) are perm it t ed. Since t he FaxP is a derivat ive of t he serial port profile, AT com m ands are used over an RFCOMM link for call cont rol. The AT com m and set used is dependent upon t he fax class( es) support ed. Audio call progress feedback is opt ional and is handled in t he sam e m anner as wit h t he DUNP. Typical FaxP operat ion is shown in Figure 15.6; not e t hat t he gat eway device also could be a m odem .

Figu r e 1 5 .6 . Typica l fa x pr ofile ope r a t ion .

175

The FaxP SDP service record is used t o det erm ine whet her or not t he opt ional audio feedback support is present , as well as t o det erm ine t he fax class( es) support ed, alt hough t he lat t er also can be det erm ined using AT com m ands. Because fax t ransm issions are generally considered reasonably secure, t he FaxP m andat es a relat ively high level of securit y. Aut hent icat ion and encrypt ion are required, as is support for bonding and at least one of securit y m odes 2 or 3 ( described in Chapt er 12) .

FaxP Usage Clearly t he FaxP is anot her exam ple of a profile t o enable exist ing usage scenarios t o be accom plished by exist ing applicat ions in a wireless fashion. Fax t echnology is quit e m at ure and is widely used t oday. Through t he use of m odem and serial port em ulat ion, t he FaxP is designed t o allow legacy fax applicat ions t o operat e over Bluet oot h links wit h lit t le, if any, change.

176

Part 4: The Future of Bluetooth Technology This book concludes wit h an exam inat ion of fut ure direct ions for t he Bluet oot h t echnology.Chapt er 16 discusses som e possibilit ies for fut ure applicat ions of Bluet oot h wireless com m unicat ion, including t opics addressed by t he SI G subsequent t o t he publicat ion of t he version 1.0 specificat ion. These include aut om ot ive, im aging, print ing and ot her scenarios. We also discuss t he product landscape and m arket place for Bluet oot h devices in t he year 2000 and beyond.Chapt er 17 offers concluding rem arks about present and fut ure opport unit ies in t his field. Part 4 is int ended t o provide a snapshot of Bluet oot h wireless com m unicat ion in t he year 2000 and a vision of where t he t echology m ay be headed in t he fut ure.

Chapter 16. Beyond the Version 1.0 Specification Having exam ined t he version 1.0 specificat ion in det ail, we now t urn our at t ent ion t o post - version 1.0 m at t ers. I n part icular we look int o t he act ivit ies of t he SI G in developing new profiles, as well as som e possibilit ies for product s t hat use Bluet oot h wireless t echnology. The t hesis of t his chapt er is on new applicat ions t hat m ight appear in t he realm of Bluet oot h t echnology, rat her t han on fact ual cont ent t hat was explored in t he m ain body of t he book. Hence t he t one of t his chapt er and t he one t hat follows is a bit different . Earlier in t he book we not ed t hat for version 1.0 t he SI G focused on enabling basic cablereplacem ent scenarios. The SI G consciously decided t o defer profile developm ent t hat would support m any m ore advanced yet int erest ing and valuable usage cases so as t o accelerat e t he developm ent of t he version 1.0 specificat ion. Many of t hese new usage m odels are addressed in profiles developed aft er version 1.0 publicat ion. I n t his chapt er we exam ine t hose profiles under developm ent in t he year 2000 along wit h ot her associat ed work wit hin t he SI G. Just as t he version 1.0 profiles are not a com plet e pict ure of what Bluet oot h wireless t echnology offers, neit her is t he second round of profiles[ 1] t o be published by t he SI G t he final answer about t he specificat ion. I ndeed, t he st ory for Bluet oot h wireless com m unicat ion m ay well be one wit hout a definit ive end, since indust ry innovat ion is likely t o spawn new applicat ions of t he t echnology for years t o com e. I n t his chapt er we exam ine j ust a few possibilit ies t hat go beyond t he first t wo edit ions of t he specificat ion. I n conj unct ion wit h t he SI G's specificat ion work, we also explore t he landscape of Bluet oot h product s, bot h t hose t hat are being m arket ed and t hose t hat are likely t o appear in t he foreseeable fut ure. [1]

Tentatively called version 2.0 of the specification, although this is subject to change before final publication.

The SIG Reconstituted The SI G's original chart er t echnically expired wit h t he publicat ion of t he version 1.0 specificat ion. That chart er called for t he specificat ion's delivery, and once t hat was achieved, t he SI G in one sense ceased t o exist . The bylaws of t he SI G allowed for t he publicat ion of errat a t o t he original specificat ion, and version 1.0B was published in Decem ber 1999 wit h m any correct ions and clarificat ions t o t he version 1.0A specificat ion.

177

The SI G's work didn't really st op, t hough, aft er t he init ial specificat ion was published. During t he lat t er half of 1999, represent at ives of t he original prom ot er m em bers of t he SI G held frequent discussions about t he next st eps t hat t he SI G would t ake. These discussions culm inat ed in Decem ber 1999 wit h t he announcem ent of a newly chart ered SI G which included four new prom ot er com panies ( 3Com , Lucent , Microsoft and Mot orola) in addit ion t o t he original five founding prom ot er com panies ( Ericsson, I nt el, I BM, Nokia and Toshiba) . Along wit h t he new prom ot er group, t he SI G also had a new organizat ion, including a new class of m em bers called associat es. Associat e m em bers are som ewhere bet ween adopt er and prom ot er m em bers and m ay part icipat e in specificat ion developm ent and SI G t echnical m eet ings. The associat e m em bership cat egory was creat ed t o perm it broader part icipat ion in t he SI G, and several com panies im m ediat ely j oined as associat es. At t he sam e t im e, t he SI G also announced t he form at ion of several new working groups, m ost of which are developing new profiles. This work, underway in 2000, is reviewed below.

New Working Groups and Profiles Som e im port ant usage m odels were deferred during t he developm ent of t he version 1.0 specificat ion, and a num ber of new ideas for usage scenarios have surfaced as t he Bluet oot h t echnology has evolved. I n 2000, t he SI G chart ered several new working groups t o explore m any such usage m odels, wit h m ost of t hem result ing in new profiles. A brief review of each working group underway in 2000 follows. I t should be not ed t hat wit h t he version 1.0 specificat ion available and wit h m any im plem ent at ions proceeding based upon it s cont ent s, backward com pat ibilit y is a key concern of t he SI G. All of t he working groups include com pat ibilit y wit h t he version 1.0 specificat ion as one of t heir core obj ect ives. I ndeed, t his is why m ost of t he version 2.0 specificat ion work is em bodied as profiles: profiles provide a way t o int roduce new funct ion wit hout affect ing t hose capabilit ies t hat already exist . All profiles, save t he GAP, are opt ional. As new profiles becom e available, im plem ent ers m ay choose t o support t hem wit hout affect ing exist ing funct ions. The prot ocols in t he core specificat ion are not expect ed t o change significant ly as t he post - version 1.0 work proceeds; in som e cases, opt ional ext ensions m ay be developed. But m ost new specificat ion cont ent will be delivered in t he form of profiles. Radio 2.0 and Coexistence Working Groups Chaired by Ericsson and Nokia, t he radio 2.0 working group invest igat es opt ional ext ensions t o t he radio specificat ion. Am ong t hese are increased dat a rat es, im provem ent s t o baseband funct ions ( especially t he inquiry process) , " handoff" capabilit y t o support roam ing, and bet t er coexist ence wit h ot her t echnologies operat ing in t he 2.4 GHz spect rum . Perhaps t he m ost prom inent feat ure under invest igat ion by t he radio 2.0 working group is t hat of higher dat a rat es. The quest for m ore bandwidt h in all t ypes of com m unicat ion seem s insat iable, and m ost t echnologies are const ant ly st riving for higher speeds and t hroughput . I ncreased dat a rat es have been seen in bot h wired and wireless com m unicat ion, wit h Et hernet and I rDA being but t wo exam ples. Bluet oot h wireless t echnology is no except ion, and m any knowledgeable engineers believe t hat Bluet oot h wireless com m unicat ion can occur at higher speeds. I n 2000, t he radio 2.0 working group was looking int o at least doubling t he raw t ransm ission speed of Bluet oot h links t o 2 Mbps, wit h som e proposals t hat could increase dat a rat es even m ore dram at ically. Like all of t he working groups, t he radio 2.0 group is concerned wit h backward com pat ibilit y. The radio 2.0 specificat ion is expect ed t o t ake t he form of opt ional ext ensions. Fundam ent al principles of t he Bluet oot h radio, including global operat ion, low cost and short - range com m unicat ion, will cont inue t o be at t he heart of t he radio specificat ion.

178

One part icular radio considerat ion, t hat of harm ony wit h ot her 2.4 GHz t echnologies, m erit s it s own working group: t he coexist ence working group. This group is concerned wit h issues such as int erference and perform ance im pact s when m ult iple RF t echnologies are used in t he sam e t im e and space. Working wit h ot her organizat ions, such as Hom eRF™ and t he I EEE 802.11 and 802.15 working groups, t he coexist ence working group produces recom m endat ions t o allow t he various 2.4 GHz t echnologies t o work well t oget her. One exam ple is t he SI G's collaborat ion wit h t he I EEE 802.15 working group, which was form ed in t he spring of 1999 t o develop st andards for wireless personal area net works. I n t he sum m er of 1999, t he SI G proposed t he version 1.0 Bluet oot h specificat ion, which had j ust been published, as a pot ent ial I EEE 802.15 st andard. A t ask group wit hin t he 802.15 working group was t hen form ed t o draft an I EEE 802.15 st andard based upon t he group of Bluet oot h t ransport prot ocols[ 2] . [2] The IEEE 802 standards are concerned only with the two lowest communication layers, the physical and data link layers. As such, only the group of Bluetooth transport protocols is relevant to an 802 standard, and this subset of the protocol stack is the basis for the 802.15 proposal.

Extensions and Enhancements Working Groups All of t he working groups discussed in t his sect ion had t heir genesis in usage cases t hat were addressed t o som e ext ent during t he version 1.0 specificat ion developm ent . I n each case, som e prelim inary work was done wit hin t he SI G during it s early days, but for various reasons t he com plet e profiles for t hese usage scenarios were deferred. Because t he SI G fully expect ed t o com plet e t hese profiles for version 2.0 of t he specificat ion, t he foundat ion for each was laid in version 1.0. Som e of t he result ing profiles will t race back t o usage cases described in Chapt er 3 for which no version 1.0 profile exist s. The working groups dealing wit h version 1.0 ext ensions and enhancem ent s are: •

•

Pe r sona l Ar e a N e t w or k ing ( PAN ) : The PAN working group is co- chaired by Microsoft and I nt el and is focused on general I P net working issues, including securit y. As described in Chapt er 15 and elsewhere, t he version 1.0 specificat ion does not define a general solut ion for ad hoc I P net working; it addresses only dial- up net working and LAN access using PPP. The SI G's original net working working group had som e prelim inary discussions of a general I P net working solut ion but realized t hat a com prehensive profile would require m ore t im e t han was available for t he version 1.0 specificat ion. The PAN group was form ed t o cont inue t his work, wit h t he deliverable of a profile t hat addresses secure ad hoc net working t o support usage m odels such as collaborat ive applicat ions ( m uch as described in " Ad Hoc Net working" in Chapt er 3) . H u m a n I n t e r fa ce D e vice s ( H I D ) : Chapt er 3 described t he cordless com put er usage m odel and not ed t hat no profile exist ed for it in version 1.0. The HI D [ 3] working group is int ended t o focus prim arily on such a usage scenario. HI D refers t o com put er peripherals such as keyboards, m ice, j oyst icks and t he like. HI D is an exist ing specificat ion for t he use of such devices wit h com put ers, and t he HI D working group, chaired by Microsoft , is charged wit h t he developm ent of a profile t o realize t he use of HI D over Bluet oot h links t o realize t he cordless com put er usage m odel. [3]

•

Not to be confused with the hidden computing usage model.

Pr in t in g: While none of t he init ial usage m odels dealt direct ly wit h print ing, it is such a com m on t ask t hat it was discussed in num erous working groups. The cordless com put er usage m odel describes print er peripherals, and print ing is a com m on exam ple for service discovery scenarios. Co- chaired by Hewlet t - Packard® ( an associat e m em ber of t he SI G) and Ericsson and populat ed by num erous print ing expert s, t he print ing working group addresses various usage cases t hat involve print ing over Bluet oot h links. These include direct - t o- print er scenarios using peer- t o- peer com m unicat ion t o print from various devices t o a Bluet oot h print er.

179

•

•

St ill I m a ge : I n " The I nst ant Post card" sect ion of Chapt er 3, we not e t hat t hat scenario is unique am ong t he version 1.0 usage m odels in t hat it includes a personal device ot her t han a m obile phone or com put ing plat form , nam ely a digit al cam era. The st ill im age working group, chaired by Nokia, works on det ails of im age handling and m anipulat ion in Bluet oot h environm ent s, wit h t he inst ant post card usage m odel at t he heart of it s focus area. This working group form alizes t he m odel of im age t ransfer as described in t he inst ant post card scenario, and also addresses m anipulat ing t he im age, perhaps for display or print ing ( and t hus works wit h t he print ing working group) . Ex t e nde d Se r vice D iscove r y Pr ofile s ( ESD P) : Chapt er 8 described a design obj ect ive of SDP t o perm it coexist ence wit h ot her indust ry service discovery prot ocols. The ESDP working group, co- chaired by Microsoft and 3Com , focuses on form al specificat ions, in t he form of profiles, for m apping select ed service discovery prot ocols t o Bluet oot h environm ent s. The init ial focus for t hese profiles is on t he Universal Plug and Play and Salut at ion t echnologies ( t he lat t er being an out growt h of [ Miller99] , which described a Salut at ion m apping in inform al t erm s) , alt hough ot her profiles for ot her t echnologies m ay com e lat er.

New Applications Working Groups While each of t he working groups not ed in t he preceding sect ion will produce profiles or ot her docum ent at ion t o enable new applicat ions of Bluet oot h t echnology, t hey all have grown out of work t hat was st art ed during version 1.0 specificat ion developm ent . The working groups discussed in t his sect ion, on t he cont rary, are t ruly new dom ains for Bluet oot h wireless com m unicat ion. While t hese applicat ions m ight have been discussed in passing in t he original SI G, t here was no specific work done t o enable t hem . Each deals wit h an applicat ion of Bluet oot h t echnology t hat is m ore t han j ust an evolut ionary ext ension of t he version 1.0 usage m odels. The working groups dealing wit h new applicat ions are: •

•

•

Ca r Pr ofile : Aut om ot ive m anufact urers have expressed great int erest in Bluet oot h t echnology for in- vehicle com m unicat ion. Chaired by Nokia, t he car profile working group is invest igat ing solut ions for wireless com m unicat ion wit hin vehicles, including accessing devices and services in a car using Bluet oot h links ( perhaps aut om ot ive inform at ion and ent ert ainm ent syst em s) and t he use of personal devices like pagers, m obile phones and m obile com put ers in aut om ot ive environm ent s. There are m any possibilit ies for t he use of Bluet oot h wireless com m unicat ion in vehicles. Consider scenarios such as aut om at ically configuring personalized set t ings in t he aut om obile ( vent ilat ion, seat and m irror posit ions, radio set t ings and so on) based upon personal ident it y carried on a Bluet oot h device, or ret rieving e- m ail t hrough a cellular link bet ween t he car's Bluet oot h net work and a larger net work and t hen having t hat m ail read, using voice t echnology, over t he car's audio syst em . Num erous ot her applicat ions can be im agined, and t he car profile working group is chart ered t o specify m any of t hese. Rich e r Audio/ Vide o ( AV) : This working group, co- chaired by Philips® and Sony® ( bot h SI G associat e m em bers) , addresses t he use of Bluet oot h links for exchanging audio inform at ion beyond t he sim ple voice- qualit y audio specified in version 1.0, as well as m ot ion video dat a. Wit h m ult im edia capabilit y on Bluet oot h devices, new usage scenarios for m ovies and video clips, m usic ( wit h wireless headphones) , video conferencing, dict at ion and ot hers could be enabled. The AV working group deals wit h t he challenges of handling t his kind of dat a- int ensive, t im e- crit ical inform at ion in Bluet oot h environm ent s. Loca l Posit ion ing: Co- chaired by Microsoft and Nokia, t his working group invest igat es t he use of Bluet oot h wireless t echnology as a m eans t o det erm ine t he geographic locat ion of a device ( and oft en, t hen, t he user of t hat device) . Through j udicious use of t he propert ies of t he short - range RF int erface, Bluet oot h t echnology can be em ployed t o det erm ine local ( in- building) posit ion inform at ion. The local posit ioning working group is chart ered t o provide a schem e t o gat her such inform at ion and m ake it available in a st andard way t o applicat ions. The applicat ions could t hen use t his inform at ion for a

180

m ult it ude of purposes t hat m ight include select ion of t he " best " device t o connect t o in a local area, based upon proxim it y, locat ing a lost device, and so on.

Creating Additional Profiles The foregoing are som e of t he working groups init ially chart ered by t he SI G in 2000. Over t im e, new working groups m ay develop m ore new ext ensions and profiles for Bluet oot h applicat ions. The SI G's new organizat ion prom ot es part icipat ion by a wider group of cont ribut ors and enables t he form at ion of new working groups when sufficient indust ry int erest exist s for a given t opic. The SI G has developed a form al process for t he creat ion of working groups and profiles. As it does for t he product s discussed below, t rem endous opport unit y exist s for innovat ion result ing in new applicat ions and profiles.

Bluetooth Products This sect ion discusses t he product landscape for Bluet oot h t echnology. We do not cit e specific product s or com panies; [ 4] rat her, we describe general product classes. We survey, in general t erm s, t he first Bluet oot h product s t o reach t he m arket in 2000 and predict t he kinds of product s expect ed t o appear over t im e. [4]

The official Bluetooth SIG web site, http://www.bluetooth.com, includes a section that links to currently available products.

Silicon and Developers Kits The basis of t he specificat ion is t he radio and baseband; so, t oo, are t hese com ponent s t he fundam ent al elem ent s of product s. Manufact urers building end- user product s need t o st art wit h a chip set t hat includes t he RF com ponent ry and digit al subsyst em s for t he baseband firm ware and it s associat ed m em ory. Original equipm ent m anufact urers ( OEMs) have a choice am ong several suppliers of Bluet oot h hardware. I n 2000, at least seven vendors were supplying Bluet oot h radio m odules t o t he m arket place. Most silicon m anufact urers also can supply com plet e developers kit s t o accom pany t he radio m odule hardware. Developers kit s t ypically include a circuit board wit h m ult iple int erfaces t o a host , along wit h prot ocol st ack soft ware t hat execut es on t he host . These developers kit s allow product m anufact urers t o creat e t heir own product s, bot h hardware and soft ware, and t o t est and debug t hose product s using t he kit s' accessible feat ures. These kit s t ypically allow for frequent and easily m ade changes t o t he product under developm ent , so t hat t he developm ent process is expedit ed. Oft en a large port ion of t he product developm ent process can be com plet ed using t he developers kit s and ot her developm ent t ools, wit hout having t o creat e a final product im age unt il lat e in t he cycle. I n addit ion t o general developm ent syst em s, a specific class of developers t ools for Bluet oot h wireless t echnology also em erged in 2000: prot ocol analyzers. These are t ools t hat can capt ure t he air- int erface t raffic over Bluet oot h links and present t his inform at ion t o t he developer in an easy- t o- com prehend fashion. These wireless prot ocol analyzers are analogous t o t heir wired count erpart s but do not require a physical connect ion t o t he product s being t est ed, since t hey j ust need t o int ercept RF t raffic. They t end t o be passive receivers which capt ure t he packet s in a piconet and t ransfer t his dat a t o a host for processing. The processing m ight include separat ing packet s from each of t he various layers in t he st ack and displaying t hat dat a in hum an- readable form on t he host . Prot ocol analyzers can be especially helpful in Bluet oot h environm ent s because t he act ual bit st ream s t ransferred over t he air- int erface can be quit e com plex. [ 5]

181

[5] Consider all of the operations that might occur on the data before it is transmitted over the air-interface: packetization, FEC, whitening, encryption and other transformations could make the over-the-air data bear little resemblance to the logical PDUs generated by upper layers of the stack.

Since silicon, hardware, firm ware and developers kit s enable t he product ion of end- user product s, t hese were t he first Bluet oot h product s available. Num erous such hardware and developm ent plat form s becam e available beginning in m id- 2000.

Legacy Product Enablers One way t o quickly int roduce Bluet oot h t echnology t o t he m arket place is t o produce " add- on" com ponent s t hat at t ach t o exist ing product s t o enable t hem for Bluet oot h wireless com m unicat ion. Exam ples of such product s include PC cards ( also known as PCMCI A cards) for not ebook com put ers and sim ilar devices and hardware " plug- ins" ( som et im es inform ally called " dongles" ; we use t he t wo t erm s int erchangeably) t hat at t ach t o a st andard int erface such as a serial or USB port . The first PC cards wit h associat ed prot ocol st ack soft ware and drivers for popular PC plat form s were announced in 2000, wit h som e being dem onst rat ed at developers conferences. These Bluet oot h PC cards work sim ilarly t o ot her PC cards; t he card is inst alled in t he com put er, along wit h it s associat ed soft ware, and t he syst em is present ed wit h a new int erface ( in t his case, one for Bluet oot h wireless com m unicat ion) . A prim ary advant age of PC cards here is in adding capabilit y for Bluet oot h wireless com m unicat ion t o exist ing m achines in a st raight forward m anner. Wit hout t he purchase of a new com put er, a new feat ure becom es available. One disadvant age is t hat t he Bluet oot h t echnology is not seam lessly int egrat ed int o t he syst em , as it would be if included in t he base m anufact ured unit . Thus perform ance m ay not be opt im al, due t o considerat ions such as ant enna placem ent ( which is necessarily on t he PC card it self, or perhaps elsewhere via a cable connect ion; in eit her of t hese cases, fragilit y is one concern) . I n addit ion, PC card slot s on m obile com put ers t ypically are lim it ed t o one or t wo, so a Bluet oot h PC card occupies a slot t hat m ight ot herwise be used for ot her feat ures. I nt erface add- ons provide a sim ilar way t o enable exist ing devices wit h Bluet oot h wireless com m unicat ion. These devices t ypically plug int o an exist ing st andard int erface, such as an RS232 serial port or a USB port . As wit h PC cards, a dongle wit h t he appropriat e prot ocol st ack and driver soft ware can enable t he exist ing int erface t o support Bluet oot h wireless com m unicat ion. From t he syst em 's point of view, t he t raffic is direct ed over t he exist ing port j ust as it would be in a cabled environm ent , but t he int erface add- on t hen receives and t ransm it s t hat dat a over t he Bluet oot h air- int erface. The advant ages and disadvant ages of dongles are sim ilar t o t hose of PC cards: t hey can enable im m ediat e use of t he Bluet oot h t echnology on exist ing devices, but t hey m ight exhibit nonopt im al perform ance and fragilit y while t aking up one of t he syst em 's int erface port s. [ 6] I nt erface add- ons can be const ruct ed for m any t ypes of devices, not j ust com put ers, t hus ( at least t heoret ically) enabling any device t hat export s a st andard int erface t o m ake use of Bluet oot h wireless com m unicat ion. Handheld com put ers, digit al cam eras, print ers, scanners and ot her devices are all candidat es for add- on Bluet oot h solut ions. However, packaging dongles for use on sm all handheld devices m ight in som e cases m ake t he result ing device significant ly larger and less convenient t o use. Dongles for use wit h equipm ent t hat t ypically is st at ionary, such as print ers, scanners and sim ilar devices, t hough, is pot ent ially quit e valuable. [6]

For a USB interface, this latter consideration is minimized through USB's "multi-drop" device attachment scheme.

Because PC cards and int erface add- ons can enable legacy devices t o im m ediat ely ut ilize Bluet oot h t echnology, t hese devices were som e of t he first end- user product s t o appear in 2000. The use of st andard int erfaces, like serial and USB port s, com bined wit h t he freedom from ext ensive elect rom echanical design and packaging as is required for int egrat ed solut ions, m akes t he product ion of t hese legacy device enabling product s relat ively st raight forward.

182

Computers and Mobile Phones Given t he com posit ion of t he original SI G's prom ot er m em bers, who have significant business int erest s in m obile phones and personal com put ers ( bot h deskt op and m obile) , it is not surprising t hat t hese devices were am ong t he first end- user product s t o have Bluet oot h t echnology int egrat ed int o t hem . All of t he version 1.0 cable- replacem ent usage m odels involve a phone, a com put ing plat form , or bot h. Am ong t he first product s t o be announced and dem onst rat ed were Bluet oot h m obile phones and headset s. Most m aj or m obile phone m anufact urers indicat ed t hat t hey will ship handset s ( and in m any cases, also headset s) wit h Bluet oot h t echnology in 2000. The popularit y of m obile t elephones result s in very high volum e m anufact uring ( in t he hundreds of m illions of unit s) of t hese devices; hence m obile phones are a significant influence on Bluet oot h m odule proliferat ion. I f a significant port ion of m obile phones include Bluet oot h t echnology, t hen hardware cost s can decrease as m anufact uring volum es increase. Achieving lower- cost Bluet oot h m odules t hen enables t heir incorporat ion int o ot her cost - sensit ive devices such as consum er elect ronics ( discussed below) . Com put ers are a key device segm ent for Bluet oot h t echnology. Mobile com put ers, especially, have a high affinit y for Bluet oot h wireless com m unicat ion and are included in several of t he version 1.0 profiles. A num ber of m aj or m obile com put er m anufact urers planned t o incorporat e Bluet oot h t echnology in t heir product s in 2000. Furt herm ore, t hrough t he use of PC cards ( described above) , t he large inst alled base of m obile PCs can be enabled wit h Bluet oot h t echnology in t he short t erm , in addit ion t o int egrat ed solut ions t hat m ay be offered by com put er m anufact urers. Moreover, Bluet oot h wireless com m unicat ion is not j ust for PCs; prot ot ype solut ions for several handheld com put ers were dem onst rat ed at developers conferences in 2000, so t hese devices are also expect ed t o incorporat e Bluet oot h t echnology.

Other Products The init ial m arket place for Bluet oot h wireless com m unicat ion is populat ed by m obile t elephones and com put ers and associat ed accessories and add- on com ponent s for t hese devices. This is not surprising, given t he com posit ion of t he SI G's prom ot er group. But t he com plet e SI G m em bership also includes m anufact urers and soft ware developers from m any indust ries. Given t he SI G's post - version 1.0 work on print ing, st ill im age and aut om ot ive solut ions, we expect t o see Bluet oot h t echnology incorporat ed in print ers, digit al cam eras and aut om obiles in t he foreseeable fut ure. Leading m anufact urers in each of t hese indust ries are act ively part icipat ing in t he SI G, and t here is m om ent um t o produce equipm ent wit h Bluet oot h wireless com m unicat ion capabilit y. As t he t echnology's cost s cont inue t o decrease over t im e, m any consum er elect ronic devices m ay incorporat e Bluet oot h wireless com m unicat ion. Again, wit h leading indust ry players being involved in t he SI G, Bluet oot h devices including t elevisions, st ereos and ot her audiovisual devices are expect ed t o appear in t he m arket place. Chapt er 3 discussed what t he SI G calls " t he ult im at e headset ," which can be used wit h com put ers and m obile t elephones. As ot her audio devices incorporat e Bluet oot h t echnology, such a headset m ight be used wit h port able CD players, aut om obiles, st ereos and ot her such devices, perhaps enabling an " ult im at e ult im at e headset ." Ot her product s in which Bluet oot h t echnology could be used include universal rem ot e cont rols, household appliances and even t oys. Bluet oot h t echnology cert ainly has t he pot ent ial t o be widely deployed in ent erprises, hom es and public venues. Successful int roduct ion of t he first devices can help t o enable posit ive percept ion, user experience and value for users of m any t ypes of devices. We believe t hat Bluet oot h wireless com m unicat ion is well posit ioned t o m ake inroads in m any different devices and m arket places.

183

Bluetooth Products This sect ion discusses t he product landscape for Bluet oot h t echnology. We do not cit e specific product s or com panies; [ 4] rat her, we describe general product classes. We survey, in general t erm s, t he first Bluet oot h product s t o reach t he m arket in 2000 and predict t he kinds of product s expect ed t o appear over t im e. [4]

The official Bluetooth SIG web site, http://www.bluetooth.com, includes a section that links to currently available products.

Silicon and Developers Kits The basis of t he specificat ion is t he radio and baseband; so, t oo, are t hese com ponent s t he fundam ent al elem ent s of product s. Manufact urers building end- user product s need t o st art wit h a chip set t hat includes t he RF com ponent ry and digit al subsyst em s for t he baseband firm ware and it s associat ed m em ory. Original equipm ent m anufact urers ( OEMs) have a choice am ong several suppliers of Bluet oot h hardware. I n 2000, at least seven vendors were supplying Bluet oot h radio m odules t o t he m arket place. Most silicon m anufact urers also can supply com plet e developers kit s t o accom pany t he radio m odule hardware. Developers kit s t ypically include a circuit board wit h m ult iple int erfaces t o a host , along wit h prot ocol st ack soft ware t hat execut es on t he host . These developers kit s allow product m anufact urers t o creat e t heir own product s, bot h hardware and soft ware, and t o t est and debug t hose product s using t he kit s' accessible feat ures. These kit s t ypically allow for frequent and easily m ade changes t o t he product under developm ent , so t hat t he developm ent process is expedit ed. Oft en a large port ion of t he product developm ent process can be com plet ed using t he developers kit s and ot her developm ent t ools, wit hout having t o creat e a final product im age unt il lat e in t he cycle. I n addit ion t o general developm ent syst em s, a specific class of developers t ools for Bluet oot h wireless t echnology also em erged in 2000: prot ocol analyzers. These are t ools t hat can capt ure t he air- int erface t raffic over Bluet oot h links and present t his inform at ion t o t he developer in an easy- t o- com prehend fashion. These wireless prot ocol analyzers are analogous t o t heir wired count erpart s but do not require a physical connect ion t o t he product s being t est ed, since t hey j ust need t o int ercept RF t raffic. They t end t o be passive receivers which capt ure t he packet s in a piconet and t ransfer t his dat a t o a host for processing. The processing m ight include separat ing packet s from each of t he various layers in t he st ack and displaying t hat dat a in hum an- readable form on t he host . Prot ocol analyzers can be especially helpful in Bluet oot h environm ent s because t he act ual bit st ream s t ransferred over t he air- int erface can be quit e com plex. [ 5] [5] Consider all of the operations that might occur on the data before it is transmitted over the air-interface: packetization, FEC, whitening, encryption and other transformations could make the over-the-air data bear little resemblance to the logical PDUs generated by upper layers of the stack.

Since silicon, hardware, firm ware and developers kit s enable t he product ion of end- user product s, t hese were t he first Bluet oot h product s available. Num erous such hardware and developm ent plat form s becam e available beginning in m id- 2000.

Legacy Product Enablers One way t o quickly int roduce Bluet oot h t echnology t o t he m arket place is t o produce " add- on" com ponent s t hat at t ach t o exist ing product s t o enable t hem for Bluet oot h wireless com m unicat ion. Exam ples of such product s include PC cards ( also known as PCMCI A cards) for not ebook com put ers and sim ilar devices and hardware " plug- ins" ( som et im es inform ally called

184

" dongles" ; we use t he t wo t erm s int erchangeably) t hat at t ach t o a st andard int erface such as a serial or USB port . The first PC cards wit h associat ed prot ocol st ack soft ware and drivers for popular PC plat form s were announced in 2000, wit h som e being dem onst rat ed at developers conferences. These Bluet oot h PC cards work sim ilarly t o ot her PC cards; t he card is inst alled in t he com put er, along wit h it s associat ed soft ware, and t he syst em is present ed wit h a new int erface ( in t his case, one for Bluet oot h wireless com m unicat ion) . A prim ary advant age of PC cards here is in adding capabilit y for Bluet oot h wireless com m unicat ion t o exist ing m achines in a st raight forward m anner. Wit hout t he purchase of a new com put er, a new feat ure becom es available. One disadvant age is t hat t he Bluet oot h t echnology is not seam lessly int egrat ed int o t he syst em , as it would be if included in t he base m anufact ured unit . Thus perform ance m ay not be opt im al, due t o considerat ions such as ant enna placem ent ( which is necessarily on t he PC card it self, or perhaps elsewhere via a cable connect ion; in eit her of t hese cases, fragilit y is one concern) . I n addit ion, PC card slot s on m obile com put ers t ypically are lim it ed t o one or t wo, so a Bluet oot h PC card occupies a slot t hat m ight ot herwise be used for ot her feat ures. I nt erface add- ons provide a sim ilar way t o enable exist ing devices wit h Bluet oot h wireless com m unicat ion. These devices t ypically plug int o an exist ing st andard int erface, such as an RS232 serial port or a USB port . As wit h PC cards, a dongle wit h t he appropriat e prot ocol st ack and driver soft ware can enable t he exist ing int erface t o support Bluet oot h wireless com m unicat ion. From t he syst em 's point of view, t he t raffic is direct ed over t he exist ing port j ust as it would be in a cabled environm ent , but t he int erface add- on t hen receives and t ransm it s t hat dat a over t he Bluet oot h air- int erface. The advant ages and disadvant ages of dongles are sim ilar t o t hose of PC cards: t hey can enable im m ediat e use of t he Bluet oot h t echnology on exist ing devices, but t hey m ight exhibit nonopt im al perform ance and fragilit y while t aking up one of t he syst em 's int erface port s. [ 6] I nt erface add- ons can be const ruct ed for m any t ypes of devices, not j ust com put ers, t hus ( at least t heoret ically) enabling any device t hat export s a st andard int erface t o m ake use of Bluet oot h wireless com m unicat ion. Handheld com put ers, digit al cam eras, print ers, scanners and ot her devices are all candidat es for add- on Bluet oot h solut ions. However, packaging dongles for use on sm all handheld devices m ight in som e cases m ake t he result ing device significant ly larger and less convenient t o use. Dongles for use wit h equipm ent t hat t ypically is st at ionary, such as print ers, scanners and sim ilar devices, t hough, is pot ent ially quit e valuable. [6]

For a USB interface, this latter consideration is minimized through USB's "multi-drop" device attachment scheme.

Because PC cards and int erface add- ons can enable legacy devices t o im m ediat ely ut ilize Bluet oot h t echnology, t hese devices were som e of t he first end- user product s t o appear in 2000. The use of st andard int erfaces, like serial and USB port s, com bined wit h t he freedom from ext ensive elect rom echanical design and packaging as is required for int egrat ed solut ions, m akes t he product ion of t hese legacy device enabling product s relat ively st raight forward.

Computers and Mobile Phones Given t he com posit ion of t he original SI G's prom ot er m em bers, who have significant business int erest s in m obile phones and personal com put ers ( bot h deskt op and m obile) , it is not surprising t hat t hese devices were am ong t he first end- user product s t o have Bluet oot h t echnology int egrat ed int o t hem . All of t he version 1.0 cable- replacem ent usage m odels involve a phone, a com put ing plat form , or bot h. Am ong t he first product s t o be announced and dem onst rat ed were Bluet oot h m obile phones and headset s. Most m aj or m obile phone m anufact urers indicat ed t hat t hey will ship handset s ( and in m any cases, also headset s) wit h Bluet oot h t echnology in 2000. The popularit y of m obile t elephones result s in very high volum e m anufact uring ( in t he hundreds of m illions of unit s) of t hese devices; hence m obile phones are a significant influence on Bluet oot h m odule proliferat ion.

185

I f a significant port ion of m obile phones include Bluet oot h t echnology, t hen hardware cost s can decrease as m anufact uring volum es increase. Achieving lower- cost Bluet oot h m odules t hen enables t heir incorporat ion int o ot her cost - sensit ive devices such as consum er elect ronics ( discussed below) . Com put ers are a key device segm ent for Bluet oot h t echnology. Mobile com put ers, especially, have a high affinit y for Bluet oot h wireless com m unicat ion and are included in several of t he version 1.0 profiles. A num ber of m aj or m obile com put er m anufact urers planned t o incorporat e Bluet oot h t echnology in t heir product s in 2000. Furt herm ore, t hrough t he use of PC cards ( described above) , t he large inst alled base of m obile PCs can be enabled wit h Bluet oot h t echnology in t he short t erm , in addit ion t o int egrat ed solut ions t hat m ay be offered by com put er m anufact urers. Moreover, Bluet oot h wireless com m unicat ion is not j ust for PCs; prot ot ype solut ions for several handheld com put ers were dem onst rat ed at developers conferences in 2000, so t hese devices are also expect ed t o incorporat e Bluet oot h t echnology.

Other Products The init ial m arket place for Bluet oot h wireless com m unicat ion is populat ed by m obile t elephones and com put ers and associat ed accessories and add- on com ponent s for t hese devices. This is not surprising, given t he com posit ion of t he SI G's prom ot er group. But t he com plet e SI G m em bership also includes m anufact urers and soft ware developers from m any indust ries. Given t he SI G's post - version 1.0 work on print ing, st ill im age and aut om ot ive solut ions, we expect t o see Bluet oot h t echnology incorporat ed in print ers, digit al cam eras and aut om obiles in t he foreseeable fut ure. Leading m anufact urers in each of t hese indust ries are act ively part icipat ing in t he SI G, and t here is m om ent um t o produce equipm ent wit h Bluet oot h wireless com m unicat ion capabilit y. As t he t echnology's cost s cont inue t o decrease over t im e, m any consum er elect ronic devices m ay incorporat e Bluet oot h wireless com m unicat ion. Again, wit h leading indust ry players being involved in t he SI G, Bluet oot h devices including t elevisions, st ereos and ot her audiovisual devices are expect ed t o appear in t he m arket place. Chapt er 3 discussed what t he SI G calls " t he ult im at e headset ," which can be used wit h com put ers and m obile t elephones. As ot her audio devices incorporat e Bluet oot h t echnology, such a headset m ight be used wit h port able CD players, aut om obiles, st ereos and ot her such devices, perhaps enabling an " ult im at e ult im at e headset ." Ot her product s in which Bluet oot h t echnology could be used include universal rem ot e cont rols, household appliances and even t oys. Bluet oot h t echnology cert ainly has t he pot ent ial t o be widely deployed in ent erprises, hom es and public venues. Successful int roduct ion of t he first devices can help t o enable posit ive percept ion, user experience and value for users of m any t ypes of devices. We believe t hat Bluet oot h wireless com m unicat ion is well posit ioned t o m ake inroads in m any different devices and m arket places.

186

Chapter 17. Concluding Thoughts I n t his book we have present ed m any facet s of Bluet oot h wireless com m unicat ion. Part 1 int roduced t he t echnology, discussed t he origins of t he SI G and present ed an overview of wireless com m unicat ion concept s leading t o t he developm ent of t he Bluet oot h t echnology and specificat ion. Part s 2 and 3 delved int o t he specificat ion, aim ing t o m ake it m ore accessible and easily underst ood. Our choice of t he t it le for t his book is based upon our endeavor t o reveal t he specificat ion's background and developm ent in addit ion t o int erpret ing it s cont ent s. Part 2 covered t he core specificat ion, or volum e 1, focusing on t he prot ocol st ack. Part 3 addressed volum e 2 of t he specificat ion, t he profiles. We conclude wit h som e forward- looking rem arks about t he direct ions in which Bluet oot h wireless com m unicat ion is likely t o proceed in t he fut ure.

Interoperability The m ot ivat ion for producing profiles—over 400 pages in version 1.0, wit h m ore profiles cont inuing t o be developed—is t o fost er int eroperabilit y. I ndeed, t he form at ion of t he SI G it self was aim ed at developing an open specificat ion wit h backing from leaders in t he com put ing and t elecom m unicat ions indust ries. The SI G is well aware t hat m any prom ising new t echnologies have not gained m arket t ract ion for various reasons, and t he SI G believes, as we do, t hat int eroperabilit y is a key at t ribut e t hat can enable t he init ial and cont inued success of Bluet oot h t echnology. Besides expending t rem endous effort t o develop t he profiles, t he SI G also sponsors ot her act ivit ies geared t oward fost ering int eroperabilit y. Event s called unplugfest s are held from t im e t o t im e. During unplugfest s, vendors can t est t heir Bluet oot h solut ions wit h t hose of ot hers t o det erm ine how well t he different im plem ent at ions int eroperat e. Unplugfest s are inform al gat herings where developers, under nondisclosure agreem ent s and wit hin a spirit of cooperat ion, can j udge t he precision and com plet eness of t heir prot ocol st ack im plem ent at ions. These event s have been popular and have allowed developers t o discuss and t est t heir im plem ent at ions wit h each ot her, helping t o resolve conflict s and work t oward producing robust , int eroperable solut ions. The com pliance t est ing and logo program s provide m ore form al m et hods for t est ing and cert ifying Bluet oot h im plem ent at ions. The cert ificat ion program is not covered in det ail in t his book; a det ailed present at ion could perhaps be a book unt o it self. The com pliance t est ing and logo program s were st ill m at uring in 2000 and are likely t o cont inue t o evolve over t im e. I n general, t hese program s revolve around a process for form al t est ing of a Bluet oot h im plem ent at ion by a SI G- cert ified t est body. The t ypes of t est s vary wit h t he t ype of im plem ent at ion being t est ed. Once a product is cert ified t hrough t he t est ing process, t he product can sport t he Bluet oot h logo ( depict ed in Chapt er 1) as an indicat ion of it s com pliance wit h t he specificat ion. The SI G publishes rules for t he use of t he logo; t hese rules and ot her aut horit at ive inform at ion about com pliance t est ing can be found at t he official Bluet oot h web sit e, ht t p: / / www.bluet oot h.com .

187

Opportunities I nnovat ion is t he lifeblood of t he com put ing and com m unicat ions indust ries. The Bluet oot h t echnology fost ers innovat ion and present s m any opport unit ies t o m any people. First and forem ost is t he value it can provide t o end users in t he form of convenience and new applicat ions of t he t echnology. As t he previous chapt er point ed out , product opport unit ies abound for m anufact urers and soft ware developers. Like m ost new t echnologies, Bluet oot h wireless com m unicat ion present s opport unit ies for educat ion and consult ing by t hose who choose t o becom e im m ersed in t he t echnology. I ndeed, t his book and ot hers on t he t opic are int ended t o educat e and widely dissem inat e inform at ion about t his excit ing new t echnology. This book has not covered every facet of Bluet oot h wireless com m unicat ion—besides t he new subj ect s which will arise as t he t echnology evolves, t here is st ill room for invest igat ing ot her t opics in m ore dept h t han we have done here. Test ing and cert ificat ion, WAP int eroperabilit y, soft ware design and developm ent , silicon and ant enna design and developm ent and ot her subj ect s are all ripe for furt her explorat ion. Wit h a solid and robust foundat ion, except ional indust ry backing, a det ailed specificat ion, t rem endous m om ent um , and dedicat ed product developers worldwide, Bluet oot h wireless com m unicat ion is poised t o becom e a m aj or influence in high- t echnology indust ries. Bluet oot h t echnology has m ade great st rides since it s incept ion, and we believe t hat King Harald would be proud of his nam esake.

Cited References [ BTSI G99] Bluet oot h Special I nt erest Group, Specificat ion of t he Bluet oot h Syst em , version 1.0B, volum es 1 and 2, available from ht t p: / / www.bluet oot h.com , Decem ber 1999. [ ETSI 99] European Telecom m unicat ions St andards I nst it ut e ( ETSI ) SMG4, ETSI TS 101 369 V7.1.0 ( 1999- 11) Technical Specificat ion: Digit al cellular t elecom m unicat ions syst em ( Phase 2+ ) ; Term inal Equipm ent t o Mobile St at ion ( TE- MS) m ult iplexer prot ocol ( GSM 07.10 version 7.1.0 Release 1998) , available from ht t p: / / www.et si.org, 1998. [ FCC99] Federal Com m unicat ions Com m ission, Code of Federal Regulat ions part 15, Tit le 47, volum e 1, available from ht t p: / / www.fcc.gov, revised Oct ober 1, 1999. [ Graham 99] Graham , St eve; Miller, Brent , and Rusnak, Joseph, I BM Corporat ion, Discovering Devices and Services in Hom e Net works, ht t p: / / www.ibm .com / pvc/ t ech/ net working.sht m l, June 1999. [ Haart sen00] Haart sen, J. C., " The Bluet oot h Radio Syst em ," I EEE Personal Com m unicat ions ( special issue on " Connect ivit y and Applicat ion Enablers for Ubiquit ous Com put ing and Com m unicat ions"—C. Bisdikian, J. C. Haart sen, P. Kerm ani, eds.) , vol. 7, no. 1, pp. 28–36, February 2000. [ I AL99] I nvent ors Assist ance League, Hedy Lam arr, ht t p: / / www.invent ion.org/ cult ure/ fem ale/ lam arr.ht m l, 1999. [ I EEE99] I nst it ut e of Elect rical and Elect ronics Engineers, Wireless St andards Package ( 802.11) , available from ht t p: / / www.ieee.org, 1999. [ I ETF92] Part ridge, C., I nt ernet Engineering Task Force Net work Working Group, Request for Com m ent s: 1363, A Proposed Flow Specificat ion, available from ht t p: / / www.iet f.org, 1992.

188

[ I ETF96] Yergeau, F., I nt ernet Engineering Task Force Net work Working Group, Request for Com m ent s: 2044, UTF- 8, a t ransform at ion form at of Unicode and I SO 10646, available from ht t p: / / www.iet f.org, 1996. [ I MC96a] The I nt ernet Mail Consort ium , vCard—The Elect ronic Business Card Exchange Form at , Version 2.1, ht t p: / / www.im c.org/ pdi/ , Sept em ber 1996. [ I MC96b] The I nt ernet Mail Consort ium , vCalendar—The Elect ronic Calendaring and Scheduling Exchange Form at , Version 1.0, ht t p: / / www.im c.org/ pdi/ , Sept em ber 1996. [ I rDA99a] I nfrared Dat a Associat ion, I rDA Obj ect Exchange Prot ocol ( I rOBEX) , Version 1.2, ht t p: / / www.irda.org/ st andards/ pubs/ I rOBEX12.pdf, April 1999. [ I rDA99b] I nfrared Dat a Associat ion, I rMC ( I r Mobile Com m unicat ions) Specificat ion, Version 1.1, ht t p: / / www.irda.org/ st andards/ specificat ions.asp, February 1999. [ I SO96] I nt ernat ional Organizat ion for St andardizat ion in I SO/ I EC 11578: 1996, I nform at ion Technology—Open Syst em s I nt erconnect ion—Rem ot e Procedure Call ( RPC) , available from ht t p: / / www.iso.ch/ , 1996. [ I TU96] I nt ernat ional Telecom m unicat ion Union, Recom m endat ion T.4—St andardizat ion of Group 3 facsim ile t erm inals for docum ent t ransm ission, available from ht t p: / / www.it u.org, July 1996. [ I TU98] I nt ernat ional Telecom m unicat ion Union, Recom m endat ion Q.931—I SDN user- net work int erface layer 3 specificat ion for basic call cont rol, available from ht t p: / / www.it u.org, May 1998. [ I TU99] I nt ernat ional Telecom m unicat ion Union Recom m endat ion V.250—Serial asynchronous aut om at ic dialing and cont rol, available from ht t p: / / www.it u.org, May 1999. [ Met t älä99] Met t älä, Riku, Nokia Mobile Phones, Bluet oot h Prot ocol Archit ect ure, Version 1.0, ht t p: / / www.bluet oot h.com / developer/ download/ download.asp?doc= 172, August 25, 1999. [ Miller99] Miller, Brent and Pascoe, Robert , I BM Corporat ion, Mapping Salut at ion Archit ect ure API s t o Bluet oot h Service Discovery Layer, Version 1.0, ht t p: / / www.bluet oot h.com / developer/ download/ download.asp?doc= 174, July 1, 1999. [ Muller99] Muller, Thom as, Nokia Mobile Phones, Bluet oot h Securit y Archit ect ure, Version 1.0, ht t p: / / www.bluet oot h.com / developer/ download/ download.asp?doc= 174, July 15, 1999. [ Suvak99] Suvak, David, Ext ended Syst em s, I nc., I rDA and Bluet oot h: A Com plem ent ary Com parison, ht t p: / / www.ext endedsyst em s.com / prodinfo/ whit e/ bt % 5Fvs% 5Fir.ht m l, 1999.

189