5G-Netzwerk-Slicing

Auf Geräten mit Android 12 oder höher unterstützt Android 5G-Network Slicing. Dabei wird die Netzwerkvirtualisierung verwendet, um einzelne Netzwerkverbindungen in mehrere separate virtuelle Verbindungen aufzuteilen, die verschiedenen Arten von Traffic unterschiedliche Mengen an Ressourcen zur Verfügung stellen. Mit 5G-Network Slicing können Netzbetreiber einen Teil des Netzwerks für bestimmte Funktionen für ein bestimmtes Kundensegment reservieren. Mit Android 12 werden die folgenden 5G-Funktionen für das Network Slicing für Unternehmen eingeführt, die Netzbetreiber ihren Unternehmenskunden anbieten können:

Aufteilen von Unternehmensgeräten 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 ein oder mehrere aktive Unternehmensnetzwerk-Slices bereitstellen, zu denen der Traffic auf den Unternehmensgeräten weitergeleitet wird. Ab Android 12 können Mobilfunkanbieter Unternehmens-Slices über URSP-Regeln bereitstellen, anstatt Slices über APNs einzurichten.

App-Slicing für Unternehmens-Apps auf Geräten mit Arbeitsprofilen

Für Unternehmen, die die Arbeitsprofil-Lösung verwenden, können Geräte unter Android 12 den Traffic aller Apps im Arbeitsprofil an einen Unternehmensnetzwerk-Slice weiterleiten. Unternehmen können diese Funktion über einen Device Policy Controller (DPC) aktivieren.

Die Arbeitsprofillösung bietet eine automatische Authentifizierung und Zugriffssteuerung, die Unternehmen benötigen, um sicherzustellen, dass nur Traffic von Unternehmens-Apps im Arbeitsprofil an den Unternehmensnetzwerk-Slice weitergeleitet wird. Apps im Arbeitsprofil müssen nicht geändert werden, um explizit den Unternehmensnetzwerk-Slice anzufordern.

So funktioniert 5G‑Network Slicing in AOSP

In Android 12 wird die Unterstützung für 5G-Network-Slicing eingeführt. Dazu wurden der Telefonie-Codebase in AOSP und dem Tethering-Modul vorhandene Connectivity-APIs hinzugefügt, die für Network-Slicing erforderlich sind.

Die Android-Telefonieplattform bietet HAL- und Telefonie-APIs zur Unterstützung von Slicing basierend auf Netzwerkanfragen, die vom Core-Networking-Code und den 5G-Slicing-Funktionen im Modem gestellt werden. Abbildung 1 zeigt die Komponenten der 5G-Network-Slicing-Funktion.

5G‑Network-Slicing-Komponenten

Abbildung 1: 5G‑Network Slicing-Architektur in AOSP.

Die Telefonie- und Verbindungsplattform unterstützt:

  • Umwandlung von Netzwerkanfragen für Slice-Kategorien in Traffic-Deskriptoren, die dann an das Modem zur URSP-Traffic-Abstimmung und Routenauswahl übergeben werden
  • Auf das Standardnetzwerk zurückgreifen, wenn der Unternehmensnetzwerk-Slice nicht verfügbar ist
  • Traffic von allen Apps im Arbeitsprofil an die entsprechende Verbindung weiterleiten

  • Unterstützung von Unternehmenssegmentierung

    • Erkennen, ob ein Arbeitsprofil auf dem Gerät vorhanden ist
    • Prüfen von Berechtigungen oder Routenbeschreibungen, die vom DPC des IT-Administrators des Unternehmens bereitgestellt werden

Der Hauptnetzwerkdienst umfasst die folgenden Änderungen am Tethering-Modul in Android 12:

  • Fügt die meisten öffentlichen oder System-API-Klassen von android.net.* dem 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

In Android 12 wird Code mit den folgenden Funktionen in das Tethering-Modul verschoben:

  • Anfragen von Apps für Netzwerkverbindungen empfangen
  • Anfragen vom System empfangen (z. B. „Diese Apps in einem Unternehmensprofil platzieren“; eingeführt in Android 12)
  • Anfragen vom System an den Telefoniecode senden, der versucht, Netzwerke oder Slices über die HAL-API und das Modem einzurichten
  • netd mitteilen, wie Traffic pro App weitergeleitet werden soll (eingeführt in Android 12)
  • Apps darüber informieren, was mit ihrem Netzwerk-Traffic passiert, über ConnectivityManager-APIs wie NetworkCallback, getActiveNetwork und getNetworkCapabilities.

