The Host Controller Interface (HCI)
`
`145
`
`Table 7 .9
`The event HCI POU.
`
`• size
`
`Field
`fl Cl Eve1it Header
`-
`-
`1 byte
`Eve·nt_ Code
`
`l byte
`Payload_Length
`H CI_Event_Payload
`Payload
`Payload
`_Lengtli bytes
`
`comments
`
`identifies the event
`• 'OxFE' is reserved for Bluetooth logo specific events
`• 'OxFF' is reserved for vendor -specific events used
`durin g module manufacturing, such as module testing
`and debugging oper ations
`length of the payload of the event HCI _PDU in bytes
`
`the payload of an event HCI _PDU is structured as a
`sequence of variable -size fields for the various parameters
`related to this event
`
`A host uses the command HCI_PDUs for things like:
`• setting operational parameters of the module , such as providing
`a link key for authentication ;
`• configuring the modul e's operational status and related parame-
`ters, for instanc e causing it to activate and set the related param-
`eters for a low power mode;
`• reading and writing register entries, like the number of broad -
`cast packet repetitions, NBc, and so o.n.
`Depending upon the command , module registers will be read or set,
`the link manager will execute an LMP n·ansaction, the link controller will
`change state and execute, say, a page, and so on. The host controller noti-
`-
`fies the host of the outcome of the command with an event H CI PD U
`either soon after the command is sent from the host or at a later time
`when appropriate-for
`example, following the termination of an LMP
`transaction. The reason that host controller H CI PD U transmissions to
`-
`the host are called events and not responses is that the host controlle1·
`may initiate its own request (for instance, requesting a missing link key
`from the host) or send a transmission to the host without ll?-e host's prior
`action (perhaps notifying it of a connection request coming from a remote
`device). Actually, some of the command HCI_PDUs sent from the host
`are simply responses to event H CI_PD Us that originated from the host
`
`IPR2020-00202
`Apple Inc. EX1057 Page 167
`
`

`

`146
`
`Chapter 7
`
`THE UPPER PROTOCOLS OF THE TRANSPORT GROUP
`
`controller. For example, tl1e HCI_Accept_ Conriection_Req11est command is
`
`sent by the l1ost to the host cont:i·oJJe1· instructing the latter to accept an
`in.coming connection request fi:om a remote device. Before the host trans-
`mits the HC!_Accept_ Conrzection_Request co.mmand , the host controller
`notifies
`the host of
`the
`incoming
`connection
`request with a
`Connection_Request event.
`Table 7.10 shows the st1ucture of a data HCI PD U.
`Table 7 .10
`The data HCI_PDU.
`
`field
`HCJ Data Header
`-
`-
`Connection_Handle
`
`• size
`
`12 bits
`
`•
`
`Flags
`
`4 bits
`
`Payload_Lengt,h
`2 bytes
`HCI_Data_Payload
`Payload
`Payload
`_Length
`bytes
`
`comments
`
`identifies the baseban d link O\rer \vhich these data are
`transmitted or received ;
`connection handle s in the range 'OxFOO' to 'OxFFF' are
`reserved .for future use
`AGL transmiss1:ons. compo sed of t\-vo subfields:
`• Packet_Boundary_Flag.
`identifies the beginning or
`continuation of an upper-la yer (L2CAP) PDU
`• Broadcast_Flag. identifies the "spread factor" for the
`ACL transmission: point -to-point , broad cast to active
`s]aves, or broadcast to al] slaves including any parked
`ones
`SCO transmissions. reserved field
`length of the payload of the data H CI_PD U in bytes
`
`data to be carried over the ACL or SCO baseba .nd link
`identified by the contents of the Connection_Handle field
`
`is
`Transmission of data HCI_PDUs across the physical interface
`regulated by the buffer sizes available on the receiving side of the PDU.
`Both the host and the host controller inquire about the buffer size avail-
`able for receiving data HCI_PDUs on the opposite side of the interface
`and adjust their transmissions accordingly. This implies that a large
`L2CAP _PDU may need to be fragmented within the HCI layer prior to
`
`IPR2020-00202
`Apple Inc. EX1057 Page 168
`
`

`

