Packet Procedures


The National Traffic System (known as NTS) is the ARRL-sponsored Amateur Radio message-handling network. Since there is no chain of responsibility for traffic on packet it is recommended that an operator doesn't introduce messages into the packet system as NTS TFC.

Handling third-party traffic is the oldest tradition in Amateur radio. This is most valuable during disasters. Nationwide, the National Traffic System has hundreds of local and section nets meeting daily in order to facilitate the origin and delivery of such messages. Check with your Section Traffic Manager for times and frequency.

If the packet system had a chain of responsibility this is how you would become involved in NTS via packet. If an operator knows nothing of NTS, this section will provide a good introduction. Local packet BBSs have to be checked daily for traffic that needs to be delivered or relayed. When connecting to the local BBS, 'List Traffic' by typing the 'LT' command. The BBS will sort and display a list of all NTS traffic awaiting delivery.

It will look similar to the following:


7893 T 486 60625 KB6ZYZ NTSIL 1227/0712 CHICAGO 312-267
7802 T 320 06234 K6TP NTSCT 1227/0655 NEW HAVEN, CT
7854 T 588 93432 KA4YEA NTSCA 1227/0625 CRESTON, CA 93432
7839 T 412 94114 KK3K NTSCA 1227/0311 SAN FRANCISCO
7781 T 298 68502 W1KPL NTSNE 1226/2356 LINCOLN NE 402-483

Also possibly displayed: traffic that is being relayed by the local BBS to some other part of the country as well as traffic for the local area. The 'Subject' or 'Title' column of the listing will show the destination of the traffic. If the operator sees see a message that is within the local area, help out and deliver it.


To take a message from the BBS for telephone delivery type R followed by the message number. Using the list above, R 7781 would 'Read' (download to the operator) the message from W1KPL for Lincoln, NE. The message will be in a special NTS RADIOGRAM format, with a preamble, address, telephone number, text and signature, ready for delivery. After the message has been saved to disk or printed, the message should be erased from the BBS. Use the KT command, which means 'Kill Traffic', followed by the message number. In this case, type KT 7781 to erase the message. This prevents the message from being delivered again by someone else.


Once the operator has received the NTS Radiogram, it should be delivered with in three days. If the message cannot be delivered or relayed it within 3 days it must be serviced back to its originator. In this case, W1KPL. If the message is for the immediate area, deliver the message.


Any amateur can send a message on behalf of another individual; regardless if that individual is a licensed amateur or not. It is the responsibility of the originator, however, to see that the message is in proper form before it is transmitted.

A specific format is used for NTS traffic so that messages are compatible across the entire network. Each message originated and handled should contain the following components in the order given: number, precedence, handling instructions (optional), the station of origin, check, place of origin, time filed, date, address, telephone number, text and signature. Check the ARRL publications or K0KKV for details on message preparation (Look in the data files under NTS).

When the message is ready to be entered into the local BBS, use the ST command, which means 'Send Traffic', followed by the zip code of the destination city, an '@' and 'NTS' followed by the two-letter state abbreviation.


     A message being sent to Boston, MA 02109 would be typed:

ST 02109 @ NTSMA

A message for Iowa City, IA 52245 would be typed:

ST 52245 @ NTSIA

The message SUBJECT or TITLE should contain the destination city, state and the telephone area code and exchange, if available (See the examples in the listing above). Only one NTS message should be included in each packet message. The actual radiogram should be included entirely within the TEXT of the packet message, including all of the components listed above. End the message with Ctrl-Z (Press the Ctrl and the Z keys together and then press on a separate line from the message).


The National Traffic System functions on a daily basis as a public service for both amateurs and the general public. It serves another function as well: the NTS provides a well-oiled and well-trained national system of experienced traffic handlers able to handle large volumes of third-party traffic accurately and efficiently during disasters.

The ARRL booklet 'An Introduction to Operating an Amateur Radio Station' offers detailed information on handling and preparing NTS Radiograms. The 'Files' section of the K0KKV BBS has further instructions on NTS. There are files such as 'Delivery.NTS', 'Howto.NTS', 'Whatis.NTS', as well as several other helpful files.


The following section will define in detail the various parts of the packet message. The following is an example of what will be seen when listing or reading messages on a BBS. On some systems, the information is displayed in a different order.


4723 P 1084 N4FAD W7ARN N5SLE 0604/1240 Packet up!!

The message number is assigned by the BBS program when the message is entered and cannot be changed. The numbers are assigned sequentially.

