Scatternets and Speed
It is possible for a device to take part in two different piconets by swapping between two different frequency-hopping sequences. Figure 2 shows two different examples of scatternets. On the left, a device is a master in one piconet and a slave in another. On the right, a device is a slave to two different masters.
){kind=link}
Bluetooth scatternets.
Of course, it is not possible to be a master of two different piconets. This is because a piconet is a group of devices all synchronized on a hopping sequence set by the master. By definition, any devices that share a master must be on the same piconet.
A device that is present on two different piconets must visit each piconet often enough to keep the link supervision timeout from elapsing. If the device is a master, it must transmit to its slaves every Tpoll slots, where Tpoll is a poll interval that is negotiated between master and slave.
Receive and transmit slots are both 650 microseconds long. A pair of slots takes 1250 microseconds, so it takes just that long to transmit a single-slot packet and receive a single-slot packet. At first thought, you might imagine that a Bluetooth device that wants to visit another piconet for just long enough to transmit and receive a single packet will be missing from its current piconet for only 1250 microseconds. This would be true if all piconets were perfectly synchronized, but that's not the case: There is no mechanism to synchronize piconets, so the slot timing on any pair of piconets likely will not match. Even if the slots on two piconets did start at precisely the same time, Bluetooth clocks do not all tick at precisely the same rate, so in time they would drift apart.
Figure 3 shows what happens if a Bluetooth device is a slave on one piconet but has to visit another piconet where it is the master, perhaps to poll a slave to comply with a polling interval that it has negotiated. The start of the slot pair that our device wants on the second piconet is not synchronized with the end of the last slot pair that it is using on the first piconet, so the device must wait around for the start of its transmit slot. When it goes back to the first piconet, the lack of synchronization leaves it waiting around for a lot that it can use. The shaded slots on the diagram are useful slots; the unshaded ones cannot be used. You can see that our device lost two slot pairs on piconet 1 so that it could use one slot pair on piconet 2.
){kind=link}
Slot timing in a scatternet.
Obviously, scatternets are not the most efficient way to use Bluetooth bandwidth. The problem arises because the piconets that make up scatternets aren't synchronized. The first solution that comes to mind is just make all the piconets in an area synchronized with one another. The problem with that is that masters transmit in even slots and slaves transmit in odd slots. Thus, timing that worked for a device that is the master on one piconet and a slave on another would be wrong for a device that was a slave on two piconets. Besides, Bluetooth piconets can form and dissolve in a few seconds, so trying to decide which piconet should set the overall timing when piconets are constantly forming and dissolving would be nearly impossible!
Sometimes it doesn't matter whether a few slots are wasted moving between the different piconets that make up a scatternet. If data rates are low, a few slots lost now and then aren't at all important. When it is important, then the solution is simply to avoid using scatternets by uniting devices into one piconet. For example, LAN access points need to share their bandwidth among many slaves, so they want to be as efficient as possible. To maintain maximum efficiency, they keep all devices connected to them in just one piconet.