John's Meanderings

[ This first appeared here ]

D-STAR, the protocol, has no notion of linking, reflectors, etc. It was designed to be “stateless”, meaning every transmission is complete in itself and has no inherent relationship to any other transmission. (For Internet Protocol folks, think of it as UDP or User Datagram Protocol).  It is also an addressed protocol, meaning the field “MYCALL” is meant to be the address (callsign) that sent the transmission and the “URCALL” is meant to be the address (callsign) to which the transmission is intended.  ”CQCQCQ” is meant as a “broadcast” address, meaning that it is intended for any receiver.  RPT1 and RPT2 are helper addresses (callsigns) to select relay (repeater) stations.

In this basic D-STAR model a station would set the “MYCALL” to the originating address (callsign), such as MY: K7VE, and the URCALL address would be set to CQCQCQ, if the station was making a “broadcast” transmission, or it would be set to the destination address (callsign) for the receiver for which the transmission was intended, such as UR: KC7PAA.  Icom took advantage of this model and added some features in their radios:

1. There is usually a button to set UR to CQCQCQ, for the operator to quickly switch to “broadcast” mode.
2. There are usually memories to store commonly called addresses (callsigns) that the operator wishes to reach.
3. Second generation radios (and subsequent generations) also provide an address (callsign) squelch, so the operator that only wants traffic addressed to them can filter out everything else.

This all works well on a local simplex or repeater conversation.  It is not, however, intuitive to the person who is making voice transmissions.  If they have not applied the callsign squelch, they simply hear all transmissions on the channel.  It sounds like any other simplex or repeater voice transmission, except between the radios it travels as a bit stream and you have the benefits (and liabilities) of a digital voice transmission.  So to the voice user the utility is the same as their analog counterparts.  On the other hand, the D-STAR digital data user (e.g. Ethernet encapsulated in D-STAR packets, not the extra data bits in the digital voice stream), the URCALL and MYCALL addresses (callsigns) become integral to directing traffic to the right receiver.

Moving up from the simplex or local repeater mode to networked communication, these addresses become more powerful.  For voice communications, the URCALL again represents the intended receiver of the traffic.  The gateway systems that sit behind the repeaters are designed to keep track of all of the addresses (callsigns) of all stations heard on the network. (In the case of Icom G2 and G4ULF gateways, an unregistered transmitter address (callsign) will cause their transmissions to be filtered out before it is relayed to the network.) So when a gateway receives a transmission from an attached repeater, it examines the the URCALL (and MYCALL) and looks to see if the URCALL address was last heard on a remote repeater and, if so, it relays the transmission to the gateway where that remote repeater is connected.  To the operator, regardless of digital voice or digital data, it means that the transmitting station doesn’t need to know where the receiving station is located, the gateway system automatically and quietly forwards the transmission.

CQCQCQ is not a registered address, so it does not get relayed beyond the local gateway (and that is why you get an error message on your display when URCALL is CQCQCQ and the RPT2 address is active).

Because of this addressing over the network, the transmitting station can change the URCALL between transmissions and if the intended recipient of the second transmission is on a different remote repeater than the intended recipient of the first transmission, each will only hear transmissions directed to them.  This has pluses and minuses:

1. It is more efficient, since the only repeaters activated are those involved at the two endpoints for any given, over the network, transmission.
2. Since it is directed, uninterested or unintended, receivers do not receive traffic, unless they happen to be monitoring one of the repeaters at the end points.
3. It also means a station who receives a transmission and replies, is doing so “blind”, not knowing if there is other traffic at the other end of the network.

This model does not work well, if at all, if you have a network of stations using digital voice and they are located at 3 or more repeaters (on 2 repeaters, each station just needs to have their URCALL set to either the address of the remote repeater, e.g. “/NW7DR B” or to the address of a station that is known to be located at the remote repeater).

Robin, AA4RC, looked at this issue, and came up with a solution, in the form of what we now know as DPLUS. DPLUS adopts the traditional notion of linking repeaters as can be found on analog repeaters. These analog repeaters use radio, wire, or voice over IP (VOIP) to relay voice from one repeater to the other and are usually symmetrical, i.e. if any repeater receives a signal it is relayed to all of the other repeaters that are on the link.  For better efficiency when linking more than two repeaters, DPLUS adopted the notion found in the VOIP based linking systems, by creating conference bridges called reflectors which become the meeting place for small to very large collections of repeaters.  This is a very powerful tool for enhancing wide area, even global, networks of stations, whether formal networks or simply “watering holes” where stations gather for random, non-directed, contacts.  DPLUS is the application that is most responsible for the growth in use of digital voice radios in amateur radio over the last few years.

