4/20/2015 (cid:9)
`
`CNN.com - Bluetooth 1.1 addresses earlier flaws - August 14, 2001
`
`Mix om
`
`e& PRI NTTHIS
`Powered by MN
`lickability
`
`Bluetooth 1.1 addresses earlier flaws
`
`By Troy Holtby
`
`(IDG) -- Imagine wireless connectivity that lets you effortlessly exchange business cards, files and other
`information with a co-worker. Or wireless technology that lets you set up your own personal-area network
`to link your PC to handheld devices, mobile phones, printers, scanners, fax machines and copiers. The new
`Bluetooth 1.1 specification promises to make such affordable wireless connections an everyday reality.
`Bluetooth Version 1.0b failed to fully deliver on its promise as a result of unexpected interoperability issues.
`Bluetooth 1.0b defined specific functionality but did not mandate specific implementation criteria, leaving key parts
`of the specification open to interpretation.
`As a result, interoperability problems arose and thwarted widespread implementation. When a Bluetooth cell phone
`from Vendor A does not work with a Bluetooth PC card from Vendor B, the user is not exactly encouraged to buy a
`Bluetooth printer from Vendor C. Fortunately, Bluetooth 1.1 addresses these interoperability issues.
`The most significant change to Bluetooth in Version 1.1 involves authentication. Bluetooth communications are
`encrypted for security. When two Bluetooth devices try to establish a link, one of the first things they do is
`exchange keys confirming their identities. If the keys don't match, the two devices won't talk to each other.
`Under Bluetooth 1.0b, the two devices could get into an irreconcilable race condition during the initial link
`negotiation. The devices would execute the algorithm to generate the key, but each device would generate a
`different key. The problem revolves around timing.
`Generating the correct key depends on which device initiates the conversation (the master) and how fast the
`responding device (the slave) replies to the master's communications. If the slave can process information faster
`than the master, the ensuing race condition can leave each device calculating that it is the master. Based on that
`error, the devices fail to generate matching keys.
`Bluetooth 1.1 rectifies this problem by more thoroughly defming the steps required for device authentication.
`Specifically, Version 1.1 requires that each device confirm its role in the master/slave relationship by reconciling
`and/or acknowledging which device initiated interaction.
`A more basic interoperability issue concerns the harmonization of frequencies. Bluetooth divides the 2.4-GHz
`frequency into 79 hops. Using a technique called frequency-hopping spread spectrum to transmit data, the master
`and slave must synchronize their movements up and down the 2.4-GHz frequency to maintain their connection. If
`they don't arrive at the same hop at the same time, the devices can't communicate.
`Unfortunately, France, Japan, Spain and a few other countries use the 2.4-GHz frequency for noncommercial
`purposes, such as military communications. To accommodate these countries, Bluetooth 1.0b defined a second hop
`count that avoided select areas of the 2.4-GHz spectrum and divided the frequency into 23 hops. Devices built to
`work at 79 hops are incompatible with those built to work at 23 hops.
`To address this problem, the Bluetooth Special Interest Group negotiated with the 23-hop countries to allow use of
`79-hop equipment, which let Bluetooth 1.1 eliminate the 23-hop option. All Bluetooth 1.1 devices use 79 hops to
`communicate within the 2.4-GHz frequency.
`Incompatible data formatting could also prevent interoperability in Bluetooth 1.0b devices. Bluetooth supports up to
`five slots per packet to reach its maximum data transfer rate of 720K bit/sec per channel. However, not all
`Bluetooth devices support five-slot packets. If a master ties to send more slots per packet than the slave can
`support, communications fail.
`
`http://cnn.career.pri ntthi s.clickabi I ity.com/pt/cpt?expi re=- 1&title=C N N .com +-+ BI uetooth+ 1.1+addresses+ earl ier+fl aws+-+August+ 14%2C+2001&url ID=5342... (cid:9)
`
`1/2
`
`SAMSUNG ELECTRONICS CO., LTD., v. AFFINITY LABS OF TEXAS, LLC
`IPR2014-01181 EXHIBIT 2032 – 1
`
`

`

`412012015 (cid:9)
`CNN.com - Bluetooth 1.1 addresses earlier flaws - August 14,2001
`Under Bluetooth 1.0b, slave devices couldn't tell master devices how many slots could be used during
`communications. Bluetooth 1.1 fixes this problem by letting the slave communicate back to the master with
`information about the packet sizes. In Version 1.1, a slave can tell a master to send fewer (or more) slots per
`packet when necessary.
`
`The Bluetooth 1.1 specification was finalized earlier this year, and vendors have begun shipping 1.1-compliant
`products.
`
`Find this article at
`http://edition.cnn.com/2001/TECH/ptech/08/14/bluetooth.1.idg
`
`Check the box to include the list of links referenced in the article.
`
`2008 Cable News Network
`
`http://cnn.career.printthis.clickability.com/pt/cpt?expire=-1&title=CNN.com+-+Bluetooth+1.1+addresses+earlier+flaws+-+August+14%2C+2001&urlID=5342... (cid:9)
`
`212
`
`SAMSUNG ELECTRONICS CO., LTD., v. AFFINITY LABS OF TEXAS, LLC
`IPR2014-01181 EXHIBIT 2032 – 2
`
`