When will Mikrotik build a feature to sync aps?

Like Ubiquiti you mean?

I would like to have 3 APs on a tower that can share the same frequency without interference. Like time slotting.

This would be really neat so I can use 3.65ghz sectors on 20mhz channels instead of 5mhz channels. I use 5mhz so I dont interfere with the other sector 20 ft away. We can only use 25mhz total so this feature would be a blessing.

Explain me in few sentences how it might work?


AP would need a GPS to get correct time for synchronization, and a protocol beetween each other to talk to and arrange time slots when they have to be silent.

How would you resolve issue with time drift ?

Its hard to imageine - set exact time on diffrent boards and keep it sychronized.

Where ist the problem? GPS chips are very cheap. You can ignore the drifting problem if you put an gps receiver at every AP and sync the clock in a short period.
This is the cheap way of two available ways to keep the wireless business a little bit longer alive. Without AP Sync your not able to increase the summary bandwidth on wireless POP's. As everybody here whe have problems with interfering APs at the towers even if they are 40 MHz far away.

I don't know what has happend with MT but from my point of view I see not much innovative things from them one year. O.k. again and again routerboard in many variants but this are not the things we can really use.

- MPLS was a nice try but the development seems to have stopped.
- No "ready-to-setup-for-customer" CPE like Ubiquity
- No SFP slots to use MT for a superior fibre-router.
- A good concept for a NMS (the dude) - I can't see any constant development here. Instead of offer it for free it would
be better to sell it and push the development

NV is a light at the end of the tunnel but without AP sync most of the WISP will run into future bandwidth problem.

As everybody here whe have problems with interfering APs at the towers even if they are 40 MHz far away.

This is the problem to solve first. It doesnt help to increase complexity with sync when basic
wireless behavior is low quality. With good engineered Wireless Cards/Drivers we would not see this
much interference issues we see.

@ste

How long must we wait before a company like MT or Ubiquity will build their (really ) own wireless card? Fibre connections are pentrating the market here and we will not build our own fibre network with the high risk to loose our money in cause of a cross-subsidized telecom company who is gotting crazy.

I need a solution in an planable, aceptable time line!!! for this people only looking for the access-prices. One the one side to fix the customers we already have and on the other side to get new ones ...

For about 1 and 1/2 year I discussed the AP Syncfeature here and at the Ubiquity forum. The company who did it was ...

MT should hear more for the whishes of their users or they should make a statement "We don't see a future market in the industry nations". Then I know where am I!

@ste

How long must we wait before a company like MT or Ubiquity will build their (really ) own wireless card? Fibre connections are pentrating the market here and we will not build our own fibre network with the high risk to loose our money in cause of a cross-subsidized telecom company who is gotting crazy.

I need a solution in an planable, aceptable time line!!! for this people only looking for the access-prices. One the one side to fix the customers we already have and on the other side to get new ones ...

For about 1 and 1/2 year I discussed the AP Syncfeature here and at the Ubiquity forum. The company who did it was ...

MT should hear more for the whishes of their users or they should make a statement "We don't see a future market in the industry nations". Then I know where am I!

They do not need to build their own card but need to cooperate with a manufacturer like Atheros in a
way that there will be a better product in terms of wireless behavior.
But I am not sure that MTs core competence is in that area. Reading documentation and following
discussions I do not feel that there is a deep understanding of wireless physics (I'm no expert in this
field either). It feels like they get cards from atheros, poke in some parameters and hope the best.
Wasnt the hardware-retry knob there for some time until it really gets used in 4.x. Looked like they
poked it into the wrong hardware register and did not even notice that this knob was not working.

We are looking/testing some wimax gear in the near future as it seems prices went down into a
reasonable range. This gear is double the price for the outdoor cpe and 8 times the price per sector
but it promises a much better behavior in terms of frequency efficiency and behavior under load/difficult
conditions (with GPS-sync).

Wisp market is getting more professional. Vendors which do not follow this way ...

As everybody here whe have problems with interfering APs at the towers even if they are 40 MHz far away.

This is the problem to solve first. It doesnt help to increase complexity with sync when basic
wireless behavior is low quality. With good engineered Wireless Cards/Drivers we would not see this
much interference issues we see.

Do you have a spectrum analyzer? I can fix that problem right now. Call me and I can teach you how and why. If you just want an answer. Move your aps aparts at minimum 10 ft. If the antennas are right next to each other. If two aps at 20mhz right next to each other. They are really 40mhz each or more. Thats how frequencies work within 10ft. Want proof. Buy spectrum analyzer. Glad I could help.

The goal is to use at much spectrum as possible without wasting it. That is a big problem with wireless cards. If you have 3 sectors. They each have a channel. If they are not speaking, they are wasting. Sync would give us full use of the whole spectrum on one channel.

As everybody here whe have problems with interfering APs at the towers even if they are 40 MHz far away.

This is the problem to solve first. It doesnt help to increase complexity with sync when basic
wireless behavior is low quality. With good engineered Wireless Cards/Drivers we would not see this
much interference issues we see.

Do you have a spectrum analyzer? I can fix that problem right now. Call me and I can teach you how and why. If you just want an answer. Move your aps aparts at minimum 10 ft. If the antennas are right next to each other. If two aps at 20mhz right next to each other. They are really 40mhz each or more. Thats how frequencies work within 10ft. Want proof. Buy spectrum analyzer. Glad I could help.

The goal is to use at much spectrum as possible without wasting it. That is a big problem with wireless cards. If you have 3 sectors. They each have a channel. If they are not speaking, they are wasting. Sync would give us full use of the whole spectrum on one channel.

I've just the poor mans Analyser (wispy dbx). I understand that distance matters. But I see equipment which can
live on the same tower with just minimal frequency and physical spacing and I see equipment which has problems
even with big frequency and physical spacing. This has to do with quality of components (E.g. look at this plastic
UBNT stuff). You can throw 1000 features like sync on low quality equipment and your result will be far from optimum
What I want to say is: Increasing quality is prior to throw new features in the game. Doing this new features with
same low quality will not make a good product. Of course I want to have sync, too.

GPS sync will make it so only 1 wireless card talks at once. So you can have the equipment right next to each other without interference. It will solve your issue.

I would like to have 3 APs on a tower that can share the same frequency without interference. Like time slotting.

This is no practical solution. You get a lot of latency. You need 6 slots. One for each AP and one
for the group of clients of each AP.
I know synced equipment which works with 4 Sectors and 2 Frequencies. So you have one slot for AP and
one for clients. As same frequency is used back to back you minimize interference.

