The AirJaldi Mesh Router (AJMR) is built around a SBCs (Single Board Computers) which we extract from low-cost popular WiFi devices such as Linksys WRT54G . Most of the SBCs used, utilize a 200mhz MIPS CPU with 4Mb of Flash memory and 16Mb of RAM. However, we also use some lower-scale units and recently also developed more powerful units. The Netgear WGT634U appears to be most suitable for our application but it was recently discontinued. This small SBC draws less power then its bulkier cousins, features a MiniPCI slot for radio card, hosting a great Atheros b/g radio, double the flash and ram of the WRT54G and maybe the greatest feature of all is a USB2.0 port.
Most of the Mesh network is based around the AJMR. The SBCs are sealed in a low-profile, weather-proof enclosures which where designed in Dharamsala and are being fabricated in Delhi. The present enclosure is the 3rd version and is designed withstand the harsh Himalayan climate as well as the scorching heat of the plains. Manufacturing costs for the enclosures are just a bit over $10, for the small quantities which we make. This will decrease as higher volumes are produced.
--- Update: We now also use a "double hight" enclosures, which house two routers - to allow for simple multi-radio applications, such as relay stations or mostly for connecting a hotspot "back-to-back" with a mesh router.
The following hardware modifications/additions are made to the AJMR SBCs:
* Power supply integrated with a POE (Power Over Ethernet) injector, which allows for long-distance PoE feeds;
* Tolerant power-supply for wide-range input voltage 90-240v;
* Current-limited battery charger.
* Low-voltage disconnect (LVD), to prevent router hung if battery is depleted and to prolong battery life;
* Optional solar-powered battery chargers;
* Improved antenna feed system, to decrease RF transmission losses;
* Optional sensors for remote monitoring, graphing, and logging of temperature and voltage;
* Optional lightening surge protector for antenna feed;
* Optional lighting surge protectors for Ethernet feeds - (build in Dharamsala).
--- Update: We have begun a collaboration with the TIER research group , out of UC-Berkeley, head by Prof. Eric Brewer, on the development of advanced (yet low cost) solar-battery-charger. We expect to begin testing these new intelligent units before end of Q2/07.
The router's firmware (operating system) is a Dharamsala-brewed Linux clone, based on multiple open-source projects. Thanks to the amazing and promising development of the OpenWRT project, we now need very little additions of our own. The core of OpenWRT is based on UCLIBC and Busybox. With so many supporters and contributors, today one can find a very rich selection of pre-compiled packages and tools. This allows people on the ground to focus on local issues, while enjoying pre-tested and fully functional OS. Multiple Mesh routing protocols were tested and are supported optionally.
A locally tweaked OLSR had become the protocol of choice for the present mesh. Major development efforts are aimed towards prevention of wireless transmissions collisions a.k.a hidden node problem. At present an iptables queue is controlling transmissions based on an advanced token-passing protocol among the mesh members. This technique, while increasing latency, prevents radio collisions and therefore provides a network free of packet-loss even when radio links quality is very poor. The concept idea and much of the development efforts are coming from Frottle and the guys at Melbourne Wireless. While such a solution is essential for the scalability of WiFi based networks, the present implementation is extremely difficult to tune in Mesh environments, hence we where forced to give-up on it's use for most of our network. We feel that a complete re-write is called for, focusing on tight integration into OLSR, possibly an OLSR plugin. We hope to focus much of our future development efforts to produce a field-tested Mesh frottle solution.
Running later Linux Kernels (2.4.30 and also 2.6), the units supports all the advanced networking elements critical for deployment of such an advanced network:
* Full iptables stateful firewall, including all forms of NAT, traffic shaping, QoS management, packet tagging and even latest Layer-7 classifiers;
* Policy routing (iproute2) is included along with "tc" and multiple supported QoS queues;
* "tcpdump" packet sniffer for network debugging;
* ARP Tables for L2, MAC filtering and Linux-bridge for L2 bridging support;
* The unit support SNMP for remote management, NTP for maintaining accurate network-time (critical for encryption) and remote syslog host support, for concentrated logging.
Encryption is done using the on-board hardware accelerator, supporting 128bit WEP for wireless encryption. An optional OpenVPN package can be included, turning the unit into a military-grade VPN tunnel end-point. Since OpenVPN encryption can only be done in software, the unit cannot handle high-speed encrypted data. It is however sufficient for most low-speed (less then 2mbps) WAN applications. The units also provide DNS and DHCP servers, with support for multiple (up to 5) physical LANs (can be extended up to 256 LANs, using VLAN tagging and matching L2 switching devices). Fixed (MAC Based) and/or dynamic address allocation and optional PPPoE support can be used if interface to ADSL or similar line is needed. A shrink Asterisk VoIP software PBX can be installed on the unit, allowing support for a small number of IP-phones or ATAs.
Tight integration of telephony applications will be essential for future deployments in rural areas and developing countries. We hope to port the existing firmware to run on devices which include ATA (Analog Telephone Adapters) within the same SBC, to further reduce the overall cost of telephony systems deployments in rural areas. At present, all management is done using remote SSH access. No GUI is offered at this point. In general, all configuration and management of the unit is done using Unix command shell, and basic knowledge of Linux is needed to manage the device.
There is hardly any documentation at this point, and many future efforts should be focused on ease of management, configuration and control, along with in-depth technical documentation.