Bluetooth: From Ericsson's Cable-Replacement Project to a Shared Radio Standard

Bluetooth is often remembered as a convenient way to remove the cable between a phone and a headset. Its history is more interesting: it began as a short-range radio project at Ericsson, but became broadly useful only after companies with competing products agreed to develop a shared specification and test for interoperability. The radio link was one layer of the achievement. Device discovery, host-controller interfaces, profiles, qualification, and a stable public specification made it possible for a headset from one company to work with a phone from another.

The term “Bluetooth” is a project name drawn from the story of Harald Bluetooth, a tenth-century Danish king. It was initially intended to be temporary, but marketing alternatives were not ready when the technology needed a public identity. The story is an unusually visible reminder that standards often carry a working label into the marketplace. The name’s historical anecdote is secondary to the engineering point: cross-industry collaboration was necessary because no single handset or computer maker could make a cable-replacement radio useful on its own.

The cable-replacement problem

Ericsson traces the project seed to 1989 research into alternatives to wired connections. In the ensuing effort, manager Tord Wingren commissioned Jaap Haartsen and Sven Mattisson to develop a way to connect computers with wireless headsets; they set out to replace RS-232 telecommunication cables. The target was not to create a general Internet access technology, but a short-range link among personal and fixed electronic devices.

That objective imposed design constraints. A radio had to be inexpensive enough for consumer devices, use modest power, cope with interference, and support communication among products from different manufacturers. A private Ericsson implementation could prove the radio, but it would not create a broad accessory market. A universal cable replacement required a common specification and a way for participants to trust that products actually implemented it.

In 1996, Intel, Ericsson, and Nokia met to plan standardization. The Bluetooth SIG’s own history identifies Ericsson, IBM, Intel, Nokia, and Toshiba as the five companies that formalized the wire-replacement effort and formed the SIG on May 20, 1998. The SIG’s role extended beyond publishing a radio description: it maintained specifications, profiles, assigned values, and qualification processes intended to encourage interoperability. Standardization transformed a product concept into an ecosystem.

Why the architecture needed layers

Bluetooth’s design separated responsibilities across layers. The radio and baseband provided the short-range wireless link and time-based exchange. A link manager handled connections and control procedures. Higher-level components provided host access, logical channels, service discovery, and application-facing profiles. The Core Specification’s architecture chapter describes Bluetooth as a system with communication topologies and transport features rather than merely a radio modulation.

This layered model allowed different kinds of products to use a common lower-level transport while defining different behaviors above it. A headset, serial-cable replacement, file-transfer application, or input device needed more than the ability to exchange bits. The devices needed to agree on how to find each other, what service was offered, which operations were valid, and how to represent data.

Bluetooth’s Service Discovery Protocol (SDP) addresses the changing availability of nearby services. A device can inquire about services exposed by another reachable device rather than assume that every peer has the same application capabilities. The SIG’s specification states that SDP helps clients determine available services and their characteristics. It does not itself make those services compatible: a profile and application protocol must define how to use one.

Profiles became a crucial interoperability abstraction. A core specification might provide many optional features, but two devices could still choose incompatible combinations. A profile narrows the choices for a use case and specifies how the relevant protocols are combined. This is why “both devices support Bluetooth” is not enough to infer that every feature will work. The products must implement compatible versions and the necessary profiles and features.

The radio and its tradeoffs

Bluetooth Classic, or Basic Rate/Enhanced Data Rate (BR/EDR), and Bluetooth Low Energy (LE) are distinct radio-system configurations within the broader Bluetooth technology. They share ecosystem branding and parts of a broader standards organization, but should not be collapsed into one interchangeable radio protocol. Bluetooth Core documentation distinguishes BR/EDR and LE systems and their behavior.

BR/EDR operates in the 2.4 GHz unlicensed industrial, scientific, and medical band. The radio specification describes frequency hopping as a method to address interference and fading; Basic Rate uses a shaped binary frequency modulation, with optional Enhanced Data Rate modes using phase modulation. The nominal gross rate in the original Basic Rate mode is not the same as application throughput. Packet headers, acknowledgments, retransmissions, profiles, link scheduling, and competing traffic consume capacity.

The technology’s low-power goals did not mean all Bluetooth devices had identical power consumption. A product’s radio mode, duty cycle, transmit level, connection interval, data volume, and application behavior determine its actual energy use. Likewise, “short range” is a design category, not a single guaranteed distance: antenna, environment, interference, device class, and regulations matter. Marketing language can obscure how these variables affect real connections.

Discovery, pairing, and user expectations