Cant we change the time slot size for this? As long as there is not interference we should only have little more latency than normal. But the benefit of using a full 20-40mhz channels is worth it.

Nv2-cell-radius - specifies distance to farthest client in Nv2 network in km. This setting affects the size of contention time slot that AP allocates for clients to initiate connection and also size of time slots used for estimating distance to client. If this setting is too small, clients that are farther away may have trouble connecting and/or disconnect with "ranging timeout" error. Although during normal operation the effect of this setting should be negligible, in order to maintain maximum performance, it is advised to not increase this setting if not necessary, so AP is not reserving time that is actually never used, but instead allocates it for actual data transfer.

@ste: You don't have to have a slot per ap. All APs are sending at the same time.

When we talking about "plastic stuff": As ste said: The business is getting professional. In most countries time for handycraft work is over (yes we have an 18GHz spectrum analyzer but I don't and I can't have a handtuned wireless central tower). At the same time the bandwidth demand is raising combined with the will to pay less as possible. Returning to the issue "plastic stuff": We need a soluting where the CPE is very cheap and customer friendly (self setup). And if we could work with ap sync and a very cheap basestation we have a limited time to stay at the market. If the plastic stuff has the technology to prevent interferences why should spend time and money (for solid stuff) to reduce but not to solve the problem:

I wan't AP sync too.

@ste: You don't have to have a slot per ap. All APs are sending at the same time.

Then you get problems with cpe's which are on the border of 2 sectors. They receive
signal of 2 APs at nearly the same signal level.

When we talking about "plastic stuff": As ste said: The business is getting professional. In most countries time for handycraft work is over (yes we have an 18GHz spectrum analyzer but I don't and I can't have a handtuned wireless central tower). At the same time the bandwidth demand is raising combined with the will to pay less as possible. Returning to the issue "plastic stuff": We need a soluting where the CPE is very cheap and customer friendly (self setup). And if we could work with ap sync and a very cheap basestation we have a limited time to stay at the market. If the plastic stuff has the technology to prevent interferences why should spend time and money (for solid stuff) to reduce but not to solve the problem:

I wan't AP sync too.

May be it's possible and necessary to live with "plastic stuff" for CPEs. But your service will suffer
from "plastic stuff" at the AP-Side.
Some of this gear is made for low density usage. And there you can live with poor separation and
plastic. So it's a good business decision to use cheap gear there. But some vendors claim 300+ Subs
per Tower. Try it and you get 300+ phone calls per day.

But of course MT shouldn't be behind these plastic stuff guys in terms of wireless or they find
themselves selling only indoor equipment.

@ste: Shure. I will spend more money for a professional AP. I want to have more monitoring, more shielding and a really good lightning protection (my nightmare).

@ste: You don't have to have a slot per ap. All APs are sending at the same time.

Then you get problems with cpe's which are on the border of 2 sectors. They receive
signal of 2 APs at nearly the same signal level.

The main problem is at the ap side. There are ways to avoid 2 customer next to each other that are on different aps. like

1. make sure the antennas cant see each other.
2. use rts/cts so they take turns(which doesnt effect whole ap
3. polling etc...

The aps are closer so they just wont work. So the aps need to have slots. Right. I am open for discussion.

@ste: You don't have to have a slot per ap. All APs are sending at the same time.

Then you get problems with cpe's which are on the border of 2 sectors. They receive
signal of 2 APs at nearly the same signal level.

The main problem is at the ap side. There are ways to avoid 2 customer next to each other that are on different aps. like

1. make sure the antennas cant see each other.
2. use rts/cts so they take turns(which doesnt effect whole ap
3. polling etc...

The aps are closer so they just wont work. So the aps need to have slots. Right. I am open for discussion.

1. But both cpes will see both sectors. With sync they will not disturb the ap while
he is sending but both cpes will get signal from both sectors at the same time as they
are synced.

2./3. helps only for cpes registered with the same sector

Why use GPS for AP sync? Isn't enough to have some sort of IP connection between AP-s to do this?

Why use GPS for AP sync? Isn't enough to have some sort of IP connection between AP-s to do this?

You get some benefit syncing APs on nearby towers.

Why use GPS for AP sync? Isn't enough to have some sort of IP connection between AP-s to do this?

The one reason i want it is so I can use more of my spectrum without wasting it.
Also to remove self interference.
Have other sectors with the same channel(no matter how close they are)

For those that haven't seen the gps sync for Ubiquiti. All manufactures should probably support similar the or the same since. But anyways here if some data for you guys if you haven't all ready seen it. This is what we need for Mikrotik. Please help Mikrotik.

) How does Airsync protocol work ?’
The airsync protocol requires Layer-2 connectivity between the participating APs.
In each sync-cluster: one of the APs is designated as the Master and the others as the slave.
A L2 bridged network can have as many sync-clusters as desired.
The Master and the slaves exchange synchronization information over Layer-2.
Once synchronized the airmax TDMA transmit and receive slots of all APs are lined up. Hence all APs shall transmit at the same time and receive at the same time.
2) Can remote towers be synchronized ?
Yes as long as the latency of communication between the towers is less than 30 ms.
One needs to avoid situations where the stations connected to the towers can *hear* more than one tower or where the towers can *hear* each other’s stations.
When using different frequencies, the frequency rejection on the radio will help shave off 10-40 dB depending upon the MHz difference, relaxing the requirement.
e.g. If one STA hears its own AP at -60 dBm and hears the other synchronized APs at -80 dBm, it would only have a 20 dB Signal to Interference Ratio. Higher rates (MCS6/14, MCS 7/15) will not be possible in this case.
If the APs were 20 MHz apart, the adjacent channel rejection factor of 10 dB can be added giving a 30 dB Signal to Interference Ratio. This would make MCS6/7 or 14/15 possible on the link.
Increasing the separation in MHz will improve the ratio.
So it will all depend on the Signal to Interference Ratios.
3) Can I deploy just one Rocket GPS, and have my other Rockets synchronize with it ?
No, each airsync participant needs its own GPS input. The reason here is that a Layer-2 connection does not provide predictable latency for communicating timing information (at the resolution that we need).
4) Can I re-use the same frequency for all APs ?
Yes the same frequency can be re-used as long as the situation described in (2) is avoided. Realistically this would only work for back-to-back deployments.
5) Do the APs share the medium capacity once synchronized ?
No, as long as the situation described in (2) is avoided, each airsync participant gets the *full medium capacity* and is not affected by traffic patterns of its peers.
The exact throughput in Mbps achieved by each airsync participant will depend on individual link quality.
Hence adding more APs shall increase network capacity.
6) I would like to synchronize APs on a tower, but do not want to bridge them. Can this work ?
Yes. One can configure the airsync protocol to use a specified VLAN. Hence only the specified VLAN needs to be bridged.
7) Can I configure the Down/Up timing ratio ?
Yes. The timing ratio can be configured at the ‘Master’ and shall be used by all the slaves.
If I need to use different frequencies to mitigate the problem described in (2) above, why do I need GPS sync ?
As discussed in (2), increasing the frequency separation, increases the SIR.
e.g. at 60 MHz separation the rejection is about 50 dB. Since the APs are co-located the would hear each other at 27-50=-23 dBm.
If the signal strength to one of the clients was -60 dBm, the SIR in this case is -37 dB (negative). This would prevent the AP from decoding even a MCS0 signal (as it needs a SIR of about +6 dB) from the station if any one of the other APs transmit.
Hence the need for synchronization.
9) Do I need GPS on CPEs ?
No, Airsync is AP side functionality. To synchronize an AirMax network, only a hardware upgrade on the AP side is required (RocketMGPS). No station side hardware upgrade is needed.
For any application/deployment specific questions please feel free to email me at sriram@ubnt.com

