A few months ago, I taped my TV remote onto the side of an acrylic rod and covered the connection in foil. Then I pointed one end of the rod at my TV and became one of only a handful of people worldwide to use intra-bedroom fiber optics to turn on The Late Show. This demonstrates a couple of things. First, that you know you need help with your tinkerer addiction when you just happen to have cast acrylic rod hanging around the house. Secondly, it showed that you can transmit data into the SIDE of a fiber optic media and have it be readable coming out the end.
In Ed Anderson’s PRT designs he uses “leaky-cable” to send and receive messages from the vehicles to a zone-controller. Leaky-cable is essentially coaxial cable with slits in the covering that lets radio signals “leak” in and out. This technology was originally used to communicate in mines but is increasingly being used to extend wireless “hot-spots” such as in hotels or dorms since running the cable down the hall is all that is required to give connectivity to the computers in all of the rooms on either side.
Unfortunately these products are designed to broadcast and receive over a wide area, usually up to 30 meters from the cable. That creates the issue is cross-talk. Inside of a PRT track, these products are shouting instead or whispering, since the signal only needs to extend a couple of centimeters. Putting a backup or any second cable won’t work, since each would broadcast and receive from the other. Anderson used time-division multiplexing to let vehicles take turns using the one cable. This is apparently a workable arrangement, but lets just say it is not exactly a modern LAN without some major tweaking. It certainly seems, in theory, that the “volume” could be turned way down and some kind of shielding might be used to enable a second cable (to get more bandwidth) but this is just speculation.
So I have been wondering about infrared. Have you seen “side glow” fiber optic cable? It looks like a flexible neon light. It is the direct optical equivalent to leaky cable. One thing about it is that there is no issue with cross-talk if the cables are shielded. It turns out that before RF wireless connectivity became the standard, there were quite a few infrared products out there for computer networking. Now I can’t really find any, although apparently it is sometimes used for financial and other confidential data because it cannot be hacked into from outside the room, since it relies on “line-of-site” between the transmitter and receiver.
There is one fundamental realization that got me thinking. Since an infrared transmitter, such as my TV remote, is essentially just an LED, (like a light bulb) why be bound to using just one? Why not have, say, 100 all blinking as one? It would be a bit like sending Morse code by plugging and unplugging a string of Christmas lights. Clearly this would be a simple way to broadcast over a wide area. What about the other direction? Can there be multiple, distributed receivers as well?
I am a bit out of my field here, but it seems to me that with Ethernet there is a designated wire from any computer to a router or switch. Could a track-based receiver(s) plug a passing vehicle into an LAN without the lengthy discovery protocol? After all, to the network, it wouldn’t be apparent that different passing vehicles were sending the data. I think the limit is 256 such nodes. I guess there are some Mac or IP address hurdles.
I have to say that this is a somewhat arbitrary exercise at this point. I probably should be starting with a fine-grained examination of exactly what needs to be communicated when and to whom. Speaking in generalities is just not cutting it. Form needs to follow function, not philosophy or “rules of thumb.” As far as rapid communication goes, it would be very rare indeed for it to involve many more than a dozen vehicles, and they are in a predictable positional relationship. (equidistant from a merge) Those positional relationships need to be the starting point for designing any network, as well as firmware and software. I’ll try and explore these more next time.
Tuesday, September 28, 2010
Subscribe to:
Post Comments (Atom)
15 comments:
seems like some reasonable ideas though using a second cable to get more bandwidth feels like it might just be overkill, I can't imagine that much bandwidth really being necessary also I'd like to mention that using higher frequency radio waves they'll penetrate less exactly as IR does but it might not need to go as high as that, around 60Ghz as is used for the upcoming 'wireless HD' standards for instance is blocked even by air (because it matches it's magnetic resonance frequency or something) so works well for short range radio and should carry ample amounts of data and be easier to work with than optics.
I would basically ignore all specifications relating to networking from the last published Anderson design. Things have changed dramatically since then. What is useful to understand is how they changed. It certainly isn't the case that better cables have been the main contributor to the massive increases in bandwidth we've seen. If it was only cable upgrades we would have maybe 10 times the bandwidth we did 20 years ago. Instead we have maybe 100,000 times the bandwidth.
The magic of these improvements is signalling, and the tolerances of transmission and reception equipment. As a result of these changes there isn't any cause to worry that a leaky cable cannot support sufficient bandwidth or that you need a second to increase capacity. In terms of backup, I think it works fine.. if one is cut and the other is not. Of course the limitation is that many events that would cut one would cut both since they are at physical maximum of a few feet apart.
If you doubt these claims, think about the use of leaky cable to extend wireless hot spots. There's plenty of bandwidth there. Putting the receivers closer to the cable should produce even better results.
While I certainly admire your inventiveness, I can't fathom any reason that PRT needs custom designed network gear. It simply needs to select from the readily available standard components a set of already reliable choices.
While some deeper research is valid, my feeling is that RF communications are more appropriate to the "last meter" communications than optics (explain that in a bit). And because it would be cost prohibitive to use a different mechanism for the last meter vs the last mile, it's really the last mile that I think would be RF based, either fully wireless, leaky cable, or ideally, both (because as a pair they are more resilient to failure and sabotage).
The reason the last meter doesn't fit optics well is because optics optics are easier to "block/obstruct". In addition high performance optics are very dependent on tight controls. One great thing about fiber optic cable is there is essentially no interference once inside. But if you have a full meter of interference before you reach the cable, and you have a moving vehicle trying to aim it's beam of light correctly.. well you can make it work but I don't suspect it will be the cheapest, most reliable or best performing solution.
Dan The Blogger Responds -
Gentlemen, I basically agree with what is being said here... I would really, REALLY prefer off-the shelf components. I would love to see the configuration of a typical LAN, using ordinary Ethernet protocols, but I don't think they have a way to convert that for having the "workstations" traveling all over the place- at least not with millisecond latency. Of course one way, which I have suggested, is to have the decision making that needs to be immediate be put in the hands of the vehicles themselves. (and possibly the half dozen vehicles most immediately effected via some separate, direct communications mode) Then we are bake to the autonomy debate.
off the shelf doesn't necessarily mean 'consumer products', there are other networking standards some of which have been designed to meet very similar constraints so although wifi might not provide the latency required it doesn't mean that there isn't an off-the-shelf solution that does, anyway, I certainly don't think the ethernet protocols in particular would be a problem, they're used in plenty of safety critical real-time networks, really though, I don't think even using IP over wifi is likely to be a problem in practical use though it might make safety certification an issue since it's not a licenced band and IP isn't a 'real-time' protocol, not that there's really anything wrong with doing things that way I just think bureaucracy would get in the way.
Yes, Chronokun, there is definitely a suitable solution out there already since there a many existing systems with far more stringent requirements.
I think as far as transport & network layers go, TCP & IP will probably be sufficient. The physical layer is probably the area where PRT's requirements are most unique, but even that is not unexplored territory, it's just not equivalent to the average computer/cell phone user's requirements.
Physically, I see leaky cable with a backup RF transmission as the correct choice. At the data link layer I don't really know what merges those two best.. maybe there is a solution based upon Ethernet already. That's the layer that I know the least about. I understand basically how Ethernet works, but not why it works well or poorly in comparison to the less widespread alternatives.
My primary candidate for the RF interface is two-way "smart" RF-id chips.
something like this
What they offer (and WLAN doesn't) is being designed for good encryption and more real-time usage.
Once we've built a system like that (from off the shelf components) opening it up as open hardware & software (or at least sharing with other PRT vendors) will be considered.
WLAN encryption is fairly good, assuming of course that you're using something current, like WPA2 with AES, rather than WEP.
Maybe you mean something other than encryption? Encryption is software. Hardware's only relevance to encryption is whether it can perform it fast enough.
Hardware still does have security implications, and quite a bit more in the wireless vs. wired world. Shorter transmission power or directionality are positive qualities for security. There is also an advantage to spreading a signal over a very wide range of frequencies, making it difficult for a receiver to properly tune to receive that data without knowing the "plan". If you're already compromised then that helps little, but it can make it much more difficult to become compromised (breaking a cipher with even 5% data loss is going to be much harder than with 0%)
Ryan, you're right. I was a bit too vague in my comment and I don't plan to dig very deep into this here. The size of the comment fields simply isn't enough.
Let's just say I would strongly suggest NOT using WLAN in any PRT system. Ever.
It's not only about cracking the encryption. It's about disturbance tolerance as well. People shouldn't be able to jam a track by bringing an open micro wave oven in its vicinity. I believe WLAN is rather easy to jam, if still not so easy to uncipher.
But ciphering always goes by what's the value of it. Eventually (10 years or so) anything we feel is "strong" now becomes much weaker (security). Problem is the PRT lifespan easily bypasses that. Think if Morgantown used 1973 wireless solution. How easy would it to push that system down?
For the same reasons, I would not trust GPS either.
Jamming is tough, but I'll come back to that.
Encryption is software, and that means that it upgrades with time. The key point is that the hardware needs to be able to handle increased load, but hopefully the encryption processors are not so deeply embedded in the larger physical infrastructure as to be impossible to replace.
One of the beautiful things about just about every encryption cipher is having a more linear scaling factor for authorized decryption that cracking. If CPU's quadruple speed in 3 years, then yes, 128bit encryption is 4 times easier to crack compared to 3 years earlier. But 256-bit encryption may still be twice as hard to crack as 3 years earlier, but practical in half the CPU load. Thus encryption under the new standard of 256bit is now twice as fast and cracking twice as hard.
The caveat to all this is "vulnerabilities", which are holes in the system where a hacker gets a hold of the keys, or can shortcut the brute force approach. A shortcut isn't likely to ever be better than the authorized decryption but if it's close enough it won't matter. It's very hard to predict where vulnerabilities will be found. If they are already known, definitely avoid them, but in general once a vulnerability is know it's either patched or anyone serious about security abandons that system all together.
If an encryption protocol has a big enough vulnerability (i.e. WEP) than using it isn't doing anything other than discouraging the most casual of activities. WEP will probably prevent some of your neighbors from leaching off your internet connection, but if someone is targeting you it won't prevent them from getting your bank login (though SSL still might).
Jamming is tough though. The earliest attempts at defeating jamming I think were based around trying to overpower the jamming or to be more directional. More recently though I believe the latest advances revolve around finding the pattern within the noise. Assuming a jamming device isn't powerful enough to simply overload the circuits of the receiver, then the best it can do is add psuedo random noise. But take any random system and add a pattern (signal) inside it, then with enough time and repetition that pattern can be isolated. This definitely harms bandwidth and adds an artificial latency as well, but it will survive jamming of less than EMP power. With less sophisticated jamming systems (i.e. microwave oven), it's possible to isolate the jamming signal (it's not very random), and the transmit around it. In that case bandwidth may not suffer much and almost all of the artificial latency can be avoided.
I'm amused. The only real advance in computing power that would cause any danger to encryption technology is practical quantum computing. Most of our encryption algorithms will be pooched. But PRT is not the biggest problem if that comes to pass--the world financial system will be in a heap of trouble.
Upshot: don't worry about encryption. Just make sure an engineer doesn't design the protocol. They're really bad at it.
just wondering what's with all the discussion about encryption? obviously if it's possible to broadcast onto the network then authentication would be necessary, but I don't see any threat from people eavesdropping on the network or anything?
Chronokun:
You're right. Eavesdropping is not really the concern (much). Access stealing can be made so hard it's not the main concern either.
About jamming. I'm not worried about long-time jamming exercise (s.a. leaving a device for a week next to a track) since those efforts will certainly show up in the communications the moment they're put on. Probably we'll get such phenomena as every-day duty in cityscapes. Even currently, there are businesses (7signal.com) doing WLAN interference mapping tools. Switch on a microwave and you'll see it in their logs.
What I'm worried about is *short time* devices being able to completely block the transmissions. This is akin to someone putting a concrete block in the middle of a public road, so obviously it is (should be) a criminal act. What it will do is run down the operations of a certain track section until the issue is resolved. No personal damages, but a heck of a lot of trouble.
The solution would be to have two means of communications to the moving vehicles. Some systems mentioned this at PRT@LHR. It's certainly an area where we need to be robust to avoid embarrassing events in the future.
That's all.
The concern with encryption is about integrity, not confidentiality. You don't want any device to be able impersonate another device. See ciphers are used for more than keeping someone from reading data, their also used for creating data that could only have been created by a source with some unique information. This is an asymmetric algorithm. With the ability to insert random data into the system, many undesirable things happen, so while I consider encryption technology generally sound and fairly future proof, it does need oversight and maintenance to stay ahead of the bad guys.
I've been suggesting leaky cable plus wireless RF as the two "physical" mediums. Both can be fairly resilient on their own, but have enough disjoint elements that it's difficult to attack both at once. An interesting third would be line of sight optical connections, but I don't generally favor optics because it would be difficult to maintain line of sight in many cases. However, as a third, if you want extra resiliency, the directionality of it would make large scale jamming nearly impossible. It's operating characteristics are fairly disjoint from those of leaky cable or RF, and having disjoint characteristics generally reduces risk among redundant systems.
I would suggest that leaky cable would be very hard to jam in this setup as the "real" sender in the vehicle is perhaps 5 cm from the cable while anything jamming it would be at leat 1 m from it (if you stand in a station).
The main problem is not the transmission speed but the latency. All wireless communication between many senders is based on time division multiplexing. The algorithm to select who gets to send when (the MAC algorithm) is crucial for getting low and predictable latency. No MAC algorithm currently specified for WLAN has a predictable latency. Not even 802.11p which should have it as it is for automotive use.
Thus I think that a special MAC algorithm must be devised for the PRT use case. This is quite easy to do and does not need creating new hardware as the MAC algorithm is usually executed in software built into the WLAN chip's computer.
Dan the Blogger Responds-
Good points Bengt!
I really can't add much except I am looking into that and a number of similar ideas. I noticed you said WLAN. I was wondering if that would even be the appropriate protocol, or if a wired one could work. After all, Leaky Feeder seems to have aspects of both. I think there’s a lot less latency with the wired 802 flavors, especially if the network is arranged as small switched subnets. But I am just learning.
Post a Comment