Latenza, jitter e packet loss nelle reti digitali vocali.

Introduzione

Quando una comunicazione digitale presenta audio metallico, parole spezzate, ritardi o improvvise interruzioni, la prima reazione è spesso attribuire il problema alla copertura radio.

In realtà, una rete vocale digitale è composta da almeno due ambienti distinti:

• il collegamento radio fra utente e ripetitore;
• il collegamento IP fra ripetitore, server, reflector e altri nodi.

Un segnale RF perfetto non garantisce quindi un audio perfetto. Se la connessione Internet perde pacchetti, cambia continuamente ritardo o introduce code eccessive, il risultato può essere molto simile a quello prodotto da una cattiva ricezione radio.

Per diagnosticare correttamente questi problemi occorre conoscere tre parametri fondamentali:

• latenza;
• jitter;
• packet loss.

Come viaggia la voce digitale

La voce dell’operatore viene inizialmente convertita in dati da un codec. I dati vengono suddivisi in blocchi o frame e trasmessi via radio.

Il ripetitore riceve il segnale, estrae i frame e può inoltrarli attraverso una rete IP. I pacchetti attraversano router, collegamenti radio, fibra, reti mobili, VPN e server prima di raggiungere gli altri nodi.

A destinazione, i pacchetti devono essere ricomposti e riprodotti con continuità.

La rete IP, però, non garantisce che ogni pacchetto:

• impieghi lo stesso tempo;
• segua lo stesso percorso;
• arrivi nell’ordine corretto;
• arrivi prima del momento di riproduzione;
• arrivi effettivamente.

Le applicazioni in tempo reale devono quindi compensare, entro certi limiti, le imperfezioni della rete.

Che cos’è la latenza

La latenza è il tempo impiegato da un’informazione per raggiungere la propria destinazione.

Può essere misurata in due modi:

• one-way delay, ritardo in una sola direzione;
• round-trip time, tempo di andata e ritorno.

Il comando ping misura normalmente il round-trip time, non il ritardo unidirezionale. La sua statistica finale riporta i tempi minimo, medio, massimo e una misura della variabilità rispetto alla media.

La latenza totale di una comunicazione vocale comprende più componenti:

1. acquisizione del microfono;
2. codifica della voce;
3. formazione del frame;
4. trasmissione radio;
5. elaborazione del ripetitore;
6. trasporto IP;
7. eventuale elaborazione del server;
8. jitter buffer;
9. decodifica;
10. riproduzione audio.

Un ping di 40 millisecondi non significa pertanto che l’utente ascolterà la voce con soli 20 o 40 millisecondi di ritardo. Il sistema aggiunge inevitabilmente tempi di elaborazione e buffering.

Quanta latenza è accettabile

La raccomandazione ITU-T G.114 indica che un ritardo unidirezionale fino a circa 150 millisecondi è generalmente accettabile per la maggior parte delle applicazioni vocali. Fra 150 e 400 millisecondi la comunicazione può ancora essere utilizzabile, ma il ritardo influenza sensibilmente la conversazione. Oltre 400 millisecondi la condizione non è considerata adatta alla pianificazione generale delle reti vocali, salvo casi eccezionali.

Questi valori riguardano la trasmissione vocale complessiva e non il solo ping verso un server.

In una rete radioamatoriale, una latenza eccessiva si manifesta attraverso:

• risposte sovrapposte;
• difficoltà nel capire quando l’altro operatore ha terminato;
• pause innaturali;
• doppie trasmissioni;
• ritardo nell’attivazione dell’audio;
• perdita delle prime sillabe;
• sensazione di collegamento satellitare.

Il problema diventa particolarmente evidente durante i QSO con passaggi brevi e frequenti.

Le cause della latenza

Una parte del ritardo è inevitabile. La propagazione fisica, la codifica e il buffering richiedono tempo.

La latenza può però aumentare a causa di:

• percorsi Internet molto lunghi;
• server collocati geograficamente lontano;
• VPN non ottimizzate;
• collegamenti mobili;
• ponti Wi-Fi congestionati;
• router sovraccarichi;
• buffer eccessivamente grandi;
• upload saturato;
• elaborazione lenta sul nodo;
• transcoding fra codec differenti;
• catene con numerosi bridge;
• DNS o riconnessioni frequenti nella fase di avvio.

Uno dei fenomeni più insidiosi è il bufferbloat: quando il router accumula grandi quantità di traffico in coda, i pacchetti non vengono persi immediatamente, ma rimangono bloccati per centinaia di millisecondi o perfino secondi.

