5G-Netzwerkaufteilung

Für Geräte mit Android 12 oder höher, Android bietet Unterstützung für 5G-Netzwerk-Slicing, die Nutzung von Netzwerkvirtualisierungen für Einzelne Netzwerkverbindungen in mehrere separate virtuelle Verbindungen aufteilen die verschiedenen Arten von Traffic unterschiedliche Ressourcenmengen bereitstellen. 5G Netzwerk-Slicing ermöglicht es Netzbetreibern, einen Teil des Netzwerks bestimmte Funktionen für ein bestimmtes Kundensegment bereitstellen. Mit Android 12 nach den 5G-Netzwerk-Slicing-Funktionen, für ihre Unternehmenskunden:

Unternehmensgeräte-Slicing für vollständig verwaltete Geräte

Für Unternehmen, die vollständig verwaltet Mitarbeitern Unternehmensgeräte bereitstellen, können Netzwerkanbieter ihnen oder mehr aktive Unternehmensnetzwerksegmente, in denen Traffic auf den Unternehmensgeräten an die weitergeleitet wird. Ab Android 12 können Mobilfunkanbieter Unternehmenssegmente über URSP-Regeln bereitstellen, anstatt sie einzurichten über APNs.

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

Für Unternehmen, die die Arbeitsprofil können Geräte mit Android 12 über alle Apps im Arbeitsprofil zu einem Unternehmensnetzwerk-Slice. Diese Funktion kann von Unternehmen aktiviert werden. durch eine Device Policy Controller (DPC):

Die Arbeitsprofillösung bietet eine automatische Ebene der Authentifizierung Zugriffskontrolle, die Unternehmen benötigen, um sicherzustellen, dass nur Datenverkehr Unternehmens-Apps im Arbeitsprofil werden an das Unternehmensnetzwerk-Slice weitergeleitet. Apps im Arbeitsprofil müssen nicht geändert werden, um die Unternehmensnetzwerk.

Funktionsweise von 5G-Netzwerk-Slicing in AOSP

Android 12 unterstützt jetzt die 5G-Netzwerkaufteilung durch Ergänzungen der Telefonie-Codebasis in AOSP und Tethering-Modul um bestehende Verbindungs-APIs einzubinden, die für das Netzwerk-Slicing erforderlich sind.

Die Android-Telefonieplattform bietet HAL- und Telefonie-APIs zur Unterstützung Segmentierung basierend auf Netzwerkanfragen, die vom Core-Netzwerkcode und 5G gesendet werden die Segmentierungsfunktionen im Modem. In Abbildung 1 werden die Komponenten von 5G beschrieben. Netzwerk-Slicing-Funktion nutzen.

5G-Netzwerk-Slicing-Komponenten

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

Die Telefonie- und Konnektivitätsplattform unterstützt:

  • Netzwerkanfragen für Slice-Kategorien in Traffic-Deskriptoren die dann für den URSP-Traffic-Abgleich und die Weiterleitung an das Modem übergeben werden. Auswahl
  • Es wird auf das Standardnetzwerk zurückgegriffen, wenn das Unternehmensnetzwerk-Slice nicht verfügbar
  • Traffic von allen Apps im Arbeitsprofil an den entsprechende Verbindung

  • Unternehmens-Slicing unterstützen

    • Vorhandensein eines Arbeitsprofils auf dem Gerät erkennen
    • Es wird nach Berechtigungen oder Routenplänen gesucht, die über das Vom IT-Administrator des Unternehmens verwendeter DPC