`The Host Controller Interface (HCI)
`
`14 7
`
`sendin g it to the host controller. On the receiving side, the HCI layer
`could reconstruct L2CAP _PDU s based on the packet boundary flag
`info1-mation within
`the received data H CI_PD Us. Transmission of
`H CI_PD Us across the physical interface is in first-in--first-out order
`without preem ption. Commands are proc essed by the host controller in
`their order of arrival, but they may complete out of order since each
`might take a different amount of time to execute. Similarly, events are
`processed by the host in order of arrival , but their processing may ter-
`min ate out of order.
`Note that none of the fields in any of the HCI_PDUs identifies the
`H CI_PD U class: command , event or data. Identification of the
`I-I CI_PD U class is left to the H CI transport protocol that actually car-
`1ies the PD Us between the host and the host controller. Strictly speak-
`ing, this is a violation of protocol layering. However , it allows the HCI
`to take advantage of the capabili ties of the underlying transport proto -
`col, which may provid e its own n1eans for distinguishing
`the three
`HCI _PD U classes with minimal overhead. Purists may wish to consider
`that the HCI layer in the host and its complementary part in the host
`controller consist of a transport -independent sublayer, and a transport
`dependent conv ergence sublayer (which executes the HCI transport
`proto col) that adapt s the HCI_PDUs to the particular transport method
`used to carry them across the physical interface .
`The HCI PDUs
`-
`Th ere are man y command HCI_PDUs organized into several groups
`identified by
`the OG F subfield
`in the header of the command
`HCI_PDU. For many of these command HCI_PDUs there exists a cor-
`responding event HCI_PDU
`that carries the outcome and return
`parameters related to the command. For several commands,
`informa-
`tion related . to their status and execution results is carried by two special
`even ts: Command_Status_Event and Command_ Complete_Event. The
`former typically is sent immediately after a command is received by the
`host controller to indicate the status of the command, such as command
`pending execution, command not understood, and so on. This provides
`a sort of acknowledgement of the command along with an indication of
`its processing status. The latter is used to indicate the completion of exe-
`cution of a command and to return related parameters,
`including
`whether or not the requested command was executed successfully.
`Observe that multiple events might be generated in response to a single
`command.
`
`•
`
`IPR2020-00202
`Apple Inc. EX1057 Page 169
`
`

`

`148
`
`Chapter 7
`
`THE UPPER PROTOCOLS OF THE TRANSPORT GROUP
`
`There are command HCI _PDU s related to link controller action s,
`policy-setting commands , the host controller
`itself, and many other s.
`Command and event HCI _PDU s number ove1· 100; son1e of these are
`highlighted
`in the following sections . The se selected HCI _PD Us are
`illustrative of the type of infor1nation and the le,,el of detail that is com-
`municated between the host and the host contr oller. For· the full set of
`H CI_PD Us, refer to the specification.
`Link Control HCI PDUs
`The commands
`in this group are identified via the OG F subfield with
`
`the value 'bOOOOOl '. This group contains command s that allo1vv inquirie s
`to be sent to cliscover other devices in the vicinity. The1·e are command s
`to create and terminat e ACL and SCO connection s and to accept or
`reject incoming connection requests. Th ere are command s for initiatin g
`authentication and encryption proc edur es as wel] as for transporting
`authentication keys and PINs from the host to the link cont1·01Ier. There
`are information commands
`in this gToup to request the user-friendl y
`name of the remote device , the link manag er options that it supports
`and the clock offset registered in the remote device.
`Following are some examples of HCI _PDU s in this group. The
`HC!_lnquiry command PDU instructs the module to ent er the inquiry
`mode, using a given inquiry access code , for a specified amount of time
`or until a specified number of responses is collected. Thi s command
`is
`summarized in Table 7.11.
`Table 7 .11
`The HCl_lnquiry command HCI_PDU.
`
`Commarul_Name
`OCF
`Parameters
`
`'bOOOOOOOOO I'
`
`
`LAP
`
`Inquiry_Length
`
`Num_Responses
`
`HCI_lnquiry
`
`3
`bytes
`1 byte
`
`I byte
`
`lower address part used for
`generating the inquiry access code
`indicates the maximum duration for
`trus inquiry: 1.28 sec - 61.44 sec
`indicates the maximum number of
`responses to be collected
`
`IPR2020-00202
`Apple Inc. EX1057 Page 170
`
`

`

`The Host Controller Interface (HCI)
`
`149
`
`Th e inquiry mode originated by this command terminates either
`when Jnqztiry_Length time has elapsed or when the number of respond-
`ing device s 1·eacl1es Num_Responses, whichever occurs first.
`Tl1e l1ost controller· returns inforn1ation collected from inquiries to
`the ho st with the lnquiry_Result_Evenf:> summarized in Table 7.12; the
`parameters of the event are derived from the FHS BB_PDUs (detailed
`in tl1e previou s chapter ) that are received from the devices responding
`to the inquirie s. A brief description of the parameters below is given in
`Table 7.13, which presents the command
`that uses these parameters.
`Table 7 .12
`The /nquiry_Result_Event event HCI_PDU; the index i identifies each of the
`Num_Responses responding devices.
`
`Event Na1ne
`-
`Event Code
`-
`Parameters
`
`lnqui1y_Result_Event
`'Ox02'
`1 byte
`Num_Responses
`6*Num_Responses bytes
`BD_ADDR[i]
`1 *Num_Responses byte(s)
`Page_Scan_Repetition_Mode[ i]
`1 *Num_Responses byte(s)
`
`Page_Scan Period_Mode[ i]
`1 *Num_Responses byte(s)
`Page_Scan_Mode[ z]
`3*Num_Responses bytes
`Class_ of-Device[ i]
`2*Num_Responses bytes
`Clock_ Offset[ i]
`d PD U · structs the module
`The HCI Create Connection comman
`·
`in
`.
`et of
`·fi d d
`. e using a given s
`-
`-
`evic '
`.
`ess i·equires
`to create a connection with a spec1 e
`BB_PDU types for the ACL link. Since the con~ectioh~ proc mand also
`,,
`'' deV1ce t is com
`that the ''local '' device page the
`remote
`.
`The paQi.ng
`'
`.
`h
`aoing process.
`b
`provides
`information used to accelerate
`t e P b- 1 1 d vice via an ear-
`t of a oca
`.
`.
`. bl
`th h
`e
`7.12. The
`1nformat1on becomes ava1la e to
`e os
`.
`Table
`shown ·zerin Table 7.13.
`lier
`Jnquiry_Result_Event PDU:
`H Cl Create Connection command 1s sum mart
`-
`-
`
`ak l·berty in the nan1ing
`· ,ve t e 1
`1·"
`. . R
`t Once again
`8. This event is actua lly called "l11qu1ry esu t even ·
`convenlion for consistency purposes ,vith other polJs.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 171
`
`

`

`150
`
`Chapter 7 i THE UPPER PROTOCOLS OF THE TRANSPORT GROUP
`
`Table 7 .13
`The HCI_Create_Connection command HCI POU.
`
`...
`
`l •
`
`-
`Command Name
`OCF
`Parameters
`
`HCJ Create Connection
`-
`-
`'bOOOOOOO 101'
`BD ADDR
`-
`
`6 bytes
`
`Packet_Type
`
`2 bytes
`
`Page_Scan_
`Repetition_Mode
`
`1 byte
`
`-
`
`Page_Scan_Mode
`
`1 byte
`
`Clock_ Offset
`
`2 bytes
`
`Allow Role Switch
`-
`-
`
`1 byte
`
`identifies tl1e remot e devi ce \.vith
`\vhich lo establish a connection
`indicates\ hich BB_PDU types can
`be used by the link manager for the
`ACL li11k
`indicates the page scan repetition
`mode, that is, ho\v frequently the
`remote device enters the page scan
`mode, last reported by the remote
`device
`indicates the page scan mode
`supported by the device
`indicates the difference betwee n the
`slave and master clocks, as
`calculated in the last
`communicat ion betwee n them
`indicates wheth er this ( the paging )
`device will be the master or will
`allow the paged device to becom e
`the master if reque sted 1
`
`I
`I
`I
`I
`I
`I
`I
`I
`
`J.
`
`A1/aster-slave role switching is described in tbe previor,s cl~a/Jler.
`Upon successful creation of the connection, a Connection_ Com-
`plete_Event is sent to the hosts on both sides of the connection. The
`events contain the Connection_Handles for identifying the connection.
`The connection handles are assigned by each host controller indepen -
`dently and their scope is limited to the local device only.
`Link Policy HCI_PDUs
`The commands in this group are identified via the OG F subfield with
`the value 'bOOOOlO'. This group contains commands that allow a device
`to set a power-management policy through the hold, sniff, and park
`
`IPR2020-00202
`Apple Inc. EX1057 Page 172
`
`

`

`The Host Controller Interface (HCI)
`
`151
`
`baseband mode s and to define the parameters for those modes. Also,
`ther·e are con1mands that pass QoS parameters from the L2CAP layer
`to the link n1anager, learn about the role (master or slave) that the
`device9 plays for a particular connection and request a role switch if
`needed.
`Table 7.14 summari zes the HCI _PDU command that requests the
`ho st contr·oller to instruct the link manager and the baseband to enter
`hold mode with the parameters provided. Similar commands exist for
`sniff and park modes.
`Table 7 .14
`The HCI_Hold_Mode command POU.
`
`Comrriand_Name
`OCF
`Parameters
`
`]{Cl Hold Mode
`-
`-
`
`'bOOOOOOOOO l'
`Conn.ection Handle
`-
`
`Hold Mode Max Interval
`-
`-
`-
`
`2 bytes
`
`•
`2 bytes
`
`Hold Mode Min Interval
`-
`-
`-
`
`2 bytes
`
`identifies the connection
`(actually the ACL link) to be
`placed in hold mode;
`only the 12 LSBs are used
`indicates the maximum
`negotiable hold interval
`(0.625 msec - 40.9 sec)
`indicates the minimum
`negotiable hold interval
`(0.625 msec - 40.9 sec)
`
`The host controller notifies the host when hold mode is entered or
`is terminated using the Mode_Change_Event.
`Host Controller and Baseband HCI PDUs
`-
`The commands in this group are identified via the OGF subfield with
`the value 'bOOOO 11 '. This group contains commands that allow the host
`to access and configure various hardware registers that maintain opera-
`tional parameters. Among the operations that can be perfo1·med are
`deter1nining the types of events that the host controller can generate;
`reading, writing, and deleting stored keys; reading and wiiting the user-
`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
`reqt1est this inforn1ation from the host controller.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 173
`
`

`

`1 52
`
`Chapter 7
`
`THE UPPER PROTOCOLS OF THE TRANSPORT GROUP
`
`friendly device name; activating and deactivating inqui ry a11d/ or page
`scans; reading and writing the authentication and/ or encryp tion activity
`flag for a link; reading and writing the inquir y access codes used to listen
`during inquiry scans; forcing the flushing of ACL packets for a connec-
`tion handle; reading and writing the audio codec para 111eters and so on.
`the HCI PDU co111mand that sets the
`Table 7.15 summarizes
`-
`inquiry scan parameters ; a similar comm and exists for page scans as
`well. Inquiry scans occur only when the host has already sent an
`HCI_ Write_Scan_Enable command PD U to enable inqui ry scans.
`Table 7 .15
`
`The HCI_ Write_Page_Scan_Activity command POU.
`Command_Name HG!_ Write_lnquiry_Scan_Activity
`OCF
`'bOOOOO 11100'
`Parameters
`lnquiry_Scan_lnterval
`
`2 bytes
`
`r· ....
`
`I.. ' ' .
`.. y .
`
`--
`
`I
`
`lnquiry_Scan_ Window
`
`2 bytes
`
`determine s the interval bet\vee n
`successive starts of inqui ry scans
`11.25 msec - 2.56 sec (typical ly,
`1.28 sec)
`de ten11ines the dur atjon of a
`single continuou s scan operation
`11.25 msec - 2.56 sec (typical ly,
`11.25 msec)
`When the host controller finishes updating the related register s it
`returns a Command_ Complete_Event to the host.
`Inf0r1national Pa.rameters HCI PDUs
`The commands
`in this group are identified via the OG F subfield with
`the value 'bOOOIOO'. This group includes commands that request static
`info11nation about the hardware and firmware that is electronically
`''engraved'' on the device at manufacture time. There is a command
`to
`request the version of the various protocols (LMP, HCI, and so on) that
`the module supports; a command to request a list of features supported
`by the link manager; a command to request the country of operation of
`the module; a command to request the BD_ADDR of the module; JO and
`to request the host controller buffer information for ACL
`a command
`
`JO. Recall that the BD_ADDR is hardwired and cannot be modjfied.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 174
`
`

`

