BLUETOOTH SPECIFICATION Version 1.0 B
`
`Service Discovery Protocol
`
`page 375 of H382
`
`Bluetunth.
`
`B.3. SDP Example 3 — ServiceSearchAttributeTransaction
`
`The third example is a form of service browsing, although it is not generic
`browsing in that it does not make use of SDP browse groups. Instead, an SDP
`client is searching for available Synchronization services that can be presented
`to the user for selection. The SDP client does not specify a particular type of
`synchronization service. In the example. the SDP server has three available
`synchronization services: an address book synchronization service and a cal-
`endar synchronization service (both from the same provider), and a second
`calendar synchronization service from a different provider. The SDP client is
`retrieving the same attributes for each of these services; namely, the data for-
`mats supported for the synchronization service (vCard, vCal. |Ca|. etc.) and
`those attributes that are relevant for presenting information to the user about
`the services. Atso assume that the maximum size of a response is 400 bytes.
`Since the result is larger than this, the SDP client will repeat the request sup-
`plying a continuation state parameter to retrieve the remainder of the response.
`The transaction illustrates:
`
`1. SDP client to SDP sen/er: 8DP_ServiceSearchAttributeRequest. specifying
`the generic SynchronisationServiceClasslD (represented as a data element
`whose 32-bit UUID value is see. . .sss) as the only element of the Service-
`SearchPattern. The SynchronisationserviceclasslD is assumed to be a 32-
`bit UUID. The requested attributes are the ServiceRecordHandle (attribute
`ID UXUUUU). ServiceC|asslDList (attribute ID OxODO1), |conURL (attribute ID
`OXOUOC), SenriceName (attribute ID 0xO1D0). ServiceDescription (attribute
`ID 0x0101). and ProviderName (attributelD 0x0102) attributes; as well as
`the service-specific SupportedDataStores (AttributelD 0xO301). Since the
`first two attribute IDs (OXUOOD and OXUOO1) and three other attribute
`lDs(0xO100. Ox0101. and 0x0102 are consecutive, they are specified as
`attribute ranges. The TransactionlD is illustrated as vvw to distinguish it
`from the TransactionlDs of the other Examples.
`
`Note that values in the service record's primary language are requested for
`the text attributes (ServiceName. ServiceDescription and ProviderNarne) so
`that absolute attribute IDs may be used. rather than adding offsets to a base
`obtained from the LanguageBaseAttributelDList attribute.
`
`. SDP server to SDP client: SDP_ServiceSearchAttributeResponse. returning
`the specified attributes for each of the three synchronization services. In the
`example, each Sen/iceClasslDList is assumed to contain a single element,
`the generic SynchronisationServiceClass|D (a 32-bit UUID represented as
`sss...sss)- Each of the other attributes contain illustrative data in the exam-
`ple (the strings have illustrative text; the icon URLs are illustrative. for each
`of the respective three synchronization services; and the SupportedDataS-
`tore attribute is represented as an unsigned 8-bit integer where 0x01 =
`vCard2.1, 0x02 = vCard3.0, 0x03 = vCal1.0 and 0x04 = lCa|). Note that one
`of the service records (the third for which data is returned) has no Service-
`Description attribute. The attributes are returned as a data element
`sequence, where each element is in turn a data element sequence repre-
`
`29 November 1999
`
`Appendix
`
`AFFLT0293604
`
`Samsung Ex. 1316 p. 376
`
`

`
`AFFLT0293605
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 377 of ICIBZ’
`
`Service Discovery Protocol
`
`senting a list of attributes. Within each attribute list. the ServiceC|asslDList is
`a data element sequence while the remaining attributes are single data ele-
`ments. The Transaction ID is the same value as supplied by the SDP client
`in the corresponding request (trirotoro). Since the entire result cannot be
`returned in a single response. a non-null continuation state is returned in this
`first response.
`
`Note that the total length of the initial data element sequence (48? in the
`example) is indicated in the first response, even though only a portion ofthis
`data element sequence (368 bytes in the example. as indicated in the
`AttributeLists byte count) is returned in the first response. The remainder of
`this data element sequence is returned in the second response (without an
`additional data element header).
`
`. SDP client to SDP server: SDP_ServiceSearchAttributefiequest. with the
`same parameters as in step 1. except that the continuation state received
`from the server in step 2 is included as a request parameter. The Transac-
`tionlD is changed to romcocu to distinguish it from previous request.
`
`. SDP server to SDP client: SDP_ServiceSearchAttributeResponse. with the
`remainder of the result computed in step 2 above. Since all of the remaining
`result fits in this second response, a null continuation state is included.
`
`/* Part 1 —— Sent
`
`from EDP Client
`
`to SD? server */
`
`SdpSDP_SerViceSea.rchAttributeReq'L1est[33]
`PDUID[1]
`{
`GXOIS
`
`{
`
`1-
`TransactionID[2]
`Elxtnnrv
`
`{
`
`} P
`
`arameterLengr.h[2]
`UXUUIB
`
`{
`
`} S
`
`erviceSea.rc:hPe.‘i;t:ern['I']
`Da.I:aE1ementSequer1::e['?]
`Clbflcillfl Db-101 DXD5
`
`{
`
`{
`
`{
`Uuloisi
`/* Synchronieations-e11riceCla.ssID *_/'
`Obflflflll Dbfllfl 0:-(assesses
`
`i
`
`1'
`
`} M
`
`aximumettributeflytecount[2]
`0x0l9Cl
`
`{
`
`}
`{
`Al:tributeIDList[18]
`De.I:aEle-memzsequen-:e[18]
`0bUD1lt'J 013101 03:10
`
`{
`
`{
`At:tribut.eIDRange[5J
`01300001 Dbulfi UXDGDDUGU1
`
`} A
`
`{
`t:t'.ributeID[3]
`Ob|DC|'DO1 Dbflfll DXDCIDC
`
`29 November 1999
`
`Samsung Ex. 1316 p. 377
`
`

`
`AFFLT0293606
`
`BLUETCJOTH SPECIFICATION Version 1.0 B
`
`page 378 of 1882
`
`Service Discovery Protocol
`
`} A
`
`[
`ttributelDRange[5]
`0b000Ul Obfilfl UXOIDUDIU2
`
`}A
`
`}
`
`{
`ttributeIDI3]
`oboooo1 Dbflfll Ox0301
`
`}
`
`{
`ontinuationState{l]
`/* no continuation state */
`UXUO
`
`}C
`
`}
`
`} /
`
`* Part 2 -- Sent from SDP server to EDP client */
`SdpSDP_ServiceSearchAttributeResponse[384]
`{
`PDUID[1]
`{
`OX0?
`
`} T
`
`ransactionlD[2]
`Oxvvvv
`
`{
`
`}P
`
`aram-=:terL-3-ng th [2]
`OXUITB
`
`{
`
`} A
`
`ttributeListEyt:eCountI2]
`DxD170
`
`{
`
`} A
`
`{
`ttributeLists{3EB]
`DataE1ementSequence[487]
`Obflflllfl Ubllfl OXUIE4
`
`{
`
`DataE1ementSequence[l?8]
`Dhflflllfl Dhlfll DXBD
`
`{
`
`{
`Jéttribut-e[8]
`{
`AttributeID[3]
`DhDDODl DbD01 UXDDDO
`
`}A
`
`}
`
`{
`ttributeVa1ue[5]
`/* service record handle */
`Obflflflfll Dbfllfl Dxhhhhhhhh
`
`} A
`
`{
`ttributeflfi]
`{
`AttributeID[3]
`DbOOD0l ObOD1 0xOOOl
`
`}
`{
`A:tributeva1ue[1]
`DataElementSequence[T} {
`oboo11o Oblfll 0x05
`
`{
`UUIDISJ
`/* Synchronisationserviceclasslfl */
`0b0OO11 Obfllfl Dxasssssss
`
`29 November 1999
`
`}
`
`}
`
`}
`
`} A
`
`ttribute[35]
`
`{
`
`Samsung Ex. 1316 p. 378
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 379 of 1032
`
`Service Discovery Protocol
`
`{
`AttributeID[3]
`obaonol oboal 0xDDUC
`
`Bluetooth.
`
`}A
`
`}
`
`ttributeVa1ue[321 {
`/* Icor1URL;
`‘*’
`replaced by client application */
`012301000 Db101 DXIE
`
`"http://synchronisation/icons/*"
`
`}A
`
`{
`ttribute[22]
`{
`AttributeID[3l
`obooool oboe; DxDlOO
`
`}A
`
`}
`
`{
`ttributeva1ue[19]
`/* service name */
`Obflfllflfl flblfll 0x11
`
`“Address Book Sync"
`
`} A
`
`{
`ttribute[59]
`{
`AttributeID[3]
`DbUDD0l UbDC|l Dx0101
`
`} A
`
`}
`
`{
`ttributeVa1ua[56]
`/* service description */
`U'b0U1U'U Dblfll CD136
`
`"synchronisation Service for"
`" VCard Address Book Entries"
`
`} A
`
`ttIibute[37} {
`{
`AttributeID[3]
`obonnol obon1 DxD1fl2
`
`} A
`
`{
`ttributeVa1ue[34]
`/* service provider */
`{‘.|bElD1OU 013101 0x20
`
`"synchronisation Specialists Inc."
`
`}
`}
`{
`Attribute[5]
`{
`Attribu:eID[3]
`nboouol nbou1 Dx03D1
`
`} A
`
`}
`
`}
`
`{
`ttributeVa1ue[2]
`f* Supported Data Store 'phonebock' */
`01300001 Dbflflfl 0x01
`
`} D
`
`ataElementSequence[l75]
`Db00l1G Oblfll D:-LI-ED
`
`{
`
`{
`Attribute[8]
`{
`AttributeID[3]
`oboonol ubna1 oxoono
`
`At tributevalue [5]
`
`{
`
`29 November 1999
`
`AFFLT0293607
`
`Samsung Ex. 1316 p. 379
`
`

`
`AFFLT0293608
`
`BLUETCJOTH SPECIFICATION Version 1.0 B
`
`page 380 of 1882
`
`Service Discovery Protocol
`
`Bluetnnth.
`
`/* service record handle */
`0bOD00l Obolfl Uxmmmmmmmm
`
`}
`
`} A
`
`{
`ttributeflfi]
`{
`AttributeID[3]
`0bO0D01 Obflfll OXOOUI
`
`}
`
`}
`
`At:tributeValue[';']
`DataElementSequence[7]
`{
`Obflflllfl Dblfll 0x05
`
`{
`
`{
`UUID[5]
`/* Synchronisa1:ionServiceClassID */
`Dbflflflll Db01O Gxssssssss
`
`}
`
`1
`
`} A
`
`{
`ttributeI35]
`{
`AttributeID[3]
`0bDO00l Ob001 0xDODC
`
`}A
`
`}
`
`{
`t I:ributeVa1ue[3 2]
`replaced by client application */
`/* IconURL;
`'*'
`0bO1000 Dblfll UXIE
`
`" http: / /Synchronisation/iconw * "
`
`} A
`
`{
`ttribute[2l]
`{
`AttributeID[3]
`0bUUD0l Ubofll UXUICO
`
`} A
`
`}
`
`{
`ttrihuteValue[l8]
`/* service name */
`UbUUlU0 Ublfil 0X10
`
`"Appointment Sync"
`
`} A
`
`{
`ttributeI57]
`{
`AttributeID[3]
`Ob0D001 obnoi oxoioi
`
`} A
`
`}
`
`{
`ttributeValue[54]
`{* service description */
`Ub0U1DD Gblfll 0x34
`
`"synchronisation Service for“
`" vcal Appointment Entries"
`
`}A
`
`{
`ttribute [37]
`{
`AttributeID[3]
`UbUUU0l Ubofll UXUIDZ
`
`} A
`
`{
`ttributeValue[34]
`/* service provider */
`UbUDl0D Dblfll DXZD
`
`"synchronisation Specialists Inc."
`
`29 November 1999
`
`Samsung Ex. 1316 p. 380
`
`

`
`AFFLT0293609
`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 361 of "1082
`
`Service Discovery Protocol
`
`}
`
`} A
`
`{
`ttributelfil
`At:rihuteID[3} {
`DbOOO0l GbDO1 DxU301
`
`} A
`
`}
`
`}
`
`{
`ttributeVa1ue[2]
`/* Supported Data Store ‘calendar’ */
`nbooool Dbono 0x03
`
`}
`/* } Data element sequence of attribute lists */
`/* is not completed in this PDU. */
`
`} C
`
`}
`
`{
`ontinuationState[9]
`/* 8 bytes of continuation state */
`0x08 Oxzzzzzzzzzzzzzzzz
`
`} /
`
`to SDP server */
`* Part 3 -- Sent from SDP Client
`SdpSDP_ServiceSearchAttributeRequeet[41]
`{
`PDUID[1]
`{
`0x06
`
`} T
`
`ransactionID[21 {
`Dxwwww
`
`} P
`
`arameterLength[2]
`OXDOZ4
`
`{
`
`}S
`
`erviceSearchPattern[7]
`DataElementSequence[7]
`Ob0U'l10 Dblfll DXD5
`
`{
`
`{
`
`{
`UUIDIS]
`/* SynchronisationServiceClas5ID */
`Db00D11 Obolfl Dxsssessss
`
`}
`
`}
`
`} M
`
`aximumAttributeByteCount[2]
`DXUIBU
`
`{
`
`{
`Attribute1DList[1a]
`DataE1ementSequenoe[18]
`ObODllD Ohlfll Dxlfl
`
`{
`
`{
`AttributeIDRange[5]
`Ub0C|IDU1 013010 UXUOBODUCI1
`
`} A
`
`{
`ttributeID[3]
`Db00001 Dbfifll DXDODC
`
`} A
`
`{
`ttributaIDRange[5]
`Dbflflflfll Dbfllfl 0x01000102
`
`} A
`
`ttribut.eID[3]
`
`{
`
`Appendix
`
`29 November 1999
`
`Samsung Ex. 1316 p. 381
`
`

`
`AFFLT0293610
`
`BLUETCJOTH SPECIFICATION Version 1.0 B
`
`page 382 of 1882
`
`Service Discovery Protocol
`DbG0OO1 Dbflfll Ox0301
`
`}
`
`}
`
`} C
`
`}
`
`-[
`ont inuationstate [9]
`/* same 3 bytes of continuation state */
`/* raceived in part 2 */
`DXD8 Dxzzzzzzzzzzzzzzzz
`
`} P
`
`art 4 —— Sent
`
`from SDP server to SDP client
`
`SdpSDP_SerViceSearchAttIibuteResponse[115]
`PDUIDI1]
`{
`Dxfl?
`
`{
`
`} T
`
`ransactionID[2]
`Dxwwww
`
`{
`
`} P
`
`aramaterLength[2]
`UXUUGE
`
`{
`
`} A
`
`ttributeListByteCountI2]
`UXUOGB
`
`{
`
`} A
`
`{
`t:ributeLists[1o7]
`/* Continuing the data element sequence of */
`/* attribute lists begun in Part 2. */
`DataElementSequence[lO?} {
`0b0DllU Dblfll UXE9
`
`{
`Attribute[8]
`{
`AttributeID[3]
`0bUUOU1 UbD0l OXOUUU
`
`}A
`
`}
`
`ttributeValue[S} {
`/* service record handle */
`UbUOD0l UbUlD Dxffiffffff
`
`} A
`
`{
`ttributa[10]
`{
`AttributeID[3]
`UbODUDl Ubflfll UXDDDI
`
`} A
`
`{
`ttributeVa1ue[7]
`DataElementSequence[7]
`Dbflflllfl Ublfll DXU5
`
`{
`
`{
`UUID[5]
`/* SynchronisationServiceCla3sID */
`Dbflflflll Dbfllo Dxssssssss
`
`}
`
`}
`
`}
`
`} A
`
`{
`ttribuI:e[35]
`{
`At-.:ribute1D[3]
`obooool Dbofll oxnooc
`
`29 November 1999
`
`Samsung Ex. 1316 p. 382
`
`

`
`BLUETCJOTH SPECIFICATION Version 1.0 B
`
`page 383 of'1C:B2
`
`Service Discovery Protocol
`
`} A
`
`}
`
`{
`ttributeValue[32]
`replaced by client application *f
`/* IconURL;
`’*'
`Db010UD Ublfll DXIE
`
`"http : :’/DevManufa::turer/ icons 1”"
`
`} A
`
`ttribute[lB} {
`{
`AttributeID[3]
`01300001 015001 0:-(0100
`
`} A
`
`}
`
`{
`ttributeValue[l5]
`/* Service name */
`01300100 0b101 0x0D
`
`"Calendar Sync"
`
`} A
`
`{
`ttribute[29]
`{
`AttributeID[3]
`01300001 013001 Dx0102
`
`} A
`
`}
`
`{
`ttributeVa.1ue[26]
`/* service provider */
`0b00100 010101 0}-C13
`"Device Manufacturer Inc."
`
`} A
`
`{
`ttributeffi]
`{
`AttributeID[3]
`01300001 DbD01 0x03-O1
`
`} A
`
`{
`ttributeValue[2]
`/* Supported Data Store ‘calendar’ */
`0b0000l 013000 UXU3
`
`/* This completes the data element sequence *f
`/* of attribute lists begun in Part 2.
`
`} C
`
`}
`
`}
`
`{
`ontinuationState[l]
`/* no continuation state *2‘
`0x00
`
`29 November 1999
`
`AFFLT0293611
`
`Samsung Ex. 1316 p. 383
`
`

`
`BLUETOOTH SPECWICATION Version 1.0 B
`
`page 384 of 1382
`
`Service Discovery Protocol
`
`29 November 1999
`
`AFFLTO293512
`
`Samsung Ex. 1316 p. 384
`
`

`
` I=coMM with TS 07.10
`
`Serial Port Emulation
`
`3:
`
`'
`
`col b speci
`
`ing a subset ofthe ETSI TS 07.10
`
`‘ Thisbocum 'nt specifies the RFCOMM proto-
`stagiard, al ng with some Bluetooth-specific
`
`ad
`
`tation
`
`5
`
`AFFLTD293513
`
`Samsung Ex. 1316 p. 385
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 386 of 1082
`
`RFCOMM with T5 07.10
`
`29 November 1999
`
`AFFLTO293614
`
`Samsung Ex. 1316 p. 386
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 387 uf1D82
`
`RFCOMM with TS 07.10
`
`CONTENTS
`
`Imroducfiimn .....................................................................
`1.1
`Overview
`
`............ "389
`
`‘L2
`
`‘$.13
`
`ifievace Types ..............................................................
`
`........ ..38Q
`
`Byie (Bra:-mrsg ......................................................................... ..39{}
`
`RFCGMM $enr§ca Gvarview
`
`........ ..,...39‘E
`
`2.’!
`2.2
`
`2.3
`
`F-‘€53-232 C-antrrzi
`Nui! Msnciem Enmiation ........................................................... "391
`
`?v§=.ei11';t3$e E.rr1=..aiated Sena:
`2.3.?
`iviuitipie E.rna.:%ated Seriai Par? bet*.vee.n two Devi::es..
`
`2.3.2 Maxiiipie Emksiateri Saris? Paris and Muéiipie EST
`
`Service interface i1}as<:£iption .....................................................
`3.1
`Service Definitian Modei
`
`TS 9?’.10 Subset Surppertesi by RFCQME
`4.‘!
`Qptaorls and Mczdes
`
`4.2
`
`e'—":'.ame T',:p:=.=sa.....
`
`..
`
`.
`
`4.4
`
`Convergence
`
`‘ES 611$ Aetiaptaiéans for
`
`..
`
`. .......3§8
`
`5.1 Media Adaptatizm
`5.1.1
`FCScaEr:1.J£atir:«n...........................................................398
`
`5.2
`
`TS {‘.I?.1{} Evhjiiipiexer Start-up and Ctosedawra Pr0ce«:Eure.......39§
`5.2.‘?
`S§ar1.-up
`
`13.2.2 Ciase-down
`
`5-2.3
`
`Link 1055 handfing ....................................
`
`...............
`
`System
`DLCE ailcscation wiii“. RFEOMM sewer‘ ::har!neis......................<$C={}
`
`................ ..4-Q’?
`.................
`?-;‘;=.m.i_:>iexse.~r Curatmi Cr:-mm:»31r:ds. ......
`5.5.1
`Remote For: Negotiation Command {RPM}
`
`55.5.2
`
`Remotes Line Estattss Comfiiand {RLS}-,.......,,..............-$02
`
`5.5.3
`
`DLC parameter negoiiatian
`
`How Contra! ................................................................................... "$63
`
`8."!
`
`LECAP Fiow Ccmtrcui in
`
`5.2 Wired Seria£ Port Firm!
`
`F‘aF(30?v%M Féaw
`
`(5.4
`
`Fort Emuiatican Entity Seriai Fiow Contra!
`
`29 November 1999
`
`AFFLT0293615
`
`Samsung Ex. 1316 p. 387
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 388 of 1082
`
`RFCOMM with TS 07.10
`
`'3'
`
`mfieractéan with Gthes‘ Entities
`
`7.1
`
`Part §:EmuIs.=tir;n .':‘~.n::' Fur? 1"-‘mxy
`?.1.'3
`PcsrtiirnuiaginnEEmity...__,..............._..,......._.._....._.....,..405
`
`?.‘i.2
`
`F'c3rtPr<.3xyEntiiy... ......
`
`........
`
`...........
`
`......
`
`ffiervécéz Ragisiraiéon and Disccwery ....................................... ..40f:'-
`
`L{3ws~3:- Layer Depeandencias ................................................... ..c%O'?
`3’. 3.?
`Reétabiiiry ................................................................ . .45?
`
`7.3.2
`
`Lt.-w gmwer m0(Jes5..........
`
`.45?
`
`“Emma and Abbraviatinns ...............................
`
`............................ “ms
`
`29 November 1999
`
`AFFLT0293616
`
`Samsung Ex. 1316 p. 388
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 389 of 1082
`
`RFCOMM with rs 07.10
`
`1
`
`INTRODUCTION
`
`Bluetoofll
`
`The RFCOMM protocol provides emulation of serial ports over the LZCAP pro-
`tocol. The protocol is based on the ETSI standard TS 07.10. This document
`does not contain a complete specification. Instead. references are made to the
`relevant parts of the TS 07.10 standard. Only a subset of the TS 07.10 stan-
`dard is used, and some adaptations of the protocol are specified in this docu-
`ment.
`
`1.1 OVERVIEW
`
`RFCOMM is a simple transport protocol, with additional provisions for emulat-
`ing the 9 circuits of RS-232 (EIATIA-232-E) serial ports.
`
`The RFCOMM protocol supports up to 60 simultaneous connections between
`two BT devices. The number of connections that can be used simultaneously in
`a BT device is implementation-specific.
`
`1.2 DEVICE TYPES
`
`For the purposes of RFCOMM. a complete communication path involves two
`applications running on different devices (the communication endpoints) with a
`communication segment between them. §"-"rgue’e-“.= ‘Lt shows the complete com-
`munication path. (ln this context. the term appiicarion may mean other things
`than end—user application; e.g. higher layer protocols or other services acting
`on behalf of end-user applications.)
`
`Device A
`
`Communication
`Segment
`
`Application
`Device E
`
`Figure 1.1: RFCOMM Communication Segment
`
`RFCOMM is intended to cover applications that make use of the serial ports of
`the devices in which they reside. In the simple configuration, the communica-
`tion segment is a BT link from one device to another (direct connect), see
`iirgure 1.2. Where the communication segment is another network. ET is used
`for the path between the device and a network connection device like a
`modern. RFCOMM is only concerned with the connection between the devices
`in the direct connect case, or between the device and a modem in the network
`
`case. RFCOMM can support other configurations, such as modules that com-
`municate via BT on one side and provide a wired interface on the other side. as
`shown in r'—"igur'e 1.3. These devices are not really modems but offer a similar
`service. They are therefore not explicitly discussed here.
`
`Introduction
`
`29 November 1999
`
`AFFLT0293617
`
`Samsung Ex. 1316 p. 389
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 390 of 1082
`
`RFCOMM with TS 07.10
`
`Bluetuuth.
`
`Basically two device types exist that RFCOMM must accommodate. Type 1
`devices are communication end points such as computers and printers.
`Type 2 devices are those that are part of the communication segment; e.g.
`modems. Though RFCOMM does not make a distinction between these two
`device types in the protocol, accommodating both types of devices impacts the
`RFCOMM protocol.
`
`Figure 1.2.‘ RFCOMM Direct Connect
`
`Figure 1.3: RFCOM.-‘vi used with iegacy COMM device
`
`The information transferred between two RFCOMM entities has been defined
`
`to support both type 1 and type 2 devices. Some information is only needed by
`type 2 devices while other information is intended to be used by both. In the
`protocol, no distinction is made between type 1 and type 2. It is therefore up to
`the RFCOMM implementers to determine if the information passed in the
`RFCOMM protocol is of use to the implementation. Since the device is not
`aware of the type of the other device in the communication path, each must
`pass on all available information specified by the protocol.
`
`1.3 BYTE ORDERING
`
`This document uses the same byte ordering as the TS 07.10 specification; i.e.
`all binary numbers are in Least Significant Bit to Most Significant Bit order.
`reading from left to right.
`
`29 November 1999
`
`Introduction
`
`AFFLT029361 B
`
`Samsung Ex. 1316 p. 390
`
`

`
`BLUETDOTH SPECIFICATION Version 1.0 B
`
`page 391 of 1032
`
`RFCOMM with TS 07.10
`
`Bluetooth.
`
`2 RFCOMM SERVICE OVERVIEW
`
`RFCOMM emulates RS-232 (EIATIA-232-E) serial ports. The emulation
`includes transfer of the state of the non-data circuits. RFCOMM has a built-in
`scheme for null modem emulation.
`
`in the event that a baud rate is set for a particular port through the RFCOMM
`service interface, that will not afiect the actual data throughput in RFCOMM;
`i.e. RFCOMM does not incur artificial rate limitation or pacing. However, if
`either device is a type 2 device (relays data onto other media), or if data pacing
`is done above the RFCOMM service interface in either or both ends, actual
`
`throughput will. on an average. reflect the baud rate setting.
`
`RFCOMM supports emulation of multipie serial ports between two devices and
`also emulation of serial ports between multiple devices, see Section
`or:
`page 393.
`
`2.1 RS-232 CONTROL SIGNALS
`
`RFCOMM emulates the 9 circuits of an RS-232 interface. The circuits are listed
`below.
`
`Circuit Name
`
`Signal Common
`
`Transmit Data (TD)
`
`Received Date {RD}
`
`Request to Send (RTS)
`
`Clear to Send (CTS)
`
`Data Set Ready (DSR)
`
`Data Terminal Ready (DTRJ
`
`Date Carrier Detect (CD)
`
`Ring indicator {RI}
`
`Table 2.1: Emulated RS-232 circuits in RFCOMM
`
`2.2 NULL MODEM EMULATION
`
`RFCOMM is based on T3 07.10. When it comes to transfer of the states of the
`
`non-data circuits. TS 07.10 does not distinguish between DTE and DCE
`devices. The RS-232 control signals are sent as a number of DTEIDCE inde-
`pendent signals, see Taste 2.2.
`
`RFCDMM Service Overview
`
`29 November 1999
`
`AFFLTU293619
`
`Samsung Ex. 1316 p. 391
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 392 of 1082
`
`RFCOMM with T5‘ 07.10
`
`Bluetooth.
`
`TS 07.10 Signals
`
`Corresponding RS-232 Control Signals
`
`DSR. DTR
`
`RTS. CTS
`
`RI
`
`Table 2.2: T8 0?. 10 Serial Port Control Signals
`
`The way in which TS 07.10 transfers the RS-232 control signals creates an
`implicit null modem when two devices of the same kind are connected together.
`Figure 2.1 shows the null modem that is created when two DTE are connected
`via RFCOMM. No single nu||—modem cable wiring scheme works in all cases;
`however the null modem scheme provided in RFCOMM should work in most
`cases.
`
`l\.Il\J03--.JO\U'|iv|hLuJl\Jl-'
`
`1 2 34 5 6 7 82 2
`
`[U0
`
`Figure 2.1’: RFCOMM DTE—DTE Null Modem Emulation
`
`29 November 1999
`
`RFCOMM Service Overview
`
`AFFLT0293520
`
`Samsung Ex. 1316 p. 392
`
`

`
`BLUETDOTH SPECIFICATION Version 1.0 B
`
`page 393 of 1082
`
`RFCOMM with TS 07.10
`
`Bluetouth‘
`
`2.3 MULTIPLE EMULATED SERIAL PORTS
`
`2.3.1 Multiple Emulated Serial Ports between two Devices
`
`Two BT devices using RFCOMM in their communication may open multiple
`emulated serial ports. RFCOMM supports up to 60 open emulated ports:
`however the number of ports that can be used in a device is implementation-
`specific.
`
`A Data Link Connection Identifier (DLCI) {E} identifies an ongoing connection
`between a client and a server application. The DLCI is represented by 6 bits,
`but its usable value range is 2...61; in T3 07.10, DLCI 0 is the dedicated con-
`trol channel. DLCI 1 is unusable due to the concept of Server Channels. and
`DLCI 62-63 is reserved. The DLCI is unique within one RFCOMM session
`between two devices. (This is explained further in Section
`To account for
`the fact that both client and server applications may reside on both sides of an
`RFCOMM session. with clients on either side making connections independent
`of each other. the DLCI value space is divided between the two communicating
`devices using the concept of RFCOMM server channels. This is further
`described in Section 5:3.
`
`Emulated serial ports
`
`Emulated serial ports
`
`*1.---._...._________-.___._-__)
`
`Figure 2.2: Multiple Emuiated Serial Ports.
`
`2.3.2 Multiple Emulated Serial Ports and Multiple BT Devices
`
`If a BT device supports multiple emulated serial ports and the connections are
`allowed to have endpoints in different BT devices, then the RFCOMM entity
`must be able to run multiple TS 07.10 multiplexer sessions. see Figure 2.3.
`Note that each multiplexer session is using its own LZCAP channel ID (CID).
`The ability to run multiple sessions of the TS 07.10 multiplexer is optional for
`RFCOMM.
`
`RFCOMM Service Overview
`
`29 November 1999
`
`AFFLTD293521
`
`Samsung Ex. 1316 p. 393
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 394 of 1082
`
`RFCOMM with TS 07.10
`
`Figure 2.3: Emularing serial ports coming from two BTdew'ces.
`
`29 November 1999
`
`RF-COMM Service Overview
`
`AFFLTD293622
`
`Samsung Ex. 1316 p. 394
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`RFCOMM with TS 07.10
`
`page 395 of 1082
`
`Bluetooth_
`
`3 SERVICE INTERFACE DESCRIPTION
`
`RFCOMM is intended to define a protocol that can be used to emulate serial
`ports. in most systems. RFCOMM will be part of a port driver which includes a
`serial port emulation entity.
`
`3.1 SERVICE DEFINITION MODEL
`
`The figure below shows a model of how RFCOMM fits into a typical system.
`This figure represents the RFCOMM reference model.
`
`Port Emulation Entity
`
`Serv'ce
`I
`registraiionidiscovery
`
`General control parameters
`Port parameter settings
`
`Data ITXRXI
`
`RFC OMM
`' Service Interface
`
`RFCOMM
`
`Basebend
`
`Figure 3. 1: RFCOMM reference model!
`
`The elements of the RFCOMM reference model are described below.
`
`Element
`
`Description
`
`Application
`
`Port Emulation
`
`Entity
`
`RFCOMM
`
`Applications that utilize a serial port communication Interface
`
`The port emulation entity maps a system-specific communication
`interface (API) to the RFCOMM services. The port emulation entity
`plus RFCOMM make up a port driver
`
`Provides a transparent data stream and control channel over an
`L2CAP channel. Mulliplexes multiple emulated serial ports
`
`Service Registra-
`lioni Discovery
`
`Server applications register here on local device. and it provides ser-
`vices for client applications to discover how to reach server applica-
`tions on other devices
`
`LZCAP
`
`Eiaseband
`
`Protocol multiplexing, SAR
`
`Baseband protocols defined by BT
`
`Service Interface Description
`
`29 November 1999
`
`AFFLT0293523
`
`Samsung Ex. 1316 p. 395
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`RFCOMM with TS 07.10
`
`page 396 of 1082
`
`Bluetooth.
`
`4 TS 07.10 SUBSET SUPPORTED BY RFCOMM
`
`4.1 OPTIONS AND MODES
`
`RFCOMM uses the basic option of TS 07.10.
`
`4.2 FRAME TYPES
`
`Talzie 4.1 shows the TS 7.10 frame types that are supported in RFCOMM.
`
`Frame Types
`
`Set Asynchronous Balanced Mode (SABM} command
`
`Unnumbered Acknowledgement (UA) response
`
`Disconnected Mode {DM} response
`
`Disconnect (DISC) command
`
`Unnumbered information with header check (UIH) command and response
`
`Table 4.1: Supported frame types in RFCOMM
`
`The 'Unnumberecl information (Ul) command and response‘ are not supported
`by RFCOM M. Since the error recovery mode option of the TS 07.10 protocol is
`not used in RFCOMM none of the associated frame types are supported.
`
`4.3 COMMANDS
`
`TS 07.10 defines a multiplexer that has a dedicated control channel. DLCI 0.
`The control channel is used to convey information between two multiplexers.
`The following commands in T8 07.10 are supported by RFCOMM:
`
`Supported control Channel Commands
`
`Test Command (Test)
`
`Flow Control On Command (Fcon)
`
`Flow Control Off Command (Fooff)
`
`Modem Status Command (MSC)
`
`Remote Port Negotiation Command (RPN)
`
`Remote Line Status (RLSJ
`
`DLC parameter negotiation (PN)
`
`Non Supported Command Response {NSC}
`
`Whenever a non-supported command type is received a ‘Non-Supported Com-
`mand Response (NSC)‘ should be sent.
`
`29 November 1999
`
`TS 07.10 Subset Supported by RFCOMM
`
`AFFLT0293524
`
`Samsung Ex. 1316 p. 396
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 397 of 1082
`
`RFCOMM with TS 07.10
`
`4.4 CONVERGENCE LAYERS
`
`Bluetouth.
`
`RFCOMM only supports the type 1 convergence layer in T3 07.10.
`
`The Modern Status Command (MISC) shall be used to convey the RS-232
`control signals and the break signal for all emulated serial ports.
`
`TS 01.10 Subse! Supported by RFCOMM
`
`29 November 1999
`
`AFFLT0293625
`
`Samsung Ex. 1316 p. 397
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 398 of 1082
`
`RFCOMM with TS 07.10
`
`Bluetunth.
`
`5 TS 07.10 ADAPTATIONS FOR RFCOMM
`
`5.1 MEDIA ADAPTATION
`
`The opening flag and the closing flags in the 07.10 basic option frame are not
`used in RFCOMM. instead it is only the fields contained between the flags that
`are exchanged between the L2CAP layer and RFCOMM layer, see Flgisre 5.1.
`
`Add ress
`
`1 octet
`
`Length
`Ind lcator
`
`1 or 2 octets
`
`I nformation
`
`Unspecified length
`but integral number
`of octets
`
`Figure 5.1: Frame Structure for Basic option. Note that the opening and ctosing flags from the
`07.10 Basic option are excluded in RFCOMM.
`
`5.1.1 FCS calculation
`
`In 07.10. the frame check sequence (FCS) is calculated on different sets of
`fields for different frame types. These are the fields that the FCS are calculated
`on.
`
`For SABM. DISC. UA. DM frames: on Address. Control and length field.
`
`For UIH frames: on Address and Control field.
`
`(This is stated here for clarification. and to set the standard for RFCOMM; the
`fields included in FCS calculation have actually changed in version 7.0.0 of TS
`07.10, but RFCOMM will not change the FCS calculation scheme from the one
`above.)
`
`29 November 1999
`
`TS 07.10 Adaptations for RFCOMM
`
`AFFLT0293626
`
`Samsung Ex. 1316 p. 398
`
`

`
`BLUETDOTH SPECIFICATION Version 1.0 B
`
`page 399 of 1082
`
`RFCOMM with TS 07.10
`
`5.2 TS 07.10 MULTIPLEXER START-UP AND CLOSEDOWN
`
`PROCEDURE
`
`The start-up and closedown procedures as specified in section 5.7 in T8 07.10
`are not supported. This means that the AT-command AT+CMUX is not sup-
`ported by RFCOMM, neither is the multiplexer close down (CLD) command.
`
`At any time, there must be at most one RFCOMM session between any pair of
`devices. When establishing a new DLC, the initiating entity must check if there
`already exists an RFCOMM session with the remote device, and if so, establish
`the new DLC on that. A session is identified by the Bluetooth BD_ADDR of the
`two endpoints‘.
`
`5.2.1 Start-up procedure
`
`The device opening up the first emulated serial port connection between two
`devices is responsible for first establishing the multiplexer control channel. This
`involves the following steps:
`
`- Establish an LZCAP channel to the peer RFCOMM entity. using LZCAP ser-
`vice primitives. see Lifiitlifki-1 “Service i=3nmitives" on page 295.
`
`Start the RFCOMM multiplexer by sending SABM command on DLCI 0, and
`await UA response from peer entity. (Further optional negotiation steps are
`possible.)
`
`After these steps, DLCs for user data traffic can be established.
`
`5.2.2 Close-down procedure
`
`The device closing the last connection (DLC) on a particular session is respon-
`sible for closing the multiplexer by closing the corresponding LZCAP channel.
`
`Closing the multiplexer by first sending a DISC command frame on DLCI 0 is
`optional, but it is mandatory to respond correctly to a DISC (with UA response).
`
`5.2.3 Link loss handling
`
`if an LZCAP link loss notification is received. the local RFCOMM entity is
`responsible for sending a connection loss notification to the port emulation!
`proxy entity for each active DLC. Then all resources associated with the
`RFCOMM session should be freed.
`
`The appropriate action to take in the port emulationiproxy entity depends on
`the AP! on top. For example, for an emulated serial port {vCOMM), it would be
`suitable to drop CD, DSR and GT3 signals (assuming device is a DTE).
`
`1. This implies that, when responding to an L2CAP connection indication. the RFCOMM entity
`should save and associate the new RFCOMM session with the remote EiD_ADDR. This is.
`at least. necessary if subsequent establishment ofa DLC in the opposite direction is possi-
`bie (which may depend on device capabilities).
`
`TS t‘J?.‘itJ Adaptations for RFCOMM
`
`29 November 1999
`
`AFFLT0293627
`
`Samsung Ex. 1316 p. 399
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`RFCOMM with TS 07.10
`
`5.3 SYSTEM PARAMETERS
`
`page 400 of 1032
`
`Bluetuoth.
`
`Tebie 5.1 contains all the applicable system parameters for the RFCOMM
`implementation of the TS 07.10 multiplexer.
`
`svstemrarameier @
`Maximum Frame Size (N1)
`Default: 12? (negotiable range 23 — 32767)
`
`Acknowledgement Timer (T1)
`
`60 seconds
`
`Response Timerfor Multiplexer
`Control Channel (T2)
`
`50 seconds
`
`Table 5.1: System parameter vaiues
`
`Note: The timer T1 is the timeout for frames sent with the PIF-bit set to one
`
`(this applies only to SABM and DISC frames in RFCOMM). T2 is the timeout
`for commands sent in UIH frames on DLCI 0.
`
`Since RFCOMM relies on lower layers to provide reliable transmission, the
`default action performed on timeouts is to close down the multiplexer session.
`The only exception to this is when trying to set up a new DLC on an existing
`session; i.e. waiting for the UA response for a SABM command. In this case,
`the initiating side may defer the timeout by an unspecified amount of time if it
`has knowledge that the delay is due to user interaction (e.g. authentication pro-
`cedure in progress). Wheniif the connection attempt is eventually considered to
`have timed out, the initiating side must send a DISC command frame on the
`same DLCI as the original SABM command frame. in order to notify the other
`party that the connection attempt is aborted. (After that the initiating side will,
`as usual, expect a UA response for the DISC command.)
`
`5.4 DLCI ALLOCATION WITH RFCOMM SERVER CHANNELS
`
`To account for the fact that both client and server applications may reside on
`both sides of an RFCOMM session. with clients on either side making connec-
`tions independent of each other, the DLCI value space is divided between the
`two communicating devices using the concept of RFCOMM server channels
`and a direction bit.
`
`The RFCOMM server channel number is a subset of the bits in the DLCI part of
`the address field in the TS 0?'.10 frame.
`
`@333
`
`BT
`
`able 5.2: The format