Implementierung

Damit ein Gerät 5G-Slicing unterstützt, muss es ein Modem haben, das die IRadio 1.6-HAL mit der setupDataCall_1_6-API unterstützt. Diese API richtet eine Datenverbindung ein und enthält die folgenden Parameter zur Unterstützung von 5G‑Slicing:

  • trafficDescriptor: Gibt den Traffic-Deskriptor an, der an das Modem gesendet wird.
  • 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 URSP-Regel für alle Übereinstimmungen zulässig ist. Bei Standardnetzwerken wird dieser Wert von der Telefonie auf „true“ gesetzt, bei Slices jedoch nicht. Die Regel „Mit allen übereinstimmen“ wird auf Standardnetzwerke angewendet. Wenn eine App ein bestimmtes Segment anfordert, das nicht verfügbar ist, wird das Segment als nicht verfügbar gemeldet. Bei Unternehmens-Apps kann das Telephony-Framework auf das Standardnetzwerk zurückgreifen, wenn das Unternehmensnetzwerk nicht verfügbar ist.

Modems müssen auch die getSlicingConfig API implementieren, sofern sie nicht von der getHalDeviceCapabilities API als nicht unterstützt gemeldet wird.

Anforderungen für Unternehmen

Im Folgenden werden die Anforderungen für Unternehmen beschrieben, die 5G-Network-Slicing auf Geräten in einer Android Enterprise-Bereitstellung verwenden möchten.

  • Achten Sie darauf, dass vollständig verwaltete Geräte oder Mitarbeitergeräte, die mit einem Arbeitsprofil eingerichtet sind, 5G SA-fähig sind und Modems haben, die die setupDataCall_1_6-API unterstützen.
  • Mit dem Mobilfunkanbieter zusammenarbeiten, um Slice-Einrichtung und Leistungs- oder SLA-Merkmale zu optimieren.

5G-Slicing auf Geräten mit Arbeitsprofil aktivieren

Bei Geräten, die mit Arbeitsprofilen eingerichtet sind, ist 5G-Network-Slicing in AOSP standardmäßig deaktiviert. Um Network Slicing zu aktivieren, können IT-Administratoren in Unternehmen die Weiterleitung des Traffics von Arbeitsprofil-Apps an den Unternehmensnetzwerk-Slice für jeden Mitarbeiter über den EMM-DPC aktivieren oder deaktivieren. Dazu wird die Methode setPreferentialNetworkServiceEnabled in der API DevicePolicyManager (DPM) verwendet, die in Android 12 eingeführt wurde.

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 Mobilfunkanbieter zur Konfiguration von URSP-Regeln für verschiedene Slice-Kategorien, darunter Unternehmens-, CBS-, Low-Latency- und High-Bandwidth-Traffic. Bei der Konfiguration von URSP-Regeln für verschiedene Slice-Kategorien müssen Mobilfunkanbieter die folgenden Android-spezifischen Werte verwenden.

ID 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.

Mobilfunkanbieter müssen URSP-Regeln für jeden Slice-Traffic mit der Traffic-Deskriptorkomponente „OS Id + OS App Id type“ konfigurieren. Für das Segment „ENTERPRISE“ muss beispielsweise der Wert 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 festgelegt sein. Dieser Wert ist eine Verkettung der OSId, der Länge der OSAppId (0x0A) und der OSAppId. Weitere Informationen zum Komponententyp des Verkehrsdeskriptors 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.