`Summary
`
`153
`
`and SCO packets, used to execute effective flow control at the host. The
`1·equested information is returned in a Command_ Complete_Event.
`Status Pa.ra.1neters HCI PDUs
`-
`Th e commands in this group are identified via the OGF subfield with
`tl1e value 'b000I01 '. This group include s commands that request infor-
`mation that is dynamically upd ated, like the value of the contact
`coun te1· t11at measure s the number of successive instants during which
`the remote device does not respond to local transmissions, causing the
`local link manag·er to flush any PDU s waiting to be transmitted. There
`is also a command HCI _PDU to retrieve information relat ed to the
`qua lity of the link and the RSSI (received signal strength indicator )
`value. Th e requested
`information
`is retut"Ded in a Command_ Com-
`plete_Event.
`Testing HCI _PDUs
`The com mands in this gToup are identified via the OGF subfield with
`the value 'bOOOl 10'. These commands, which all result in Command_
`Complete_Event events , are used for testing the Bluetooth module and
`are not discussed further here.
`
`•
`
`•
`
`Summary
`
`In this chapter we have highlighted the upper two Bluetooth transport
`protocols: L2CAP and HCI. The latter is a transport protocol internal to
`a device, rather than an over-the-air protocol as are L2CAP and the
`other proto cols discussed in Part 2 of the book. The primary purposes of
`these proto cols are both to hide, in the case of L2CAP, and to expose, in
`the case of H CI, the internal operation of the lower transport protocols.
`L2CAP is used to multiplex and transport higher protocol layers while
`shielding them from the peculiarities of the lower transport protocols,
`like the baseband. The H CI provides a standardized interface to the ser-
`vices and capabilities provided by the lower tr·ansport protocols.
`In this and the previous chapters we have presented the protocols
`that the SIG has developed
`for transporting data across Bluetooth
`devices. These protocols have been developed entirely by the SIG spe-
`cifically for Bluetooth wireless communication. They reflect the SIG,s
`objectives to develop simple, cost-effective communication systems that
`can operate at low power in noise-susceptible places. In the next chap-
`ter we introduce the middleware protocols that are used to take advan-
`
`IPR2020-00202
`Apple Inc. EX1057 Page 175
`
`

`

