5G-Netzwerk-Slicing

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

Aufteilen von Unternehmensgeräten für vollständig verwaltete Geräte

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

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

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

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

So funktioniert 5G‑Network Slicing in AOSP

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

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

Komponenten von 5G‑Network-Slicing

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

Die Telefonie- und Verbindungsplattform unterstützt:

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

  • Unterstützung von Enterprise-Slicing

    • Erkennen des Vorhandenseins eines Arbeitsprofils auf dem Gerät
    • Prüfen von Berechtigungen oder Routenbeschreibungen, die vom DPC des IT-Administrators des Unternehmens bereitgestellt werden

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

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

  • Erweitert die Grenzen des Tethering-Moduls um Folgendes:

    • f/b/core/java/android/net/…
    • f/b/services/net/…
    • f/b/services/core/java/com/android/server/connectivity/…
    • f/b/services/core/java/com/android/server/ConnectivityService.java
    • f/b/services/core/java/com/android/server/TestNetworkService.java

  • Verschiebt VPN-Code aus dem Tethering-Modul

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

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

Implementierung

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

  • trafficDescriptor: Gibt den an das Modem gesendeten Traffic-Deskriptor an.
  • sliceInfo: Gibt Informationen für den Netzwerk-Slice an, der im Fall der EPDG-zu-5G-Übergabe verwendet werden soll.
  • matchAllRuleAllowed: Gibt an, ob die Verwendung einer standardmäßigen URSP-Regel für alle Übereinstimmungen zulässig ist. Telephony legt diesen Wert für Standardnetzwerke auf „true“ fest, nicht aber für Slices. Die Regel „Mit allen übereinstimmen“ wird auf Standardnetzwerke angewendet. Wenn eine App ein bestimmtes Slice anfordert, das nicht verfügbar ist, wird das Slice als nicht verfügbar gemeldet. Bei Unternehmens-Apps kann das Telephony-Framework auf das Standardnetzwerk zurückgreifen, wenn das Unternehmensnetzwerk nicht verfügbar ist.

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

Anforderungen für Unternehmen

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

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

5G-Network-Slicing auf Geräten aktivieren, die mit einem Arbeitsprofil eingerichtet wurden

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 die Weiterleitung des App-Traffics von Arbeitsprofilen an den Unternehmensnetzwerk-Slice über den EMM-DPC (EMM Device Policy Controller) für jeden Mitarbeiter einzeln aktivieren oder deaktivieren. Dazu wird die Methode setPreferentialNetworkServiceEnabled in der DevicePolicyManager-API (Device Policy Manager) verwendet, die in Android 12 eingeführt wurde.

EMM-Anbieter mit benutzerdefinierten DPCs müssen die DevicePolicyManager API integrieren, um Enterprise-Kunden zu unterstützen.

URSP-Regeln

Dieser Abschnitt enthält Informationen für Mobilfunkanbieter zum Konfigurieren von URSP-Regeln für verschiedene Slice-Kategorien, darunter Unternehmens-, CBS-, Low-Latency-, High-Bandwidth- und Unified-Communications-Traffic.

Bei der Konfiguration von URSP-Regeln können Mobilfunkanbieter Verkehrsdeskriptoren verwenden, die auf den folgenden Faktoren basieren:

  • Betriebssystem-ID und Betriebssystem-App-ID-Typ, Komponententyp 0x08, unterstützt in Android 12 und höher
  • Typ der Verbindungsfunktionen, Komponententyp 0x90, unterstützt in Android 17 und höher

Betriebssystem-ID und Betriebssystem-App-ID

Bei der Konfiguration von URSP-Regeln mit der Traffic-Deskriptorkomponente vom Typ „OS Id“ und „OS App Id“ können Mobilfunkanbieter die folgenden Android-spezifischen Werte für „OS Id“ und „OS App Id“ verwenden.

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