Segmentkategorie OSAppId Beschreibung
ENTERPRISE 0x454E5445525052495345 Die OSAppId ist eine Byte-Array-Darstellung des Strings „ENTERPRISE“.
ENTERPRISE2 0x454E544552505249534532 Die OSAppId ist eine Byte-Array-Darstellung des Strings „ENTERPRISE2“.
ENTERPRISE3 0x454E544552505249534533 Die OSAppId ist eine Byte-Array-Darstellung des Strings „ENTERPRISE3“.
ENTERPRISE4 0x454E544552505249534534 Die OSAppId ist eine Byte-Array-Darstellung des Strings „ENTERPRISE4“.
ENTERPRISE5 0x454E544552505249534535 Die OSAppId ist eine Byte-Array-Darstellung des Strings „ENTERPRISE5“.
CBS 0x434253 Die OSAppId ist eine Byte-Array-Darstellung des Strings „CBS“.
PRIORITIZE_LATENCY 0x5052494f524954495a455f4c4154454e4359 Die OSAppId ist eine Byte-Array-Darstellung des Strings „PRIORITIZE_LATENCY“.
PRIORITIZE_BANDWIDTH 0x5052494f524954495a455f42414e445749445448 Die OSAppId ist eine Byte-Array-Darstellung des Strings „PRIORITIZE_BANDWIDTH“.

Beispiel für URSP-Regeln

Die folgenden Tabellen enthalten Beispielregeln für URSP für Unternehmens-, CBS-, Low-Latency-, High-Bandwidth- und Standard-Traffic.

Enterprise 1

Die Unterstützung für Enterprise 1 ist ab Android 12 verfügbar. Hier ist ein Beispiel für eine URSP-Regel für ENTERPRISE1-Traffic:

URSP-Regel 1 (enterprise1)
Vorrang 1 (0x01)
Traffic-Deskriptor 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN Unternehmen
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN Unternehmen

Enterprise 2

Unterstützung für Enterprise 2 ist ab Android 13 verfügbar. Hier ist ein Beispiel für eine URSP-Regel für ENTERPRISE2-Traffic:

URSP-Regel 2 (enterprise2)
Vorrang 2 (0x02)
Traffic-Deskriptor 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN enterprise2
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN enterprise2

Enterprise 3

Unterstützung für Enterprise 3 ist ab Android 13 verfügbar. Hier ist ein Beispiel für eine URSP-Regel für ENTERPRISE3-Traffic:

URSP-Regel 3 (enterprise3)
Vorrang 3 (0x03)
Traffic-Deskriptor 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN enterprise3
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN enterprise3

Enterprise 4

Die Unterstützung für Enterprise 4 ist ab Android 13 verfügbar. Hier ist ein Beispiel für eine URSP-Regel für ENTERPRISE4-Traffic:

URSP-Regel 4 (enterprise4)
Vorrang 4 (0x04)
Traffic-Deskriptor 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN enterprise4
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN enterprise4

Enterprise 5

Unterstützung für Enterprise 5 ist in Android 13 und höher verfügbar. Hier ist ein Beispiel für eine URSP-Regel für ENTERPRISE5-Traffic:

URSP-Regel 5 (enterprise5)
Vorrang 5 (0x05)
Traffic-Deskriptor 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN enterprise5
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN enterprise5

CBS

Die Unterstützung für CBS ist ab Android 13 verfügbar. Hier ist ein Beispiel für eine URSP-Regel für CBS-Traffic:

URSP-Regel 6 (CBS)
Vorrang 6 (0x06)
Traffic-Deskriptor 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E4703434253
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN cbs
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN cbs

Niedrige Latenz

Die Unterstützung für niedrige Latenz ist in Android 13 und höher verfügbar. Hier ist ein Beispiel für eine URSP-Regel für LOW_LATENCY-Traffic:

URSP-Regel 7 (niedrige Latenz)
Vorrang 7 (0x07)
Traffic-Deskriptor 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN Latenz
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN Latenz

Hohe Bandbreite

Die Unterstützung für hohe Bandbreite ist ab Android 13 verfügbar. Hier ist ein Beispiel für eine URSP-Regel für HIGH_BANDWIDTH-Traffic:

URSP-Regel 8 (hohe Bandbreite)
Vorrang 8 (0x08)
Traffic-Deskriptor 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN Bandbreite
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN Bandbreite

Standard

URSP-Regel 9 (Standard)
Vorrang 9 (0x09)
Traffic-Deskriptor 1
match-all –
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY

Testen

Verwenden Sie den folgenden manuellen Test, um 5G-Network-Slicing zu testen.

