Sunday, October 24, 2010

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!  


Anonymous said...

Use of anything "off the shelf" is a must. You're right on that.

One software layer that is interesting regarding these issues is ZeroMQ. It can run on multiple physical layers but what it emphasises is we also need a convenient way of orchestrating the nodes within the network. It's all about speed, too. :)

Dan said...

Dan the Blogger confesses to being new to networking terms like "sockets."

I got pretty exited as I started reading about that, akauppi, but now I'm not so sure. I'm certainly no expert, but that's in the transport layer (layer 4) of the OSI model, and as I understand it, most of the latency is coming from layers 2 and 3, so presumably those delays would remain. In particular, I personally am most concerned about fast and reliable "discovery" of new vehicles (nodes) joining a LAN or subnet and immediately having connectivity with their counterparts. As I interpret it, discovery would have to happen first before ZeroMQ could work. Also, wouldn't it only communicate during the periods allowed by the time-division multiplexing? Again, I'm just starting to get a handle on this stuff, so I might be completely wrong...

Anonymous said...

You're right. If there's a bad non-real time connection below ZMQ, it cannot do marvels. Naturally.

But there's two ways to seeing this. Outside-in and inside-out. ZMQ can run on practically any networking infrastructure, so once a software is developed for it (and if there are delay problems) the physical layer can be exchanged for a better one. Without touching the networking code essentially, if at all.

This way, we could craft software in a PC (simulated) and then apply the *same* software essentially unaltered in a hardware scenario. I believe ZMQ will be an essential tool in making PRT networks come true.

As a sample, the iPhone was (to my knowledge) developed "as software" until Apple knew, what kind of hardware they actually needed. That's opposite to the traditional hardware based thinking in the handset world.

Dan said...

Speaking of handsets, what do you think of the Android OS? It's open source, (but you can keep your improvements proprietary) Linux kernel with Java Libraries and the source code includes the networking and telephony stacks - I'd wager they're pretty fast. Plus you get the names of thousands of programmers who might find PRT challenging and the whole Open Handset Alliance in the deal. (just in case you want to brag that your that your OS was a collaboration involving Intel, Google, and Sony, among others. Oh yeah, and speaking of apps...