[linux] LinLink

[dubose at texas.net]

LinLink

Purpose:  An Open Source Enhanced Digital Messaging for Amateur Radio Utilizing 
Source Code From Previously Released Amateur Radio Open-Source Applications . 

Mission:  Provide Amateur Radio Operators and emergency service and disaster 
relief organizations with a low or no cost system utilizing enabling 
technologies and sound operating practices to provide a full-featured radio 
digital message transfer system with attachments, map & text-based position 
reporting, graphic & text-based weather bulletin services such as developed by 
Texas A&M Univ. Packet like application similar to AX.25 and AX.25 BBS 
applications such as JNOS, TNOS, FBB and the like. An MTA using existing RFC 
compliant standards where practical and an HF modem using current or newly 
developed  high-speed, robust computer sound card applications such as in MT63.

Hardware: The hardware suggested is a computer running a 350 MHz CPU or better 
(the higher the better), 128 MB RAM (256 MB RAM suggested), 4.0 GB Hard drive, 
CD ROM (X42 suggested) and floppy. A sound card equal to the Sound Blaster 16 
or better may be required.  Our goal is to support on board sound such as AC97.
Software:  The initial thrust will be a server/high end client application(s) 
which will require one of the current Linux distributions. Later, or 
simultaneously if we can obtain the programming support we will attempt to 
provide a high-end client for Microsoft operating systems. For the high end 
client, we also plan to have a Linux system running completely from a CD so 
that you can boot up the system from the CD and not disturb your currently 
installed operating system. Additionally, for low-end clients, we plan to be 
able to use commonly available terminal applications or perhaps current Packet 
programs. 

Cost: The LinLink Development Team will release the product under the terms of 
GNU GPL license. See http://www.gnu.org. There will be no cost for any of the 
software that is downloadable from the LinLink web site. However, the 
distribution may be acquired, for example, on removable media for little or no 
cost from various sources. 

Development: The development team's desire is to provide a product that meets, 
to the extent possible, the data transfer (traffic) requirements of the DHS, 
FEMA, the ARRL, MARS, CAP, RACES, ARES or other disaster response or relief 
agencies such as the Red Cross, REACT and Salvation Army. We will modify the 
software as necessary, in a timely manner, to meet changing requirements . 
Since the software will be released under the GNU GPL license, any individual 
may change the software as they see fit as long as they release the changes per 
the GNU GPL license. The primary message delivery wil be designed to be 
delivered by radio in an E-Mail or ARRL message format.  However, we desire to 
make the software capable of E-Mail delivery via the Internet, HF and V/UHF 
SMTP and BBS formats, and later, HF and V/UHF AX.25 BBS Formats. We will also 
have the ability to print out messages in ARRL and MARS formats for transfer to 
voice systems. 

Contact:  Currently the points of contact are, Walt DuBose/K5YFW, E-Mail, 
dubose at texas.net; Curt Mills/ WE7U, E-Mail archer at eskimo.com; Gerry 
Creager/N5JXS,E-Mail n5jxs at tamu.edu. 
  
HF Data Modem and Message Delivery System Specifications

Here are some general specifications that could help guide
programmers in writing software that would produce a high speed,
robust, HF modem and messaging system for amateur radio.

Since amateur radio operators are generally familiar with E-Mail
and Web E-Mail forms, it is desirable to create a high speed,
robust HF data system with user familiar input and output
interfaces.  Additionally, the system outputs need to meet the
needs of automatic, manual and voice traffic networks.  We realize
that the ultimate goal is a fully automatic input and output,
nation wide, message system; however, we need to initially be
flexable enough to service the needs of all types of message
creation and delivery systems.

General System Description:

The system will move messages between stations on HF, VHF, UHF,
802.11 networks operating under Part 97 or if the commercial
Internet is available, it may also be used. The system will be
expected to be able to pass message traffic between stations
across the entire nation both the contentious 48 states and the
other states and territories.  Additionally, the
ability to send and receive multi-national message traffic is
desirable.