STATUS shows several pieces of information about the message: the first letter of STATUS indicates the TYPE of message: B for Bulletin, P for Personal, or T for Traffic (NTS). Bulletins are messages of general interest to all users, and are available to be read by anyone using the system. Personal messages are listed for the sender and the addressee, and only they can read them. (Of course, anyone in monitor mode can see a message of this type as it is being sent, because nothing on packet is private.) Traffic messages are for relay on the National Traffic System.

STATUS will also show if the message has been read, has been forwarded to all designated stations, is in the process of being forwarded, or is an 'old' message. One of the following letters may be listed in addition to the B-P-T designator:

  • Y - yes, it has been read.
  • F - it has been forwarded,
  • I - it's in the process of being forwarded now on another port.
  • O - the message has been on the BBS long enough to become an 'old' message. 'Old' can be anywhere from two days for an NTS message to 4 weeks for bulletins. The time frame for each message type is specified by the local sysop. The 'O' is mainly used to catch the attention of the sysop.

SIZE indicates the combined total of characters, including punctuation in the message.

TO is the callsign of the addressee or is used to categorize messages on particular topics. A message addressed TO AMSAT, TO PACKET or TO ARRL will actually be a message about AMSAT, about PACKET or having to do with the ARRL.

FROM shows the callsign of the station originating the message. @ BBS is used if the message to be forwarded to someone at another BBS or to a specific designator. In the earlier example, the message would be automatically forwarded to N4FAD at the N5SLE BBS. Special designators, such as ALLNE, in the '@ BBS' column, will multiple-forward the message to all BBSs in Nebraska.

DATE and TIME as stamped when the message was received at K0KKV. The date and time are shown in the format used by K0KKV, and will be Zulu (or UTC) time.

SUBJECT (or TITLE) is a short statement describing the message. It should be brief but informative - again, this may be the most important entry for bulletins: this is the information that determines whether or not a person is going to read the message!

The parts of the message described above are parts of the header, and are seen when listing messages (the L or LL command). The remaining parts are in the body of the message, and are seen only when the message is read.

If a message has been forwarded from another BBS, forwarding headers will be seen at the top of the actual message. This information is added by each BBS used to transfer the message from origin to destination.

Each BBS adds one line: date/time the message was received by that particular BBS, BBS callsign, QTH, zip code and message number. Other information is often added at the discretion of the sysop there.

When R 7823 is entered, headers are reduced to a list of the BBS callsigns. Complete headers are useful to determine how long it took a message to be forwarded, and be used to determine the message path. To do this use the RH command when reading a message.
Example: RH 7823

THE TEXT of the message contains the information for the reader. It can be any length, although in practical terms, three Kilobytes should be the upper limit. When preparing a message to be uploaded to a BBS or when entering a message into a BBS, press the 'Enter' key or 'Return' key at the ends of the lines, just like using a typewriter. DO NOT allow the automatic wrapping of lines to occur. A message entered without Returns is very difficult to read, as words are cut at improper points, lines vary in length, and blank lines are often inserted.

Complete the text with either a Ctrl-Z or type '/EX'. On any BBS, this must be on a line by itself. This tells the system that message entry has been finished.

Messages to be forwarded to several BBSs or across long distances should be limited in size. Extremely long messages can tie up the forwarding system unnecessarily, so users are requested to break up long messages into several parts, each of which should be no longer than two to three kilobytes.


The 'White Pages' were initially designed by Eric Williams, WD6CMU, of Richmond, California. It's a database of packet users showing their name, home BBS, QTH and zip code, and is updated and queried by packet message, allowing stations from all over the world to take advantage of it.

As users enter their name, home BBS, QTH and zip code into the BBS user file, the software automatically assembles a message once a day containing all of the latest user information and sends it to the WD6CMU White Pages.

The WP feature has now been expanded, and each BBS can now elect to operate its own White Pages database. Each BBS, however, continues to send a daily 'WP' update of new or changed information to the WD6CMU White Pages. It's easy to make use of the packet White Pages information, both at the local BBS and at WD6CMU.

If the local BBS is operating with its own WP database, the operator may make inquiries using the 'I' command: type 'I' followed by the callsign for which data is requested.



     For information on WB9LOZ, type:


Information from the WD6CMU White Pages is obtained by sending a message to 'WP @ WD6CMU'. Capital and lower case letters may both be used within the message.

The operator may also update the database with new information. One message can contain several lines, including a combination of queries and updates. Since the messages are read and answered by the WP software and not a person, each line must be in the proper format. One of the following formats must be used:



This is a query. A message will be returned to the operator giving the home BBS, QTH and zip code of the person with the leading callsign. If the information is not available from the WP database, the return message will inform the operator.