`154
`
`Chapter 7 , THE UPPER PROTOCOLS OF THE TRANSPORT GROUP
`
`tage of the data -transp ort services of the t1~ansport pr otoco ls to enable a
`plethora of application s, includin g legacy applications,
`to ope rate
`smoothly over Bluetooth links.
`
`I
`I
`I
`I I
`
`IPR2020-00202
`Apple Inc. EX1057 Page 176
`
`

`

`The RFC
`SDP
`
`an~
`eware
`I 1, I
`Protoco
`
`s
`
`W e now move from the transport protocol layers to a detailed discus-
`sion of
`the middleware protocols.
`In
`this chapter we discuss
`RFCOMM,
`the Bluetooth serial port emulation protocol, and the Blue-
`tooth Service Discovery Protocol, or SDP. Version 1.0 of the core speci-
`fication (volume 1) devotes nearly 90 pages to these two protocols. As
`with the other detailed discussions of portions of the specification, this
`chapter attempts to reveal the motivation and thought process behind
`the development of these p1·otocols. While the important elements of
`RFCOMM and SDP are examined here, this material focuses on the
`design basis for the protocols and thus is not a substitute for the specifi-
`cation itself.
`Both RFCOMM and SDP 1·eside directly above the L2CAP layer
`(discussed in the previous chapter) and use L2CAP connections
`to
`accomplish their respective functions. Both of these protocols provide a
`protocol data unit (PD U) structure for use by higher layers ( either appli-
`cations or other middleware protocols) in the stack. PDUs allow the
`higher layers of the stack to work with logical data elements at a higher
`level of abstraction than that of the packet for 1nat used by the transport
`protocols. Both RFCOMM and SDP are protocols developed specifi-
`cally for use with Bluetooth wireless communications,
`although
`RFCOMM borrows heavily from an existing standard. Figu.re 8.1 illus-
`trates the position of RFCO MM and SD P in the protocol stack. As
`shown in the figure, RFCOMM
`is used by higher layer middleware
`protocols and by applications for networking, IrDA interoperability and
`telephony. These same applications may communicate directly with
`
`155
`
`IPR2020-00202
`Apple Inc. EX1057 Page 177
`
`