Here are 3 methods of doing these syncing.

1.2 Wireless Network Synchronization

The definition of time synchronization does not necessarily mean that all clocks are perfectly matched across the network. This would be the strictest form of synchronization as well as the most difficult to implement. Precise clock synchronization is not always essential, so protocols from lenient to strict are available to meet one's needs.

There are three basic types of synchronization methods for wireless networks. The first is relative timing and is the simplest. It relies on the ordering of messages and events. The basic idea is to be able to determine if event 1 occurred before event 2. Comparing the local clocks to determine the order is all that is needed. Clock synchronization is not important.

The next method is relative timing in which the network clocks are independent of each other and the nodes keep track of drift and offset. Usually a node keeps information about its drift and offset in correspondence to neighboring nodes. The nodes have the ability to synchronize their local time with another nodes local time at any instant. Most synchronization protocols use this method.

The last method is global synchronization where there is a constant global timescale throughout the network. This is obviously the most complex and the toughest to implement. Very few synchronizing algorithms use this method particularly because this type of synchronization usually is not necessary.



Figure 1 - Breakdown of packet delay components

As shown in figure 1, all the wireless synchronization schemes have four basic packet delay components: send time, access time, propagation time, and receive time. The send time is that of the sender constructing the time message to transmit on the network. The access time is that of the MAC layer delay in accessing the network. This could be waiting to transmit in a TDMA protocol. The time for the bits to by physically transmitted on the medium is considered the propagation time. Finally, the receive time is the receiving node processing the message and transferring it to the host. The major problem of time synchronization is not only that this packet delay exists, but also being able to predict the time spent on each can be difficult. Eliminating any of these will greatly increase the performance of the synchronization technique.

As illustrated there are many different variations of time synchronization or wireless networks. They range from very complex and difficult to implement to simpler and easy to implement. No matter the scheme used, all synchronization methods have the four basic components: send time, access time, propagation time, and receive time.

There are many synchronization protocols, many of which do not differ much from each other. As with any protocol, the basic idea is always there, but improving on the disadvantages is a constant evolution. Three protocols will be discussed at length: Reference Broadcast Synchronization (RBS), Timing-sync Protocol for Sensor Networks (TPSN), and Flooding Time Synchronization Protocol (FTSP). These three protocols are the major timing protocols currently in use for wireless networks. There are other synchronization protocols, but these three represent a good illustration of the different types of protocols. These three cover sender to receiver synchronization as well as receiver to receiver. Also, they cover single hop and multi hop synchronization schemes.

I wonder which method mikrotik is going to do. Would ntp clock timeing mixing with wireless syncing be adequate? That would save money. ntp or gps. They are both timing. Is one faster than the other? Or better? If someone answers this question. Remember the costs behind this method.

I see that almost every poster on this thread thinks of something else when they talk about gps sync I still don't understand what you want to be implemented.

"only 1 wireless card talks at once", "All APs are sending at the same time. ", " share the same frequency without interference", "which works with 4 Sectors and 2 Frequencies", "have some sort of IP connection between AP-s to do this", "requires Layer-2 connectivity between the participating APs"

I see that almost every poster on this thread thinks of something else when they talk about gps sync I still don't understand what you want to be implemented.

"only 1 wireless card talks at once", "All APs are sending at the same time. ", " share the same frequency without interference", "which works with 4 Sectors and 2 Frequencies", "have some sort of IP connection between AP-s to do this", "requires Layer-2 connectivity between the participating APs"

The goal is: Maximize sector thruput and minimize problems arising from interference.

As wisp with multiple towers with overlapping segments some sort of
global (gps) sync may help.

Nevertheless the implementation is complicated and may lead to some additional
problems. As your implementation depends on Atheros you are bound to their
technical restrictions.

May be implementing this features is to far away from the standard 802.11 path
which keeps things cheap. Lets see if UBNT implements a *proven* sync feature.

I see moto-wimax users did not profit from sync as much as the feature promised
they switched to ABCD sector scheme as ABAB did not workout with sync.

As vacation gives me some time to read a background wimax book I can extend
the wishlist far beyond sync features. So e.g. PUSC is a great feature addressing the
same problems. But this even more leaves the path of 802.11.

I would appreciate MT to talk with sequans or beecem to open up the door for
a bunch of new features.

I see that almost every poster on this thread thinks of something else when they talk about gps sync I still don't understand what you want to be implemented.

"only 1 wireless card talks at once", "All APs are sending at the same time. ", " share the same frequency without interference", "which works with 4 Sectors and 2 Frequencies", "have some sort of IP connection between AP-s to do this", "requires Layer-2 connectivity between the participating APs"

Hello Normis,

I posted the big (questions and answer) resently about the gps sync that Airmax (ubiquiti) deployed. I think that is a good system. There is other types of Wireless gps sync systems. Everyone needs to use the same sync system in order to work well. The first wireless sync system was each ap takes turns. I think Mikrotik should build the sytem just like Ubiquiti. Which is all aps will speak at same time. Does this answer your question?

I see that almost every poster on this thread thinks of something else when they talk about gps sync I still don't understand what you want to be implemented.

"only 1 wireless card talks at once", "All APs are sending at the same time. ", " share the same frequency without interference", "which works with 4 Sectors and 2 Frequencies", "have some sort of IP connection between AP-s to do this", "requires Layer-2 connectivity between the participating APs"

