5G-Netzwerkaufteilung

Auf Geräten mit Android 12 oder höher unterstützt Android 5G-Netzwerk-Slicing. Dabei werden einzelne Netzwerkverbindungen mithilfe von Netzwerkvirtualisierung in mehrere verschiedene virtuelle Verbindungen unterteilt, die verschiedenen Arten von Traffic unterschiedliche Ressourcen zur Verfügung stellen. Mit 5G-Netzwerk-Slicing können Netzwerkbetreiber einen Teil des Netzwerks für die Bereitstellung bestimmter Funktionen für ein bestimmtes Kundensegment reservieren. Mit Android 12 werden die folgenden 5G-Unternehmensnetzwerk-Slicing-Funktionen eingeführt, die Netzwerkbetreiber ihren Unternehmensclients zur Verfügung stellen können:

Enterprise Device Slicing für vollständig verwaltete Geräte

Für Unternehmen, die ihren Mitarbeitern vollständig verwaltete unternehmenseigene Geräte zur Verfügung stellen, können Netzwerkanbieter ihnen ein oder mehrere aktive unternehmenseigene Netzwerksegmente zur Verfügung stellen, an die der Traffic auf den unternehmenseigenen Geräten weitergeleitet wird. Ab Android 12 können Mobilfunkanbieter Unternehmens-Slices über URSP-Regeln bereitstellen, anstatt Slices über APNs einzurichten.

App-Slicing für Unternehmen für Geräte mit Arbeitsprofilen

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

Die Arbeitsprofillösung bietet eine automatische Ebene der Authentifizierung und Zugriffssteuerung, die Unternehmen benötigen, um sicherzustellen, dass nur Traffic von Unternehmensanwendungen im Arbeitsprofil an das Unternehmensnetzwerksegment geleitet wird. Apps im Arbeitsprofil müssen nicht geändert werden, um das Unternehmensnetzwerksegment explizit anzufordern.

So funktioniert 5G-Netzwerk-Slicing in AOSP

Android 12 unterstützt 5G-Netzwerk-Slicing durch Ergänzungen der Telefonie-Codebase in AOSP und des Tethering-Moduls, um vorhandene Konnektivitäts-APIs zu integrieren, die für Network Slicing erforderlich sind.

Die Android-Telefonieplattform bietet HAL- und Telefonie-APIs zur Unterstützung von Slices basierend auf Netzwerkanfragen, die vom Kernnetzwerkcode gestellt werden, und 5G-Slice-Funktionen im Modem. Abbildung 1 zeigt die Komponenten der 5G-Netzwerksegmentierungsfunktion.

Komponenten für 5G-Netzwerk-Slicing

Abbildung 1. 5G-Netzwerk-Slicing-Architektur in AOSP

Die Telefonie- und Konnektivitätsplattform unterstützt:

  • Netzwerkanfragen für Segmentkategorien in Trafficdeskriptoren umwandeln, die dann für den URSP-Trafficabgleich und die Routenauswahl an das Modem übergeben werden
  • Wenn das Unternehmensnetzwerk-Stück nicht verfügbar ist, auf das Standardnetzwerk zurückgreifen
  • Traffic von allen Apps im Arbeitsprofil an die entsprechende Verbindung weiterleiten

  • Unterstützung für die Segmentierung nach Unternehmen

    • Vorhandensein eines Arbeitsprofils auf dem Gerät erkennen
    • Prüfen auf Berechtigungen oder Routinganweisungen, die vom DPC bereitgestellt werden, den der IT-Administrator des Unternehmens verwendet

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

  • Fügt dem Tethering-Modul die meisten öffentlichen API- oder System-API-Klassen android.net.* hinzu

  • Das Tethering-Modul wird um Folgendes erweitert:

    • 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

  • VPN-Code aus dem Tethering-Modul verschoben

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

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

Implementierung