Ideally each station will have an updated routing table that will
be broadcast by a QST FEC type broadcast by various stations
stations across the country, on various frequencies and at various
times. Input to the routing table will be via a web server on
the Internet prior to an emergency and manually input by the
broadcast stations when the commercial Internet cannot contact all
broadcast stations. Routing to destination will be done using the
ZipCodes that receiving stations can service. It is expected that
HF stations, especially those that also have one or more other
system input, would maintain a complete routing table.  Stations
with VHF, UHF or 802.11 inputs might only maintain routing tables
for their local area.

The input and output formats should be the same regardless of
the band or frequency selected.  Typical system inputs would be by
TCP/IP - SMTP, a "lite" SMTP format that can be converted to a full
SMTP format at the receiving station, 802.11 networks, manual
input, AX.25 packet, etc. If AX.25 packet is used, modulation
rates should be 9600 BPS or higher.  HF stations will also be able
to forward messages to other ZipCodes that they cannot service
locally.

Since local stations will know the outbound paths better than a
system, it is expected that local area stations would route local
traffic to stations that can 1) deliver the message, 2) relay the
message to a station that can deliver the message.  If local area
stations cannot delivery a message, such as in the case of VHF
stations, it is expected that the traffic would be routed to
another VHF, UHF, 802.11 or HF stations.

HF stations in addition to their HF capability, should also have
at least one other other input frequency.

We are stressing the use of the ARRL Message form or a look-a-like
form as an input since most amateurs passing message traffic are
familiar with this form.  Additionally, while there are many
other possible input forms such as various E-Mail clients,
everyone is familiar with Web E-Mail input forms.  This will
simplify input to the system.

Specifications - Requirements:

Modem:

+  1)  The modem should be designed to work with a computer sound
card.  The sound card requirement should be of the type that is
found in most modern "on-board" sound cards of if necessary,
specify the minimum acceptable type of sound card such as SB
16 type sound card.  We want as many computers as possible to be
able to use this modem/system. Note: AC'97 sound cards, the type
found on many mother boards and notebooks, are notoriously hard to
program to, although some common APIs do exist. It is expected
however, that this problem can be over come.

+  2)  High Speed Throughput.  The user available throughput
should be at least 200 WPM.  The modem might have a greater
throughput; however, we want the recoverable or user data to be
at least 200 WPM.

+  3) Robustness.  A goal of full throughput on poor CCIR channel
at 15 dB SNR.  If the throughput in 2) above is 200 WPM on a good
CCIR channel at a +5 to +10 dB SNR, we want the same throughput on
a poor channel.

   4) Allowable bandwidth.  Less than a normal SSB signal
(approximately 2.7-2.8 KHz). 

   5) Error Free. 99.9% error free.  99.9% error free is at 
least theoretically achievable.  Depending on the protocol and 
modems involved, you can get better results by incorporating 
error detection and correction schemes. Attempting to get much 
better than "3-9's" is very difficult and expensive in both dollars 
and effort, and often not directly achievable. 

   6) Modes. ARQ & Broadcast.  Both modes  should use FEC.
When we talk about a robust FEC, we halve or third our throughput,
in general terms.  If the FEC is "really good" we may drop it to
1/3 the original data rate.  Hence, to get both FEC and 200 WPM
user data throughput, we're looking at 400-600 WPM needed to meet
the robust FEC goal. Using ARQ, you might be able to use a lesser
mount of ARQ.

+  7) The modem throughput and robustness should demonstrated
using a channel simulator as well as well documented on-the-air
test over various distances including coast-to-coast test on at
least 30 and 20 meters.  Medium and short distances would be done
on 80 and 40 meters.

+  8) The system must be able to transmit text and binary files.

Message Delivery System:

+  9) The prime operation of the system is to be Internet
independent.  However, the ability to leveraging the commercial
Internet, if available, is permitted and encouraged. 

  10) Secure protocols.  Use secure protocols and/or secure
