All About Digipeaters

And how to set them up for Packet Radio...

Digital repeaters, also known as digipeaters, form the backbone of any packet radio network which is responsible for the reliable transmission of information sent across long distances from one station in a relaying path to another.

Since the earliest days, when an insistent sender had to get the message through to an anxious receiver, the concept of message relaying, whether it be by human runners, horse-mounted couriers, or chariot drivers, has been well known to communicators who were dispatching news, military orders, or military outcomes to those standing by.

In our more recent era, "live" transport has been replaced by inanimate, elemental signals, such as: fires, smoke signals, light beacons, flags or semafores, and even mechanical contrivances . Each relay "station," usually on a high tower perch, copied and then faithfully repeated the message along to the next station in the chain until it reached its final destination... The "news" was either good or bad, with very little indifferent "chit-chat" since the authorities that were, owned, operated and maintained these information systems abiding a minimum of trivia.

And even though message through-put could be amazingly fast, since "compression" codes had been developed and applied since earliest times, it is clear that the bandwidth was practically non-existent. Only really urgent and important messages ever were sent over these "imperial/royal" relay channels.

In the middle of the nineteenth century, the telegraph, an electro-magnetic and mechanical device, not only increased transmission speeds, but also made possible the popularization of "information technology" by selling telegraphic services to anyone who could pay the cost of a telegram. Despite the near monopoly of commerce's interest in this utility in the early days of its development, telegraphy laid the public networks foundation for the telephone, and even radio communications systems, available to all, spanning the entire globe, oceans and continents alike.

Perhaps at no other time was the engineering of the "relay station" more innovatively developed than during the installation of the global telegraphic network. Since the medium of transmission was iron or copper wire, none of this would have been possible without the regeneration or amplification of electrical signals. Edison, among other notables such as Samuel F.B. Morse (his circuit relay), filed for numerous patents whose sole objective was the accurate, and possibly simultaneous, continuation of electric signals down a resistive, amazingly lossy wire! (Morse actually preceded Edsion by several decades in this regard, developing the first true telegraphic relay system which was no longer impeded by distance.)

Today, we can see the evolution of these basic relaying concepts in our cell phone networks, and to a lesser extent, in our radio and satellite networks. Elelctro-magnetic emission has added complexity to the fundamental network principles by broadening the single "telegraphic" or line-of-sight path into a radial distribution pattern, a broadcast area. For every transmitter, there can be numerous receivers, which in turn may become transmitters themselves. It is clear that this type of "propensity to communicate" needs to be carefully managed and accounted for. This is what digipeating, and especially TCP/IP oriented networks with digital relaying as their underpinning, strives to do!


The Ins and Outs of Digital Repeating

Departing from our brief historical sketch above, what does a digipeater actually do? It listens for a packet, part of a larger message, on a given frequency, and once having copied the packet completely, sends it on to the next station, usually but not always, on the same frequency. Before it sends the next packet, it must be sure that the last one was copied correctly, also known as end-to-end acknowledgement, (as opposed to node-to-node acknowledgement which only has to check on the last node). Even if there are eight intervening stations in the chain (the maximum allowed by the AX25 protocol), it will not continue sending more of the message until the current packet that is being transmitted has been faithfully delivered to the very end of the path, the destination station. Then, and only then, will it send the next packet! (Any failed attempt has to begin again from the very beginning, not the last successful node.)

This seems like a torturous endeavor indeed! And if you have ever watched a "doomed" packet time-out or try-out just before making the last station, you know what I mean! For this reason, most digipeating is best accomplished using fewer rather than greater intervening station nodes. Typical numbers are one, two, or perhaps three stations, depending on the quality of the links of course. Occasionally, you may even see five or six, but this is rare! So the moral of this story is: choose your digipeaters well! In a metropolitan region, it is likely that you may have more than one route or frequency that you may choose to reach your destination. You should choose the best one on average since route reliability may vary considerably at different times and on different days due to VHF conditions.

