Slicing della rete 5G

Per i dispositivi con Android 12 o versioni successive, Android fornisce il supporto per il network slicing 5G, l'uso della virtualizzazione della rete per dividere singole connessioni di rete in più connessioni virtuali distinte che forniscono diverse quantità di risorse a diversi tipi di traffico. Lo slicing della rete 5G consente agli operatori di rete di dedicare una porzione della rete alla fornitura di 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:

Slicing dei dispositivi aziendali per dispositivi completamente gestiti

Per le aziende che forniscono ai propri dipendenti dispositivi aziendali completamente gestiti , i provider di rete possono fornire loro una o più sezioni di rete aziendale attive verso cui viene instradato il traffico sui dispositivi aziendali. A partire da Android 12, Android consente agli operatori di fornire sezioni aziendali tramite regole URSP, invece di impostare sezioni tramite APN.

Slicing delle app aziendali aziendali per dispositivi con profili di lavoro

Per le aziende che utilizzano la soluzione del profilo di lavoro , Android 12 consente ai dispositivi di instradare il traffico da tutte le app nel profilo di lavoro a una sezione della rete aziendale. Le aziende possono abilitare questa funzionalità tramite un Device Policy Controller (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 instradato alla sezione di rete aziendale. Non è necessario modificare le app nel profilo di lavoro per richiedere esplicitamente la sezione di rete aziendale.

Come funziona lo slicing della rete 5G in AOSP

Android 12 introduce il supporto per lo slicing della rete 5G attraverso aggiunte al codice di telefonia in AOSP e al modulo Tethering per incorporare le API di connettività esistenti necessarie per lo slicing della rete.

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

Componenti di slicing della 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 sezioni in descrittori di traffico che vengono poi passati al modem per la corrispondenza del traffico URSP e la selezione del percorso
  • Ritorno alla rete predefinita se la sezione della rete aziendale non è disponibile
  • Instradare il traffico da tutte le app nel profilo di lavoro alla connessione corrispondente
  • Supporto dello slicing aziendale

    • Rilevamento della presenza di un profilo di lavoro sul dispositivo
    • Verifica delle autorizzazioni o delle indicazioni di instradamento 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 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 fuori dal modulo Tethering

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

  • Ricezione di richieste da app per connessioni di rete
  • Ricevere richieste dal sistema (ad esempio, "posiziona queste app su una sezione aziendale"; introdotto in Android 12)
  • Invio di richieste dal sistema al codice di telefonia che tenta di impostare reti o slice passando attraverso l'HAL API e il modem
  • Informare netd su come instradare il traffico in base all'app (introdotto in Android 12)
  • Informare le app su cosa sta accadendo al loro traffico di rete tramite API ConnectivityManager come NetworkCallback , getActiveNetwork , getNetworkCapabilities .

Implementazione

Per supportare lo slicing 5G su un dispositivo, il dispositivo deve disporre di un modem che supporti l'HAL IRadio 1.6 che dispone dell'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 passaggio da EPDG a 5G
  • matchAllRuleAllowed : specifica se è consentito l'utilizzo di una regola URSP match-all predefinita. La telefonia lo imposta su True per le reti predefinite ma non per le porzioni. La regola "match all" viene applicata alle reti predefinite. Quando un'applicazione richiede una sezione specifica che non è disponibile, la sezione specifica viene segnalata come non disponibile. Per le app aziendali, il framework di telefonia può ricorrere alla rete predefinita se la rete aziendale non è disponibile.

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

Requisiti aziendali

Di seguito vengono descritti i requisiti per le aziende per utilizzare lo slicing di rete 5G sui dispositivi in ​​una distribuzione aziendale Android.

  • Assicurati che i dispositivi completamente gestiti o dei dipendenti configurati con un profilo di lavoro siano compatibili con 5G SA con modem che supportano l'API setupDataCall_1_6 .
  • Collabora con il partner dell'operatore sulla configurazione delle sezioni e sulle prestazioni o sulle caratteristiche dello SLA.

Abilitazione dell'affettatura 5G sui dispositivi configurati con un profilo di lavoro

Per i dispositivi configurati con profili di lavoro, lo slicing della rete 5G è disattivato per impostazione predefinita in AOSP. Per abilitare il sezionamento di rete, gli amministratori IT aziendali possono attivare o disattivare l'instradamento del traffico delle app del profilo di lavoro alla sezione di rete aziendale in base al dipendente tramite EMM DPC, 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.

Regolamento URSP

Questa sezione include informazioni per gli operatori sulla configurazione delle regole URSP per diverse categorie di porzioni, tra cui traffico aziendale, CBS, bassa latenza e larghezza di banda elevata. Quando si configurano le regole URSP per diverse categorie di sezioni, gli operatori devono utilizzare i seguenti valori specifici di Android.

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

Gli operatori devono configurare le regole URSP per ogni sezione di traffico con il componente descrittore del traffico come "ID sistema operativo + tipo ID app sistema operativo". Ad esempio, la sezione "ENTERPRISE" deve avere un valore pari a 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 . Questo valore è una concatenazione di OSId, della lunghezza di OSAppId ( 0x0A ) e di OSAppId. Per ulteriori informazioni sul tipo di componente descrittore di traffico, vedere 3GPP TS 24.526 Tabella 5.2.1 .

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

Categoria fetta OSAppId Descrizione
IMPRESA 0x454E5445525052495345 OSAppId è una rappresentazione di array di byte della stringa "ENTERPRISE"
IMPRESA2 0x454E544552505249534532 OSAppId è una rappresentazione di array di byte della stringa "ENTERPRISE2"
IMPRESA3 0x454E544552505249534533 OSAppId è una rappresentazione di array di byte della stringa "ENTERPRISE3"
IMPRESA4 0x454E544552505249534534 OSAppId è una rappresentazione di array di byte della stringa "ENTERPRISE4"
IMPRESA5 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"

Esempio di regole URSP

Le tabelle seguenti mostrano esempi di regole URSP per Enterprise, CBS, bassa latenza, larghezza di banda elevata e traffico predefinito.

Impresa 1

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

Regola URSP n. 1 (impresa1)
Precedenza 1 (0x01)
Descrittore del traffico n. 1
ID sistema operativo + tipo ID app sistema operativo 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Descrittore di selezione del percorso n. 1
Precedenza 1 (0x01)
Componente n. 1: S-NSSAI SST:XX SD:AAAAAA
Componente n. 2: DNN impresa
Descrittore di selezione del percorso n. 2
Precedenza 2 (0x02)
Componente n. 1: DNN impresa

Impresa 2

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

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

Impresa 3

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

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

Impresa 4

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

Regola URSP n.4 (impresa4)
Precedenza 4 (0x04)
Descrittore del traffico n. 1
ID sistema operativo + tipo ID app sistema operativo 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
Descrittore di selezione del percorso n. 1
Precedenza 1 (0x01)
Componente n. 1: S-NSSAI SST:XX SD:AAAAAA
Componente n. 2: DNN impresa4
Descrittore di selezione del percorso n. 2
Precedenza 2 (0x02)
Componente n. 1: DNN impresa4

Impresa 5

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

Regola URSP n.5 (impresa5)
Precedenza 5 (0x05)
Descrittore del traffico n. 1
ID sistema operativo + tipo ID app sistema operativo 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
Descrittore di selezione del percorso n. 1
Precedenza 1 (0x01)
Componente n. 1: S-NSSAI SST:XX SD:AAAAAA
Componente n. 2: DNN impresa5
Descrittore di selezione del percorso n. 2
Precedenza 2 (0x02)
Componente n. 1: DNN impresa5

CBS

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

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

Bassa latenza

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

Regola URSP n.7 (bassa latenza)
Precedenza 7 (0x07)
Descrittore del traffico n. 1
ID sistema operativo + tipo ID app sistema operativo 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
Descrittore di selezione del percorso n. 1
Precedenza 1 (0x01)
Componente n. 1: S-NSSAI SST:XX SD:AAAAAA
Componente n. 2: DNN latenza
Descrittore di selezione del percorso n. 2
Precedenza 2 (0x02)
Componente n. 1: DNN latenza

Elevata larghezza di banda

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

Regola URSP n.8 (larghezza di banda elevata)
Precedenza 8 (0x08)
Descrittore del traffico n. 1
ID sistema operativo + tipo ID app sistema operativo 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
Descrittore di selezione del percorso n. 1
Precedenza 1 (0x01)
Componente n. 1: S-NSSAI SST:XX SD:AAAAAA
Componente n. 2: DNN larghezza di banda
Descrittore di selezione del percorso n. 2
Precedenza 2 (0x02)
Componente n. 1: DNN larghezza di banda

Predefinito

Regola URSP n.9 (predefinita)
Precedenza 9 (0x09)
Descrittore del traffico n. 1
tutto sommato N / A
Descrittore di selezione del percorso n. 1
Precedenza 1 (0x01)
Componente n. 1: S-NSSAI SST:XX SD:AAAAAA

Test

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

Per configurare un dispositivo per il test, procedere come segue:

  1. Assicurarsi che la policy URSP sia configurata con una regola non predefinita che corrisponda alla categoria aziendale e che il descrittore di selezione del percorso corrispondente associ la categoria aziendale alla sezione aziendale; e una regola predefinita che indirizza il traffico alla sezione Internet predefinita.

  2. Assicurati che sul dispositivo sia configurato un profilo di lavoro.

  3. Attivare l'utilizzo del network slicing tramite il DPC

Per testare il comportamento di slicing della rete 5G, procedi come segue:

  1. Verifica che sia stabilita una sessione PDU con la sezione aziendale (ad esempio, utilizzando un indirizzo IP specifico) e che le app nel profilo di lavoro utilizzino tale sessione PDU.
  2. Verificare che sia stabilita una sessione PDU separata con la sezione Internet predefinita e che le app nel profilo personale utilizzino la sessione PDU.

Upselling dello slicing 5G

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

La funzionalità di upsell dello slicing 5G utilizza la risposta TS.43 dal server di autorizzazione dell'operatore per guidare il flusso di acquisto. Gli operatori possono utilizzare la risposta per specificare l'URL per la visualizzazione Web di acquisto dell'operatore, inviare dati aggiuntivi alla visualizzazione Web e indicare se la sezione è fornita ed è 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 dall'utente o dalla rete.

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

La Figura 2 mostra il flusso di acquisto di upsell dello slicing 5G:

Flusso di acquisto di upsell con slicing 5G

Figura 2. Flusso di acquisto di upsell del 5G slicing.

TS.43 processo di autorizzazione

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

Suddividi i campi di acquisto

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

Stato del diritto

Chiave: EntitlementStatus

Tipo: int

Valori supportati: 0 (disabilitato), 1 (abilitato), 2 (incompatibile), 3 (provisioning), 4 (incluso)

Stato del provisioning

Chiave: ProvStatus

Tipo: int

Valori supportati: 0 (non fornito), 1 (fornito), 2 (non disponibile), 3 (in corso)

Il framework Telefonia utilizza la combinazione dello stato di diritto e dello stato di provisioning per determinare lo stato corrente di acquisto della porzione. Il risultato può essere uno dei seguenti:

Se lo stato del diritto è 1 (abilitato) e lo stato del provisioning è 0 (non fornito), il framework di telefonia visualizza una notifica di upsell all'utente per acquistare il boost tramite la visualizzazione web dell'operatore. La tabella seguente descrive il comportamento del framework di telefonia per diverse combinazioni di valori di provisioning e stato di autorizzazione.

Stato del provisioning
Non fornito ( 0 ) Provvisto ( 1 ) 1 ) Non disponibile ( 2 ) In corso ( 3 )
Stato del diritto Disabilitato ( 0 ) Fallito Fallito Fallito Fallito
Abilitato ( 1 ) Mostra visualizzazione web Già acquistato Già acquistato In corso
Incompatibile ( 2 ) Fallito Fallito Fallito Fallito
Provisioning ( 3 ) Errore del corriere Errore del corriere In corso In corso
Incluso ( 4 ) Errore del corriere Già acquistato Già acquistato Errore del corriere

Campi del flusso di servizio

La risposta TS.43 specifica l'URL, i dati utente e il tipo di contenuto per personalizzare il comportamento di visualizzazione web di acquisto dell'operatore. Se il tipo di contenuto non è specificato, l'URL viene caricato come richiesta GET. Se i dati utente esistono, vengono aggiunti all'URL come parametro di query (ad esempio, https://www.android.com?encodedValue=Base64EncodedUserData ); e se non esiste, l'URL viene utilizzato così com'è (ad esempio, https://www.android.com ).
Se il tipo di contenuto è specificato in formato JSON o XML, l'URL viene caricato come richiesta POST e i dati utente (decodificati se 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 contenuto

Chiave: ServiceFlow_ContentsType

Tipo: String

Valori supportati: 0 (non specificato), 1 (JSON), 2 (XML)

Configurazioni del vettore

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 di funzionalità premium supportate. Si tratta di un array int 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 fallisce con 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 upselling dell'acquisto viene mostrata all'utente. Se viene raggiunto il limite massimo giornaliero, la notifica di upselling non viene visualizzata e le richieste di acquisto (incluse le richieste del server di adesione) vengono limitate fino alla mezzanotte del giorno successivo. Le richieste di acquisto effettuate dopo il raggiungimento del limite massimo giornaliero falliscono con 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 upselling dell'acquisto viene mostrata all'utente. Se viene raggiunto il limite massimo mensile, la notifica di upsell non viene visualizzata e le richieste di acquisto (incluse le richieste del server di adesione) vengono limitate fino al primo giorno del mese successivo. Le richieste di acquisto effettuate dopo il raggiungimento del limite massimo mensile hanno esito negativo con il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED .

KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING

L'URL di acquisto del corriere di riserva da visualizzare all'utente quando fa clic sulla notifica di upsell. Se l'URL di acquisto non viene trovato nella risposta TS.43 dal server di autorizzazione, viene utilizzato questo valore. Se né l'URL della risposta TS.43 né la configurazione del corriere sono validi, la richiesta di acquisto non riesce con 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 che su New Radio (NR). Se false , le richieste di acquisto possono essere effettuate solo su NR e le richieste effettuate su LTE falliscono con il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE .

KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG

Il tempo necessario per mostrare all'utente la notifica di upselling dell'acquisto prima che venga annullata automaticamente. Quando la notifica viene annullata, le richieste successive vengono limitate e falliscono 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 richieste di acquisto successive devono essere limitate dopo un errore dovuto al timeout o all'annullamento 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 ignora la notifica, viene avviato questo timer di backoff. Mentre questo timer è attivo, le richieste di acquisto falliscono 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 richieste di acquisto successive 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 falliscono con il risultato PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED .

KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG

Il periodo di tempo entro il quale la rete deve impostare una configurazione di suddivisione 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 impostare una configurazione di slicing in tempo, le app possono richiedere di acquistare nuovamente funzionalità premium. La telefonia non considera completato un acquisto 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, all'utente viene mostrato 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 di porzioni.

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

Se l'acquisto ha esito positivo, il sito Web dell'operatore deve avvisare l'app di acquisto di sezioni tramite notifyPurchaseSuccessful() o notifyPurchaseSuccessful(duration) dove duration è un parametro facoltativo che indica la durata prevista della sezione.

Se l'acquisto non va a buon fine, il sito web dell'operatore deve avvisare l'app di acquisto di fette tramite il metodo notifyPurchaseFailed(code, reason) , dove code è il codice di errore che indica il motivo dell'errore e reason è il motivo leggibile dall'uomo dell'errore se l'acquisto 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 alla fine scade.

Di seguito sono riportati i codici di errore validi che il sito Web del corriere può restituire in caso di errore di acquisto:

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