Chi lavora con PoC radio e SIM multioperatore, prima o poi, si chiede se i parametri APN siano davvero fissi o se ci sia margine per intervenire manualmente e ottimizzare il comportamento del terminale. La risposta breve è che il margine esiste — ma i “magheggi” non funzionano tutti allo stesso modo, e alcuni possono peggiorare le cose invece di migliorarle. Serve capire cosa si può toccare, cosa è bloccato da chi e perché, e quali modifiche producono risultati reali su una PoC radio come i modelli Inrico analizzati in questa serie.
La struttura interna di un profilo APN
Quando apri il menu APN su Android (Impostazioni → Reti mobili → Nomi punti di accesso) non vedi un semplice indirizzo web. Ogni profilo APN è composto da almeno dodici parametri distinti, ciascuno con una funzione specifica e un impatto preciso sul comportamento della connessione:
Nome APN — l’etichetta leggibile dall’utente, puramente descrittiva. Modificarla non cambia nulla nel comportamento della rete. APN — il nome del punto di accesso vero e proprio (es. ibox.tim.it, web.omnitel.it, tm per Things Mobile). È il parametro che il PGW usa per identificare il gateway di destinazione. MCC e MNC — il codice paese e il codice rete. Su Android determinano su quale SIM il profilo viene applicato: un profilo con MCC=222 e MNC=01 si attiva automaticamente quando la SIM registrata ha IMSI che inizia con 222-01 (TIM). Tipo APN — definisce per quali servizi il profilo è usato: default per i dati generici, mms per gli MMS, supl per l’A-GPS, dun per il tethering, ims per il VoLTE. Protocollo APN — specifica se il traffico usa IPv4, IPv6 o entrambi (IPv4/IPv6 dual-stack). Protocollo Roaming APN — stesso parametro ma applicato specificamente quando il terminale è in roaming. MVNO Type e MVNO Value — parametri avanzati che permettono di legare il profilo APN non solo al MCC/MNC ma all’identità specifica del MVNO. MTU — la dimensione massima del pacchetto trasmissibile. Non appare nell’interfaccia standard ma è configurabile tramite ADB o MDM.
Cosa si può modificare su un Inrico con Android
I terminali Inrico con Android 10, 13 e 14 (S300 Pro, S300 Plus, S350, T330/T338, S380, IRC390) usano Android con modifiche minimali al framework di rete — non sono smartphone consumer con APN pre-bloccati dagli operatori, ma terminali professionali con accesso completo alle impostazioni di rete. Su questi modelli, aprendo il menu APN, è possibile creare un nuovo profilo con parametri completamente personalizzati e renderlo il profilo di default.
I modelli più datati con Android 7.1 e 8.1 (TM-9, S100, T310) possono presentare il problema documentato delle APN bloccate in sola lettura su alcuni firmware: il sistema carica i profili APN predefiniti da un file XML nella partizione di sistema e li contrassegna come non modificabili. In questo caso esiste una procedura — documentata nella community Android — che consiste nel creare un nuovo profilo APN con lo stesso nome di quello bloccato, copiare tutti i parametri nel nuovo profilo e poi modificarli: Android unisce i due profili identici in uno solo, che diventa modificabile. Questa procedura non richiede root e funziona su tutti i dispositivi Android dalla versione 5 in su.
I parametri che producono effetti reali
Dei dodici parametri di un profilo APN, tre producono effetti misurabili sul comportamento di una PoC radio con SIM multioperatore.
Il primo è il Tipo APN. Se il profilo della SIM multioperatore contiene solo default, il terminale usa quello stesso APN per tutti i servizi — dati, MMS, A-GPS e tethering. In un contesto PTT professionale, aggiungere supl allo stesso profilo accelera notevolmente la prima acquisizione del segnale GPS (A-GPS usa i server di posizionamento assistito dell’operatore per calcolare una posizione approssimativa prima che il ricevitore GPS agganci i satelliti) — riducendo il Time To First Fix da 30-60 secondi a 3-8 secondi in ambienti con scarsa visibilità del cielo. Aggiungere dun permette di usare il terminale come modem in tethering — utile nelle installazioni veicolari TM-9 e TM-7 Plus dove la radio funge anche da hotspot per altri dispositivi nel veicolo.
Il secondo è il Protocollo Roaming APN. La scelta tra IPv4, IPv6 e IPv4/IPv6 dual-stack ha impatti concreti sulla latenza PTT in roaming. La maggior parte dei server PTT italiani risponde ancora su IPv4. Se il profilo APN in roaming è configurato per IPv6 puro, il terminale deve richiedere un tunnel IPv4-in-IPv6 (NAT64) — un’operazione che aggiunge 5-15 ms di overhead. Configurare il Protocollo Roaming APN su IPv4/IPv6 dual-stack risolve il problema: Android tenta prima IPv4 diretto (più veloce verso server italiani) e usa IPv6 solo se l’IPv4 non è disponibile.
Il terzo è l’MTU (Maximum Transmission Unit). Il valore standard in LTE è 1500 byte. Alcune reti in roaming applicano ulteriori header di incapsulamento GTP che riducono l’MTU effettivo disponibile, causando la frammentazione dei pacchetti — un fenomeno che degrada le prestazioni di qualsiasi stream in tempo reale, voce PTT inclusa. Abbassare manualmente l’MTU a 1400 o 1450 byte elimina la frammentazione a costo di un leggero aumento del numero di pacchetti trasmessi. Questo parametro non è accessibile nell’interfaccia grafica di Android ma si imposta via ADB con il comando adb shell ip link set rmnet_data0 mtu 1450 (dove rmnet_data0 è l’interfaccia di rete mobile del terminale) oppure tramite un profilo MDM.
Il parametro MVNO Type: il più sottovalutato
Il campo MVNO Type merita un capitolo a parte perché è quello che più spesso causa comportamenti imprevedibili con le SIM multioperatore — e che pochi tecnici conoscono a fondo.
Quando Android deve scegliere quale profilo APN attivare, non guarda solo MCC e MNC: guarda anche il MVNO Type e il MVNO Value del profilo. Il MVNO Type può essere impostato su quattro valori: None (nessun filtro MVNO, il profilo si applica a chiunque con quel MCC/MNC), SPN (Service Provider Name — il profilo si applica solo se la SIM presenta un nome di provider specifico), IMSI (il profilo si applica solo se i primi N digit dell’IMSI corrispondono al valore specificato), GID (Group Identifier — usato dagli operatori per distinguere sottogruppi di abbonati).
Su una SIM multioperatore con IMSI straniero (es. MCC=234, MNC=30 per T-Mobile UK) registrata su TIM Italia in roaming, se nel terminale esiste un profilo APN con MCC=222, MNC=01 (TIM Italia) e MVNO Type=None, quel profilo non verrà attivato — perché l’IMSI della SIM non corrisponde alla rete domestica TIM. Android legge l’IMSI effettivo della SIM, non il PLMN della rete registrata. Il profilo APN corretto per una SIM multioperatore deve avere MCC e MNC corrispondenti all’IMSI fisico della SIM (es. 234-30 per T-Mobile UK) oppure usare valori generici. Configurare un profilo APN con MCC=0 e MNC=0 su alcuni firmware Android crea un profilo “catch-all” che si applica a qualsiasi SIM indipendentemente dall’IMSI — la soluzione più semplice per garantire la connessione dati su qualsiasi rete in roaming.
Cosa non si può modificare (e perché)
Ci sono limiti precisi che non è possibile aggirare senza intervenire sul software di sistema. Il primo è la logica di selezione della rete: la PLMN Priority List è scritta nella memoria protetta della SIM e non è accessibile da Android. Non esiste parametro APN che influenzi su quale operatore la SIM si registra — quella logica è gestita dal firmware della SIM, non dal sistema operativo del terminale.
Il secondo è la politica di traffico del PGW remoto: il fornitore della SIM può imporre sul proprio PGW limiti di banda, regole di routing e filtri di traffico che nessuna modifica APN lato terminale può aggirare. Se il fornitore ha configurato il PGW per non permettere il tethering su un certo piano, impostare dun nel tipo APN non farà nulla — il PGW rifiuterà la sessione dedicata.
Il terzo limite riguarda il VoLTE in roaming. Il VoLTE (Voice over LTE, voce digitale ad alta qualità tramite IMS) richiede che l’operatore ospite supporti il HR-VoLTE (Home Routed VoLTE) — un accordo tecnico bilaterale che in Italia è ancora parzialmente implementato tra gli MNO. Anche configurando manualmente il tipo APN ims con i parametri corretti, il VoLTE in roaming funzionerà solo se sia l’operatore ospite sia il fornitore della SIM hanno attivato gli accordi bilaterali. Per le PoC radio questo non è un problema critico — il PTT usa traffico dati IP, non VoLTE — ma è un limite da conoscere per chi volesse usare le chiamate vocali tradizionali sul terminale.
La configurazione APN ottimale per SIM multioperatore su PoC Inrico
Partendo da tutto quanto sopra, la configurazione APN raccomandata per una SIM multioperatore professionale su terminali Inrico della serie S e IRC è la seguente:
| Parametro | Valore raccomandato | Motivo |
|---|
| Nome | Nome del fornitore SIM | Solo descrittivo |
| APN | APN fornito dal fornitore | Es. tm, simbase, iot.provider.com |
| MCC | MCC dell’IMSI fisico della SIM | Deve corrispondere all’IMSI, non alla rete ospite |
| MNC | MNC dell’IMSI fisico della SIM | Stessa logica del MCC |
| Tipo APN | default,supl,dun | Dati + GPS assistito + tethering |
| Protocollo APN | IPv4/IPv6 | Dual stack, priorità IPv4 |
| Protocollo Roaming APN | IPv4/IPv6 | Evita overhead NAT64 in roaming |
| MVNO Type | None | Profilo universale, non legato a SPN/IMSI specifico |
| MVNO Value | (vuoto) | Necessariamente vuoto con MVNO Type=None |
Se il terminale mostra l’APN bloccato in sola lettura, applicare la procedura di duplicazione-unione descritta in precedenza su Android 8.1, oppure — nei modelli con Android 10+ — usare un profilo MDM per forzare la configurazione APN via policy di gestione remota. I terminali Inrico con GMS (S300 Pro, S300 Plus, S350, S380, IRC380, IRC390, T330/T338) supportano l’enrollment in piattaforme MDM standard come Android Enterprise, che permette il push della configurazione APN sull’intera flotta in modo centralizzato senza toccare fisicamente ogni dispositivo.
ADB: lo strumento per chi vuole andare più in profondità
Per chi non ha paura della riga di comando, ADB (Android Debug Bridge) apre possibilità che l’interfaccia grafica non offre. Con ADB abilitato sul terminale (Opzioni sviluppatore → Debug USB) e il PC connesso via USB, è possibile intervenire su parametri di rete non esposti dall’interfaccia grafica:
Verificare l’interfaccia di rete attiva e il suo MTU corrente: adb shell ip link show. Impostare l’MTU manualmente: adb shell ip link set rmnet_data0 mtu 1400. Visualizzare le statistiche di traffico in tempo reale per diagnosticare perdite di pacchetti: adb shell cat /proc/net/dev. Forzare la selezione manuale della rete radio su un PLMN specifico (utile per test comparativi tra operatori): adb shell service call phone 3 s16 "222 01" (dove 222 01 è il PLMN di TIM Italia). Questo ultimo comando è utile in fase di testing sul campo per verificare quale operatore garantisce la latenza PTT più bassa in una specifica location — un test che vale la pena fare prima di configurare la PLMN Priority List della SIM multioperatore.
Attenzione: le modifiche via ADB sono temporanee e si perdono al riavvio del terminale. Per renderle permanenti su Android 10+ serve o un’app di sistema con permessi CHANGE_NETWORK_STATE (richiede firma di sistema) oppure un profilo MDM con policy di rete persistente.
Il verdetto pratico
I “magheggi” sull’APN funzionano, ma con una gerarchia precisa di impatto reale. La configurazione del Tipo APN (aggiungendo supl e dun) porta benefici immediati e misurabili senza rischi. La configurazione del Protocollo Roaming su IPv4/IPv6 dual-stack riduce la latenza PTT in roaming di qualche millisecondo — poca cosa in valore assoluto ma migliore in contesti critici. La corretta impostazione di MCC/MNC e MVNO Type è fondamentale per garantire che il profilo APN si attivi effettivamente sulla SIM multioperatore invece di rimanere inerte. La modifica dell’MTU via ADB è una ottimizzazione avanzata utile in scenari con reti in roaming che introducono overhead di incapsulamento.
Quello che nessuna modifica APN può fare è cambiare su quale operatore la SIM si registra, aggirare le policy del PGW del fornitore o abilitare funzionalità che richiedono accordi bilaterali tra operatori. Quelli sono limiti di architettura, non di configurazione — e nessun terminale, per quanto avanzato, può aggirarli dal lato software.
Siamo su TELEGRAM!
