Internet-Engineering Task Force Kulwinder Atwal/ Draft Zucotto Wireless draft-akers-atwal-btooth-01.txt Ron Akers/ May 27, 2001 Motorola Labs Expires: November, 2001 Obsoletes: draft-akers-atwal-btooth-00.txt 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, local radio communications. This document describes how to use the Specification of the Bluetooth System Core Version 1.1 standard for the transport of Internet Protocol Version 4 and Internet Protocol Version 6 datagrams. This document describes link MTU, path MTU, Address Resolution, IPv6 Interface ID, encapsulation, and how to route unicast, multicast, anycast, and broadcast IP datagrams over the Bluetooth link-layer. 1. INTRODUCTION Bluetooth is a wireless standard for low cost, low power, local radio communications. The Specification of the Bluetooth System Core Version 1.1 [INTRO:1] is standardized in the Bluetooth Special Interest Group, Inc. This document describes an IP over Bluetooth solution, and discusses how it differs from current approaches. K. Atwal, R. Akers [Page 1]
Internet Draft Bluetooth IP May 28, 2001 TABLE OF CONTENTS ----------------- 1. INTRODUCTION..................................................1 2. MOTIVATION....................................................3 2.1 Proposed Solution...........................................4 3. IP ENCAPSULATION..............................................5 4. ADDRESS RESOLUTION............................................6 4.1 Link-Local Address Resolution (within a Piconet)............6 4.2 Global Address Resolution (within an IP subnet).............6 4.3 ARP Encapsulation...........................................7 5. IPv6 INTERFACE ID MAPPING.....................................8 6. IP ROUTING....................................................8 6.1 IP Link-Layer Routing Table.................................8 6.2 IP Unicast..................................................9 6.3 IP Multicast................................................10 6.4 IP Broadcast................................................10 6.5 IP Anycast..................................................10 7. MAXIMUM TRANSMISSION UNIT.....................................11 7.1 Link MTU....................................................11 7.2 Path MTU....................................................11 8. GLOSSARY OF TERMS.............................................11 9. Authors Addresses.............................................13 10. REFERENCES....................................................14 11. REFERENCE BLUETOOTH IP ARCHITECHURES..........................15 11.1 Piconet Reference IP Architecture...........................15 11.2 Scatternet Reference IP Architecture........................16 11.2.2 Scatternet Slave IP Architecture............................17 11.2.3 Scatternet Master IP Architecture...........................17 K. Atwal, R. Akers [Page 2]
Internet Draft Bluetooth IP May 28, 2001 2. Motivation The current solution places IP over the Bluetooth Network Encapsulation Protocol (BNEP). BNEP runs over the Bluetooth Logical Link Control and Adaptation Protocol (L2CAP). While BNEP is a method for IP Encapsulation, it has drawbacks, limitations, and is a duplication of the functionality provided directly by IP. BNEP Drawbacks: o Adds an additional encapsulation layer between the L2CAP encapsulation layer, and the encapsulation provided by IP, such that there are three encapsulation layers for an IP Bluetooth solution: L2CAP, BNEP, and IP. o BNEP/L2CAP is not optimized for the transmission of IP, the most widely used network protocol. o BNEP is implicitly based on IETF "IP over IEEE 1394", which unlike Bluetooth has no encapsulation layer. o Treats IP as less important than other protocols. Limitations: o Not interoperable across the Internet, or any other type of network. o Will require BNEP headers to be removed and added for other types of link-layers like USB, I2C, CANBus, IEEE 1394, and 3G Cellular. Duplication of Effort: o IP already supports encapsulation of the protocols currently specified by BNEP, or envisioned such as IPX, AppleTalk, and Ethernet. o While BNEP is easy to invent, it will require vendors to support and maintain two protocols that provide the same functionality: BNEP and IP. o The support and maintenance costs for vendors will increase over time as more functionality is added to BNEP, while the needed functionality is already available in IP. At some point, vendors will have to weigh the costs of continuing to support two protocols with the same functionality. K. Atwal, R. Akers [Page 3]
Internet Draft Bluetooth IP May 28, 2001 The approach taken in this draft is not to support the creation of a "Bluetooth Only" networking solution, that considers Bluetooth devices as only forming a Bluetooth network in isolation of other types of networks. But, to consider a Bluetooth device as a part of a larger heterogeneous IP network, where each link-layer is responsible for interacting with IP according to its own unique characteristics [HOST:1]. The larger heterogeneous IP network may be composed of any combination of link layers, such as, but not restricted to: USB, IEEE 1394, Ethernet, I2C, CANBus, DeviceNet, Bluetooth, and 3G Cellular. In this document Bluetooth will be treated as another link layer over which all IP compatible protocols will be carried in an optimal manner [HOST:2]. This approach has the advantage of allowing a collection of Bluetooth devices the ability to communicate and discover each other over the Internet, or any wired/wireless IP capable network. Also, this approach allows an ad hoc network to be treated as an isolated IP capable network, rather than as a special case requiring special protocols. This approach shows there to be two areas of interest in an IP capable heterogeneous network: 1. IP: Network-layer specific 2. Bluetooth: Link-layer specific. These two areas suggest the use of L2CAP for Bluetooth link-layer specific encapsulation, and the use of IP for any network-layer specific encapsulation. The limited functionality of BNEP is replaced by the much greater functionality already provided by Protocol Numbers [IANA:1], and UDP/TCP Port Numbers [IANA:2] in the Internet Protocol. 2.1 Proposed Solution. The proposed solution in this draft will have the following stack on a Mobile Node attached to an IP capable network that may be an isolated IP capable network, or a larger IP capable network: +----------------------+ | Internet Protocol | +----------------------+ | L2CAP | +----------------------+ | LMP | +----------------------+ K. Atwal, R. Akers [Page 4]
Internet Draft Bluetooth IP May 28, 2001 The proposed solution will have the following stack on an IP Router [ROUTER:1] attached to an IP capable wired-line network: +----------------------------------+ | Internet Protocol | +------+---+-----------------------+ |L2CAP | | Encapsulation | +------+ +-----------------------+ (I.E. Ethernet, CANBus, USB,..) | LMP | | Wired-Line Link-Layer |---------------------------> +------+ +-----------------------+ [To Wired-Line Network] The proposed solution will have the following stack on an IP Router attached to an IP capable wireless network: +---------------------------------+ | Internet Protocol | +------+---+----------------------+ |L2CAP | | Encapsulation | +------+ +----------------------+ | LMP | | Wireless Link-Layer | (I.E. 802.11b, 2.5G, 3G,..) +------+ +----------------------+ 3. L2CAP IP Encapsulation using a connectionless data channel Unlike some other link-layers, such as IEEE 1394, Bluetooth has an encapsulation protocol called L2CAP. L2CAP provides a Channel Identifier (CID) field for the dynamic encapsulation of other protocols after a Service Discovery procedure has been completed by SDP. Using the CID field for the encapsulation for the Internet Protocol: | | | Length | Channel ID | Payload | +----------+------------+----------+ | 16 bits | 16 bits | | +----------+------------+----------+ 3.1 IP Encapsulation: | | | Length | Channel ID | Payload | +----------+------------+-----------+ | 16 bits | CID_IP | IP Packet | +----------+------------+-----------+ The Service Discovery procedure can be further extended over an IP capable network by merging SDP with the IETF Service Locator Protocol. The SDP Record and SLP Service Attributes are to be defined. K. Atwal, R. Akers [Page 5]
Internet Draft Bluetooth IP May 28, 2001 4. Address Resolution 4.1 Link-Local Address Resolution (within a Piconet) The Bluetooth link-layer is connection-oriented. Any two devices that wish to communicate must setup a point-to-point connection. The device initiating the connection assumes the role of "Master Device", and the device being connected to assumes the role of "Slave Device". The roles of "Master" and "Slave" may be reversed at any time. While a single connection is point-to-point, like any other type of Master-Slave network, the Master may have more than one point-to-point connection active at any time. A device assuming the role of "Slave" device may also be an active "Master" device on its own subnet (A Piconet Bluetooth), or visa versa. A connection must be setup before any IP packets can flow. There are two ways that a connection can be initiated: o Inquiry followed by Page o Page If the Bluetooth link-layer address of the other device is not known previously, the Inquiry procedure must be preformed by the device requesting a connection. If the link-layer address is known then the requesting device can just perform the Page procedure. In any case, after the connection setup process is complete both devices will know the link-layer address of the other. Therefore, a link-layer address resolution protocol [ARP:1] is not necessary within a Piconet. The Master holds all link-layer addresses within the Piconet as a result of connection setup. 4.2 Global Address Resolution (across an IP subnet) An End-User wishing to discover the link-layer identity of device attached at some distance away on the IP network will need an Address Resolution Protocol [ARP:1]. Since the Bluetooth setup procedure is link-local, a method for discovering the link-layer identity of a device is necessary across an IP network. The End-user will need access to the same link-layer information that is available within a single Piconet, such as: o (CoD) Class of Device (24 bits) o (UAP) Upper Address Part (8 bits) o (NAP) Non-significant Address Part (16 bits) o (LAP) Lower Address Part (24 bits). K. Atwal, R. Akers [Page 6]
Internet Draft Bluetooth IP May 28, 2001 The ARP format [ARP:1],[IANA:3] can be used to convey link-layer identity across an IP network: ar$hrd 16 bits Hardware type (Bluetooth assigned by IANA) ar$pro 16 bits Protocol type ar$hln 8 bits Byte length of each hardware address (9) ar$pln 8 bits Byte length of each protocol address (m) ar$op 16 bits Operation code ar$sha 9 bytes source hardware address (CoD,UAP,NAP,LAP) ar$spa mbytes source protocol address ar$tha 9 bytes target hardware address ar$tpa mbytes target protocol address Where the hardware address is nine bytes composed of: o (CoD) Class of Device (24 bits) o (UAP) Upper Address Part (8 bits) o (NAP) Non-significant Address Part (16 bits) o (LAP) Lower Address Part (24 bits). The hardware address field packet format is: | | | CoD | UAP | NAP | LAP | +----------+--------+---------+---------+ | 24 bits | 8 bits | 16 bits | 24 bits | +----------+--------+---------+---------+ 4.3 L2CAP ARP Encapsulation using a connectionless data channel L2CAP provides a Protocol Service/ Multiplexer (PSM) field for encapsulation of the Address Resolution Protocol. The PSM field can can be used for the encapsulation of the Address Resolution Protocol: | | | Length | Channel ID | Protocol Service/Multiplexer | Payload | +----------+------------+------------------------------+-----------+ | 16 bits | 16 bits | 16 bits | | +----------+------------+------------------------------+-----------+ 3.1 IP Encapsulation: | | | Length | Channel ID | Protocol Service/Multiplexer | Payload | +----------+------------+------------------------------+------------+ | 16 bits | 0x0002 | PSM_ARP | ARP Packet | +----------+------------+------------------------------+------------+ Also, a merged Service Discovery/Locator Protocol may convey link-layer indentity. K. Atwal, R. Akers [Page 7]
Internet Draft Bluetooth IP May 28, 2001 5. IPv6 Interface ID Mapping In an IPv6 network, link-layer information can be provided through the IPv6 Address [IPV6:1]. During connection setup the Bluetooth devices will exchange their link-layer identity: o (CoD) Class of Device (24 bits) o (UAP) Upper Address Part (8 bits) o (NAP) Non-significant Address Part (16 bits) o (LAP) Lower Address Part (24 bits) The 64-bit Interface ID of an IPv6 address will be formed by the CoD, NAP, and LAP: | | | subnet prefix | Interface ID | +----------------+------------+-----+-----+ | 64 bits | CoD | NAP | LAP | +----------------+------------+-----+-----+ This combination is included for three reasons. It allows: o IP devices to be addressed based on their function. (I.E.: All printers, or all fax machines) o there to be no unused bits in the Interface ID. o the Interface ID to be site unique. Accessing devices based on their function (CoD) allows network operators to account, monitor and control IP devices based on their function. A network operator may send a request to all IP devices of a particular type by setting bits in the interface ID, such as: "Download maintenance records from all printers attached to the IP network". 6. IP Routing 6.1 IP Routing Table: Routing in a Bluetooth Network, like any other type of Master-Slave network, is accomplished by a single device acting as the Master. The Master must maintain a table of IP addresses to link-layer addresses for every attached IP capable device [ROUTER:1]. The mapping may be an IP address to a logical link-layer address (link local), or a physical link-layer address. An implementation may use a logical link-layer address such as the logical Connection Indentifier (CID) provided by L2CAP. K. Atwal, R. Akers [Page 8]
Internet Draft Bluetooth IP May 28, 2001 For a dynamically assigned IP address: +------------+-----+-------------------+ | IP Address | CID | Bluetooth Address | +------------+-----+-------------------+ For a permanently assigned IP address, the IP address may be used to uniquely identify a device: +------------+-----+ | IP Address | CID | +------------+-----+ 6.2 IP Unicast: On a Bluetooth Piconet the primary mode of communication is point-to-point time-slot based according to a scheduling algorithm. Slave devices may be scheduled for communications in a time-slot manner based on the policy negotiated by the Master and Slave device upon connection setup to reduce power consumption. When an IP unicast packet arrives, the Master will check its IP to link-layer routing table to ensure that the device with the correct link-layer address is connected, before scheduling the packet for delivery at the next available time-slot for that particular Slave device. 6.3 IP Multi-cast: When a single Slave device in a Piconet is a participant of an IP Multi-cast, the Master after checking its routing table, will route the Multi-cast packet identical to an IP Unicast packet. For Bluetooth devices that do not support Broadcast all packets shall be sent as per Section 6.2 IP Unicast. If there is more than one Slave device participating on the same Multi-cast session, then routing is identical to an IP Broadcast packet to multiple devices [6.4.2]. 6.4 IP Broadcast: 6.4.1 IP Broadcast to single device: When only one Slave device in a Piconet is the receiver of an IP Broadcast, after checking the routing table, routing is identical to that of a Unicast packet. K. Atwal, R. Akers [Page 9]
Internet Draft Bluetooth IP May 28, 2001 6.4.2 IP Broadcast to multiple devices: If sufficient unused bandwidth is available, the slots required for the session shall be allocated from available unused bandwidth, by the Bluetooth Scheduler using the Host Controller Interface. If insufficient bandwidth is available, then the Slots required for the session must be subtracted equally from the slots allocated ONLY to the participants. If there is an odd number of slots per participants, the first participants to join will supply the remainder. The slots must be used for a Piconet Active Member Broadcast. If some of the participants are Parked devices, these participants should be made active, and given sufficient bandwidth for the Broadcast. If it is not possible to un-Park all the participants, then a Piconet Broadcast shall be used. 6.5 IP Anycast: When only one Slave device in a Piconet is the receiver of an IP Anycast packet, after checking the routing table, routing is identical to that of a Unicast packet. If more than one Slave device could be the potential receiver of an IP Anycast packet, then the Slave device with the earliest scheduled slot will be the receiver of the Anycast IP packet. K. Atwal, R. Akers [Page 10]
Internet Draft Bluetooth IP May 28, 2001 7. MTU 7.1 Link MTU: The Maximum Transmission Unit for an L2CAP packet is 65535 bytes. In a Bluetooth network all L2CAP packets are delivered in-order. Therefore, the IP header does not need to be re-transmitted for every IP fragment sent over L2CAP. Only the first IP fragment must have an IP header. An implementation must set the Logical Channel Code (L_CH Code) in the Link Manager Protocol header to 0x01 to indicate the continuation of the last IP fragment of an IP packet greater than the L2CAP MTU size of 65535 bytes (IP header + payload). And, set the Logical Channel Code to 0x10, to indicate the start of the next IP packet. It is not necessary to know the end of an IP packet at the L2CAP level, as this can be inferred from the length field in the IP header. There is no Maximum Transmission Unit for IP over L2CAP, when the Logical Channel Code is used effectively. But, an implementer may define an IP MTU that is appropriate for the intended application. 7.2 Path MTU: IPv4 Path MTU discovery will be done in accordance with [PATHMTU:1]. When one IP host has a large amount of data to send to another host, the data is transmitted as a series of IP datagrams. It is usually preferable that these datagrams be of the largest size that does not require fragmentation anywhere along the path from the source to the destination. This datagram size is referred to as the Path MTU (PMTU), and it is equal to the minimum of the link MTUs of each hop in the path. IPv6 Path MTU discovery will be done in accordance with [PATHMTU:2]. When one IPv6 node has a large amount of data to send to another node, the data is transmitted in a series of IPv6 packets. It is usually preferable that these packets be of the largest size that can successfully traverse the path from the source node to the destination node. This packet size is referred to as the Path MTU (PMTU), and it is equal to the minimum link MTU of all the links in a path. IPv6 defines a standard mechanism for a node to discover the PMTU of an arbitrary path. 8. 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. K. Atwal, R. Akers [Page 11]
Internet Draft Bluetooth IP May 28, 2001 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 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. K. Atwal, R. Akers [Page 12]
Internet Draft Bluetooth IP May 28, 2001 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. RFCOMM: RS-232 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. 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. 9. 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 K. Atwal, R. Akers [Page 13]
Internet Draft Bluetooth IP May 28, 2001 10. REFERENCES [ARP:1] RFC 826, An Ethernet Address Resolution Protocol, David C. Plummer, November 1982. [HOST:1] RFC 1122, Requirements for Internet Hosts -- Communications Layers, R. Braden (Editor), October 1989. [HOST:2] RFC 1123, Requirements for Internet Hosts -- Application and Support, R. Braden (Editor),October 1989. [INTRO:1] Specification of the Bluetooth System Core Version 1.1. (http://www.bluetooth.com/developer/specification/specification.asp) [IANA:1] Protocol Numbers for the Internet Protocol. (http://www.isi.edu/in-notes/iana/assignments/protocol-numbers) [IANA:2] Port Numbers for TCP/UDP. (http://www.iana.org/assignments/port-numbers) [IANA:3] Parameters for the Address Resolution Protocol. (http://www.iana.org/assignments/arp-parameters) [IPv6:1] RFC 1884, IP Version 6 Addressing Architecture, R. Hinden and S. Deering, December 1995. [PATHMTU:1] RFC 1191, Path MTU Discovery, J. Mogul and S. Deering, October 1989. [PATHMTU:2] RFC 1981, Path MTU Discovery for IP version 6, J. McCann, S. Deering, and J. Mogul, August 1996. [ROUTER:1] RFC 1009, Requirements for Internet Gateways, R. Braden and J. Postel, June 1987. K. Atwal, R. Akers [Page 14]
Internet Draft Bluetooth IP May 28, 2001 11.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. 11.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 11.1.1 - A simple Master-Slave Bluetooth Piconet +------+ | | |Master| | | +------+ | | | | +----------+ | | +--------------------+ - - - - - -+ | | +---------+ | | | | | | | | | | V | | | | +-----+ +-----+ +-----+ +-----+ +--------+ | | | | | | | | | Parked | |Slave| |Slave| |Slave| o o o|Slave| | Slaves | | 1 | | 2 | | 3 | | 7 | | 8-255 | +-----+ +-----+ +-----+ +-----+ +--------+ Figure 11.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. K. Atwal, R. Akers [Page 15]
Internet Draft Bluetooth IP May 28, 2001 11.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 | | | | - - - - | |Slave 2| | Master | | | +---------+ +-------+ | | | +----------+ | +---------+ | | | | | | | | | +-----+ +-----+ +-----+ | | | | | | |Slave| |Slave| |Slave| | 1 | | 2 | | 3 | +-----+ +-----+ +-----+ Figure 11.2.1 - A Bluetooth Scatternet made up of two Piconets by a Routing 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. K. Atwal, R. Akers [Page 16]
Internet Draft Bluetooth IP May 28, 2001 11.2.2 Scatternet Slave IP Architecture: +-------+ +-------+ |Piconet| |Piconet| | A | | B | |Master | |Master | +-------+ +-------+ | | | | +----------+ | +---------+ +--------+ | | | | +-----+ +-----+ +-----+ | | | | | | |Slave| |Slave| |Slave| | 1A | | 2A | |3A/1B| +-----+ +-----+ +-----+ Figure 11.2.2 - A Bluetooth Scatternet made up of two Piconets by a Slave node with no Routing capability. The Bluetooth node "Slave 3A/1B" is member of the Bluetooth Piconet A. The node is also a member in the Bluetooth Piconet B. Since the node is a Slave it has no active routing capability. In this way a node can participate on two networks. 11.2.3 Scatternet Master IP Architecture: If an active routing capability were desired in Slave 3A/1B it would need to become the Scatternet Master in the above arrangement, such that: +----------+ |Scatternet| | Master | | C | +----------+ | | +----------+ +-----+ | | +---------+ +---------+ |Slave 1C | |Slave 2C | | - - - - | | - - - - | |Master A | |Master B | +---------+ +---------+ | | +----------+ | | | +-----+ +-----+ | | | | |Slave| |Slave| | 1A | | 2A | +-----+ +-----+ Figure 11.2.3 - A Bluetooth Scatternet made up of two Piconets by a Master node with Routing capability. K. Atwal, R. Akers Expires: November, 2001 [Page 17]