A partire dal 2026, per allinearci al nostro modello di sviluppo trunk stabile e garantire la stabilità della piattaforma per l'ecosistema, pubblicheremo il codice sorgente su AOSP nel secondo e nel quarto trimestre. Per compilare e contribuire ad AOSP, utilizza android-latest-release. Il branch del manifest android-latest-release farà sempre riferimento alla release più recente pubblicata su AOSP. Per saperne di più, consulta la sezione Modifiche ad AOSP.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Network slicing 5G

Per i dispositivi con Android 12 o versioni successive, Android supporta lo slicing della rete 5G, l'utilizzo della virtualizzazione della rete per dividere le singole connessioni di rete in più connessioni virtuali distinte che forniscono quantità diverse di risorse a diversi tipi di traffico. Il network slicing 5G consente agli operatori di rete di dedicare una parte della rete a fornire funzionalità specifiche per un particolare segmento di clienti. Android 12 introduce le seguenti funzionalità di slicing della rete aziendale 5G, che gli operatori di rete possono fornire ai propri clienti aziendali:

Suddivisione dei dispositivi aziendali per i dispositivi completamente gestiti

Per le aziende che forniscono dispositivi aziendali completamente gestiti ai propri dipendenti, i fornitori di rete possono fornire una o più sezioni di rete aziendale attive a cui viene indirizzato il traffico sui dispositivi aziendali. A partire da Android 12, Android consente agli operatori di fornire sezioni aziendali tramite regole URSP, anziché configurare le sezioni tramite APN.

Sezionamento delle app aziendali Enterprise per i dispositivi con profili di lavoro

Per le aziende che utilizzano la soluzione profilo di lavoro, Android 12 consente ai dispositivi di instradare il traffico di tutte le app nel profilo di lavoro a una sezione di rete aziendale. Le aziende possono attivare questa funzionalità tramite un controller dei criteri dei dispositivi (DPC).

La soluzione del profilo di lavoro fornisce un livello automatico di autenticazione e controllo dell'accesso richiesto dalle aziende per garantire che solo il traffico proveniente dalle app aziendali nel profilo di lavoro venga indirizzato alla sezione di rete aziendale. Le app nel profilo di lavoro non devono essere modificate per richiedere esplicitamente lo slice di rete aziendale.

Come funziona lo slicing della rete 5G in AOSP

Android 12 introduce il supporto del network slicing 5G tramite aggiunte al codebase di telefonia in AOSP e al modulo Tethering per incorporare le API di connettività esistenti necessarie per il network slicing.

La piattaforma di telefonia Android fornisce API HAL e di telefonia per supportare lo slicing in base alle richieste di rete presentate dal codice di rete principale e alle funzionalità di slicing 5G nel modem. La Figura 1 descrive i componenti della funzionalità di slicing della rete 5G.

Componenti dello slicing di rete 5G

Figura 1. Architettura di slicing della rete 5G in AOSP.

La piattaforma di telefonia e connettività supporta:

Conversione delle richieste di rete per le categorie di slice in descrittori di traffico che vengono poi passati al modem per la corrispondenza del traffico URSP e la selezione della route
Eseguire il fallback alla rete predefinita se lo slice di rete aziendale non è disponibile
Instradamento del traffico da tutte le app nel profilo di lavoro alla connessione corrispondente
Supporto del sezionamento aziendale
- Rilevamento della presenza di un profilo di lavoro sul dispositivo
- Controllo delle autorizzazioni o delle indicazioni stradali fornite dal DPC utilizzato dall'amministratore IT dell'azienda

Il servizio di rete principale include le seguenti modifiche al modulo Tethering in Android 12:

Aggiunge la maggior parte delle classi API pubbliche o di sistema di android.net.* al modulo Tethering
Espande i limiti del modulo Tethering per includere:
- f/b/core/java/android/net/…
- f/b/services/net/…
- f/b/services/core/java/com/android/server/connectivity/…
- f/b/services/core/java/com/android/server/ConnectivityService.java
- f/b/services/core/java/com/android/server/TestNetworkService.java
Sposta il codice VPN dal modulo Tethering

