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.

Here is my latest response.

I don’t think anyone is saying that AMBE/D-STAR is the only way to do digital voice on Amateur Radio.

I think what people that do the work, understand the system, and have been at this for awhile get tired of are just a few key points:

1. Beating up D-STAR over the use of AMBE
• It’s just a part, like a microprocessor, DSP, etc.
• It is the best commercially available, off the shelf, component to provide digital human voice over the radio
• It’s price is reasonable (how it is packaged by some vendors for sale is pretty high for their BOM)
• It is used in other Amateur Radio products (AOR ARD  digital voice, Alinco digital voice, NXDN, MotoTRBO, next generation P25) without the same vitriol.
2. People saying we can just modify D-STAR to use Codec-2 or some other Codec
• Those of us who work with interoperability and implementation standards understand the issues with making non-standard changes to a protocol.
• Standards are controlled through a process (that the JARL doesn’t execute well), which is where changes should be vetted, voted, and documented.
• We shouldn’t confuse consumers of a protocol by implementing something different and give it the same (or very similar) name.
• Introduction of incompatible systems into a working and established network or protocol framework creates unneeded issues.
3. People taking a narrow view of what the protocol means
• If you only look at Digital Voice you are leaving out much of the D-STAR protocol
• Not considering side effects
• Not understanding how one interconnects incompatible protocols  (through the use of bridges, protocol gateways, etc.)
4. Market, social, investment, and cultural aspects
• Acknowledging that most operators want a self-contained radio whether a handheld, mobile, or base.
• Interconnect issues to external devices creating more points of failure
• Aesthetics – lost on the experimenter, but for the larger community there is value in an attractive package.
• They want to buy something off the shelf that is ready to use. (USTrust registration is problematic for this)
• People who have made investments in infrastructure (repeaters, gateways, etc.) don’t want them “broken” by non-compliant systems
• Some people like the clarity of AMBEs vocoder and don’t want it mixed with analog or even other systems that don’t fit the same profile.

I, and I venture many others, look forward to additional digital voice and data options.  Maybe something will come of Codec-2, maybe not.  If it proves to be a better technical (not religious) solution and a manufacturer picks it up to create the self-contained radios to build out an entire network like D-STAR, great, the market will decide.  I believe digital is the future and it will evolve, but basically I think the plea is basically, bluntly, “put up or shut up” — in other words, do the work to build something and put it out, in the meantime use what is available without this continued babble about how evil AMBE/D-STAR is and if “somebody” would just make “this change” it would be so much …

Let’s use the D-STAR and related forums and groups to work on D-STAR.  If one wants to do something different create your own community/forum/group and have at it.

http://groups.yahoo.com/group/STARnetDigital

I love being Grandpa to these sweet little girls.

By VK5ZEA

The name of the application is “STARnet Digital” (not StarNet, StarNet Digital, or other variations)

Tools, webpages, etc. should follow this branding.  When shortened it is STARnet.

Client stations are STARnet Subscribers or STARnet Users.
Servers are STARnet Digital Group Servers or when shortened they are called a STARnet Server
A network of STARnet Subscribers are called a STARnet Group
A station subscribes to a group, they do not “link”
If a STARnet Group is connected to a DEXTRA (or other) reflector, it is called a STARnet Group Bridge (or bridging)

We should talk in these terms to avoid confusion with “linking” systems like DPLUS or DEXTRA.  It will help the user community start to differentiate between the technologies.  We do not want STARnet Digital to be seen as a linking technology, it is a callsign routed system where each transmission is individually routed with individual clients able to subscribe to multiple groups and individual repeaters able to multiplex multiple groups for different users.

K7VE-CommAcademy-2011-Presentation

There is a new Internet Only version of STARnet Digital Server which can be run on an Internet connected computer without any repeaters attached.  This is ideal to place groups in hardened locations like a data center.  The executable and source can be found in the ircDDBGateway packages.

A recently added feature allows a STARnet Digital Group to mirror to and from a DEXTRA reflector (e.g. XRF001 C) to help expose more users to STARnet Digital.

STARnet Digital is a new application for use with D-STAR (Digital Smart Technology for Amateur Radio) that builds upon Smart Technology for Amateur Radio, creating dynamic networks of D-STAR radio stations through the worldwide network of D-STAR gateways and repeaters.

The fundamental building block of a STARnet Digital network is the Group. Each Group is accessed by a Group Callsign. User radios subscribe to a Group by putting the Group Callsign in the destination (UR) address of the D-STAR radio header and keying their transmitter. Once subscribed, any transmissions directed to the Group will be automatically relayed to the repeater where the subscribing station was last heard. The subscribing station can move from repeater to repeater and upon a transmission from the subscribing station to the repeater, the Group will automatically redirect Group transmissions to the subscribing station’s new repeater.

D-STAR was designed to use addressable communications where the originating station selected the destination station by placing the callsign of the remote station in the destination (UR) field of the D-STAR radio. The D-STAR gateway network is responsible for keeping track of individual stations and routing communications based on the destination callsign. This is a one-to-one relationship and creates complications if more than two stations wish to communicate over a variety of gateways and repeaters.

Early D-STAR gateway software was and continues to be closed source with no Application Program Interface (API). To facilitate wide area communications, including a large network of stations, industrious developers created “bolt on” linking technology that “sniffs” network traffic and relays it “out of band” between gateways delivering it to other repeaters for retransmission. We applaud this work and believe that it will continue to provide needed functionality for certain types of network activity.

STARnet Digital takes the native, callsign routed, approach to creating a nework of subscribing stations. The STARnet Digital server looks like a D-STAR repeater to a gateway. The STARnet Digital “repeater” advertises itself to the network, and individual Groups report through that repeater as if they were just another user station with a Group Callsign. Existing D-STAR gateways do not have to add any special software or hardware for its users to subscribe to STARnet Digital Groups, the subscribing stations simply set the destination (UR) address in their radio to the Group Callsign of the Group they wish to communicate with; no linking, no unlinking, no exclusivity of Groups which the repeater can relay.

To setup a STARnet Digital server is easy:

1. Obtain a non-user (e.g. club) callsign for your gateway and register it at http://regsrv.ircddb.net/index.htm
2. Wait for the username and password to be returned
3. Register a user terminal for your Group on USROOT (This can be any callsign that is registered at USROOT) through your local USROOT connected gateway. This is necessary since Icom G2 and G4ULF gateways check USROOT database to authorize transmissions.
4. Get the latest ircDDBgateway at Yahoo! ircDDBGateway Forum
5. Install the Microsoft Windows binary or compile and install from the source in the zip file on a Linux box (edit the makefile for your CPU type).
6. Start the ircddbgateway in GUI mode.
7. Goto the Edit -> Preferences -> Gateway tab and setup your gateway callsign and longitude/latitude
8. Goto the ircDDB tab and insert your Gateway’s ircDDB Username/Password
9. Goto the STARnet 1 tab and select Band (A, B, C, D) to create the virtual repeater on the gateway, put the user terminal callsign in the space provided
10. Select “OK”, stop and restart the ircddbgateway — once it registers with ircDDB you are ready to test.

The callsign from step 9 above is the Group Callsign. All users that want to talk to the Group will put this callsign in the destination (UR) address field of their radio. For example, if station KQ1ZZZ wanted to participate on a Group with the Group Callsign EX4MPLE, the settings on their radio would be:

MY: KQ1ZZZ

UR: EX4MPLE (from step 9)

RPT1: <Local Repeater Callsign> (Whatever nearby repeater they want to use on the D-STAR network)

RPT2: <Local Repeater Gateway Callsign>

The local gateway must be setup to report into ircDDB, whether the gateway is an Icom G2, G4ULF, etc., or using the native ircDDBgateway. The local gateway needs no additional software installed. You can see if your local gateway is on the ircDDB network by visiting http://www.ircddb.net/ – Select your country and look for the callsign of your local gateway.

When the user transmits for the first time, they will be automatically registered with the Group and any transmissions directed to the Group will be relayed back to the user. If the user moves to another repeater on a gateway that supports ircDDB, and transmits, the Group will follow them and send traffic for the Group to the new repeater. (It will stop sending to the previous repeater if the user was the last subscribing station on that repeater.)

If the station switches repeaters, the UR callsign will automatically switch to CQCQCQ on their radio, and the user will have to re-enter the UR callsign (or use callsign capture, usually the CS/RX button on their radio) to transmit into the group, but receive is automatic. Common Group Callsings are great candidates for the UR memories on the D-STAR radio.

The user can unsubscribe from the Group by setting the UR to the Group Callsign, and put “LOGOFF” in the TX Message/Comment on their radio.  We recommend putting this command in one of the TX message memory slots on the radio for easy access.

The Group may be configured to logoff a user after a period of inactivity or to logoff all users after a set period of inactivity on the Group.

There is one other command that can be placed in the TX Message/Comment field, “INFO” which will return a short description of the Group associated with the Group Callsign.

A user can subscribe to more than one Group at a time, but must set the destination (UR) call to each group individually with which the user wishes to send traffic.

Gateway operators may wish to use ircDDBgateway as their primary gateway software. It is Free Open Source Software (FOSS) under the GNU license. It can be configured to operate with the Icom RP2C controller, GMSK node adapters, or use soundcard GMSK modem software. It has connectivity for DExtra, DPlus (client only), D-RATS (login), D-PRS (GPS A only), and STARnet Digital. A single ircDDBgateway can manage repeaters and Groups at the same time. It uses ircDDB for all callsign routing and updates and does not use Trust Servers for any purpose.  Support is through the ircDDBGateway Yahoo! Forum.

Whereas the STARnet Digital software is FOSS, we invite others to contribute to its development and inclusion in other gateways or similar projects.

DVDongles, DVAPs, and DVAR Hotspots will not be able to use STARnet Digital since they do not currently support native D-STAR callsign routing, which is the transport technology for STARnet Digital. These devices use DPLUS linking rather than native D-STAR callsign routing. The STARnet Digital team would like to see software developed where these devices authenticate using strong authentication to a proxy server that would allow callsign routing to and from these “stations”. (Those individuals who currently run HotSpots, are advised that both G4ULF and ircDDBGateway software can operate on simplex radios and provide full callsign routing functionality.)

STARnet Digital was conceived and functionally designed by John Hays, K7VE, with code design, engineering, and implementation by Jonathan Naylor, G4KLX. It builds on the work of many others, including the JARL which developed the D-STAR protocol, and the ircDDB network team, for which we are grateful.

This is the first public beta of the software, additional features such as a visualization layer, and additional gateway operator tools, are currently under design and consideration. Currently group callsigns must be regular Trust Server registered terminals and we ask that “tactical” callsigns not be used until the USROOT Trust Server team has an opportunity to study if using “tactical” callsigns, such “NYARES A” will create any issues with their systems. Also, if the ircDDBgateway is not supporting RF modules, it may be possible to use tactical names for these as well, but again, let the USROOT and ircDDB teams have time to consider any unintended consequences of such a move.

See: http://k7ve.org/blog/2011/04/starnet-digital/ for further information.

1. With the assistance of my son, James – KC7OSO, the antenna was moved from the deck of my house, to a pole on the roof.
   
2. With the assistance of David Lake, G4ULF, I upgraded the gateway software to NI-STAR and moved the system over to the USROOT Trust Server. Included in this install are DPLUS (linking) and D-PRS (GPS reporting) support.
3. I integrated ircDDB support.
4. Here is the new coverage plot for the repeater as computed by SPLAT! (Coverage is primarily in the yellow and red/orange area — due to low power of the repeater):
   

More later…