This instruction adds or changes the entry for the given callsign. When updating or adding an entry to WP, make SURE that the information is accurate.


     DE  @ 

This format gives a return address for the requested information. Replies will be sent to the originating station at the BBS specified. If the return address line is not given, the WP program will attempt to determine the originating station and BBS from the message headers.

Examples (messages to the WD6CMU White Pages database):

     1. The operator needs the home BBS of K9AT:

Enter title of message:
Enter text:

2. The operator needs to update or add information to the WP:

Enter title of message:
Enter text:
N0XYZ @ W0BBS 68510 John Lincoln NE
AD6ZZ @ WB6ABC 94015 Anne Daly City, CA

3. The operator needs to both query and update the WP:

Enter title of message:
Enter text:
N0XYZ @ W0BBS 68510 John Lincoln NE
AD6ZZ @ WB6ABC 94015 Anne Daly City, CA

Like other packet messages, those addressed to WP @ WD6CMU are forwarded from BBS to BBS to their destination. When a message containing new or updated information passes through a BBS operating the WP program, the software recognizes the WP format and extracts the information from the message for its database. The WP program also collects data from any WP responses it sees and from the message headers of every message that passes through. In addition, if a BBS operating with the WP sees a query, it will respond with any pertinent information it has available. As a result, the operator may receive more than one response to a WP query.

The information on each callsign in a WP database is active for no more than 90 days if not updated. This keeps each local database current and at a manageable size. The WD6CMU White Pages directory retains the data for a longer period of time. It is important, when checking into a new BBS, to always enter the same information entered previously. The operator should choose one home BBS, where all messages for that operator are to be sent - enter that callsign each time it's requested. If two or more BBS callsigns are used, the operator's mail be could end up on more than one BBS.

When a message arrives at the destination given in the '@ BBS' column, the software checks the WP information to make sure the message was delivered to the correct BBS. If it finds a different BBS listed as the home BBS, it will insert the new BBS callsign and send the message on its way..., and the operator may never get it.

If the operator moves, or changes the home BBS, then make sure that the WP information is updated in the White Pages database. The BBS will send a WP update message if the N, NH, NQ and NZ commands are used. If these commands are not available on the local BBS, the operator will need to send an update message directly to WP @ WD6CMU. It's an excellent idea to make sure that the information in the White Pages is correct - this will help to get all messages delivered to the correct BBS.


Message forwarding to other BBSs transfers mail automatically and according to a predetermined list. Forwarding normally occurs during off-hours to minimize traffic congestion on the frequency, or it may forward the messages on a different frequency.

Each BBS maintains a list of all stations and their 'home' BBS. Once each hour, the BBS checks the mail file for messages to be passed to a station on the forwarding list. If there is mail to be transferred and it is the proper time to forward to that station, the BBS goes off line, connects with the other BBS and sends the mail. If the connect is not successful or the other BBS is busy, the mail is not forwarded and the BBS waits until the next forwarding time (generally an hour later) and tries again.

Each BBS in the link is assigned a specific forwarding time - a certain number of minutes after the hour. These are coordinated to prevent two stations from trying to forward to each other at the same time. When not inhibited, forwarding occurs at the same time each hour for a given station. Start and stop times can also be specified for each forwarding time - to each destination. This allows inhibiting the forward process during peak 'operator' times.

The SYSOP (BBS System Operator) is responsible for setting up and maintaining the forwarding files. Mail sent to a user at another BBS will automatically be forwarded if that user is in the forward file or the sender identifies the other BBS by using the '@ BBS' phrase. Typically, all BBSs in a given area will have entries in their forwarding files for all other BBSs in the area; sometimes even for the entire country.

To send a message to WB0TDB: if the operator knows that WB0TDB's home BBS is WA0PXW, all the operator needs to do to address the message is type S WB0TDB @ WA0PXW. The local BBS will then forward it to WA0PXW.

If the operator travels and wants to operate packet at other BBSs, it would be a good idea to add an SSID number to the callsign, such as WB0TDB-1. Subsequently, when the BBSs share forwarding files, only one (the home) BBS will have the 'plain' callsign (WB0TDB), and mail sent to the operator will be forwarded to the proper BBS (and not to numerous ones).

Not every BBS is set up to forward to each packet user. The only way for the SYSOP to know the operator's home BBS: send a message to the home BBS SYSOP and request that other BBSs be informed of the operator's 'home' status. Then, if someone posts a message and does not specify the home BBS when sending the message, the BBS itself will have a record in its forwarding file of the callsign and home BBS. The 'foreign' BBS will then automatically forward the message to the proper BBS.