Damit 5G-Slicing auf einem Gerät unterstützt wird, 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 des 5G-Slicings:

  • trafficDescriptor: Gibt den Traffic-Descriptor an, der an das Modem gesendet wird
  • sliceInfo: Gibt Informationen für das Netzwerksegment an, das bei der Übergabe von EPDG zu 5G verwendet werden soll.
  • matchAllRuleAllowed: Gibt an, ob die Verwendung einer standardmäßigen URSP-Regel vom Typ „Alle übereinstimmen“ zulässig ist. Telephony setzt dies für Standardnetzwerke auf „wahr“, aber nicht für Slices. Die Regel "Alle Übereinstimmungen" wird auf Standardnetzwerke angewendet. Wenn eine App einen bestimmten Datensatz anfordert, der nicht verfügbar ist, wird der Datensatz 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, es sei denn, sie wird von der getHalDeviceCapabilities API als nicht unterstützt gemeldet.

Unternehmensanforderungen

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

  • Sorgen Sie dafür, dass vollständig verwaltete Geräte oder Mitarbeitergeräte, die mit einem Arbeitsprofil eingerichtet wurden, 5G-SA-fähig sind und Modems verwenden können, die die setupDataCall_1_6 API unterstützen.
  • Arbeiten Sie mit dem Mobilfunkanbieter zusammen, um die Slice-Einrichtung und die Leistung oder SLA-Eigenschaften zu konfigurieren.

5G-Slicing auf Geräten mit einem Arbeitsprofil aktivieren

Bei Geräten, die mit Arbeitsprofilen eingerichtet sind, ist 5G Network Slicing in AOSP standardmäßig deaktiviert. Zum Aktivieren der Netzwerkaufteilung können IT-Administratoren des Unternehmens die Weiterleitung von Traffic von Apps im Arbeitsprofil zum Unternehmensnetzwerksegment für einzelne Mitarbeiter über den EMM-DPC aktivieren oder deaktivieren. Dieser verwendet die Methode setPreferentialNetworkServiceEnabled in der DevicePolicyManager (DPM) API (in Android 12 eingeführt).

EMM-Anbieter mit benutzerdefinierten DPCs müssen die DevicePolicyManager API einbinden, um Unternehmenskunden zu unterstützen.

URSP-Regeln

Dieser Abschnitt enthält Informationen für Mobilfunkanbieter zum Konfigurieren von URSP-Regeln für verschiedene Slice-Kategorien, darunter Enterprise, CBS, Low Latency und High Bandwidth Traffic. Bei der Konfiguration von URSP-Regeln für verschiedene Sliver-Kategorien müssen Mobilfunkanbieter die folgenden Android-spezifischen Werte verwenden.

ID Wert Beschreibung
Betriebssystem-ID 97a498e3-fc92-5c94-8986-0333d06e4e47 Die OSId für Android ist eine UUID der Version 5, die mit dem Namespace-ISO-OID-Element und dem Namen „Android“ generiert wird.

Mobilfunkanbieter müssen URSP-Regeln für jeden Slice-Traffic mit der Komponente „Traffic-Descriptor“ als „OS-ID + OS-App-ID-Typ“ konfigurieren. Beispielsweise muss der Slice "ENTERPRISE" den Wert 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 haben. Dieser Wert ist eine Konkatenierung der OS-ID, der Länge der OSApp-ID (0x0A) und der OSApp-ID. Weitere Informationen zum Komponententyp des Traffic-Descriptors 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
UNTERNEHMEN 0x454E5445525052495345 Die OSAppId ist eine Byte-Array-Darstellung des Strings „ENTERPRISE“.
ENTERPRISE2 0x454E544552505249534532 Die OSAppId ist eine Bytearray-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 Bytearray-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 Bytearray-Darstellung des Strings „PRIORITIZE_BANDWIDTH“.

Beispiele für URSP-Regeln

Die folgenden Tabellen enthalten Beispiele für URSP-Regeln für Unternehmen, CBS, niedrige Latenz, hohe Bandbreite und Standard-Traffic.

Unternehmen 1

Enterprise 1 wird ab Android 12 unterstützt. Im folgenden Beispiel wird eine URSP-Regel für ENTERPRISE1-Traffic verwendet:

