Re: Towards open-source infrastructure for DMR repost from OpenDV


 

On 26/11/20 3:54 am, Steve N4IRS wrote:
DMR, after D-Star, is the most political of the digtial voice modes.
Unlike the other modes, most DMR systems connect to a centralised
server, known as a "master" and that is responsible for all of the
talk group routine, personal calls, and position data interpretation
and forwarding. There are three main centralised systems:
BrandMeister, DMR+ (known as Phoenix in the UK), and TGIF.
 
What these systems have in common is that they are closed source. This
is not good for the amateur community. There were mutterings about
them having signed NDAs with Hytera and Motorola to get details of
their internet connection protocols, which may or may not be true.
Even if true, why not make the non-NDA parts of the source code open?
 
In the commercial world, digital voice repeaters, be they for DMR,
P25, NXDN, or dPMR have limited abilities within themselves for call
routing. They do include CPUs of course, but for anything other than
simple point-to-point links, they are useless. This limitation is fine
for what they were originally designed for, small centrally controlled
networks, with or without a dispatching console function. The YCS
system for System Fusion is looking to do the same for YSF and that is
why I oppose it.
 
This model of a centralised control structure carried through to the
amateur DMR networks. In its simplest form, a repeater would simply
have a point-to-point network connection to the master and things
would be fine. Even with a semi-distributed system, with one or more
master per country, there is still some central control of the system
with the power to overrule the decisions made at the local level. Such
central control is also not conducive to supporting each countries
requirements, and leads to much used functionality being arbitrarily
removed. In the extereme case the countries master may also be
removed. When such things happen you have to ask from where did they
derive their authority? Who voted for them? Who made the decision and
how do they know that it is correct?
I'm in agreement with the general idea.  I was involved in EchoIRLP,
which came about simply because people like me simply wanted to be able
to connect to whatever network we wanted.  EchoIRLP also incorporated
features to protect the networks from accidental cross linking, which
was one of the reasons it was readily accepted, once people got their
head around the concept.

While it's great to play with different modes, we do have a real "Tower
of Babel" when it comes to DV modes.  Projects like DV Switch do go a
long way towards mitigating the effect of having multiple incompatible
modes among a relatively small user base. 
 
In the amateur world we have gone beyond having dumb repeaters. Most
MMDVM systems for example have a Raspberry Pi or similar running the
system, and have the potential to provide a lot of local processing
power which can be used for more complex tasks than simply routing
traffic over a point-to-point link. Many sysops expressed the wish to
be able to have access to multiple masters, simultaneously, and hence
the DMR Gateway was born in 2017. It does complex call routing, and
almost everything else, bar the position data interpretation.
What would I like?  In an ideal world, I'd like to be able to
communicate with the hams I want to, regardless of network or mode,
using the radios I have,  In essence, think of it like EchoIRLP on
steroids.  I have something close to this with my AllStar node, which
not only can do AllStar, IRLP and Echolink (IRLP/EL via my existing
EchoIRLP node - with all proper lockouts in place), but it's configured
to do DMR (BM), YSF and P25 via a local DVSwitch installation.   I'd
like to be able to run multiple DMR networks eventually.  

The end game is something that performs the role that IP does for data -
providing routing over the top of multiple networks, so any endpoint can
find any other endpoint.

Another issue is audio processing.  I believe in processing the audio as
little as possible.  This philosophy goes back to EchoIRLP (2003-) and
the IRLP/Echolink integrated conference servers (2005-), and results in
the best audio quality with minimum latency.  DV modes, unlike the
analog systems often don't have a "common vocoder", so some amount of
transcoding is unavoidable, but again given the aggressive vocoders in
use, I'd like to keep it to a minimum, while preserving as much metadata
as possible.  Incidentally, this would be handy internally in cross mode
gateways like the one I have in the cloud.

Here's how I see it working.  At the source, the audio is decoded to
PCM, and two audio streams are sent - one in PCM and a second stream in
the original encoded format.  Information about the vocoder in use is
added to the metadata.  Stations receiving the stream examine the
vocoder metadata.  If they natively support the vocoder used, they
simply take the original encoded voice data and use that.  Otherwise the
receiving nodes that can't handle the source vocoder will take the PCM
stream and re-encode that.  In these days of unlimited (or near
unlimited) broadband Internet, the overheads of doing things this way
shouldn't be an issue.   If a viable software implementation of the
D-STAR vocoder comes along, it would still then be possible to have a
"dumb" node linked to a "smart router" running in the cloud, to save
local processing power or bandwidth, if needed.

 
In some quarters this development was opposed. I believe that the
sysop should have the choice on how to route their traffic and so
development went ahead and it has been enhanced since. It has been a
huge success.
 
I think that the time has come to look at having an open source,
non-centralised, DMR network. A network where no one person or group
has control. We already have the beginnings of this with the HBLink
and with XLX projects. If more people get involved with these projects
then they will grow and offer more features as time goes on.  I
haven't played with HBLink yet, but it does interest me.
The only issue I see is avoiding issues like routing loops or malicious
interference (sadly, it does happen).  For the former, it would be ideal
if the network was smart enough to detect loops and then take action to
block the source of problems or break the loop, until it's fixed. 
Otherwise some human oversight would be needed.

I do run an XLX reflector, but keep it standalone, as the very manual
interlinking process isn't compatible with my ADHD (I did play with it
in the early days of XLX).  I'm also somewhat cut off from that
community, because they moved all their internal communication to a web
forum years ago, which is relatively inaccessible to me - too slow and
cumbersome and yet another login to remember to check.
 
Some may say, what about integration of commercial repeaters like
Hyteras and Motorolas? There is already a program available that
converts the Hytera repeater protocol to the protocol used by the
MMDVM, and integration of Motorola repeaters is possible all be it
with a number of programs in series. Maybe someone will rationalise
this into something simpler.
This could be a use case of the "dumb node" scenario above.
 
Things are already moving on this, and I hope that in the future we
will see such systems appear and then DMR will be free of the tyranny
of what we have now. Sysops and their users are sovereign and should
not be dictated to by anybody (the same goes for software developers
:-) ).

Let's hope for more openness. :)

--
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Join main@DVSwitch.groups.io to automatically receive all group messages.