What is Packet?

Packet radio has been a way for digital information to be communicated across large distances since 1978, when amateurs in Montreal, Canada developed the Terminal Node Controller (TNC). The TNC is a modem for your computer (or terminal, such as a VT220), batching digital information into bite-sized packets to be sent using standardised tones. The specifications that sit behind these packets being able to be deciphered at the other end form the AX.25 protocol.

Because packet has existed as a way for amateur radio hobbyists to exchange information for more than 40 year, a number of concepts, tools and nomenclature constitute idiomatic packet operation. As I have tried to learn about this networking and communication standard that once competed with TCP/IP, I have struggled to break into a largely forgotten, poorly documented, and rarely discussed world.

This post is intended to be my main location for helpful packet information. If it gets too large I may have to split it up; I hope I might eventually collect enough worthwhile information to justify that.

It starts with some lower level technical detail, but from Original Uses of Packet onwards should generally ease up.

AX.25

AX.25 is the protocol used for amateur packet raido. AX.25 is a successor/spin-off of X.25; the ‘A’ represents the amateur (as in amateur radio) aspect of its creation. The latest specification of AX.25 is available here.

AX.25 is based on the High-Level Data Link Control (HDLC) protocol. The linked Wikipedia page has further useful background technical information on HDLC, much of which is directly applicable to AX.25

References below to layers are made in the context of the OSI Model of communications. If you are not familiar with these, Layer 1 (the bottom) deals with the physical link, and Layer 7 (the top) is the video game/web browser/other use-case you might have. In between both of those stacks are the intermediary layers that manage error control and correction, flow control, any sessions that need to be tracked, and anything else to make a connection work.

AX.25 is a Layer 2 protocol.

Layer 1

Though AX.25 is a Layer 2 protocol, there are some common Layer 1 characteristics that have become commonplace, if not de-facto standards.

AX.25 can operate on high frequency (HF) bands and very high frequency/ultra-high frequency (VHF/UHF) bands. For example, this might mean data around 3.5 MHz, 144 MHz or 440 MHz correspondingly.

Bandwidths on HF frequencies are much lower, and a common transfer speed is 300 baud. At VHF/UHF, this typically moves to 1200 baud and 9600 baud operations are possible. 9600 baud is harder to achieve with a standard VHF/UHF radio, due to more stringent calibration and filtering requirements (like working around FM pre-emphasis filters which are typically installed in VHF/UHF radios).

At 1200 baud, Bell 202 tones are typically used. At 300 baud, Bell 103 tones are standard. AX.25 does not prescribe these, but are the de-facto standards from what I have gathered.

General Frame Types

Layer 2 provides a data link layer, and each transmitted component is called a ‘frame’ at this layer. There are three general types of AX.25 frames:

  1. Information frame (I frame)
  2. Supervisory frame (S frame)
  3. Un-numbered frame (U frame)

Traffic between two connected stations are either I frames, or S frames.

A station may be connected to more than one remote station, just like your web browser can have more than 1 tab open. However, an AX.25 connection in the connected state has only 2 stations.

Frame construction

Un-numbered and Supervisory frames have the following construction:

Flag Address Control Info FCS Flag
01111110 112/224 bits 8/16 bits N*8 bits 16 bits 01111110

Information frames have the following construction:

Flag Address Control PID Info FCS Flag
01111110 112/224 bits 8/16 bits 8 bits N*8 bits 16 bits 01111110

The purpose of drawing out these 2 tables is to demonstrate the addition of the PID field in the Information frame.

Information Frames

Information frames are frames that convey textual information between stations. These are the frames that contain any content.

Supervisory Frames

Supervisory frames can convey four messages, relating to the connection between two TNCs:

  1. Receive ready (RR): the sender is ready to receive more I frames
  2. Receive not read (RNR): not able to process further packets at this time (possibly due to a full processing buffer)
  3. Reject (REJ): missed correct receipt of a packet
  4. Selective reject (SREJ):

Connection/Disconnection Frames

These are the frames that establish and tear-down connections between stations. Please refer to the AX25 specification for more information on these.

Other Frames

Please refer to the AX25 specification for more information on these.

Poll/Final (P/F) Bit

This is an additional bit in the frame the demand a reply to it, ideally immediately. All packets (e.g. INFORMATION, RECEIVE_READY, etc) the option to have the P bit set, which stands for poll and necessitates a reply with the same bit set in the reply, indicating an f or final reply.

The AX.25 specification is based on the High-Level Data Link Control specification, which has a notion of a primary and secondary station. The treatment of the P/F flag depends on the station’s nomination as primary or secondary. However the AX.25 specification specifically mentions this as a point of difference from HDLC:

