Für Geräte mit Android 12 oder höher bietet Android Unterstützung für 5G Network Slicing, den Einsatz von Netzwerkvirtualisierung, um einzelne Netzwerkverbindungen in mehrere unterschiedliche virtuelle Verbindungen aufzuteilen, die unterschiedliche Ressourcenmengen für verschiedene Arten von Datenverkehr bereitstellen. Durch das 5G-Netzwerk-Slicing können Netzwerkbetreiber einen Teil des Netzwerks für die Bereitstellung spezifischer Funktionen für ein bestimmtes Kundensegment reservieren. Android 12 führt die folgenden 5G-Unternehmensnetzwerk-Slicing-Funktionen ein, die Netzwerkbetreiber ihren Unternehmenskunden bereitstellen können:
Enterprise Device Slicing für vollständig verwaltete Geräte
Für Unternehmen, die ihren Mitarbeitern vollständig verwaltete Unternehmensgeräte zur Verfügung stellen, können Netzwerkanbieter ihnen einen oder mehrere aktive Unternehmensnetzwerk-Slices zur Verfügung stellen, zu denen der Datenverkehr auf den Unternehmensgeräten weitergeleitet wird. Ab Android 12 ermöglicht Android Netzbetreibern die Bereitstellung von Unternehmens-Slices über URSP-Regeln, anstatt Slices über APNs einzurichten.
Unternehmens-App-Slicing für Geräte mit Arbeitsprofilen
Für Unternehmen, die die Arbeitsprofillösung verwenden, ermöglicht Android 12 Geräten, den Datenverkehr von allen Apps im Arbeitsprofil an einen Unternehmensnetzwerk-Slice weiterzuleiten. Unternehmen können diese Funktion über einen Device Policy Controller (DPC) aktivieren.
Die Arbeitsprofillösung bietet ein automatisches Maß an Authentifizierung und Zugriffskontrolle, das Unternehmen benötigen, um sicherzustellen, dass nur Datenverkehr von Unternehmensanwendungen im Arbeitsprofil an den Unternehmensnetzwerk-Slice weitergeleitet wird. Apps im Arbeitsprofil müssen nicht geändert werden, um den Unternehmensnetzwerk-Slice explizit anzufordern.
So funktioniert 5G Network Slicing in AOSP
Android 12 führt durch Ergänzungen der Telefonie-Codebasis in AOSP und des Tethering-Moduls Unterstützung für 5G-Netzwerk-Slicing ein, um vorhandene Konnektivitäts-APIs zu integrieren, die für Netzwerk-Slicing erforderlich sind.
Die Android-Telefonieplattform bietet HAL und Telefonie-APIs zur Unterstützung von Slicing basierend auf Netzwerkanforderungen, die vom Kernnetzwerkcode gestellt werden, und 5G-Slicing-Funktionen im Modem. Abbildung 1 beschreibt die Komponenten der 5G-Netzwerk-Slicing-Funktion.
Abbildung 1. 5G-Netzwerk-Slicing-Architektur in AOSP.
Die Telefonie- und Konnektivitätsplattform unterstützt:
- Konvertieren von Netzwerkanforderungen für Slice-Kategorien in Verkehrsdeskriptoren , die dann zur URSP-Verkehrsanpassung und Routenauswahl an das Modem weitergeleitet werden
- Zurückgreifen auf das Standardnetzwerk, wenn der Unternehmensnetzwerk-Slice nicht verfügbar ist
- Leiten Sie den Datenverkehr von allen Apps unter dem Arbeitsprofil an die entsprechende Verbindung weiter
Unterstützung von Unternehmens-Slicing
- Erkennen des Vorhandenseins eines Arbeitsprofils auf dem Gerät
- Überprüfung auf Berechtigungen oder Routing-Anweisungen, die vom DPC bereitgestellt werden, der vom IT-Administrator des Unternehmens verwendet wird
Der Kernnetzwerkdienst umfasst die folgenden Änderungen am Tethering-Modul in Android 12:
- Fügt die meisten öffentlichen oder System-API-Klassen
android.net.*
zum Tethering-Modul hinzu Erweitert die Grenzen des Tethering-Moduls um Folgendes:
-
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
-
Verschiebt VPN-Code aus dem Tethering-Modul
Android 12 verschiebt Code mit den folgenden Funktionen in das Tethering-Modul:
- Empfangen von Anfragen von Apps für Netzwerkverbindungen
- Empfangen von Anfragen vom System (z. B. „Platzieren Sie diese Apps auf einem Enterprise-Slice“; eingeführt in Android 12)
- Senden von Anfragen vom System an den Telefoncode, der versucht, über die HAL-API und das Modem Netzwerke oder Slices einzurichten
- Netd darüber informieren, wie der Datenverkehr pro App weitergeleitet wird (eingeführt in Android 12)
- Informieren Sie Apps über
ConnectivityManager
APIs wieNetworkCallback
,getActiveNetwork
undgetNetworkCapabilities
darüber, was mit ihrem Netzwerkverkehr passiert.
Implementierung
Um 5G-Slicing auf einem Gerät zu unterstützen, muss das Gerät über ein Modem verfügen, das IRadio 1.6 HAL mit der API setupDataCall_1_6
unterstützt. Diese API richtet eine Datenverbindung ein und enthält die folgenden Parameter zur Unterstützung von 5G-Slicing:
-
trafficDescriptor
: Gibt den an das Modem gesendeten Verkehrsdeskriptor an -
sliceInfo
: Gibt Informationen für den Netzwerk-Slice an, der im Falle einer EPDG-zu-5G-Übergabe verwendet werden soll -
matchAllRuleAllowed
: Gibt an, ob die Verwendung einer standardmäßigen Match-All-URSP-Regel zulässig ist. Telefonie setzt dies für Standardnetzwerke auf „true“, nicht jedoch für Slices. Die Match-All-Regel wird auf Standardnetzwerke angewendet. Wenn eine Anwendung ein bestimmtes Slice anfordert, das nicht verfügbar ist, wird das spezifische Slice als nicht verfügbar gemeldet. Bei Unternehmensanwendungen kann das Telefonie-Framework auf das Standardnetzwerk zurückgreifen, wenn das Unternehmensnetzwerk nicht verfügbar ist.
Modems müssen auch die getSlicingConfig
-API implementieren, es sei denn, sie wird von der getHalDeviceCapabilities
-API als nicht unterstützt gemeldet.
Unternehmensanforderungen
Im Folgenden werden die Anforderungen beschrieben, die Unternehmen erfüllen müssen, um 5G-Netzwerk-Slicing auf Geräten in einer Android-Unternehmensbereitstellung zu verwenden.
- Stellen Sie sicher, dass vollständig verwaltete oder Mitarbeitergeräte, die mit einem Arbeitsprofil eingerichtet sind, 5G SA-fähig sind und Modems verwenden, die die
setupDataCall_1_6
-API unterstützen. - Arbeiten Sie mit dem Carrier-Partner an der Slice-Einrichtung und Leistung oder den SLA-Merkmalen.
Aktivieren von 5G-Slicing auf Geräten, die mit einem Arbeitsprofil eingerichtet sind
Bei Geräten, die mit Arbeitsprofilen eingerichtet sind, ist das 5G-Netzwerk-Slicing in AOSP standardmäßig deaktiviert. Um das Netzwerk-Slicing zu aktivieren, können IT-Administratoren von Unternehmen die Weiterleitung des Arbeitsprofil-App-Datenverkehrs zum Unternehmensnetzwerk-Slice für jeden einzelnen Mitarbeiter über den EMM-DPC aktivieren oder deaktivieren, der die setPreferentialNetworkServiceEnabled
-Methode in der DevicePolicyManager
(DPM) -API (eingeführt in Android) verwendet 12).
EMM-Anbieter mit benutzerdefinierten DPCs müssen die DevicePolicyManager
API integrieren, um Unternehmenskunden zu unterstützen.
URSP-Regeln
Dieser Abschnitt enthält Informationen für Netzbetreiber zum Konfigurieren von URSP-Regeln für verschiedene Slice-Kategorien, einschließlich Enterprise-, CBS-, Low-Latency- und High-Bandbreiten-Verkehr. Beim Konfigurieren von URSP-Regeln für verschiedene Slice-Kategorien müssen Netzbetreiber die folgenden Android-spezifischen Werte verwenden.
AUSWEIS | Wert | Beschreibung |
---|---|---|
OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 | Die OSId für Android ist eine UUID der Version 5, die mit dem Namespace ISO OID und dem Namen „Android“ generiert wird. |
Netzbetreiber müssen URSP-Regeln für jeden Slice-Verkehr mit der Verkehrsbeschreibungskomponente „OS-ID + Betriebssystem-App-ID-Typ“ konfigurieren. Beispielsweise muss das Slice „ENTERPRISE“ den Wert 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
haben. Dieser Wert ist eine Verkettung der OSId, der Länge der OSAppId ( 0x0A
) und der OSAppId. Weitere Informationen zum Verkehrsdeskriptor-Komponententyp finden Sie in 3GPP TS 24.526 Tabelle 5.2.1 .
In der folgenden Tabelle werden die OSAppId-Werte für verschiedene Slice-Kategorien beschrieben.
Slice-Kategorie | OSAppId | Beschreibung |
---|---|---|
UNTERNEHMEN | 0x454E5445525052495345 | Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge „ENTERPRISE“. |
UNTERNEHMEN2 | 0x454E544552505249534532 | Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge „ENTERPRISE2“. |
UNTERNEHMEN3 | 0x454E544552505249534533 | Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge „ENTERPRISE3“. |
UNTERNEHMEN4 | 0x454E544552505249534534 | Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge „ENTERPRISE4“. |
UNTERNEHMEN5 | 0x454E544552505249534535 | Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge „ENTERPRISE5“. |
CBS | 0x434253 | Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge „CBS“. |
PRIORITIZE_LATENCY | 0x5052494f524954495a455f4c4154454e4359 | Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge „PRIORITIZE_LATENCY“. |
PRIORITIZE_BANDWIDTH | 0x5052494f524954495a455f42414e445749445448 | Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge „PRIORITIZE_BANDWIDTH“. |
Beispiel-URSP-Regeln
Die folgenden Tabellen zeigen beispielhafte URSP-Regeln für Unternehmen, CBS, niedrige Latenz, hohe Bandbreite und Standardverkehr.
Unternehmen 1
Unterstützung für Enterprise 1 ist in Android 12 und höher verfügbar. Im Folgenden finden Sie ein Beispiel für eine URSP-Regel für ENTERPRISE1-Datenverkehr:
URSP-Regel Nr. 1 (Unternehmen1) | |
---|---|
Vorrang | 1 (0x01) |
Verkehrsbeschreibung Nr. 1 | |
Betriebssystem-ID + Betriebssystem-App-ID-Typ | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Komponente Nr. 2: DNN | Unternehmen |
Routenauswahldeskriptor Nr. 2 | |
Vorrang | 2 (0x02) |
Komponente Nr. 1: DNN | Unternehmen |
Unternehmen 2
Unterstützung für Enterprise 2 ist in Android 13 und höher verfügbar. Im Folgenden finden Sie eine Beispiel-URSP-Regel für ENTERPRISE2-Datenverkehr:
URSP-Regel Nr. 2 (Enterprise2) | |
---|---|
Vorrang | 2 (0x02) |
Verkehrsbeschreibung Nr. 1 | |
Betriebssystem-ID + Betriebssystem-App-ID-Typ | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Komponente Nr. 2: DNN | Unternehmen2 |
Routenauswahldeskriptor Nr. 2 | |
Vorrang | 2 (0x02) |
Komponente Nr. 1: DNN | Unternehmen2 |
Unternehmen 3
Unterstützung für Enterprise 3 ist in Android 13 und höher verfügbar. Im Folgenden finden Sie eine Beispiel-URSP-Regel für ENTERPRISE3-Datenverkehr:
URSP-Regel Nr. 3 (Enterprise3) | |
---|---|
Vorrang | 3 (0x03) |
Verkehrsbeschreibung Nr. 1 | |
Betriebssystem-ID + Betriebssystem-App-ID-Typ | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Komponente Nr. 2: DNN | unternehmen3 |
Routenauswahldeskriptor Nr. 2 | |
Vorrang | 2 (0x02) |
Komponente Nr. 1: DNN | unternehmen3 |
Unternehmen 4
Unterstützung für Enterprise 4 ist in Android 13 und höher verfügbar. Im Folgenden finden Sie eine Beispiel-URSP-Regel für ENTERPRISE4-Datenverkehr:
URSP-Regel Nr. 4 (Enterprise4) | |
---|---|
Vorrang | 4 (0x04) |
Verkehrsbeschreibung Nr. 1 | |
Betriebssystem-ID + Betriebssystem-App-ID-Typ | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Komponente Nr. 2: DNN | Unternehmen4 |
Routenauswahldeskriptor Nr. 2 | |
Vorrang | 2 (0x02) |
Komponente Nr. 1: DNN | Unternehmen4 |
Unternehmen 5
Unterstützung für Enterprise 5 ist in Android 13 und höher verfügbar. Im Folgenden finden Sie eine Beispiel-URSP-Regel für ENTERPRISE5-Datenverkehr:
URSP-Regel Nr. 5 (Enterprise5) | |
---|---|
Vorrang | 5 (0x05) |
Verkehrsbeschreibung Nr. 1 | |
Betriebssystem-ID + Betriebssystem-App-ID-Typ | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Komponente Nr. 2: DNN | Unternehmen5 |
Routenauswahldeskriptor Nr. 2 | |
Vorrang | 2 (0x02) |
Komponente Nr. 1: DNN | Unternehmen5 |
CBS
Unterstützung für CBS ist in Android 13 und höher verfügbar. Das Folgende ist eine Beispiel-URSP-Regel für CBS-Verkehr:
URSP-Regel Nr. 6 (CBS) | |
---|---|
Vorrang | 6 (0x06) |
Verkehrsbeschreibung Nr. 1 | |
Betriebssystem-ID + Betriebssystem-App-ID-Typ | 0x97A498E3FC925C9489860333D06E4E4703434253 |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Komponente Nr. 2: DNN | cbs |
Routenauswahldeskriptor Nr. 2 | |
Vorrang | 2 (0x02) |
Komponente Nr. 1: DNN | cbs |
Geringe Wartezeit
Unterstützung für niedrige Latenz ist in Android 13 und höher verfügbar. Das Folgende ist eine Beispiel-URSP-Regel für LOW_LATENCY-Datenverkehr:
URSP-Regel Nr. 7 (geringe Latenz) | |
---|---|
Vorrang | 7 (0x07) |
Verkehrsbeschreibung Nr. 1 | |
Betriebssystem-ID + Betriebssystem-App-ID-Typ | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Komponente Nr. 2: DNN | Latenz |
Routenauswahldeskriptor Nr. 2 | |
Vorrang | 2 (0x02) |
Komponente Nr. 1: DNN | Latenz |
Grosse Bandbreite
Unterstützung für hohe Bandbreite ist in Android 13 und höher verfügbar. Im Folgenden finden Sie ein Beispiel für eine URSP-Regel für HIGH_BANDWIDTH-Datenverkehr:
URSP-Regel Nr. 8 (hohe Bandbreite) | |
---|---|
Vorrang | 8 (0x08) |
Verkehrsbeschreibung Nr. 1 | |
Betriebssystem-ID + Betriebssystem-App-ID-Typ | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Komponente Nr. 2: DNN | Bandbreite |
Routenauswahldeskriptor Nr. 2 | |
Vorrang | 2 (0x02) |
Komponente Nr. 1: DNN | Bandbreite |
Standard
URSP-Regel Nr. 9 (Standard) | |
---|---|
Vorrang | 9 (0x09) |
Verkehrsbeschreibung Nr. 1 | |
Match-All | N / A |
Routenauswahldeskriptor Nr. 1 | |
Vorrang | 1 (0x01) |
Komponente Nr. 1: S-NSSAI | SST:XX SD:JJJJJJ |
Testen
Um das 5G-Netzwerk-Slicing zu testen, verwenden Sie den folgenden manuellen Test.
Gehen Sie wie folgt vor, um ein Gerät zum Testen einzurichten:
Stellen Sie sicher, dass die URSP-Richtlinie mit einer nicht standardmäßigen Regel konfiguriert ist, die der Unternehmenskategorie entspricht, und dass der entsprechende Routenauswahldeskriptor die Unternehmenskategorie dem Unternehmenssegment zuordnet. und eine Standardregel, die den Datenverkehr zum Standard-Internet-Slice leitet.
Stellen Sie sicher, dass auf dem Gerät ein Arbeitsprofil konfiguriert ist.
Aktivieren Sie die Verwendung von Network Slicing über den DPC
Gehen Sie wie folgt vor, um das 5G-Netzwerk-Slicing-Verhalten zu testen:
- Stellen Sie sicher, dass eine PDU-Sitzung mit dem Enterprise-Slice eingerichtet ist (z. B. durch Verwendung einer bestimmten IP-Adresse) und dass Apps im Arbeitsprofil diese PDU-Sitzung verwenden.
- Stellen Sie sicher, dass eine separate PDU-Sitzung mit dem Standard-Internet-Slice eingerichtet wird und dass Apps im persönlichen Profil die PDU-Sitzung verwenden.
5G-Slicing-Upselling
Mit der 5G-Slicing-Upsell-Funktion, die ab Android 14-QPR1 verfügbar ist, können Netzbetreiber ihren Benutzern durch 5G-Netzwerk-Slicing verbesserte Netzwerkfunktionen (Latenz und Bandbreite) anbieten.
Die 5G-Slicing-Upsell-Funktion nutzt die TS.43-Antwort vom Carrier-Berechtigungsserver, um den Kauffluss voranzutreiben. Netzbetreiber können die Antwort verwenden, um die URL für die Kauf-Webansicht des Netzbetreibers anzugeben, zusätzliche Daten an die Webansicht zu senden und anzugeben, ob der Slice bereitgestellt und im Netz des Netzbetreibers verfügbar ist.
Netzbetreiber können das Verhalten der 5G-Slicing-Upsell-Funktion mithilfe von Netzbetreiberkonfigurationen anpassen, die steuern, ob Kaufanfragen gestellt werden können, wann Apps Premium-Funktionen anfordern dürfen und wie lange das Telefonie-Framework auf Antworten vom Benutzer oder vom Netzwerk wartet.
Die 5G-Slicing-Upsell-Funktion stellt eine Schnittstelle namens DataBoostWebServiceFlow
bereit, um die Kommunikation zwischen Android und der Webansicht des Netzbetreibers zu ermöglichen.
Abbildung 2 zeigt den 5G-Slicing-Upsell-Kaufablauf:
Abbildung 2. 5G-Slicing-Upsell-Kaufablauf.
TS.43-Berechtigungsprozess
Wenn ein Benutzer eine Anfrage nach erweiterten Netzwerkfunktionen stellt, fordert das Telefonie-Framework die Konfiguration der Dienstberechtigungen für die angeforderte Premium-Funktion an. Wenn die TS.43-Antwort gültig ist, verwendet das Telefonie-Framework die Felder aus der HTTP-Antwort, um die Kaufanfrage zu steuern.
Slice-Kauffelder
Die TS.43-Berechtigungskonfiguration umfasst die folgenden Slice-Kauffelder:
- Berechtigungsstatus
Schlüssel:
EntitlementStatus
Typ:
int
Unterstützte Werte:
0
(deaktiviert),1
(aktiviert),2
(inkompatibel),3
(Bereitstellung),4
(enthalten)- Bereitstellungsstatus
Schlüssel:
ProvStatus
Typ:
int
Unterstützte Werte:
0
(nicht bereitgestellt),1
(bereitgestellt),2
(nicht verfügbar),3
(in Bearbeitung)
Das Telefonie-Framework verwendet die Kombination aus Berechtigungsstatus und Bereitstellungsstatus, um den aktuellen Slice-Kaufstatus zu bestimmen. Das Ergebnis kann eines der folgenden sein:
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASED
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESS
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILED
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Wenn der Berechtigungsstatus 1
(aktiviert) und der Bereitstellungsstatus 0
(nicht bereitgestellt) ist, zeigt das Telefonie-Framework dem Benutzer eine Upsell-Benachrichtigung an, um den Boost über die Webansicht des Netzbetreibers zu erwerben. In der folgenden Tabelle wird das Verhalten des Telefonie-Frameworks für verschiedene Kombinationen von Bereitstellungs- und Berechtigungsstatuswerten beschrieben.
Bereitstellungsstatus | |||||
---|---|---|---|---|---|
Nicht bereitgestellt ( 0 ) | Bereitgestellt ( 1 ) 1 ) | Nicht verfügbar ( 2 ) | In Bearbeitung ( 3 ) | ||
Berechtigungsstatus | Deaktiviert ( 0 ) | Fehlgeschlagen | Fehlgeschlagen | Fehlgeschlagen | Fehlgeschlagen |
Aktiviert ( 1 ) | Webansicht anzeigen | Bereits gekauft | Bereits gekauft | Im Gange | |
Inkompatibel ( 2 ) | Fehlgeschlagen | Fehlgeschlagen | Fehlgeschlagen | Fehlgeschlagen | |
Bereitstellung ( 3 ) | Trägerfehler | Trägerfehler | Im Gange | Im Gange | |
Im Lieferumfang enthalten ( 4 ) | Trägerfehler | Bereits gekauft | Bereits gekauft | Trägerfehler |
Service-Flow-Felder
Die TS.43-Antwort gibt die URL, die Benutzerdaten und den Inhaltstyp an, um das Webansichtsverhalten beim Netzbetreiberkauf anzupassen. Wenn der Inhaltstyp nicht angegeben ist, wird die URL als GET-Anfrage geladen. Wenn die Benutzerdaten vorhanden sind, werden sie als Abfrageparameter an die URL angehängt (z. B. https://www.android.com?encodedValue=Base64EncodedUserData
); und wenn sie nicht vorhanden ist, wird die URL unverändert verwendet (z. B. https://www.android.com
).
Wenn der Inhaltstyp im JSON- oder XML-Format angegeben ist, wird die URL als POST-Anfrage geladen und die Benutzerdaten (dekodiert, wenn sie in Base 64 kodiert sind) werden als Daten für die POST-Anfrage gesendet.
- URL
Schlüssel:
ServiceFlow_URL
Typ:
String
Beispiel:
"https://www.android.com"
- Benutzerdaten
Schlüssel:
ServiceFlow_UserData
Typ:
String
Beispiel:
"encodedValue=Base64EncodedUserData"
- Inhaltstyp
Schlüssel:
ServiceFlow_ContentsType
Typ:
String
Unterstützte Werte:
0
(nicht spezifiziert),1
(JSON),2
(XML)
Trägerkonfigurationen
Im Folgenden sind die verfügbaren Netzbetreiberkonfigurationen aufgeführt, mit denen Sie das Verhalten der 5G-Slicing-Upsell-Funktion anpassen können.
-
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY
Eine Liste der unterstützten Premium-Funktionen. Dies ist ein int-Array von
TelephonyManager.PremiumCapability
. Diese Premium-Funktionen haben denselben Wert wie die entsprechendeNetworkCapabilities.NetCapability
Klasse. Wenn eine Premium-Funktion angefordert wird und diese nicht in dieser Konfiguration enthalten ist, schlägt die Kaufanfrage mit dem ErgebnisCARRIER_DISABLED
fehl.In Android 14 wird nur
PREMIUM_CAPABILITY_PRIORITIZE_LATENCY
unterstützt.-
KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT
Die tägliche maximale Häufigkeit, mit der dem Benutzer die Kauf-Upsell-Benachrichtigung angezeigt wird. Wenn das Tagesmaximum erreicht ist, wird die Upsell-Benachrichtigung nicht angezeigt und Kaufanfragen (einschließlich Anfragen des Berechtigungsservers) werden bis Mitternacht des nächsten Tages gedrosselt. Kaufanfragen, die nach Erreichen des Tagesmaximums gestellt werden, schlagen mit dem Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
fehl.-
KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT
Die monatliche maximale Häufigkeit, mit der dem Benutzer die Kauf-Upsell-Benachrichtigung angezeigt wird. Wenn das monatliche Maximum erreicht ist, wird die Upsell-Benachrichtigung nicht angezeigt und Kaufanfragen (einschließlich Berechtigungsserveranfragen) werden bis zum ersten Tag des Folgemonats gedrosselt. Kaufanfragen, die nach Erreichen des monatlichen Maximums gestellt werden, schlagen mit dem Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
fehl.-
KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING
Die Kauf-URL des Ersatzanbieters, die dem Benutzer angezeigt wird, wenn er auf die Upsell-Benachrichtigung klickt. Wenn die Kauf-URL nicht in der TS.43-Antwort vom Berechtigungsserver gefunden wird, wird stattdessen dieser Wert verwendet. Wenn weder die URL aus der TS.43-Antwort noch die Netzbetreiberkonfiguration gültig ist, schlägt die Kaufanfrage mit dem Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED
fehl.-
KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL
Ob der Kauf von Premium-Funktionen zugelassen werden soll, wenn das Gerät mit Long-Term Evolution (LTE) verbunden ist. Bei
true
können Kaufanfragen sowohl für LTE als auch für New Radio (NR) gestellt werden. Beifalse
können Kaufanfragen nur über NR gestellt werden und Anfragen über LTE schlagen mit dem ErgebnisPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE
fehl.-
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG
Die Zeitspanne, die dem Benutzer die Kauf-Upsell-Benachrichtigung angezeigt wird, bevor sie automatisch storniert wird. Wenn die Benachrichtigung abgebrochen wird, werden nachfolgende Anforderungen gedrosselt und schlagen mit dem Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
fehl.-
KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG
Die Zeitspanne, die nachfolgende Kaufanfragen nach einem Fehler aufgrund einer Zeitüberschreitung oder eines Benutzerabbruchs gedrosselt werden sollen. Wenn der Benutzer nicht innerhalb des durch
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG
angegebenen Zeitlimits auf die Kauf-Upsell-Benachrichtigung klickt oder wenn er die Benachrichtigung abbricht oder ablehnt, startet dieser Backoff-Timer. Während dieser Timer aktiv ist, schlagen Kaufanfragen mit dem ErgebnisPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
fehl.-
KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG
Der Zeitraum, für den nachfolgende Kaufanfragen nach einem Fehler aufgrund des Netzbetreibers oder Netzwerks gedrosselt werden sollen. Wenn die Berechtigungsprüfung fehlschlägt, die URL nicht verfügbar ist oder die Kauf-URL des Netzbetreibers einen Fehler anzeigt, startet dieser Backoff-Timer. Während dieser Timer aktiv ist, schlagen Kaufanfragen mit dem Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED
fehl.-
KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG
Die Zeitspanne, innerhalb derer das Netzwerk eine Slicing-Konfiguration für die Premium-Kauffunktion einrichten muss. Während dieses Zeitraums werden nachfolgende Kaufanfragen blockiert und geben das Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP
zurück. Wenn es dem Netzwerk nicht gelingt, rechtzeitig eine Slicing-Konfiguration einzurichten, können Apps erneut den Kauf von Premium-Funktionen anfordern. Telefonie betrachtet einen Kauf erst dann als abgeschlossen, wenn die entsprechende Slicing-Konfiguration gesendet wird, unabhängig davon, ob der Benutzer den Mobilfunkanbieter bezahlt hat oder nicht.
Javascript-Schnittstelle
Wenn der Benutzer auf die Netzwerk-Boost-Benachrichtigung klickt, wird dem Benutzer ein WebView
Objekt mit der Kauf-URL des Netzbetreibers angezeigt. Netzbetreiber können die in der DataBoostWebServiceFlow
Javascript-Schnittstelle bereitgestellten APIs auf ihrer Kaufwebsite verwenden, um mit der Slice-Kauf-App zu kommunizieren.
Die Carrier-Website kann die angeforderte Premium-Funktion über die Methode getRequestedCapability()
abrufen.
Wenn der Kauf erfolgreich ist, muss die Carrier-Website die Slice-Kauf-App über notifyPurchaseSuccessful()
oder notifyPurchaseSuccessful(duration)
benachrichtigen, wobei duration
ein optionaler Parameter ist, der die beabsichtigte Dauer des Slice angibt.
Wenn der Kauf nicht erfolgreich ist, muss die Carrier-Website die Slice-Kauf-App über die Methode notifyPurchaseFailed(code, reason)
benachrichtigen, wobei code
der Fehlercode ist, der den Grund für den Fehler angibt, und reason
der für Menschen lesbare Grund für den Fehler ist, wenn der Fehlercode ist unbekannt.
Wenn keine dieser Antwortmethoden aufgerufen wird, gilt der Kauf nicht als abgeschlossen und die Kaufanfrage läuft möglicherweise ab.
Im Folgenden sind die gültigen Fehlercodes aufgeführt, die die Website des Anbieters bei einem Kauffehler zurückgeben kann:
-
FAILURE_CODE_UNKNOWN
-
FAILURE_CODE_CARRIER_URL_UNAVAILABLE
-
FAILURE_CODE_AUTHENTICATION_FAILED
-
FAILURE_CODE_PAYMENT_FAILED
-
FAILURE_CODE_NO_USER_DATA
Wenn der Kauf abgeschlossen ist, muss der Netzbetreiber die URSP-Regeln mit dem PRIORITIZE_LATENCY
Slice auf dem Gerät des Benutzers aktualisieren.