Why do we say this? Go back to what a node is (and what it does) for your answer. A node is a sophisticated repeater of packets that you, and the station you are connected to, originate. If any of the stations using the network are not set up correctly, a node gets busy, and in some cases can sever a connection altogether. Looking at packet radio basics will tell show us why this can happen.

Remember what the basis of packet radio is - the sending of digital data by way of a shared radio channel. The fact that packet radio data is sent in short bursts allows several stations to use one frequency in the same time frame. In fact, packet radio stations share time as much as they share a frequency. Now let's review how packet becomes "error free" (or nearly so).

First, a line (or character) of text is sent from your computer to the TNC. The TNC counts how many bytes of data are being held in it's memory, ready to be sent out as a packet. When the number of bytes gets to a certain value (called the PACLEN), the TNC assembles a packet. When a packet is assembled, it calculates a number, called a checksum. This sending TNC assigns a sequence number to this packet, and addresses it.

Then, the TNC checks to see if the any other stations are sending any packets on the frequency. It waits for what it thinks is a good amount of time before transmitting. Finally, the TNC keys the transmitter and sends the data to the transmitter in the form of audio tones. When the complete packet is sent, it unkeys the transmitter, and waits.

If receiving TNC can copy the packet, it converts the audio tones back into data that the computer inside of the TNC can use. It disassembles the packet, determines if the packet meets the checksum, and if it is of the correct protocol. Remember, most user stations use the AX.25 protocol, Nodes use Net/Rom, and TCP/IP stations use IP. Then it replies to let the sender know it's status.

The receiving station replies in one of a few ways, if it hears the packet. If the packet meets the checksum that is sent with the packet, and the sequence number matches what it is expecting, it checks to see if the frequency is clear. It waits for what it considers a good amount of time, and responds with a "Receiver Ready" packet. It also tells the sender what the next expected packet will be numbered as. All is well so far.

If however, the packet is corrupted for some reason, or it is a duplicate packet, the receiver will send a "Reject" packet. If it fails the checksum, it tells the sender this. Again, it tells the sender what sequence number of packet it is expecting. If the packet is not of the expected protocol (generally AX.25), then it sends a "Frame Reject". If it is a serious protocol error, it will break the connection and make you start over. Protocol errors between two AX.25 packet stations are rare, however, and are usually due to incorrectly decoded packets.

If the receiving station does not hear the packet, or if the packet is so badly distorted that it cannot recognize it, it does not reply. The sender is waiting for a reply, however, and a timer determines just how long it will wait before it asks "Did you get the last one?". If no reply is heard, and the timer expires, it does just that. This is called "polling".

While all of this might be "more than you really wanted to know", it is important to understand in these basic terms. Why? Look at all of the timing at work here. First, we divide up time to allow several stations to use a given frequency. The sender waits to send data. The receiver waits to acknowlege the receipt of data. The sender waits a certain amount of time before checking to see if the packet has arrived. As with the rest of life, "Timing is Everything!".

Consider what happens if a station sends a packet out, and does not wait long enough for the receiver to reply. That is a wasted packet. What happens if a receiver does not wait long enough before acknowleging a packet? Some other station will not get a chance to transmit a packet. What happens if both stations do not wait long enough between transmissions, or between polling? Then the frequency is virtually "locked up" as long as these stations are connected! And that is where the network comes in.

The network starts with you, and your fellow packet operators. Remember, we are all "time sharing", as well as frequency sharing. All of these timing parameters are configurable through simple TNC commands. The sad fact is, the defaults that are factory set are totally unrealistic in today's packet radio environment. Most of these were decided on in the early 1980's when packet radio was not nearly as well-populated as it is now. Add to that the fact that a lot of TNC instruction manuals are written in Techno-Babble, and it is no wonder that we are all confounded and prefer to leave them as they are. We could all be operating a lot more efficiently than we are now. And that is what the next installments of this series will be about. We will discuss TNC parameters, what they mean, and how to set them up in a cooperative manner.
 

On to Part 13 -  How to set your TNC parameters in concert with the network

Back to Part 11  -  TCP/IP Stations as Network Nodes and Node Commands

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

Back to the WAPR home page  - Look at something else