`

`156
`
`Chapter 8
`
`THE RFCOMM AND SDP M IDDLEWARE PROTOCOLS
`
`RFCOMM as well as with thei1· assoc iated middl eware p1-otoco ls that in
`,,vith RFCOMM . Since service discovery
`is funda-
`tum communicate
`mental
`to all Bluetooth p1·ofiles, mo st app lication s will also communi -
`cate with the SD P layer.
`
`,
`other
`applications r
`
`I
`
`networking
`applications
`
`I rDA
`telephony
`applications
`applications
`r········t············
`r············
`I rDA
`telephony
`net\vorki ng
`inter-
`control
`middlevvare
`operabi I ity
`m i d d I e v, a re
`protocols
`middleware
`protocols
`protocols
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`•
`
`'
`.
`"
`Figure 8.1
`RFCOMM and SDP in the Bluetooth protocol stack.
`
`L2CAP
`
`The RFCOMM Protocol
`and telecommunications
`in computing
`Serial interfaces are ubiquitous
`devices, particularly
`those devices with a high affinity for Bluetooth
`communications. Notebook computers have serial po .rts, personal digi -
`tal assistants
`typically have serial ports ( often used to synchronize
`the
`PDA with some other device), many mobile
`telephones
`have
`serial
`ports (often used for a wired headset), many digital cameras use serial
`ports to transfer
`image data to another device, printers and other com -
`puter peripherals
`often use serial ports for communication,
`and so on.
`Moreover,
`infrared
`communication, which as previously
`established
`traits in common with Bluetooth wireless comm uni cation,
`has some
`normally uses a serial port to communicate with the IR transceiver. 1
`Because Bluetooth
`technology
`aims
`to replace
`cables,
`it seems
`clear that there is a large opportunity
`to replace serial cables. To do this
`effectively,
`the stack needs to support serial communication
`in the same
`
`IPR2020-00202
`Apple Inc. EX1057 Page 178
`
`

`

