107> An App for that.

In the world of TCP/IP, and even Ethernet, and especially any wireless version of either, there are transmission delays that limit what such technologies can do for synchronizing PRT vehicles. That is not to say that such delays cannot be overcome. The problem is that off-the-shelf solutions are only just emerging. Building an IP-based PRT network infrastructure that doesn’t rely on proprietary techniques is, for the time being, still fairly complicated.

Modern computer networking involves lots and lots of flexibility, security, compatibility and legacy issues. After all, computers are used for all sorts of things that were developed over time by many players. Anything resembling a standard communication procedure needs to address many unknowns. Remarkably, the present systems are designed to handle messages of unknown length, coming in at unknown speed, which will be forwarded along an unknown route. The original designers of these systems wisely prioritized accuracy and completeness of the data being sent over speed, and the protocols reflect this. Hence these systems (as they analyze and sort bits of information like a postal worker sorting letters) produce the delays we refer to as latency.

Luckily PRT vehicle control is not the only application that requires minimal network latency. Two others come to mind. The first is industrial processes. Machinery must often interact with split-second precision. The ubiquity of Ethernet as a way to network computers has created a market for methods to achieve “real-time” process control using the same equipment. One interesting open-source project worth exploring is RTnet, which has advanced to the point of having suites of development tools written for it.

A second area driving change is VOIP. (Voice Over Internet Protocol)  You see, VOIP cannot tolerate latency. Unlike the data packets that will re-assemble into an Email or even a streaming movie, the packets that comprise your telephone conversation must arrive in order and on time. (relatively speaking)  With new “smart phones” appearing daily, higher quality VOIP is becoming essential. Getting there involves a reversal of the previous priority of completeness and accuracy. For example, if a split-second part of a conversation is lost or scrambled, it should just be tossed out, leaving a click or silent spot in the audio. In ordinary TCP/IP, the system would detect the damaged data and ask that it be resent, even if it came in two seconds late. The bottom line is VOIP is forcing a rethink of this and all of the other latency producing steps used in communication and networking. Furthermore, telephones are inherently mobile. When a person travels down the highway talking on the phone he is forcing the network to find a seamless way to “hand-off” his call from one antenna (network access point) to another. This is similar to the problem PRT designers face if they want to minimize the number of vehicles in any subnet and want to minimize the number of hops any transmission must take.

Telephone standards have been referred to in terms of which “generation” they come from. We are coming to the end of the 3G era. Aspects of 4G are already appearing. Whereas some 3G systems had legacy analog capabilities for better phone reception, 4G is 100% packet based. Previously cellular carriers had little incentive to adhere tightly to standards such as the various flavors of IEEE 802, preferring to compete with proprietary protocols. The convergence of corporate data networks, internet, smart phones and the like will surely lead to more “Plug-and-Play” solutions for mobile users interacting with private networks. And that means more standardization between carriers. And, speaking of IEEE 802.xx, the next generation of standards (such as 802.20) looks pretty awesome. But what is “state of the art” now?

There is a lot of activity surrounding the 802.16e standard, which is being commercialized as “WiMAX.” (successor to WiFi) Supposedly latencies are in the in the 40 ms range, but I’m skeptical as to whether real world performance is anything like that. I assume, for example that that is a one-way number, which would double in a round-trip message that included a confirmation. But I am no expert. 

I also am not sure what, specifically, can be done with a guaranteed round-trip transmission in, say, 50 ms that can’t be done with a turnaround time of a second or more. It seems to me that for real split-second control issues, 50 ms is still an eternity. It is possible that real-time Ethernet (like RT net) could be adapted for “leaky cable” but that seems like a lot of effort for the hypothetical portion of the PRT control that needs 10ms to one second access times. After all, there is still direct sensing and switching, which is essentially instantaneous. I guess it would be worthwhile to take a good look at the specific maneuvers that a PRT vehicle must make in terms of actual time requirements, from control signal to electro-mechanical response, before getting too far in terms of favoring one technology over another. More specifically, I question whether sub-second communications are really necessary for pre-merge maneuvers. This question leads to track layout and capacity considerations as much as anything else. Should vehicles be packed so closely together and run so fast between closely spaced merge points as to necessitate split-second communications? It seems to me that a little traffic management and prudent track design could go a long way toward allowing a bit of latency. And there is also my often-stated preference for putting more control at the vehicular level, limiting the need for top-down control.  Meanwhile, technology marches on. Maybe PRT should run on the Android OS!