The amateur radio service has a good chunk of the IPv4 Internet address space (220.127.116.11/8), and it's not being used to its fullest potential. Meanwhile, the rest of the Internet is crowding into the remaining address space and will no longer have any left in the near future.
The address space isn't being used because of a chicken-and-egg problem: the necessary digital repeaters aren't available for users, and there are no users to justify building the repeater network.
Simultaneously, the United States is debating a bill to create an Internet kill switch, also known as the PCNAA bill. Echolink, IRLP, APRS gateways, and many other services assume the Internet's original distributed design won't allow a single entity to take out the entire network. If the PCNAA passes, this will no longer be true. For true redundancy, a non-critical network can and should be built by the amateur service to avoid this single point of failure.
The cost of the equipment has finally come down to the point where even a modestly funded amateur radio club can afford to set up a small regional network by themselves. Through advocacy and standards development, Noisebridge is building a packet radio network modelled on the original vision of the Hinternet.
Frequently Asked Questions
Coordination is taking place on the Noisebridge CQ list. If you or your ham club has access to a tower and a little cash, sign up for the CQ list and speak up so the folks in the next city over can connect to you.
Chris Verges, the address maintainer for 44.4/16, has given the go-ahead for allocation of up to a /22 for experimental use of the HSMM gear. The SFBA 44.4/16 allocation is currently two /17s: one is for 1200bps and the other is for 9600bps. Hams are needed to volunteer to maintain radios for the initial allocations in the /22 before it will go through.
Noisebridge members will be touring the SFBA ham clubs and giving presentations at their monthly meetings to gather the necessary volunteers.
PAARA: Friday, September 3
SBARA: Friday, September 10th
EBARC: Friday, September 10th
ORCA: Saturday, September 11th
HARC: Saturday, September 11th Thanks to Ken Fowler, KO6NO for helping install a Ubiquiti Nanostation 5 in Alameda for testing.
CCCC: Sunday, September 12th
MDARC: Friday, September 17th Thanks to Tim Barrett, K6BIV, for volunteering to host a radio on Mt. Diablo's North Peak, Dale McIntyre, AD6HD, for helping with presentation logistics, and Trevor Hall, WA6JAU, for coordinating with MDARC's technical committee on installing a radio on Mt. Diablo's main peak.
SFARC: Friday, September 17th
HRC: Friday, September 17th
CARC: Wednesday, October 13th
Pacificon: October 15th - 17th
ARCA: Friday, October 22nd
The next meeting for the Noisebridge HInternet group will be Saturday, October 2nd. The meeting will be 3 PM at Noisebridge.
The architecture will be an 802.11s (open80211s implementation) mesh in the backbone, with fixed towers forming the core of the network. Each tower will service a subnet, and each subnet will itself be an 802.11s mesh. Each subnet mesh will be independent of the backbone mesh and all other subnet meshes. Towers will route packets between subnets and filter traffic to ensure compliance with FCC part 97 regulations.
There are four major bands suitable for use by hams transmitting spread spectrum: 420-430 MHz, 2.4 GHz, 3.4 GHz, and 5.8 GHz. Within a region, one band will be used for tower-to-tower connections, and the other bands will be available for use by non-tower radios.
The initial goal of the first wave of HInternet backbone deployment is to transmit a "golden packet" between New York and San Francisco. Further backbone deployments will concentrate on expanding the network towards the north and the south to cover the rest of the continent.
Noisebridge HInternet Project Technical Recommendations describe standards for connecting to the network.
- HInternet/TR1: HSMM HInternet Layer 1 Recommendations
- HInternet/TR2: HSMM HInternet Layer 2/2.5 Recommendations
- HINternet/TR3: HSMM HInternet Layer 3 Recommendations
- HInternet/ApplicationLayer: Application-layer communications and protocols