The goal is: Maximize sector thruput and minimize problems arising from interference.

As wisp with multiple towers with overlapping segments some sort of
global (gps) sync may help.

Nevertheless the implementation is complicated and may lead to some additional
problems. As your implementation depends on Atheros you are bound to their
technical restrictions.

May be implementing this features is to far away from the standard 802.11 path
which keeps things cheap. Lets see if UBNT implements a *proven* sync feature.

I see moto-wimax users did not profit from sync as much as the feature promised
they switched to ABCD sector scheme as ABAB did not workout with sync.

As vacation gives me some time to read a background wimax book I can extend
the wishlist far beyond sync features. So e.g. PUSC is a great feature addressing the
same problems. But this even more leaves the path of 802.11.

I would appreciate MT to talk with sequans or beecem to open up the door for
a bunch of new features.

I think Mikrotik should make the NV2 protocol to support a GPS wireless sync. If Mikrotik setup the GPS sync. They will test it in the test lab. Using to aps right next to each other. If it works there with a -19 signal seeing each other. If they can pull lots of bandwidth from each ap and see the sync is working. I think that would be a good test right before production users use it. I will support testing this feature in production for Mikrotik. This will stop self interference which is the #1 problem with WISP. Most of the WISP dont even know they have this issue. I have have proven this over and over to other wisps about this problem. This fixes the invisable problem(To most users). I dont want to get off this subject too much. Anyways. I support the Airmax Ubquiti GPS sync design.

1. Question: Couldn't we use ntp clocking for syncing the wireless cards. Why do we need to bring too much costs in the matter with GPS systems. We are only using the (TIMING) of that feature.
2. It would be cool if one of the sectors is the master and it set the timing for the slaves for the syncing.

i dont understand why it even matters what time source you use, as long as everyone is on the same one. if you get 30 people in a room shouting at once its really noisy, and then tell each one to take turns, one right after the other, then its nice and peaceful - why can't mikrotik just listen to the other radios and adjust themselves without gps? the clients already do this, why cant aps?

Yeah kinda what I said about master and slave.

i dont understand why it even matters what time source you use, as long as everyone is on the same one. if you get 30 people in a room shouting at once its really noisy, and then tell each one to take turns, one right after the other, then its nice and peaceful - why can't mikrotik just listen to the other radios and adjust themselves without gps? the clients already do this, why cant aps?

how do you think Nv2 works? It's the same thing, only without GPS.
http://en.wikipedia.org/wiki/Time_divis ... ple_access

i dont understand why it even matters what time source you use, as long as everyone is on the same one. if you get 30 people in a room shouting at once its really noisy, and then tell each one to take turns, one right after the other, then its nice and peaceful - why can't mikrotik just listen to the other radios and adjust themselves without gps? the clients already do this, why cant aps?

how do you think Nv2 works? It's the same thing, only without GPS.
http://en.wikipedia.org/wiki/Time_divis ... ple_access

Normis, does TMDA allow several aps next to each other to share the same frequency without interference? I know TMDA does this for stations but does it help for access point to access point using the same frequency? If so, Each ap is added to the time slot?

I am not really sure that end users care how you do it as long as it works, after all you guys are the experts developing the software. I am pretty sure you guys understand why it is needed and if you don't then we have an issue because there aren't many wireless providers out here that aren't having both network capacity and interference issues "both self and from others". The only way to increase capacity at this point in time with 2.4Ghz is to pack more AP's in the same amount of spectrum hence the need to synchronize the AP's with each other so they can coexist on same/overlapping channels without causing interference with each other.

I see that almost every poster on this thread thinks of something else when they talk about gps sync I still don't understand what you want to be implemented.

"only 1 wireless card talks at once", "All APs are sending at the same time. ", " share the same frequency without interference", "which works with 4 Sectors and 2 Frequencies", "have some sort of IP connection between AP-s to do this", "requires Layer-2 connectivity between the participating APs"

i dont understand why it even matters what time source you use, as long as everyone is on the same one. if you get 30 people in a room shouting at once its really noisy, and then tell each one to take turns, one right after the other, then its nice and peaceful - why can't mikrotik just listen to the other radios and adjust themselves without gps? the clients already do this, why cant aps?

how do you think Nv2 works? It's the same thing, only without GPS.
http://en.wikipedia.org/wiki/Time_divis ... ple_access

Normis, does TMDA allow several aps next to each other to share the same frequency without interference? I know TMDA does this for stations but does it help for access point to access point using the same frequency? If so, Each ap is added to the time slot?

No it doesn't at all.

Ok so mikrotik needs to implement wireless sync with some timing feature as discussed. This feature should be implemented in nv2. Normis can mikrotik develop this feature?

I am not really sure that end users care how you do it as long as it works, after all you guys are the experts developing the software

We would love to, but I don't understand what you want exactly. There seem to be many things called "wireless sync". I simply wanted some clarification to understand which things do you find the most important. Is it really only in the name of it ?

Sync aps so they can use same or not use the same channel to remove self interference. This will also let wisp use the spectrum more effeciantly if we can use the same channel. Sometimes we have a sector that has a frequency but its not currently being used. So another ap can use the frequency. This is what I mean by more effeciantly. If you make all aps transmit at same time and receive at same time in sync. That's what we want. This will remove intereference. That's is the main feature I would see many wisp benefiting from it. Also use a timing source or ntp or self set timing like master and slave for the local sectors. Thanks in advance.

Hi Normis,

As a fairly large WISP with 8 years experience I can answer your question pretty well I think. I'll try.

Sync is a little trick that greatly increases bandwidth re-utilization. I'll give a simplified scenario.

Imagine a tower with 4 90 degree sectors on it, pointing North, S, E, W.

To do this now with MT requires 4 channels. With sync you can do it with 2 channels, and actually get better results. Let's focus on the North and South sectors to explain how. All numbers are examples only.

You link the sectors to a common time source, then you have them broadcast for 10ms then listen for 2ms *at the same time*. So when North is broadcasting, so is South. Then they both fall silent at the same time and listen. Notice that when they are listening for their clients, the other AP is silent, so there is no interference from the other AP even though it is on the same channel. For this to work, you need decent quality sectors that can't "see" each other's clients. If you have sectors with 27db back end rejection. Consider a client on the South sector with a -65 signal. The North sector will see that customer with a -92 signal - so it does not interfere with the North sector even though it is on the same channel. This is probably why UB created their own antenna line.

