I think in this tread we have some confusion amongst some of us.
Let me explain.
In fact, we have different timings happening on radio network to what is our objective:
1. Ordinary time. Useful for log registers and schedulers, scripts etc. As long as there is a clock in a device it is nice it would reflect the time we see on our watch!
Special in troubleshooting its handy that you can compare different units on a time base to see what happened. Accuracy needed is seconds....
2. Send/Receive timing in ordinary 802.11 networks. The RTS/CTS protocol. A very rudimentary timing sync for nodes in a network. The nodes have to negotiate amongst each other whose turn it is to speak/listen. No real time needed, not a real timing sync.
3. Send/Receive timing in TDM (tdma or airmax or nv2 etc.) networks. Here an AP sets a send/receive schedule for itself and each connected node. This way the 'hidden node' issue is avoided and better use of the spectrum capacity can be made by separating each node's sending or receiving from the others. "One after the other gets his turn". It becomes important that nodes in a network become synchronized but the (proprietarily) protocol guarantees such. We have a master-slave network where the master depicts when and how long the client can send or receive, each at its assigned time.
4. Send/Receive timing in multi AP networks where frequency or interference avoidance is needed. By having all radio's on a tower that work in the same frequency band sending and receiving at the same time we reduce (up to elimination) interference between radio's in the same tower. Off course we need some master clock that now has to be connected to each of the other units to give a 'zero' ("Z") time signal and the difference to it very precisely. Even after long time all connected units must still run in the same sync. Hence the update of "Z" that can happen at an almost continuously basis.
It now becomes possible on a same tower to use several radios working on the same frequency but in different direction to serve different distant nodes. We need less spectrum and the overall quality of the network (clearer signal) also goes up! Win-win...? No;
There is one side effect; In tdma networks we have several options;
a. Variable, but fixed, time slots. Depending on the latency versus throughput and distance of node we have to set a certain length of the time slots. So they can be different for different AP/BH radio's.
b. Variable adapted times slots. If have seen some examples of technologies where the time slot actually can get change upon need of the network.
If we want a tower to be fully sync, all radio's need to adept to the same scheme. And since the radio that for whatever reason needs the longest time slot it predicts the sync for all others The overall outcome might be that for some PtMP networks (or PtP) the latency goes up (a bit...)
5. Send/Receive timing in multi AP/multi tower networks. For same reasons as 4. we might want to sync even between towers. If all AP's in a region would transmit at the same time clients that receive signals from different AP's will benefit.
This will have a new complication. If these towers are interconnected with radio backhauls in the same radio band and taking part in one of the tower’s sync it automatically will be in counter sync on the other tower.
To solve this, we can start working with ABAB sync over radio backhaul towers but if all these towers have AP's and in between them are clients that can 'hare' two or more the risk is now a client becomes in full counter-sync with some other AP network. If clients are now in close proximity but one connects to tower 'A' and the other to 'B' they could start interfering with each other, special if the frequencies are the same or close.
To arrange such a network properly becomes a complicated task.
1. a simple clock will do, each unit on its own a time stamp from the NTP protocol is sufficient.
2. no clock is needed. Abait that the radio itself creates some time related energy pulses (the frequency) nothing more is needed.
3. A precise clock is needed to sustain a coherent time slot with a protocol that guarantees all nodes are in sync with the master (AP). Since each clock can vary in speed each node also needs to be continuously updated by the master. The tda protocol takes care of that. This could also be done by GPS or the 1588 protocol but since actual time is not needed, only sync, the tda is good enough and doesn't need any further hardware. (I don't know if the 1588v2 is better or worse than tda but since most vendors are still developing or using any form of tda I presume it’s a winner...)
4. To sync between different hardware devices there need to be some interconnectivity between units on the tower with one master. This master not only needs to set a "z" hour time stamp to each unit, it also needs to update it continuously to guarantee all units stay in sync. At the same time, it also needs to override each radio's own tda settings. Since all tda's timeslots on all radio's need to have the same length and therefore start/stop this very important.
To transport the sync, signal a protocol like 1588v2 can be used or any other proprietary. The master is best equipped with a very precise clock and since usually only one master is needed, and a radio that sits on a tower usually also 'sees' several satellites a GPS sync'd clock seems to be the best way to go. (And most vendors do so... Other earlier mentioned GPS 'issues' are virtually of no importance.)
5. If we now also need to sync between towers we have to guarantee the time stamps and hour "Z" are the same on both. We can do that with the 1588v2 protocol but if the towers are only interconnected by radio backhauls it might be more reliable to only transport the start cycle and the tda scheme to be used to send over the radio where the actually timing than is done by a GPS updated clock that guarantees that the time cycles between towers are of the same length.
(GPS is now probably more reliable than 1588v2 because the radio link can be interfered o hammered by all kinds of issues that if towers would be dependent on this sync only would make a mess a soon as packages get distorted, corrupted or delayed. The change two GPS clock in relative close proximity are going to run out of sync of each other is very, very small...)
Bottom line is; Sync within a tower, or between towers, is a spectrum saver and will also benefit the overall quality of the network but isn't the holy grail on itself. Imho several technologies are needed in combination to fight nowadays challenges to make and keep a good network running. That GPS is a tool of choice to sync AP’s and towers can be seen by the many vendors that are using it or are preparing their hardware to do so.