服务器和接入点之间的线路以及射频到端点设备的设计
我们即将设计一个内部行业网络，其基本组成如下： 1 台服务器通过有线方式连接至最多 100 个专有 RF 接入点（基本上是嵌入式设备），每个接入点可通过无线电连接至最多 100 个端点嵌入式设备。像这样的东西：
现在，我想知道我们需要采取的一些设计决策，我确信有很多类似的设计，并且很多人都有过这些设计的经验，无论好坏。也许你可以插话一下？
所有端点设备都是独立的，并将其自己独特的数据传递给服务器，反之亦然。因此，服务器需要能够单独定位每个端点设备。每个端点设备将自身与 1 个接入点配对，然后与其进行专有 RF 协议对话，TCP/IP 不是其中的选项。
服务器将知道哪个端点设备与哪个接入点配对，因此当服务器需要与单个端点设备通信时，通信必须通过配对的接入点。因此，服务器需要直接寻址接入点。
问题：考虑到专有接入点中可用的资源有限，是否建议在这种情况下使用服务器和接入点之间的 TCP/IP？或者你会建议一些完全不同的东西吗？
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:
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我发现该图令人困惑：
如果这不是它自己的网络，并且服务器到 AP 的链接正在您的内部公司网络上运行，那么就没有真正的选择，AP 上必须有一个 TCP/IP 堆栈。
如果这是它自己的隔离网络，那么路由器有什么用呢？
如果这实际上是它自己的隔离网络，那么您是对的，实际上根本不需要以太网连接。您将在无线网络上看到的开销是巨大的，您的无开销理想数据速率是 250kbit/秒，在 802.15.4 @ 2.4ghz 点对点上运行 ZigBee，您的实际数据传输速度通常约为 20kbit/秒。自定义协议应该能够获得较低的开销，但这需要定义。
如果我要设计这个，我会为 AP 选择一个具有板载 802.15.4 和 CAN（控制器局域网）的 SoC。根据大小和数据速率，只需为服务器获取 PCI CAN 卡并将其连接起来，使用 DeviceNet 之类的东西作为服务器到 AP 通信的协议层。这可以通过使用 CAN 交换机和中继器进行扩展。 CAN一直用于工业自动化领域，稍微谷歌一下就可以找到一些制造工厂使用的数万个节点的例子。
I find the diagram confusing:
If this isn't its own network and the server to AP link is running on your internal company network, there isn't really an option, there must be a TCP/IP stack on the AP.
If this is its own isolated network then what is the router for?
If this is, in fact, its own isolated network then you are right, there really isn't a need for the Ethernet connectivity at all. The overhead you will see on the wireless is huge, your no overhead ideal data rate is 250kbit/sec, running ZigBee on 802.15.4 @ 2.4ghz point to point your real data throughout is usually around 20kbit/sec. A custom protocol should be able to obtain lower overhead but this would need to be defined.
If I were designing this I would choose a SoC for the AP that had on board 802.15.4 and CAN (Controller Area Network). Depending on size and data rate just get a PCI CAN card for the server and connect it up, use something like DeviceNet as your protocol layer for server to AP communications. This can be expanded by using CAN switches and repeaters. CAN is used all the time in industrial automation, a little googling can find you example of tens of thousands of nodes used in some manufacturing plants.
有一些小型 TCP/IP 堆栈，例如 LwIP。
There are small TCP/IP stacks, for example LwIP.
您没有提到要通信的数据量或带宽考虑因素？
针对 8051 的第 3 方 TCPIP 堆栈将简化连接 100 个单元的所有网络问题。您最终可能仍然会得到位于 tcpip 堆栈顶部的专有协议，但它只是服务器和每个端点之间的简单点对点通信。
You didn't mention the amount of data to be communicated, or bandwidth considerations?
A 3rd party TCPIP stack targeted at the 8051 would simplify all the networking issues with connecting 100 units. You probably will still end up with a proprietary protocol that sits on top of the tcpip stack but then it is just simple point-to-point communication between the server and each end point.