Most link-layer protocols assume that one primary (or master) device (generally called a Data Circuit Terminating Equipment, or DCE), is connected to one or more secondary (or slave) device(s) (usually called a Data Terminating Equipment, or DTE). This type of unbalanced operation is not practical in a shared RF amateur radio environment. Instead, AX.25 assumes that both ends of the link are of the same class, thereby eliminating the two different classes of devices.

– AX.25 Link Access Protocol for Amateur Packet Radio, Version 2.2 Revision 1998

In AX.25, each node is peered with another — there is no heirarchy.

In the AX.25 protocol, when the P flag is raised, it should be immediately responded to and cleared by its peer. The F bit in response clears a poll.

Original Uses of Packet

In the 1980s and 90s bulletin boards were a commonplace way for people to talk to each other using their computers. Telephone modems allowed a computer to ‘dial’ into a host (usually a nearby technical person, with a dedicated line plugged into a computer), and be presented with a screen of text to navigate forums, chatrooms, and download software. This would be like ‘dialling into’ an ISP, except you had access to only one specific website instead of the whole internet.

Some bulletin boards allowed access not over the telephone, but over the air, using the AX.25 protocol. This allowed the same functionality (text-based communication and binary transfers), without the expense of out-of-area calls, and inconvenience of tying up the home phone.

Alongside bulletin board use, people could make contacts with others just by ‘connecting’ directly to their TNC (modem) and typing. Once sent, a message would be displayed immediately on the screen of the other user, if the screen was turned on. All that user had to do to reply was type back, pressing ‘enter’ to transmit. We’ll explore how the range of these contacts can be expanded later, in the nodes section.

Modern Uses

The Automatic Packet Reporting System is an application typically implemented using the AX.25 protocol (packet radio).

APRS was invented by Bob Bruninga WB4APR (SK), first implemented in 1982. Commonly available today across large parts of Australia and the rest of the world, APRS allows objects to identify themselves, and optionally their position and other characteristics, in an automated way.

Web-based applications such as APRS.fi integrate with this radio-based technology. Other components behind the scenes like APRS-IS integrate the internet with this packet communication method.

Through the power of this connectivity, APRS is able to drive a number of other technologies. One such example is SMSGTE (SMS GATE), enabling radio-only users to send and receive SMSs to/from mobile phone users. This can be helpful in areas where mobile phone coverage is low, but a 144 MHz radio signal can make it out. A range of digipeaters (discussed later) remarkably improve coverage for APRS users.

Types of Packet Messages

A packet bulletin board system (PBBS or BBS) is typically a place to go and read and send messages. Interfaces can vary but it is helpful to think of a PBBS as a single machine with different types of message. There are 3 types of message: personals, bulletins, and traffic. The first lines of a recent bulletin are shown below:

From: VK7AX
To: BCAST
Type/Status: B$
Date/Time: 11-Mar 01:31Z
Bid: 15895_VK7AX
Title: VK National News 05Mar23

R:230311/0142Z @:PI8ZTM.#ZH1.NLD.EURO #:23972 [Zoetermeer] FBB7.00i
R:230311/0139Z @:CX2SA.SAL.URY.SOAM #:24256 [Salto] FBB7.00e $:15895_VK7AX
R:230311/0131Z @:VK7AX.#ULV.TAS.AUS.OC #:15895 [Ulverstone] $:15895_VK7AX

From: VK7AX@VK7AX.#ULV.TAS.AUS.OC
To  : BCAST@WW


VK National News 05Mar23

Text edition:


Weekly news from the WIA:
MP3 edition of news available at: http://www.wia-files.com/podcast/wianews-2023-03-05.mp3
Text edition:


 2023 MARCH 05 VK NATIONAL NEWS BROADCAST ON VK1WIA
------------------------------------------------------------*

 THE BEST NEWS YOU'LL GET ALL WEEK

 THIS LINK IS A VIDEO VERSION OF NEWS COMPILED BY VK5BD BEVAN
 tinyurl.com/WIA-News-Videos

------------------------------------------------------------*

 NATIONAL NEWS FOR WEEK COMMENCING MARCH 5 2023
 IN OUR 28th YEAR OF NON STOP NEWS

 THIS WEEK:-

 Chris VK3FY on behalf of the WIA Board

Personals

Personals are private (insofar as it is still amateur radio) messages, sent from one amateur call sign to another. They are typically not shown to non-pertinent amateurs using the BBS.

Bulletins

Bulletins are messages effectively for ‘broadcast’ of some size. They may be for a defined geographic area, or a given topic. For example, an earthquake in Germany might be sent to QUAKE@DL (DL is the amateur country code for Germany). More information on the ‘@’ annotation is given in BBS addressing.