URSP-Regel 1 (enterprise1)
Vorrang 1 (0x01)
Verkehrsbeschreibung 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Routenauswahl-Beschreibung 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN Enterprise
Routenauswahl-Beschreibung 2
Vorrang 2 (0x02)
Komponente 1: DNN Unternehmen

Enterprise 2

Enterprise 2 wird ab Android 13 unterstützt. Im folgenden Beispiel wird eine URSP-Regel für ENTERPRISE2-Traffic verwendet:

URSP-Regel 2 (enterprise2)
Vorrang 2 (0x02)
Verkehrsbeschreibung 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532
Routenauswahl-Deskriptor 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN Unternehmen2
Routenauswahl-Beschreibung 2
Vorrang 2 (0x02)
Komponente 1: DNN Unternehmen2

Enterprise 3

Support für Enterprise 3 ist ab Android 13 verfügbar. Im folgenden Beispiel wird eine URSP-Regel für ENTERPRISE3-Traffic verwendet:

URSP-Regel 3 (enterprise3)
Vorrang 3 (0x03)
Traffic-Deskriptor Nr. 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533
Routenauswahl-Beschreibung 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN enterprise3
Routenauswahl-Beschreibung 2
Vorrang 2 (0x02)
Komponente 1: DNN Unternehmen3

Enterprise 4

Enterprise 4 wird ab Android 13 unterstützt. Im Folgenden finden Sie ein Beispiel für eine URSP-Regel für ENTERPRISE4-Traffic:

URSP-Regel 4 (enterprise4)
Vorrang 4 (0x04)
Verkehrsbeschreibung 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
Routenauswahl-Deskriptor 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN Unternehmen4
Routenauswahl-Deskriptor 2
Vorrang 2 (0x02)
Komponente 1: DNN enterprise4

Enterprise 5

Support für Enterprise 5 ist ab Android 13 verfügbar. Im folgenden Beispiel wird eine URSP-Regel für ENTERPRISE5-Traffic verwendet:

URSP-Regel 5 (Unternehmen5)
Vorrang 5 (0x05)
Verkehrsbeschreibung 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
Routenauswahl-Deskriptor 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN enterprise5
Routenauswahl-Beschreibung 2
Vorrang 2 (0x02)
Komponente 1: DNN enterprise5

CBS

CBS wird ab Android 13 unterstützt. Das folgende Beispiel zeigt eine URSP-Regel für CBS-Traffic:

URSP-Regel 6 (CBS)
Vorrang 6 (0x06)
Verkehrsbeschreibung 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 0x97A498E3FC925C9489860333D06E4E4703434253
Routenauswahl-Deskriptor 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN cbs
Routenauswahl-Beschreibung 2
Vorrang 2 (0x02)
Komponente 1: DNN cbs

Niedrige Latenz

Die Funktion „Niedrige Latenz“ wird ab Android 13 unterstützt. Im Folgenden sehen Sie ein Beispiel für eine URSP-Regel für Traffic vom Typ LOW_LATENCY:

URSP-Regel 7 (niedrige Latenz)
Vorrang 7 (0x07)
Traffic-Deskriptor Nr. 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
Routenauswahl-Beschreibung 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN Latenz
Routenauswahl-Beschreibung 2
Vorrang 2 (0x02)
Komponente 1: DNN Latenz

Hohe Bandbreite

Die Unterstützung für eine hohe Bandbreite ist ab Android 13 verfügbar. Im folgenden Beispiel wird eine URSP-Regel für HIGH_BANDWIDTH-Traffic verwendet:

URSP-Regel 8 (hohe Bandbreite)
Vorrang 8 (0x08)
Verkehrsbeschreibung 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
Routenauswahl-Beschreibung 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN Bandbreite
Routenauswahl-Beschreibung 2
Vorrang 2 (0x02)
Komponente 1: DNN Bandbreite

Standard

URSP-Regel 9 (Standard)
Vorrang 9 (0x09)
Verkehrsbeschreibung 1
match-all –
Routenauswahl-Beschreibung 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY

Testen

Mit dem folgenden manuellen Test können Sie die 5G-Netzwerkaufteilung testen.