`The RFCOMM Protocol
`
`15 7
`
`mann e1· as is done with cables, so that application s are presented with a
`famili ar serial interface. This permits the cornucopia of legacy applica -
`tions that are unawa1·e of the Bluetooth
`technology
`to operate seam-
`lessly over Bluetoot h
`links. Furthermore,
`application
`software
`developer·s skilled in developing se1ial communi cation applications
`may still continue
`to do so, assured that their applications will operate
`over Bluetooth
`link s. But the transport-layer protocols are not modeled
`after a seria l port. L2CAP support s packet data structure s, and while the
`air·-inter face ma y transmit bit patte1ns in a serial fashion, this is not the
`sam e as tl1e commo n RS-232 types of serial interfaces used today with
`seria l cables.
`Thu s the SIG has chosen to define a laye1· in the protocol stack
`that look s very much
`like a typical serial interf ace : the RFCO MM
`layer·. In the world of per sona l computers, serial interfaces are often
`called COM ports. The name RFCOMM
`connotes a wireless
`(RF)
`instance of a virtua l COM port. RFCO MM primarily
`is intended
`to
`enab le cab le-replacement scenarios for existing application s.
`RFCOMM Protocol Development
`in the
`is rooted
`layer
`Th e motivation
`for the RFCOMM
`protocol
`requirement
`to support legacy applications with initial Bluetooth imple -
`ment atio ns. The need for· this serial communication
`function in the soft-
`ware stack was identified quite early in the SIG's fo1·1nation. Just one
`month after the SIG was publi cly announced, discussions ensued on
`developing the specificati on for the RFCO MM laye1·. At that time, the
`ETSI TS 07.10 standard [ETSI 99] had already been identified as a can-
`did ate for a basis upon which to build Bluetooth serial communications.
`Requir ements for Bluetoot h serial communications
`include:
`Multiplexed
`serial co1n1nunications:
`There may be many
`simultan eous clients of the serial interface
`in the stack, including
`IrOBEX , telephony control and networking clients. Thus the serial
`port needs to be shareable
`through multiplexed connections
`(which
`1. 1n the PC domain , infrared commun ications are frequently tied to a COM port resource . In
`commonly used PC operati ng environments , these CO M ports classically have been difficult to
`configure, especial ly for infrared communica tions. Tl1is drawback has led to a situation ,vhere,
`,vhile many infrared ports are deployed in produ cts, only a fraction of these ports are actually
`used, since n1any users lack the expe rtise or motivation to perform the necessar) ' configuration
`process. The rise of infrared ports on PDAs and mobil e phone s, ,vhere the configuration pro -
`cess is much easier, seems to lead to a higher usage rate of infrar ed in peer-to-peer communica -
`tions.
`
`••
`
`•
`•
`
`•
`• ,
`
`IPR2020-00202
`Apple Inc. EX1057 Page 179
`
`

`

`I
`
`158
`
`Chapter 8 , THE RFCOMM AND SDP MIDDLE\'t./ARE PROTOCOLS
`
`in the
`in tum might be supported by the proto col mt1ltiplexing
`L2CAP layer, over which distinct RFCOMM
`entities in different
`de,rices communicate ).
`RS-232 signal compatibility: RS-232 is a widely t1sed serial inter -
`face for the cables with which Bluetooth wireles s con1munication
`needs to be compatible. Many application s are ·fan1ilia1~ ,vitl1 RS-232
`interfaces, including the various control signals associated \Vith RS-
`232; these include common signals such as Requ est to Send / Clear to
`Send (RTS/ CTS), Data Terminal Ready / Data Set Ready (DTR/
`DSR ), the RS-232 break frame and others . Emulating
`these sig11als
`allo,.vs RFCOMM
`to present to its clients the appeara nce of a serial
`port that is virtually the same as that used \vith a ser·ial cable .
`Remote status and configuration:
`In a peer -to-pee r environ -
`ment, the two parties communicating over the seria l link often need
`to determine
`the status and configuration of the remot e serial inter -
`face so that the local serial interface can be configured in a compati-
`ble manner. The service discovery protocol , discussed in f ollo,.ving
`sections, can be used to obtain basic information needed to estab lish
`a serial communications
`channel; following connection
`estab lish-
`ment the two ends of the serial interface need to be able to negotiate
`compatible serial communication settings for the connect ion.
`Internal and exter11al serial port: To support the vario us uses
`in Bluetooth applications, RFCO MM
`of serial communications
`needs to support both an internal emulated serial port, in which the
`serial port parameters are used only locally ( the parameter s do not
`apply across the air-interface ) as well as an external serial port, where
`the serial port parameters and status are transmitt ed across the RF
`link along with the data and may be used by the receiving serial port.
`These requirements are not unique to Bluetooth environments,
`and the SIG realized that the aforementioned ETSI TS 07.10 standard
`so
`was a good match for the needs of Bluetooth serial communications,
`the SIG adopted much of that standard. However, TS 07.10 is not a per -
`fect match for use in the Bluetooth protocol stack, so the SIG added
`some of its own modifications
`to adapt the ETSI standard for use in
`Bluetooth wireless communications. Among
`these additions
`and
`changes are:
`Data. fra1ne adaptations: Since Bluetooth communication has an
`underlying packet structure by virtue of the use of L2CAP, some of
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`IPR2020-00202
`Apple Inc. EX1057 Page 180
`
`

`

`The RFCOMM Protocol
`
`159
`
`the data f1·ame conte11ts specified by TS 07.10 are unnecessary for
`RFCO M~. For example,
`the frame delimiter flags specified in TS
`07.10 are discar ded for the RFCOMM
`specification.
`Connection
`establishment and terniination: Again, because
`Bluetoot h com ·munication has its own connection management in
`tl1e transport protocol
`laye1·s that RFCOMM uses, the connection
`manage 111ent functions of TS 07.10 are superfluous for RFCOMM.
`The spec ificatio n detail s how RFCO MM links are managed.
`Multiplexing: RFCOMM uses a subset of the multiplex channels
`specified for TS 07.10 and specifies the way in which some TS 07.10
`multiplexing control commands are used in RFCOMM.
`Applicability: The RFCOMM
`specification mandates support of
`in the TS 07.10 standard. These
`severa l features wl1ich are optional
`features de al with exchanging
`infor111ation about the configuration
`and statu s of the seria l connection and include negotiating the serial
`port and individual channel settings and retrieving the serial port sta-
`tus. In Bluetooth environments
`these functions are quite useful and in
`fact can be considered necessary for effective use of the air-interface;
`thu s the y are specified as mandatory
`to support in RFCOMM.
`Flow control: Typical serial ports pace the data transfer using
`XON/XOFF
`pacing or DTR signal pacing. For RFCOMM,
`the
`specification describes flow control mechanisms specific to the Blu~-
`tooth protocol stack, including flow control that applies to all multi-
`plexed RFCOMM
`channels as well as per-channel pacing.
`The remaining RFCOMM
`sections in this chapt~r revi~w. key
`points of the RFCOMM specification, in many cases highlighting the
`significance of the design choices fo1· this p1·otoc0I layer.
`The RFCOMM Protocol Examined
`R.FCOMM in the specification
`2
`The relatively
`few pages dev~ted
`to
`k RFCOMM is the
`in the version 1.0 protocol stacal. b
`belie its importance
`din some
`basis for most of the version 1.0 profiles and ~ight
`bsol e upseort for leg-
`.
`.
`se is to ena e sup
`future profiles, although its primary purpo
`.
`3 The main rea-
`1 cernent scenanos.
`.
`.
`.
`I
`bl
`l.
`acy app 1cations 1n srmp e ca e-rep a
`dozens of pages of
`.
`does not reqUire many
`son
`that RFCOMM
`ti·on a good ca11didate for
`.6
`. n of the spec1 ca
`k
`2. Only about 25 pages, making the RFCOMM porbo
`d
`t ding this ke)' layer of the stac ·.
`d . fttlly \ln ers an
`.
`,
`h
`.
`beginning-to-end reading ,or t .ose 1ntereste 1n
`
`IPR2020-00202
`Apple Inc. EX1057 Page 181
`
`

`