Android 12 sposta il codice con le seguenti funzionalità nel modulo Tethering:

Ricezione di richieste di connessione di rete dalle app
Ricezione di richieste dal sistema (ad esempio "inserisci queste app in una sezione aziendale"; introdotto in Android 12)
Invio di richieste dal sistema al codice di telefonia che tenta di configurare reti o sezioni tramite l'API HAL e il modem
Comunicare a netd come instradare il traffico in base all'app (introdotto in Android 12)
Informare le app su cosa sta succedendo al loro traffico di rete tramite API ConnectivityManager come NetworkCallback, getActiveNetwork, getNetworkCapabilities.

Implementazione

Per supportare lo slicing 5G su un dispositivo, quest'ultimo deve avere un modem che supporti l'HAL IRadio 1.6, che include l'API setupDataCall_1_6. Questa API configura una connessione dati e include i seguenti parametri per supportare lo slicing 5G:

trafficDescriptor: Specifica il descrittore del traffico inviato al modem
sliceInfo: specifica le informazioni per la sezione di rete da utilizzare in caso di handover da EPDG a 5G
matchAllRuleAllowed: specifica se è consentito utilizzare una regola URSP predefinita di corrispondenza totale. Telefonia imposta questo valore su true per le reti predefinite, ma non per gli slice. La regola di corrispondenza di tutti viene applicata alle reti predefinite. Quando un'app richiede una sezione specifica non disponibile, questa viene segnalata come non disponibile. Per le app aziendali, il framework Telephony può eseguire il failover sulla rete predefinita se la rete aziendale non è disponibile.

I modem devono anche implementare l'API getSlicingConfig a meno che non sia segnalata come non supportata dall'API getHalDeviceCapabilities.

Requisiti aziendali

Di seguito sono descritti i requisiti per le aziende per utilizzare lo slicing di rete 5G sui dispositivi in un deployment Android Enterprise.

Assicurati che i dispositivi completamente gestiti o dei dipendenti configurati con un profilo di lavoro siano compatibili con il 5G SA con modem che supportano l'API setupDataCall_1_6.
Collabora con il partner operatore per la configurazione e le prestazioni dello slice o le caratteristiche dello SLA.

Attivare lo slicing 5G sui dispositivi configurati con un profilo di lavoro

Per i dispositivi configurati con profili di lavoro, lo slicing di rete 5G è disattivato per impostazione predefinita in AOSP. Per attivare lo slicing di rete, gli amministratori IT aziendali possono attivare o disattivare il routing del traffico delle app del profilo di lavoro alla sezione di rete aziendale in base ai singoli dipendenti tramite il DPC EMM, che utilizza il metodo setPreferentialNetworkServiceEnabled nell'API DevicePolicyManager (DPM) (introdotta in Android 12).

I fornitori EMM con DPC personalizzati devono integrare l'API DevicePolicyManager per supportare i clienti aziendali.

Regole URSP

Questa sezione include informazioni per gli operatori sulla configurazione delle regole URSP per diverse categorie di slice, tra cui traffico aziendale, CBS, a bassa latenza, a larghezza di banda elevata e di comunicazioni unificate.

Quando configurano le regole URSP, gli operatori possono utilizzare descrittori del traffico basati su questi fattori:

Tipo di ID sistema operativo e ID app sistema operativo, tipo di componente 0x08, supportato in Android 12 e versioni successive
Tipo di funzionalità di connessione, tipo di componente 0x90, supportato in Android 17 e versioni successive

ID sistema operativo e ID app sistema operativo

Quando configurano le regole URSP utilizzando il componente descrittore del traffico di tipo ID sistema operativo e ID app sistema operativo, gli operatori possono utilizzare i seguenti valori di ID sistema operativo e ID app sistema operativo specifici per Android.

ID	Valore	Descrizione
ID sistema operativo	`97a498e3-fc92-5c94-8986-0333d06e4e47`	L'ID sistema operativo per Android è un UUID versione 5 generato con lo spazio dei nomi ISO OID e il nome Android.