Let's look at a few digipeater topics which include: how to turn on digipeating, how to use it, how to expand its usefulness, and how some of the "internals" work...

Enabling your Station to Digipeat

At first, this might seem like a bogus option. Isn't it obvious that everyone wants to digipeat? After all, this is the essence of packet radio! But there may be times when you don't want to digipeat. Suppose you were running a remote weather station that linked back to you via a "dedicated" packet channel. The last thing you would want is people using your weather station in a digipath. So here is a point-to-point case where you would disable the digi option. Note that users could still directly contact your weather station and make a connection from there to another location. But it would discourage its ease-of-use by disallowing any stations' inclusions in the AX25 routing table. (It is this table that remembers the relaying paths, generally based on operator usage.)

You can probably think of several more examples where you might want to discourage digipeating, and note I say discourage, because you really can't prohibit someone from connecting and then connecting again to the station they want. In general, a station that thinks of itself as strickly a destination may want to consider disallowing the digipeater option.

But for the rest of us, bring on the digipeating! Can we really span across our state in eight hops or less? And, how do we do this? Be it also noted that in today's TNCs, digipeating is usually automatically set up for you as the default. However, I suggest that you specifically set or unset a digi flag for each device/interface you plan on using as a way of documenting the state of this mode.

For example, in the *NOS family of BBS software, to enable digipeating on a device, you would issue this command syntax either from the console, or more typically from the autoexec.nos file:

  • ax25 digipeat <device> [ on | off ]


If you are running more than one device, you could issue this sequence of actual commands in your autoexec.nos, one per interface:

  • ax25 digipeat ax0 on
  • ax25 digipeat vhf on
  • ax25 digipeat bc0 on


If you are using a Kantronics TNC not in KISS mode:

Kantronics:
KAM, KPC3,
etc...
If you are running a Kantronics TNC, you may optionally set digi to on by issuing the "DIGIPEAT ON" command using the setup software supplied. (Although, it too defaults to "ON" and, if you are running a KAM, this command will simultaneously apply to both its vhf and hf interfaces. At least it does on my older KAM.) The "DIGIPEAT OFF" command shuts digipeating off for any or all of the TNC's devices...


If for some reason you want to disable digipeating, you may issue this command from the console, the autoexec.nos file, or a script file:

  • ax25 digipeat hf off


Here digipeating for the hf (high frequency) interface has been disabled, as is recommended by the NET105 guidelines. This means that operators cannot relay through you, but rather have to connect to your BBS and then initiate another connect to the destination station. (This is strongly encouraged on hf packet due to its lower 300 baud speed and its annoyingly relentless persistence when not completing a requested link.)

NOTE: As an intended or unintended consequence, if you turn digipeating off, no entries for that device will be made automatically (Auto) in the ax25 routing table.

My version of JNOS1.11f, and perhaps other *NOSes, defaults to all devices being in digipeater mode at startup, according to the documentation that came with the package. But for clarification, and documentation purposes, I would still set the flags manually as shown above in either the autoexec.nos or script files.

How to Digipeat as a Packet Radio Operator

Once you have enabled your machine for digipeating, all that is left to do is to try it! The first step is to look through your "heard" list and attempt connects to as many stations as you can. You may be able to connect directly to them all. In that case, you may not need digipeating right away. But, if you find some you cannot link to directly, then here is a opportunity to test your station's reach by digipeating over a multi-node path.

Sometimes, it is easy to get confused about how to make a request from your machine to set up the digipath. After beginning with the "c" for connect, the next item is usually the device to send it out on, such as ax0. The next in the syntax statement is the destination station, or the final stop for your message or connection. Now the next station(s) will be the one(s) you will be using as the digipeater(s) and they will build a path as you think it should be. Let's look at an example:

  • c ax0 ka1oxq we1ct


