September 10th, 2000
1. Introduction, Purpose, and Scope Gnet is an ambitious open-concept networking project to establish a ubiquitous wireless and wired network to ensure that the free flow of information is not obstructed, captured, analyzed, modified, or logged. The ultimate goal is to create a network outside the control of governments, corporations, and dubious Internet regulatory committees. To achieve this goal a network infrastructure which does not rely on commercial networking resources is required. Hence the wireless aspect of the network. Unfortunately, limitations in current RF technologies make it difficult for high-speed long-haul wireless links. To encourage wireless network development in other parts of the world, the gnet VPN will allow distant wireless network to share data over secure, encrypted channels. As the wireless network cloud expands over geographical distances, redundant VPN links will be replaced with their wireless counterparts. This document will define the various hardware components of the network, and a wireless network link requirement. Packet Priority Protocols, the VPN configuration, and software configurations of the nodes is beyond the scope of this document and will be tended to in their respective documents. 2. Definition of Network Components The architecture of the network is loosely based on the early cellular telephony system which was developed by Bell Laboratories in the early 1980's. One key difference is the additional redundant connections between backbones to counter the catastrophic effect of network fragmentation, should a backbone node operator loose interest and withdraw their services. A method to counter this condition is presented below. The network is comprised of the following fundamental blocks: Network Routing/Repeaters [NRR] ( Backbone Nodes ) Network Cell Access Points [NCAP] ( Feeder Node ) End User Equipment [EUE] ( Mobile / Stationary User ) While there are three very distinct blocks, most gnet sites will often have a combination of all three at their location. It would also not be uncommon to see the functionality of the NRR and NCAP combined on the same computer system. Budgetary constraints will most likely be the limiting factor of each node's functionality. It would be in the networks best interest for each node to function as a NRR or a NCAP, or both, as this will allow maximum wireless coverage of geographical terrain by wireless services. A tight cell structure with minimal overlap is achieved through a frequency management plan coupled with minimal transmit power will keep the cells tight and manageable. Separate frequencies for point-to-point links and user channels will further ensure that inter-cell traffic is transported with negligible interference with network inputs. This will eliminate "hidden-transmitter syndrome" (HTS) from backbone links and reduce the same from user inputs. To further reduce HTS, the EUE should be capable of reducing output power so that only minimal power to reach the closest NCAP is used. 2.1 Network Routing/Repeater [NRR] ( Backbone Node ) This is the main building block of the network. The NRR act as the backbone links, routing packets between NRR's and NCAP's. Due to the critical role NRR's play in the network, great effort should be made to house NRR's at radio clubs, repeater sites, or some other non-individualistic ownership arrangement. If a user moves away from the location or becomes disinterested in the network, the absence doesn't leave a gaping hole in network coverage. In addition to wireless backbone node interconnectivity, the NRR is also responsible for routing packets destined to remote wireless clusters out over the Internet via the gnet VPN. For the sake of redundancy and to lessen the detrimental effects of a NRR or NCAP dropping off the network, each NRR should connect to at least TWO other NRRs thereby creating diverse network links. This requirement is achieved by 2 different antenna's, 2 feedlines, 2 radios, and 2 TNCs (or soundcards). NRR wireless links should utilize point-to-point full-duplex communications, when possible. The minimum speed of a backbone link will be 9k6bps(maybe we should just jump to 19k2?). Geographical location and elevation will dictate the backbone RF characteristics. Line of Sight [LOS] to other NRR's should be considered a requirement of NRR sites. LOS will allow for higher data rate transceivers to be employed between backbone links. All NRR's must carry IP. [ thoughts on wireline bandwidth requirements? I think it is a function of the wireless pipe capacity. Same with backbone bandwidth requirements.] The NRR base computing requirements: 133Mhz pentium Class or equivalent 1GB HD 32MB Ram Soundblaster compatible Soundcard (soundmodem) Parallel/Serial port Linux Operating System 2.2 Network Cell Access Point ( Feeder Node ) The Network Cell Access Point [NCAP] acts as a way for fixed point or mobile users to connect to the network. The requirement for NCAP's is one Omni-directional antenna/radio, and one point-to-point link to a NRR. It should now be apparent how easily it is for a NRR to also function as a NCAP. All NCAPs must carry IP. An NCAP can support multiple access points into the network via different radios. For example. A NCAP way have a 2meter port and also a 70cm port. Just remember that your NRR link must support at least 4 simultaneous connections over an access port. The NCAP base computing requirements: 133Mhz pentium Class or equivalent 1GB HD 32MB Ram Soundblaster compatible Soundcard (soundmodem) Parallel/Serial port Linux Operating System 2.3 End User Equipment [EUE] ( Mobile/ stationary user ) All user network access is performed by achieved through EUE equipment. The minimum speed of EUE equipment should be no less that 1k2bps. Typical EUEs will be laptops with a packet modem, or a user with minimal resources or roof access. Only true mobile users should be allowed to connect via EUEs. Fixed users should be pressured into providing at least NCAP services. This equipment may be allowed to run software other than the Linux operating system as required by the NRR and NCAP. 3. Other Requirements All network/operating system software for the NRR and NCAP must be open sourced. There is no need nor benefit for using non-opensourced software without access to source code. This will allow for customization and optimization further down the developmental road. NRR and NCAP administration should be somewhat open to the elected network technicians. Nothing is more frustrating than having a node fall into disrepair due to absentee operators. While little can be done to keep physical infrastructure from deteriorating, at least the OS can be maintained remotely. 4. Conclusion This living document will provide a roadmap for gnet architecture requirements. Changes to the network and capabilities should be captured in this document as well as any other appropriate documents covering other aspects of the network.