Traffic (NTS)

Particularly in the US, there is a strong culture of passing third party traffic as part of what they call the National Traffic System (NTS).

That’s much less significant in Australia so I won’t mention much about this scheme. If you are a VK amateur you are unlikely to need to concern yourself with Traffic messages. The ARRL has a page on the NTS.

Nodes

Directly connecting from one amateur station to another and having a real-time chat-like QSO is only a small part of what packet radio can offer.

Radio amateurs may also connect to automated stations, often called “nodes”. These might be thought of as providing a service, and providing unattended service.

Types of Nodes

  • Digipeater
  • Net/ROM
  • ROSE
  • Wormhole
  • BBS/PBBS

I may expand more on this section at a later date.

BBS Software

Below is a list of known BBS software that is reasonably up to date that I have come across frequently through my research.

Briefly, alongside last known update

  • G8BPQ (26 June 2022)
  • F6FBB (26 October 2021)
  • PakCatt (in development, alpha) (16 July 2023)

A very comprehensive list of known BBS software is available at the BBS Documentary website. Note that this website encompasses all bulletin board software, and not those relevant to the topic of amateur radio.

BBS Addressing

Described here

A heirarchical way of nominating a BBS, with the path used for routing information.

Only country and contintent codes are defined in the specification; these are given in tables in the above PDF.

BBS Forwarding

A powerful feature of packet is that remote stations can talk to each other without human intervention, if a suitably protocol is designed. To facilitate forwarding messages from one BBS to another, a number of protocols have been developed to acommodate just this. In particular, message forwarding is a common way for two BBSs to share information. This may involve the one-way or bidirectional exchange of messages between stations.

SID

Forgot everything you might know about other things calls SIDs and SSIDs outside of packet radio, because this is different.

The SID or System IDentifier is a string of characters in the form of [SoftwareName-v.1.2.3-MF$], where this tells the receiving server the name of the software and version number being used to connect automatically for forwarding, and what capabilities are available at that computer. Each letter corresponds to a

SID Capabilities

The following is a reproduction from https://www.scc-ares-races.org/data/packet/docs/W0RLI-BBS_spec_12oct1998.pdf, with additional context from https://www.f6fbb.org/sid.html:

  • $: Supports bulletin IDs (BIDs). This feature must be supported.
  • A: F6FBB protocol acknowledge for personal messages.
  • B: F6FBB protocol V0 binary messages supported.
  • B1: F6FBB protocol V1 binary messages support.
  • C: Supports automatic distribution of current date/time. This feature is obsolete.
  • F: F6FBB basic batch forwarding protocol supported.
  • H: Supports Hierarchical Location designators. This feature must be supported.
  • I: Supports ignoring lines beginning with a ‘;’.
  • L: G1NNA compression supported. When I tried to look this up, all I could find were broken links.
  • M: I’m not sure I understood descriptions of this. Please review source material yourself.
  • R: Extended responses:
    • OK: Send to me
    • NO: Duplicate
    • REJECT: I can’t handle this
    • LATER: Send to me later The difference between NO and REJECT is whether or not SYSOP attention is needed. (A REJECT calls the attention of the SYSOP).
  • S: Unclear
  • T: WinLink
  • U: WinLink
  • X: Supports ihave/iwant compressed batch forwarding. Defines the syntax and use of commands SS, SX, SY. Uses lzh compression

Please note: I have read that the $ character must be the last of the capabilities listed. I have not come across any other requirements for ordering, but I am almost positive some programmes will expect an alphabetical ordering.

The purpose of the SSID is two-fold:

  1. Its presence in the welcome message indicates to the remote station that automated-message retrieval/storage may be supported.
  2. The string indicates which functionalities, exactly, are provided.

The distinction between these two may be slight, however it is important to note that no message forwarding will be supported, and a BBS may be surprised/confused if you try to give it a prompt to forward messages without feeding it an appropriate SSID beforehand.

I have seen welcome message from common BBSs that contain the SSID midway through the welcome message. From this, I understand that the SSID need only be present somewhere in the server’s first response. The SSID needs to be on its own line.

W0RLI

This document is the only one I could find that encompasses the “W0RLI protocol”, which was one of the earliest protocols for managing messages across multiple bulletin boards. Most subsequent bulletin boards are based on, or support, this protocol. However, documentation elsewhere is scant.

F6FBB Protocols

F6FBB, as a newer programme, offers updated forwarding protocols.

There are three protocols that F6FBB supports anew:

  1. ASCII
  2. Binary version 0
  3. Binary version 1

Appendix