$Id$ 1. Sector of Interest, Application Category, & General Project Information: Sector of Interest: Independent News Media Application Category: Collaboration Name of Organization: Urbana-Champaign Independent Media Center Name of Project: Community Wireless Network . Phase III Name & Title of Head of Organization: Sascha Meinrath, Project Manager Name & Title of Technical Coordinator: David Young, Technical Lead Address: 218 West Main Street, Suite 110 Urbana, IL 61801 USA Telephone: (217) 278-3933 Fax: (217) 278-7171 Email: cwn@cuwireless.net Website: www.cuwireless.net Program at OSI: ICT Toolsets Amount Requested from OSI: $200,000 Length of Project: 12 Months 2. Abstract/Overview: The Community Wireless Network (CWN) is building a next-generation communications Network that allows people to share bandwidth, publish media, and disseminate information by creating mesh-style, ad-hoc wireless networks throughout a geographical area (e.g., neighborhoods, communities, towns) using off-the-shelf wireless hardware. The CWN utilizes open-source software and open-architecture hardware developed in-house over the past three years. The CWN has researched possible solutions and programmed the initial software (Phase I) and implemented two proof-of-concept Network prototypes (Phase II). The CWN development team is currently seeking funding for Phase III of the project---refining the software to improve/include routing, a web-interface, online upgrading of wireless nodes, kernel development, route visualization, name service, and community web resources; and, building both a large-scale, in-vivo test-bed Community Wireless Network, and 2-3 international implementations of small-scale networks as a proof-of-concept test of the software and hardware's scalability and utility. The four-part mission the CWN project is to: 1. provide wireless Internet connectivity to Network users; 2. develop software and hardware for use by other wireless projects throughout the United States and abroad; 3. disseminate open-source software and hardware specs to interested people and organizations; and, 4. build and support sustainable, not-for-profit communications networks in communities throughout the world. 3. Detailed Description: A. Overview The Champaign-Urbana Community Wireless Network (CWN) is building and implementing a mesh-style Community Wireless Network that allows anyone within range of the Network to get on-line, free from monthly fees, using off-the-shelf wireless hardware. CWN's software is open-source (under the GPL license) and open-architecture. The four main goals of this project are: 1. provide wireless Internet connectivity to Network users; 2. develop software and hardware for use by other wireless projects throughout the United States and abroad; 3. disseminate software and hardware specs to interested non-profit and community organizations; and, 4. build and support sustainable, non-hierarchical, and not-for-profit community networks in communities throughout the world. The Community Wireless Network is a program of the Urbana-Champaign Independent Media Center Foundation (IMC), a federally recognized non-profit organization, and has supported itself through donations from participants, foundational grants, and institutional support. The Community Wireless Network is composed of a consortium of researchers, programmers, community activists, non-profit organizations, for-profit businesses, and educational institutions. Currently, over 130 people from around the globe actively monitor the developers e-mail list. Software already developed by the CWN team has been integrated into the NetBSD operating system, CWN programmers have created multiple drivers for wireless cards, and developers are downloading the network software to locations both locally and across the country. Finally, the hardware developed by the CWN is being utilized by multiple wireless projects. Since its inception, the CWN has grown to become one of the leading sources for information, software, and hardware for building community wireless networks and was recently granted control over the wireless domain and project of SourceForge.net (SourceForge is the world's largest open source software development website). Over the past three years, the Community Wireless Network has gone through three distinct phases of development: Phase I: initial research and experimentation; Phase II: initial software development and prototype network rollout; Phase III: software refinement and scalable network implementation (the current phase). B. Rationale & Background Networks like the Internet are essentially indifferent to the applications used over their infrastructure (i.e., they are a relatively neutral medium) and are more easily and quickly adapted to meet the new communication needs of humans than networks that are tailored to a particular application. For example, one can compare the myriad uses for the IP protocol---WWW, e-mail, chat, radio, video, file sharing---to the uses for a typical telephone service. Much as the Internet has transformed long-distance communication though e-mail and other applications, it can also transform local communication, making it faster, less expensive, more versatile, and more accessible. In addition, local networking can provide fairer access to the global communications infrastructure. For example, the flat pricing structures for the typical commercial "1-payer-per-line" DSL and cable business models, where low- and average-use customers are subsidizing bandwidth hogs, effectively places broadband out of reach for low-income households. At the same time, the Internet is becoming more and more geared to high-speed users. The Community Wireless Network breaks down this barrier and helps close this digital divide by making Internet access available throughout a community and sharing the cost (and economies of scale of larger bandwidth purchasing) among multiple users. Thus, this infrastructure has applicability both within local ("first-world") towns and cities as well as in communities throughout the world. "Rooftop networking" (creating a communications infrastructure among buildings) is an important part of local wireless networks for reasons of cost and scalability. Access to telephone companies. "local loops" are prohibitively costly, and these same companies resist sharing their resources with community organizations, even where the law provides for or mandates competitive access. In addition, building new wire/fiber infrastructure is enormously expensive---for example, crossing a single street with wire or fiber can often cost thousands of dollars. Rooftop networking avoids both the phone company and wire/fiber costs. The CWN functions by creating a communications "mesh" (much like a net or spider web) whereby each wireless "node" (a wireless router/antenna combo) communicates with one or more other wireless nodes to create a fully functioning Local Area Network and community intranet. The self-configuring nature of CWN's wireless rooftop networking software saves much of the cost of planning, building, and maintaining communications networks and allows networks to develop organically and ad-hoc. In other words, the software allows any potential end-user of the CWN can join the network as long as they are within range of another wireless node. The software is user-friendly, requiring only that a user place a CD with the software in a designated computer and turn the computer on---the software automatically scans for other wireless nodes, sets up routing between itself and the rest of the Network, and assimilates itself into a newly expanded Network. Currently, the Community Wireless Network is one of the only systems in the world that is capable of growing organically as new nodes come on-line. Furthermore, because bandwidth is shared across the network and there is no centralized "mission-critical" point of failure, the CWN is far more robust than most wireless Internet systems. Finally, as more nodes come on-line (and thus, multiple pathways exist for shuttling data between computers), the Network becomes capable of "healing" itself (e.g., if a node goes off-line, the Network will search for ways to route packets via a different path to the end user). This interconnected mesh of nodes is one of the defining characteristics of CWN and is made possible by the software that CWN has developed. Once the network grows to a few dozen nodes and a community contains multiple Community Wireless Network "seeds", the network can grow at low cost, "hop-by-hop," at the cost of new nodes. Since installation of new nodes is uncomplicated (being no more difficult than setting up an outdoor TV antenna), and since nodes will get cheaper and cheaper as the technology matures, it becomes more and more difficult for any one corporation to assert their control over the network and increasingly easy for additional people and organizations to join. Telephone and cable companies have been resistant to community-wide networks using their networks, preferring to charge each household individually for broadband Internet connectivity. With the consolidation of media-producing and media-delivering companies (e.g., Time-Warner Cable and SBC/Yahoo DSL), community-area networking increasingly does not fit these companies' existing business models. Community-area networking is to cable/DSL as low-power FM radio is to the National Association of Broadcasters---grassroots owned and operated, cost-effective, and diverse competition that undermines the continuing conglomerization and monopolization of our public airwaves. CWN has created one of the first fully-operational community owned and operated wireless networks and plans to introduce additional community services (e.g. web hosting, e-mail accounts, etc.) as the network is developed and as funding becomes available. C. Phase I: Initial Organizing, Research, and Software Design In Spring 2000, a group of software programmers, radio techies, system administrators, and community activists began discussing ways to set up a community-owned and operated wireless Internet network. These informal discussions continued to gain steam and within a year regular working meetings were being held, an e-mail developers forum had been set up, and research into community networking initiatives and various technical problems was being divvied up and reported back to the group. In addition, the group began experimenting with building various antennas, different hardware configurations, recruiting contacts for possible node deployment sites, and laying out the groundwork for building the initial software to run the system. Though Fall 2002 the CWN development team programmed two different software forks (one Linux-based and the other NetBSD-based), built multiple hardware platforms for the wireless nodes, reported bugs in existing wireless card firmware, tested computer interactions utilizing different architectures, and collected additional information and feedback about these experiments. On November 18, 2002 the first multi-hop bandwidth-sharing wireless cloud went operational---allowing, for the first time, end users to access the Internet connection of the IMC from houses located a half-kilometer away. D. Phase II The second phase of the Community Wireless Network development consisted of deploying additional nodes in the community and patching the software to deal with real-world conditions (e.g., transient connections, interference, radio driver incompatibilities). This initial deployment brought our first major local press coverage and created opportunities for many new stakeholders to partner with the project (see section 9). The CWN development team also quickly realized that in order to scale up the system, major changes to the software would have to be made. In the Summer 2003 the CWN received an exploratory grant from the Threshold Foundation to buy additional equipment and test the network as a proof of concept for deployment in Africa. From this time to the present, the CWN development team has been building a new generation of hardware---chosen for its durability (the nodes are solid state with no moving parts), price, and suitability for this application. This exploratory grant has allowed the CWN to double the number of nodes in the project. These nodes will be fully deployed by Spring 2004. Since receiving the Threshold Foundation's exploratory grant, the CWN development team has been in contact with organizations in South and Central America, India, Africa, the Southeast Asia, the Middle East, and Eastern Europe. Following the successful completion of Phase III, the CWN development team hopes to deploy CWN software and hardware to many of these contacts. As of Fall 2003, the Community Wireless Network is composed of two wireless "clouds" (areas of wireless connectivity composed of at least 2 interconnected wireless nodes): the first cloud has 5 nodes, is roughly oval shaped, and spans a half-kilometer area; the second is composed of three nodes in a roughly triangular shape spanning several hundred meters. Both clouds will be expanded using Threshold Foundation funding but are also awaiting further funding to add nodes at nearby residences (already there is a sizable waiting list). Eventually, once both wireless areas grow, these two clouds will merge to create a single trans-neighborhood, interconnected wireless area. Even with the current Network, the CWN is already facing "growing pains"---to build a large-scale wireless network while avoiding the maintenance and administration overheads that typify projects with computers and networking, the Community Wireless Network must develop new software that enables rooftop network routing. The software must contain facilities for experimentation and new development (upgrades on-line)---currently the CWN developers have to physically reinstall new software upgrades at each wireless node (which are often located on rooftops of buildings or houses). In addition, the software must present a usable interface to network subscribers (web interface) so that end users can more easily configure their home networks. To help with infrastructure maintenance and Network testing, route visualization will need to be added. To support information dissemination and publishing of text, radio, and video produced in the home, the Community Wireless Network will put subscribers in control of their "address" on the community network with an innovative "name service"---an innovation that allows both Internet access as well as information dissemination and web-publishing from any point on the Community Wireless Network. Furthermore, CWN programmers have identified two areas where the NetBSD kernel itself will need to be patched. Finally, to increase the utility to the community and speed the implementation of new nodes, the CWN developers will maintain a POP e-mail and community Web space on a server. 4. Description of Technology Involved: The Community Wireless Network is a fully operational community Intranet---allowing information dissemination and web publishing (of text, audio, video, etc.) from any point within range of the Network. The CWN software and hardware create a mesh-style infrastructure that grows organically as new nodes are set up within range of the pre-existing Network. Below are detailed descriptions of the seven development areas for the CWN (budgets and minimum time estimates for each component are available under the budget/timeline section). A. Routing To sustain the scalability of its infrastructure, Community Wireless Network needs software that implements an uncomplicated, extensible routing protocol that will support a network of hundreds of nodes, and a routing path metric that "prefers" reliable, high-capacity routes to spotty, low-capacity routes. Based on a review of the wireless networking literature, BBN Technologies' Hazy Sighted Link State (HSLS) routing algorithm will support growth to thousands of nodes, which will more than meet our requirements. HSLS also admits a parsimonious implementation that will be far easier for a grassroots project to debug and extend than more complicated algorithms whose scalability is comparatively poor. The Expected Transmission Count (ETX) path metric is a simple, proven routing path metric that favors high-capacity, reliable links. The Community Wireless Network will develop a UNIX routing daemon implementing HSLS and ETX. The major functional units of the daemon are described below. CWN will leverage existing open source software whenever that is possible. For example, the Zebra routing software suite will provide our Routing Information Base (RIB) and kernel abstraction. Because we will re-use Zebra, we will save tens of hours of development and debugging, we will gain some inter-operating system portability (*BSD, Linux, Solaris), and we will have the capability to extend our HSLS daemon to share routes with other routing protocols (BGP, OSPF, and RIP) in the future. Zebra library All communication with Zebra is through a socket. CWN will program a library for assembling and disassembling messages exchanged with Zebra through a socket. Socket-Server Library The architecture of the HSLS/ETX daemon will be a single-threaded socket server with a timer/task queue: timers will trigger link-state advertisements, change of socket condition will signal reception of "hello" packets and link-state updates, and a task will run Dijkstra's shortest path first algorithm. CWN will program and test a socket server library to support timers, tasks, and sockets. Shortest Path First Library As a link-state protocol, HSLS uses Dijkstra's Shortest Path First algorithm to find "least cost" paths on the network. CWN will program a shortest-path library. HSLS Packet Library CWN will produce a packet format for HSLS Hello messages and link-state update messages, and program a subroutine library for transforming records in the link-state database to and from packets. The HSLS packet format will support application-specific options to facilitate communication between sub-modules of the HSLS daemon, for example, the module that computes routing metrics using ETX (see ETX Module, below). HSLS Configuration Loader An operator will use a configuration file to tell the HSLS daemon that interfaces to operate on and to tell interface IP addresses, the link-state update transmission interval, etc. The daemon will load the configuration file when it first starts and whenever it receives a HUP signal. CWN will write a parser for simple configuration files. HSLS "Air Interface" An HSLS daemon will communicate with HSLS daemons on remote hosts using a combination of IP broadcast packets (for Hellos) and IP unicast packets (for reliable flooding of link-state updates). The HSLS "air interface" hides from the HSLS logic how Hellos and link-state updates are transmitted. CWN will program the first air interface in terms of BSD's raw IP sockets. A Linux port will be trivial, and in future work, the air interface can be adapted to use the network APIs in Windows and PalmOS. HSLS Module CWN will program the logic for processing and generating link-state updates, for processing and receiving Hellos, for link-state expiration, triggering SPF calculations, etc. The HSLS Module's API will contain methods for injecting a link-state update (LSU) into the Module, for setting callbacks for LSU-transmission and for kernel-route injection, and for setting/getting link costs. ETX Module The Estimated Transmission Count (ETX) routing metric is found out from the proportion of beacons sent but not received in both directions on a wireless link. CWN will program a module that counts the HSLS Hello packets sent and received in both directions on each link. Designs are not set, but the module will probably be a layer between the HSLS Module and the HSLS Packet Library that implements the latter's interface. HSLS Packet Options will transport ETX metrics from host to host. Tcpdump enhancement for HSLS For debugging, it will be necessary to examine HSLS packets "on the air." CWN will extend tcpdump, a popular open-source tool for examining network packets, with an HSLS packet-disassembler. B. Web Interface Some of CWN's subscribers have wireless networks in their living room. Subscribers do not usually distinguish problems with their home wireless network from problems with CWN's network. It will help save CWN volunteers from making "service calls," and it will protect the CWN Network's reputation, if a user can visit a web page hosted on their wireless node to find out the status of their home network and the CWN Network. CWN will add a small web server to its software distribution which provides a home-network bandwidth test and status information for the CWN Network. This task has three components: 1. write the script for thttpd (Tiny HTTP server) installation and configuration; 2. research existing Web bandwidth testers and produce a compact one for the station boot CD-ROM/CompactFlash; and, 3. write a CGI script which downloads the link-state database from the HSLS daemon and displays available routes from the rooftop router to the Internet and to each rooftop router in the network. Display the "strength" of each link as found by ETX. C. Upgrades On-line There are privacy and life-safety issues with climbing subscribers' roofs to upgrade software. It is possible to upgrade software on nodes over the CWN Network, but the process is difficult because of the small amount of free space on the nodes' CompactFlash cards, and risky because of the chance a botched software upgrade will turn a node to a doorstop (or, more appropriately, a weathervane) until a volunteer can climb a subscriber's roof to replace the CompactFlash card (which has the aforementioned privacy and life-safety issues). CWN will modify its standard software distribution, reserving space on nodes' CompactFlash cards to "stage" software updates, modifying the boot loader to allow "rollback" to the "last good" software version, and writing a script that will install and verify software updates in the staging area, set a "watchdog" timer, and reboot. This task has three parts: 1. trim the CWN software to 32MB so that the "last-good" and "raw" version will both fit on a single 64MB flash; 2. adapt the NetBSD bootloader or GRUB bootloader to do "rollback" to the last-good software; and, 3. write the script to install a software update, set the watchdog timer, and reboot D. Kernel Development The ARP table and routing table were unified in NetBSD. This complicates neighbor discovery and routing in wireless networks. It will be necessary for CWN to adapt the RADIX_MPATH patches from KAME.net to solve the problem. This task has two parts: 1. integrate RADIX_MPATH patches; and, 2. modify RADIX_MPATH patches to always select remote ("gateway") routes before local ("directly-connected") routes to the same destination E. Name Service If CWN's network nodes will be useful even when Internet connections are not present, they need to provide a name service. Also, if members of a rooftop network will be able to advertise their personal web servers and such to each other without the intervention of a central name authority, they need to be able to provide their own name service. CWN sees glimmers of a non-central name authority in the IETF Zeroconf (Apple Rendezvous) initiative, which is producing standards for name-based access to services such as storage, printing, and chat on home and office LANs. CWN wants to take this technology to the next level by extending it from the LAN to the rooftop community-area network. CWN will write a UNIX daemon for the rooftop routers which re-advertises IETF Zeroconf services (e.g., printing, storage, and chat) across the whole network in a secure way. The station owner will control which services are advertised and which are not using a Web interface. The daemon will protect against name collisions, protect against spoofing and denial of service, and handle network merges. CWN will demonstrate peer-to-peer chat, file sharing, and Web serving over the rooftop network. This task has five parts: 1. design and programming of a web interface which lets the rooftop network subscriber choose services to advertise to the community and to the Internet; 2. find and study the best available Zeroconf and DNS libraries for use in the rooftop name service; 3. write a subroutine library for filtering DNS name queries traveling in both directions through a rooftop router based on pass/stop rules; 4. program a flood-relay function for DNS queries sent over the rooftop network; and, 5. re-advertise rooftop names on the Internet by acting as "master" for an Internet name server. F. Route Visualization CWN finds that for most people, the mere mention of wireless conjures up ideas of ubiquity and mobility---i.e., cellular phones, FM radio, and television. Rooftop networking works by using short-distance radio links, and in this way it is foreign to people whose expectations are set by TV, cellular, and radio. It is important for CWN subscribers and funding agencies to understand the rooftop networking concept. A map overlaid with a diagram of connections between nodes on a running CWN Network is a useful tool for educating both the community and funding agencies about CWN's accomplishments and plans. It is also a valuable network diagnostic tool, since it can show a CWN volunteer the presence and strength or abscence of network links "at a glance." This task consists of two parts: 1. build a user interface; and, 2. program a node "back-end" to provide link database to the user interface 5. Description of User Group, Expected Locations, and Use Scenarios: Currently, about 20 people in private residences use the CWN regularly. In the future, the CWN will have a projected 200- to 300-user clientele, not including public access computers belonging to the Network. The CWN users come from all racial and socio-economic backgrounds and are of all ages. They are both male and female. They have varying levels of education, degrees of technical expertise and have many different areas of interest. The Network is used for professional, educational, and recreational purposes. To become part of the CWN right now, a user must meet the following criteria: 1. be a homeowner or long-term renter (or have an agreement with the owner of the home); 2. own a computer (free personal computers are available through an arrangement with Community Networking Initiative); and, 3. ability to pay for the rooftop router is preferred. In the future, the CWN would like to see a sliding-scale equipment fee, thus providing access to low-income households. CWN envisions several uses for the network. For example, CWN developers hope to provide public Internet access at the Don Moyer Boys and Girls Club, which is a youth-oriented social service agency, located in the heart of the area's African American and migrant worker communities. More generally, CWN anticipates that its rooftop network software will be used by persons who: 1. have a social or political message but no access to traditional broadcast media such as radio, television, or newspapers; 2. cannot afford broadband at the prices charged by conventional, monopoly-owned media (DSL, cable) or whose broadband needs fall short of or exceed the broadband plans they can buy; and, 3. have created a neighborhood Internet co-op. Suitable locations for application of the CUW software include 1. rural communities where wireless is the most cost-effective way to bring broadband to homes and businesses; 2. areas lacking a communications infrastructure; and, 3. communities whose governments have built a municipal broadband network using wireless technology. Uses for the software include e-mail and web browsing but also self-publishing of news, research, and opinion on the web using one's own PC as web server, IP radio broadcast to the community (with no more sophisticated broadcast equipment than what is ordinarily built into PCs), community calendars and bulletin boards. 6. Description of Civil Society Application for the Project: CWN anticipates three major civil-society applications for our rooftop network technology in civil society. First, rooftop networks will turn more media-consumers into media-makers. Second, a rooftop network will provide a valuable intra-community communications tool whether or not it is connected to the Internet. Third, rooftop networks will help to bridge the digital divide throughout the world. The technology used in today's Internet services only provides for a narrow range of Internet applications. The home's connection to the Internet is geared toward high-speed downloads but far, far slower uploads. Static IP numbers and Domain Name Service are either unavailable or expensive. User agreements with many providers prohibit the user from running any servers. In many ways, the broadband services for sale now are geared toward media consumption instead of media production. Thus, while independent production of electronic media (text, audio, photos, video) is possible using today's $500 personal computer, which has ample production capabilities with its 1GHz processor and 80 gigabyte hard drive (in fact, almost any computer of Pentium class or better can easily be utilized for multi-media production), self-publishing is out of reach: owners of web servers remain the gateways to the Web, and they charge monthly fees for such paltry amounts of web storage that even publishing a substantial family photo album is prohibitively expensive. Rooftop networks provide the opportunity for the equal upload and download speeds that the cable and telephone companies are reluctant to provide. A municipality or neighborhood Internet co-op can purchase an IP number block for its rooftop network and assign static IPs to every rooftop router. The ad-hoc name service we propose to develop will let users put a name to their IP number without a system administrator's intervention. Thus, rooftop networks will empower the home media-producer to distribute his or her product by bringing the full power of broadband to their increasingly powerful personal computer. Following the consolidation of media ownership into fewer and fewer national and international hands, and the subsequent decline in local media focus and access in the United States and elsewhere, part of rooftop networks. importance is that they provide a community-owned multimedia communications infrastructure to supplement (or even replace) local TV and radio. With or without a connection to the Internet, a rooftop network will connect a community in a way that DSL and cable modems do not: there are recurring access fees for any amount of DSL or cable service, but once the equipment for a rooftop network is paid for, it provides a broadband intra-community communications network for no cost (i.e., the community could decide whether to pay the cost to connect their network to the outside Internet). Given the lack of communications infrastructure through much of the third world, rooftop networks will be extremely valuable community assets. One real-world example is that wireless equipment similar to what CWN uses has provided telephone service to remote villages in Costa Rica and Vietnam. Rooftop networking will help lessen the "digital divide" between rich and poor in the United States as well as around the world. A rooftop network can be installed anywhere there is electricity (the development of solar- or people-powered equipment is beyond the scope of this application) to enable a community to purchase, share, and divide the cost of a broadband Internet connection such as a DSL or T1. Also, with a rooftop network, it is possible to offer price structures that serve the diverse budgets and bandwidth needs of all members of a community, instead of every single person subsidizing the "bandwidth hogs," as they do under the flat-rate structures. Municipal rooftop networks can choose to provide citizens with bandwidth under any number of progressive schemes. By making broadband available to the poor, providing a local broadband communications infrastructure, and making broadband a tool for independent media-makers, rooftop networks serve civil society. Finally, building this well-documented and thoroughly tested software will allow wireless network developers to more easily build on the CWN project software, adding additional functionality and creating new application within the open source community. Thus, this project will spawn scores of additional endeavors across the globe benefiting civil society far beyond the immediate scope of this phase of development. 7. Description of Team: The core Community Wireless Network development team members are all currently employed as professional software developers and/or system administrators. Team members have committed to taking a sabbatical from their employment to develop this software and build a prototype of a larger scale Network. The CWN is a research and development project as well as a hi-tech prototype for building the next generation in communications infrastructure. Thus, the core project team consists of individuals with both a research and technological background. Sascha Meinrath, Project Manager: Sascha is from New Haven, CT and holds triple citizenship with the United States, Germany, and Brazil. He received his undergraduate degree in Psychology from Yale University and is now finishing both his Masters is Psychology and his Doctorate of Philosophy in the Institute of Communications Research at the University of Illinois, Urbana-Champaign. Sascha is experienced with multiple statistical analysis tools including LISREL, SAS, and SPSS. Over the past half-decade he has coordinated multiple project teams of over a dozen people; as a project manager at OJC Technologies Sascha has overseen software development projects with budgets of between $50,000 and $250,000. He is the Co-director of the Urbana-Champaign Independent Media Center Foundation as well as the treasurer for the Global Indymedia Network. Sascha co-founded the Global South Fund and currently works with communities throughout the world building media infrastructure. Sascha has designed multiple award-winning qualitative and quantitative studies. As a co-founder and coordinator of the CWN, he brings his strengths in research methodology, community organizing, and project management to the team. David Young, Technical Lead: David was born in Huntsville, AL but has lived in central Illinois for the majority of his adult life. He earned a Bachelor's degree in Computer Science from the engineering program at Cornell University. He has a wide base of theoretical knowledge covering algorithms, data structures, and the theory of computation; strong diagnostic abilities; and an enormous breadth of programming experience spanning 3-D computer graphics, networking, machine intelligence, systems programming, and computational science. He is fluent in many programming languages, including C, Java, and Python. Currently, he is a software engineer at OJC Technologies. David has been the technical lead for the CWN software development for over two years and has helped develop and troubleshoot the existing technology and implement software improvements. Dave has garnered widespread respect for his NetBSD patches and kernel improvements as well as his work developing and reverse-engineering drivers for multiple wireless cards. Zach Miller, System Administrator: Zachary grew up in the suburbs of Chicago. For high school, he went to the prestigious Illinois Math and Science Academy (IMSA). Zach graduated a Chancellor's Scholar from the University of Illinois at Urbana-Champaign with a BS in Computer Science and Mathematics and a BA in Linguistics. Zach has wide-ranging experience as a system administrator, network designer, database developer, and computer programmer, beginning with his 2-year stint as network designer and lead Solaris and Netware systems administrator for IMSA, where he served more than 1000 users. In ten years, Zachary has distinguished himself as a programmer and systems administrator for the United States Geological Survey and as a consulting programmer for a variety of clients. Currently, Zach manages a heterogeneous network of machines for the Hierarchical Data Format Group at the National Center for Supercomputing Applications. He also helps to meet the special computing needs of the cutting-edge research group. Bryan Cribbs, Programmer/System Administrator: Bryan moved to Illinois from his native New Jersey in 1995 to study Electrical and Computer Engineering at the University of Illinois at Urbana-Champaign. Bryan is adept at turning concepts into code in several computer languages (Java, C/C++, Perl, Python, SQL, Bourne shell), and he is a quick learn: he has devoured both research literature on wireless networking and the CWN project code and documentation. Bryan is currently a programmer and system administrator for OJC Technologies, where he has worked since 2000. Significant project experience includes programming a test suite for a client/server configuration database developed by OJC for Nexthop Technologies, and leading the Java development for an on-line textbook developed by OJC for McGraw-Hill. 8. Project Budget & Timeline & Deliverables & Funding Dates, etc.: The core Community Wireless Network development team members are all currently employed as professional software developers and/or system administrators. Team members have committed to taking a sabbatical from their employment to develop this software full-time and build a prototype of a larger scale Network. Time estimates are based on market rates and include funding for benefits (e.g., health insurance) and employer taxes. Updated Project Budget & Timeline: Stage I: Software: Development & QA A. Routing i. Zebra Library a. research/programming b. testing ii. Socket-Server Library a. programming b. testing iii. Shortest Path First Library a. programming b. testing iv. HSLS Packet Library a. programming b. testing v. HSLS Configuration Loader a. programming b. testing vi. HSLS "Air Interface" a. programming b. testing vii. HSLS Module a. programming b. testing viii. ETX Module a. programming b. testing ix. Tcpdump Enhancement for HSLS a. programming b. testing B. Web Interface i. thttpd---tiny HTTP daemon a. programming b. testing ii. Web Bandwidth Tester a. research/programming b. testing iii. CGI Script a. programming b. testing C. Upgrades On-line i. Trim software to 32 MB ii. Adapt NetBSD/GRUB Bootloader iii. Software Update Script D. Kernel Development i. Integrate RADIX_MPATH Patch ii. Modify RADIX_MPATH Patch a. programming b. testing E. Name Service i. Web Interface: design/programming ii. Multicast DNS Operation: research iii. Filtering DNS Name Queries iv. Flood-Relay Function for DNS Queries v. Re-advertise Rooftop Names on the Internet F. Route Visualization i. User Interface a. programming b. testing ii. Node "back-end" a. programming b. testing Stage II: Hardware Rollout A. Node Hardware & Infrastructure i. 50 nodes at $500 each ii. Server equipment iii. Broadband Connectivity B. Node construction & Installation i. Construction of 32 nodes (96 hours) ii. Installation of 32 nodes (2 people at 2.5 hours each = 160 hours) Stage III: Integrated Network Testing A. Routing testing B. Throughput testing C. User Survey & Feedback D. Fixes Stage IV: Prototype Implementation In vivo implementation of 2-3 prototype networks with local technology partners to be agreed upon by OSI and the Community Wireless Network. Each in-vivo network cost includes travel, training, and coordinating with local partners. The remainder of this allotment may be spent on promotion of the tool, including but not limited to attending conferences, writing papers for publication, and working with local partners towards better internationalization. The details of this part of the grant will be agreed upon during Stage III of the grant period. Note that part of the funding, intended for hardware purchase for the prototypes, will be given during Stage I of the grant in order to take advantage of bulk purchase discounts. Ongoing Project Costs 1. Project Oversight/Management/Coordination (12%) 2. Fiscal Sponsorship Fee (5%) 3. Project (and Software) Documentation, End-User Manual, Hardware Set-up (How-to) Instructions, Testing Results Final Report, & Deliverables (10%) Funding Dates: 1. March 1, 2004 Disbursement: $95,000 Half the Programming funds, half the ongoing project costs, and Hardware and Infrastructure funding. 2. June 1, 2004 Disbursement: $71,050 Half the Programming funds, half the ongoing project costs, and Node Construction and Installation funding. Change(s) from originally submitted budget: space/equipment rental; Stage I G (Community E-mail & Web Server); and, funding for 18 node construction moved to March 2005 Disbursement. 3. January 1, 2005 Disbursement: $18,000 Stage III funding. 4. March 1, 2005 Disbursement: $15,950 Stage IV funding: in vivo implementation of 2-3 prototype networks with local technology partners to be agreed upon by OSI and the Community Wireless Network. Change(s) from originally submitted budget: If it is preferred to buy hardware in two batches, the March 2004 disbursement could be less and March 2005 Disbursement more; however, this will lead to decreased economy of scale on equipment purchases and higher equipment allocations for the project. Benchmarks/Deliverables: June 1, 2004 Benchmarks/Deliverables Kernel Development: port and test RADIX_MPATH patches HSLS & ETX Protocol Documentation. Development of Socket-Server Library, HSLS Air Interface, HSLS Module (Part One: no kernel interface, no shortest-path first), TCPdump Extensions for HSLS, ETX Module, Route Visualization. * CWN will have expert advisors review implementation documents. * CWN will develop software that runs on our testbed to demonstrate that ETX is computing correct, stable link costs, and HSLS is propagating changes in the wireless link-state. * Initial Progress Report Delivered to OSI with financial statement January 1, 2005 Benchmarks/Deliverables Development of Shortest-Path First (SPF) Library, Zebra Library, HSLS Module (Part Two: integrate with SPF Library & Zebra Library), HSLS Configuration Loader, Upgrades On-line, Web Interface. Documentation of HSLS/ETX Software. Initial Design of Reference & User's Guide, Hardware Design & Construction Manual, and User's Guide. Testing of Routing & Throughput. Building of Full-Size (32-node) Testbed. * CWN software ready for distribution. * CWN manuals describing how our software works and how to use it ready for distribution. * Illustrated guide explaining how to build network nodes ready for distribution. * Second progress report delivered to OSI with financial statement March 1, 2005 Benchmarks/Deliverables Implementation of Name Service and Domain Names. Final Design of Reference & User's Guide, Hardware Design & Construction Manual, and User's Guide. * CWN Development Report, including network operational report, key accomplishments, user survey, areas for improvement, future development needs. * Third and final development report delivered to OSI, along with final development financial statement. OSI will engage expert reviewers to assess the documented code and user manuals. Post-Proof-of-Concept Benchmarks/Deliverables (Summer 2005) * CWN Final Report delivered, including updated network operational report, key accomplishments, areas for further improvement, future development needs and final financial statement. Software License: Copyright (c) 2005 Urbana-Champaign Independent Media Center Foundation. All rights reserved. This code was written by the Champaign-Urbana Community Wireless Network Project and its contributors: David Young Sascha D. Meinrath Zachary C. Miller Bryan Cribbs Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the Urbana-Champaign Independent Media Center Foundation Community Wireless Network Project. 4. Urbana-Champaign Independent Media Center's name may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE URBANA-CHAMPAIGN INDEPENDENT MEDIA CENTER FOUNDATION "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE URBANA-CHAMPAIGN INDEPENDENT MEDIA CENTER FOUNDATION BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Treatment of Code: Urbana-Champaign Independent Media Center agrees to the following conditions for the abovementioned code: * The source code will be available from Sourceforge or another long-term online repository agreed upon by UC-IMC and the Open Society Institute. * UC-IMC will not charge users for the download of their source code; the complete source code will be available at no charge to anyone who wishes to use it. Documenation Plan: Documentation for this project will include both in-code commenting as well as user manuals and instruction guides for network installation in "high-resource" and "low-resource" locales made available in both online and printed formats: I. Software documentation A. Protocol documentation 1. HSLS a. Packet format: byte order, fields description, fields layout, extensions format. b. State machine: joining, leaving network, forming adjacencies, link-state update schedule, "hello" schedule c. Operational parameters: hello rate, link-state update quantum, etc. d. Assigned numbers: e.g., service ports and multicast addresses e. Abstract API (as design phase dictates), extensions API hooks f. Algorithms: choosing routes (shortest-path first) 2. ETX a. Packet format: byte order, fields description, fields layout,extensions format b. State machine: joining, leaving network, scheduling beacons c. Operational parameters: beacon rate, etc. d. Assigned numbers: e.g., service ports and multicast addresses e. Abstract API (as design phase dictates), extensions API hooks f. Algorithms: setting link-weights B. Design overview 1. HSLS logic module a. API documentation b. Diagrams and functional descriptions for data structures & algorithms 2. HSLS packet assembly/disassembly a. API documentation b. Diagrams and functional descriptions for data structures & algorithms 3. ETX module a. API documentation b. Diagrams and functional descriptions for data structures & algorithms 4. Name service a. API b. Data structures & algorithms C. On-line documentation 1. Unify on-line documenation formats with DocBook, XML, or similar technology 2. UNIX manual pages 3. Web pages II. Software end-user manual (HSLS, ETX, name service, network visualizer) A. Installation 1. Where to download 2. Writing the media 3. Configuration and testing B. Operation 1. Monitoring network ops 2. Dynamic configuration C. Troubleshooting III. High-resource installation A. Photo-illustrated assembly manual B. Waterproofing C. Grounding D. Siting E. Testing IV. Low-resource installation A. Software duplication B. Computer setup C. Software installation D. Cable assembly E. Antenna siting F. Antenna mounting G. Grounding H. Testing V. Testing results A. HSLS updates overhead 1. Unstable/stable links 2. Compare with expectations B. Convergence and stability of ETX 1. Unstable/stable links 2. High/low traffic load 3. Compare with expectations C. Name service performance 1. Effectiveness of duplicate name detection/resolution 2. Response time 3. Percent overhead VI. Final report A. Summary of accomplishments 1. Communities served 2. Areas of application, new & expected 3. Technical achievements B. Areas for additional work 1. Technical opportunities a. Improve capacity b. Create new applications 2. Social opportunities a. Serve new communities under new conditions b. Meet new user-base demands c. Respond to social/cultural change 9. Co-Funders: The Community Wireless Network (CWN) has brought together a diverse array of individual donors, foundation, and organizational/institutional support over its three-year development history. Phase I support has been given by: 1. The Urbana-Champaign Independent Media Center Foundation 2. National Center for Supercomputing Applications (NCSA) 3. University of Illinois Department of Computer Science 4. The dozens of individual donors who helped initially fund the project Phase II support has been given by: 1. The Urbana-Champaign Independent Media Center Foundation 2. National Center for Supercomputing Applications (NCSA) 3. The Threshold Foundation 4. OJC Technologies 5. The City of Urbana, Illinois 6. Innovative Education 7. Prairienet Community Network Phase III support is expected/has been secured from: 1. The Urbana-Champaign Independent Media Center Foundation 2. OJC Technologies 3. The City of Urbana, Illinois 4. Innovative Education 5. Prairienet Community Network 6. Illinois Community Technology Consortium 7. Dept. of Afro-American Studies, University of Illinois Urbana-Champaign (UIUC) 8. University of Illinois Learning in Community (LINC) 9. Graduate School of Library and Informational Sciences at UIUC 10. Urbana School District 116 11. Provena Behavioral Health Hospital 12. Parkland College 13. East Saint-Louis Action Research Project 14. Illinois Century Network 15. Department of Speech Communications at UIUC 16. Department of Electrical Engineering at UIUC 17. Institute for Communications Research at UIUC The CWN will be launching Phase III of the project as soon as financing becomes available and is also actively pursuing grants from several additional sources (e.g., Illinois Dept. of Commerce and Economic Development, Progressive Technology Project, Haymarket Foundation, City of Champaign, Illinois). Thus, the Phase III supporters list will grow as new partners are added. $Id$