Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're about to design an inhouse industry network consisting basically of the following: 1 server connected via wire to up to 100 proprietary RF access points (basically embedded devices), which each can be connected via radio to up to 100 endpoint embedded devices. Something like this:

alt text

Now, I'm wondering about some design decisions that we need to take and I'm sure there are plenty of similar designs out there and lots of folks with experiences of them, both good and bad. Maybe you can chime in?

All endpoint devices are independent and will communicate their own unique data to the server, and the other way around. The server therefore needs to be able to target each endpoint device individually. Each endpoint device pairs itself with 1 access point and then talks a proprietary RF protocol to it, TCP/IP is not an option there.

The server will know which endpoint device is paired with which access point, so when the server needs to talk to an individual endpoint device, the communication must go through the paired access point. Hence, the server needs to directly address the access point.

Question: Considering the limited resources available in the proprietary access point, is TCP/IP between server and access point recommended for this scenario? Or would you suggest something entirely different?

share|improve this question
Not nearly enough info. But based on what's here, I'd say "yes". – Dennis Williamson Sep 23 '09 at 17:18
I'm new to that arena and a bit unsure what info you need to make it "enough" - I'd be glad to add more if you could please give me some pointer on what's needed. Thanks! – Johann Gerell Sep 24 '09 at 5:48
Look for zigbee / Xbee. – Brad Gilbert Sep 24 '09 at 19:55
@Brad: Yes, Zigbee is on our radar, but my main concern with the above question was the wired server-to-access-point part of the network, not the wireless part. – Johann Gerell Sep 24 '09 at 20:51
up vote 3 down vote accepted

When in doubt, over Ethernet, use IP. If you want to use UDP or TCP is another issue entirely. Both have advantages, but honestly I would consider this.

How stable is the RF part? How often do the devices reassociate? If not often, you could quite easily implement a lazy learning system where the device associates, and the AP sends a single UDP frame saying "I have device X." When device X transmits, it could take that data, wrap it in UDP, mark it up a bit with some info saying which device slot it is at, etc. and then transmit it to the host.

I would not use TCP for this. TCP has too much state. With UDP, you would want some sort of simple send/ack protocol though, or design your smarts as close to the high-powered computer end as you can and have it detect and ask for missing data, or cope with it missing.

Have you considered asking this question on the 'piclist' -- which is full of very smart uP types?

share|improve this answer

The 8051 is a very old and small microcontroller. You may have difficulty implementing an IP stack on it depending ont he features required. I would also imagine it is underpowered unless of course you are implementing it at a higher clock rate in an fpga. That being said using IP is pretty much a foregone conclusion because of the router and switch elements you have in your topology. IP is easy to route, Ethernet is easy to switch, and using an IP protocol stack its easy to program all of the intermediate control/data protocol from server to the access point. The only time this wouldn't be a good fit is if the access point just doesn't have the processing power to handle multiplexing the RF transmitted data from 100 devices onto a single tcp/udp stream, or cannot handle a hundred tcp/udp stream ( a more likely scenario ).

My gut instinct is that in this example the 8051 MCU is not up to the task, so if you are wedded to using that microcontroller for the access point and you don't have a faster controlling processor you may need to add a layer of indirection after the ethernet switch, like a control node so you can have a straight serial protocol with the access point / devices. If the data rates are very low and you can live with UDP it may be doable though.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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