Now you come back with a second channel for East and West and do the same thing, and you have now doubled the spectrum available. But remember that I said this is a simplified example. In the real world there are more complex antenna configurations that can triple or more your bandwidth utilization.

Why is this important? In a word: streaming video. Streaming video DRAMATICALLY increases the bandwidth consumption averages per customer. This simply can't be accomplished without more spectrum or more efficient use of existing spectrum. Probably both. I don't see how any WISP that is not using sync will still be alive in 2 years thanks to streaming video. So MT will have to make this switch to survive in the Wisp market too. Your customers will have no choice but to switch or die. Either way you lose them if you don't have sync.

The next thing to consider is how sync is accomplished. Syncing a tower is great, but for a WISP like me with many towers, I also need to sync between towers, and ideally even my competitors and I need to be able to sync. This greatly reduces noise levels throughout the entire service area, which again improves customer performance and keeps a WISP viable in an age when bandwidth demands are going through the roof. This requires GPS sync. This is why, as another poster said, you need to make your sync compatable with whatever UB does. Or possibly Canopy, but I don't see Canopy WISPS as being your main customer base.

I REALLY hope you don't force me to switch. I've got at least 1000 MT clients in the field. But switch I must if MT does not have this feature in 6 mo or so.

If you would like more info feel free to contact me by email: c-o=r-k=y A p-v=c-0= . n-e=t

I am in the same situation as corky. I agree with corkey. Hey corkey, if we get NV2 sync at a tower. We dont need tower to tower sync right? Because we would have saved more frequencies. So each tower location would have a different frequency. Lets think small so mikrotik can get at least the NV2 sync started. That alone is a huge start. This feature on NV2 is going to make a huge difference in my network.

you could accomplish that without gps, if you dont care about remote towers correct? The North and South sectors can hear each other loud and clear, so those 2 (or 5 on the same tower) can all get their timing straight and broadcast at the same time (without an actual gps clock). AP/Client already does this in TDMA - the extra step would be AP / AP broadcast time slots. Some people need even the next step and thats to use GPS so they can synchronize towers that are farther apart. Correct guys ?

Thats exactly right. I need ap/ap real bad so I dont want to give mikrotik to much to do right now. I say hold off on gps timing and have master and slave timing for the timing source of that one tower.

Thats exactly right. I need ap/ap real bad so I dont want to give mikrotik to much to do right now. I say hold off on gps timing and have master and slave timing for the timing source of that one tower.

You really need to have the ability to sync remote towers also. If not you are only bandaiding the situation, If you had no other wisps in the area raising the noise floor then you may be able to get a way without tower to tower sync. But where I am at to make the best use of the spectrum we have I need to be able to use the cleanest channel I can find on as many towers as possible.

Thats exactly right. I need ap/ap real bad so I dont want to give mikrotik to much to do right now. I say hold off on gps timing and have master and slave timing for the timing source of that one tower.

You really need to have the ability to sync remote towers also. If not you are only bandaiding the situation, If you had no other wisps in the area raising the noise floor then you may be able to get a way without tower to tower sync. But where I am at to make the best use of the spectrum we have I need to be able to use the cleanest channel I can find on as many towers as possible.

Yes I agree. I was just saying that mikrotik didnt have a build all of it at once. One step at a time. They havent built sync before so I thought it would be easier for them.

Sync between APs on a tower is more important than sync between towers.

I'm thinking though that doing it with GPS may not be any harder. In fact it may be easier.

With Moto, you have to cable between the APs to give them all a sync. MT would have to engineer that somehow. If they are going to have to engineer something anyway, it may be just as easy to go ahead and use GPS as the sync source.

Units like this are available off the shelf and communicate over USB.
http://www.amazon.com/Garmin-18x-USB-Na ... 785&sr=8-1
It's affordable, weather proof, and the software interface is already worked out. See here:
http://www8.garmin.com/manuals/425_Tech ... cation.pdf

MT could just automatically align to even second boundaries and presto -- all the APs are in sync w/o need of any new hardware at all. All APs on this and all towers would be in sync.

This limits the problem for MT to a pure SW solution. Of course we would have to change our APs to use routerboards that have USB, but that is a small price to pay.

Sync between APs on a tower is more important than sync between towers.

I would disagree, Most wisps even if they are on different channel. They still self interfere on same tower. I know this because I got a spectrum analyzer. The customers connecting to Tower A will have a great signal then the signal coming from the remote tower. Thus you will have a greater margin. Your customers will work good. However I do agree we need gps sink for remote tower syncing. And yes we should have that feature.

I'm thinking though that doing it with GPS may not be any harder. In fact it may be easier.

With Moto, you have to cable between the APs to give them all a sync. MT would have to engineer that somehow. If they are going to have to engineer something anyway, it may be just as easy to go ahead and use GPS as the sync source.

Units like this are available off the shelf and communicate over USB.
http://www.amazon.com/Garmin-18x-USB-Na ... 785&sr=8-1
It's affordable, weather proof, and the software interface is already worked out. See here:
http://www8.garmin.com/manuals/425_Tech ... cation.pdf

MT could just automatically align to even second boundaries and presto -- all the APs are in sync w/o need of any new hardware at all. All APs on this and all towers would be in sync.

This limits the problem for MT to a pure SW solution. Of course we would have to change our APs to use routerboards that have USB, but that is a small price to pay.

Thanks for your opinion corky. Thanks for your support.

Are we able to use gps over serial? The cost will be huge for me if I have a invest in to usb gps's. I have serial ports.

Mikrotik could we pay you to get this done sooner? Would anyone else be willing to put money down? If Mikrotik is willing to do this. I will talk to my bosses and see how much they are willing to pay.

GPS sync is the full solution. Ubiquiti is already using it for their Airmax product.

Yes, I'd be willing to pay.

You know how that works. If you buy our products, we get more resources to make such things. So - keep buying our products. Did you order the SXT already ?

You know how that works. If you buy our products, we get more resources to make such things. So - keep buying our products. Did you order the SXT already ?

That statement is sales driven and I think Mikrotik need to reverse the order (1) get resources first (2) build working products (3) sales -product purchase (4) support

Just a little SXT advertisement, nothing to worry about

We are 100% mikrotik. We buy 20 MikroTik client radios every 2-3 weeks. SXT, haven't heard of it. I am researching it now. I just talked my boss into ordering a couple to try out.

Ha ha, I'm in good standing then Normis, I've spent at least $100K on routerboards, radio cards and other misc stuff.