Gli operatori che configurano le regole URSP utilizzando il tipo ID sistema operativo e ID app sistema operativo devono configurare il traffico di ogni slice con il componente descrittore del traffico come concatenazione dell'ID sistema operativo, della lunghezza dell'ID app sistema operativo (0x0A) e dell'ID app sistema operativo. Ad esempio, la sezione ENTERPRISE deve avere un valore di 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345. Per saperne di più sul tipo di componente del descrittore del traffico, consulta 3GPP TS 24.526 Table 5.2.1.

La tabella seguente descrive i valori OSAppId per le diverse categorie di slice.

Categoria della sezione	OSAppId	Descrizione
`ENTERPRISE`	`0x454E5445525052495345`	OSAppId è una rappresentazione di array di byte della stringa `ENTERPRISE`
`ENTERPRISE2`	`0x454E544552505249534532`	OSAppId è una rappresentazione di array di byte della stringa `ENTERPRISE2`
`ENTERPRISE3`	`0x454E544552505249534533`	OSAppId è una rappresentazione di array di byte della stringa `ENTERPRISE3`
`ENTERPRISE4`	`0x454E544552505249534534`	OSAppId è una rappresentazione di array di byte della stringa `ENTERPRISE4`
`ENTERPRISE5`	`0x454E544552505249534535`	OSAppId è una rappresentazione di array di byte della stringa `ENTERPRISE5`
`CBS`	`0x434253`	OSAppId è una rappresentazione di array di byte della stringa `CBS`
`PRIORITIZE_LATENCY`	`0x5052494f524954495a455f4c4154454e4359`	OSAppId è una rappresentazione di array di byte della stringa `PRIORITIZE_LATENCY`
`PRIORITIZE_BANDWIDTH`	`0x5052494f524954495a455f42414e445749445448`	OSAppId è una rappresentazione di array di byte della stringa `PRIORITIZE_BANDWIDTH`
`PRIORITIZE_UNIFIED_COMMUNICATIONS`	`0x5052494f524954495a455f554e49464945445f434f4d4d554e49434154494f4e53`	OSAppId è una rappresentazione di array di byte della stringa `PRIORITIZE_UNIFIED_COMMUNICATIONS`

Non abbiamo in programma di introdurre nuovi valori di OSAppId. Miglioreremo il descrittore del traffico delle funzionalità di connessione in base alle esigenze.

Funzionalità di connessione

A partire da Android 17 e versioni successive (Radio HAL AIDL 2.5 e versioni successive), Android supporta il componente descrittore del traffico delle funzionalità di connessione (tipo 0x90), definito nella tabella 5.2.1 di 3GPP TS 24.526.

Quando un'app o un servizio di sistema richiede una rete con una funzionalità specifica, lo stack di dati di telefonia Android mappa la NetworkCapabilities richiesta a un valore di funzionalità di connessione standard inserito in TrafficDescriptor inviato al modem durante la configurazione della chiamata dati (setupDataCall). Sebbene la specifica 3GPP consenta più funzionalità di connessione in un unico descrittore, il framework di telefonia Android 17 mappa le più funzionalità di connessione richieste a una singola funzionalità di connessione.

La tabella seguente descrive il mapping predefinito dalle funzionalità di rete Android alle funzionalità di connessione 3GPP:

Capacità di rete	Funzionalità di connessione	Valore (esadecimale o decimale)	Descrizione
`NET_CAPABILITY_IMS`	`CONNECTION_CAPABILITY_IMS`	`0x01` (1)	Comunicazioni vocali e video IMS
`NET_CAPABILITY_MMS`	`CONNECTION_CAPABILITY_MMS`	`0x02` (2)	Traffico MMS
`NET_CAPABILITY_SUPL`	`CONNECTION_CAPABILITY_SUPL`	`0x04` (4)	Secure User Plane Location (SUPL)
`NET_CAPABILITY_INTERNET`	`CONNECTION_CAPABILITY_INTERNET`	`0x08` (8)	Traffico di dati internet predefinito
`NET_CAPABILITY_PRIORITIZE_LATENCY`	`CONNECTION_CAPABILITY_REAL_TIME_INTERACTIVE`	`0xA6` (166)	Traffico interattivo in tempo reale (ad esempio giochi, AR/VR)
`NET_CAPABILITY_PRIORITIZE_BANDWIDTH`	`CONNECTION_CAPABILITY_DOWNLINK_STREAMING`	`0xA3` (163)	Traffico di streaming a larghezza di banda elevata in downlink
`NET_CAPABILITY_PRIORITIZE_UNIFIED_COMMUNICATIONS`	`CONNECTION_CAPABILITY_UNIFIED_COMMUNICATIONS`	`0xA7` (167)	Comunicazioni unificate (ad esempio, chiamate vocali o videochiamate OTT)