Our destination station is ka1oxq and we will be using we1ct as the first, and only, digipeater in the path on device ax0. If you look at your trace screen, you should see the relay station returning an acknowledgement (RR) with a star or asterisk after its name. Something like this:

  • KA1FSB-15->KA1OXQ v WE1CT*


When you see the asterisk, you know that the relay request has been forwarded by the digipeater station WE1CT. When the destination station acknowledges, the trace line will look like this:

  • KA1OXQ->KA1FSB-15 v WE1CT*


As you can see the digipeating station WE1CT still shows its asterisk since it has successfully relayed the RR, Ready Receive, control data. If there are no asterisks, then the digipeater did not do its job!

So, the general syntax for a digipeat command is:

  • c <device> <destination> <first_node> [<next_nodes>]


Where device is something like ax0, ax1, bc0, bc1, etc, and destination is the callsign of the target station, and first node is a single digipeater, and optional next nodes are station names separated by a space, which make up the digipath to the target destination... Here is an example of a path set up for two intervening relaying stations:

  • c bc0 n1uro-7 we1ct ka1oxq


The destination is n1uro-7 with we1ct being the first relay and then ka1oxq being the last relay in the chain.

NOTE: Some software requires a "v" for via between the destination station name and the rest of the path. Most *NOS systems do not need this, although you may optionally include it if you wish...

As a result of this contact, a digipath or route will be automatically recorded in the AX25 routing table as seen below:

AX25 Routing Table 
Target    Iface  Type  Mode Digipeaters
N1URO-7   bc0    Auto   IF  WE1CT KA1OXQ


The next time you want to contact n1uro-7, all you will need to do is "c ax0 n1uro-7" and the routing table will look up the destination station as its data key returning the digipath as found under Digipeaters in that table. Saves you a few extra key strokes and is usually regarded as a nice convenience...

That about sums up digipeater operations! Keep those paths short, but on a good day, why not see how far digipeating will take you!

Crossband and Multiport Options

In the *NOS family of BBS's, it is possible to receive connections on one frequency and have them sent out on another! If you were connecting on a UHF port and digipeating through a VHF port, this would be classified as crossband operation. If you were crossing between two frequencies in the same band, this is known as multiport operation. (And just a reminder; you need the hardware that supports two radio nets: the antennas, the radios, the TNC's, and associated cabling. These networks are two independent radio systems, so there is some expense involved unless you happen to be running more than one radio to begin with... Most Hams typically run one VHF channel.)

For example, let's say a station was contacting me on 145.090 and wanted to reach a station on 145.010. I could set up a multiport operation on ka1fsb-4, whose sole job is to link these two frequencies together, making digipeating between them possible. Note that ka1fsb-4 cannot be contacted directly, but may be used in the digipath as the linking station.

To illustrate further, let's say you are on 145.090 and wish to connect to wc1ma-7, a MEMA station on 145.010. You could connect to me, ka1fsb-7, and then re-connect to wc1ma-7. But can you do this in one operation? And, the answer is yes if you use the multiport option. Here is the command line to use from your BBS:

  • c ax0 wc1ma-7 ka1fsb-4


Assume that ax0 is your *NOS device for 145.090 and wc1ma-7 is on 145.010. The callsign ka1fsb-4 has been configured to bridge these two frequencies. This one op will make the connection.

Why else might you want to do this? If you are sending smtp mail and/or running tcp/ip , you can begin to configure your node as a true router. In other words, a subnetwork is typically built around a frequency. If you want to send mail across subnets, i.e., different frequencies, here is a way to form that bridge. Recall that all successful ax25 links are stored in the ax25 routing table by their primary key, which is the destination callsign. That callsign extracts all the path information for a particular route and it may certainly include a multiported station! This is the layer that is handled by ax25 and remains virtually "unseen" by any tcp/ip operation such as mail or telnet or ftp! So, you might be sending mail across several frequencies or subnets via many routers without really ever being aware of these paths... very much in the same way that the internet works.

