Sponsored By
Efika 5200B Project
Disaster Relief Network Infrastructure (ad-hoc wireless mesh deployment)in category Other
proposed by luvdownbabylon on 8th February 2006 (accepted on 11th February 2006)
Project Summary
This project idea is largely inspired by the efforts of many techie-types in the aftermath of Hurricane Katrina who helped create communications infrastructure for the shelters and emergency response folks largely out of what equipment was at hand or donated. Much can be learned from their experience, and many good things are already developing as a result of said experience. This project should fit nicely into the evolving ecosystem here.One main thing is that it took knowledgable, skilled people to make the miracles after Katrina et al happen. As a result, there are things such as bootable GNU/Linux \"Live CDs\" being devloped that can take advantage of hardware detection to self-configure and use what hardware is at hand and tie it into a disaster-recovery network infrastructure. The notion is that it should be made as easy as possible to replicate a disaster recovery network next time it is needed with as little fuss as possible.
This helps. But even with hardware detection, using random equipment will mean that there will be many edge cases that will require \"fine tuning\" to make them fit, if they can be fit into the disaster recovery network. Thus having an expert in the field, or more likely \"on the gound\" becomes necessary to handle the edge cases.
The EFIKA platform has the potential to be developed into a low-cost reference hardware implementation of such a disaster recovery network model that is largely self-configuring and requires minimal on-site expertise.
It will benefit existing efforts developing the model disaster recovery network infrastructure to have one (or more) reference hardware implementations that were ready to go \"out of the box\" as \"plug and play\" components.
Relief Agencies, other NGOs, and Govornments at all levels may be interested in \"off the shelf\" hardware systems that implemented a reference disaster recovery networking infrastructure. Especially a truly open and non-proprietary model, which would guarantee interoperability between the \"branded\" solution and components from other vendors, or scavenged and re-purposed equipment that follows the same network model. Supporting an open-source, community-led design will be an especially attractive feature for any product offerings in this arena. Interoperability is a must for such a system to be effective.
EFIKA is a versatile and capable enough platform to support solutions for the three main components of such an infrastructure:
The first major component is a long-range Wireless MESH router to create the ad-hoc back-haul network that gets the coverage out where it is needed. EFIKA-based units with appropriate radios in weatherproof housings would serve this role. Flexible power options that included solar or generated power would be appropriate. In a minimal implementation, this would be the only type of unit deployed, and each would serve as a base station for communications to the outside world.
The second major component would be a kiosk or workstation unit to network in to these \"base stations\". In practice this role is the one that is best fit by \"avialable hardware\" running Live CDs that give a kiosk environment for web browsing and other basic communications, such as VoIP telephony. It is reasonable to equip an EFIKA based unit with at least dual video for use as a dual-head, two-seat workstation utilizing USB mice and keyboards, for instance. The main purpose of this type of unit is for public access to email, people-finder, and disaster relief services available through web interfaces. So hardware requirements here are fairly thin-clientish.
The third major component would be a site-server type role. A site-server would be the most variable in application. Essential fucntion would be to support site management of the local network, and applications, such as Asterisk for telephony. A suggested base implementation would include broadly compatible WiFi (802.11a/b/g) to provide a WAP service on the ground. (WiMax up the pole for backbone on the router units; WiFi, Ethernet, USB, and perhaps Bluetooth connectivity on the ground via the site-servers.)
Site-server units could also be developed to support specialized applications. They may be used as servers for applications supporting police, fire and rescue co-ordination and communications, on-site relief effort logistics, telephony (such as an Asterisk server, as mentioned earlier), and so on. Ideally most of these would be on an identical hardware configuration taking on different roles.
Development of an EFIKA based implementation of such a network along these lines will have benefits outiside the scope of the project. The ad-hoc MESH routers could also be used for any other similar networking needs. They could be used in municipal or private wireless broadband systems, for instance. The Site-servers, combined with the workstation-kiosk units could be deployed in schools or other computer labs. Perhaps there could be more substantial offerings based on the ODW and OSW products that can fit into this \'ecosystem\'. Suppose an OSW acting as a powerful site-server sporting a LTSP-style thin client environment. Now you have a product offering that can readily cross-polinate into a computer lab or call center environment.
Any number of permutations are possible, as the core components can be easily used to support similar networks for other purposes. Perhaps divergent mainly in application more so than structure, as it is an infrastructure that supports a rather generic platform to build on.
Peace.
Project Blog Entries
Sorry I have been very busy and have not had time to update the blog, but I have been doing much research for the project. I have been reading gobs and gobs on the OLSR routing protocol implementations, and have decided to write some of the folks at freifunk.net in Germany, funkfreuer.at in Austria, and the olsr-users mailing list (olsr.org) about my project. OLSR apparently works but does not scale well at all. The freifunk folks have been hacking on it, extending it, and have even come up with the B.A.T.M.A.N. (better approach to mobile ad-hoc networking) protocol. The have this interesting article entitled "The OLSR story". Well the people at funkfreuer.at have this page detailing OLSR-NG development, apparently taking in the lessons from the freifunk and funkfreuer MESH communities, including the olsrd extensions done by freifunk and the b.a.t.m.a.n. protocol. OLSR-NG seems to be the protocol I am looking for. Yet, I have many questions. And, of course, I am very interested in auto-config extensions. Plug and Play is foremost in my mind with every aspect of this project. No time to read the friendly manual when there are lives to save.
Besides protocol research, I have also been looking into options for some of the application components that will be needed. As I mentioned in my OSW Project Proposal, an important part of the Disaster Relief Network will be applications for logistics, finding missing people, communications and coordination, etc. To be honest, I figured that much of this would have to be home-spun, and I was planning to delve into a massive review process of the available CMS systems and web application frameworks. Guess what?!?! Someone else has already been tackling this problem, and it is open source!!! How cool is that?!?! Well I stumbled onto the Sahana FOSS Disaster Management System. (Here is their Wikipedia entry, too). This is just so perfect! Not only is it Open Source, but it is Web-based as well!!! This is exactly the sort of application suite I was envisioning! Man I love Open Source. Soon I will be installing Sahana on my machine to check it out. It is quite simple to do, as it only requires Apache, MySQL, and PHP. Sweet!! Just as this project was inspired by work done in the aftermath of Hurricane Katrina, the SAHANA project was inspired by the Tsunami in Sri Lanka. And you can bet, any additions or ideas I have beyond the fantastic work SAHANA have already done will be given back to them and coordinated with them. Just as no man is an island, well, no FOSS Project is an island either! And, of course, I am practically giddy over the serendipitous synchronisity between our projects. I hope they like what I am intending to do with my modest little EFIKA project. Some questions I will have for them are infrastructure related. I want to be able to empower different shelters/camps to set up their own services even before the mesh is fully deployed, and later migrate them to centralized servers. I have not even installed it yet and already I have so many questions! Needless to say I am excited about this find!
Okay, well, no more time just now but I will try to keep up with more frequent updates as I have them.
PEACE!!
Tim
Well my project got off to a rocky start after some delays, but I am proud to report that our little EFIKA is alive!
Though limited on resources I have managed to invest in some added hardware for the project. The EFIKA is now equipped with a 40Gb hard disk, keyboard, mouse, and video card. There are a couple different pieces to this project, the first being the back-haul router. In final form I don't see a need for a display on that, and would likely use a compact flash drive as opposed to a hard disk. But that is the first component I am developing in the mix. Once I have some progress there, I will probably put in to the XGI Volari program as another piece of the puzzle will be, basically, an internet kiosk. I would expect the EFIKA can support two stations with dual video and dual kbd/mice via either a USB hub or a keyboard that has another USB port like the Macs have. I have a bit of work to do before I approach that aspect, though, and there are others who are doing LTSP-type EFIKA projects already that I can probably consult with when the time comes.
In the past few weeks I have learned a few things. Not having a handy USB memory stick nor a serial cable, I decided to net-boot the EFIKA in order to get an operating system installed on the hard drive. Configuring a second ethernet port, setting up IP masquerading (NAT), and running a DHCP server on my Linux desktop was not new for me. But getting a TFTP server to service my second interface proved to be a challenge. Eventually I threw in the towel and configured the EFIKA with static addresses and attached it to my regular LAN.
Next I learned that when you enable diag-mode? in the EFIKA's Open Firmware, it does not ask for the same file over tftp as it does when diag-mode? is set to false. It uses the value in the diag-file variable, I believe (it is not in front of me as I write this). I was pulling my hair out over this, even to the point of using WireShark to sniff the packets coming in to my Linux box. But at last I realized what was going on. This Open Firmware is neat but it is new territory for me. After I got the EFIKA to start requesting the correct file, I could not get it to completely boot. The video card I had been using is an nVida model. I had heard that the ATi cards worked better with the EFIKA, but I was not thinking that it made a difference in text mode. I figured it was an issue with graphics support. I was wrong. Luckily I have an ATi Radeon 9800 Pro in my Linux desktop so I was able to swap it out. Then fate had another curve ball as the di_efika debian installer image I downloaded off of the blpan site was corrupt. Thank you, bplan, for putting the md5 hashes on your site! I should have checked those in the first place, I know... :)
So now I have the Debian installer working on my EFIKA and am in the process of getting the base operating system install. I will probably go with dropbear for ssh access over the wire, and I will set about trimming down the installed environment. I may not stick with Debian but for now it is the environment I am most comfortable in. And with the 40Gb hard drive I have room to play while I get my ducks in order. If I can get a cross-compiling environment set up in Ubuntu on my x86 desktop I will see about building a Gentoo system for the EFIKA. I have a feeling it will benefit from a source distro, though it may be that the Debian packages work well enough. If nothing else it is an excuse to dive into Gentoo.
For Mesh Network routing I am primarily looking at implementing Optimized Link State Routing protocol (RFC3626). But there are a few others out there including some interesting ideas involving fractal math to manage the routes. I will of course check all avenues but it seems OLSR is my leading candidate. It is developed with mobility in mind, which may or may not come in to play in one of our deployments. But it seems very flexible and adaptive as opposed to reactive protocols. I still have a little time and research before committing.
Routing across a Mesh is one thing, and being done by plenty of folks. But the goal here is a truly plug-and-go self-configuring network. At most I would like the folks who eventually have to deploy these things in a disaster zone to have to configure a network name and have all the mesh nodes with the same name find each other and work out their IP scheme on their own. Having a mesh back-haul is not the goal in and of itself... I can see many scenarios where there is no true mesh, but rather a chain of back-haul nodes back to an up-link site (where there is internet access). The real key here is minimal user configuration. Emergency workers have enough to deal with besides becoming instant computer networking techs. I will be doing some research here to see what similar work being done. But if it comes to it I am prepared to roll my own from scratch. Well, not completely from scratch... My ideas would involve a mutation of a DCHP client and server into more of a cooperative peer daemon that is aware of the evolving topology. Which routing protocol I use will of course have a big impact on configuration.
I have enough to keep me busy for the moment, building and researching. Once I start experimenting with OLSR I may have to get real creative. Firstly, I have no radios in my EFIKA. Nor can I really afford to add more hardware at this time. But even if I had the cash it is not really feasible to test a mesh with just one unit. I am probably going to play with virtual machines on my desktop to do some simulations. When it comes time to pick radios, I will probably have to hold my hand out. So I would like to get as much of the system as possible operating in simulation first before begging someone to feed my project. If you are interested to know, though, I have been drooling over this sub-$100 miniPCI module. It even looks like Freescale is also involved with Wavesat's WiMAX designs. I would like to get a PCI-to-miniPCI adapter card, probably one of these from routerboard.com. Or something very simlilar that supports two miniPCI modules, as I intend to run two radios on each back-haul node. Which modules to use of course will come after more research. Those links are just my preliminary finds.
Well that is all to report for right now. Now that we can update our blogs again I hope to keep some regular updates.
Peace!
Tim
Sorry it seems my entry got posted twice. No need for you all to read it twice so I've edited one copy out. :)
Well today I got an email notice that Gensesi is shipping me something! That's the good part. Bad part is I just moved and had not updated my address... but after a couple frantic e-mails, it looks like the good folks there are going to help rectify that.
So after many months it looks like this project will be coming together after all! HURRAY! This should be a lot of fun!
Tim