BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 751 of 1013?
`
`Host Controiier interface Functional Specification
`
`uetouth.
`
`(with Status=Ox00) returned by the Host Controller after the Reject_
`Connection_Request command has been issued. The reason code issued in
`the Reason parameter of the Reject_Connection_Request command will also
`be sent over the air. so that it is returned in a Connection Complete event on
`the initiating side. Before this, the initiating side has issued a Create_
`Connection command or Add_SCO_Connection command, and has received a
`Command Status event (with Status=0x00).
`
`6.16 HOST TIMEOUT (ox1o)
`
`Note: this error code is used to indicate a reason for rejecting an incoming con-
`nection. It is therefore called reason code in the following description.
`
`Assume that a Connection Request event has been received by the Host and
`that the Host does not issue the Accept_Connection_Request or Reject_
`Connection_Request command before the connection accept timer expires
`(the connection accept timeout is set using Wrlte_Connection_Accept_
`'l”Imeout). in this case, the ‘Host Timeout‘ reason code will be sent by the Host
`Controller in the Status parameter of a Connection Complete event. The rea-
`son code will also be sent over the air. so that it is returned in a Connection
`
`Complete event on the initiating side. The initiating side has before this issued
`a Create_Connection or Add_SCO_Connection command and has received a
`Command Status event (with Status=0x00).
`
`6.17 UNSUPPORTED FEATURE on PARAMETER VALUE
`
`(M11)
`
`The ‘Unsupported Feature or Parameter Value‘ error code is returned by the
`Host Controller in the Status parameter in an event when the Host Controller
`has received a command where one or more parameters have values that are
`not supported by the hardware (the parameters are. however, within the
`allowed parameter range specified in this document). If the issued command is
`a command for which a Command Complete event should be returned, the
`event containing the error code is a Command Complete event. Othenivise, the
`event containing the error code is a Command Status event or the event
`associated with the issued command (following a Command Status event with
`Status=0xO0) depending on the implementation.
`
`6.18 INVALID HCI COMMAND PARAMETERS (0X12)
`
`The ‘Invalid HCI Command Parameters‘ error code is returned by the Host
`Controller in the Status parameter of an event when the total parameter length
`(or the value of one or more parameters in a received command) does not con-
`form to what is specified in this document.
`
`The error code can also be returned if a parameter value is currently not
`allowed although it is inside the allowed range for the parameter. One case is
`when a command requires a Connection Handle for an ACL connection but the
`
`List of Error Codes
`
`29 November 1999
`
`751
`
`AFFLT0293979
`
`Samsung Ex. 1419 p. 751
`
`

`
`BLUETOOTH SPECiF|CAT|ON Version 1.0 B
`
`page 752 of 3082
`
`Host Controiier interface Funciionai Specification
`
`Bluetuoth.
`
`Host has given a Connection Handle for an SCO connection as a parameter
`instead. Another case is when a link key. a PIN code or a reply to an incoming
`connection has been requested by the Host Controller by using an event but
`the Host replies using a response command with a BD_ADDR for which no
`request has been made.
`
`If the issued command is a command for which a Command Complete event
`should be returned, the event containing the error code is a Command Com-
`plete event. Otherwise, the event containing the error code is a Command Sta-
`tus event or the event associated with the issued command (foilowing a
`Command Status event with Status=0x00). depending on the implementation.
`
`6.19 OTHER END TERMINATED CONNECTION:
`
`(OX13-OX1 5)
`
`Note: these error codes are used to indicate a reason for disconnecting a con-
`nection. They are therefore called reason codes in the following description.
`
`When the Host issues the Disconnect command, one of these reason codes is
`
`used as value for the reason parameter. The ‘Connection Terminated By Local
`Host’ reason code will then be returned in the Reason parameter of the Discon-
`nection Complete event that will follow the Command Status event (with Sta-
`tus=0xD0) that is returned by the Host Controller after the Disconnect
`command has been issued. The reason code issued in the Reason parameter
`of the Disconnect command will also be sent over the air, so that it is returned
`
`in the Reason parameter of a Disconnection Complete event on the remote
`side.
`
`6.20 CONNECTION TERMINATED BY LOCAL HOST (0X16)
`
`See description in €3'.‘E‘3.*. This error code is called a reason code, since it is
`returned in the Reason parameter of a Disconnection Complete event.
`
`6.21 REPEATED ATTEMPTS (OX1?)
`
`The ‘Repeated Attempts’ error code is returned by the Host Controller in the
`Status parameter in a Connection Complete event or Authentication Complete
`event when a device does not allow authentication or pairing because too little
`time has elapsed since an unsuccessful authentication or pairing attempt. See
`manager iiirotoooi" on page 185 for a description of how repeated
`attempts work.
`
`6.22 PAIRING NOT ALLOWED (OX18)
`
`The ‘Pairing Not Allowed‘ error code is returned by the Host Controller in the
`Status parameter in a Connection Complete event or Authentication Complete
`event when a device for some reason does not allow pairing. An example may
`be a PSTN adapter that only allows pairing during a certain time window after a
`button has been pressed on the adapter.
`
`752
`
`29 November 1999
`
`List ofError Codes
`
`AFFLT0293980
`
`Samsung Ex. 1419 p. 752
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 753 of 10132
`
`Host Controller inteiface Functional Specification
`
`uetooth.
`
`6.23 UNSUPPORTED REMOTE FEATURE (0X1A)
`
`The ‘Unsupported Remote Feature‘ error code is returned by the Host Control-
`ler in the Status parameter of the event associated with the issued command
`when a remote device that has been specified in the command parameters
`does not support the feature associated with the issued command. The
`‘Unsupported Remote Feature‘ error code can also be used as a value for the
`Reason parameter in the Disconnect command (as a reason code). The error
`code will then be sent over the air so that it is returned in the Reason parame-
`ter of a Disconnection Complete event on the remote side. In the Disconnec»
`tion Complete event following a Command Status event (where Status=Ox00)
`on the local side on which the Disconnect command has been Issued, the Rea-
`son parameter will however contain the reason code ‘Connection Terminated
`By Local Host‘. (The ‘Unsupported Remote Feature‘ error code is called
`‘Unsupported LMP Feature’ in the LMP specification, see “i_'m:'=< i'v'i.-3l’i:':2i_'}8:’ Proto --
`col“ on page
`
`6.24 UNSPECIFIED ERROR (OX1 F)
`
`The ‘Unspecified error’ error code is used when no other error code specified
`in this document is appropriate to use.
`
`6.25 UNSUPPORTED LMP PARAMETER VALUE (OXZO)
`
`The ‘Unsupported LMP Parameter Value’ error code is returned by the Host
`Controller in the Status parameter of the event associated with the issued com-
`mand when a remote device that has been specified in the command parame-
`ters sent back an LMP message containing the LMP error code 0x20.
`‘Unsupported parameter values‘ (see "i.inl-t Manager Protocoi" on page 18%).
`
`6.26 ROLE CHANGE NOT ALLOWED (OXZ1)
`
`The ‘Role Change Not Allowed‘ error code is returned by the Host Controller in
`the Status parameter in a Connection Complete event or Role Change event
`when role change is not allowed. If the local Host issues the Switch_Role com-
`mand and the remote device rejects the role change, the error code will be
`returned in a Role Change event. If a connection fails because a device
`accepts an incoming ACL connection with a request for role change and the
`role change is rejected by the initiating device, the error code will be returned in
`a Connection Complete event on both sides.
`
`6.27 LMP RESPONSE TIMEOUT (OX22)
`
`The ‘LMP Response Timeout‘ error code is returned by the Host Controller in
`the Status parameter in a Command Complete event or an event associated
`with the issued command following a Command Status event with Sta-
`tus=0x0{). when the remote device does not respond to the LMP PDUs from
`
`List of Error Codes
`
`29 November 1999
`
`AFFLTD2939B1
`
`Samsung Ex. 1419 p. 753
`
`

`
`BLUETOOTH SF'EClF|C:°l.T|ON Version 1.0 B
`
`page 754 of 3082
`
`Host Controller interface Functional Specification
`
`Bluetunth.
`
`the local device as a result of the issued command within LMP response time-
`out. (See "t..§nt< Manager i7—‘roro.r:ol" on page E85)
`
`6.28 LMP ERROR TRANSACTION COLLISION (DX23)
`
`The ‘LMP Error Transaction Collision‘ error code is returned by the Host Con-
`troller in the Status parameter of the event associated with the issued com-
`mand when a remote device that has been specified in the command
`parameters sends back an LMP message containing the LMP error code 0x23,
`"LMP Error Transaction Collision" (see “Littler tvtanegsr P.rotoooi" on page 1235).
`
`6.29 LMP PDU NOT ALLOWED (OX24)
`
`The ‘LMP PDU Not Allowed’ error code is returned by the Host Controller in the
`Status parameter of the event associated with the issued command when a
`remote device that has been specified in the command parameters sends back
`an LMP message containing the LMP error code 0x24. "PDU Not Allowed"
`(see "Limit lVlaoage!' Protocol" on page ‘$85).
`
`29 November 1999
`
`List ofError Codes
`
`AFFLTD2939B2
`
`Samsung Ex. 1419 p. 754
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 755 of 1082
`
`Host Controiier interface Functional Specification
`
`uetooth.
`
`7 LIST OF ACRONYMS AND ABBREVIATIONS
`
`Acronym or
`abbreviation
`
`Complete name
`
`ACL
`
`Asynchronous Connection Less
`
`BD_ADDR
`
`Bluetooth Device Address
`
`DH
`
`DIAC
`DM
`
`Data High rate
`
`Dedicated Inquiry Access Code
`Data Medium rate
`
`Device Under Test
`
`Data Voice
`
`General Inquiry Access Code
`
`Host Controller Interface
`
`Logical Link Control and Adaptation Protocol
`
`Logical Channel
`
`Lower Address Part
`
`Link Controller
`
`Link Manager
`
`Link Manager Protocoi
`
`Opcode Command Field
`
`OpCode Group Field
`
`Radio Frequency
`
`Received Signal Strength indication
`
`Synchronous Connection Oriented
`
`To Be Defined
`
`User Asynchronous
`
`User lsochronous
`
`User Synchronous
`
`Universal Serial Bus
`
`Tabie 7.1: List of Acronyms and Abbreviations
`
`List of Acronyms and Abbreviations
`
`29 November ‘T999
`
`AFFLT02939B3
`
`Samsung Ex. 1419 p. 755
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 756 of ‘$082
`
`Host Controller Interface Functional Specification
`
`uetnnth.
`
`8 LIST OF FIGURES
`
`Figure1.1: Overview cf the Lower Safiware
`
`Figure ?.2: End to End Civewiew sf Lower Saftware Layers
`in "fiarisfer Data ...........
`....................................................... ..
`
`Figure 1.3: Biuetooth Hardware Architmture Qvawiew. .......................... ._
`
`Figure ’§_<§~:
`
`E3~£ue'Lr:aoth Biuck Diagram with USES .3-{CE
`
`Figazre “i
`
`:3: Biuetooih Bieck. Diagram wiiiw PC”.-Card HG
`
`Figure 63.3: HG! Command Packet¢
`
`Figu-re«$.2:
`
`HG! Event Packet
`
`Figure 4.3:
`
`HG! ACE. Data
`
`*'
`
`"
`
`"
`
`Figure :1.-5:: HG! ECO ‘flaw Woke:’
`Figure 4.5‘.
`£3031 L00§}!’J3<';§‘I
`
`Figure, 4.8:
`
`5"-{emote-: Lnopback
`
`Locai Loogsbacf-1
`Figure ȢE.?:
`Figure A38: Remote: Loopback
`
`.
`
`29 November 1999
`
`Lis1ofFiguras
`
`AFFLT02939B4
`
`Samsung Ex. 1419 p. 756
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 757 of 10132
`
`Host Coniroiier interface Functional Specification
`
`uetouth.
`
`9 LIST OF TABLES
`
`List of Saappcsrtacj
`List 91‘ Fnssibie Error (3-zzdes .......
`
`................
`
`................. .....'i’«’-H3
`
`List of Acrcmyms and Abbrseviaiioms ........
`
`...................... ..?'.‘"5
`
`List of Tables
`
`29 November 1999
`
`AFFLT02939B5
`
`Samsung Ex. 1419 p. 757
`
`

`
`BLUETOOTH SPECWICATION Version 1.0 B
`
`page 758 of 3082
`
`Host Controfler Inreyface Functions.‘ Specification
`
`uetuoth.
`
`29 November 1999
`
`List at‘ Tables
`
`AFFLTD2939B6
`
`Samsung Ex. 1419 p. 758
`
`

`
`addendum to the HCI document
`
`E
`This Z ocum 'nt describes the USB transport
`(betwe n a host and the host controller).
`HCI omma ds flow through this layer, but the
`lay
`does ot decode the commands.
`$
`.*§
`
`5
`
`'
`
`AFFLTD293987
`
`Samsung Ex. 1419 p. 759
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 780 of 1082
`
`HC! USE Transport Layer
`
`29 November 1999
`
`AFFLTD2939B8
`
`Samsung Ex. 1419 p. 760
`
`

`
`BLUETCJOTH SPECIFICATION Version 1.0 B
`
`page 761 uf1D82
`
`HC! USE Transport Layer
`
`CONTENTS
`
`BIuetouth_
`
`fivaavfiaw ....
`
`...........
`
`.................................................................... .352
`
`{.553 Endpoint Exgsectatiozms .......................................................... ..‘?E$«£
`
`Conimi EEn€.*:J:,2ir1‘£ Expsecgatéons.
`
`Biiik Enripaénts Expactaticms.......,...............................,............
`
`interrupt Endpoint
`
`fsochro_nc3=..=s Endpoints Exgzeotaiiorzs ..................................... ..'i"P'E.‘-
`
`ii
`
`2.’!
`2.2
`
`2.3
`
`2.4
`
`£2.53
`
`Céass
`
`fleviae Firmwarza Upgrade ........................................................... ....?'?‘2
`
`§..§mitations .............................................
`
`...................................... ..?’?‘3
`
`5.‘:
`
`5.3
`
`Power Specific
`
`Ofhear
`
`29 November 1999
`
`AFFLT0293989
`
`Samsung Ex. 1419 p. 761
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`HG! USE Transport Layer
`
`1 OVERVIEW
`
`page 782 of 1082
`
`Bluetuuth.
`
`This document discusses the requirements of the Universal Serial Bus (USB)
`interface for Bluetooth hardware. Readers should be familiar with USB. USB
`
`design issues. Advanced Configuration Power interface (ACPI). the overall
`Bluetooth architecture, and the basics of the radio interface.
`
`The reader should also be familiar with the Bluetooth Host Controller Interface-
`
`Referring to Figure 1.1 below, notice that this document discusses the imple-
`mentation details of the two-way arrow labelled ‘U88 Function‘.
`
`Dther Hofl Drivers
`
`Baseband Controller
`LMP Fimmafe
`
`RF-"BD (wllh Blualooth HCI Library]
`
`Elnieloofh HCI
`
`Bluetoolh HCI Finnware
`
`RFU SB {USE Mlnld fiver]
`
`" T USB'F'EinT:fi6n_T 'T .3,
`
`Biustooth USE Firmware
`
`Microsoft USE Stack
`
`USB Ht Controller
`
`Figure 1. 1: The Figure iiiustrates the reletionshtjtn between the host and the Bluetoath Radio Moduie
`
`The USB hardware can be embodied in one of two ways:
`
`1. As a USB dongle, and
`
`2. Integrated onto the motherboard of a notebook PC.
`
`29 November 1999
`
`AFFLT0293990
`
`Samsung Ex. 1419 p. 762
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 763 of 1082
`
`HC! USB Transport Layer
`
`Bluetouth.
`
`Finaliy, for an overview of the connection that is established between two
`Bluetooth devices, reference Figure 1.2, below-
`
`Other Host Dm-af‘5
`
`BusDri\.'ar(L2CAi
`.
`F'GHC1Librarv _
`Blueloum
`LM
`USE Furvcauan Dover
`Blualuuih
`Lg;
`Bluelooth
`Radio
`
`Furmwere
`USE Demos
`Controller
`
`USB Host
`Cenmuler
`
`Sen:-1:9 II’
`Furh'.:uor1 at
`Other UHVIOB
`
`Other Dev-nee
`
`Driver
`olher HW
`lnlerlaee
`
`LM
`
`Lc
`Blualooth
`Ra-um
`
`Ellueloolh
`
`Drwar
`'"”"""°°
`other HW
`Interlaee
`
`Figure 1.2: The figure illustrates the flow of data from one Biuetoorh device to another
`
`29 November 1999
`
`AFFLT0293991
`
`Samsung Ex. 1419 p. 763
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`HCI USB Transport Layer
`
`2 USB ENDPOINT EXPECTATIONS
`
`page 764 of 1082
`
`Bluetunth.
`
`This section outlines specific USB endpoints that are required in order to func-
`tion properly with the host. This section assumes a basic familiarity with USB.
`The endpoint numbers (labelled ‘Suggested Endpoint Address’ below) may be
`dynamically recognized upon driver initialization ~ this depends on the imple-
`mentation.
`
`2.1 DESCRIPTOR OVERVIEW
`
`The USB device is expected to be a high-speed device.
`
`The finnware configuration consists of two interfaces. The first interface (inter-
`face zero) has no alternate settings and contains the bulk and interrupt end-
`points. The second interface (interface one) provides scalable isochronous
`bandwidth consumption. The second interface has four alternate settings that
`provide different consumption based on the required isochronous bandwidth.
`The default interface is empty so that the device is capable of scaling down to
`no isochronous bandwidth.
`
`An HCI frame - consisting of an HCI header and HCI data - shouid be con-
`tained in one USB transaction. A USB transaction is defined as one or more
`
`USB frames that contain the data from one IO request. For example. an ACL
`data packet containing 256 bytes (both HCI header and HCI data) would be
`sent over the bulk endpoint in one IO request. That I0 request will require four
`64-byte USB frames - and forms a transaction.
`
`The endpoints are spread across two interfaces so. when adjusting isochro-
`nous bandwidth consumption (via select interface calls), any pending bulk and!
`or interrupt transactions do not have to be terminated and resubmitted.
`
`29 November 1999
`
`USB Endpoint Expectations
`
`AFFLTD293992
`
`Samsung Ex. 1419 p. 764
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`HCI USB Transport Layer
`
`page 765 of 1082
`
`Bluetooth.
`
`The following table outlines the required configuration
`
`Interface
`Number
`
`Alternate
`
`Setting
`
`5 uggested
`Endpoint Address
`
`Endpoint
`W99
`
`Suggested Max
`Packet Size
`
`HCI Commands
`
`DXOD
`
`Control
`
`81' 1 SE32/B4
`
`HCI Events
`
`I 0x81
`
`|nterrupt(|N)
`
`[16
`
`0x02
`
`Bulk (IN)
`
`Bulk (our)
`
`No active voice channels (for USB compliance)
`
`lsoch (IN)
`
`lsoch (OUT)
`
`voice channel with 16-bit encoding
`
`0x03
`
`lsoch (IN)
`
`lsoch (OUT)
`
`Three voice channels with B-bit encoding
`
`01:03
`
`lsoch (IN)
`
`lsoch (OUT)
`
`Two voice channels with 16-bit encoding
`
`Three voice channels with 16-bit encoding
`
`lsoch (IN)
`
`lsoch (OUT)
`
`USB Endpoinl Expectations
`
`29 November 1999
`
`AFFLT0293993
`
`Samsung Ex. 1419 p. 765
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`HCt USS Transport Layer
`
`page 766 of 1082
`
`Bluetooth.
`
`The following two examples are used to demonstrate the flow of data given the
`describe endpoints.
`
`Number of voice
`channels
`
`Duration of voice data
`
`Encoding
`
`One
`
`3 ms per IO Request
`
`8-bit
`
`USB data
`
`(header refers to H8} header)
`(Receive 8. Send from the host)
`
`Receive 0 bytes
`
`Send 9 bytes (3 header. 6 data)
`
`Receive 0 bytes
`
`Send 9 bytes (9 bytes HCi data)
`
`Receive 0 bytes
`
`Send 9 bytes (9 bytes HCI data)
`
`Receive 9 bytes (3 header, 6 data)
`Send 9 bytes (3 header, 8 data)
`
`Receive 9 bytes (9 bytes data)
`
`Send 9 bytes (9 bytes HCI data)
`
`Receive 9 bytes (9 bytes data)
`
`Send 9 bytes (9 bytes HCI data)
`
`Receive 9 bytes (3 header, 6 data)
`
`Send 9 bytes (3 header, 6 data)
`
`Receive 9 bytes (9 bytes data)
`Send 9 bytes (9 bytes HCi data)
`
`Receive 9 bytes (9 bytes data)
`
`Send 9 bytes (9 bytes HCI data)
`
`Receive 9 bytes (3 header, 6 data)
`
`Send 9 bytes (3 header. 6 data)
`
`Amount
`Received I
`
`sent (ms)
`
`Send 0
`
`010
`
`Receive 10
`
`1.2510
`
`Send 0
`
`'1.25i'0
`
`Receive 10
`
`2.50 I’ 0
`
`Send 0
`
`2.50 J’ 0
`
`Receive 10
`
`3.75 I 0
`
`Send 10
`
`3.75 1' 1.25
`
`Receive 10
`
`5.0 1' 1.25
`
`Send 10
`
`5.0 1' 2.50
`
`Receive 10
`
`6.25 I 2.50
`
`Send 10
`
`6.25 I 3.75
`
`Receive 10
`
`7.5 I 3.75
`
`Sand 10
`
`7.5 I 5.0
`
`Receive 10
`
`8.75 I 5.0
`
`Send 10
`
`8.75 I 6.25
`
`Receive 10
`
`10.0 I 6.25
`
`Table 2. 1:
`
`?{-36
`
`29 November 1999
`
`USB Endpoint Expectations
`
`AFFLT0293994
`
`Samsung Ex. 1419 p. 766
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 767 of 1082
`
`HCI USB Transport Layer
`
`USB data
`
`.
`
`(header refers to HCI header}
`(Receive 8. Send from the host)
`
`Receive 9 bytes (9 bytes data)
`
`Send 9 bytes {9 bytes HCI data)
`
`Amount
`
`Received!
`Sent {ms}
`
`Send 10
`
`10.0 I ?.5
`
`Receive 10
`
`11.25 .-‘?.5
`
`11
`
`Receive 9 bytes (9 bytes data}
`
`Send 10
`
`11.25 i 8.75
`
`Send 9 bytes (9 bytes HCI data)
`
`Table 2. 1:
`
`Convergenoe is expected because the radio is sending out an average of 8
`bytes of voice data every 1 ms and USB is sending 8 bytes of voice data every
`1 ms.
`
`Number of voice
`channels
`
`Duration of voice data
`
`Encoding
`
`3 ms per IO Request E
`
`USB data
`
`{header refers to HCI header)
`{Receive 8. Send from the host)
`
`Receive 0 bytes for Channel #1
`Send 1? bytes (3 header. 14 data)
`for Channel #1
`
`C1- EH14
`C2- OX0
`
`Receive 0 bytes for Channel #1
`Send 17 bytes (17 bytes HCI data)
`for Channel #1
`
`C1- 2D."14
`
`C2- mo
`
`C1- 2DI31
`c2- cvo
`
`C1- 2Di'31
`
`C2- 2010
`
`Receive 0 bytes for Channel #1
`C1» 2Dt28
`Send 1? bytes (17 bytes HCI data} C2- 2010
`for Channel #1
`
`.
`
`.
`
`.
`
`Amount
`
`Received 1
`Sent {ms}
`
`Send 0 for C1- 0.-'0
`C1
`C2- OIO
`
`Receive 20 C1- 2.530
`
`‘*3’ 01
`
`C2- DID
`
`Send 0 for C1- 2.5;‘0
`02
`C2- oro
`
`Receive 20 C1- 2.5/0
`
`*3’ 02
`
`C2- 2.510
`
`Send 20
`*0’ C1
`
`C1- 2.5!2.5
`C2- 2.5ro
`
`c1- 40:23
`
`C2- 0:0
`
`Receive 20 C1- 5012.5
`
`*0’ 01
`
`C2- 2.510
`
`USB Endpoint Expectations
`
`29 November 1999
`
`AFFLT0293995
`
`Samsung Ex. 1419 p. 767
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 768 OHO82
`
`HCi USS Transport Layer
`
`USB data
`( header refers to HCI header)
`(Receive 8. Send from the host}
`
`Receive 0 bytes for Channel #2
`Send 17 bytes (3 header. 14 data}
`for Channel #2
`
`Queued
`data {read
`iwrite}
`
`C1- 40i28
`02- 20314
`
`Receive 0 bytes for Channel #2
`Send 1? bytes (17 bytes HCI data)
`for Channel #2
`
`C1- 4028
`02- 40:31
`
`C1- 40/8
`02- 40:43
`
`C1- 5038
`
`02- 40143
`
`C1- 46a'22
`C2_
`
`01- 46122
`
`02- 60:23
`
`C1- 29119
`C2_
`
`Receive 0 bytes for Channel #2
`Send 17 bytes (17 bytes HCI data}
`for Channel #2
`
`Receive 17 bytes (3 header, 14
`data) for Channel
`Send 17 bytes (3 header. 14 data}
`for Channel #1
`
`Receive 17 bytes (17 bytes data)
`fUT Channel
`Send 17 bytes (17 bytes HCI data}
`for Channel #1
`
`Receive 1? bytes (17 bytes data)
`for Channel #1
`Send 1? bytes (17 bytes HCI data}
`for Channel #1
`
`Air data
`
`Amount
`Received 1
`Sent {ms}
`
`Send 0 for C1- 5.E|!2.5
`C2
`02- 2.50
`
`Receive 20 C1- 5.0.12.5
`W C2
`02- 5.010
`
`Send 20
`f°' 01
`
`C1- 5.iJ!5.U
`02- 5.010
`
`Receive 20 C1- 72515.0
`
`f°’ 01
`
`02- 5.020
`
`Send 20
`fOT
`
`C1- ?.5i5.D
`C2_
`
`Receive 20 C1- 7.5-6.0
`
`f°' C2
`
`02- 7.52.5
`
`Send 20
`fOF
`
`C1- 7.5f?.5
`C2_
`
`.
`
`.
`
`.
`
`.
`
`C1- 3236
`C2_ 50,23
`
`Receive 20
`for C1
`
`C1- 32/36
`
`.
`
`Send 20
`
`C1-10.-‘?.5
`
`02- 50:3
`
`*0’ C3
`
`02- 7.5150
`
`Receive 17 bytes (3 header. 14
`
`C1- 32/36
`
`Receive 20 C1- 10.-7.5
`
`data) for Channel
`Send 1? bytes (3 header. 14 data}
`icr Channel #2
`
`C2_
`
`fO|'
`
`C2_
`
`Receive '17 bytes (17 bytes data)
`‘W C“a”"e' *2
`Send 1? bytes (17 bytes HCI data}
`for Channel #2
`
`C1- 32/16
`02- 37f39
`
`C1- 52116
`
`02- 37:39
`
`C1- 10:10
`02- 1015.0
`
`Receive 20 C1-12.51110
`
`f°' 01
`
`02- 1015.0
`
`29 November 1999
`
`USB Endpoint Expectations
`
`AFFLT0293996
`
`Samsung Ex. 1419 p. 768
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 769 of 1082
`
`HCI USB Transport Layer
`
`USB data
`{header refers to HCI header}
`(Receive 8. Send from the host)
`
`Receive 1? bytes (17 bytes data)
`for Channel #2
`
`Send 1? bytes (1? bytes HCI data}
`for Channel #2
`
`C1- 52."1B
`
`C2- 20l36
`
`Table 2.2:
`
`Bluetooth-
`
`Amount
`Received.-'
`
`Sent (ms)
`
`C1- 12.5110
`
`C2- 10:75
`
`2.2 CONTROL ENDPOINT EXPECTATIONS
`
`Endpoint 0 is used to configure and control the USB device. Endpoint 0 will
`also be used to allow the host to send HCI-specific commands to the host con-
`troller. When the USB firmware receives a packet over this endpoint that has
`the Bluetooth class code. it should treat the packet as an HCI command
`packet.
`
`2.3 BULK ENDPOINTS EXPECTATIONS
`
`Data integrity is a critical aspect for ACL data. This, in combination with band-
`width requirements, is the reason for using a bulk endpoint. Multiple 64-byte
`packets can be shipped, per millisecond. across the bus.
`
`Suggested bulk max packet size is 64 bytes. Bulk has the ability to transfer
`multiple 64-byte buffers per one millisecond frame, depending on available bus
`bandwidth.
`
`Bulk has the ability to detect errors and correct them. Data flowing through this
`pipe might be destined for several different slaves. In order to avoid starvation,
`a flow control model similar to the shared endpoint model is recommended for
`the host controller.
`
`2.4 INTERRU PT ENDPOINT EXPECTATIONS
`
`An interrupt endpoint is necessary to ensure that events are delivered in a pre«
`dictable and timely manner. Event packets can be sent across USB with a
`guaranteed latency.
`
`The interrupt endpoint should have an interval of1 ms.
`
`The USB software and firmware requires no intimate knowledge of the events
`passed to the host controller.
`
`USB Endpoint Expectations
`
`29 November 1999
`
`AFFLT0293997
`
`Samsung Ex. 1419 p. 769
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`HCI USB Transport Layer
`
`page 770 of 1082
`
`Bluetunth.
`
`2.5 ISOCHRONOUS ENDPOINTS EXPECTATIONS
`
`These isochronous endpoints transfer SCO data to and from the host controtler
`of the radio.
`
`Time is the critical aspect for this type of data. The USB firmware should trans-
`fer the contents of the data to the host controllers’ SCO FlFOs. If the FlFOs are
`
`full. the data should be overwritten with new data.
`
`These endpoints have a one (1) ms interval. as required by Chapter 9 of the
`USB Specification. Versions 1.0 and 1.1.
`
`The radio is capable of three (3) 64Kbi's voice channels (and can receive the
`data coded in different ways — 16-bit linear audio coding is the method that
`requires the most data). A suggested max packet size for this endpoint would
`be at least 64 bytes. (It is recommended that max packet sizes be on power of
`2 boundaries for optimum throughput.) However. if it is not necessary to sup-
`port three voice channels with 16-bit coding, 32 bytes could also be considered
`an acceptable max packet size.
`
`29 November 1999
`
`USB Endpoint Expeclations
`
`AFFLT0293998
`
`Samsung Ex. 1419 p. 770
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 771 of 1082
`
`HC! USB Transport Layer
`
`3 CLASS CODE
`
`A class code will be used that is specific to all USB Bluetooth devices. This will
`allow the proper driver stack to load. regardless of which vendor built the
`device. It also allows HCI commands to be differentiated from USB commands
`
`across the control endpoint.
`
`The class code (bDeviceClass) is OXEO ~ Wireless Controller.
`
`The Subclass code (bDeviceSubC|ass) is 0x01 — RF Controller.
`
`The Protocol code (bDeviceProtoco|) is 0x01 — Bluetooth programming.
`
`29 November 1999
`
`AFFLT0293999
`
`Samsung Ex. 1419 p. 771
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 772 of 1082
`
`HCI USS Transport Layer
`
`4 DEVICE FIRMWARE UPGRADE
`
`Firmware upgrade capability is not a required feature. Bui if implemenied, the
`firmware upgrade shall be compliant with the "Universal Serial Bus Device
`Class Specification for Device Firmware Upgrade" (version 1.0 dated May 13,
`1999) available on the USB Forum web site at him:frv.mvv.r_ueb.nrg.
`
`29 November 1999
`
`Device Firmware Upgrade
`
`AFFLT0294000
`
`Samsung Ex. 1419 p. 772
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 773 of 1082
`
`HG! USS Transport Layer
`
`5 LIMITATIONS
`
`5.1 POWER SPECIFIC LIMITATIONS
`
`Today, the host controller of USB-capable machines resides inside a chip
`known as PIIX4. Unfortunately. because of errata. the USB host controller will
`not receive power while the system is in S3 or $4. This means that a USB
`wake-up can only occur when the system is in S1 or 32.
`
`Another issue with the USB host controller is that. while a device is attached. it
`
`continually snoops memory to see if there is any work that needs to be done.
`The frequency that it checks memory is 1ms. This prevents the processor from
`dropping into a low power state known as (33. Because the notebook processor
`is not able to enter the C3 state, significant power loss will occur. This is a real
`issue for business users — as a typical business user will spend almost 90% of
`their time in the C3 state.
`
`5.2 OTHER LIMITATIONS
`
`Data corruption may occur across isochronous endpoints. Endpoints one and
`two may suffer from data corruption.
`
`USB provides 16-CRC on all data transfers. The USB has a bit error rate of
`1043.
`
`Note that when a dongte is removed from the system. the radio wiii lose power
`
`(assuming this is a bus-powered device). This means that devices wiii iose
`connection.
`
`Limitations
`
`29 November 1999
`
`AFFLTiJ294-O01
`
`Samsung Ex. 1419 p. 773
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 774 of 1082
`
`HC! USE Transport Layer
`
`29 November 1999
`
`Limitations.
`
`AFFLTD294002
`
`Samsung Ex. 1419 p. 774
`
`

`
`addendum to the HCI document
`
`_
`
`
`
`3
`_' This gocum ' tdescribes the RS232 transport
`
`layer betwe n the Host and the Host Controller).
`HCI §omma d, event and data packets flow
`r
`gh thi
`"layer, but the layer does not decode
`
`s
`
`-
`
`5
`
`AFFLT0294003
`
`Samsung Ex. 1419 p. 775
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 778 of 1082
`
`HC! RS232 Transport Layer
`
`29 November 1999
`
`AFFLT0294004
`
`Samsung Ex. 1419 p. 776
`
`

`
`BLUETCJOTH SPECIFICATION Version 1.0 B
`
`page 777 c)f1D82
`
`HC! RS232 Transport Layer
`
`CONTENTS
`
`fifiemzrai ......
`
`.....................
`
`.......................................................... ..??$
`
`flvewéew ......................................................................................... II???
`
`NegmiationProtucai
`
`Packet Transfer Pmmcai
`
`tiséng deiimitars with (3683 fear synchronizatéoei ....................... ..?‘$5
`
`5.1
`5.2
`
`5.3
`5.4
`
`Using Deiimaters man C083 and CIFZC, Proiocoi Mode :3x'i3...}’8:'5
`Frarne Formai
`
`Error Messafga i'—"3r,ket._.. ........................................................ ...7’8€s
`Consistent Overheéad
`Stuff2'n.f,;
`
`using RTSECTS far Syzzahranizaiinn
`
`z;'i.'1
`
`8.2
`
`{£3
`6.4
`
`Using 3’-2TS.r’CT8 for Syn».*: without CRO. Protocm Mode Q.‘.{‘§4 ..'.783
`
`Error Message
`
`Exarnpie nf Signailirzg ............................................................. ..'.?’9{}
`Cuniroi Fiow
`6.4.‘: Case 1, Nomnaé Recovery Process ........................... ..7?=‘3
`
`65.4.23 Case 2, 84.331‘; sides detect an ewes‘ 5im=.;fiam.-ousi-g.....?9'i
`
`ES.=$.3 Case 3. Errnr Message with an error
`
`References ...................................................................................... .3394
`
`29 November 1999
`
`AFFLT0294-005
`
`Samsung Ex. 1419 p. 777
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 778 of 1082
`
`HCI RS232 Transport Layer
`
`1 GENERAL
`
`The objective of the H01 RS232 Transport Layer is to make it possible to use
`the Bluetooth HCI over one physical RS232 interface between the Bluetooth
`Host and the Bluetooth Host Controller.
`
`Bluetooth
`Host
`
`Bluetooth HCI
`
`Bluetooth
`Host
`Controller
`
`HCl RS232 Transport Layer
`
`29 November 1999
`
`AFFLTD294OD6
`
`Samsung Ex. 1419 p. 778
`
`

`
`BLUETDOTH SPECIFICATION Version 1.0 B
`
`page 779 of 1082
`
`HC! RS232 Transport Layer
`
`2 OVERVIEW
`
`There are four kinds of HCI packets that can be sent via the RS232 Transport
`Layer; i.e. HCI Command Packet, HCI Event Packet. HCI ACL Data Packet
`and HCI SCO Data Packet (see "Host (3-ontroiier interface Furrctiranai E:3,r_:ecifi«
`catic»:1"ot-tpage £317’). HCI Command Packets can only be sent to the Bluetooth
`Host Controller. HCI Event Packets can only be sent from the Bluetooth Host
`Controller, and HCI ACLISCO Data Packets can be sent both to and from the
`Bluetooth Host Controller.
`
`However, HCI does not provide the ability to differentiate the four HCI packet
`types. Therefore, if the HCI packets are sent via a common physical interface,
`a HCI packet indicator has to be added according to the Table 3 1 below.
`
`HCI packet type
`
`HCI packet in dicator
`
`HCl Command Packet
`
`HCI ACL Data Packet
`
`HCl SCO Data Packet
`
`HCJ Event Packet
`
`Error Message Packet‘
`
`Negotiation Packet’
`
`Table 2.1: HCi RS232 Packet Header
`
`in addition to those four HCl packet types, two additional packet types are
`introduced to support dynamic negotiation and error reporting. The Error Mes-
`sage Packet (0:05) is used by the receiver to report the nature of error to the
`transmitting side. The Negotiation Packet (0x06) is used to negotiate the com—
`munication settings and protocols.
`
`The HCI packetindicator shall be followed by an 8-bit sequence number that is
`incremented by 1 every time any of the above packets are sent, except when
`the retransmission packets are sent as a part of the error recovery. The HCI
`packet shall immediately follow the sequence number field. All four kinds of
`HCl packets have a length field, which is used to determine how many bytes
`are expected for the HCI packet. The Error Message Packet and Negotiation
`Packet are fixed-length packets, although the negotiation packet can be
`extended up to 7 more bytes, based on the number in the extension field.
`
`The frame of the basic RS232 Transport Packet is shown below.
`
`HCI Packet
`
`or Error llflessageihlegotlation Packet payload
`
`The least significant byte is transmitted first.
`
`Overview
`
`29 November 1999
`
`AFFLT0294007
`
`Samsung Ex. 1419 p. 779
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`HCI RS232 Transport Layer
`
`3 NEGOTIATION PROTOCOL
`
`page 780 of 1082
`
`Bluetuoth.
`
`Before sending any bytes over the RS232 link, the baud rate, parity type, num-
`ber of stop bit and protocol mode should be negotiated between the Host Con-
`troller and the Host. Tdetect is the maximum time required for the transmitter to
`detect the CTS state change, plus the time it takes to flush the transmit buffer if
`RTSICTS is used for error indication and re-synchronization. Otherwise, Tde-
`tect represents the local-side interrupt latency. H