Mobilfunkanbieter, die URSP-Regeln mit dem Typ „OS-ID“ und „OS-App-ID“ konfigurieren, müssen den Traffic für jeden Slice mit der Traffic-Deskriptorkomponente als Verkettung der OS-ID, der Länge der OS-App-ID (0x0A) und der OS-App-ID konfigurieren. Das Segment ENTERPRISE muss beispielsweise den Wert 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 haben. Weitere Informationen zum Komponententyp des Verkehrsdeskriptors finden Sie in 3GPP TS 24.526, Tabelle 5.2.1.

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

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

Wir haben keine Pläne, neue OSAppId-Werte einzuführen. Wir werden den Verkehrsdeskriptor für Verbindungsfunktionen bei Bedarf optimieren.

Verbindungsfunktionen

Ab Android 17 und höher (Radio HAL AIDL 2.5 und höher) unterstützt Android die Traffic-Deskriptorkomponente für Verbindungsfunktionen (Typ 0x90), die in 3GPP TS 24.526, Tabelle 5.2.1 definiert ist.

Wenn eine App oder ein Systemdienst ein Netzwerk mit einer bestimmten Funktion anfordert, ordnet der Android-Telefonie-Datenstack die angeforderte NetworkCapabilities einem Standardwert für die Verbindungsfunktion zu, der in der TrafficDescriptor enthalten ist, die während der Einrichtung des Datenanrufs (setupDataCall) an das Modem gesendet wird. Während die 3GPP-Spezifikation mehrere Verbindungsfunktionen in einem einzelnen Deskriptor zulässt, ordnet das Android 17-Telefonie-Framework die angeforderten Verbindungsfunktionen einer einzelnen Verbindungsfunktion zu.

In der folgenden Tabelle wird die Standardzuordnung von Android-Netzwerkfunktionen zu 3GPP-Verbindungsfunktionen beschrieben:

Netzwerkfähigkeit Verbindungsfähigkeit Wert (hexadezimal oder dezimal) Beschreibung
NET_CAPABILITY_IMS CONNECTION_CAPABILITY_IMS 0x01 (1) IMS-Sprach- und ‑Videokommunikation
NET_CAPABILITY_MMS CONNECTION_CAPABILITY_MMS 0x02 (2) MMS-Traffic
NET_CAPABILITY_SUPL CONNECTION_CAPABILITY_SUPL 0x04 (4) Secure User Plane Location (SUPL)
NET_CAPABILITY_INTERNET CONNECTION_CAPABILITY_INTERNET 0x08 (8) Standard-Internetdatenverkehr
NET_CAPABILITY_PRIORITIZE_LATENCY CONNECTION_CAPABILITY_REAL_TIME_INTERACTIVE 0xA6 (166) Interaktiver Echtzeit-Traffic (z. B. Gaming, AR/VR)
NET_CAPABILITY_PRIORITIZE_BANDWIDTH CONNECTION_CAPABILITY_DOWNLINK_STREAMING 0xA3 (163) Streaming-Traffic mit hoher Bandbreite im Downlink
NET_CAPABILITY_PRIORITIZE_UNIFIED_COMMUNICATIONS CONNECTION_CAPABILITY_UNIFIED_COMMUNICATIONS 0xA7 (167) Unified Communications (z. B. OTT-Sprach- oder ‑Videoanrufe)

URSP-Konfiguration des Mobilfunkanbieters und Abwärtskompatibilität

Damit der Betrieb auf Geräten mit unterschiedlichen HAL- und Betriebssystemversionen reibungslos funktioniert, sollten Mobilfunkanbieter beim Bereitstellen von URSP-Regeln Folgendes berücksichtigen:

  • Geräte mit Android 16 oder niedriger (Radio HAL AIDL 2.4 und niedriger): Das Modem empfängt mindestens die OSAppId im Traffic-Deskriptor.
  • Geräte mit Android 17 oder höher (AIDL 2.5 und höher): Für Premium-Slice-Funktionen (z. B. geringe Latenz, hohe Bandbreite und Unified Communications) wird entweder OSAppId, ConnectionCapability oder beides im Traffic-Deskriptor angegeben.