To implement this crossband or multiport option, you must first choose a callsign with a free SSID for your two devices, which will serve as a common link. I chose ka1fsb-4. As mentioned above, you cannot connect to this callsign directly. You may, of course, build it into a digipath. To actually set up the option on a device, you may enter it from the admin console, include it in the autoexec.nos, or a script file to be ultimately called by the autoexec.nos. Here are the command lines using the special instruction word, cdigi:

  • ifc ax0 cdigi ka1fsb-4
  • ifc bc1 cdigi ka1fsb-4


It goes without saying that you must always have a pair of devices to be linked across since packets arriving on one port or device, will then be sent out on the other and visa-versa. (You can think of these two devices: ax0 and bc1 as being a dedicated "married" couple... :)

After issuing these commands, the ifconfig table as shown by the "ifconfig" command will have additional information on the second line. You will see the key command word Cdigi followed by your choice of callsign for this bridge or crossover SSID.

Ifconfig Tables for Devices: bc1, ax0

 
bc1    IP addr 44.56.20.86 MTU 256 Link encap AX25
       Link addr KA1FSB-7   BBS KA1FSB-7   Cdigi KA1FSB-4   Paclen 128   Irtt 5000
       BCText: KA1FSB-8/N AX25 Utilities <-> KA1FSB-7/N JNOS [Wellesley, MA] 
        Multiport JNOS Digipeater KA1FSB-4 145.010<->145.090
       flags 0xcb3 trace 0x311 netmask 0xffffff00 broadcast 44.56.20.255
       sent: ip 0 tot 50 idle 0:00:06:50
       recv: ip 0 tot 82 idle 0:00:06:39
       descr:  VHF port on 145.010 BAY    MDM 1200 baud (WC1MA, MBOS:N1CSI)
  IN:  82 pkts
  OUT: 50 pkts

ax0    IP addr 44.56.20.86 MTU 256 Link encap AX25
       Link addr KA1FSB-7   BBS KA1FSB-7   Cdigi KA1FSB-4   Paclen 128   Irtt 5000
       BCText: JNOS/Linux-1.11f * 44.56.20.86 * 14.105<>145.090 [Wellesley, MA]
        Multiport JNOS Digipeater KA1FSB-4 145.090<->145.010
       flags 0xcba trace 0x311 netmask 0x00000000 broadcast 0.0.0.0
       sent: ip 0 tot 114 idle 0:00:06:09
       recv: ip 0 tot 786 idle 0:00:00:13
       descr:  VHF port on 145.090 KAM    TNC 1200 baud (W1JOE-7, ->N1MNX-4,N1XTB-5)
  IN:  786 pkts
  OUT: 114 pkts


To "advertise" the multiport capability, a mention about the two "linked" frequencies has been included in the BCText string for each device. And, to offer help about how to use this facility, a screen can be called up using the xband alias command which displays a brief explanation contained in a file named /jnos/pub/xband. (This is how it is currently done on my JNOS system.)

An Alias-driven Help Screen for Multiport Devices 
01-18-06
--------

Crossband/Multiport Digipeater Operation:

Use KA1FSB-4 to send packets between 145.090 and 145.010.

For example, from 145.090, "c ax09 wc1ma-7 <some_digi_090> ka1fsb-4"

Normally wc1ma-7 is on 010. But ka1fsb-4 will make the connect
on 010 to wc1ma-7 via <some_digi_090>. 

See "help xband" for more information...

WELLS:KA1FSB-7 Area: ka1fsb Current msg# 0.


Anatomy of a Packet Frame

Rarely will you ever see a real, "raw" packet, on the air or anywhere! Most views of them are translated by programs which pull out, or abstract, certain parts in certain formats. Maybe the closest would be something in hex. But who can read hex with any fluency? (Probably only another machine.)

