Address scheme for international traffic

From Digital Traffic System
Jump to: navigation, search

Introduction

Traffic handling is a part of amateur radio most popular in the United States and Canada. In recent years interest in traffic handling grew in other parts of the world as well mainly driven by emergency communications needs.

This evolution is for the benefit of all as it increases the overall volume of traffic. On the other side this expansion also demands for rules on how to address and route international traffic. As most of the long-haul traffic links are digital by nature these questions have predominantly to be answered for the digital traffic systems.

Radiograms are based on postal addresses and therefore zip codes are the means of choice to route them. The address scheme <zip>@NTS<state> used in the Digital Traffic System (RRI DTS) for the USA and Canada is perfectly suited to this end.

This address scheme has been extended to Europe and Oceania with the routing domains @NTSEU and @NTSOC, respectively. Here callsigns are used for the TO part of the address. However, this will neither work for future extensions e.g. to Asia nor is it suitable to support any kind of zip code addressing outside the US and Canada.

Objectives

Our aim is therefore to introduce a new address scheme for digital radiogram messages with the following main properties:

  • both international callsign and zip code addressing are supported
  • the existing address schemes @NTSEU and @NTSOC can exist in parallel and are not affected
  • the system allows for geographical extensions and is flexible to support changes regarding the routing of messages
  • from the user perspective the address scheme is stable and independent of any routing changes in the background
  • configuration changes involved with shifts in message routing are limited to a small set of MBOs only
  • the address scheme can easily be converted to local address flavours with existing local schemes not being changed
  • the system can be implemented with standard features of the BPQ BBS software


The new address scheme

In order to lay the basis for an international address scheme supporting zip codes as well as callsigns in the TO field we are following basically the ideas the addressing for physical letters work with.

When you send an international letter you put an extra line at the end of the address indicating the country name. We do however not have an extra (unused) field in the address scheme so we choose a special character to indicate that a message is for someone in another country. This special character is the minus sign (-). As a substitute for the country name we use a standardized and internationally recognized country code, the ISO-3166 alpha 3 code. Examples are DEU for Germany and GBR for Great Britain. Thus a message for someone in Great Britain is addressed as

    <zip>@-GBR      e.g. CH73NT@-GBR  or
    <callsign>@-GBR e.g. G0DUB@-GBR

An international letter is brought to an international airport to be transferred to the destination country. Anybody involved in this only needs to know where the airport is but not where the country of destination is or how to precisely transport a letter there. Our airports are designated target (or gateway) stations. Every MBO on the path to the target stations needs to recognize that a message is international in the first place i.e. that the AT parts starts with a minus sign.

With letters not every airport is equally well suited for a particular international letter. You do not want to transfer a letter from Texas to LAX just to find out that your letter is for someone in Great Britain and that the JFK airport would have been a much better choice for you. Note that this information is not known to the originator of your letter who only writes the country name on the envelope.

The same may happen with international digital traffic which is why certain central stations (the area hubs and their backups) where you message will come through know where to forward it. This is achieved with autonomous system codes something like continental codes which are put in front of the country code. Thus

    CH73NT@-GBR  becomes  CH73NT@-EU-GBR  and
    G0DUB@-GBR   becomes  G0DUB@-EU-GBR

only for message routing purposes.

MBOs on the message path still recognize this as an international address because of the minus sign following the AT sign. Those stations knowing how to get your message to Europe (-EU-*) will route it the right way i.e. to the target station KW1U.

Once the message arrived in Europe the AT part may be replaced with a suitable routing domain for Great Britain and the message will be routed there.

Although this sounds all simple and straightforward there is some theory behind doing things exactly this way. You will find more on this in the concept document referenced in the "Useful Links" section at the end of this page.


Current status and next steps

We propose to introduce the new address scheme with a step-by-step approach. Existing routes for @NTSEU will be kept in parallel as long as necessary.

At the end of each implementation phase we review the existing concepts for any necessary changes. Although not explicitly mentioned each implementation step also includes suitable tests and a rollback will be performed if the results do not meet our expectations.

We start with the implementation of the new address scheme on the European side so that we will have had at least one review round before we perform any changes on the US side.

Here is the current version of our plan and what we achieved so far:

  • (done) conceive a concept on handling international digital traffic
    • (done) the RRI Board of Directors approved the concept on international traffic on October 2017 and recommended it for implementation
    • (done) prepare a detailed design of the European target station (DB0NTS)
  • (todo) implement the European target station according to the above design
    • (todo) separate @NTSEU routing from the new address scheme
    • (todo) establish the @NTSxy routing domain translation for outbound traffic to North America
    • (todo) set up the mapping rules for inbound traffic from North America
    • (todo) review the design of the European target station and perform any changes necessary
    • (todo) review the concept on international traffic and perform any changes necessary
  • (todo) configure the US target station (KW1U) for the new address scheme
    • (todo) introduce the necessary INTRCPT file and the routing rule KW1U:@-EU-*>>DB0NTS
    • (todo) collect experiences with handling traffic originating from KW1U using the new address scheme and
    • (todo) collect experiences with handling traffic from DTS directly linked to KW1U
    • (todo) review the interplay of KW1U and DB0NTS and perform any changes necessary
    • (todo) review the concept on international traffic and perform any changes necessary
  • (todo) configure selected EAN MBOs for the new address scheme
    • (todo) set up the routing rule MBO:@-*>>KW1U at selected EAN MBOs
    • (todo) collect experiences with handling traffic from DTS linked to these MBOs
    • (todo) collect experiences with handling traffic to and from Canada (ON DTS) as they have their own zip code system
    • (todo) review the concept on international traffic and perform any changes necessary
  • (todo) configure the remaining EAN MBOs for the new address scheme
    • (todo) set up the routing rule MBO:@-*>>KW1U at the remaining EAN MBOs
    • (todo) prepare a training document for DTS operators on how to use the new address scheme
    • (todo) collect experiences with handling traffic from EAN DTS
    • (todo) review the DTS training document and perform any changes necessary
  • (todo) configure the CAN and WAN MBOs for the new address scheme
    • (todo) introduce the necessary INTRCPT file at the area hubs
    • (todo) set up the routing rules for international traffic at all MBOs
    • (to be clarified) routing rules for Oceania need to be introduced
    • (todo) update the DTS training document regarding traffic with Oceania
    • (todo) collect experiences with handling traffic from selected DTS
    • (todo) review the DTS training document and perform any changes necessary
  • (todo) plan the next steps to come


Useful links

Contact

If you have comments on or want to get involved in this project please contact your Area Digital Co-ordinator or Peter Dintelmann (dl4fn (atsign) yahoo (dot) com).