Since D-STAR has no facility, in the protocol, to perform this linking and because the Icom G2 gateway is closed source and proprietary, Robin was forced to create a method that would enable this linking. The Icom G2 system uses UDP port 40000 to relay digital voice between gateways on the Internet and all callsign addressed D-STAR digital voice uses this port on the Internet, and a different UDP port is used to talk to the Icom controller (and by extension, the repeaters), usually port 20000.  DPLUS is able to use a technique called packet inspection (or packet sniffing) to watch all digital voice traffic between the controller and gateway, and between the gateway and Internet. DPLUS can then copy that traffic to another port to send it over a link to another gateway or reflector. Conversely, any traffic coming in over a link can be copied to the local controller, using packet insertion, to be sent over the air by the repeater. I will leave out a lot of the detail of the complexity required (some I don’t know, but have an appreciation that its no small feat) to avoid routing loops, separate streams for different repeaters connected to the same controller, handling DVDongles, DVAPs, etc., but fundamentally this what DPLUS linking does.  Additionally, DPLUS monitors the packet headers for URCALL addresses that have been overloaded as commands for linking, unlinking, and other housekeeping.

One of Robin’s goals is to make sure every repeater, and by extension every station, on a link hears the digital voice traffic that appears on any other repeater on that same link, including traffic that comes into a gateway via callsign addressing (on port 40000) that would go out a local repeater to its intended recipient, if that repeater was on a link. The intent of that goal is to inform all stations of traffic that could collide if an additional transmission was put on the link.  Also, it is intended to help avoid confusion for operators who may not be aware that some traffic is originating elsewhere.  A reasonable thing to attempt, however, it does have some side effects:

1. Any traffic whether from a repeater’s receiver (if RPT2 is set), through the Internet, from an attached device like a DVDongle or DVAP, that keys the repeater’s transmitter is automatically sent over the link associated to that repeater to any remote gateway or reflector on the other end of the link. In turn, a reflector copies that traffic to all attached repeaters and other devices. It does this without regard to the intended destination in the UR field.
2. Traffic is sent to all repeaters (and other device) attached to the link, directly or via a reflector, even if there is no interested receiver.

We are all aware that most repeaters, by themselves, are largely silent. In any given metropolitan area, it is likely that > 90% of repeater traffic is on a handful of repeaters.  To provide traffic on a repeater, in hopes of keeping it interesting, some repeaters are always linked to a particular reflector and deny stations the ability to ‘unlink’ or have aggressive watchdog scripts that re-link the repeater to the reflector on failure or if no other link is present.  Other systems use reflectors for regional networks.

Most reflectors are likewise mostly quiet with just a few carrying the bulk of traffic. Today, a reflector with 20+ attached repeaters may only see the traffic we saw on a single analog repeater 20 years ago.  So there is a lot of “dead air” out there!

A fraction of all D-STAR radio owners have learned to use addressing to direct their transmissions to their intended recipient. These transmissions can easily slip in to this “dead air” and would have no impact on any repeaters other than those directly involved. However, due to linking and reflectors, their transmissions are often sent to unintended destinations, including reflectors, which impacts many repeaters and their users.  Some consider this “interference” on their links and have come up with scripts to try to mitigate these unintended incursions by unlinking a repeater when addressed traffic comes into a gateway from a local repeater.  Unfortunately, they don’t really accomplish what one might suppose.  Let me provide some cases:

Case 1:

Station 1 uses addressing to direct a transmission to Station 2.  Station 1′s local repeater has a script that examines the header and unlinks it from a reflector.  The transmission goes to the repeater where Station 2 is located and that repeater is linked to a different reflector.  DPLUS will note the addressed traffic on Station 2′s repeater and dutifully copy it over its link to the reflector, which in turn copies it to all repeaters (and other devices) connected to that reflector.  Possibly sending traffic to hundreds of unintended receivers (who may not notice it is addressed traffic and may attempt to reply, putting more traffic on the reflector intended for Station 1 who will never see or hear it.)

Case 2:

Station 1 addresses a direct transmission to Station 2.  Station 1′s local repeater does not have such a script installed and is connected to REF001 C.  So Station 1′s transmission is reflected to everyone listening to REF001 C.  It arrives at Station 2′s repeater, which is linked to REF014 C, and goes out on Station 2′s repeater but is also copied to REF014 C, and in turn to every repeater linked to REF014 C.   Since Station 1′s repeater is linked to REF001 C, stations on REF001 C can reply and be heard by Station 1, but not by Station 2 or anyone on REF014 C.  Stations on REF014 C (not on the same repeater as Station 2) will not be heard by Station 1.

As some have suggested, if DPLUS only copied traffic addressed to CQCQCQ (broadcast), then it would greatly reduce the impact to reflector users in the above cases, as every addressed transmission would only be heard on the 2 repeaters where Station 1 and Station 2 are operating and neither repeater would have to unlink.   There might be an occasional collision between addressed and DPLUS traffic, but it would almost always be limited to only one repeater instead of the impact to many repeaters as seen in the above scenarios.

DPLUS is Robin’s code and he is absolutely the one who makes the final call on how it works.  This discussion is only intended to provide the information on what is happening in a gateway and how it interacts with linking.  If you have suggestions on how DPLUS might address your concerns, you should share them with Robin.