Configurazione URSP dell'operatore e compatibilità con le versioni precedenti

Per garantire un funzionamento ottimale su dispositivi con versioni diverse di HAL e sistema operativo, gli operatori devono tenere conto del seguente comportamento durante il provisioning delle regole URSP:

Dispositivi con Android 16 o versioni precedenti (Radio HAL AIDL 2.4 e versioni precedenti): il modem riceve almeno OSAppId nel descrittore del traffico.
Dispositivi con Android 17 o versioni successive (AIDL 2.5 e versioni successive): per le funzionalità di slice premium (come bassa latenza, larghezza di banda elevata e comunicazioni unificate), la piattaforma compila OSAppId, ConnectionCapability o entrambi nel descrittore del traffico.

Gli operatori possono configurare le regole URSP utilizzando uno dei seguenti approcci:

Regole basate sulla precedenza (consigliate):
- Regola A (precedenza più alta, numero di precedenza più basso, ad esempio, 10): corrispondenza in base alle funzionalità di connessione (ad esempio, 0xA6 per bassa latenza, 0xA3 per larghezza di banda elevata o 0xA7 per comunicazioni unificate). I dispositivi Android 17 e versioni successive corrispondono prima a questa regola.
- Regola B (precedenza inferiore, numero di precedenza superiore, ad esempio 20): corrispondenza con il tipo di ID sistema operativo e ID app sistema operativo (ad esempio, PRIORITIZE_LATENCY). I dispositivi meno recenti che non supportano la funzionalità di connessione nell'HAL corrispondono a questa regola di fallback.
Regola solo ID app del sistema operativo (legacy):
- Gli operatori possono continuare a utilizzare le regole URSP esistenti in base al tipo di ID sistema operativo e ID app sistema operativo. Poiché i dispositivi con Android 17 e versioni successive continuano a superare il OSAppId, sia i dispositivi nuovi che quelli meno recenti corrispondono correttamente a queste regole.
Regola combinata (condizione AND):
- Gli operatori possono specificare sia l'ID sistema operativo sia l'ID app del sistema operativo e le funzionalità di connessione all'interno di un unico descrittore del traffico. Questa regola corrisponde solo ai dispositivi con Android 17 o versioni successive con AIDL 2.5 e versioni successive.

Esempi di regole URSP

Le seguenti tabelle mostrano regole URSP di esempio per traffico aziendale, CBS, a bassa latenza, a larghezza di banda elevata, di comunicazione unificata e predefinito.

Enterprise 1

Il supporto di Enterprise 1 è disponibile in Android 12 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico ENTERPRISE1:

Regola 1 dell'URSP (ENTERPRISE1)
Precedenza	`1 (0x01)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	azienda
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	azienda

Enterprise 2

Il supporto di Enterprise 2 è disponibile in Android 13 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico ENTERPRISE2:

Regola 2 URSP (ENTERPRISE2)
Precedenza	`2 (0x02)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	enterprise2
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	enterprise2

Enterprise 3

Il supporto di Enterprise 3 è disponibile in Android 13 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico ENTERPRISE3:

Regola URSP 3 (ENTERPRISE3)
Precedenza	`3 (0x03)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	enterprise3
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	enterprise3

Enterprise 4

Il supporto di Enterprise 4 è disponibile in Android 13 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico ENTERPRISE4:

Regola 4 dell'URSP (ENTERPRISE4)
Precedenza	`4 (0x04)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	enterprise4
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	enterprise4

Enterprise 5

Il supporto di Enterprise 5 è disponibile in Android 13 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico ENTERPRISE5:

Regola 5 dell'URSP (ENTERPRISE5)
Precedenza	`5 (0x05)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	enterprise5
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	enterprise5

CBS

Il supporto di CBS è disponibile in Android 13 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico CBS:

Regola 6 dell'URSP (CBS)
Precedenza	`6 (0x06)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E4703434253
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	cbs
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	cbs

Bassa latenza con funzionalità di connessione

Il supporto delle funzionalità di connessione nelle regole URSP è disponibile in Android 17 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico a bassa latenza che utilizza il descrittore delle funzionalità di connessione:

Regola URSP 7 (bassa latenza con capacità di connessione)
Precedenza	`7 (0x07)`
Descrittore del traffico n. 1
Tipo di funzionalità di connessione	0xA6 (166: Interattivo in tempo reale)
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	latenza
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	latenza

Bassa latenza con OSAppId

Il supporto della bassa latenza è disponibile in Android 13 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico LOW_LATENCY che utilizza OSAppId:

Regola 8 di URSP (bassa latenza con fallback OSAppId)
Precedenza	`8 (0x08)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	latenza
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	latenza

Larghezza di banda elevata con capacità di connessione

Il supporto delle funzionalità di connessione nelle regole URSP è disponibile in Android 17 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico a larghezza di banda elevata che utilizza il descrittore delle funzionalità di connessione:

Regola 9 dell'URSP (larghezza di banda elevata con capacità di connessione)
Precedenza	`9 (0x09)`
Descrittore del traffico n. 1
Tipo di funzionalità di connessione	0xA3 (163: Streaming in downlink)
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	larghezza di banda
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	larghezza di banda

Larghezza di banda elevata con OSAppId

Il supporto della larghezza di banda elevata è disponibile in Android 13 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico HIGH_BANDWIDTH che utilizza OSAppId:

Regola URSP 10 (larghezza di banda elevata con fallback OSAppId)
Precedenza	`10 (0x0A)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY
Componente n. 2: DNN	larghezza di banda
Descrittore di selezione del percorso n. 2
Precedenza	`2 (0x02)`
Componente 1: DNN	larghezza di banda

Comunicazioni unificate con funzionalità di connessione

Il supporto per le comunicazioni unificate è disponibile in Android 17 e versioni successive. Di seguito è riportato un esempio di regola URSP per il traffico UNIFIED_COMMUNICATIONS che utilizza la funzionalità di connessione. Poiché il traffico di comunicazioni unificate viene instradato tramite la connessione dati internet predefinita, non è necessario un APN (DNN) dedicato nel descrittore di selezione della route:

Regola URSP 11 (comunicazioni unificate con funzionalità di connessione)
Precedenza	`11 (0x0B)`
Descrittore del traffico n. 1
Tipo di funzionalità di connessione	0xA7 (167: Unified Communications)
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY

Unified Communications con OSAppId

Regola URSP 12 (comunicazioni unificate con fallback OSAppId)
Precedenza	`12 (0x0C)`
Descrittore del traffico n. 1
Tipo di ID sistema operativo + ID app sistema operativo	0x97A498E3FC925C9489860333D06E4E47215052494F524954495A455F554E49464945445F434F4D4D554E49434154494F4E53
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY

Predefinito

Regola URSP 13 (predefinita)
Precedenza	`13 (0x0D)`
Descrittore del traffico n. 1
match-all	N/D
Descrittore di selezione del percorso n. 1
Precedenza	`1 (0x01)`
Componente 1: S-NSSAI	SST:XX SD:YYYYYY

Test

Per testare lo slicing della rete 5G, utilizza il seguente test manuale.

Per configurare un dispositivo per il test:

Assicurati che il criterio URSP sia configurato con una regola non predefinita che corrisponda alla categoria aziendale e che il descrittore di selezione del percorso corrispondente mappi la categoria aziendale alla slice aziendale; e una regola predefinita che indirizzi il traffico alla slice internet predefinita.
Assicurati che sul dispositivo sia configurato un profilo di lavoro.
Attivare l'utilizzo dello slicing di rete tramite il DPC

Per testare il comportamento dello slicing di rete 5G:

