Using the Wisconsin Network - Part 25

by Andy Nemec, KB9ALN

In the last part of this series, we took a look at the future of Amateur Packet Radio, and what we can do with it. We took note of the evolution of the packet network, and what other changes we might want to see in it's continuing development.

We drew some paralells with the Internet, and how we would draw on some of the networking advances that have been made there, perhaps applying them to Amateur Radio. When we left the last part of our series, we broke the network system down to a few basic functions like these:

1) An originator of data.

2) A Network Interface Host computer (Similar to what we use now, only more functional and automatic).

3) An transparent Auto-Routing network requiring no user knowlege or intervention.

4) Another Network Interface Host Computer at the destination.

5) A receiver of data.

Of course, the originator of data would be your, or any other Amateur Packet Radio station. We mentioned that this station could be combined with a Network Interface Host Computer, more on that later.

The Network Interface Host Computer can be compared to a current node in some ways, but capable of being more "network friendly" than our current nodes. This, as well as the network itself, deserves the most study and contemplation. Just what would this computer do? Aside from storing and auto-delivering your personal mail, it would route packets properly, maintain a table of reachable destinations, and know the best way to reach a destination. It could act as a gateway to the Internet, it would allow use of different protocols to accomplish different tasks. In effect, it could replace both the BBS and the nodestack you are currently using, and allow you to access the "World-Wide Web" with a text browser (if data rates can be increased sufficiently).

The network itself would consist of interconnected host computers. They would exchange data concerning routing, as well as acting as relay stations and routers to make certain any data it handles is effectively sent to it's destination. While some of this sounds familiar, the methods that these computers use to communicate would be different and far more varied than they are now.

Currently, only a portion of the network will allow anything other than AX.25 and the Net/Rom (node) protocols to be passed. This is the primary difference between what we are using now and what we could use in the future. In the past 3 years or so, we in Green Bay have been doing considerable experimentaion with TCP/IP protocols - the protocols used on the internet. Currently, we have 10 TCP/IP stations in full-time operation, with one or two ocasionally operating.

In addition, we have a node stack that is equipped with the X-1J4 node firmware, which allows both conventional and TCP/IP protocols to be passed through it. While the X-1J node does not have all of the features of the Network Host Interface Computer described earlier, it is a mid-way point that allows some of the advanced features we may be looking for. Currently, the only real network host computers we have are the TCP/IP stations themselves. These stations access the network through the nodes, and work with the network.

Here is a sampling of what we have been able to do with these stations:

1) Mail a freind without ever having to manually connect up to a node or a mailbox. This is done with the use of "SMTP", the "Simple Mail Transfer Protocol". While SMTP can directly deliver mail to a recipient, it's operation can be modified to store it at a different computer - a different station.

2) If mail is left at another station, it can be automatically collected from that station using the "Post Office Protocol" (POP). Stations are configured to automatically "POP" the nominated "POP Mail Server" and collect mail. These operators don't have to remember to check into their local BBS - their station automatically remembers for them.

3) Transfer text and binary files to other TCP/IP stations with ease. This is the "File Transfer Protocol" (FTP) at work. There is no need to fool with YAPP to transfer binary files, binaries are simply identified as such and the system automatically accomodates this.

4) Test a radio path by requesting an Echo. This is called "Pinging" a station. The Amateur Radio implemetation will tell you how long it takes to get an echo return, letting you judge how busy the network is.

5) Find out who somebody is without taking a lot of time to do so. This is the "Finger", kind of like tapping someone on the shoulder and asking "Who are you?" A short custom information file is returned with the answer.

There are even more possibilities that we can talk about, and more yet to explore. We have talked about this before in an earlier installment of this series, but needed to repeat this here to show the versatility of the TCP/IP protocol set.

So now we come to the next step in the evoloution of the network as it pertains to Amateur Packet Radio. The Network Interface Host Computer would perform a lot of the functions that current TCP/IP stations would perform, freeing their resources for other things. POP Mail and the SMTP system - automatic mail - could free things up additionally. And now with the intense interest in the World-Wide Web, we could also utilize that for Amateur Radio.

Now let's talk about the other things we will have to consider for the Amateur Radio to effectively use this protocol set. First we need more user-friendly for the ocassional user of this powerful system. Programs could be stand-alone DOS versions, or based on the Windows operating platform. Secondly, we need to resolve one issue that is important to making this sytem widespread.

Currently, all TCP/IP staions are numbered, kind of like a serial number. For example, my IP address All Amateur Radio network stations begin with the 44 series of numbers. Obviously, there are a limited number of TCP/IP addresses available, and assignment of the number varies according to location. Therefore, widespread use and mobility becomes another complication.

Then there is overcoming the wide-area reliable pathing and routing of data. Right now we rely on the Net/Rom system to do this. Although we have maybe gotten used to some of it's shortcomings, it is not exactly reliable or automatic. TCP/IP routing principles are borne of a wired network that is not subject to propagation variables. So simply adapting all of the routing techniques the Internet uses are not effective. There have been some attempts at doing this, and progress is being made.

Next time we will further explore how a Network Interface Host Computer system can overcome some of these problems, and what to look for in the future.

On to Part 26 - More TCP/IP and future Packet Radio - Network Needs

Back to Part 24  - The New Age of Packet Radio - Part 2

Back to the Using the Wisconsin Network Index - Choose a different part to view

Back to the WAPR home page  - Look at something else