Early Bluetooth experiences made discovery and pairing visible because devices needed to identify nearby peers and establish a trusted or usable relationship. Those processes are sometimes mistaken for the entire protocol. In reality, device discovery, link establishment, service discovery, authentication, and application procedures are distinct steps. A product could discover another radio and still fail to provide the expected service because it lacked a common profile or did not agree on parameters.

User-facing pairing also evolved across specification versions. Early device interactions and current mobile operating-system flows are not identical. The history is a reason to describe a particular version and profile when explaining behavior rather than treating present smartphone UX as intrinsic to every 1990s Bluetooth product.

The SIG’s conformance and qualification program addresses a system-level challenge: standards text alone does not ensure that independently designed products interoperate. Test suites and qualification help vendors check behavior against defined requirements. They cannot guarantee that every product choice will satisfy every user’s expectations, but they create a shared process for reducing implementation differences.

Standards grew through versioned releases

The public version history of the Core Specification records the first included protocol elements in 1998 and publication of Bluetooth Specification 1.0a on the public web in July 1999. Early versions added the radio specification, L2CAP, RFCOMM, host-controller interfaces, service discovery, and other parts over successive drafts. This chronology matters because “Bluetooth 1.0” is not a single design frozen at the project’s start; the technical package was assembled, reviewed, and revised.

Later releases introduced new capabilities and reorganized the specification into volumes and individual profile documents. The Core Specification’s version-history chapter records those revisions and their dates. Some legacy transport or profile material has since been moved or deprecated, while newer versions add capabilities for new use cases. A device’s advertised core version alone is not a complete feature statement, because optional functionality and profiles still determine what it can do.

Bluetooth Low Energy, introduced as part of Bluetooth 4.0, brought a different connection and data model aimed at low-duty-cycle sensors and peripherals. It is not merely Classic Bluetooth with a lower transmit power. LE has distinct advertising, scanning, connection, and attribute/profiles mechanisms. That architecture opened new markets in health devices, beacons, accessories, and sensors, while preserving the need for compatible application-level services.

Governance and market scale

The SIG created a mechanism for member companies to contribute to specifications and for the ecosystem to use one public identity. The organization also controls qualification and the Bluetooth brand. That governance structure is not the same as a single company opening a proprietary protocol or a formal government standardization body writing an abstract specification without product testing. It combines member-driven technical work, intellectual-property rules, testing, and marketing.

Interoperability helped generate network effects. Users were more likely to buy accessories when they could work with multiple phones; handset makers benefited when compatible accessories already existed; computer manufacturers could adopt the same ecosystem for peripherals. A multi-company standard reduces the risk that an accessory is stranded by one vendor’s private interface. The gain depends on maintaining profiles and qualification discipline as the number of product types grows.

Bluetooth also competed with alternatives. Infrared links, proprietary radio systems, Wi-Fi, and wired USB each offered different performance, range, cost, power, and configuration tradeoffs. Bluetooth’s niche was not simply “wireless is better.” Its design aimed to make low-cost nearby device communication sufficiently interoperable and low-friction for products that did not need a high-throughput local-area network.

Avoiding common historical shortcuts

The familiar origin story about a Viking king provides a memorable name explanation but does not identify the inventors, initial project goals, or standardization process. Ericsson’s records give context for the engineering team; Bluetooth SIG materials document the member organization and specification milestones. Each is a different type of evidence.

It is also inaccurate to attribute the entire system to one inventor or one company. Ericsson engineers produced important early radio work, while the broad specification came from a group of companies and later member contributors. The technology’s history includes implementation, protocol design, interoperability testing, product development, and continuing standard revisions.

Finally, Bluetooth is not one protocol in the sense of a single fixed message format. It is a family of specifications and profiles whose capabilities change by generation. A sound historical explanation names the relevant mode and version and separates radio behavior from host interfaces and application profiles. That specificity is necessary to explain why a device can be “Bluetooth-enabled” yet not support a particular accessory feature.

From wire replacement to platform

Bluetooth’s technical success came from a precise combination: an inexpensive short-range radio, shared protocol layers, discoverable services, application profiles, a member organization, and a qualification process. The first product that removes a cable is not automatically a platform. The platform emerges when independent manufacturers can build compatible products and users can expect them to work together within defined limits.

The technology continues to evolve, but its early history remains a useful example of collaborative infrastructure. The project started with a bounded task - connect nearby devices without a cable - and grew by making the boundaries between radio, transport, discovery, and application behavior explicit. That architecture let new profiles and use cases build on the same ecosystem while making compatibility a testable goal rather than a slogan.

Related:

Sources: