techieb0y.corbettdigital.net
peter@corbettdigital.net

Notes About D-Star

Overview

Icom's D-Star is a family of radio products developed by Icom and others in conjunction with JARL, Japan's counterpart to the US's American Radio Relay League (ARRL). It provides voice and data modes, both using digital signaling, on 144, 440, and 1200Mhz bands. The 144 and 440 modes are voice with low-speed data, good for integration with APRS-style use and chat/IM use. The 1200Mhz mode supports this digital voice mode, as well as a 'high-speed' data mode, running at about 128kbps. This high-speed data mode is the focus of the 145.67 Network project.

ID-1

The only user radio currently in the Icom family supporting the high-speed data mode is the ID-1. It has a 10BaseT interface to access the data network, and either a normal front-panel controller or a USB interface to PC software to adjust the frequency and other parameters. The USB interface is wired into a serial converter inside the unit, so from the PC's point of view, the radio appears as a COM port for configuration (or slow-speed data in digital voice mode). The unit is small and solid, but it has some quirks in operation.

Repeaters and Controllers

There are 2 revisions to date of the repeater/controller hardware. The original (RP1D) data module had an integrated controller (so you needed only one unit for a data-only network, and then added the 1.2GHz DV, 440DV, and 144DV modules separately) and comes in a white, weather-resistant enclosure. The newer (RP2D/RP2C) units use separate digital data and controller modules, both in more standard 19-inch rackmount enclosures. The RP2C controller includes DC power distribution for the rest of the stack; the older RP1D does not. Another feature of the D-Star system is the ability to link repeater stacks together into a larger system using either an Internet gateway or 10GHz microwave links, using a proprietary protocol based on ATM. Both versions of the controller include a 10BaseT port for the gateway, and the ability to connect 2 microwave link modules. The microwave link modules are expensive (several thousand more than for the controller and a data module). Each controler can connect up to 2 microwave link modules, but forming a ring between sites is not supported, so redundant paths are not possible.

Callsigns

D-Star allows for selective calling using callsigns. Within the D-star network, callsigns must be unique. Thus, current practice is to be similar to packet -- use a SSID of callsign+suffix, either numbers or letters. Callsigns are also used to address the repeater (and its subparts) directly. The radios allow you to enter not only your own callsign and the callsign of your intended recipient, but up to 2 intermediate repeaters. An ID-1 allows only one active pairing of callsigns at a time. In voice mode, there is a general call mode, by using CQCQCQ as the destination callsign. Once a response is received and accepted, the radio sets the destination (YOUR) call to the caller. Digital data works similarly; there is no way to form a shared Ethernet segment beyond a point-to-point link using only 2 ID-1s. This seems similar to how a switch builds an address table of MACs-port-port; the repeater seems to keep a table of MACs-per-callsign. No mechanism to view or alter this table is provided. (An alternate thinking is of the callsign pairings as being like a VLAN; simultaneous conversations on the same repeater can occur without interfering with each other, subject to the limitations of the simplex operation. The radio will show the callsign of the sender when it is in receive mode; whether it shows other conversations it can hear is currently untested. This seems to be the only way to monitor channel activity -- the Gateway PC only sees Ethernet frames on its interface if the user radios specify it as the destination/YOUR call.) The Gateway PC (connected to the repeater controller) can be accessed directly, by using the repeater's callsign in both YOUR and RPT1. RPT2 should be empty and the gateway flag disabled in this mode. In theory, this creates a shared Ethernet segment for all radios on the same repeater and using the repeater as the destination callsign. In practice, this seems not to be the case; while each end-user can address the PC at the repeater, they still cannot directly talk to each other. In order to connect directly between end-user stations, the Gateway PC does destination NAT, or could be a tunneling endpoint. GRE or ipip could be used for this, but perhaps the simplest approach would be for the Gateway PC to act as a PPPoE concentrator, with crypto and authentication disabled, as most OSes these days have PPPoE support built-in. (This basically limits the network to IPv4 with current implementtaions, though; few systems support IPv6 over PPP with PPPoE as far as I am aware). In voice mode, it's even more complicated: If both parties are on the same repeater, then they enter each other's call into the YOUR call field, and the callsign of their local repeater in the RPT1 field. If they are on separate modules of the same stack (cross-band mode), or separate stacks within a zone (separated by microwave links) -- or both! -- they enter the local repeater's call into RPT1 and the repeater module local to the other party into RPT2. (Repeater modules in a stack use a suffix letter in the last position.) If they are using the internet gateway, they enter their local repeater into RPT1 and the repeater with the gateway interface (even if it is also their local repeater) into RPT2 and enable the Gateway mode.

TCP/IP

The primary use of the digital data mode is for TCP/IP networking, which gets into interesting questions about routing. Without the microwave link modules, each repeater site is, from the point of view of the Icom hardware and software, a standalone site -- but on the TCP/IP layer, may be routed or bridged by other means, either with an ID-1 at the repeater site as a point-to-point link with another repeater site, or using 802.11 or other unlicensed gear for the same purpose. Straight bridging between sites should be simple and easy, but from a network engineering perspective is potentially unwise; this increases the size of the broadcast domain. Since there is only a 128kb data channel, this can be quickly saturated by poorly-behaved client machines. Using a separate IP subnet at each site seems like the better approach, but then you need to perform IP routing between sites. NAT can be used for this purpose, but can cause many headaches for inter-site communications. For a simple setup, static routes should work, but this does not provide fault tolerance. Thus, dynamic routing (preferably OSPF, alternately RIP or BGP4) is recommended. The next problem is what subnet to use. Current setups are using RFC1918 space. Amateur packet radio has the use of the 44.0.0.0/8 network, and Minnesota specifically 44.94.0.0/16, but more research into how to use this best is needed.

User setup complexity

In a traditional FM repeater, the end used needs to know at most 3 pieces of information to use the system: the frequency, the offset, and any PL/DCS tone. Since digital data mode is a simplex operation (even when using a repeater), the offset is unnecessary; the callsign acts in place of the PL/DCS tones for selective calling -- but the user needs to know 2 or 3 of them to use the system. Additionally, unlike with voice, the user must also be able to determine the IP network settings. DHCP makes this much easier; prior reports that DHCP for some reason did not work with D-Star were proven to be unfounded. In order to access a data service on the network, the IP address of that service must also be known. (For added fun, the ID-1's internet port is fixed at 10Base, half-duplex, and wired as MDI-X -- it will plug directly into any computer, but connecting it to a switch requires an extra crossover adapter, as the unit itself is a crossover already, just like the switchport.) Since the service may be on an ID-1 user radio, not at the repeater site, it is inaccessible directly; you need to route through the Gateway PC to get there (ie, Destination NAT). For this, some sort of dynamic DNS arrangement seems like the most sense -- DHCP updates DNS as users connect to the system. This requires setting a suitable identifier (say, your callsign) as a DHCP hostname/client identifier, and the DNS update system is built around cryptographically-signed updates; if DHCP and DNS are on the same machine, and the updates are traversing the loopback interface (never sent over the air), this is a non-issue; otherwise, further research is required. This then creates the issue of how to layout a DNS namespace, and how to provide fault-tolerant operation for it. If each site is a separate DNS domain (sitename.zone.ampr.net, perhaps?), each other site can be a slave nameserver and provide redundancy, as well as reducing DNS traffic across backbone links. With a large flat DNS namespace, this is not possible; out-of-band mechanisms would be required to coordinate updates of DNS zones between all sites. With a subdomain arrangement, each site would also maintain a zone file for one or more parent domains (to provide glue records), which would also require out-of-band management as new repeater sites are added or removed.

Base set of IP services provided

Each site should provide a base set of IP services: DHCP and DNS so the user can get up and running quickly (particularly important in emergency/disaster communications); ICMP (ping) for troubleshooting -- the repeater controller has an IP, but it doesn't respond well to pings from anywhere. Pinging the Gateway PC works far more consistently. Providing NTP seems like a good idea, ideally with at least one site providing stratum-1 time from a GPS. A website on the Gateway PC to provide information and links to other active services makes sense. Interfacing with packet BBS networks would require telnet.

Gateways and Icom's proprietary (yet Linux-powered) Kool-Aid

The Icom-supplied internet Gateway software provides Echolink-style features for voice, as well as some manner of roaming manager so that once a repeater site has heard your callsign on the network, other internet gateway connected repeaters can connect to you regardless of which repeater site you are on -- similar to cell phone roaming, but without the seemless transitions. For digital data, the goal is the same -- each user registeres with their local repeater operator for an IP to use under 10.0.0.0/8, and that IP is entered into a registration table along with their callsign and synchronized with all other interconnected repeaters. Repeater operators pull these IPs from a pool they are assigned, as far as I can tell these pools are /27 sized (32 addresses). When roaming, some kind of routing magic is done, possibly using RIP. Assuming users never roamed, each gateway would need 64MB of RAM for just the full table of /27s under 10.0.0.0/8; if roaming hosts are added on a per-host basis, then even more spaces is needed, with a theoretical max of 256MB (a separate routing entry for every /32 under 10.0.0.8), assuming that route entries are 16 bytes each. Each gateway then is presumed to have some sort of tunnel (IPIP? GRE?) to every other gateway system, and uses these to exchange traffic to other sites. Since the Gateway software runs on normal PCs and specs a minimum RAM requirement of 512MB, the routing table size shouldn't be an issue, but it does seem like poor design. (Actual behavior of gateways is currently unknown; when I get to see what they actually do, hopefully things will make more sense).

Playing well with others

Although messy and poorly designed, the Gateway system remains kinda nifty. Since the better design presented here doesn't work directly with the Gateway network model, an alternative must be arranged for those wishing to use it. The simplest way would be for clients to set up an IPIP or GRE tunnel to a the gateway server, but this requires client setup -- reducing the free-roaming aspect somewhat. Possibly, some sort of anycast could be employed to make it work better?

Hobbies: