Gnet Network Architecture

[DRAFT]

 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.