I have also spent over 100k in routerboards last year. I am planning to expand 40 more cities in 2 years. Yes I will be buying a huge amount more routerboards. If you need proof. I can get it for you. I am really excited about gps sync. Ubiquiti has it, I am jealous. I don't want ubiquiti. I want mikrotik with gps sync. Will it be here this spring?

I don't know about that. We will see if it's possible to do. No promises.

What about your boards that support multiple cards(RB600, RB800, RB433, etc.), can they be set up so that each card sends and receives at the same time.

I can't see why not. This is only a software change. As long as the board supports a gps.

I can't see why not. This is only a software change. As long as the board supports a gps.

I would assume that there is more than just software programming involved for this to work, other items in this chain to be considered are radio card and antenna, also if the radio card is made by another company and if unannounced component changes are done this could alter performance, in short Mikrotik need to make the complete package then and only then will they have control, otherwise we could or will have with different builds of these components when purchased will result in software "hotfixes"??

I could be wrong but I believe Mikrotik puts the wireless card in adhoc mode giving them control on when to send and recieve. That and a gps should be all we need in order to make wireless sync. I dont want sync for only specific cards. I want it for all 802.11 cards. Besides, mikrotik doesnt make 300mw 3.65ghz cards. That would be nice if they did make them. But right now they dont. I know mikrotik can control the 802.11 card.

Whats your guys thoughts?

Many of us are in the same boat, we need to maximize spectral efficiency.

I've been using RouterOS for our wireless network for ~5 yrs now. While AP sync, and tower sync would have been nice features to have they were not required features when evaluating hardware for our network. To get around the issue we have made rules to follow so we don't run into too many problems. However, I do know that during heavy use times it is becoming more and more difficult to maintain stable use of higher data rates.

Now we are always planning for the next step, and are now in the process of evaluating solutions to increase capacity for the system. We have already erected towers throughout our coverage to keep the number of clients/AP to a resonable level, we have already deployed CPE's in 900 MHz, 2.4 GHz, and 5.8 GHz spectrums, and we already use sectorized antennas at each tower site. In addition each AP has its own RouterBoard, and radio installed in its own isolated compartment to minimize radio to radio interference at each tower site.

With the next upgrade to our network we are requiring both AP sync, and tower sync. I know there has been alot of confusion on the topic, but generally speaking, I want the all APs throughout the network using a specific spectrum (900 MHz, 2.4 GHz, 5.8 GHz) to all transmit simutaneously.

I have supported Mikrotik for some time now and while the 1st couple years may have been slow (maybe 50 Routerboards deployed), the past 2 yrs have been averaging ~300-400 units. I have been very pleased with the boards and with the RouterOS software, and while problems have arised Mikrotik has addressed them. BUT...

Like many others we are really starting to feel the pressure of requiring features that would help improve capacity. I don't measure capacity in CPEs/AP, I measure it in continuous Mbps/AP. AP and tower sync features would allow us reliably utilize the higher data rates thus increasing the bandwidth capabilities of the entire network. I don't care how it is done, but I do know that most serious AP and tower sync systems I've seen all use GPS to maintain precise timing of transmissions.

As long as I see progress with RouterOS in this regard it will most likely remain our preferred network equipment, I can understand a stepped approach, AP sync 1st diagnosed, tested and bugfixed, follow that with tower sync. If we don't see progress with this unfortunately we will have to rule RouterOS out for our next upgrade.

Hopefully we see something within 6 months, otherwise Mikrotik will only see money from my company when we update our wired routers, as opposed to on a weekly basis.

Cheers

I am feeling the pressure too. Like I said I need to install 40 more cities the next 2 years. I want them to have wireless sync. Thanks for you thoughts. Anyone else?

GPS sync is in our to-do list.

GPS sync is in our to-do list.

Any idea if this is something that may slip into v5 or not?

GPS sync is in our to-do list.

This is what I needed to hear. As long as its implemented in a timely fashion, Mikrotik will continue to see business from me.

Cheers

Mikrotik, may I ask how you are going to implement the wireless sync? I am going to be spending a lot of money on the expansion. I want to make sure once its built. I am not going to have a to redo it once I am done. I want what I am going to be building to be ready for wireless sync. Let us know your thoughts so we can plan sync with mikrotik for our future networks. Thanks in advance.

Normis, have you started on the wireless sync yet? I had a meeting today with the big bosses to find out what all our options are to fix the wireless network here. Today I went out in the field and did serveral tests to prove by adding this feature will definitly fix the issue.

Dallas

NV2's not even stable yet! Sync's going to need a stable TDMA base to build off first

NV2 has been out for some time now. I am sure they will have it stable soon. I am optimistic for mikrotik.

You link the sectors to a common time source, then you have them broadcast for 10ms then listen for 2ms *at the same time*. So when North is broadcasting, so is South. Then they both fall silent at the same time and listen. Notice that when they are listening for their clients, the other AP is silent, so there is no interference from the other AP even though it is on the same channel. For this to work, you need decent quality sectors that can't "see" each other's clients. If you have sectors with 27db back end rejection. Consider a client on the South sector with a -65 signal. The North sector will see that customer with a -92 signal - so it does not interfere with the North sector even though it is on the same channel. This is probably why UB created their own antenna line.

I think this is the best explanation in the thread of the desired functionality.
As for UB's rocket sectors - they have awful back end rejection which the early adopters of their sync technology will be deeply disapointed with.

corky, you do understand, of course, that they can't really listen for 2ms to all clients, right?
They would have to listen for 2/X ms per client where X is the number of connected clients.

What about your boards that support multiple cards(RB600, RB800, RB433, etc.), can they be set up so that each card sends and receives at the same time.

This is an excellent first step that requires no new hardware.
You could call it "NV2 Group" and allow syncing of multiple radio cards which are on the same routerboard.

There seem to be many things called "wireless sync". I simply wanted some clarification to understand which things do you find the most important. Is it really only in the name of it ?

Most WISPs have limited understanding of the physics involved in wireless communication. For most customers, any kind of sync will have very minimal benefits but it will help you sell more units because it is the latest hype. Far more can be achieved with proper network design than with sync.

With the next upgrade to our network we are requiring both AP sync, and tower sync. I know there has been alot of confusion on the topic, but generally speaking, I want the all APs throughout the network using a specific spectrum (900 MHz, 2.4 GHz, 5.8 GHz) to all transmit simutaneously.

Are you sure that is what you really want?
Do you realize that if a client radio can hear 2 or 3 APs, there will be so much noise that data rates will drop virtually to zero?
Proper sync will require very careful physical planning where no device ever hears more than one other device.