Verifica che sia stabilita una sessione PDU con lo slice aziendale (ad esempio utilizzando un indirizzo IP specifico) e che le app nel profilo di lavoro utilizzino questa sessione PDU.
Verifica che sia stabilita una sessione PDU separata con lo slice internet predefinito e che le app nel profilo personale utilizzino la sessione PDU.

Upsell dello slicing 5G

La funzionalità di upsell dello slicing 5G, disponibile a partire da Android 14 QPR1, consente agli operatori di offrire funzionalità di rete migliorate (latenza e larghezza di banda) ai propri utenti tramite lo slicing della rete 5G.

La funzionalità di upsell dello slicing 5G utilizza la risposta TS.43 del server di autorizzazione dell'operatore per guidare il flusso di acquisto. Gli operatori possono utilizzare la risposta per specificare l'URL della webview di acquisto dell'operatore, inviare dati aggiuntivi alla webview e indicare se lo slice è sottoposto a provisioning e disponibile sulla rete dell'operatore.

Gli operatori possono personalizzare il comportamento della funzionalità di upsell dello slicing 5G utilizzando le configurazioni dell'operatore, che controllano se è possibile effettuare richieste di acquisto, quando le app possono richiedere funzionalità premium e per quanto tempo il framework di telefonia attende le risposte dell'utente o della rete.

La funzionalità di upsell dello slicing 5G fornisce un'interfaccia, chiamata DataBoostWebServiceFlow, per consentire la comunicazione tra Android e la webview dell'operatore.

La figura 2 mostra il flusso di acquisto dell'upsell dello slicing 5G:

Flusso di acquisto dell'upsell dello slicing 5G

Figura 2. Flusso di acquisto dell'upsell dello slicing 5G.

TS.43 entitlement process

Quando un utente richiede funzionalità di rete avanzate, il framework Telephony richiede la configurazione dei diritti di servizio per la funzionalità premium richiesta. Se la risposta TS.43 è valida, il framework Telephony utilizza i campi della risposta HTTP per gestire la richiesta di acquisto.

Sezionare i campi di acquisto

La configurazione dei diritti TS.43 include i seguenti campi di acquisto delle slice:

Stato diritto: Chiave: EntitlementStatus; Tipo: int; Valori supportati: 0 (disattivato), 1 (attivato), 2 (incompatibile), 3 (provisioning), 4 (incluso)
Stato del provisioning: Chiave: ProvStatus; Tipo: int; Valori supportati: 0 (non eseguito il provisioning), 1 (provisioning eseguito), 2 (non disponibile), 3 (in corso)

Il framework Telephony utilizza la combinazione dello stato dei diritti e dello stato di provisioning per determinare lo stato attuale dell'acquisto dello slice. Il risultato può essere uno dei seguenti:

Se lo stato del diritto è 1 (attivato) e lo stato del provisioning è 0 (non eseguito), il framework di telefonia mostra una notifica di upsell all'utente per l'acquisto del boost tramite la webview dell'operatore. La tabella seguente descrive il comportamento del framework Telephony per diverse combinazioni di valori di stato di provisioning e diritti.

		Stato del provisioning
		Non eseguito il provisioning (`0`)	Provisioned (`1`)	Non disponibile (`2`)	In corso (`3`)
Stato del diritto	Disattivato (`0`)	Non riuscito	Non riuscito	Non riuscito	Non riuscito
	Attivato (`1`)	Mostra WebView	Già acquistato	Già acquistato	In corso
	Incompatibile (`2`)	Non riuscito	Non riuscito	Non riuscito	Non riuscito
	Provisioning (`3`)	Errore dell'operatore	Errore dell'operatore	In corso	In corso
	Incluso (`4`)	Errore dell'operatore	Già acquistato	Già acquistato	Errore dell'operatore

Campi del flusso di servizio

