5G-Netzwerk-Slicing

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.

5G-Netzwerk-Slicing-Komponenten

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 wie NetworkCallback , getActiveNetwork und getNetworkCapabilities 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:

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

  2. Stellen Sie sicher, dass auf dem Gerät ein Arbeitsprofil konfiguriert ist.

  3. Aktivieren Sie die Verwendung von Network Slicing über den DPC

Gehen Sie wie folgt vor, um das 5G-Netzwerk-Slicing-Verhalten zu testen:

  1. 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.
  2. 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:

5G-Slicing-Upselling-Kauffluss

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:

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 entsprechende NetworkCapabilities.NetCapability Klasse. Wenn eine Premium-Funktion angefordert wird und diese 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 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. Bei false können Kaufanfragen nur über NR gestellt werden und 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, 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 Ergebnis PURCHASE_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:

Wenn der Kauf abgeschlossen ist, muss der Netzbetreiber die URSP-Regeln mit dem PRIORITIZE_LATENCY Slice auf dem Gerät des Benutzers aktualisieren.