Direct Communication Among Slaves: Questions/Views
Original Post: No Direct Communication Among Slaves (?) (eGroups Msg. 88)
Date: Wed Nov 17, 1999
This question arises a number of times. One view supports it but 2 are
against. I believe the latter is the case (at least in the lower layers).
For:
But have you read the Synchronization profile of Bluetooth Spec? You will see
a phrase saying: "extended works, schemes, spec.. etc.. are left for the
inventory of the vendors".
Therefore, a slave-master-slave communication can be done through the higher
level "Application layer" where such routing query from slave [1] can
be accompanied in the data payload of the Bluetooth MSG and the master of the
piconet will deliver it to slave [2] accordingly.
Against(1):
There is no way for a slave to inform the master about to which slave it
wants to communicate. In the Spec, you don't find any specific way to do this.
The only way for a slave to communicate with another slave is to create a new
piconet with the former as the master and the latter as the slave. That means
the first slave pages the second slave.
Against(2):
All of the communications between the slaves in a piconet must go through the
master of that piconet only. In other words, the master will route the necessary
data among it's slaves.
Extra View/Question:
A sample Question/answer submitted which i believe is incorrect. See below
Submitted:
There is one point to arise: You might ask: what if an active slave in a
piconet [A] becomes a master for other piconet [B] while he is still a slave at
piconet [A], i.e. a scatternet
The question: Is it possible for that slave to become a master to one active
slave in piconet [A] or even just to communicate with it directly? The answer is
still NO. Why? That slave can't become a master for any other active slaves
neither to communicate with a slave from other piconet directly. Again, the
whole process should be done through the desired slaves' master.
My Observation:
A slave unit in a piconet[A] can inquiry all devices in area,
including another slave which is part of piconet[A]. These devices could reply
and a new piconet could be setup. there is nothing in the specification which
forbids this, as the new piconet would have a totally different hopping sequence
to the existing hopping sequence[A].
This view was subsequently confirmed in the post: intra-piconet issues (SIG
Forum) Date:2000-07-13
|
