The following document describes, in as simple terms as possible, what nodes are, how they work, and how to get the best from them. It was written by G6NHK in the early 1990s and is somewhat out of date now.
If you're reading this via packet you obviously know what a TNC is and how to connect it to a radio and some sort of terminal, so we won't be starting from absolute basics ! There are several types of packet node which you will encounter - TheNet, NET/ROM, BPQ, TCP/IP and KA nodes, but for now we will be referring to the TheNet and NET/ROM types, which are used extensively by GB3 and GB7 nodes.
The setup of a node is very similar to the setup which you are probably using at your station, except that a node's TNC contains different software, and there usually isn't a terminal permanently connected. The main task of a node is to help establish connections, and the software contained inside the TNC is specially written to do that. We shall see later that this software is very powerful, and much of what the node does is transparent to the users. The software has been designed so that the node can send information about itself to other nodes and receive similar data from other nodes with the minimum of interference to users.
To avoid creating extra traffic when conversing with other nodes, a node uses a special abbreviated language called "Level 4" (most ordinary users on packet use Level 2). Since node TNC's are basically simple computers, node-to-node "chatter" need not be in plain language, so on a normal "Level 2" terminal this data will appear as hieroglyphics ! A node needs to know the callsigns of other nearby nodes, so each node sends out a "Nodes Broadcast" at regular intervals (usually every hour).
This broadcast contains (1) the callsign & alias of the node sending the broadcast, (2) information about neighbour nodes which it can "hear" including the "route quality" (more on this later), (3) information about nodes even further away, which neighbouring nodes have "heard".
On receiving these broadcasts, the node can build two "tables", which are called the "Routes Table" and the "Nodes Table". These tables can be accessed by users, and used as a guide when they wish to connect to other stations (or other nodes).
A connection needn't involve just one node, connections can be made (or at least attempted !) by using several nodes. Those who have only had experience with voice repeaters may find it difficult to grasp this concept - it can be likened to a frog crossing a pond, the frog cannot jump the whole pond at one go, but by jumping from one lily-pad to another it can eventually cross the pond. When you connect to a node it is like landing on a lily-pad, you can then "jump" to the next pad (node), and so on.
The ROUTES TABLE is accessed by sending the command "ROUTES" (or R). The node will reply with a list similar to the one below (but longer) -:
0 GB7XX-2 100 5 > 0 GB3YY 50 4 ! : : : : : : : : : : : > ! indicates that these parameters have been "locked" : : : : : in by the "Sysop" (the person in charge of the node). : : : : : : : : : > the number of entries in this node's nodes table. : : : : : : : > the route quality of this neighbour (best = 255, worst = 0). : : : : : > the callsign of this neighbouring node. : : : > "0" = radio path, "1" = wired connection to node (on another frequency). : > ">" indicates that the path is already in use. This doesn't mean that you can't use it as well !
The ">" symbol is relevant because (unlike normal stations), nodes do not disconnect from one another when a user's connection is terminated. Even if there are no other communications going on involving the two nodes, the nodes will continue to periodically ask each other "Are you still receiving me ?" (all in "Level 4" code of course !), for about 15 to 30 minutes after the last users have terminated their connections. This is done to save well-used links having to be re-established every few minutes, thus saving time on air and reducing congestion.
The ROUTE QUALITY of adjacent nodes is usually "locked in" by the Sysop, because when the node "hears" a nodes-broadcast from another node it has no way of telling how strong the radio signal was. The received broadcast could be from another node just 15 miles away, or alternatively it could be from a node 100 miles away and heard under quiet or "lift" conditions.
Usually the Sysop will choose to "lock in" all of the immediate neighbour nodes with their corresponding route qualities, and allow "rogue" nodes to enter the routes table with a default low quality (usually 10 or 20). He might also decide to "lock out" a node (locked with zero quality) if the path is "one-way" (ie can be heard but not able to be contacted). This is important because route qualities are not only for the benefit of the user, they are used by the nodes themselves when they are deciding on the best path for a connection.
As an example, let's consider just three nodes, which for sake of simplicity we will call A, B and C. A cannot "hear" C (and vice-versa), but good radio paths exist between A-B and B-C. B will tell C that it can also "hear" A, but what route quality will C assign to the path via B to A ?
A > route quality = 100 < B > route quality = 100 < C This is where the computing power of the software takes over. There is an established formula which the node uses to calculate the effective "route quality" of the path A-C. This is given by the following formula
( X * Y ) + 128
(A-C) Route Quality = -----------------
256
Where X = the path quality existing between node B and node C.
and Y = the quality of the route A-B as broadcast by B.
If you feel that the maths is getting a bit "heavy", don't worry, this is as complex as it gets ! And if you can't understand the formula, then just try to get the fact that some sort of "attenuation factor" has to be applied, otherwise nodes would claim to be able to connect to any other node in the world, since (eventually) the info about all the nodes would pass unhindered across the network !
To the user, the "NODES TABLE" is a list of nodes to which a usable path exists, and it can be listed by sending a "NODES" (or N) command. This may not be a "one-hop" path, depending on the inter-node path qualities inbetween, an entry on a nodes table could be five or more "hops" away. The nodes table includes both the callsign and the alias of each node, and connect requests can be made to either the callsign or the alias. The user doesn't really have to concern himself (or herself) with the actual path which the connection will take - the node itself only knows the immediate neighbour(s) which claim to have paths to the required node. One can, however, ask the node about these neighbours.
For example, a "NODES" command issued to our node GB7XX sends back a list which includes the following -:
YY2:GB7YY ZZ1:GB7ZZ
How do we find out where a connect command to YY2 would be routed ? We would send the command "NODES YY2" (or N YY2). A typical response might be -:
XX2:GB7XX } Routes to YY2:GB7YY > 100 6 0 GB7QQ 50 4 0 GB7ZZ : : : : : : : : : > Neighbour's callsign : : : : : : : > Port type. 0 = radio route, 1 = "hard wired". : : : : : > "Obsolescence count". Set to default value when nodes-broadcast is : : heard from node. Each unsuccessful connect attempt reduces this by 1. : : A successful attempt will reset this to default value. If this count : : drops below pre-determined limits (usually default - 2), this node is : : no longer broadcast. Default (usually about 6) set by Sysop. : : : > Route quality to neighbour. : > indicates path is in use.
As stated before, the node doesn't know the exact route to each entry on the nodes table (there isn't enough memory to store it), and we do not need to concern ourselves with it either. The obsolescence count ensures that the optimum path is chosen if two or more neighbours with equal route qualities all claim to have paths to our destination.
TheNet, NET/ROM and BPQ nodes use "automatic adaptive routing" which simply means that they can quickly adapt to varying radio conditions. Indeed, the path taken by our connection could change whilst we are connected, as the system is constantly monitoring and adapting to network conditions. If a path should fail while it is in use and the node has an alternative, it will attempt to restore the connection using the alternative. This system is also quick to adapt itself should a node suddenly go "off air" due to a failure somewhere.
Most of the other commands available on TheNet and NET/ROM are fairly self-explanatory. The "USERS" command lists the connections currently existing (or in the process of being made). The command is useful if you're thinking about trying a "DX" connection - this might not be too successful if another user is flooding the node by downloading text from a BBS !
The "CQ" command enables users to connect to a node (either direct or via multi-hop), and then send out a CQ beacon. The Syntax is "CQ ". Those replying to your CQ would connect to your callsign AS IT APPEARED ON THEIR SCREEN.
There is a command "I" (which is INFO on TheNet and IDENT on NET/ROM), which will cause the node to send info about itself which has been entered by the Sysop.
There is also a "PARAM" command - this causes the node to send out a list of numbers which correspond to certain parameters which are set in the node. They cannot be changed by anyone other than the Sysop, so we won't go into details of their meaning.
How does a user know what type of node that he/she has connected to ? Well, a little detective work is required here, since TheNet, NET/ROM, and BPQ nodes all behave in a very similar manner. You can tell a lot from the response of the node to your initial connect request. If the symbol after the callsign/alias is a ">" you are almost certainly connected to a TheNet node. However, both NET/ROM and BPQ nodes respond with a "}", so a little more work is required. Fortunately, BPQ nodes are easily identifiable, as their response to a "U" command will include the G8BPQ callsign and software revision number.
KA nodes don't follow the "norm". They don't work in the same way as the other nodes, but they will at least list the NET/ROM type nodes that they have heard. So an automatic, "multi-hop" link will not use KA nodes. KA nodes always identify themselves as KA when you connect to them. TCP/IP is a complex system of file and message transfer which "rides on the back" of NET/ROM type nodes, and later versions of TCP/IP (or NOS) emulate some (but not all) of the functions of NET/ROM.
...is not encouraged through NET/ROM, TheNet and BPQ nodes ! In fact, the "digi" facility on most of these nodes is disabled, so users would be most unwise to try a multi-node digi ! Where the digi is enabled, it is really there so that "Mail For:" beacons of BBS's can be relayed over a wider area. With all this sophisticated software at your disposal, why should you want to digi anyway ?
BPQ nodes use software written by John Wiseman G8BPQ, and this software enables stations to emulate the workings of TheNet and NET/ROM using an IBM PC/XT/AT computer with TNC's or internal TNC cards. BPQ nodes usually work in conjunction with a BBS or private mailbox.
Most BPQ type nodes will operate on more than one frequency, and the software is configured in such a way as to make it easy for users to choose which frequency to make outgoing connections. For this reason there is a "PORTS" command, and this causes the node to list its port numbers and frequencies. The "ROUTES" command on BPQ will result in a slightly different response -:
> * GB7XX 100 5 !
where the "*" will be replaced by a port number. Connections to other nodes do not normally need a port number, but connections to other stations do. So, on a BPQ node, to connect to G9XXX on Port 3 you would send -:
"CONNECT 3 G9XXX" (or C 3 G9XXX).
If you omit the port number the BPQ node will list its ports and ask you to repeat the connect request using a port number.
73, Nick G6NHK
Note:
NET/ROM is a trade-mark of SOFTWARE 2000 Inc.
TheNet is the copyright of NORD<>LINK Software.
BPQ software is the copyright of John Wiseman G8BPQ.
TCP/IP software is the copyright of Phil Karn KA9Q.
KA is a trade-mark of Kantronics.