So richten Sie ein Gerät für Tests ein:

  1. Die URSP-Richtlinie muss mit einer nicht standardmäßigen Regel konfiguriert sein, die der Unternehmenskategorie entspricht. Der entsprechende Routenauswahldeskriptor muss die Unternehmenskategorie der Unternehmens-Slice zuordnen. Außerdem muss eine Standardregel vorhanden sein, die den Traffic an die Standard-Internet-Slice weiterleitet.

  2. Achten Sie darauf, dass auf dem Gerät ein Arbeitsprofil konfiguriert ist.

  3. Netzwerk-Slicing über den DPC aktivieren

So testen Sie das Verhalten von 5G-Network-Slicing:

  1. Prüfen Sie, ob eine PDU-Sitzung mit dem Unternehmens-Slice eingerichtet wurde (z. B. über eine bestimmte IP-Adresse) und ob Apps im Arbeitsprofil diese PDU-Sitzung verwenden.
  2. Prüfen Sie, ob eine separate PDU-Sitzung mit dem Standard-Internetslice eingerichtet wurde und ob Apps im privaten Profil die PDU-Sitzung verwenden.

Upselling von 5G‑Slicing

Mit der Upsell-Funktion für 5G-Slicing, die ab Android 14-QPR1 verfügbar ist, können Mobilfunkanbieter ihren Nutzern über 5G-Network-Slicing verbesserte Netzwerkfunktionen (Latenz und Bandbreite) anbieten.

Die Upsell-Funktion für 5G-Slicing nutzt die TS.43-Antwort des Berechtigungsservers des Mobilfunkanbieters, um den Kaufvorgang zu steuern. Mobilfunkanbieter können mit der Antwort die URL für die Kauf-Webview des Mobilfunkanbieters angeben, zusätzliche Daten an die Webview senden und angeben, ob der Slice im Mobilfunknetz des Mobilfunkanbieters bereitgestellt und verfügbar ist.

Mobilfunkanbieter können das Verhalten der Upsell-Funktion für 5G-Slicing mithilfe von Anbieterkonfigurationen anpassen. Damit wird gesteuert, ob Kaufanfragen gestellt werden können, wann Apps Premium-Funktionen anfordern dürfen und wie lange das Telefonie-Framework auf Antworten vom Nutzer oder vom Netzwerk wartet.

Die Upsell-Funktion für 5G‑Slicing bietet eine Schnittstelle namens DataBoostWebServiceFlow, über die die Kommunikation zwischen Android und der Webview des Mobilfunkanbieters ermöglicht wird.

Abbildung 2 zeigt den Kaufvorgang für das 5G-Slicing-Upselling:

Kaufvorgang für Upselling von 5G‑Slicing

Abbildung 2: Kaufvorgang für das Upselling von 5G‑Slicing.

TS.43-Berechtigungsprozess

Wenn ein Nutzer eine Anfrage für erweiterte Netzwerkfunktionen stellt, fordert das Telephony-Framework die Konfiguration für die Dienstberechtigung für die angeforderte Premium-Funktion an. Wenn die TS.43-Antwort gültig ist, verwendet das Telephony-Framework die Felder aus der HTTP-Antwort, um die Kaufanfrage zu steuern.

Kauffelder segmentieren

Die TS.43-Berechtigungskonfiguration umfasst die folgenden Felder für den Kauf von Slices:

Berechtigungsstatus

Taste: EntitlementStatus

Typ: int

Unterstützte Werte: 0 (deaktiviert), 1 (aktiviert), 2 (nicht kompatibel), 3 (Bereitstellung), 4 (enthalten)

Status der Nutzerverwaltung

Taste: ProvStatus

Typ: int

Unterstützte Werte: 0 (nicht bereitgestellt), 1 (bereitgestellt), 2 (nicht verfügbar), 3 (wird ausgeführt)

Das Telefonie-Framework verwendet die Kombination aus Berechtigungsstatus und Bereitstellungsstatus, um den aktuellen Status des Slice-Kaufs zu bestimmen. Das Ergebnis kann einer der folgenden Werte sein:

