I have a rather interesting problem that has probably been solved before, but I'm not really sure where to look.
I am developing a system that consists of:
I am trying to develop an algorithm & implementation that:
E.g. some example topologies that should work are:
4 nodes that can all see each other
A-B
|X|
C-D
long lines that can see at most 4 neighbours
A-B-C-D-E-F-G-H-I
|
X-Y-Z
Example 1 -A & B close to each other, algorithm decides B should move towards the right
1000 2000 3000 4000
0 250 500 750 0 250 500 750 0 250 500 750 0 250 500 750 0
| | | | | | | | | | | | | | | | |
A A A A A
>> >>>>
B B B B
Time ------------------------------------------------------------------------------>
Example 2 - A & B aligned, algorithm decides C should move towards the left
1000 2000 3000 4000
0 250 500 750 0 250 500 750 0 250 500 750 0 250 500 750 0
| | | | | | | | | | | | | | | | |
A B A B A B A B A
<< <<<<
C C C C
Time ------------------------------------------------------------------------------>
The radio communications are unacknowledged/broadcast beacons, so confirmation of the RF link is impossible. However, if the nodes included in their own beacon the identifiers of their neighbours they can kind of share enough information.
e.g. In example 2 above, if A can hear B, then A's beacon could include "B is 250ms after me". Likewise, if B can hear A, then B's beacon could include "A is 750ms after me".
With this style of information this problem starts to look a lot like a network graph problem, where each node can build outwards from itself based on the nodes it can hear and the nodes they can hear in turn. I have looked into things like Spanning Tree Protocol for inspiration but haven't had much luck yet.
Although it looks like a network graph problem, the issue is really how to shift the timing of the beacons.
In essence, the algorithm answers the question "Should I move my own beacon? If yes, which direction?", but it takes into account:
Sooooo, after quite a lot of text, my questions really are:
BTW: I'm not interested in Radio/MAC layer solutions to this, it really is an application issue!
I never got around to solving this "slotting" idea. Instead our nodes just moved away from any conflicts. I.e. instead of trying to develop a solution to the slotting algorithm we just made something that would attempt to space equally but that could result in oscillations.
I suggest that you break this up into two distributed algorithms that you can find written up.
1) Distributed clock synchronization. Have all nodes agree on a common time base, using algorithms such as those used by NTP. At this point, and maybe for some time, there may not be a common agreement in time to separate different transmissions, but you can use http://en.wikipedia.org/wiki/ALOHAnet#The_ALOHA_protocol while this is a problem.
2) Distributed graph colouring. One starting point is http://en.wikipedia.org/wiki/Graph_coloring#Parallel_and_distributed_algorithms. I don't even recognise the algorithms named there, but it at least looks like there is work you can refer to. Under "Decentralized algorithms" they also reference applications to Wireless Channel Allocation, so some of this might be quite close to what you want.