La connessione può quindi apparire veloce durante uno speed test, ma diventare inadatta alla voce quando qualcuno avvia un upload, un backup o una videocamera ad alto bitrate.

Che cos’è il jitter

Nel linguaggio delle reti vocali, il jitter rappresenta la variazione del tempo di arrivo dei pacchetti.

Supponiamo che il trasmettitore generi un pacchetto ogni 20 millisecondi.

In una rete ideale i pacchetti arriverebbero così:

0 ms — 20 ms — 40 ms — 60 ms — 80 ms

In una rete reale potrebbero arrivare:

0 ms — 24 ms — 37 ms — 68 ms — 82 ms

Il ritardo medio potrebbe essere ancora relativamente basso, ma gli intervalli non sono regolari.

RFC 3550 considera l’interarrival jitter una misura a breve termine delle variazioni nella rete: la perdita di pacchetti tende a segnalare congestione persistente, mentre il jitter può evidenziare una congestione transitoria prima che questa provochi perdite.

Il jitter buffer

Per compensare l’arrivo irregolare, il ricevitore utilizza un jitter buffer o de-jitter buffer.

Il sistema non riproduce immediatamente il primo pacchetto ricevuto. Attende per un breve intervallo, accumulando alcuni pacchetti. Successivamente li riproduce a ritmo costante.

Il buffer trasforma quindi:

ARRIVO IRREGOLARE → ACCUMULO → RIPRODUZIONE REGOLARE

Se il buffer è troppo piccolo, un pacchetto leggermente in ritardo non sarà disponibile al momento della riproduzione e verrà considerato perso.

Se il buffer è troppo grande, la voce sarà fluida ma la latenza complessiva aumenterà.

RFC 5481 descrive esattamente questo compromesso: il buffer deve essere abbastanza grande da assorbire la variazione del ritardo, ma un buffer eccessivo riduce la naturalezza e la spontaneità della conversazione.

Buffer fisso e buffer adattivo

Un buffer fisso utilizza sempre lo stesso tempo di attesa.

È semplice e prevedibile, ma può funzionare male quando le condizioni della rete cambiano.

Un buffer adattivo modifica dinamicamente la propria dimensione:

• aumenta quando cresce il jitter;
• diminuisce quando la rete torna stabile;
• scarta i pacchetti troppo tardivi;
• cerca di mantenere il miglior compromesso fra continuità e ritardo.

Gli adattamenti possono però produrre piccoli salti temporali, ripetizioni o soppressioni di campioni audio. ITU-T G.1020 considera espressamente l’interazione fra variazione del ritardo, perdita di pacchetti, de-jitter buffer e tecniche di concealment.

Che cos’è il packet loss

Il packet loss è la perdita di uno o più pacchetti durante il trasporto.

Un pacchetto può essere perso perché:

• viene scartato da una coda piena;
• attraversa un collegamento instabile;
• arriva corrotto;
• viene bloccato da un firewall;
• viene inoltrato verso un percorso non più valido;
• arriva oltre il termine utile;
• il ricevitore non riesce a elaborarlo in tempo;
• una sessione UDP viene temporaneamente interrotta.

Dal punto di vista dell’audio, anche un pacchetto ricevuto ma arrivato dopo il proprio istante di riproduzione equivale spesso a un pacchetto perso.

I sistemi di monitoraggio distinguono infatti fra pacchetti realmente mancanti e pacchetti scartati perché giunti troppo presto o troppo tardi rispetto al buffer di riproduzione.

Perché non basta conoscere la percentuale media

Dire che una connessione ha perso l’1% dei pacchetti non descrive completamente il problema.

Dieci pacchetti persi e distribuiti nell’arco di alcuni minuti possono produrre piccoli difetti occasionali.

Dieci pacchetti consecutivi persi nello stesso istante possono cancellare una parte importante di una parola.

La distribuzione della perdita è quindi fondamentale.

Perdita casuale

I pacchetti mancanti sono isolati. Il codec o il decoder può talvolta ricostruire o mascherare parzialmente il contenuto.

Perdita a raffica

Più pacchetti consecutivi vengono persi. Il ricevitore non dispone di informazioni sufficienti e l’audio può interrompersi completamente.

Gli standard RTCP-XR prevedono metriche separate per la perdita durante le raffiche e durante gli intervalli regolari, proprio perché gli effetti percettivi sono differenti.

Come reagisce il decoder

Quando manca un frame audio, il decoder può utilizzare tecniche di Packet Loss Concealment.

A seconda del codec e dell’implementazione, il sistema può:

• ripetere una porzione del suono precedente;
• interpolare i campioni;
• inserire rumore di comfort;
• attenuare gradualmente l’audio;
• ricostruire una stima della voce;
• produrre silenzio.

Queste tecniche non recuperano realmente i dati perduti. Cercano soltanto di rendere il difetto meno fastidioso. RFC 7294 descrive il loss concealment come la generazione di campioni sostitutivi quando un frame codificato non è disponibile al decoder nel momento necessario.

La capacità di mascherare la perdita dipende da:

• codec;
• durata del frame;
• numero di frame consecutivi mancanti;
• tipo di voce;
• rumore;
• presenza di correzione d’errore;
• implementazione del decoder.

Perché la ritrasmissione non sempre serve

Nei trasferimenti di file è possibile chiedere nuovamente un pacchetto perso. La correttezza è più importante della velocità.

Nella voce in tempo reale, invece, un pacchetto ritrasmesso potrebbe arrivare quando la parola è già stata riprodotta. Recuperarlo non avrebbe più utilità e aumenterebbe ulteriormente la latenza.

Per questo molti sistemi real-time preferiscono tollerare una piccola perdita piuttosto che attendere una ritrasmissione. I meccanismi RTP che prevedono la ritrasmissione devono valutare attentamente il tempo disponibile prima che il pacchetto diventi inutilizzabile.

Come distinguere un problema RF da un problema IP

La diagnosi può iniziare osservando dove compare il difetto.

Probabile problema RF

• il difetto riguarda soltanto un utente;
• il segnale ricevuto è basso o instabile;
• aumenta spostandosi o schermando l’antenna;
• il BER radio peggiora;
• il ripetitore riceve frame corrotti già all’ingresso;
• l’audio locale del ponte è degradato.

Probabile problema IP

• tutti gli utenti remoti ascoltano interruzioni;
• l’audio locale è corretto ma quello di rete è degradato;
• il difetto coincide con traffico Internet intenso;
• più ripetitori presentano simultaneamente lo stesso problema;
• il server mostra disconnessioni;
• ping e test UDP evidenziano variazioni o perdite;
• il problema cambia secondo l’operatore Internet.

Possibile problema del server

• numerosi nodi geograficamente diversi mostrano lo stesso difetto;
• la latenza cresce soltanto verso uno specifico master o reflector;
• il server presenta carico elevato;
• i processi accumulano code;
• il problema compare durante riavvii o riconnessioni.

Misurare la latenza con ping

Un primo test può essere effettuato con:

ping -c 100 indirizzo-del-server

Il risultato consente di osservare:

• RTT minimo;
• RTT medio;
• RTT massimo;
• variabilità;
• eventuale perdita ICMP.

Il test deve essere eseguito verso una destinazione realmente significativa: router della postazione, endpoint VPN, server della rete o altro nodo coinvolto.

Un ping verso un grande motore di ricerca può dimostrare che Internet funziona, ma non descrive necessariamente il percorso utilizzato dal traffico radio.

Occorre inoltre ricordare che alcuni router assegnano bassa priorità ai pacchetti ICMP. Un ping anomalo non prova da solo che il traffico vocale sia degradato.

Testare la rete sotto carico

La misura più interessante è spesso quella effettuata mentre la connessione viene utilizzata.

Si può avviare un ping continuo e contemporaneamente:

• eseguire un upload;
• visualizzare una telecamera remota;
• effettuare un backup;
• scaricare un file;
• attivare il traffico radio.

Se il ping passa improvvisamente da 20 a 500 millisecondi durante l’upload, è probabile che il collegamento soffra di code eccessive.

Per una postazione remota è importante verificare soprattutto l’upload, perché il traffico proveniente dal ripetitore deve uscire verso Internet.

Misurare jitter e perdita con iperf3

iperf3 è uno strumento destinato alla misurazione delle prestazioni di rete e supporta test TCP, UDP e SCTP. In modalità UDP consente di impostare il bitrate e osservare throughput, jitter e perdita. Richiede un server a un’estremità e un client all’altra.

Sul server:

iperf3 -s

Sul client:

iperf3 -c 192.168.1.10 -u -b 128K -t 60

Il parametro -u seleziona UDP, -b imposta il bitrate e -t la durata.

Il bitrate di prova dovrebbe essere scelto in modo realistico. Un test a centinaia di megabit può misurare la capacità massima della linea, ma non riproduce il comportamento di un piccolo flusso vocale.

È utile ripetere il test:

• in entrambe le direzioni;
• in diversi orari;
• con rete libera;
• durante un upload;
• con e senza VPN;
• prima e dopo ogni modifica.

