Internet-Engineering Task Force Kulwinder Atwal/
Draft Zucotto Wireless
draft-akers-atwal-btooth-00.txt Ron Akers/
February 20, 2001 Motorola Labs
Expires: August, 2001
Transmission of IP Packets over Bluetooth Networks
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Bluetooth is a wireless standard for low cost, low power, short-
range radio communications. This document describes some issues and
goals for IPv4/IPv6, header compression, Real-Time Streaming, IP
Multicast, IPSec, QoS, end-to-end IP network design, and Link-Layer
features that are candidates for use in an IP over Bluetooth solution,
and discusses how it differs from current approaches.
R. Akers, K. Atwal [Page i]
Internet Draft Bluetooth IP February 20, 2001
TABLE OF CONTENTS
-----------------
1. INTRODUCTION............................................1
2. ISSUES AND GOALS........................................1
2.1 IPv6....................................................1
2.2 Header Compression......................................1
2.3 Real-Time Streaming.....................................1
2.4 IP Security (IPSEC).....................................2
2.5 Quality of Service......................................2
2.6 End-to-end IP Network Design............................2
3. REFERENCE BLUETOOTH IP ARCHITECTURES....................2
3.1 Reference Piconet IP Architecture.......................2
3.2 Reference Scatternet IP Architecture....................4
4. SOLUTIONS FOR IP OVER BLUETOOTH.........................5
4.1 Current BT SIG Solution for IP over Bluetooth...........5
4.2 Solution for IP under development by Bluetooth SIG......7
4.3 Possible Solutions for consideration by the IETF........7
4.3.1 Solution 1..............................................7
4.3.2 Solution 2..............................................8
4.3.2 Solution 3..............................................8
5. POSSIBLE CANDIDATES FOR USE AS A BEARER FOR IP..........9
5.1. Bluetooth Network Layer (L2CAP).........................9
5.1.1 Connection-Oriented Data Channel........................9
5.1.2 Connectionless Data Channel.............................9
5.1.3 Signalling Channel.....................................10
5.2. Host Controller (MAC) Layer............................10
5.2.1 Connection-Oriented Data (ACL).........................10
5.2.2 Connectionless Data (SCO)..............................11
5.2.3 Host Controller Command Packet.........................11
5.2.4 Host Controller Event Packet...........................11
6. GLOSSARY OF TERMS......................................12
7. Authors Addresses......................................14
8. REFERENCES.............................................14
R. Akers, K. Atwal [Page ii]
Internet Draft Bluetooth IP February 20, 2001
1. INTRODUCTION
Bluetooth is a standard for low cost, low power, short-range radio
communications. This RFC describes some of the issues and goals
that we feel should be considered in the design of IP networking for
Bluetooth wireless devices.
Typical IP based technology that we intend to discuss includes IPv4/IPv6,
header compression, Real-Time Streaming, IP Multicast, IPSec, QoS,
end-to-end IP network design, and Link-Layer features.
We also will discuss the current standard for IP over Bluetooth that is
described in published specifications from Bluetooth SIG, and we will
describe our understanding of future SIG designs. Finally we propose a
set of possible designs that the IETF could pursue.
2. ISSUES AND GOALS
2.1 IPv6:
Since Bluetooth proliferation is expected to be several hundred million
devices per year, the fast depletion of IPv4 addresses must be
considered a serious issue for the long term success of Bluetooth IP
devices and the end-to-end IP network. Since any electrical device, or
appliance can be a Bluetooth IP device, it is expected that migration to
IPv6 will be a serious concern. A goal will be to consider the issues,
time lines, and benefits involved in moving Bluetooth to IPv6, and how
Bluetooth will accelerate the move to IPv6 for the global IP network.
2.2 Header Compression:
Since Bluetooth is currently a bandwidth limited medium for IPv6,
header compression is an issue. A goal will be to consider the issues,
and concerns involved in IP using IETF header compression like ROHC.
2.3 Real-Time Streaming:
Since many real-time streaming applications require IP Multicast, IP
Multicast is an issue for the widespread acceptance of Bluetooth IP
devices. Also, the appropriate Transport Layer protocols will be
discussed as candidates for mobile wireless Real-Time Streaming. A
goal will be to consider the issues, and benefits involved in Bluetooth
IP Multicast, UDP, TCP, and SCTP.
R. Akers, K. Atwal [Page 1]
Internet Draft Bluetooth IP February 20, 2001
2.4 IP Security (IPSEC):
Since the Bluetooth Host Controller employs SAFER+ (128-bit)
encryption,as well as providing for external encryption methods for
secure transactions, security is a serious issue. A goal will be to
consider the issues, and concerns involved in providing IPSEC for IP
over Bluetooth.
2.5 Quality of Service:
Since the Bluetooth Host Controller employs QoS based on IETF
RFC 1363, providing IP with QoS is an issue. A goal will be to consider
the issues, and concerns involved in providing QoS for IP over a mobile
wireless link.
2.6 End-to-end IP Network Design:
Since the growth and use of Bluetooth IP devices is expected to place
a significant load on the global IP network, determining design
guidelines for an IP solution is an issue. A goal will be to consider
the mobile wireless issues, and concerns involved in providing an
end-to-end IP network solution.
3. REFERENCE BLUETOOTH IP ARCHITECTURES
Bluetooth devices communicate on a Master-Slave Frequency Hopping
Radio network operating within the 2.4-2.5 Giga-Hertz radio spectrum.
3.1 Reference Piconet IP Architecture:
A Bluetooth Piconet can be formed between any two Bluetooth devices
engaging in a RF discovery procedure. The discovered device becomes
a "Slave" device, while the discoverer becomes the "Master".
+------+
| |
|Master|
| |
+------+
|
|
+-----+
| |
|Slave|
| |
+-----+
Figure 3.1.1 - A simple Master-Slave Bluetooth Piconet
R. Akers, K. Atwal [Page 2]
Internet Draft Bluetooth IP February 20, 2001
+------+
| |
|Master|
| |
+------+
| | | |
+----------+ | | +--------------------+ - - - - - -+
| | +---------+ |
| | | | |
| | | |
V | | | |
+-----+ +-----+ +-----+ +-----+ +--------+
| | | | | | | | | Parked |
|Slave| |Slave| |Slave| o o o|Slave| | Slaves |
| 1 | | 2 | | 3 | | 7 | | 8-255 |
+-----+ +-----+ +-----+ +-----+ +--------+
Figure 3.1.2 - Single Bluetooth Piconet with multiple Slaves
A Master Bluetooth node can have up to seven active slaves associated
to it at any one time. There can also be a number of "parked" slaves
associated with the Master at the same time. When a slave is in the
parked state it is not participating in normal communications. A Slave
can request to be "parked", or "un-parked". Also, a Master can "park"
any of its active nodes, and "un-park" any of it's parked nodes.
R. Akers, K. Atwal [Page 3]
Internet Draft Bluetooth IP February 20, 2001
3.2 Reference Scatternet IP Architecture:
A Bluetooth Piconet can be formed between any two devices engaging in
a discovery procedure. The discovered device becomes the Slave device,
while the discoverer becomes the Master. A Scatternet can be formed
between at least three devices, where at least one device is able to
switch between the hopping sequences of the other two devices.
+------+
| |
|Master|
| |
+------+
| |
+----------+ |
| |
| +-----+
| |
+-------+ +-------+
|Slave 1| | |
|\Master| |Slave 2|
| | | |
+------ + +-------+
| | |
+----------+ | +---------+
| | |
| | |
| | |
+-----+ +-----+ +-----+
| | | | | |
|Slave| |Slave| |Slave|
| 1 | | 2 | | 3 |
+-----+ +-----+ +-----+
Figure 3.2.1 - A Bluetooth Scatternet made up of two Piconets
by a "Bridging" Master/Slave node
The Bluetooth node "Slave 1" is member of the upper Bluetooth Piconet.
The node is also a Master node in the lower Bluetooth Piconet. In this
way a series of Bluetooth nodes can become a multiple-hop wireless network.
R. Akers, K. Atwal [Page 4]
Internet Draft Bluetooth IP February 20, 2001
+-------+ +-------+
|Piconet| |Piconet|
| A | | B |
|Master | |Master |
+-------+ +-------+
| | | |
+----------+ | +---------+ +--------+
| | | |
| | | |
+-----+ +-----+ +-----+
| | | | | |
|Slave| |Slave| |Slave|
| 1A | | 2A | |3A/1B|
+-----+ +-----+ +-----+
Figure 3.2.2 - A Bluetooth Scatternet made up of two Piconets
by a "Bridging" Slave node
4. SOLUTIONS FOR IP OVER BLUETOOTH
4.1 Current Solution for IP over Bluetooth
The current IP over Bluetooth solution known as the LAN Profile [1] is
a legacy solution designed for backward compatibility based on the
serial cable replacement protocol RFCOMM [2]. The LAN Profile is a
protocol stack composed of IP, PPP(IETF), RFCOMM, L2CAP, over the
Host Controller:
+-------+ +----------------------------+
| IP | | PPP Networking |
+------------+ |----------------------------+
| P P P | | PPP | | |
+------------+ +-------------+ | L |
|SDP |RFCOMM | |SDP| RFCOMM | | |
+----+-------+ +-------------+ | A |
| L2CAP | | L2CAP | | |
+------------+ +-------------+ | N |
| Host Cont. | | Host Cont. | | |
+------------+ +-------------+ +-------+
Mobile Node LAN Access Point
Figure 4.1.1 - Bluetooth Version 1.0 Protocol Stack for
IP networking
R. Akers, K. Atwal [Page 5]
Internet Draft Bluetooth IP February 20, 2001
Shown in Figure 4.1.2 is a typical use of the LAN Profile. In this
network, one node is directly connected to an IP-based wired network.
This node is usually named an Access Point (AP), and it is conected to
up to seven active client nodes via the wireless Bluetooth link layer:
INTERNET
|
|
|
+------+
| AP |
| |
|Master|
+------+
| | | |
+----------+ | | +--------------------+ - - - - - -+
| | +---------+ |
| | | | |
PPP PPP PPP PPP
| | | | |
+-----+ +-----+ +-----+ +-----+ +--------+
| | | | | | | | | Parked |
|Slave| |Slave| |Slave| o o o|Slave| | Slaves |
| 1 | | 2 | | 3 | | 7 | | 8-255 |
+-----+ +-----+ +-----+ +-----+ +--------+
Figure 4.1.2 - Bluetooth Version 1.0 Protocol Stack for
IP networking
The IETF PPP protocol is used exclusively to transport IP traffic
to and from the clients to the AP and out to the wired network. While
this design is basically effective, all the limiting problems of running
a network over serial PPP link are evident. Moreover PPP is not
sufficient for ad-hoc networks that contain multiple wireless hops.
R. Akers, K. Atwal [Page 6]
Internet Draft Bluetooth IP February 20, 2001
4.2 Solution for IP under development by Bluetooth SIG:
The solution under development by the Bluetooth SIG is known as the
PAN profile [3], but little has been published other than it will run
Ethernet over the Bluetooth Network Layer (L2CAP) with some compression:
+----+-------+
| | IP |
+SDP |-------+
| | BNEP |
+----+-------+
| L2CAP |
+------------+
| Host Cont. |
+------------+
Figure 4.2.1 - Proposed Bluetooth Protocol Stack for
IP networking
4.3 Possible Solutions for consideration by the IETF:
4.3.1 Solution 1
The IETF may consider to run IP over modified L2CAP with, or without
compression:
+-----+------+
| SLP | |
+-----+ +
| IP |
+------------+
| ROHC(?) |
+------------+
| L2CAP(M) |
+------------+
| Host Cont. |
+------------+
Figure 4.3.1.1 - 1st. Possible Bluetooth Protocol Stack for
IP networking
In the above stack notice that we are proposing that the IETF
Service Location Protocol (SLP)- or a modified version of it- be used
as a replacement for the SDP protocol.
R. Akers, K. Atwal [Page 7]
Internet Draft Bluetooth IP February 20, 2001
4.3.2 Solution 2
The IETF may consider to run IP and L2CAP over the Host Controller
with a new protocol:
+------------+
| IP | L2CAP|
+------------+
|Foo Protocol|
+------------+
| Host Cont. |
+------------+
Figure 4.3.2.1 - 2nd Possible Bluetooth Protocol Stack for
IP networking
4.3.2 Solution 3
The IETF may consider to run L2CAP over IP over the Host Controller
with a new protocol:
+------------+
| L2CAP |
+------------+
| IP |
+------------+
| Foo2 Proto.|
+------------+
| Host Cont. |
+------------+
Figure 4.3.3 - 3rd. Possible Bluetooth Protocol Stack for
IP networking
These are some possible solutions, however there probably are many
others that should be considered and compared to the solutions that have
been presented in this document.
R. Akers, K. Atwal [Page 8]
Internet Draft Bluetooth IP February 20, 2001
5. POSSIBLE CANDIDATES FOR USE AS A BEARER FOR IP
5.1. Bluetooth Network Layer (L2CAP)
5.1.1 Connection-Oriented Data Channel:
+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
+---------------------------------------------------------------+
| Length | Channel ID | |
+---------------------------------------------------------------+
| |
| Payload |
| |
+---------------------------------------------------------------+
LSB MSB
Length (16 bits): Length of Payload in Bytes.
Channel ID (16 bits): Logical Device Address
Payload (1 to 65535 bytes): Packet Data.
5.1.2 Connectionless Data Channel:
+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
+---------------------------------------------------------------+
| Length | Channel ID (0x0002) |
|---------------------------------------------------------------|
| Protocol/Service Multiplexer | Payload |
+---------------------------------------------------------------+
LSB MSB
Length (16 bits): Length of Payload in Bytes.
Channel ID (0x0002): Logical Device Address 0x0002 is
reserved for Connectionless data.
Protocol/Service Multiplexer(PSM): Similiar to the Protocol field
in IP protocol headers.
Payload (1 to 65535 bytes): Packet Data.
R. Akers, K. Atwal [Page 9]
Internet Draft Bluetooth IP February 20, 2001
5.1.3 Signalling Channel:
+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
| Length | Channel ID (0x0001) |
|---------------------------------------------------------------|
| Commands |
| |
+---------------------------------------------------------------+
LSB MSB
Length (16 bits): Length of Payload in Bytes.
Channel ID (0x0001): Logical Device Address 0x0001 is
reserved for Signalling.
Commands (1 to 65535 bytes): One, or more commands.
5.2. Host Controller (MAC) Layer
5.2.1 Asynchronous Connection Link (ACL):
+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
| Connnection Handle |PB |BC | Length |
|---------------------------------------------------------------|
| |
| |
| Payload |
| |
+---------------------------------------------------------------+
LSB MSB
Connection Handle (12 bits): Logical Device Address.
PB (2 bits): Packet Boundary Flag.
BC (2 bits): BroadCast Flag.
Length (16 bits): Length of Payload in Bytes.
Payload (1 to 65535 bytes): Packet Data.
R. Akers, K. Atwal [Page 10]
Internet Draft Bluetooth IP February 20, 2001
5.2.2 Synchronous Connection-Oriented Link (SCO):
+---------------------------------------------------------------+
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
|Connnection Handle | Rsvd | Length | Payload |
|---------------------------------------------------------------|
| Payload (cont) |
+---------------------------------------------------------------+
LSB MSB
Connection Handle (12 bits): Logical Device Address.
Rsvd (4 bits): Reserved.
Length (8 bits): Length of Payload in Bytes.
Payload (1 to 65535 bytes): Packet Data.
5.2.3 Host Controller Command Packet:
|---------------------------------------------------------------|
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
| Opcode | Length | Parameter(s) |
|---------------------------------------------------------------|
LSB MSB
Opcode (16 bits): Host Controller Command code.
Length (8 bits): Length of Payload in Bytes.
Parameters (0 to 65535 bytes): Zero, or more command parameters.
5.2.4 Host Controller Event Packet:
|---------------------------------------------------------------|
|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|
|---------------------------------------------------------------|
| Event Code | Length | Parameter(s) |
|---------------------------------------------------------------|
LSB MSB
Event Code (8 bits): Host Controller Event code.
Length (8 bits): Length of Payload in Bytes.
Parameters (1 to 65535 bytes): One or more Event Parameters.
R. Akers, K. Atwal [Page 11]
Internet Draft Bluetooth IP February 20, 2001
6. GLOSSARY OF TERMS
Active Member(AM):
A device with a valid active Link.
AM_ADDR:
A 3-bit physical address assigned by the Master to a Slave device during
connection setup.
Access Point(AP):
A wireless node that directly connects to a wireline network, and
provides network access to other wireless nodes that are associated
to the AP. Typically, the wireline network is the INTERNET or an IP
based Intranet.
Baseband:
A Physical Layer Device (PHY2).
BD_ADDR:
A 48-bit physical address used by a Bluetooth device for discovery
and connection setup.
Bluetooth Radio:
A Radio Interface (PHY1).
Connection Handle:
A 12-bit logical address assigned to a physical link by the Host
Controller.
Frequency-Hopping Radio:
A radio that uses a Frequency Hopping Sequence for communications.
Frequency-Hopping Sequence:
A set of radio frequencies that are selected in pseudo-random order to
tune a radio to a new frequency once per Slot-Time.
Host Controller:
A controller consisting of the MAC(MAC1 + MAC2) and PHY(PHY1 + PHY2).
Host Controller Interface:
An API provided by the Host Controller Driver.
IP:
Internet Protocol
L2CAP:
Logical Link Control and Adaptation Protocol
R. Akers, K. Atwal [Page 12]
Internet Draft Bluetooth IP February 20, 2001
Link Controller:
A lower Link Layer Controller (MAC1)
Link Manager:
A upper Link Layer Controller (MAC2).
Master Device(MD):
The device delegated as the router on a Piconet.
Master-Slave Network:
A network where a single device is delegated the Master, and all other
devices assume the role of Slave devices. A Master must poll a Slave
device by addressing a packet to a Slave device, before a Slave device
can transmit. All communications are either Master to Slave,or Slave to
Master. Since all communications in a Master-Slave Network are between
the Master and a Slave, the Master is effectively the router. A Master-
Slave Network must have one and only one Master device. A Master-Slave
network may have broadcast capabilities.
Master/Slave Slot-Pair:
The smallest integral unit of transmission composed of a Master device
Slot-Time followed immediately by a Slave device Slot-Time
Parked Member(PM):
A device with a valid dormant link.
Piconet:
Two or more Bluetooth devices linked on the same Frequency-Hopping
Sequence.
Piconet Active Member Broadcast:
A packet addressed to be received by all Active Members.
Piconet Broadcast:
A packet addressed to be received by all Active and Parked Members.
PM_ADDR:
A 8-bit physical address assigned by the Master to a Parked Slave
device.
PPP:
IETF Point to Point Protocol
RFCOMM:
Serial port emulation protocol
Scatternet:
Three or more Bluetooth devices linked on at least two Frequency-Hopping
Sequences. A device may be a slave on all sequences, or a master on one
and a slave on the other.
R. Akers, K. Atwal [Page 13]
Internet Draft Bluetooth IP February 20, 2001
SDP:
Bluetooth Service Discovery Protocol
Slave Device(SD):
A device not acting as a router on a Piconet.
Slot-Time:
A fixed interval of time specifying the duration that a radio will spend
tuned to one frequency before tuning to a new frequency. For Bluetooth
this is 625 microseconds with a clock jitter of -/+ of 10 microseconds
and a clock drift rate of 20 parts per million.
Un-discovered Device(UD):
A device that has not been discovered.
7. Authors Addresses
Ronald G. Akers
Motorola Laboratories
1301 Algonquin Rd.
Schaumburg IL. 60196
ron.akers@motorola.com
Kulwinder S. Atwal
Zucotto Wireless
130 Slater St.
Ottawa, Ontario, Canada
kulwinder.atwal@zucotto.com
8. REFERENCES
[1] Specification of the Bluetooth System Profiles Verbsion 1.0.
(http://www.bluetooth.com/developer/specification/specification.asp)
[2] Specification of the Bluetooth System Core Version 1.0.
(http://www.bluetooth.com/developer/specification/specification.asp)
[3] Bluetooth SIG Working Group Charters
(http://www.bluetooth.com/sig/sig/sig.asp)
R. Akers, K. Atwal [Page 14]
Internet Draft Bluetooth IP February 20, 2001