There seem to be many things called "wireless sync". I simply wanted some clarification to understand which things do you find the most important. Is it really only in the name of it ?

Most WISPs have limited understanding of the physics involved in wireless communication. For most customers, any kind of sync will have very minimal benefits but it will help you sell more units because it is the latest hype. Far more can be achieved with proper network design than with sync.

With the next upgrade to our network we are requiring both AP sync, and tower sync. I know there has been alot of confusion on the topic, but generally speaking, I want the all APs throughout the network using a specific spectrum (900 MHz, 2.4 GHz, 5.8 GHz) to all transmit simutaneously.

Are you sure that is what you really want?
Do you realize that if a client radio can hear 2 or 3 APs, there will be so much noise that data rates will drop virtually to zero?
Proper sync will require very careful physical planning where no device ever hears more than one other device.

I believe using sync for 3 sectors on different channels would work. This would work for the senario of removing self interference. What do you think?

I dont believe a successful GPS sync method can easily be done in software alone. We are talking microseconds, not milliseconds when it comes to the TDD timing of TDMA. In theory there would need to be a very tight timing interface directly to the WiFi card involved - and thats assuming the WiFi card is even capable of having its timing provided externally in the first place.

It would probably be easy to sync WiFi cards connected to the same motherboard but this would only achieve sync at the same tower at best. What about the the other tower on the hill that faces this tower 10km away for example?

I am guessing for MT to achieve a proper GPS sync method, they would possibly need to release a routerboard or WiFi card with a proprietary GPS input socket. Or ideally accept the pulse from an industry standard 1PPS GPS source.

I am wondering if maybe there is such a WiFi device currently on the market somewhere? Eg a standard minipci device that the O/S and related hardware communicates with just like a normal WiFi card, but the card itself has a separate connector that accepts a GPS sync pulse.
This dream WiFi card would be compatible with ALL systems without the need for operating system vendor integration.
Hmmm....

I dont believe a successful GPS sync method can easily be done in software alone. We are talking microseconds, not milliseconds when it comes to the TDD timing of TDMA. In theory there would need to be a very tight timing interface directly to the WiFi card involved - and thats assuming the WiFi card is even capable of having its timing provided externally in the first place.

It would probably be easy to sync WiFi cards connected to the same motherboard but this would only achieve sync at the same tower at best. What about the the other tower on the hill that faces this tower 10km away for example?

I am guessing for MT to achieve a proper GPS sync method, they would possibly need to release a routerboard or WiFi card with a proprietary GPS input socket. Or ideally accept the pulse from an industry standard 1PPS GPS source.

I am wondering if maybe there is such a WiFi device currently on the market somewhere? Eg a standard minipci device that the O/S and related hardware communicates with just like a normal WiFi card, but the card itself has a separate connector that accepts a GPS sync pulse.
This dream WiFi card would be compatible with ALL systems without the need for operating system vendor integration.
Hmmm....

Replacing the cards would be my last option. If mikrotik did the card. It would be one frequency at a time. I got 3.65ghz 2.4ghz 5.8ghz 900mhz etc.. It would take too long. I like the idea that we can use any frequency and any card.

Here is my though. We have ap A 5 miles away from ap B. Ap A would probe all aps and ap B would respond. Giving us the almost exact timing. I think this is almost the best approach. If we can time to the gps satillites, why cant we time to our own access points. That would be faster. Once the timing is set, it will propergate thoughout the network.

Here is my though. We have ap A 5 miles away from ap B. Ap A would probe all aps and ap B would respond. Giving us the almost exact timing. I think this is almost the best approach. If we can time to the gps satillites, why cant we time to our own access points. That would be faster. Once the timing is set, it will propergate thoughout the network.

The standard GPS sync method we are trying to achieve here with MT is very much more complicated than that.

A GPS sync'd network controls the exact timing window of when AP's are allowed to transmit and when they are allowed to recieve with a granularity down to the microsecond. This has nothing to do with when someone wants to send data for 10 secs etc etc, this is way down at the Layer 1 TDD radio timing level. A standard wifi card switches very rapidly between TX and RX in the order of thousands (maybe millions?) of times per second even when you are not sending or receiving data. This is how they send and recieve on the same channel - its called TDD, and this is the part we are trying to get 'in sync'

TDMA is the allocation of timeslots for those stations who want to send data, but it's the TDD who controls who's turn it is to transmit radio waves at any given microsecond. When the entire radio network's TDD is syncd to an accurate source (aka a standard GPS clock with a 1PPS master pulse and sometimes a 10mhz reference clock), every AP's 'microsecond' turn to transmit all happen at the same time.

The confusion I am seeing in this thread is from not differentiating between data transmissions and radio wave transmissions - they are completely different.
GPS Sync is ONLY related to the radio wave transmission side of things

The upside is a perfectly syncd network with the ability to colocate adjacent 'splattery' AP's on neighbouring channels with efficient channel re-use between towers and even sometimes at the same tower for AP antennas that are back to back.
The downside of sync'd TDD that many people are not aware of is that there also needs to be uplink and downlink ratios defined across all radios playing ball in the same sync'd network for it to be effective. EG you have to define if the radio network will be 50/50 up/down or maybe 25/75 up/down that is more generally the case. This means your AP with a total capacity of 20meg now becomes limited to 10meg down and 10meg up assuming a TDD uplink/dowlink ratio of 50%

It's a very complicated method indeed and I dont think many people actually comprehend that it's VERY DOUBTFUL that GPS sync can be properly implimented in software alone.

The downside of sync'd TDD that many people are not aware of is that there also needs to be uplink and downlink ratios defined across all radios playing ball in the same sync'd network for it to be effective. EG you have to define if the radio network will be 50/50 up/down or maybe 25/75 up/down that is more generally the case. This means your AP with a total capacity of 20meg now becomes limited to 10meg down and 10meg up assuming a TDD uplink/dowlink ratio of 50%

Quoting myself here after an interesting revelation just spotted on 'another vendors' wifi TDMA forum.

They use a separate GPS for each and every AP to look after the TDD side of things. This is the timing critical part.
They ALSO use an ethernet UDP link for distribution of not-so-timing-critical dynamic information amongst AP's. If my guess is correct, this could be the dynamic redistribution of TDMA timeslot scheduling amongst AP's. Therefore the network would also be able to overcome the above limitation re static uplink/downlink ratios. Now thats kinda cool.

Back on track - all we need right now is GPS to solve the TDD timing, and im now 99.99995% convinced that GPS for TDD timing CANNOT be done in software alone.

Dont get your hopes up, people... if 'real' GPS sync does eventually happen its more than likely going to involve a hardware upgrade (aka replacement) of your AP's in some way, shape or form.

Let's say we do software and a gps on each ap. All the aps don't need to talk exactly the same time as long as all the aps are not listening. We could use a delay to make this work. Yes we would lose a little bandwidth. But the benefit is so much better.

2 different types of syncing:

Time Division Duplex (TDD)

Using the TDD method, a single frequency channel is assigned to both the transmitter and the receiver. Both the uplink (UL) and downlink (DL) traffic use the same frequency f0 but at different times (Figure 1).

Figure 1: Spectrum Utilization in TDD

In effect, TDD divides the data stream into frames and, within each frame, assigns different time slots to the forward and reverse transmissions. This allows both types of transmissions to share the same transmission medium (i.e., the same radio frequency), while using only the part of the bandwidth required by each type of traffic (Figure 2).

Figure 2: Dynamic Bandwidth Allocation in TDD

Several inferences can be drawn from this description:

1. Since the TDD scheme can allocate dynamically the amount of time slots assigned to each direction -- transmit and receive-- an operator can define the percentage of UL versus DL traffic. This is especially important for Internet-type traffic (the ratio for UL/DL is no longer constrained to a fixed 50/50).
2. A guard band is not required to separate the UL and DL channels, because they both use the same frequency – hence, there is no loss in spectrum. A guard period, though, is necessary for synchronization purposes and to accommodate the turnaround time and the round trip delay whenever switching transmission from DL to UL, and vice versa.
3. Because the UL/DL allocation is dynamic, there is very little waste of spectrum for asymmetric operations, i.e., last-mile applications, where typically the UL traffic is a fraction of the DL traffic. (Some spectrum is still lost for the guard periods, but this is negligible compared to the total length of data in a time slot).

Frequency Division Duplex (FDD)

Using the FDD method, a distinct frequency channel is assigned to both the transmitter and the receiver. At any particular instant in time, uplink (UL) traffic uses a frequency f0 that is different from the frequency f1 used by the downlink (DL) traffic (Figure 3).

Figure 3: Spectrum Utilization in FDD

The Base Station Unit (BSU) may receive uplink traffic while it simultaneously transmits on the downlink. To avoid the high design costs that FDD imposes on Subscriber Units (SU), WiMAX SUs use a hybrid duplex method called HFDD (half-duplex FDD). HFDD is very similar to TDD. An HFDD device transmits and receives at different times like a TDD device. The difference is that it also uses different frequencies for transmit and receive to communicate with an FDD Base Station. As a result, HFDD Subscriber Units offer only half the throughput capacity of a full duplex FDD Subscriber Unit.

FDD is typically used in applications that require an equal up- and downlink bandwidth, as all TDM voice applications do. Therefore, regulatory agencies grant up- and downlink channels of equal capacity for FDD-based systems.

Several inferences can be drawn from this description:

1. Due to the symmetric nature of FDD transmission channels, and the FDD legacy as duplex method of choice for TDM voice applications, FDD transmission channels are always of equal size (50% for UL and 50% for DL). In applications such as Internet access, which can be very asymmetric in nature, a large percentage of the available UL bandwidth remains unused and is, therefore, wasted.
2. A guard band about two times the size of the UL or DL channel is required to separate the UL and DL channels. This amounts to an additional 50% loss in spectrum.
3. Once the channel bandwidth is granted by the regulator, the UL/DL allocation cannot be changed. This leads to unused spectrum for asymmetric operations, i.e., for last-mile applications, where typically the UL traffic is a fraction of the DL traffic.

Conclusion

TDD is ideally suited to the transport of asymmetric traffic, as is typical with Internet access, and it allows service providers to define accordingly the percentage of bandwidth allocated to each direction. In addition, TDD makes more efficient use of spectrum, allowing network operators to achieve greater returns on their investments in infrastructure. As for FDD, it is the scheme of choice when traffic is symmetric, as in carrier backhaul and enterprise data transfer applications.

Therefore, in the near term – as WiMAX is adopted for last-mile applications – network operators are advised to choose TDD in order to achieve the flexibility required for managing divergent traffic patterns.

FDD requires one transmitter and a separate receiver. Further a diplexer and shields are required to isolate the DL and UL.


As the transmitter and receiver use the same filters, mixers etc the cost of a TDD scheme is substantially less than an FDD scheme.

Would Normis or anyone else at MT care to update us about what your thinking is on this subject?

As per Normis' Plug, I love my little Sxt's

I am very excited about this. TDD will give me great opportunities to do great stuff with my mikrotiks. My frequencies will be very officiant.

Dallas

Don't get too excited Dallas. They have not said they are going to do this. Last I checked, N is not even working well enough for a WISP to use. With great sadness we have quit deploying MT as CPEs and APs, we only use them for routing boxes now. We are even starting to remove them from the field and replace them with other gear. It's really painful. We loved the power and interface, but our customers demand more speed and more reliability.

Don't get too excited Dallas. They have not said they are going to do this. Last I checked, N is not even working well enough for a WISP to use. With great sadness we have quit deploying MT as CPEs and APs, we only use them for routing boxes now. We are even starting to remove them from the field and replace them with other gear. It's really painful. We loved the power and interface, but our customers demand more speed and more reliability.

Almost my whole network is using NV2 and it works great. I am also using 802.11N and it works very well. Great results. With the new features that Mikrotik has to offer. I am providing very releighable internet to rural market. I am setting up a new system that is full duplex and I can offer 100mbps to customer 6 miles away and 60mbps full duplex at 10 miles. Can I help you with some mikrotik stuff?

Many clients wondering when this new option is available in mk because they are starting to migrate to competitor AirSync...

Any position???

Many clients wondering when this new option is available in mk because they are starting to migrate to competitor AirSync...

Any position???

Reading the forum of this competitor I do not see AirSync working.
I see rusting equipment and a lot of problems.
Where do you migrate to? Throwing Marketing Material at your customers?

I see rusting equipment and a lot of problems.

How does plastic rust? he he.

Interesting old debate about the GPS synchronization (from 2010). Today Motorola-Cambium works with this method and "noisy" areas wireless networks work fine while the other devices without this technology does not work or hardly work very degraded. 
I love Mikrotik devices but it is necessary for you to do a major leap forward on the development of wireless technologies.

cetalfio

The main question is Mikrotik developing gps sync? If yes when we can start to test it?

MT guys can answer to this question?

+1 cetalfio