Any representations that we see, we being humans, will have been greatly modified for readability and understandability. However, these renditions will contain all the information that we are interested in. This data usually presents a time/date stamp, a port or device name, the ID of the sending and receiving stations, followed by some "funny looking codes," and then at last the text message, which may be a beacon, an encrypted mail document, or the body of an actual conversation. This is what we see when we run our trace or listening programs...

But what about the byte layout for a packet frame. Here is a typical Information frame:

Information Frame Layout: 7 Fields
Flag   Address   Control PID Information FCS Flag
8 Bits 112 - 560 Bits 8 Bits 8 Bits N x 8 Bits 16 Bits 8 Bits
(Frame Start)
01111110 		Destination,
Source Stations
or, Digipath 		Frame
Type
I,U,S 		Layer 3
Protocol
Type 		User Data
Goes Here 		Computed
Check
Value 		(Frame End)
01111110


Information frames are the building blocks of any linked, connected data interchange for the AX.25 protocol.

There are also unnumbered and supervisory frames. Their layouts are both nearly identical to the above information frame layout except they contain no PID field and no Information field, no data. They are used to manage the packet flow and message reconstruction at the sending and receiving stations, respectively. These frames act as the "switchers" which tell the processes when it is OK to send, or when to shut down, or when to keep on trying... the foundation of packet communications.

Let's look at the byte fields in more detail:

Field Descriptions
Flag:
The flag field contains a special hex symbol 7E which acts more like a separator then a conventional programming flag. Whenever the software encounters this symbol, it means either we are beginning a new frame or just ending one. The receiving buffer no doubt keeps reading the frame until it "sees" this flag, and then it parses the buffer breaking out the fields into memory areas which can be evaluated by the network code.
Address:
The address field essentially contains the digipath: that is, the name of the source and destination stations and any intervening stations that make up the relay path. The data itself are the callsigns with possible SSID's, Secondary Station IDentifers. This path data is sent along to every station so that it knows exactly where it is in the chain. (It finds and compares its current hostname or callsign in the digipath and keeps an accounting of which stations have successfully digipeated, advancing to the next only after verifying the current link.)
Control:
This stores the name of the frame type such as: Information, Unnumbered, or Supervisory using a descriptive set of state identifiers such as: UA, RR, I, REJ, SABM, D, DM, to name just a few. This information is often displayed in packet monitoring software, and are what I call the "funny looking codes..." (It also assigns sequence numbers to frames, helping to manage the flow control.) To the novice operator, this information can be rather arcane at first glance, but the seasoned operator comes to rely on it to quicky follow and summarize what is happening to those packets!
PID:
Protocol IDentifier, Layer 3 type, this specifies the type of service, TOS, that will be used by the network layer, if you are using it! For Layer 2, the link level, using AX.25, this field will be null or blank. However, if you are running TCP/IP, this field will hold a hex number code that corresponds to: IP, TELNET, FTP, DNS, IMAP, SMTP, etc.
Information:
This field contains the message, or what you typed in and intend to communicate, which is the text body. It is usually in the form of string ASCII data, or if mail, encrypted for purposes of compression and speed.
FCS:
Frame Check Sequence - Just before sending a frame, a quick check is performed to measure its size. This data is then stored in the FCS field and will be read on arrival at the receiving station, which also does its own verifying computation on the frame size. If they match, then it is assumed that the frame made it "in one piece." If it doesn't match, then the frame is discarded, thrown out, and the frame is sent again. Either, the receiver tells the sender to send again, or the T1 timer expires in the sender, and it gets sent again anyway.


The development of internet and AX.25 packet protocols is a facinating subject, and we have just touched the surface here. The main emphasis has focused on the practical aspects of setting up your station as a digipeater and exploring some of the operational aspects. But, if you have the time, researching the background material mentioned above, will prove to be well worth your efforts...

(Courtesy KBNorton Computer Services)