Simulare una rete degradata

Linux permette di utilizzare netem per introdurre artificialmente ritardo, variazione, perdita, duplicazione e corruzione dei pacchetti. È uno strumento utile in laboratorio per verificare come reagiscono gateway, bridge e applicazioni vocali.

Esempio di prova su un’interfaccia di laboratorio:

sudo tc qdisc add dev eth0 root netem delay 50ms 10ms loss 1%

Questo comando introduce:

• 50 ms di ritardo;
• una variazione di circa 10 ms;
• perdita dell’1% dei pacchetti.

Al termine:

sudo tc qdisc del dev eth0 root

Questi test devono essere eseguiti soltanto su un banco prova o su un’interfaccia controllata. Applicare netem alla connessione di un ripetitore operativo può interrompere il servizio o rendere irraggiungibile la postazione.

Catturare il traffico

Quando il problema è intermittente, può essere utile catturare i pacchetti con tcpdump o Wireshark.

Esempio:

sudo tcpdump -i eth0 -nn -w traffico-radio.pcap

Il file può essere analizzato successivamente per verificare:

• sequenze mancanti;
• intervalli fra pacchetti;
• porte utilizzate;
• indirizzi sorgente e destinazione;
• riconnessioni;
• duplicazioni;
• variazioni del flusso;
• eventuali messaggi di errore.

tcpdump è uno strumento di cattura del traffico e può richiedere privilegi specifici sull’interfaccia.

La cattura deve essere gestita con attenzione perché potrebbe contenere indirizzi IP, nominativi, identificativi e informazioni operative.

Metriche da registrare

Per monitorare seriamente una rete non basta osservare un valore istantaneo.

È utile registrare nel tempo:

• RTT minimo, medio e massimo;
• percentili della latenza;
• perdita complessiva;
• perdita a raffica;
• jitter;
• numero di riconnessioni;
• durata delle sessioni;
• traffico in ingresso e uscita;
• saturazione dell’upload;
• carico CPU;
• memoria;
• temperatura;
• stato della VPN;
• errori dell’interfaccia Ethernet;
• qualità del collegamento radio IP.

I valori medi possono nascondere eventi brevi ma molto dannosi. Un collegamento con media di 30 ms potrebbe avere picchi periodici di un secondo che interrompono ogni passaggio radio.

Per questo sono importanti grafici temporali e percentili elevati, non soltanto la media.

Una politica operativa per D2ALP

Non esiste un singolo limite valido per ogni protocollo, codec e jitter buffer. Per una rete come D2ALP si può però adottare una politica prudenziale.

Latenza

• mantenere il percorso verso il server il più breve possibile;
• investigare aumenti improvvisi rispetto al valore abituale;
• evitare che il solo trasporto IP consumi gran parte del limite end-to-end;
• confrontare rete libera e rete sotto carico.

Jitter

• definire una condizione normale per ogni postazione;
• generare un allarme quando la variabilità supera stabilmente la baseline;
• analizzare i picchi e non soltanto la media;
• verificare se il jitter aumenta durante upload o backup.

Perdita

• assumere come obiettivo operativo lo 0%;
• considerare significativa qualsiasi perdita persistente;
• distinguere perdita casuale e perdita a raffica;
• correlare gli eventi con log del router, della VPN e del server.

Questi criteri non sono limiti normativi: rappresentano una strategia conservativa per mantenere stabile una rete vocale.

Quality of Service

La QoS può assegnare maggiore priorità ai pacchetti vocali rispetto ad attività meno sensibili al tempo.

Può essere utile quando la stessa connessione trasporta:

• telecamere;
• aggiornamenti;
• backup;
• accesso remoto;
• navigazione;
• traffico del ripetitore.

La QoS non crea nuova banda. Se il collegamento è guasto o fortemente sottodimensionato, la prioritizzazione non risolve il problema.

Può però impedire che un upload occupi completamente la coda e ritardi i pacchetti radio.

La classificazione dovrebbe essere applicata nel punto in cui si forma la congestione, generalmente sul router che controlla il collegamento più lento.

Separare il traffico

Una postazione ben progettata dovrebbe separare logicamente:

• traffico radio;
• amministrazione;
• videosorveglianza;
• dispositivi IoT;
• accesso degli ospiti;
• aggiornamenti;
• backup.

VLAN, firewall e code distinte rendono più semplice:

• proteggere gli apparati;
• diagnosticare i problemi;
• applicare QoS;
• limitare una telecamera mal configurata;
• evitare che un dispositivo compromesso interferisca con la rete radio.