procedures where possible and practical.  This of course is a gray
area now; but, we should strive to make the system capable of
using secure protocols and procedures should it be desired or
needed in future use. 

  11) Text Compression Goal:  3:1 

  12) OSI Compliant Design (i.e. RFC 822) .  As much as possible,
we would like to see the system be as OSI Compliant as possible
and as practical. This is a goal rather and a specific
requirement.

In this case we are trying to get the new code designers to follow
conventional standards for segregation of functions so that they
can easily be modularized.  If someone develops a package that will
do data transmission in KISS Mode on a TNC, directly (oh, yeah!
those already exist), its integration should be just another lower
layer on the  OSI reference model for network-enabled applications.
The same thing with wired ethernet or wireless ethernet (HSMM -
802.11 operating under Part 97) 

+ 13) Source Code.  The source code should be written in a modern
programming language such as C++, to promote portability among
modern operating systems.

Utilization of existing open source code is acceptable and
encouraged as long as it meets the above criteria. Adequate
recognition of the originator of the code is encouraged.

+ 14) Source Code Licensing.  The source code should be released
under the GNU GPL License (http://www.gnu.org) so that all
interested parties can use the code to improve it as their skills
allow them...so that we can improve to the extent possible, the
communications arts.

+ 15)  Released Application.  The released application should
initially be able to run on Linux (Linux/Unix/BSD), Microsoft
and MAC OS-X computer operating systems.  Additionally, creation
of a bootable CD to run the complete or streamlined version of the
application is encouraged so that the system can be temporarily
installed on any computer with IBM PC architecture. 

  16) Message Input.  The message input should be at a minimum a
web based (HTML) form with a CGI written for the various platform,
i.e. Perl and PhP for open source operating systems and VBasic for
Microsoft platforms.  The input form to the maximum extent
possible look the  ARRL Message Form used by the NTS.  Other
messages forms such as use of Eudora, Netscape, Mozilla, Outlook,
Evolution, and Outlook Express or even simple BBS or text
E-Mail client such as Pine could also be use.  Transfer of
messages should be in SMTP format or convertable to SMTP format.
Whether the message is intended for delivery by automatic HF
E-Mail/traffic system of via some other VHF or UHF delivery system,
keeping the basic format in SMTP will benefit standardization.
See the attached HTML form. 

  17) Message Out Format. -The  ARRL  message format  and E-Mail
formats are the desired outputs.  The outputs might be displayed
as an HTML form that is printable, could be saved as a file, and
the received information should be presented in a "text" format
such as would be written down while receiving a message on a voice
net. This allows flexability within the system to meet the needs
of various end customer such as ARES, RACES, NTS, Internet E-Mail,
voice or CW nets or 802.11. 

  18) Create and use routing table so that "registered" stations
can be located  by zip code. Callsign, Zipcode, frequency and time
monitored information should be included. Multiple stations in a
ZipCode area should be listed in a priority order.

An effort should be undertaken to initiate a routing database and
protocol to allow automatic determination of the next hop, or
station, in the network design.  This protocol should be a dynamic,
self-reloading, protocol.  A prototype for this is the Radio-Shortest
Path First system demonstrated in the late 1980's in AX.25 and still
viable today.

+ 19)  Have a priority system so that priority messages are
transmitted before routine messages.  If a routine message is
being transmitted, when the message is complete and a priority
message exist or has just been submitted to the system, the
priority message is the next message sent. 

  20) To the extent possible, applications developed should be
interoperable with other existing similar applications without
sacrificing the development of the new system. Or if not
interoperable is not possible, it may be desirable to
provide developmental information to programmers of existing
similar software if they have a desire to try and make their
applications interoperable with developing systems.

However, if there is anticipation of holding a contest to
determine the best" system, the above sharing of information may
no be advisable.

Certain of the above items should carry more weight that others.
Those items with a "+" before the item number should carry more
weight than the other items.