Mobilfunkanbieter können URSP-Regeln mit einer der folgenden Methoden konfigurieren:

  1. Vorrangregeln (empfohlen):
    • Regel A (höhere Priorität, niedrigere Prioritätsnummer, z. B. 10): Abgleich mit Verbindungsfunktionen (z. B. 0xA6 für niedrige Latenz, 0xA3 für hohe Bandbreite oder 0xA7 für Unified Communications). Auf Geräten mit Android 17 und höher wird diese Regel zuerst angewendet.
    • Regel B (niedrigere Priorität, höhere Prioritätsnummer, z. B. 20): Abgleich mit der Betriebssystem-ID und dem Typ der Betriebssystem-App-ID (z. B. PRIORITIZE_LATENCY). Ältere Geräte, die keine Verbindungsmöglichkeit im HAL unterstützen, entsprechen dieser Fallback-Regel.
  2. Regel nur mit Betriebssystem-App-ID (alt):
    • Mobilfunkanbieter können weiterhin vorhandene URSP-Regeln basierend auf dem Typ „Betriebssystem-ID“ und „Betriebssystem-App-ID“ verwenden. Da Geräte mit Android 17 und höher weiterhin die OSAppId bestehen, entsprechen sowohl neue als auch ältere Geräte diesen Regeln.
  3. Kombinierte Regel (AND-Bedingung):
    • Mobilfunkanbieter können sowohl die Betriebssystem-ID als auch die Betriebssystem-App-ID und die Verbindungsfunktionen in einem einzelnen Verkehrsdeskriptor angeben. Diese Regel gilt nur für Geräte mit Android 17 oder höher und AIDL 2.5 oder höher.

Beispiel für URSP-Regeln

Die folgenden Tabellen enthalten Beispielregeln für URSP für Enterprise, CBS, niedrige Latenz, hohe Bandbreite, Unified Communications und Standard-Traffic.

Enterprise 1

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

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

Enterprise 2

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

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

Enterprise 3

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

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

Enterprise 4

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

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

Enterprise 5

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

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

CBS

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

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

Niedrige Latenz mit Verbindungsmöglichkeit

Die Unterstützung für Verbindungsfunktionen in URSP-Regeln ist ab Android 17 verfügbar. Das Folgende ist ein Beispiel für eine URSP-Regel für Traffic mit geringer Latenz unter Verwendung des Deskriptors für Verbindungsfunktionen:

URSP-Regel 7 (niedrige Latenz mit Verbindungsfunktion)
Vorrang 7 (0x07)
Traffic-Deskriptor 1
Typ der Verbindungsfunktionen 0xA6 (166: Interaktiv in Echtzeit)
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN Latenz
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN Latenz

Niedrige Latenz mit OSAppId

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

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

Hohe Bandbreite mit Verbindungsmöglichkeit

Die Unterstützung für Verbindungsfunktionen in URSP-Regeln ist ab Android 17 verfügbar. Das Folgende ist ein Beispiel für eine URSP-Regel für Traffic mit hoher Bandbreite, die den Deskriptor für Verbindungsfunktionen verwendet:

URSP-Regel 9 (hohe Bandbreite mit Verbindungsfunktion)
Vorrang 9 (0x09)
Traffic-Deskriptor 1
Typ der Verbindungsfunktionen 0xA3 (163: Downlink-Streaming)
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN Bandbreite
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN Bandbreite

Hohe Bandbreite mit OSAppId

Die Unterstützung für hohe Bandbreite ist in Android 13 und höher verfügbar. Hier ist ein Beispiel für eine URSP-Regel für HIGH_BANDWIDTH-Traffic mit OSAppId:

URSP-Regel 10 (hohe Bandbreite mit OSAppId-Fallback)
Vorrang 10 (0x0A)
Traffic-Deskriptor 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 0x97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY
Komponente 2: DNN Bandbreite
Deskriptor für die Routenauswahl 2
Vorrang 2 (0x02)
Komponente 1: DNN Bandbreite

Vereinheitlichte Kommunikation mit Verbindungsfunktion

Die Unterstützung für Unified Communications ist in Android 17 und höher verfügbar. Das Folgende ist ein Beispiel für eine URSP-Regel für UNIFIED_COMMUNICATIONS-Traffic mit Verbindungsfunktion. Da der Unified Communications-Traffic über die standardmäßige Internetdatenverbindung geleitet wird, ist im Routenauswahldeskriptor kein dedizierter APN (DNN) erforderlich:

URSP-Regel 11 (Unified Communications mit Verbindungsfunktion)
Vorrang 11 (0x0B)
Traffic-Deskriptor 1
Typ der Verbindungsfunktionen 0xA7 (167: Unified Communications)
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY

Vereinheitlichte Kommunikation mit OSAppId

Die Unterstützung für Unified Communications ist in Android 17 und höher verfügbar. Hier ist ein Beispiel für eine URSP-Regel für UNIFIED_COMMUNICATIONS-Traffic mit OSAppId:

URSP-Regel 12 (Unified Communications mit OSAppId-Fallback)
Vorrang 12 (0x0C)
Traffic-Deskriptor 1
Betriebssystem-ID + Typ der Betriebssystem-App-ID 0x97A498E3FC925C9489860333D06E4E47215052494F524954495A455F554E49464945445F434F4D4D554E49434154494F4E53
Deskriptor für die Routenauswahl 1
Vorrang 1 (0x01)
Komponente 1: S-NSSAI SST:XX SD:YYYYYY

Standard

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

Test

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

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

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

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

  3. Netzwerk-Slicing über den DPC aktivieren

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

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

Upselling für 5G-Network-Slicing

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

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

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

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

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

Kaufvorgang für Upselling von 5G-Network-Slicing

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

TS.43-Berechtigungsprozess

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

Kauffelder segmentieren

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

Berechtigungsstatus

Schlüssel: EntitlementStatus

Typ: int

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

Status der Nutzerverwaltung

Schlüssel: ProvStatus

Typ: int

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

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

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

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

Felder für den Serviceablauf

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

URL

Schlüssel: ServiceFlow_URL

Typ: String

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

Nutzerdaten

Schlüssel: ServiceFlow_UserData

Typ: String

Beispiel: "encodedValue=Base64EncodedUserData"

Inhaltstyp

Schlüssel: ServiceFlow_ContentsType

Typ: String

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

Konfigurationen des Mobilfunkanbieters

Im Folgenden finden Sie die verfügbaren Netzbetreiberkonfigurationen, mit denen Sie das Verhalten der Upsell-Funktion für 5G-Network-Slicing anpassen können.

KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY

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

In Android 14 wird nur PREMIUM_CAPABILITY_PRIORITIZE_LATENCY unterstützt.

KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT

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

KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT

Die monatliche maximale Anzahl der Anzeigen der Benachrichtigung zum Upselling von Käufen für den Nutzer. Wenn das monatliche Maximum erreicht ist, wird die Upsell-Benachrichtigung nicht angezeigt und Kaufanfragen (einschließlich Berechtigungsserveranfragen) werden bis zum ersten Tag des Folgemonats gedrosselt. Kaufanfragen, die nach Erreichen des monatlichen Maximums gestellt werden, schlagen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED fehl.

KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING

Die URL für den Kauf des Reserve-Carriers, die dem Nutzer angezeigt werden soll, wenn er auf die Upsell-Benachrichtigung klickt. Wenn die Kauf-URL nicht in der TS.43-Antwort des Berechtigungsservers gefunden wird, wird stattdessen dieser Wert verwendet. Wenn weder die URL aus der TS.43-Antwort noch die Betreiberkonfiguration gültig ist, schlägt die Kaufanfrage mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED fehl.

KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL

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

KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG

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

KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

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

KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Die Zeitspanne, in der nachfolgende Kaufanfragen nach einem Fehler aufgrund des Mobilfunkanbieters oder Netzwerks gedrosselt werden sollen. Wenn die Berechtigungsprüfung fehlschlägt, die URL nicht verfügbar ist oder die URL für den Kauf über den Mobilfunkanbieter einen Fehler anzeigt, wird dieser Backoff-Timer gestartet. Während dieser Timer aktiv ist, schlagen Kaufanfragen mit dem Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED fehl.

KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG

Die Zeit, innerhalb derer das Netzwerk eine Slicing-Konfiguration für die Funktion „Kaufprämie“ einrichten muss. Während dieses Zeitraums werden nachfolgende Kaufanfragen blockiert und das Ergebnis PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP wird zurückgegeben. Wenn das Netzwerk die Einrichtung einer Slicing-Konfiguration nicht rechtzeitig durchführt, können Apps noch einmal den Kauf von Premium-Funktionen anfordern. Bei der Telefonie gilt ein Kauf erst dann als abgeschlossen, wenn die entsprechende Slicing-Konfiguration gesendet wurde, unabhängig davon, ob der Nutzer den Mobilfunkanbieter bezahlt hat oder nicht.

JavaScript-Schnittstelle

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

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

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

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

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

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

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

Automatisches Routing von 5G‑Network-Slicing für OTT-Sprach- und ‑Videoanrufe

Android 17 unterstützt das automatische Weiterleiten von OTT-Sprach- und ‑Videoanrufen (Over-the-Top) an Premium-Netzwerkverbindungen. Mit dieser Funktion kann das System den Traffic von Sprach- und Videoanrufen automatisch an eine dedizierte Premium-Netzwerkschnittstelle (z. B. einen Premium-5G-Slice oder eine Premium-4G-PDN-Verbindung) weiterleiten, ohne dass Änderungen am Netzwerk-Stack der App erforderlich sind.

Mit dieser Lösung auf Plattformebene müssen App-Entwickler keine Netzwerkfunktionen explizit anfordern. Das sorgt für eine reibungslose Nutzung für Entwickler und Endnutzer.

Funktionsweise

Android unterstützt die automatische Weiterleitung durch Ergänzungen der Frameworks für Konnektivität und Telekommunikation. Die automatische Weiterleitung funktioniert so:

  • Anruferkennung:Das System nutzt vorhandene Telecom Jetpack APIs, die von OTT-Apps verwendet werden, um den Beginn und das Ende von Sprach- oder Videoanrufen zu erkennen.
  • Verbindungsverwaltung:Wenn ein Anruf erkannt wird, stellt Android eine bestimmte Premium-Netzwerkschnittstelle bereit, z. B. einen Unified Communication-Slice.
  • Traffic Steering:Während des Anrufs identifiziert die Plattform die Anwendung anhand ihrer UID und leitet ihren Traffic automatisch an die Premium-Netzwerkverbindung weiter.
  • Fallback nach dem Anruf:Wenn der Anruf beendet wird, entfernt die Plattform die Routingregel und der Traffic der App wird für Nicht-Anruftraffic (z. B. Messaging) wieder auf das Standardnetzwerk des Systems zurückgesetzt.

Voraussetzungen

Damit das automatische Routing für OTT-Anrufe unterstützt wird, müssen die folgenden Anforderungen erfüllt sein:

  • Mobilfunkanbieter:Müssen einen Unified Communication-Slice anbieten, indem sie entsprechende URSP-Regeln konfigurieren (mit connection capability oder OSAppId für Unified Communication-Traffic).
  • Apps:Sie müssen die Android Telecom Jetpack APIs verwenden, damit das System Anrufstatus erkennen kann.
  • Gerätehersteller:Android 17 oder höher ist erforderlich.