VPN e sovraccarico

Una VPN aumenta la sicurezza, ma introduce elaborazione e overhead.

Su hardware moderno il costo può essere trascurabile. Su router economici o Raspberry Pi molto vecchi, la cifratura può saturare la CPU e produrre:

• aumento della latenza;
• jitter;
• perdita;
• riduzione del throughput;
• riconnessioni.

La diagnosi deve quindi comprendere il carico del processore e non soltanto la velocità nominale della connessione.

Disattivare permanentemente la VPN non è una buona soluzione. Occorre piuttosto utilizzare hardware adeguato, configurazioni efficienti e percorsi non inutilmente complessi.

Collegamenti 4G e 5G

Le reti mobili possono fornire ottime velocità, ma la latenza può variare secondo:

• congestione della cella;
• cambio di banda;
• qualità del segnale;
• priorità assegnata dall’operatore;
• handover;
• NAT dell’operatore;
• condizioni radio;
• risparmio energetico del modem.

Una postazione su rete mobile dovrebbe essere valutata per diversi giorni e in orari differenti.

Una misura effettuata alle tre del mattino non rappresenta necessariamente la condizione delle ore serali.

Collegamenti Wi-Fi

Un ponte Wi-Fi può essere affidabile se correttamente progettato, ma utilizza un mezzo condiviso.

Interferenze, segnale insufficiente, riflessioni e ritrasmissioni radio possono aumentare la variazione del ritardo senza produrre immediatamente una disconnessione.

È necessario controllare:

• livello ricevuto;
• rapporto segnale-rumore;
• occupazione del canale;
• modulazione utilizzata;
• ritrasmissioni;
• capacità effettiva;
• allineamento delle antenne;
• zona di Fresnel;
• stabilità dell’alimentazione.

Procedura pratica di diagnosi

Una procedura ordinata può seguire questi passaggi.

1. Stabilire dove nasce il difetto

Confrontare audio locale, audio proveniente dalla rete e comportamento degli altri nodi.

2. Controllare la radiofrequenza

Verificare livello ricevuto, BER, antenna, duplexer, filtri e interferenze.

3. Misurare il percorso IP

Eseguire ping verso gateway, endpoint VPN e server.

4. Provare la rete sotto carico

Ripetere le misure durante upload e attività della postazione.

5. Effettuare un test UDP

Usare iperf3 con bitrate realistico e in entrambe le direzioni.

6. Controllare router e VPN

Verificare CPU, memoria, code, errori e riconnessioni.

7. Analizzare i pacchetti

Registrare una cattura durante il difetto.

8. Modificare un elemento per volta

Cambiare simultaneamente router, provider, VPN e server impedisce di capire quale intervento abbia risolto il problema.

9. Conservare una baseline

Registrare i valori normali della postazione per poter riconoscere rapidamente le variazioni future.

Errori comuni

Uno degli errori più frequenti è affidarsi esclusivamente allo speed test.

Una linea da 500 Mbit/s può avere più jitter di una linea da 30 Mbit/s ben gestita.

Un altro errore consiste nel valutare soltanto il ping medio. La voce può essere disturbata da picchi brevi che la media nasconde.

È inoltre sbagliato aumentare indefinitamente il jitter buffer. L’audio può diventare più continuo, ma il QSO sarà sempre più ritardato.

Infine, non bisogna confondere packet loss radio e packet loss IP. Entrambi possono produrre suoni simili, ma richiedono interventi completamente diversi.

Conclusione

La qualità di una rete radio digitale non dipende soltanto da antenne, potenza e copertura.

Dopo che il segnale è stato ricevuto dal ripetitore, la comunicazione continua attraverso un’infrastruttura informatica che deve rispettare requisiti temporali molto più severi rispetto alla normale navigazione web.

La latenza determina quanto tempo impiega la voce ad arrivare.

Il jitter descrive quanto quel tempo varia.

Il packet loss misura quanta informazione non raggiunge utilmente la destinazione.

Questi tre parametri devono essere considerati insieme. Una rete può avere latenza media bassa ma jitter elevato, oppure nessuna perdita apparente ma code talmente grandi da rendere innaturale la conversazione.

Misurare, registrare e confrontare i dati permette di trasformare un generico “si sente male” in una diagnosi tecnica.

Per una rete come D2ALP, il monitoraggio della qualità IP dovrebbe avere la stessa importanza della manutenzione delle antenne e dei trasmettitori: perché una comunicazione digitale è realmente affidabile soltanto quando funzionano bene sia la radio sia la rete.