Wenn der Berechtigungsstatus 1 (aktiviert) und der Bereitstellungsstatus 0 (nicht bereitgestellt) ist, wird dem Nutzer im Telefonie-Framework eine Upsell-Benachrichtigung angezeigt, in der er aufgefordert wird, das Boost über die Webview des Mobilfunkanbieters zu kaufen. In der folgenden Tabelle wird das Verhalten des Telephony-Frameworks für verschiedene Kombinationen von Bereitstellungs- und Berechtigungsstatuswerten beschrieben.

Bereitstellungsstatus
Nicht bereitgestellt (0) Bereitgestellt (1) Nicht verfügbar (2) Wird bearbeitet (3)
Berechtigungsstatus Deaktiviert (0) Fehlgeschlagen Fehlgeschlagen Fehlgeschlagen Fehlgeschlagen
Aktiviert (1) WebView anzeigen Bereits gekauft Bereits gekauft In Bearbeitung
Nicht kompatibel (2) Fehlgeschlagen Fehlgeschlagen Fehlgeschlagen Fehlgeschlagen
Bereitstellung (3) Mobilfunkanbieterfehler Mobilfunkanbieterfehler In Bearbeitung In Bearbeitung
Enthalten (4) Mobilfunkanbieterfehler Bereits gekauft Bereits gekauft Mobilfunkanbieterfehler

Felder für den Serviceablauf

