tag:blogger.com,1999:blog-4063450658421522356.post713385182289351179..comments2024-03-09T04:13:55.185-06:00Comments on Open PRT specification project: 104> Pondering InfraredDanhttp://www.blogger.com/profile/16303568401426087509noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-4063450658421522356.post-2258671103759995022010-10-20T23:52:18.721-05:002010-10-20T23:52:18.721-05:00Dan the Blogger Responds-
Good points Bengt!
I r...Dan the Blogger Responds- <br />Good points Bengt! <br />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.Danhttps://www.blogger.com/profile/16303568401426087509noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-23230364559988357742010-10-11T12:31:31.529-05:002010-10-11T12:31:31.529-05:00I would suggest that leaky cable would be very har...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).<br /><br />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.<br /><br />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.Bengt Gustafssonhttps://www.blogger.com/profile/09713334872197066961noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-90894286802516174472010-10-03T10:29:07.873-05:002010-10-03T10:29:07.873-05:00The concern with encryption is about integrity, no...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.<br /><br />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.Ryan Bakerhttps://www.blogger.com/profile/10358323841471401980noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-50271599864658126112010-10-03T03:34:20.381-05:002010-10-03T03:34:20.381-05:00Chronokun:
You're right. Eavesdropping is no...Chronokun: <br /><br />You're right. Eavesdropping is not really the concern (much). Access stealing can be made so hard it's not the main concern either.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />That's all.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-83008932760400647742010-10-03T00:53:34.580-05:002010-10-03T00:53:34.580-05:00just wondering what's with all the discussion ...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?Anonymoushttps://www.blogger.com/profile/01518049187596170410noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-433215153573040882010-10-02T13:39:30.303-05:002010-10-02T13:39:30.303-05:00I'm amused. The only real advance in computing...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.<br /><br />Upshot: don't worry about encryption. Just make sure an engineer doesn't design the protocol. They're really bad at it.Andrew Fnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-8349281509221099042010-10-02T12:51:07.555-05:002010-10-02T12:51:07.555-05:00Jamming is tough, but I'll come back to that.
...Jamming is tough, but I'll come back to that.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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).<br /><br />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.Ryan Bakerhttps://www.blogger.com/profile/10358323841471401980noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-72782958825593019312010-10-02T02:54:57.250-05:002010-10-02T02:54:57.250-05:00Ryan, you're right. I was a bit too vague in m...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.<br /><br />Let's just say I would strongly suggest NOT using WLAN in any PRT system. Ever.<br /><br />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. <br /><br />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?<br /><br />For the same reasons, I would not trust GPS either.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-6899642274294659072010-10-01T19:55:30.180-05:002010-10-01T19:55:30.180-05:00WLAN encryption is fairly good, assuming of course...WLAN encryption is fairly good, assuming of course that you're using something current, like WPA2 with AES, rather than WEP.<br /><br />Maybe you mean something other than encryption? Encryption is software. Hardware's only relevance to encryption is whether it can perform it fast enough.<br /><br />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 Bakerhttps://www.blogger.com/profile/10358323841471401980noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-38260290496453545822010-10-01T00:47:41.726-05:002010-10-01T00:47:41.726-05:00My primary candidate for the RF interface is two-w...My primary candidate for the RF interface is two-way "smart" RF-id chips. <br /><br /><a href="http://www.atmel.in/products/smartRF/default.asp?family_id=651&source=global_nav" rel="nofollow">something like this</a><br /><br />What they offer (and WLAN doesn't) is being designed for good encryption and more real-time usage.<br /><br />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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-88123255976715861792010-09-30T21:24:40.753-05:002010-09-30T21:24:40.753-05:00Yes, Chronokun, there is definitely a suitable sol...Yes, Chronokun, there is definitely a suitable solution out there already since there a many existing systems with far more stringent requirements.<br /><br />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.<br /><br />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.Ryan Bakerhttps://www.blogger.com/profile/10358323841471401980noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-59098293834343160502010-09-30T19:54:09.407-05:002010-09-30T19:54:09.407-05:00off the shelf doesn't necessarily mean 'co...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.Anonymoushttps://www.blogger.com/profile/01518049187596170410noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-13653221703890588372010-09-30T15:58:26.772-05:002010-09-30T15:58:26.772-05:00Dan The Blogger Responds -
Gentlemen, I basically...Dan The Blogger Responds - <br />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.Danhttps://www.blogger.com/profile/16303568401426087509noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-84565534618761734142010-09-30T14:17:41.440-05:002010-09-30T14:17:41.440-05:00I would basically ignore all specifications relati...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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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).<br /><br />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.Ryan Bakerhttps://www.blogger.com/profile/10358323841471401980noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-11208592561822118032010-09-30T05:34:17.789-05:002010-09-30T05:34:17.789-05:00seems like some reasonable ideas though using a se...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.Anonymoushttps://www.blogger.com/profile/01518049187596170410noreply@blogger.com