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. Android 12 bietet die folgenden 5G-Funktionen für die Netzwerksegmentierung für Unternehmen, die Netzbetreiber ihren Unternehmenskunden 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 für Arbeitsprofile 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 Lösung für Arbeitsprofile bietet eine automatische Authentifizierungs- und Zugriffssteuerung, die Unternehmen benötigen, um sicherzustellen, dass nur Traffic von Unternehmens-Apps im Arbeitsprofil an das Unternehmensnetzwerksegment weitergeleitet 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.
Abbildung 1: 5G-Netzwerk-Slicing-Architektur in AOSP
Die Telefonie- und Konnektivitätsplattform unterstützt:
- Netzwerkanfragen für Slice-Kategorien in Traffic-Beschreibungen umwandeln, die dann an das Modem zur URSP-Traffic-Übereinstimmung und Routenauswahl ü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:
- Dem Tethering-Modul werden die meisten öffentlichen oder System-API-Klassen von
android.net.*hinzugefügt. 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.javaf/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:
- Empfang von Anfragen von Apps für Netzwerkverbindungen
- 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 über
ConnectivityManagerAPIs wieNetworkCallback,getActiveNetworkundgetNetworkCapabilitiesdarüber informieren, 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 von 5G-Slicing:
trafficDescriptor: Gibt den Traffic-Descriptor an, der an das Modem gesendet wirdsliceInfo: Gibt Informationen für das Netzwerksegment an, das bei der Übergabe von EPDG an 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 übereinstimmen“ 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.
Anforderungen für Unternehmen
Im Folgenden werden die Anforderungen für Unternehmen beschrieben, die 5G-Netzwerk-Slicing auf Geräten in einer Android-Unternehmensumgebung verwenden möchten.
- Vollständig verwaltete Geräte oder Mitarbeitergeräte, die mit einem Arbeitsprofil eingerichtet sind, müssen 5G SA-fähig sein und Modems mit der
setupDataCall_1_6API 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. Um Network Slicing zu aktivieren, können IT-Administratoren von Unternehmen das Weiterleiten von App-Traffic von Arbeitsprofilen an das Unternehmensnetzwerk-Slicing auf Mitarbeiterebene über die EMM-DPC aktivieren oder deaktivieren. Dabei wird die Methode setPreferentialNetworkServiceEnabled in der DevicePolicyManager (DPM) API (in Android 12 eingeführt) verwendet.
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 |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
Die OS-ID für Android ist eine UUID der Version 5, die mit der ISO-OID des Namespace 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. Der Wert für den Bereich „UNTERNEHMEN“ muss beispielsweise 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 sein.
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 Bytearray-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:YYYYYY |
| Komponente 2: DNN | Unternehmen |
| 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-Beschreibung 1 | |
| Vorrang | 1 (0x01) |
| Komponente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Komponente 2: DNN | enterprise2 |
| Routenauswahl-Beschreibung 2 | |
| Vorrang | 2 (0x02) |
| Komponente 1: DNN | enterprise2 |
Enterprise 3
Enterprise 3 wird ab Android 13 unterstützt. Im folgenden Beispiel wird eine URSP-Regel für ENTERPRISE3-Traffic verwendet:
| URSP-Regel 3 (enterprise3) | |
|---|---|
| Vorrang | 3 (0x03) |
| Verkehrsbeschreibung 1 | |
| Betriebssystem-ID + Typ der Betriebssystem-App-ID | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Routenauswahl-Beschreibung 1 | |
| Vorrang | 1 (0x01) |
| Komponente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Komponente 2: DNN | enterprise3 |
| Routenauswahl-Beschreibung 2 | |
| Vorrang | 2 (0x02) |
| Komponente 1: DNN | enterprise3 |
Enterprise 4
Enterprise 4 wird ab Android 13 unterstützt. Im folgenden Beispiel wird eine URSP-Regel für ENTERPRISE4-Traffic verwendet:
| URSP-Regel 4 (enterprise4) | |
|---|---|
| Vorrang | 4 (0x04) |
| Verkehrsbeschreibung 1 | |
| Betriebssystem-ID + Typ der Betriebssystem-App-ID | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Routenauswahl-Beschreibung 1 | |
| Vorrang | 1 (0x01) |
| Komponente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Komponente 2: DNN | enterprise4 |
| Routenauswahl-Beschreibung 2 | |
| Vorrang | 2 (0x02) |
| Komponente 1: DNN | enterprise4 |
Enterprise 5
Enterprise 5 wird ab Android 13 unterstützt. Im folgenden Beispiel wird eine URSP-Regel für ENTERPRISE5-Traffic verwendet:
| URSP-Regel 5 (enterprise5) | |
|---|---|
| Vorrang | 5 (0x05) |
| Verkehrsbeschreibung 1 | |
| Betriebssystem-ID + Typ der Betriebssystem-App-ID | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Routenauswahl-Beschreibung 1 | |
| Vorrang | 1 (0x01) |
| Komponente 1: S-NSSAI | SST:XX SD:YYYYYY |
| 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-Beschreibung 1 | |
| Vorrang | 1 (0x01) |
| Komponente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Komponente 2: DNN | cbs |
| Routenauswahl-Beschreibung 2 | |
| Vorrang | 2 (0x02) |
| Komponente 1: DNN | cbs |
Niedrige Latenz
Die Unterstützung für eine geringe Latenz ist unter Android 13 und höher verfügbar. Im Folgenden finden Sie ein Beispiel für eine URSP-Regel für LOW_LATENCY-Traffic:
| URSP-Regel 7 (niedrige Latenz) | |
|---|---|
| Vorrang | 7 (0x07) |
| Verkehrsbeschreibung 1 | |
| Betriebssystem-ID + Typ der Betriebssystem-App-ID | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Routenauswahl-Beschreibung 1 | |
| Vorrang | 1 (0x01) |
| Komponente 1: S-NSSAI | SST:XX SD:YYYYYY |
| 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:YYYYYY |
| 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
Führen Sie zum Testen von 5G Network Slicing den folgenden manuellen Test aus.
So richten Sie ein Gerät für den Test ein:
Achten Sie darauf, dass die URSP-Richtlinie mit einer nicht standardmäßigen Regel konfiguriert ist, die der Unternehmenskategorie entspricht, und dass der entsprechende Routenauswahl-Beschreibung die Unternehmenskategorie dem Unternehmens-Slice zuordnet. Außerdem muss eine Standardregel vorhanden sein, die den Traffic an das Standard-Internet-Slice weiterleitet.
Achten Sie darauf, dass auf dem Gerät ein Arbeitsprofil konfiguriert ist.
Netzwerk-Slicing über das DPC aktivieren
So testen Sie das Verhalten von 5G-Netzwerk-Slicing:
- 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.
- Prüfen Sie, ob eine separate PDU-Sitzung mit dem Standard-Internet-Speilplatz 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.
Bei der Upselling-Funktion für 5G-Slicing wird die TS.43-Antwort vom Berechtigungsserver des Mobilfunkanbieters verwendet, 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 Sliver bereitgestellt und im Mobilfunkanbieternetzwerk verfügbar ist.
Mobilfunkanbieter können das Verhalten der Upselling-Funktion für 5G-Slicing mithilfe von Mobilfunkanbieterkonfigurationen anpassen. Damit wird festgelegt, ob Kaufanfragen gestellt werden können, wann Apps Premiumfunktionen anfordern dürfen und wie lange das Telephony 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:
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 Berechtigungskonfiguration für TS.43 enthält die folgenden Felder für den Kauf von Slices:
- Berechtigungsstatus
Taste:
EntitlementStatusTyp:
intUnterstützte Werte:
0(deaktiviert),1(aktiviert),2(nicht kompatibel),3(Bereitstellung),4(inbegriffen)- Status der Nutzerverwaltung
Taste:
ProvStatusTyp:
intUnterstützte Werte:
0(nicht bereitgestellt),1(bereitgestellt),2(nicht verfügbar),3(in Bearbeitung)
Das Telephony Framework verwendet eine Kombination aus Berechtigungsstatus und Bereitstellungsstatus, um den aktuellen Kaufstatus des Streifens zu bestimmen. Das Ergebnis kann einer der folgenden Werte sein:
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
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 Telephony-Frameworks für verschiedene Kombinationen von Bereitstellungs- und Berechtigungsstatus 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. Wenn die Nutzerdaten vorhanden sind, werden sie als Suchparameter an die URL angehängt (z. B. https://www.android.com?encodedValue=Base64EncodedUserData). Wenn sie nicht vorhanden sind, 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, wenn sie in Base64 codiert sind) werden als Daten für die POST-Anfrage gesendet.
- URL
Taste:
ServiceFlow_URLTyp:
StringBeispiel:
"https://www.android.com"- Nutzerdaten
Taste:
ServiceFlow_UserDataTyp:
StringBeispiel:
"encodedValue=Base64EncodedUserData"- Inhaltstyp
Taste:
ServiceFlow_ContentsTypeTyp:
StringUnterstü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_ARRAYEine Liste der unterstützten Premium-Funktionen. Dies ist ein Int-Array von
TelephonyManager.PremiumCapability. Diese Premiumfunktionen haben denselben Wert wie die entsprechendeNetworkCapabilities.NetCapability-Klasse. Wenn eine Premiumfunktion angefordert wird, die nicht in dieser Konfiguration enthalten ist, schlägt der Kaufantrag mit dem ErgebnisCARRIER_DISABLEDfehl.Unter Android 14 wird nur
PREMIUM_CAPABILITY_PRIORITIZE_LATENCYunterstützt.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTDie maximale Anzahl der täglichen Auslieferungen der Kauf-Upselling-Benachrichtigung an den Nutzer. Wenn das Tageslimit erreicht ist, wird die Upselling-Benachrichtigung nicht angezeigt und Kaufanfragen (einschließlich Berechtigungsanfragen) werden bis Mitternacht des nächsten Tages gedrosselt. Kaufanfragen, die nach Erreichen des Tageslimits gestellt werden, schlagen mit dem Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDfehl.KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INTDie 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_THROTTLEDfehl.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGDie URL für den Kauf beim Mobilfunkanbieter, die dem Nutzer angezeigt werden soll, wenn er auf die Upselling-Benachrichtigung klickt. Wenn die Kauf-URL in der TS.43-Antwort vom Berechtigungsserver nicht 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_DISABLEDfehl.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLOb Premiumfunktionen gekauft werden dürfen, wenn das Gerät mit Long Term Evolution (LTE) verbunden ist. Bei
truekönnen Kaufanfragen sowohl über LTE als auch über New Radio (NR) gesendet werden. Wennfalseist, können Kaufanfragen nur über NR gesendet werden. Anfragen über LTE schlagen mit dem ErgebnisPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLEfehl.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGDie 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_THROTTLEDfehl.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGDie Zeitspanne, in der nachfolgende Kaufanfragen nach einem Fehler aufgrund von Zeitüberschreitung oder Nutzerabbruch gedrosselt werden sollen. Wenn der Nutzer innerhalb der von
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGangegebenen Zeitüberschreitung nicht auf die Kauf-Upselling-Benachrichtigung klickt oder die Benachrichtigung abbricht oder schließt, startet dieser Backoff-Timer. Solange dieser Timer aktiv ist, schlagen Kaufanfragen mit dem ErgebnisPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDfehl.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGDie 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 URL für den Kauf beim Mobilfunkanbieter einen Fehler anzeigt, wird dieser Backoff-Timer gestartet. Solange dieser Timer aktiv ist, schlagen Kaufanfragen mit dem Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLEDfehl.KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONGDie Zeitspanne, innerhalb derer das Netzwerk eine Segmentierungskonfiguration für die Kauf-Premium-Funktion einrichten muss. Während dieses Zeitraums werden nachfolgende Kaufanfragen blockiert und das Ergebnis
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUPzurü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 in der JavaScript-Schnittstelle DataBoostWebServiceFlow auf ihrer Kaufwebsite bereitgestellt werden, um mit der App für den Kauf von Speicherplatz zu kommunizieren.
Die gewünschte Premiumfunktion kann über die Methode getRequestedCapability() von der Mobilfunkanbieterwebsite abgerufen werden.
Wenn der Kauf erfolgreich war, muss die Website des Mobilfunkanbieters die App für den Kauf von Snippets über notifyPurchaseSuccessful() oder notifyPurchaseSuccessful(duration) benachrichtigen. Dabei ist duration ein optionaler Parameter, der die beabsichtigte Dauer des Snippets 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 keine dieser Antwortmethoden aufgerufen wird, wird der Kauf nicht als abgeschlossen betrachtet und die Kaufanfrage läuft schließlich ab.
Die folgenden gültigen Fehlercodes können von der Website des Mobilfunkanbieters bei einem Kauffehler zurückgegeben werden:
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
Nach Abschluss des Kaufs muss der Mobilfunkanbieter die URSP-Regeln mit dem PRIORITIZE_LATENCY-Snippet auf dem Gerät des Nutzers aktualisieren.