`• ' ' '
`
`160
`
`Chapter 8 D THE RF(OMM
`
`AND SOP M IDDLEWARE PROTOCOLS
`
`is the SIG's decision to adopt much of the ETSI TS 07.10
`explanation
`protocol (whicl1 itself is over 50 pages of specification ). By specifying TS
`07.10 as the basis for RFCOMM , the SIG has adopted a mature stan-
`dard protocol and the specification needs to describ e only the adapta -
`tion of
`this standard
`for Bluetooth
`envi1·onn1ents. Mu ch of the
`RFCOMM
`chapter of the specification focuses 011 desc1ibing which
`parts of TS 07.10 are relevant for RFCOMM , hovv those features are
`used and the modifications necessary to map TS 07.10 into the Blue-
`tooth protocol stack.
`RFCO MM uses a.n L2CAP connectio11 to instanti ate a logical
`serial link beh,veen two devices. In pa1·ticula1·, an L2CAP connection-
`enti -
`that connects the tv\ro RFCOMM
`oriented channel is established
`ties in the h-vo devices. Only a single RFCOMM
`connec tion is per111it-
`ted between h-vo devices at a given time , but that connection may be
`multiplexed so that there can be multi.pie logical se1ial links between
`the devices. 4 The first RFCOMM
`client establishe s the RFCOMM
`connection over L2CAP; additional users of the existing· connection can
`use the multiplexing capabilities of RFCOMM
`to establish new chan-
`nels over the existing link; and the last user to drop the final RFCOMM
`serial link should te1·rninate the RFCOMM connection
`(and hence the
`underlying L2CAP connection ). Each multiplexed
`link is identified by a
`number called a Data Link Connection Identifier, or DLCI. Figure 8.2
`depicts multiplexed serial communications
`links using RFCO MM over
`L2CAP. In the illustration
`the various clients of RFCOMM
`each see
`their own emulated serial port, distinguished by a D LCI value ( depicted
`by the different line types in the figure). These separate channels are
`then multiplexed over the RFCO MM link,