La risposta TS.43 specifica l'URL, i dati utente e il tipo di contenuti da personalizzare il comportamento della webview di acquisto dell'operatore. Se il tipo di contenuti non è specificato, l'URL viene caricato come richiesta GET. Se i dati utente esistono, vengono aggiunti all'URL come parametro di ricerca (ad esempio, https://www.android.com?encodedValue=Base64EncodedUserData); se non esistono, l'URL viene utilizzato così com'è (ad esempio, https://www.android.com).
Se il tipo di contenuti è specificato in formato JSON o XML, l'URL viene caricato come richiesta POST e i dati utente (decodificati se sono codificati in Base 64) vengono inviati come dati per la richiesta POST.

URL: Chiave: ServiceFlow_URL; Tipo: String; Esempio: "https://www.android.com"
Dati utente: Chiave: ServiceFlow_UserData; Tipo: String; Esempio: "encodedValue=Base64EncodedUserData"
Tipo di contenuti: Chiave: ServiceFlow_ContentsType; Tipo: String; Valori supportati: 0 (non specificato), 1 (JSON), 2 (XML)

Configurazioni operatore

Di seguito sono riportate le configurazioni dell'operatore disponibili per personalizzare il comportamento della funzionalità di upsell dello slicing 5G.

KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY: Un elenco delle funzionalità premium supportate. Questo è un array di numeri interi di TelephonyManager.PremiumCapability. Queste funzionalità premium condividono lo stesso valore della classe NetworkCapabilities.NetCapability corrispondente. Se viene richiesta una funzionalità premium e non è inclusa in questa configurazione, la richiesta di acquisto non va a buon fine e viene restituito il risultato CARRIER_DISABLED.; In Android 14 è supportato solo PREMIUM_CAPABILITY_PRIORITIZE_LATENCY.
KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT: Il numero massimo giornaliero di volte in cui la notifica di upsell dell'acquisto viene mostrata all'utente. Se viene raggiunto il limite massimo giornaliero, la notifica di upsell non viene mostrata e le richieste di acquisto (incluse le richieste del server dei diritti) vengono limitate fino a mezzanotte del giorno successivo. Le richieste di acquisto effettuate dopo il raggiungimento del massimo giornaliero non vanno a buon fine e restituiscono il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT: Il numero massimo mensile di volte in cui la notifica di upsell dell'acquisto viene mostrata all'utente. Se viene raggiunto il limite mensile, la notifica di upselling non viene mostrata e le richieste di acquisto (incluse le richieste del server dei diritti) vengono limitate fino al primo giorno del mese successivo. Le richieste di acquisto effettuate dopo il raggiungimento del limite massimo mensile non vanno a buon fine e restituiscono il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING: L'URL di acquisto dell'operatore di backup da mostrare all'utente quando fa clic sulla notifica di upselling. Se l'URL di acquisto non viene trovato nella risposta TS.43 del server dei diritti, viene utilizzato questo valore. Se né l'URL della risposta TS.43 né la configurazione dell'operatore sono validi, la richiesta di acquisto non va a buon fine e viene restituito il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.
KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL: Se consentire l'acquisto di funzionalità premium quando il dispositivo è connesso a Long-Term Evolution (LTE). Se true, le richieste di acquisto possono essere effettuate sia su LTE sia su New Radio (NR). Se false, le richieste di acquisto possono essere effettuate solo su NR e le richieste effettuate su LTE non vanno a buon fine con il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG: Il periodo di tempo durante il quale mostrare all'utente la notifica di upsell dell'acquisto prima che venga annullata automaticamente. Quando la notifica viene annullata, le richieste successive vengono limitate e non vanno a buon fine con il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG: Il periodo di tempo durante il quale le successive richieste di acquisto devono essere limitate dopo un errore dovuto a timeout o annullamento da parte dell'utente. Se l'utente non fa clic sulla notifica di upsell dell'acquisto entro il timeout specificato da KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG o se annulla o chiude la notifica, viene avviato questo timer di backoff. Mentre questo timer è attivo, le richieste di acquisto non vanno a buon fine con il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG: Il periodo di tempo durante il quale le successive richieste di acquisto devono essere limitate dopo un errore dovuto all'operatore o alla rete. Se il controllo dei diritti non riesce, l'URL non è disponibile o l'URL di acquisto dell'operatore indica un errore, viene avviato questo timer di backoff. Mentre questo timer è attivo, le richieste di acquisto non vanno a buon fine con il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.
KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG: Il periodo di tempo entro il quale l'emittente deve configurare una segmentazione per la funzionalità premium di acquisto. Durante questo periodo, le successive richieste di acquisto vengono bloccate e restituiscono il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Se la rete non riesce a configurare una configurazione di slicing in tempo, le app possono richiedere nuovamente l'acquisto di funzionalità premium. La telefonia non considera un acquisto completato finché non viene inviata la configurazione di slicing corrispondente, indipendentemente dal fatto che l'utente abbia pagato o meno l'operatore.

Interfaccia JavaScript

Quando l'utente fa clic sulla notifica di potenziamento della rete, viene visualizzato un oggetto WebView con l'URL di acquisto dell'operatore. Gli operatori possono utilizzare le API fornite nell'interfaccia JavaScript DataBoostWebServiceFlow nel loro sito web di acquisto per comunicare con l'app di acquisto della slice.

Il sito web dell'operatore può ottenere la funzionalità premium richiesta tramite il metodo getRequestedCapability().

Se l'acquisto va a buon fine, il sito web dell'operatore deve notificare l'app di acquisto della slice tramite notifyPurchaseSuccessful() o notifyPurchaseSuccessful(duration), dove duration è un parametro facoltativo che indica la durata prevista della slice.

Se l'acquisto non va a buon fine, il sito web dell'operatore deve comunicarlo all'app di acquisto della fetta tramite il metodo notifyPurchaseFailed(code, reason), dove code è il codice di errore che indica il motivo dell'errore e reason è il motivo dell'errore leggibile se il codice di errore è sconosciuto.

Se uno di questi metodi di risposta non viene chiamato, l'acquisto non verrà considerato completato e la richiesta di acquisto scadrà.

Di seguito sono riportati i codici di errore validi che il sito web dell'operatore può restituire in caso di errore di acquisto:

Una volta completato l'acquisto, l'operatore deve aggiornare le regole URSP con lo slice PRIORITIZE_LATENCY sul dispositivo dell'utente.

Routing automatico dello slicing 5G per voce e video OTT

Android 17 supporta il routing automatico delle chiamate vocali e video over-the-top (OTT) verso connessioni di rete premium. Questa funzionalità consente al sistema di indirizzare automaticamente il traffico delle chiamate vocali e video a un'interfaccia di rete premium dedicata (ad esempio una sezione premium 5G o una connessione PDN premium 4G) senza richiedere modifiche allo stack di rete dell'app.

Questa soluzione a livello di piattaforma elimina la necessità per gli sviluppatori di app di richiedere esplicitamente le funzionalità di rete, offrendo un'esperienza senza interruzioni sia per gli sviluppatori che per gli utenti finali.

Come funziona

Android incorpora il supporto per il routing automatico tramite aggiunte ai framework di connettività e telecomunicazioni. La funzionalità di routing automatico funziona nel seguente modo:

Rilevamento delle chiamate:il sistema sfrutta le API Telecom Jetpack esistenti utilizzate dalle app OTT per rilevare l'inizio e la fine delle chiamate vocali o video.
Gestione della connessione:al rilevamento della chiamata, Android visualizza un'interfaccia di rete premium designata, ad esempio una sezione di comunicazione unificata.
Gestione del traffico:durante la chiamata, la piattaforma identifica l'applicazione in base al suo UID e indirizza automaticamente il traffico alla connessione di rete premium.
Fallback post-chiamata:al termine della chiamata, la piattaforma rimuove la regola di routing e il traffico dell'app torna alla rete predefinita del sistema per il traffico non di chiamata (ad esempio la messaggistica).

Requisiti

Per supportare il routing automatico per le chiamate OTT, devono essere soddisfatti i seguenti requisiti:

Operatori:devono offrire una sezione di comunicazione unificata configurando regole URSP appropriate (utilizzando la funzionalità di connessione o OSAppId per il traffico di comunicazione unificata).
App:devono utilizzare le API Android Telecom Jetpack per consentire al sistema di rilevare gli stati delle chiamate.
Produttori di dispositivi:è necessario Android 17 o versioni successive.