In der TS.43-Antwort werden die URL, die Nutzerdaten und der Inhaltstyp angegeben, um das Verhalten der Webview für den Kauf beim Mobilfunkanbieter anzupassen. Wenn der Inhaltstyp nicht angegeben ist, wird die URL als GET-Anfrage geladen. Wenn die Nutzerdaten vorhanden sind, werden sie als Suchparameter an die URL angehängt (z. B. https://www.android.com?encodedValue=Base64EncodedUserData). Andernfalls 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 Nutzerdaten (decodiert, falls sie in Base 64 codiert sind) werden als Daten für die POST-Anfrage gesendet.

URL

Taste: ServiceFlow_URL

Typ: String

Beispiel: "https://www.android.com"

Nutzerdaten

Taste: ServiceFlow_UserData

Typ: String

Beispiel: "encodedValue=Base64EncodedUserData"

Inhaltstyp

Taste: ServiceFlow_ContentsType

Typ: String

Unterstützte Werte: 0 (nicht angegeben), 1 (JSON), 2 (XML)

Konfigurationen des Mobilfunkanbieters

Im Folgenden sind die verfügbaren Mobilfunkanbieterkonfigurationen aufgeführt, mit denen das Verhalten der Upsell-Funktion für 5G‑Slicing angepasst werden kann.

KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY

Eine Liste der unterstützten Premiumfunktionen. Dies ist ein Int-Array von TelephonyManager.PremiumCapability. Diese Premiumfunktionen haben denselben Wert wie die entsprechende Klasse NetworkCapabilities.NetCapability. Wenn eine Premium-Funktion angefordert wird, die nicht in dieser Konfiguration enthalten ist, schlägt die Kaufanfrage mit dem Ergebnis CARRIER_DISABLED fehl.

In Android 14 wird nur PREMIUM_CAPABILITY_PRIORITIZE_LATENCY unterstützt.

KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT

Die maximale Anzahl der täglichen Anzeigen der Benachrichtigung zum Upselling von Käufen für den Nutzer. Wenn das Tageslimit erreicht ist, wird die Upsell-Benachrichtigung nicht angezeigt und Kaufanfragen (einschließlich Anfragen an den Berechtigungsserver) werden bis Mitternacht des nächsten Tages gedrosselt. Kaufanfragen, die nach Erreichen des Tageslimits gestellt werden, schlagen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED fehl.

KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT

Die monatliche maximale Anzahl der Anzeigen der Benachrichtigung zum Upselling von Käufen für den Nutzer. 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 URL für den Kauf des Reserve-Carriers, die dem Nutzer angezeigt werden soll, wenn er auf die Upsell-Benachrichtigung klickt. Wenn die Kauf-URL nicht in der TS.43-Antwort des Berechtigungsservers gefunden wird, wird stattdessen dieser Wert verwendet. Wenn weder die URL aus der TS.43-Antwort noch die Betreiberkonfiguration gültig ist, schlägt die Kaufanfrage mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED fehl.

KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL

Gibt an, ob Premium-Funktionen gekauft werden dürfen, wenn das Gerät mit Long-Term Evolution (LTE) verbunden ist. Bei true können Kaufanfragen sowohl über LTE als auch über New Radio (NR) gestellt werden. Wenn false, können Kaufanfragen nur über NR gestellt werden. Anfragen über LTE schlagen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE fehl.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG

Die Zeit, die die Benachrichtigung zum Upselling von Käufen dem Nutzer angezeigt wird, bevor sie automatisch abgebrochen wird. Wenn die Benachrichtigung abgebrochen wird, werden nachfolgende Anfragen gedrosselt und schlagen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED fehl.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Die Zeitspanne, in der nachfolgende Kaufanfragen nach einem Fehler aufgrund von Zeitüberschreitung oder Nutzerabbruch gedrosselt werden sollten. Wenn der Nutzer nicht innerhalb des durch KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG angegebenen Zeitlimits auf die Benachrichtigung zum Upselling klickt oder die Benachrichtigung abbricht oder schließt, wird dieser Backoff-Timer gestartet. Während dieser Zeit schlagen Kaufanfragen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED fehl.

KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Die Zeitspanne, in der nachfolgende Kaufanfragen nach einem Fehler aufgrund des Mobilfunkanbieters oder Netzwerks gedrosselt werden sollen. Wenn die Berechtigungsprüfung fehlschlägt, die URL nicht verfügbar ist oder die URL für den Kauf über den Mobilfunkanbieter einen Fehler anzeigt, wird dieser Backoff-Timer gestartet. 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 Zeit, innerhalb derer das Netzwerk eine Slicing-Konfiguration für die Kaufprämie einrichten muss. Während dieses Zeitraums werden nachfolgende Kaufanfragen blockiert und geben das Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP zurück. Wenn das Netzwerk die Einrichtung einer Slicing-Konfiguration nicht rechtzeitig durchführt, können Apps noch einmal den Kauf von Premium-Funktionen anfordern. Bei der Telefonie gilt ein Kauf erst dann als abgeschlossen, wenn die entsprechende Slicing-Konfiguration gesendet wurde, unabhängig davon, ob der Nutzer den Mobilfunkanbieter bezahlt hat oder nicht.

JavaScript-Schnittstelle

Wenn der Nutzer auf die Benachrichtigung zum Netzwerk-Boost klickt, wird ihm ein WebView-Objekt mit der Kauf-URL des Mobilfunkanbieters angezeigt. Mobilfunkanbieter können die APIs, die in der Javascript-Schnittstelle DataBoostWebServiceFlow bereitgestellt werden, auf ihrer Kaufwebsite verwenden, um mit der App für den Kauf von Slices zu kommunizieren.

Die Website des Mobilfunkanbieters kann die angeforderte Premium-Funktion über die Methode getRequestedCapability() abrufen.

Wenn der Kauf erfolgreich ist, muss die Website des Mobilfunkanbieters die App für den Kauf von Teilinhalten über notifyPurchaseSuccessful() oder notifyPurchaseSuccessful(duration) benachrichtigen. Dabei ist duration ein optionaler Parameter, der die beabsichtigte Dauer des Teilinhalts angibt.

Wenn der Kauf nicht erfolgreich ist, muss die Website des Mobilfunkanbieters die App für den Kauf von Datenvolumen über die Methode notifyPurchaseFailed(code, reason) benachrichtigen. Dabei ist code der Fehlercode, der den Grund für den Fehler angibt, und reason der für Menschen lesbare Grund für den Fehler, wenn der Fehlercode unbekannt ist.

Wenn keine dieser Antwortmethoden aufgerufen wird, gilt der Kauf nicht als abgeschlossen und die Kaufanfrage läuft schließlich ab.

Die folgenden gültigen Fehlercodes können von der Website des Mobilfunkanbieters bei einem fehlgeschlagenen Kauf zurückgegeben werden:

Nach Abschluss des Kaufs muss der Mobilfunkanbieter die URSP-Regeln mit dem PRIORITIZE_LATENCY-Slice auf dem Gerät des Nutzers aktualisieren.