So richten Sie ein Gerät zum Testen ein:

  1. Achten Sie darauf, dass die URSP-Richtlinie mit einer nicht standardmäßigen Regel konfiguriert ist, die mit der Unternehmenskategorie übereinstimmt, und dass der entsprechende Routenauswahldeskriptor die Unternehmenskategorie dem Unternehmenssegment zuordnet. Außerdem muss eine Standardregel den Traffic an das Standard-Internetsegment weiterleiten.

  2. Auf dem Gerät muss ein Arbeitsprofil konfiguriert sein.

  3. Network Slicing über die DPC aktivieren

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

  1. Prüfen Sie, ob eine PDU-Sitzung mit dem Unternehmens-Slice hergestellt wird (z. B. durch Verwendung einer bestimmten IP-Adresse) und ob Apps im Arbeitsprofil diese PDU-Sitzung verwenden.
  2. Prüfen Sie, ob eine separate PDU-Sitzung mit dem Standard-Internet-Speilraum eingerichtet ist und ob Apps im privaten Profil die PDU-Sitzung verwenden.

5G-Slicing-Upselling

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

Die Upselling-Funktion für die 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 das Snippet bereitgestellt und im Mobilfunkanbieternetzwerk verfügbar ist.

Mobilfunkanbieter können das Verhalten der 5G-Slicing-Upselling-Funktion mithilfe von Anbieterkonfigurationen anpassen. Diese steuern, ob Kaufanfragen gestellt werden können, wann Apps Premium-Funktionen anfordern dürfen und wie lange das Telefonie-Framework auf Antworten des Nutzers oder des Netzwerks wartet.

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

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

Kaufvorgang für 5G-Slicing-Upselling

Abbildung 2. Kaufvorgang für 5G-Slicing-Upselling

TS.43-Berechtigungsverfahren

Wenn ein Nutzer erweiterte Netzwerkfunktionen anfordert, fordert das Telephony Framework die Konfiguration der Dienstberechtigung für die angeforderte Premiumfunktion 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 Segmentkauf:

Berechtigungsstatus

Taste: EntitlementStatus

Typ: int

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

Status der Nutzerverwaltung

Taste: ProvStatus

Typ: int

Unterstützte Werte: 0 (nicht bereitgestellt), 1 (bereitgestellt), 2 (nicht verfügbar), 3 (in Bearbeitung)

Das Telephony Framework verwendet die Kombination aus Berechtigungsstatus und Bereitstellungsstatus, um den aktuellen Kaufstatus des Streifens zu bestimmen. Das Ergebnis kann einer der folgenden Werte sein:

Wenn der Berechtigungsstatus 1 (aktiviert) und der Bereitstellungsstatus 0 (nicht bereitgestellt) ist, zeigt das Telephony-Framework dem Nutzer eine Upselling-Benachrichtigung an, um den Boost über die Webview des Mobilfunkanbieters zu kaufen. In der folgenden Tabelle wird das Verhalten des Telefonie-Frameworks für verschiedene Kombinationen von Nutzerverwaltungs- und Berechtigungsstatuswerten beschrieben.

Bereitstellungsstatus
Nicht bereitgestellt (0) Bereitgestellt (1) Nicht verfügbar (2) In Bearbeitung (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) Fehler des Mobilfunkanbieters Fehler des Mobilfunkanbieters In Bearbeitung In Bearbeitung
Im Lieferumfang enthalten (4) Fehler des Mobilfunkanbieters Bereits gekauft Bereits gekauft Fehler des Mobilfunkanbieters

Felder für den Servicefluss

In der TS.43-Antwort werden die URL, die Nutzerdaten und der Inhaltstyp angegeben, um das Webview-Verhalten für den Kauf über einen Mobilfunkanbieter anzupassen. Wenn der Inhaltstyp nicht angegeben ist, wird die URL als GET-Anfrage geladen. Sind die Nutzerdaten vorhanden, werden sie als Abfrageparameter an die URL angehängt, z. B. https://www.android.com?encodedValue=Base64EncodedUserData. Ist sie nicht vorhanden, 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 (wenn 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)