There are certain 'ALL' destinations that are used to send mail to all users at a remote BBS. For example, ALLAK will distribute a message to all ALASKAN BBSs, and ALLUSA will do for ALL BBSs in the USA. What 'ALL' designations are available, and where the messages will go are determined solely by the SYSOPs of the various BBSs. Some SYSOPs will post a copy of the BBS's forwarding files for those interested. This file defines 'what goes where'.


All BBS software writers have devised a scheme called HIERARCHICAL ADDRESSING. With hierarchical routing designators, a significant improvement in traffic routing is apparent. No longer will a missing callsign in a BBS forwarding file cause a message to remain unforwarded; sysops will no longer burn the midnight oil trying to keep their forward files up-to-date, and messages will move much more directly toward their destination.

The format for hierarchical routing is:



It may look complicated, but it's not. First, note that each section of the format is separated by a period.

Codes used for the countries and continents are standardized and accepted throughout the world. The Continental Designators are:


EURO -- Europe
MEDR -- Mediterranean
INDI -- Indian Ocean including the Indian subcontinent
MDLE -- Middle East
SEAS -- South-East Asia
ASIA -- The Orient
NOAM -- North America (Canada, USA, Mexico)
CEAM -- Central America
CARB -- Caribbean
SOAM -- South America
AUNZ -- Australia/New ZeAC -- Eastern Pacific
NPAC -- Northern Pacific
SPAC -- Southern Pacific
WPAC -- Western Pacific
NAFR -- Northern Africa
CAFR -- Central Africa
SAFR -- Southern Africa
ANTR -- Antarctica

The continental and Country Designators are available in the 'Files' section of the local BBS.

State and province codes are the recognized two-character codes established by the American and Canadian Post Offices. These may be found in the Callbook, the local phone directory, or any zip code listing.

The code for local area or county is headed by an octothorpe (#) and is optional, since the operator seldom knows what code is being used back in upper New York state or in Iowa City, IA. If it's known, use it, since it will help get the message closer to where it is going.

The Japanese networks (and possibly other areas) want to use routing numbers for the local area and/or county codes. These could become confused with zip and postal codes, so the # in front of these local area codes destroys their designation as numbers.

As examples, the code for Northern California is #NOCAL, and the code for Southern California is #SOCAL. For messages going outside of the US or Canada, the local area is optional and the state is normally eliminated.

Some routing examples using the hierarchical format:



Two very important points need to be emphasized:

1. Hierarchical addressing DOES NOT indicate a forwarding PATH.

2. Only ONE BBS callsign should be included in the address.

A list of BBS calls separated by dots WILL NOT get your message to its destination. The addressing scheme is said to be one area inside another area.



Ed's Hierarchical Address: KB6DRN @ K6RAU.#NOCAL.CA.USA.NOAM

Ed's Call--------: KB6DRN
Ed's BBS---------: K6RAU
Ed's Local Region: #NOCAL (optional)
Ed's State-------: CA
Ed's Country-----: USA
Ed's Continent---: NOAM


Marks's Hierarchical Address: WB9QZB @ N3AIA.IL.USA.NOAM

Mark's Call------: WB9QZB
Mark's BBS-------: N3AIA
Mark's State-----: IL
Mark's Country---: USA
Mark's Continent-: NOAM

Note that each element of the hierarchical address must be six or fewer characters.

There are several BBS programs that implement hierarchical addressing now, including the W0RLI, AA4RE and WD6CMU software. Check the ID block displayed when logging onto the BBS: if it has an 'H' in the block (such as [RLI-9.07-CH$] or [4RE-02.4-HM$]), the BBS system supports hierarchical addressing.

This section explains how the BBS software uses hierarchical addressing. First, it's necessary to understand how the software matches items in the '@ BBS' address with items in the forward file.

For example, if a message is sent to W3IWI, who operates his own BBS and is located near Baltimore, Maryland, the following would be entered:



If the only entries in the forward file are California BBSs, plus a list of state abbreviations, the following would define the message forwarding process. The software attempts to match the items in the forward file and the left-most code in the address field. In this case, it would look for, and not find W3IWI. As there is no match, it will then move to and compare the next code to the right. It will find MD, and that match will be sufficient to forward the message. If it had found and matched the callsign (W3IWI), it would take precedence (because it is more 'left' than MD) and would, of course, also ensure delivery.


A signature line should be appended to all messages as the last line of the message. This ensures that a full hierarchical address is linked to the mail, and makes it easier for a response to be sent. An example for Lincoln: