Nel mondo radioamatoriale digitale sentiamo continuamente parlare di:
DMR2YSF, YSF2DMR, DMR2NXDN, cross-mode, bridge, transcoder e gateway.
A prima vista tutto sembra semplice.
Un radioamatore parla in DMR.
Un altro lo ascolta in System Fusion.
Un terzo entra da NXDN.
Un quarto magari utilizza un client software.
E sembra quasi che il server faccia semplicemente:
DMR → YSF → NXDN
In realtà dietro una comunicazione cross-mode può esserci una catena estremamente più complessa.
Bisogna infatti distinguere almeno quattro operazioni differenti:
trasporto dei pacchetti;
conversione del protocollo;
conversione della segnalazione;
transcoding della voce.
Sono concetti differenti e comprenderli permette di capire anche perché alcuni bridge producono audio eccellente mentre altri introducono ritardo, artefatti o addirittura rendono impossibile la comunicazione.
MMDVM è un ottimo esempio della varietà dei sistemi coinvolti: il firmware supporta D-STAR, DMR, System Fusion, P25 e NXDN, mentre MMDVMHost utilizza gateway separati per connettere i diversi modi alle rispettive infrastrutture di rete.
Partiamo dall’inizio: la voce non viaggia come audio normale
Quando premiamo il PTT di una radio digitale, la nostra voce viene prima acquisita dal microfono e successivamente codificata da un vocoder.
Possiamo rappresentare il processo così:
VOCE
↓
MICROFONO
↓
ADC / DSP
↓
VOCODER
↓
DATI VOCALI COMPRESSI
Questi dati vengono inseriti nei frame del protocollo utilizzato dalla radio.
Per esempio:
DMR
oppure:
YSF
oppure:
D-STAR
oppure:
NXDN
Quindi sulla rete non viaggia semplicemente:
audio.wav
ma qualcosa concettualmente simile a:
HEADER
IDENTIFICATIVO
DESTINAZIONE
SEQUENZA
CONTROLLO
PAYLOAD VOCALE
Il payload contiene la rappresentazione compressa della voce.
Primo concetto fondamentale: protocollo e codec non sono la stessa cosa
Questo è probabilmente il punto più importante di tutto l’articolo.
Un protocollo digital voice descrive aspetti quali:
- struttura dei frame;
- identificazione delle stazioni;
- indirizzamento;
- sincronizzazione;
- gestione della chiamata;
- dati;
- modalità di accesso;
- trasporto del payload vocale.
Il codec/vocoder, invece, descrive come viene rappresentata la voce.
Possiamo quindi pensare:
PROTOCOLLO
│
├── signalling
├── addressing
├── framing
└── VOICE PAYLOAD
│
└── vocoder
Questa distinzione spiega perché “tradurre DMR in YSF” non significa necessariamente “convertire anche l’audio”.
MMDVM non significa automaticamente cross-mode
Il modem MMDVM può gestire differenti modi digitali RF, ma ciò non implica automaticamente che una trasmissione ricevuta in DMR venga trasformata in NXDN o System Fusion.
MMDVMHost opera infatti con componenti di rete specifici: D-Star Gateway sul lato D-STAR, DMR Gateway per DMR, YSF/DG-ID Gateway per System Fusion, P25 Gateway e NXDN Gateway per i rispettivi sistemi.
La situazione normale è quindi:
┌→ DMR NETWORK
│
MMDVMHost ─┼→ YSF NETWORK
│
├→ NXDN NETWORK
│
└→ D-STAR NETWORK
I vari modi possono coesistere.
Ma questo non significa ancora che parlino tra loro.
Che cos’è allora un bridge?
Un bridge collega due ecosistemi differenti.
Supponiamo:
DMR TG 22215
e vogliamo collegarlo a:
YSF ROOM XYZ
Il bridge deve ricevere informazioni provenienti dal primo sistema e produrre informazioni comprensibili dal secondo.
Conceptualmente:
DMR NETWORK
│
▼
BRIDGE
│
▼
YSF NETWORK
Il problema è che i due sistemi non utilizzano necessariamente:
- la stessa struttura di frame;
- lo stesso sistema di indirizzamento;
- gli stessi metadati;
- la stessa gestione PTT;
- lo stesso payload vocale.
Il bridge deve quindi stabilire una corrispondenza.
Traduzione dei metadati
Immaginiamo che arrivi una comunicazione DMR:
SOURCE ID = 2221234
TG = 22215
TS = 1
CC = 1
Sul lato YSF alcuni di questi concetti semplicemente non esistono nello stesso modo.
Il bridge deve quindi trasformare:
DMR ID
in qualcosa che possa essere presentato all’altro sistema, magari associandolo a:
CALLSIGN
oppure utilizzando un identificativo configurato nel gateway.
Analogamente:
TG 22215
potrebbe essere associato a:
YSF Room XYZ
Questa associazione è una decisione di configurazione del bridge, non una proprietà intrinseca dei due protocolli.
Talkgroup e Room non sono la stessa cosa
Se configuriamo:
DMR TG 22215
↕
YSF ROOM D2ALP
l’esperienza per l’utilizzatore può sembrare identica:
tutti quelli collegati alla stessa risorsa ascoltano la conversazione.
Ma internamente sono entità differenti.
Il bridge crea una relazione:
ENTITÀ A
↕
ENTITÀ B
e si occupa di mantenere quella relazione durante la comunicazione.
E arriviamo al problema più interessante: il codec
Supponiamo che i due sistemi trasportino dati vocali compatibili.
Potremmo avere:
VOICE DATA
↓
conversione protocollo
↓
VOICE DATA
senza necessariamente ricostruire l’audio analogico.
Questo è il caso ideale.
La voce rimane nel dominio compresso e il server deve principalmente trasformare framing e signalling.
La qualità non subisce quindi un ulteriore ciclo completo:
decode
encode
Quando invece serve il transcoding
Supponiamo ora che:
SISTEMA A
utilizzi una rappresentazione vocale incompatibile con:
SISTEMA B
Il bridge non può semplicemente copiare il payload.
Deve fare:
VOICE CODEC A
↓
DECODER
↓
PCM AUDIO
↓
ENCODER
↓
VOICE CODEC B
Questo è transcoding.
Il progetto MMDVM-CrossMode di G4KLX è costruito proprio attorno a questo concetto e punta al transcoding fra D-STAR, DMR, System Fusion, P25, NXDN e FM; la sua implementazione corrente dichiara già il supporto iniziale a D-STAR, DMR, YSF DN e FM.
Perché il PCM viene usato come lingua comune?
Immaginiamo due lingue.
ITALIANO
e
GIAPPONESE
Possiamo creare un traduttore diretto.
Oppure passare attraverso una lingua intermedia.
Nei sistemi audio la lingua intermedia può essere:
PCM AUDIO
Quindi:
AMBE
↓
PCM
↓
Codec B
oppure:
Codec B
↓
PCM
↓
AMBE
Il componente che esegue questa funzione deve avere accesso ai decoder e encoder necessari.
DVSwitch: un esempio molto interessante
La suite DVSwitch utilizza componenti distinti per svolgere ruoli differenti.
MMDVM_Bridge viene descritto dal progetto come software destinato a fare bridge tra reti basate su MMDVM.
Analog_Bridge, invece, si occupa del passaggio tra audio PCM e formati vocali digitali compressi; la documentazione del progetto lo descrive esplicitamente come bridge tra AMBE/IMBE e PCM.
Concettualmente possiamo quindi avere:
RETE DIGITALE
│
▼
MMDVM_Bridge
│
▼
Analog_Bridge
│
▼
PCM
e poi dall’altro lato:
PCM
↓
Analog_Bridge
↓
MMDVM_Bridge
↓
ALTRA RETE DIGITALE
TLV, PCM e audio digitale
Nell’architettura DVSwitch possiamo vedere chiaramente la separazione.
Una parte della configurazione tratta l’audio digitale compresso.
Un’altra utilizza un’interfaccia PCM.
Le configurazioni di Analog_Bridge descrivono infatti una sezione AMBE_AUDIO, destinata all’audio compresso, e una sezione USRP, che utilizza PCM. In modalità transcoding due istanze possono essere collegate in modo che il flusso attraversi la conversione audio intermedia.
Una struttura semplificata può quindi diventare:
TLV CODEC A
↓
Analog_Bridge
↓
PCM
↓
Analog_Bridge
↓
TLV CODEC B
Un esempio: DMR → altro modo digitale
Prendiamo una comunicazione proveniente dal DMR.
RADIO DMR
↓
RF
↓
MMDVM
↓
MMDVMHost
↓
DMR NETWORK
Il bridge riceve il flusso.
Supponiamo che sia necessario effettuare transcoding:
DMR VOICE
↓
DECODER
↓
PCM
↓
ENCODER DESTINAZIONE
Successivamente vengono creati i frame necessari alla nuova rete:
PCM
↓
NUOVO VOCODER
↓
NUOVO PROTOCOLLO
↓
DESTINATION NETWORK
Perché l’audio cambia?
Qui troviamo una conseguenza inevitabile.
Ogni vocoder speech a basso bitrate è normalmente lossy.
Significa che non conserva tutta l’informazione del segnale originale.
Prendiamo:
VOCE ORIGINALE
La prima radio esegue:
VOCE
↓
VOCODER A
Al bridge:
VOCODER A
↓
PCM RICOSTRUITO
Poi:
PCM RICOSTRUITO
↓
VOCODER B
Il secondo vocoder non riceve più il microfono originale.
Riceve la ricostruzione prodotta dal primo vocoder.
È come comprimere più volte una fotografia JPEG
L’analogia non è perfetta ma rende bene l’idea.
Prendiamo una fotografia.
ORIGINALE
↓ JPEG
immagine A
↓ ricodifica JPEG
immagine B
↓ ricodifica JPEG
immagine C
Ogni passaggio può introdurre nuovi artefatti.
Con la voce succede qualcosa di simile.
Il risultato può diventare:
- più metallico;
- meno naturale;
- meno intelligibile sulle consonanti;
- più sensibile al rumore;
- caratterizzato da strani artefatti vocali.
Perché alcune conversioni suonano invece molto bene?
Perché non tutte le catene richiedono la stessa quantità di transcoding.
Possiamo avere:
CODEC A
↓
stesso CODEC A
con sola conversione di protocollo.
Oppure:
CODEC A
↓
PCM
↓
CODEC B
con transcoding completo.
La prima situazione tende a preservare meglio il payload vocale.
System Fusion: attenzione alle modalità
System Fusion introduce un’ulteriore complessità perché può utilizzare modalità vocali differenti.
MMDVM-CrossMode distingue infatti esplicitamente System Fusion DN e VW tra le modalità considerate dal progetto.
Quindi anche dire semplicemente:
“YSF”
non descrive sempre tutta la situazione.
Il bridge deve sapere quale tipo di payload sta ricevendo e quale deve produrre.
Non dimentichiamo D-STAR
MMDVMHost tratta D-STAR attraverso il relativo gateway dedicato, così come utilizza gateway distinti per gli altri protocolli.
Se vogliamo collegare:
D-STAR
a:
DMR
il bridge deve gestire differenze profonde non soltanto nella voce, ma anche nell’identificazione delle stazioni.
In DMR siamo abituati ai numeri ID.
In D-STAR l’identità radioamatoriale è fortemente legata ai callsign.
Il bridge deve quindi creare una traduzione anche a quel livello.
NXDN introduce ancora un’altra logica
MMDVMHost utilizza NXDNGateway per collegarsi alle infrastrutture NXDN e NXCore.
Immaginiamo:
DMR TG 22215
collegato a:
NXDN TG 22215
Il fatto che il numero sia identico non significa che i due Talkgroup siano tecnicamente lo stesso oggetto.
Il bridge decide:
DMR 22215
↕
NXDN 22215
e trasferisce chiamate e metadata secondo le proprie regole.
Cross-mode RF e cross-mode network non sono la stessa cosa
Altro concetto importante.
Possiamo realizzare una conversione:
RF DMR
↓
SERVER
↓
RF YSF
oppure:
NETWORK DMR
↓
SERVER
↓
NETWORK YSF
Nel primo caso abbiamo anche modem e interfacce RF.
Nel secondo lavoriamo soltanto nel dominio IP.
La catena diventa molto più corta:
DMR NETWORK
↓
BRIDGE
↓
YSF NETWORK
La latenza aumenta a ogni passaggio
Immaginiamo una catena semplice:
Radio
↓
Hotspot
↓
Internet
↓
Reflector
↓
Internet
↓
Hotspot
↓
Radio
Ora aggiungiamo:
Bridge
+
Transcoder
La comunicazione diventa:
Radio
↓
Hotspot
↓
Server A
↓
Bridge
↓
Decoder
↓
PCM buffer
↓
Encoder
↓
Server B
↓
Hotspot
↓
Radio
Ogni passaggio può aggiungere:
- buffering;
- elaborazione;
- packetizzazione;
- trasporto;
- jitter buffer.
Di conseguenza il ritardo end-to-end cresce.
Ecco perché serve lasciare spazio tra i passaggi
In analogico possiamo quasi immediatamente:
rilasciare PTT
↓
altro operatore preme PTT
Su una grande rete cross-mode è meglio evitare risposte istantanee.
Il flusso precedente deve:
terminare
↓
raggiungere bridge
↓
chiudere stream
↓
raggiungere rete remota
↓
rilasciare gli endpoint
Una breve pausa migliora enormemente la convivenza tra sistemi diversi.
Il problema del clipping
Il transcoding introduce anche un problema che non riguarda solo il codec.
Quando passiamo attraverso PCM possiamo avere differenti livelli audio.
Se il livello è troppo basso:
audio debole
Se è troppo alto:
clipping
Analog_Bridge include infatti parametri dedicati a gain, AGC e gestione audio proprio perché la conversione fra dominio digitale compresso e PCM richiede corretta gestione dei livelli.
Questo spiega perché due bridge apparentemente identici possano avere qualità audio molto differente.
AGC: utile ma non miracoloso
Possiamo utilizzare un Automatic Gain Control per compensare variazioni.
Ma un AGC troppo aggressivo può:
- amplificare il rumore;
- modificare la dinamica;
- produrre pumping;
- peggiorare alcune voci.
L’obiettivo dovrebbe sempre essere fornire al vocoder un audio già correttamente dimensionato.
Il rumore viene “tradotto” anche lui
Immaginiamo una radio con microfono rumoroso.
VOCE + RUMORE
↓
VOCODER A
↓
ricostruzione
↓
VOCODER B
Il secondo codec cerca di interpretare un segnale che contiene già artefatti del primo.
Questo può produrre il classico effetto:
voce subacquea, robotica o gorgogliante.
Nei bridge la qualità della sorgente diventa quindi ancora più importante.
Hardware vocoder e software vocoder
Per alcune conversioni possiamo utilizzare software.
In altri casi può essere necessario o conveniente un vocoder hardware.
DVSwitch supporta, ad esempio, configurazioni che possono dialogare con dispositivi AMBE dedicati attraverso AMBEServer, mentre alcune configurazioni prevedono anche decoder software alternativi.
L’architettura può quindi essere:
BRIDGE
↓
AMBEServer
↓
USB VOCODER
oppure, quando supportato:
BRIDGE
↓
SOFTWARE VOCODER
Il transcoder può essere il collo di bottiglia
Un semplice reflector può spesso replicare i pacchetti molto rapidamente.
Il transcoder deve invece:
- decodificare;
- ricostruire PCM;
- ricodificare;
- mantenere la temporizzazione.
Se arrivano molte comunicazioni simultanee, il numero di conversioni aumenta.
Per questo nelle grandi architetture è utile separare:
REFLECTOR
da:
TRANSCODER
Un bridge multiprotocollo completo
Possiamo immaginare:
┌── DMR
│
├── YSF
│
BRIDGE HUB ──┼── NXDN
│
├── D-STAR
│
└── P25
Ma attenzione.
“Supportare cinque protocolli” non significa necessariamente:
tutti parlano con tutti contemporaneamente e senza transcoding.
Bisogna conoscere la compatibilità del payload vocale e le capacità del software utilizzato.
Come progettare bene un bridge
Prima di collegare due reti bisogna rispondere ad almeno sei domande.
1. Quali protocolli?
DMR ↔ YSF?
DMR ↔ NXDN?
D-STAR ↔ DMR?
2. Quali codec?
Dobbiamo stabilire se è necessario transcoding.
3. Come traduciamo le destinazioni?
TG
ROOM
REFLECTOR
MODULE
4. Come traduciamo gli identificativi?
DMR ID
CALLSIGN
NXDN ID
5. Chi controlla il PTT?
Serve evitare collisioni e stream simultanei.
6. Come evitiamo i loop?
Se la rete A è già collegata alla rete B attraverso un altro percorso, aggiungere un secondo bridge può produrre un disastro.
Il pericolo dei loop
Immaginiamo:
DMR
↓
YSF
↓
NXDN
↓
DMR
Una trasmissione può tornare al punto di partenza.
Possiamo ottenere:
- audio duplicato;
- eco;
- PTT continuo;
- stream che non terminano;
- enorme traffico inutile.
Prima di creare bridge multipli bisogna quindi disegnare la topologia.
Meglio una topologia a stella
Una struttura ordinata può essere:
DMR
│
│
YSF ─────── CROSSMODE HUB ───── NXDN
│
│
D-STAR
Il nodo centrale stabilisce tutte le conversioni.
È molto più semplice capire:
- chi entra;
- chi esce;
- quale codec viene usato;
- dove si effettua transcoding.
Il debugging diventa molto più semplice
Se l’audio è brutto possiamo seguire:
SORGENTE
↓
INPUT BRIDGE
↓
DECODE
↓
PCM
↓
ENCODE
↓
OUTPUT BRIDGE
↓
DESTINAZIONE
e ascoltare eventualmente il PCM intermedio.
Se il PCM è già pessimo:
problema lato ingresso/decoder
Se PCM è ottimo ma l’uscita è cattiva:
problema lato encoder/output
Questa metodologia evita di modificare venti parametri contemporaneamente.
Registrare l’audio intermedio è utilissimo
Per un Sysop avanzato, salvare per pochi secondi il PCM del bridge può essere uno strumento diagnostico eccezionale.
Possiamo confrontare:
AUDIO SORGENTE
con:
PCM INTERMEDIO
e:
AUDIO DESTINAZIONE
e capire esattamente dove si introduce il degrado.
La regola d’oro: meno conversioni possibile
Se esistono due possibili percorsi:
A → B
e:
A → C → PCM → D → B
il primo è generalmente preferibile.
Ogni conversione aggiunge:
- complessità;
- latenza;
- possibili errori;
- possibile degrado vocale.
Quindi:
non effettuare transcoding se puoi semplicemente fare routing o protocol translation.
Esempio di una rete D2ALP cross-mode
Supponiamo di voler rendere disponibile una risorsa principale attraverso:
DMR
YSF
NXDN
Una possibile struttura concettuale potrebbe essere:
DMR TG
│
▼
CROSSMODE SERVER
/ \
/ \
YSF ROOM NXDN TG
Se la conversione vocale lo richiede:
TRANSCODER
viene inserito nel percorso appropriato.
Monitoring e logging dovrebbero poi mostrare:
SOURCE
PROTOCOL IN
DESTINATION
PROTOCOL OUT
TRANSCODE YES/NO
LATENCY
A quel punto abbiamo finalmente una rete osservabile e non una scatola nera.
Conclusioni
Quando una radio DMR parla con una radio YSF o NXDN, la voce non attraversa magicamente i protocolli.
Il server deve effettuare una serie di traduzioni.
La catena può essere semplice:
FRAME A
↓
PROTOCOL TRANSLATION
↓
FRAME B
oppure molto più complessa:
FRAME A
↓
ESTRAZIONE PAYLOAD
↓
DECODER VOCODER A
↓
PCM
↓
ENCODER VOCODER B
↓
GENERAZIONE FRAME B
↓
RETE B
È proprio quest’ultima operazione che chiamiamo transcoding.
Capire questa differenza spiega quasi tutto:
- perché alcuni bridge hanno audio migliore;
- perché altri producono voce robotica;
- perché aumenta la latenza;
- perché servono vocoder hardware o software;
- perché non tutti i protocolli possono essere collegati semplicemente copiando pacchetti;
- perché i loop sono pericolosi.
Un bridge ben progettato quindi non deve semplicemente:
“far parlare più reti.”
Deve farlo utilizzando il minor numero possibile di conversioni, una corretta gestione dell’audio e una topologia di rete comprensibile e controllabile.
Ed è proprio in questo punto che un semplice collegamento cross-mode diventa una vera infrastruttura digital voice.