I am a newbie at network and I am trying to find an architecture for a WI-FI system which is deployed in large area(over 50,000 square meters) and connects 1000-2000 devices with a server.

Each of the devices is a robot and will be navigating inside the factory. The server will communicate with each robot, read data from the robot and control the behaviour of the robots. The server connects to the robots through WI-FI.

The requirements of the systems are:

  1. The robots will navigate inside the 50,000 square meters(200m * 250m) factory;
  2. The robots shall be connected to the server all the time. If there is any disconnection and re-connection, it shall happen in 100ms;

  3. The data delay shall be around 100ms;

  4. The communication rate is around 5Hz, meaning there is a send and receive from the robot to the server every 200ms;

  5. The data amount for every communication is around 1KB;

What I am thinking

1.The server will be connected with several wireless APs which are located at the roof of the factory. The APs will cover all the area of the factory.

2.Each robot will have two WI-FI modules on it. The two WI-FI modules always connect to different APs to ensure that when there is a transition from the coverage of an AP to the coverage of another AP there is always an established connection.

Any comments/insights will be really appreciated

  • \$\begingroup\$ Does it have to be WiFi? Or will any form of wireless/radio communication do? \$\endgroup\$
    – Jack B
    Sep 7, 2016 at 9:30
  • 12
    \$\begingroup\$ The two-wifi system will require you to write and debug a whole pile of software to make it work. There are consultants you can hire who specialise in making this kind of thing work, e.g. at conferences, and given that your overall system budget is probably in the multiple millions for all those robots you should just get an expert in. Or it'll cost a lot more when it doesn't work. \$\endgroup\$
    – pjc50
    Sep 7, 2016 at 9:31
  • 6
    \$\begingroup\$ (Note that if your data delay requirements are safety-critical the project is doomed - wifi cannot deliver that kind of reliability. Oh, and you may have problems if you have EMI-emitting equipment in the factory like welders. I'd start by speaking to Ubiquiti) \$\endgroup\$
    – pjc50
    Sep 7, 2016 at 9:33
  • 1
    \$\begingroup\$ This question seems awfully broad. Quoting How to Ask Is your question about electronics design? We prefer questions that can be answered, not just discussed. Provide details. Share your research. \$\endgroup\$
    – Dampmaskin
    Sep 7, 2016 at 10:23
  • 2
    \$\begingroup\$ @pjc50: The two-wifi system might not require that much work, if you use 5 Ghz primary and 2.4 Ghz secondary. Use separate AP's for the two, so that the cell boundaries do not coincide. \$\endgroup\$
    – MSalters
    Sep 7, 2016 at 12:29

3 Answers 3


Let's make some back-of-the envelope calculations:

You have 2000 devices. If you're using 5 GHz WiFi, you'll have around 45 available non-overlapping channels for the US, a bit less in the EU, if you're using just 20 MHz per channel. This is of course, assuming you have equipment which properly supports dynamic frequency selection, and this might be an issue (or it was 4-5 years ago, when I looked into it at least!).

Now, if we try to put a reasonable number of devices per access point, this would give us around 10 devices per AP (this number can be adjusted a bit if more precise calculations are to be done). So you'll need to fit 200 access points into 45 channels. I've seen the following formula for the number of hexagonal sectors in a cluster: \$N=a+ab+b\$ So you'd need to pick a and b such that the N is closest as possible to the number of allowed channels in your region. I think that the derivation was explained in Wireless Communications from Theodore Rappaport. This book will also have some calculations about peak and average utilization of a network system, so you could get some estimates on how much throughput you actually need, when we take into account average number of requests per minute per AP.
This all should be doable, with say 5 to 6 clusters, but you'll probably need to use highly-directional sector antennas pointing downward from the roof and a very low transmit power, so not to disturb co-channel stations in neighboring clusters.

Then there's also the part which I don't remember so well and that's how feasible this is to do with actual WiFi network protocols as well. My feeling is that 200 ms update rate is a bit high. Perhaps it might be worth it to try to have the system work reliably with some missed updates, just in case.

Furthermore, there are certain wait periods defined in the standards themselves which are going to affect your operation. I don't remember actual values right now, but look up SIFS, PIFS, DIFS, EIFS, AIFS and how they interact. Next, you commented about relaxing the 1 KiB requirement. I personally don't find that all that reasonable. In fact, I'd recommend to go even higher than 1 KiB packet. Namely, with each datagram you send, you'll have extra overhead before it reaches the frame level and goes out into the æther. I don't remember exact values now, but keeping your useful data to the size of around 1.3 KiB is relatively good. The maximum frame size for WiFi is a bit higher than 2 KiB, but for Ethernet, it's around 1.5 KiB (yes, there are jumbo-frames that go up to around 9 KiB, but using them is asking for problems, unless you can 100% guarantee that every single device in the net will support them). If your datagrams are around 1.3 KiB, you'll have more than enough space for WiFi and still be able to fit the frame into the Ethernet. For these type of calculations, I found books from Matthew S. Gast very useful. He wrote 802.11 Wireless Networks, 802.11n: A Survival Guide and 802.11ac: A Survival Guide, which form a series.

Also as an advice, be sure to do the calculations, select which network standard you want to use and enable ONLY that single standard and disable backward-compatibility. The issue is the so-called "air time". Basically, if you have backward compatibility enabled, some of the service data will be sent at the rate at which even the oldest compatible device will be able to receive it. It happened to me that once a WiFi network downgraded down to IEEE 802.11 with no letters speed! The result is that at low speeds, even small maintenance packets needed to keep the network alive will take long time to transmit.
Backward compatibility was mandated in standards until recently (I don't remember if 802.11n or 802.11ac is the one who broke that), but equipment which allows breaking of that requirement does exist and can be commonly found.

Next, don't forget that for something like this, you'll need serious wired network infrastructure to support all of what you want. I don't go too much into that here, but I'll just say that the wired part can be as complex as the WiFi, if you want it to run properly. Also you mention "the server". For this to work, you'll probably need several physical servers running a single virtual machine redundantly. Even this part will be very complicated.

  • 1
    \$\begingroup\$ Plenty of gamers can live with WiFi, so we can safely assume that 5 packets/second, 100 ms average latency is achievable. I'd expect problems with the roaming. \$\endgroup\$
    – MSalters
    Sep 7, 2016 at 12:24
  • 2
    \$\begingroup\$ @MSalters That's true for one robot, but if we have 10? That's a packet to different host every 10 ms, in the best case. Furthermore, you need to take roaming into those 100 ms. Things could get a bit critical here. \$\endgroup\$
    – AndrejaKo
    Sep 7, 2016 at 12:40

@AndrejaKo explained very well why using a WiFi infrastructure for this many devices is problematic.

I'd go one step further and say: It's wrong for your application.

Your application is time-critical navigation/control/process automation. WiFi is a Collision-avoiding multiple user scheme that makes absolutely zero guarantees about whether a single station will be able to send the tiniest amount of data within a bounded time.

Hence, in a congestion scenario, a few robots will simply not be able to communicate, even if others see "spare channel time" that could be used. This is absolutely not acceptable for your application, and is central to how WiFi works.

What you need is a system that guarantees all stations can get channel access within a finite amount of time, and you need to do that for a lot of devices. Hence, you need something that looks much more like a cellular network, or classical token ring networks. Cellular have a central arbitration unit and defined spectral/temporal positions where stations can request access to the channel for data transmission and are guaranteed to get it within a defined amount of time – this requires, however, completely different infrastructure than your WiFi approach. I admit, your delay constraints are relatively lax, but I also see that the probability that they aren't met in a grid of WiFi networks is really high. As AndrejaKo said, you'd essentially need 45 channels. WiFi has max 12 or 13 channels. Things will get hairy.

In fact, there's serious research / development going on right now for 5G, which, as far as buzzwording goes, should become the infrastructural basis for "Industry 4.0", i.e. exactly what you describe your robots do.

In any case, the whole "I have many stations, and tight latency requirements, but only a limited spectrum" problem isn't easy, but WiFi is definitely not a viable choice here, not in any modification or restriction to a single sub-standard. Think more in the ways of wireless automation buses – which already exist!

  • \$\begingroup\$ According to the OP, "The server will communicate with each robot", not the other way around, so congestions should not happen. \$\endgroup\$ Sep 7, 2016 at 12:18
  • 2
    \$\begingroup\$ @DmitryGrigoryev that doesn't matter here, WiFi needs Ack, and on higher-up levels, you want the stations to be able to provide acknowledgement of actions; anything based on internet protocols will pretty much require the back-channel to have bounded latency with respect to random access to either end. \$\endgroup\$ Sep 7, 2016 at 12:21
  • \$\begingroup\$ Please check this one... extricom.com/category/… \$\endgroup\$ Sep 7, 2016 at 12:36
  • \$\begingroup\$ Actually, as I mentioned in my answer, 5 GHz WiFi has around 45 channels that are in 20 MHz mode non-overlapping. The 2.4 GHz band, with its overlapping channels, is imho out of the question here. \$\endgroup\$
    – AndrejaKo
    Sep 7, 2016 at 12:42

MQTT is a good protocol that you can use in this project for communication purpose. the protocol is pretty transparent and easy to sent/broadcast messages in between robots. You can use a software to control these devices by installing MQTT library.

The protocol is available in almost all programing languages to fit with any system (controller, PC, smartphones, web etc..)


Not the answer you're looking for? Browse other questions tagged or ask your own question.