Mobilfunkanbieterkonfigurationen

Im Folgenden sind die Mobilfunkanbieterkonfigurationen aufgeführt, mit denen sich das Verhalten der Upselling-Funktion für 5G-Slicing anpassen lässt.

KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY

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

Unter Android 14 wird nur PREMIUM_CAPABILITY_PRIORITIZE_LATENCY unterstützt.

KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT

Die maximale Häufigkeit, mit der dem Nutzer die Upselling-Benachrichtigung für Käufe pro Tag angezeigt wird. Wenn das Tageslimit erreicht ist, wird die Upselling-Benachrichtigung nicht angezeigt und Kaufanfragen (einschließlich Berechtigungsserveranfragen) werden bis Mitternacht des nächsten Tages gedrosselt. Kaufanfragen, die nach Erreichen des Tageslimit gesendet werden, schlagen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED fehl.

KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT

Die maximale Anzahl der monatlichen Anzeigen der Kauf-Upselling-Benachrichtigung für den Nutzer. Wenn das monatliche Maximum erreicht ist, wird die Upselling-Benachrichtigung nicht angezeigt und Kaufanfragen (einschließlich Berechtigungsanfragen) werden bis zum ersten Tag des Folgemonats gedrosselt. Kaufanfragen, die nach Erreichen des monatlichen Höchstwerts gesendet werden, schlagen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED fehl.

KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING

Die URL für den Kauf beim Mobilfunkanbieter, die dem Nutzer angezeigt werden soll, wenn er auf die Upselling-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 Mobilfunkanbieterkonfiguration 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 Premiumfunktionen 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) gesendet werden. Wenn false, können Kaufanfragen nur über NR gesendet 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 Zeitspanne, während der die Kauf-Upselling-Benachrichtigung 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 Zeit, in der nachfolgende Kaufanfragen gedrosselt werden sollen, nachdem ein Fehler aufgrund einer Zeitüberschreitung oder einer Nutzerstornierung aufgetreten ist. Wenn der Nutzer nicht innerhalb des unter KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG festgelegten Zeitlimits auf die Upselling-Benachrichtigung für Käufe klickt oder die Benachrichtigung abbricht oder schließt, wird dieser Backoff-Timer gestartet. Solange dieser Timer aktiv ist, schlagen Kaufanfragen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED fehl.

KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Die Zeitspanne, nach der nachfolgende Kaufanfragen nach einem Fehler aufgrund des Mobilfunkanbieters oder des Netzwerks gedrosselt werden sollten. Wenn die Berechtigungsprüfung fehlschlägt, die URL nicht verfügbar ist oder die Kauf-URL des Mobilfunkanbieters auf einen Fehler hinweist, 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

Der Zeitraum, in dem das Netzwerk eine Segmentierungskonfiguration für die Erwerb einer Premium-Funktion einrichten muss. Während dieses Zeitraums werden nachfolgende Kaufanfragen blockiert und das Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP zurückgegeben. Wenn das Netzwerk die Segmentierungskonfiguration nicht rechtzeitig einrichten kann, können Apps den Kauf von Premium-Funktionen noch einmal anfordern. In 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 verwenden, die auf der JavaScript-Schnittstelle DataBoostWebServiceFlow auf ihrer Kaufwebsite verfügbar sind, um mit der Slice-Kauf-App zu kommunizieren.

Die gewünschte Premiumfunktion kann über die Methode getRequestedCapability() von der Mobilfunkanbieterwebsite abgerufen werden.

Wenn der Kauf erfolgreich ist, muss die Website des Netzbetreibers die App für den Segmentkauf über notifyPurchaseSuccessful() oder notifyPurchaseSuccessful(duration) informieren, wobei duration ein optionaler Parameter ist, der die beabsichtigte Dauer des Segments angibt.

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

Wenn eine dieser Antwortmethoden nicht aufgerufen wird, gilt der Kauf nicht als abgeschlossen und die Kaufanfrage läuft möglicherweise ab.

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

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