Für den Hauptnetzwerkdienst wurden die folgenden Änderungen am Tethering vorgenommen in Android 12:

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

  • 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 zum Tethering-Modul hinzu:

  • Anfragen von Apps für Netzwerkverbindungen erhalten
  • Wenn Sie Systemanfragen erhalten (z. B. „Platzieren Sie diese Apps auf einem Unternehmenssegment"; eingeführt, die mit Android 12 eingeführt wurde.)
  • Das Senden von Anfragen vom System an den Telefoniecode, der versucht, Netzwerke oder Slices über die HAL API und das Modem einrichten
  • Informationen zur Weiterleitung des Traffics auf App-Basis (eingeführt in Android 12)
  • Apps zu informieren, was mit ihrem Netzwerkverkehr passiert, ConnectivityManager APIs wie NetworkCallback, getActiveNetwork, getNetworkCapabilities.

Implementierung

Damit 5G-Slicing auf einem Gerät möglich ist, muss das Gerät ein Modem haben, das IRadio 1.6 HAL mit der setupDataCall_1_6 der API erstellen. Diese API richtet eine Datenverbindung ein und enthält die folgenden Parameter zur Unterstützung des 5G-Slicings:

  • trafficDescriptor: Gibt die an das Modem gesendete Traffic-Deskriptor an
  • sliceInfo: Gibt Informationen für das Netzwerksegment an, das in verwendet werden soll Fall von EPDG- an 5G-Umstellung
  • matchAllRuleAllowed: gibt an, ob ein standardmäßiger Abgleich mit allen URSP verwendet wird zulässig ist. Für Telefonie wird dieser Wert für Standardnetzwerke auf „true“ gesetzt aber nicht für Slices. Die Regel "Alle Übereinstimmungen" wird auf die Standardeinstellung angewendet Netzwerken. Wenn eine App ein bestimmtes Segment anfordert, verfügbar ist, wird das entsprechende Segment als nicht verfügbar gemeldet. Für Unternehmens-Apps kann das Telefonie-Framework auf die Standardeinstellungen wenn das Unternehmensnetzwerk nicht verfügbar ist.

Modems müssen außerdem die getSlicingConfig es sei denn, sie wird vom getHalDeviceCapabilities der API erstellen.

Unternehmensanforderungen

Im Folgenden werden die Anforderungen für Unternehmen zur Verwendung von 5G-Netzwerkaufteilung beschrieben. auf Geräten in einer Android Enterprise-Bereitstellung.

  • Sicherstellen, dass auf vollständig verwalteten Geräten oder auf Mitarbeitergeräten ein Arbeitsprofil eingerichtet ist sind 5G-SA-fähig und haben Modems, die den setupDataCall_1_6 der API erstellen.
  • Arbeiten Sie mit dem Mobilfunkanbieter zusammen, um die Slice-Einrichtung und -Leistung oder das SLA zu besprechen. Eigenschaften.

5G-Slicing auf Geräten mit Arbeitsprofil aktivieren

Bei Geräten mit Arbeitsprofilen ist die 5G-Netzwerkaufteilung wie folgt deaktiviert: Standardeinstellung in AOSP. Zum Aktivieren der Netzwerksegmentierung können IT-Administratoren von Unternehmen die Traffic-Weiterleitung von der Arbeitsprofil-App zum Unternehmensnetzwerksegment auf einem pro Mitarbeiter über den EMM DPC, der die setPreferentialNetworkServiceEnabled im 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 zur Konfiguration von URSP-Regeln für Slice-Kategorien wie Enterprise, CBS, und Traffic mit hoher Bandbreite. Beim Konfigurieren von URSP-Regeln für Slice-Kategorien unterscheiden, müssen Mobilfunkanbieter die folgenden Android-spezifischen Werte.

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 generiert wurde OID und der Name „Android“.

Mobilfunkanbieter müssen URSP-Regeln für jeden Slice-Traffic mit dem Traffic konfigurieren Deskriptorkomponente als „OS-ID + OS-App-ID-Typ“. Beispiel: „ENTERPRISE“ Segment muss den Wert von 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 Dieser Wert ist eine Verkettung aus OSId, der Länge der OSAppId (0x0A), und die OSAppId. Weitere Informationen zum Komponententyp „Traffic-Deskriptor“ finden Sie unter 3GPP TS 24.526 Tabelle 5.2.1.

In der folgenden Tabelle werden die OSAppId-Werte für verschiedene Slice-Kategorien beschrieben.

Segmentkategorie OSAppId (OS-App-ID) Beschreibung
UNTERNEHMEN 0x454E5445525052495345 Die OSAppId ist eine Byte-Array-Darstellung des Strings "ENTERPRISE".
UNTERNEHMEN2 0x454E544552505249534532 Die OSAppId ist eine Byte-Array-Darstellung des Strings "ENTERPRISE2".
UNTERNEHMEN3 0x454E544552505249534533 Die OSAppId ist eine Byte-Array-Darstellung des Strings "ENTERPRISE3".
UNTERNEHMEN4 0x454E544552505249534534 Die OSAppId ist eine Byte-Array-Darstellung des Strings "ENTERPRISE4".
UNTERNEHMEN5 0x454E544552505249534535 Die OSAppId ist eine Byte-Array-Darstellung des Strings "ENTERPRISE5".
CBS 0x434253 Die OSAppId ist eine Byte-Array-Darstellung der Zeichenfolge "CBS".
PRIORITIZE_LATENCY 0x5052494f524954495a455f4c4154454e4359 Die OSAppId ist eine Byte-Array-Darstellung des Strings "PRIORITIZE_LATENCY".
PRIORITIZE_BANDBREITE 0x5052494f524954495a455f42414e445749445448 Die OSAppId ist eine Byte-Array-Darstellung des Strings "PRIORITIZE_BANDWIDTH".

Beispiele für URSP-Regeln

In den folgenden Tabellen sehen Sie Beispiele für URSP-Regeln für Unternehmen. CBS, niedrige Latenz, hohe Bandbreite und Standard-Traffic.

Enterprise 1

Support für Enterprise 1 ist ab Android 12 verfügbar. Hier sehen Sie ein Beispiel für eine URSP-Regel für ENTERPRISE1-Traffic:

URSP-Regel 1 (Unternehmen1)
Vorrang 1 (0x01)
Traffic-Deskriptor Nr. 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Routenauswahl-Deskriptor 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN Enterprise
Routenauswahl-Deskriptor 2
Vorrang 2 (0x02)
Komponente 1: DNN Enterprise

Enterprise 2

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

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

Enterprise 3

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

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

Enterprise 4

Support für Enterprise 4 ist ab Android 13 verfügbar. Hier sehen Sie ein Beispiel für eine URSP-Regel für ENTERPRISE4-Traffic:

URSP-Regel 4 (enterprise4)
Vorrang 4 (0x04)
Traffic-Deskriptor Nr. 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 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 Unternehmen4

Enterprise 5

Support für Enterprise 5 ist ab Android 13 verfügbar. Hier sehen Sie ein Beispiel für eine URSP-Regel für ENTERPRISE5-Traffic:

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

CBS

CBS wird ab Android 13 unterstützt. Hier sehen Sie ein Beispiel für eine URSP-Regel für CBS-Traffic:

URSP-Regel 6 (CBS)
Vorrang 6 (0x06)
Traffic-Deskriptor Nr. 1
Betriebssystem-ID + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E4703434253
Routenauswahl-Deskriptor 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN cbs
Routenauswahl-Deskriptor 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 + Betriebssystem-App-ID-Typ 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
Routenauswahl-Deskriptor 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ
Komponente 2: DNN Latenz
Routenauswahl-Deskriptor 2
Vorrang 2 (0x02)
Komponente 1: DNN Latenz

Hohe Bandbreite

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

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

Standard

URSP-Regel 9 (Standard)
Vorrang 9 (0x09)
Traffic-Deskriptor Nr. 1
Match-All –
Routenauswahl-Deskriptor 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYJJJJ

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 die entsprechende Routenauswahl Der Deskriptor ordnet die Unternehmenskategorie dem Enterprise-Slice zu. und Standardregel, die Traffic an das Standard-Internet-Slice weiterleitet.

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

  3. Netzwerksegmentierung über den DPC aktivieren

So testen Sie die 5G-Netzwerkaufteilung:

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

Upselling für 5G-Slicing

Die Upselling-Funktion für 5G-Slicing, verfügbar von Mit Android 14-QPR1 können Mobilfunkanbieter erweiterte Netzwerke zur Verfügung stellen (Latenz und Bandbreite) durch 5G-Netzwerk-Slicing den Nutzern zur Verfügung stellen.

Für die Upselling-Funktion für 5G-Slicing wird die TS.43-Antwort des Mobilfunkanbieters verwendet. Berechtigungsserver, um den Kaufvorgang zu steuern. Mobilfunkanbieter können die Antwort auf die URL für die WebView für den Kauf angeben, zusätzliche Daten an den WebView und geben an, ob das Slice bereitgestellt und im

Mobilfunkanbieter können das Verhalten der 5G-Slicing-Upselling-Funktion anpassen, indem sie Mobilfunkanbieter-Konfigurationen, die steuern, ob Kaufanfragen wann Apps Premium-Funktionen anfordern dürfen und wie lange Das Telefonie-Framework wartet auf Antworten des Nutzers oder des Netzwerks.

Die 5G-Slicing-Upselling-Funktion bietet eine Schnittstelle, DataBoostWebServiceFlow, um die Kommunikation zwischen Android und der WebView des Mobilfunkanbieters zu ermöglichen.

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

Upselling-Kaufabwicklung mit 5G-Slicing

Abbildung 2: Upselling-Kaufprozess mit 5G-Slicing

TS.43-Berechtigungsprozess

Wenn ein Nutzer erweiterte Netzwerkfunktionen anfordert, fordert das Framework die Konfiguration der Dienstberechtigung für die angeforderte Premium-Funktionen. Wenn die TS.43-Antwort gültig ist, verwendet das Telefonie-Framework die Felder aus der HTTP-Antwort für die Kaufanfrage.

Felder für den Slice-Kauf

Die TS.43-Berechtigungskonfiguration umfasst den folgenden Slice-Kauf Felder:

Berechtigungsstatus

Taste: EntitlementStatus

Typ: int

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

Status der Nutzerverwaltung

Taste: ProvStatus

Typ: int

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

Das Telefonie-Framework nutzt die Kombination aus Berechtigungsstatus und Bereitstellungsstatus, um den aktuellen Status des Segmentkaufs zu ermitteln. Das Ergebnis Folgende Werte sind möglich:

Wenn der Berechtigungsstatus 1 (aktiviert) und der Bereitstellungsstatus 0 ist (nicht bereitgestellt), zeigt das Telefonie-Framework eine Upselling-Benachrichtigung an Nutzer können die Aktion über WebView des Mobilfunkanbieters kaufen. In der folgenden Tabelle beschreibt das Verhalten des Telefonie-Frameworks für verschiedene Kombinationen von Nutzerverwaltungs- und Berechtigungsstatuswerte.

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
Inkompatibel (2) Fehlgeschlagen Fehlgeschlagen Fehlgeschlagen Fehlgeschlagen
Bereitstellung (3) Fehler des Mobilfunkanbieters Fehler des Mobilfunkanbieters In Bearbeitung In Bearbeitung
Enthalten (4) Fehler des Mobilfunkanbieters Bereits gekauft Bereits gekauft Fehler des Mobilfunkanbieters

Service-Flow-Felder

Die TS.43-Antwort gibt die URL, die Nutzerdaten und den Inhaltstyp an, die angepasst werden sollen. das WebView-Verhalten bei Käufen über den Mobilfunkanbieter. Wenn der Inhaltstyp nicht angegeben ist, Die URL wird als GET-Anfrage geladen. Sind die Nutzerdaten vorhanden, werden sie an den URL als Suchparameter (z. B. https://www.android.com?encodedValue=Base64EncodedUserData); Und wenn es 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 gesendet, und die Nutzerdaten (decodiert, wenn sie mit Base64 codiert sind) werden als die Daten für die POST-Anfrage.

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)

Mobilfunkanbieter-Konfigurationen

Im Folgenden sind die Mobilfunkanbieter-Konfigurationen aufgeführt, die zur Anpassung des der 5G-Slicing-Upselling-Funktion.

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 entsprechenden NetworkCapabilities.NetCapability . Wenn eine Premium-Funktion angefordert wird, die hier nicht enthalten ist Konfiguration ist, schlägt die Kaufanfrage mit dem CARRIER_DISABLED Ergebnis.

In Android 14 werden nur PREMIUM_CAPABILITY_PRIORITIZE_LATENCY wird unterstützt.

KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT

Die maximale Häufigkeit, mit der die Kauf-Up-Selling-Benachrichtigung täglich Nutzenden. Wenn das Tageslimit erreicht ist, wird die Upselling-Benachrichtigung nicht angezeigt und Kaufanfragen (einschließlich Anfragen von Berechtigungsservern) werden gedrosselt, bis um Mitternacht des nächsten Tages. Kaufanfragen, die nach dem Tageslimit erfolgen mit dem Parameter PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED Ergebnis.

KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT

Die maximale Häufigkeit, mit der die Upselling-Benachrichtigung für Käufe angezeigt wird für den Nutzer. Wenn das monatliche Maximum erreicht ist, wird die Upselling-Benachrichtigung nicht angezeigt. Kauf- und Kaufanfragen (einschließlich Anfragen von Berechtigungsservern) werden gedrosselt. bis zum ersten Tag des Folgemonats. Kaufanfragen, die nach dem monatliches Maximum erreicht wird, schlagen Sie mit dem PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED Ergebnis.

KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING

Die URL für den Ersatz des Mobilfunkanbieters, die dem Nutzer angezeigt wird, wenn er auf das Upselling-Benachrichtigung. Wenn die Kauf-URL nicht in der TS.43-Antwort gefunden wird vom Berechtigungsserver gesendet wird, wird stattdessen dieser Wert verwendet. Wenn weder die URL aus die TS.43-Antwort oder die Konfiguration des Mobilfunkanbieters gültig ist, scheitert mit der PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED Ergebnis.

KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL

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

KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG

Die Zeitspanne, in der dem Nutzer die Up-Selling-Benachrichtigung für den Kauf angezeigt wird, bevor wird er automatisch abgebrochen. Wird die Benachrichtigung abgebrochen, werden nachfolgende Anfragen gedrosselt werden und mit dem Fehler PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED Ergebnis.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Der Zeitraum, nach dem nachfolgende Kaufanfragen gedrosselt werden sollen Fehler aufgrund von Zeitüberschreitung oder Abbruch durch den Nutzer. Wenn der Nutzer nicht auf der Upselling-Benachrichtigung innerhalb des durch KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG oder wenn sie die Benachrichtigung abbrechen oder verwerfen, startet dieser Backoff-Timer. Während wenn dieser Timer aktiv ist, schlagen Kaufanfragen mit dem PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED Ergebnis.

KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Der Zeitraum, nach dem nachfolgende Kaufanfragen gedrosselt werden sollen aufgrund des Netzbetreibers oder Netzwerks aufgetreten ist. Wenn die Berechtigungsprüfung fehlschlägt, wird die URL nicht verfügbar ist oder die Kauf-URL des Mobilfunkanbieters auf einen Fehler hinweist, erfolgt der Backoff Timer startet. Während dieser Timer aktiv ist, schlagen Kaufanfragen fehl: die PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED Ergebnis.

KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG

Der Zeitraum, in dem das Netzwerk eine Aufteilungskonfiguration einrichten muss um eine Premium-Funktion zu erwerben. Während dieses Zeitraums gilt ein nachfolgender Kauf -Anfragen blockiert werden und den Fehler PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP Ergebnis. Wenn das Netzwerk die Aufteilungskonfiguration nicht rechtzeitig einrichten kann, anfragen, um wieder Premium-Funktionen zu erwerben. Bei der Telefonie spielt es keine Rolle, Kauf abgeschlossen ist, bis 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 Netzwerk-Boost-Benachrichtigung klickt, wird ein WebView-Objekt mit wird dem Nutzer die Kauf-URL des Mobilfunkanbieters angezeigt. Mobilfunkanbieter können die APIs verwenden im DataBoostWebServiceFlow JavaScript-Schnittstelle auf der Website des Unternehmens, um mit dem Slice zu kommunizieren Kauf-App.

Die gewünschte Premium-Funktion kann auf der Website des Netzbetreibers über die Methode getRequestedCapability()

Wenn der Kauf erfolgreich ist, muss das Segment auf der Website des Netzbetreibers informiert werden. App kaufen über notifyPurchaseSuccessful() oder notifyPurchaseSuccessful(duration), wobei duration ein optionaler Parameter ist , der die beabsichtigte Dauer des Slice angibt.

Wenn der Kauf nicht erfolgreich ist, muss das Segment auf der Website des Netzbetreibers benachrichtigt werden. die App mit der Methode notifyPurchaseFailed(code, reason) kaufen, wobei code ist der Fehlercode, der den Grund für den Fehler angibt, und reason ist der menschenlesbarer Grund für den Fehler, wenn der Fehlercode unbekannt ist.

Wenn keine dieser Antwortmethoden aufgerufen wird, wird der Kauf nicht als abgeschlossen betrachtet wird, wodurch das Zeitlimit für die Kaufanfrage überschritten wird.

Nachfolgend sind die gültigen Fehlercodes aufgeführt, die von der Website des Transportunternehmens zurückgegeben werden können bei Kauffehler:

Nach Abschluss des Kaufs muss der Mobilfunkanbieter die URSP-Regeln mit dem Slice PRIORITIZE_LATENCY für das Gerät des Nutzers.