W przypadku urządzeń z Androidem 12 lub nowszym Android obsługuje podział sieci 5G, czyli wykorzystanie wirtualizacji sieci do dzielenia pojedynczych połączeń sieciowych na wiele odrębnych połączeń wirtualnych, które zapewniają różne ilości zasobów dla różnych rodzajów ruchu. Technologia 5G Network Slicing umożliwia operatorom sieci wydzielenie części sieci na potrzeby udostępniania określonych funkcji konkretnemu segmentowi klientów. Android 12 wprowadza te 5 możliwości dzielenia sieci 5G na potrzeby firm, które operatorzy sieci mogą udostępniać swoim klientom biznesowym:
Podział urządzenia na potrzeby firmy na w pełni zarządzanych urządzeniach
Firmy, które udostępniają pracownikom w pełni zarządzane urządzenia firmowe, mogą korzystać z usług dostawców sieci, którzy zapewniają im co najmniej 1 aktywny wycinek sieci firmowej, do którego kierowany jest ruch z urządzeń firmowych. Od Androida 12 operatorzy mogą udostępniać segmenty sieci dla firm za pomocą reguł URSP zamiast konfigurować segmenty sieci za pomocą APN.
Dzielenie aplikacji biznesowych na urządzeniach z profilami służbowymi
W przypadku firm korzystających z rozwiązania profilu służbowego Android 12 umożliwia kierowanie ruchu ze wszystkich aplikacji w profilu służbowym do segmentu sieci firmowej. Firmy mogą włączyć tę funkcję za pomocą kontrolera zasad dotyczących urządzeń (DPC).
Rozwiązanie profilu służbowego zapewnia automatyczny poziom uwierzytelniania i kontroli dostępu, którego firmy potrzebują, aby mieć pewność, że tylko ruch z aplikacji firmowych w profilu służbowym jest kierowany do wyodrębnionej sieci firmowej. Aplikacje w profilu służbowym nie muszą być modyfikowane, aby wyraźnie żądać wycinka sieci firmowej.
Jak działa dzielenie sieci 5G w AOSP
Android 12 wprowadza obsługę podziału sieci 5G dzięki dodatkom do kodu telefonicznego w AOSP i modułu tetheringu w celu uwzględnienia istniejących interfejsów API łączności, które są wymagane do podziału sieci.
Platforma telefoniczna Androida udostępnia interfejsy HAL i telefoniczne API, które obsługują podział na podstawie żądań sieciowych zgłaszanych przez podstawowy kod sieciowy oraz funkcje podziału sieci 5G w modemie. Na rysunku 1 przedstawiono elementy funkcji podziału sieci 5G.
Rysunek 1. Architektura segmentacji sieci 5G w AOSP.
Platforma telefoniczna i łączności obsługuje:
- Przekształcanie żądań sieciowych dotyczących kategorii wycinków na deskryptory ruchu, które są następnie przekazywane do modemu w celu dopasowania ruchu URSP i wyboru trasy.
- W przypadku niedostępności wycinka sieci firmowej powrót do sieci domyślnej.
- Kierowanie ruchu ze wszystkich aplikacji w profilu służbowym do odpowiedniego połączenia
Obsługa podziału sieci w przypadku firm
- wykrywanie obecności profilu służbowego na urządzeniu;
- Sprawdzanie uprawnień lub wskazówek dojazdu podanych przez DPC używany przez administratora IT firmy
Podstawowa usługa sieciowa obejmuje te zmiany w module Tethering w Androidzie 12:
- Dodaje większość klas interfejsu API
android.net.*publicznego lub systemowego do modułu Tethering. Rozszerza granice modułu tetheringu, aby obejmował:
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
Przenosi kod VPN z modułu tetheringu
Android 12 przenosi kod z tymi funkcjami do modułu tetheringu:
- Otrzymywanie żądań połączeń sieciowych z aplikacji
- Odbieranie żądań z systemu (np. „umieść te aplikacje w profilu służbowym”; wprowadzono w Androidzie 12)
- Wysyłanie żądań z systemu do kodu telefonicznego, który próbuje skonfigurować sieci lub wycinki sieciowe za pomocą interfejsu HAL API i modemu.
- informowanie usługi netd o sposobie kierowania ruchu w przypadku poszczególnych aplikacji (wprowadzone w Androidzie 12);
- Informowanie aplikacji o tym, co dzieje się z ich ruchem w sieci, za pomocą
ConnectivityManagerinterfejsów API, takich jakNetworkCallback,getActiveNetwork,getNetworkCapabilities.
Implementacja
Aby urządzenie obsługiwało segmentację sieci 5G, musi mieć modem obsługujący interfejs HAL IRadio 1.6, który ma interfejs API setupDataCall_1_6. Ten interfejs API konfiguruje połączenie do transmisji danych i zawiera te parametry
do obsługi segmentacji sieci 5G:
trafficDescriptor: Określa deskryptor ruchu wysyłany do modemu.sliceInfo: określa informacje o plasterku sieci, który ma być używany w przypadku przekazywania połączenia z EPDG do 5G.matchAllRuleAllowed: określa, czy można używać domyślnej reguły URSP dopasowującej wszystkie żądania. Telefonia ustawia tę wartość na „true” w przypadku sieci domyślnych, ale nie w przypadku wycinków sieci. Reguła dopasowania wszystkich sieci jest stosowana do sieci domyślnych. Gdy aplikacja zażąda konkretnego wycinka, który jest niedostępny, zostanie on zgłoszony jako niedostępny. W przypadku aplikacji dla firm platforma Telephony może przełączyć się na domyślną sieć, jeśli sieć firmowa jest niedostępna.
Modemy muszą też implementować interfejs API getSlicingConfig, chyba że interfejs API getHalDeviceCapabilities zgłosi go jako nieobsługiwany.
Wymagania dotyczące klientów Enterprise
Poniżej opisujemy wymagania, które muszą spełniać przedsiębiorstwa, aby korzystać z segmentacji sieci 5G na urządzeniach wdrożonych w ramach Androida Enterprise.
- Sprawdź, czy w pełni zarządzane urządzenia należące do pracowników, na których skonfigurowano profil służbowy, obsługują 5G SA i mają modemy, które obsługują interfejs
setupDataCall_1_6. - Współpracuj z partnerem telekomunikacyjnym w zakresie konfiguracji i wydajności wycinka sieci lub charakterystyki umowy SLA.
Włączanie segmentacji sieci 5G na urządzeniach skonfigurowanych z profilem służbowym
W przypadku urządzeń z utworzonymi profilami służbowymi w AOSP domyślnie wyłączone jest dzielenie sieci 5G. Aby włączyć segmentację sieci, administratorzy IT w firmie mogą włączać lub wyłączać kierowanie ruchu z aplikacji w profilu służbowym do segmentu sieci firmowej w przypadku poszczególnych pracowników za pomocą kontrolera zasad dotyczących urządzeń (DPC) usługi EMM, który korzysta z metody setPreferentialNetworkServiceEnabled w interfejsie DevicePolicyManager (DPM) API (wprowadzonego w Androidzie 12).
Dostawcy usług EMM z niestandardowymi kontrolerami zasad dotyczących urządzeń muszą zintegrować interfejs DevicePolicyManager API, aby obsługiwać klientów korporacyjnych.
Reguły URSP
Ta sekcja zawiera informacje dla operatorów o konfigurowaniu reguł URSP dla różnych kategorii wycinków sieci, w tym dla ruchu związanego z przedsiębiorstwami, CBS, małym opóźnieniem, dużą przepustowością i komunikacją ujednoliconą.
Podczas konfigurowania reguł URSP operatorzy mogą używać deskryptorów ruchu na podstawie tych czynników:
- Identyfikator systemu operacyjnego i identyfikator aplikacji systemu operacyjnego, typ komponentu
0x08, obsługiwane w Androidzie 12 i nowszych wersjach - Typ możliwości połączenia, typ komponentu
0x90, obsługiwane w Androidzie 17 i nowszym
Identyfikator systemu operacyjnego i identyfikator aplikacji w systemie operacyjnym
Podczas konfigurowania reguł URSP za pomocą komponentu deskryptora ruchu typu OS Id i OS App Id operatorzy mogą używać tych wartości OS Id i OS App Id specyficznych dla Androida.
| Identyfikator | Wartość | Opis |
|---|---|---|
| Identyfikator systemu operacyjnego | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
Identyfikator systemu operacyjnego Android to identyfikator UUID w wersji 5 wygenerowany w przestrzeni nazw ISO OID i o nazwie Android. |
Operatorzy konfigurujący reguły URSP za pomocą identyfikatora systemu operacyjnego i identyfikatora aplikacji systemu operacyjnego muszą skonfigurować ruch w każdej sieci za pomocą komponentu deskryptora ruchu jako połączenia identyfikatora systemu operacyjnego, długości identyfikatora aplikacji systemu operacyjnego (0x0A) i identyfikatora aplikacji systemu operacyjnego. Na przykład wycinek ENTERPRISE musi mieć wartość 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
Więcej informacji o typie komponentu deskryptora ruchu znajdziesz w tabeli 5.2.1 w 3GPP TS 24.526.
W tabeli poniżej znajdziesz wartości OSAppId dla różnych kategorii segmentów.
| Kategoria wycinka | OSAppId | Opis |
|---|---|---|
ENTERPRISE |
0x454E5445525052495345 |
OSAppId to tablica bajtów reprezentująca ciąg ENTERPRISE |
ENTERPRISE2 |
0x454E544552505249534532 |
OSAppId to tablica bajtów reprezentująca ciąg ENTERPRISE2 |
ENTERPRISE3 |
0x454E544552505249534533 |
OSAppId to tablica bajtów reprezentująca ciąg ENTERPRISE3 |
ENTERPRISE4 |
0x454E544552505249534534 |
OSAppId to tablica bajtów reprezentująca ciąg ENTERPRISE4 |
ENTERPRISE5 |
0x454E544552505249534535 |
OSAppId to tablica bajtów reprezentująca ciąg ENTERPRISE5 |
CBS |
0x434253 |
OSAppId to tablica bajtów reprezentująca ciąg CBS |
PRIORITIZE_LATENCY |
0x5052494f524954495a455f4c4154454e4359 |
OSAppId to tablica bajtów reprezentująca ciąg PRIORITIZE_LATENCY |
PRIORITIZE_BANDWIDTH |
0x5052494f524954495a455f42414e445749445448 |
OSAppId to tablica bajtów reprezentująca ciąg PRIORITIZE_BANDWIDTH |
PRIORITIZE_UNIFIED_COMMUNICATIONS |
0x5052494f524954495a455f554e49464945445f434f4d4d554e49434154494f4e53 |
OSAppId to tablica bajtów reprezentująca ciąg PRIORITIZE_UNIFIED_COMMUNICATIONS |
Nie planujemy wprowadzenia nowych wartości OSAppId. W razie potrzeby ulepszymy deskryptor ruchu funkcji połączenia.
Możliwości połączenia
Od Androida 17 (Radio HAL AIDL 2.5 i nowsze) Android obsługuje komponent deskryptora ruchu funkcji połączenia (typ 0x90) zdefiniowany w 3GPP TS 24.526 Table 5.2.1.
Gdy aplikacja lub usługa systemowa zażąda sieci o określonej możliwości, stos danych telefonicznych Androida mapuje żądany NetworkCapabilities na standardową wartość możliwości połączenia wypełnianą w TrafficDescriptor wysyłanym do modemu podczas konfigurowania połączenia danych (setupDataCall). Specyfikacja 3GPP dopuszcza wiele możliwości połączenia w jednym deskryptorze, ale platforma telefoniczna Androida 17 mapuje wiele żądanych możliwości połączenia na jedną możliwość połączenia.
W tabeli poniżej opisano domyślne mapowanie możliwości sieci Androida na możliwości połączenia 3GPP:
| Funkcjonalność sieci | Możliwości połączenia | Wartość (szesnastkowa lub dziesiętna) | Opis |
|---|---|---|---|
NET_CAPABILITY_IMS |
CONNECTION_CAPABILITY_IMS |
0x01 (1) |
Komunikacja głosowa i wideo w ramach IMS |
NET_CAPABILITY_MMS |
CONNECTION_CAPABILITY_MMS |
0x02 (2) |
Ruch MMS |
NET_CAPABILITY_SUPL |
CONNECTION_CAPABILITY_SUPL |
0x04 (4) |
Secure User Plane Location (SUPL) |
NET_CAPABILITY_INTERNET |
CONNECTION_CAPABILITY_INTERNET |
0x08 (8) |
Domyślny ruch danych internetowych |
NET_CAPABILITY_PRIORITIZE_LATENCY |
CONNECTION_CAPABILITY_REAL_TIME_INTERACTIVE |
0xA6 (166) |
Ruch interaktywny w czasie rzeczywistym (np. gry, AR/VR) |
NET_CAPABILITY_PRIORITIZE_BANDWIDTH |
CONNECTION_CAPABILITY_DOWNLINK_STREAMING |
0xA3 (163) |
Ruch transmisji strumieniowej o dużej przepustowości w kierunku urządzenia |
NET_CAPABILITY_PRIORITIZE_UNIFIED_COMMUNICATIONS |
CONNECTION_CAPABILITY_UNIFIED_COMMUNICATIONS |
0xA7 (167) |
Komunikacja ujednolicona (np. połączenia głosowe lub wideo OTT) |
Konfiguracja URSP operatora i zgodność wsteczna
Aby zapewnić bezproblemowe działanie na urządzeniach z różnymi wersjami HAL i systemu operacyjnego, operatorzy powinni wziąć pod uwagę to zachowanie podczas udostępniania reguł URSP:
- Urządzenia z Androidem 16 lub starszym (Radio HAL AIDL 2.4 i starsze): modem otrzymuje co najmniej
OSAppIdw deskryptorze ruchu. - Urządzenia z Androidem 17 lub nowszym (AIDL 2.5 i nowszy): w przypadku funkcji zaawansowanego wycinka sieci (takich jak małe opóźnienia, duża przepustowość i zintegrowana komunikacja) platforma wypełnia w deskryptorze ruchu pole
OSAppId,ConnectionCapabilitylub oba te pola.
Operatorzy mogą konfigurować reguły URSP na jeden z tych sposobów:
- Reguły oparte na pierwszeństwie (zalecane):
- Reguła A (wyższy priorytet, niższy numer priorytetu, np. 10): dopasowanie do możliwości połączenia (np.
0xA6w przypadku małego opóźnienia,0xA3w przypadku dużej przepustowości lub0xA7w przypadku ujednoliconej komunikacji). Urządzenia z Androidem 17 lub nowszym są dopasowywane do tej reguły w pierwszej kolejności. - Reguła B (niższy priorytet, wyższy numer priorytetu, np. 20): dopasowanie do identyfikatora systemu operacyjnego i identyfikatora aplikacji systemu operacyjnego (np.
PRIORITIZE_LATENCY). Starsze urządzenia, które nie obsługują możliwości połączenia w warstwie HAL, pasują do tej reguły rezerwowej.
- Reguła A (wyższy priorytet, niższy numer priorytetu, np. 10): dopasowanie do możliwości połączenia (np.
- Reguła dotycząca tylko identyfikatora aplikacji w systemie operacyjnym (starsza wersja):
- Operatorzy mogą nadal korzystać z dotychczasowych reguł URSP opartych na identyfikatorze systemu operacyjnego i identyfikatorze aplikacji w systemie operacyjnym. Urządzenia z Androidem 17 i nowszym nadal przechodzą test
OSAppId, więc zarówno nowe, jak i starsze urządzenia spełniają te reguły.
- Operatorzy mogą nadal korzystać z dotychczasowych reguł URSP opartych na identyfikatorze systemu operacyjnego i identyfikatorze aplikacji w systemie operacyjnym. Urządzenia z Androidem 17 i nowszym nadal przechodzą test
- Reguła łączona (warunek ORAZ):
- Operatorzy mogą określać zarówno identyfikator systemu operacyjnego, jak i identyfikator aplikacji systemu operacyjnego oraz możliwości połączenia w ramach jednego deskryptora ruchu. Ta reguła pasuje tylko do urządzeń z Androidem 17 lub nowszym z AIDL 2.5 lub nowszym.
Przykładowe reguły URSP
W tabelach poniżej przedstawiono przykładowe reguły URSP dla ruchu w sieciach firmowych, CBS, o niskim opóźnieniu, o wysokiej przepustowości, ujednoliconej komunikacji i domyślnego.
Enterprise 1
Obsługa profilu Enterprise 1 jest dostępna na urządzeniach z Androidem 12 i nowszym.
Oto przykładowa reguła URSP dla ruchu ENTERPRISE1:
| Reguła URSP 1 (ENTERPRISE1) | |
|---|---|
| Pierwszeństwo | 1 (0x01) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | przedsiębiorstwo |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | przedsiębiorstwo |
Enterprise 2
Obsługa Enterprise 2 jest dostępna na urządzeniach z Androidem 13 i nowszym.
Oto przykładowa reguła URSP dla ruchu ENTERPRISE2:
| Reguła 2 URSP (ENTERPRISE2) | |
|---|---|
| Pierwszeństwo | 2 (0x02) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | enterprise2 |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | enterprise2 |
Enterprise 3
Obsługa profilu Enterprise 3 jest dostępna na urządzeniach z Androidem 13 i nowszym.
Oto przykładowa reguła URSP dla ruchu ENTERPRISE3:
| Reguła URSP 3 (ENTERPRISE3) | |
|---|---|
| Pierwszeństwo | 3 (0x03) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | enterprise3 |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | enterprise3 |
Enterprise 4
Obsługa Enterprise 4 jest dostępna na urządzeniach z Androidem 13 i nowszym.
Oto przykładowa reguła URSP dla ruchu ENTERPRISE4:
| Reguła URSP 4 (ENTERPRISE4) | |
|---|---|
| Pierwszeństwo | 4 (0x04) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | firma4 |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | firma4 |
Enterprise 5
Obsługa profilu Enterprise 5 jest dostępna na urządzeniach z Androidem 13 i nowszym.
Oto przykładowa reguła URSP dla ruchu ENTERPRISE5:
| Reguła 5 URSP (ENTERPRISE5) | |
|---|---|
| Pierwszeństwo | 5 (0x05) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | enterprise5 |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | enterprise5 |
CBS
Obsługa CBS jest dostępna na urządzeniach z Androidem 13 i nowszym. Oto przykładowa reguła URSP dla ruchu CBS:
| Reguła 6 URSP (CBS) | |
|---|---|
| Pierwszeństwo | 6 (0x06) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | cbs |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | cbs |
Małe opóźnienie z możliwością połączenia
Obsługa możliwości połączenia w regułach URSP jest dostępna na urządzeniach z Androidem 17 i nowszym. Oto przykładowa reguła URSP dla ruchu o niskim opóźnieniu, która korzysta z deskryptora możliwości połączenia:
| Reguła URSP 7 (małe opóźnienie z możliwością połączenia) | |
|---|---|
| Pierwszeństwo | 7 (0x07) |
| Opis ruchu 1 | |
| Typ możliwości połączenia | 0xA6 (166: interaktywne w czasie rzeczywistym) |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | opóźnienie |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | opóźnienie |
Małe opóźnienie z parametrem OSAppId
Obsługa krótkiego czasu oczekiwania jest dostępna na urządzeniach z Androidem 13 i nowszym.
Poniżej znajdziesz przykładową regułę URSP dla LOW_LATENCY
ruchu korzystającego z parametru OSAppId:
| Reguła URSP 8 (małe opóźnienie z wersją zastępczą OSAppId) | |
|---|---|
| Pierwszeństwo | 8 (0x08) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | opóźnienie |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | opóźnienie |
Duża przepustowość z możliwością połączenia
Obsługa możliwości połączenia w regułach URSP jest dostępna na urządzeniach z Androidem 17 i nowszym. Oto przykład reguły URSP dla ruchu o dużej przepustowości, która korzysta z deskryptora możliwości połączenia:
| Reguła 9 URSP (wysoka przepustowość z możliwością połączenia) | |
|---|---|
| Pierwszeństwo | 9 (0x09) |
| Opis ruchu 1 | |
| Typ możliwości połączenia | 0xA3 (163: strumieniowe przesyłanie danych do urządzenia) |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | bandwidth, |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | bandwidth, |
Duża przepustowość z identyfikatorem OSAppId
Obsługa dużej przepustowości jest dostępna w Androidzie 13 i nowszych wersjach.
Poniżej znajdziesz przykładową regułę URSP dla HIGH_BANDWIDTH
ruchu korzystającego z parametru OSAppId:
| Reguła URSP 10 (wysoka przepustowość z wartością OSAppId jako rezerwą) | |
|---|---|
| Pierwszeństwo | 10 (0x0A) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | bandwidth, |
| Deskryptor wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | bandwidth, |
Komunikacja zintegrowana z możliwością połączenia
Obsługa ujednoliconej komunikacji jest dostępna na urządzeniach z Androidem 17 i nowszym. Poniżej znajduje się przykładowa reguła URSP dla ruchu UNIFIED_COMMUNICATIONS korzystającego z możliwości połączenia.
Ponieważ ruch związany z komunikacją ujednoliconą jest kierowany przez domyślne połączenie do transmisji danych w internecie, w deskryptorze wyboru trasy nie jest wymagany dedykowany punkt APN (DNN):
| Reguła URSP 11 (komunikacja ujednolicona z możliwością połączenia) | |
|---|---|
| Pierwszeństwo | 11 (0x0B) |
| Opis ruchu 1 | |
| Typ możliwości połączenia | 0xA7 (167: Unified communications) |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
Ujednolicona komunikacja z OSAppId
Obsługa ujednoliconej komunikacji jest dostępna na urządzeniach z Androidem 17 i nowszym. Poniżej znajdziesz przykładową regułę URSP dla ruchu UNIFIED_COMMUNICATIONS z użyciem parametru OSAppId:
| Reguła 12 URSP (ujednolicona komunikacja z wartością zastępczą OSAppId) | |
|---|---|
| Pierwszeństwo | 12 (0x0C) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 0x97A498E3FC925C9489860333D06E4E47215052494F524954495A455F554E49464945445F434F4D4D554E49434154494F4E53 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
Domyślny
| Reguła 13 URSP (domyślna) | |
|---|---|
| Pierwszeństwo | 13 (0x0D) |
| Opis ruchu 1 | |
| dopasowanie do wszystkich | Nie dotyczy |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
Testowanie
Aby przetestować podział sieci 5G, użyj tego testu ręcznego.
Aby skonfigurować urządzenie do testowania:
Sprawdź, czy zasady URSP są skonfigurowane z regułą inną niż domyślna, która pasuje do kategorii przedsiębiorstwa, a odpowiedni deskryptor wyboru trasy mapuje kategorię przedsiębiorstwa na wycinek sieci przedsiębiorstwa oraz czy istnieje reguła domyślna kierująca ruch do domyślnego wycinka sieci internetowej.
Sprawdź, czy na urządzeniu jest skonfigurowany profil służbowy.
Włączanie korzystania z funkcji podziału sieci za pomocą kontrolera zasad urządzeń
Aby przetestować działanie podziału sieci 5G:
- Sprawdź, czy sesja PDU została nawiązana z segmentem sieciowym przedsiębiorstwa (np. za pomocą konkretnego adresu IP) i czy aplikacje w profilu służbowym korzystają z tej sesji PDU.
- Sprawdź, czy została utworzona osobna sesja PDU z domyślnym wycinkiem sieci internetowej i czy aplikacje w profilu osobistym korzystają z tej sesji.
Dodatkowa sprzedaż segmentacji sieci 5G
Funkcja dodatkowej sprzedaży segmentacji sieci 5G, dostępna od Androida 14 QPR1, umożliwia operatorom oferowanie użytkownikom ulepszonych możliwości sieci (opóźnienia i przepustowość) za pomocą segmentacji sieci 5G.
Funkcja dodatkowej sprzedaży segmentacji sieci 5G korzysta z odpowiedzi TS.43 z serwera uprawnień operatora, aby kierować procesem zakupu. Operatorzy mogą użyć odpowiedzi, aby określić adres URL widoku internetowego zakupu operatora, wysłać dodatkowe dane do widoku internetowego i wskazać, czy wycinek jest udostępniony i dostępny w sieci operatora.
Operatorzy mogą dostosowywać działanie funkcji ulepszonej segmentacji sieci 5G za pomocą konfiguracji operatora, które określają, czy można wysyłać prośby o zakup, kiedy aplikacje mogą prosić o funkcje premium i jak długo platforma telefoniczna czeka na odpowiedzi od użytkownika lub sieci.
Funkcja dodatkowej sprzedaży segmentacji sieci 5G udostępnia interfejs o nazwie
DataBoostWebServiceFlow,
który umożliwia komunikację między Androidem a widokiem internetowym operatora.
Rysunek 2 przedstawia proces zakupu dodatkowej usługi segmentacji sieci 5G:
Rysunek 2. Proces zakupu dodatkowej usługi segmentacji sieci 5G.
TS.43 entitlement process
Gdy użytkownik poprosi o zaawansowane funkcje sieciowe, platforma Telephony zażąda konfiguracji uprawnień do usługi w przypadku żądanej funkcji premium. Jeśli odpowiedź TS.43 jest prawidłowa, platforma telefoniczna używa pól z odpowiedzi HTTP do obsługi prośby o zakup.
Pola zakupu wycinka
Konfiguracja uprawnień TS.43 zawiera te pola zakupu segmentu:
- Stan uprawnienia
Klucz:
EntitlementStatusTyp:
intObsługiwane wartości:
0(wyłączone),1(włączone),2(niezgodne),3(wdrażanie),4(uwzględnione)- Stan obsługi administracyjnej
Klucz:
ProvStatusTyp:
intObsługiwane wartości:
0(nie przydzielono),1(przydzielono),2(niedostępne),3(w trakcie)
Platforma telefoniczna wykorzystuje kombinację stanu uprawnień i stanu udostępniania, aby określić bieżący stan zakupu wycinka sieci. Wynik może być jednym z tych rodzajów:
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Jeśli stan uprawnień to 1 (włączony), a stan udostępniania to 0 (nieudostępniony), platforma telefoniczna wyświetla użytkownikowi powiadomienie o możliwości zakupu dodatku w widoku internetowym operatora. W tabeli poniżej opisujemy działanie platformy telefonicznej w przypadku różnych kombinacji wartości stanu udostępniania i uprawnień.
| Stan udostępniania | |||||
|---|---|---|---|---|---|
Nie udostępniono (0) |
Zainicjowano (1) |
Niedostępne (2) |
W trakcie (3) |
||
| Stan uprawnienia | Wyłączone (0) |
Niepowodzenie | Niepowodzenie | Niepowodzenie | Niepowodzenie |
Włączone (1) |
Pokaż WebView | Mam już ten produkt | Mam już ten produkt | W toku | |
Niekompatybilne (2) |
Niepowodzenie | Niepowodzenie | Niepowodzenie | Niepowodzenie | |
Provisioning (3) |
Błąd operatora | Błąd operatora | W toku | W toku | |
Uwzględniono (4) |
Błąd operatora | Mam już ten produkt | Mam już ten produkt | Błąd operatora | |
Pola przepływu usługi
Odpowiedź TS.43 określa adres URL, dane użytkownika i typ treści, aby dostosować działanie widoku internetowego zakupu u operatora. Jeśli typ treści nie jest określony, adres URL jest wczytywany jako żądanie GET. Jeśli dane użytkownika istnieją, są dołączane do adresu URL jako parametr zapytania (np. https://www.android.com?encodedValue=Base64EncodedUserData). Jeśli nie istnieją, adres URL jest używany w niezmienionej postaci (np. https://www.android.com).
Jeśli typ zawartości jest określony w formacie JSON lub XML, adres URL jest wczytywany jako żądanie POST, a dane użytkownika (dekodowane, jeśli są zakodowane w Base64) są wysyłane jako dane żądania POST.
- URL
Klucz:
ServiceFlow_URLTyp:
StringPrzykład:
"https://www.android.com"- Dane użytkownika
Klucz:
ServiceFlow_UserDataTyp:
StringPrzykład:
"encodedValue=Base64EncodedUserData"- Typ treści
Klucz:
ServiceFlow_ContentsTypeTyp:
StringObsługiwane wartości:
0(nieokreślone),1(JSON),2(XML)
Konfiguracje operatora
Poniżej znajdziesz konfiguracje operatora, które można dostosować, aby zmienić działanie funkcji dodatkowej sprzedaży segmentacji sieci 5G.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYLista obsługiwanych funkcji premium. To jest tablica liczb całkowitych
TelephonyManager.PremiumCapability. Te funkcje premium mają taką samą wartość jak odpowiednia klasaNetworkCapabilities.NetCapability. Jeśli zostanie zgłoszone żądanie funkcji premium, która nie jest uwzględniona w tej konfiguracji, żądanie zakupu zakończy się niepowodzeniem z wynikiemCARRIER_DISABLED.W Androidzie 14 obsługiwany jest tylko format
PREMIUM_CAPABILITY_PRIORITIZE_LATENCY.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTMaksymalna dzienna liczba wyświetleń powiadomienia o dodatkowej sprzedaży użytkownikowi. Jeśli osiągnięto dzienny limit, powiadomienie o dodatkowej sprzedaży nie jest wyświetlane, a żądania zakupu (w tym żądania serwera uprawnień) są ograniczane do północy następnego dnia. Żądania zakupu przesłane po osiągnięciu dziennego limitu maksymalnego kończą się niepowodzeniem i zwracają wynik
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INTMiesięczna maksymalna liczba wyświetleń powiadomienia o dodatkowej sprzedaży użytkownikowi. Jeśli miesięczny limit zostanie osiągnięty, powiadomienie o dodatkowej sprzedaży nie będzie wyświetlane, a żądania zakupu (w tym żądania serwera uprawnień) będą ograniczane do pierwszego dnia kolejnego miesiąca. Prośby o zakup złożone po osiągnięciu miesięcznego limitu maksymalnego kończą się niepowodzeniem i zwracają wynik
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGAdres URL zakupu operatora zapasowego, który ma być wyświetlany użytkownikowi po kliknięciu powiadomienia o dodatkowej sprzedaży. Jeśli adres URL zakupu nie zostanie znaleziony w odpowiedzi TS.43 z serwera uprawnień, zamiast niego używana jest ta wartość. Jeśli ani adres URL z odpowiedzi TS.43, ani konfiguracja operatora nie są prawidłowe, prośba o zakup kończy się niepowodzeniem z wynikiem
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLOkreśla, czy można kupować funkcje premium, gdy urządzenie jest połączone z siecią LTE. Jeśli
true, prośby o zakup można przesyłać zarówno w sieci LTE, jak i w sieci New Radio (NR). Jeślifalse, prośby o zakup można przesyłać tylko w sieci NR, a prośby przesyłane w sieci LTE kończą się niepowodzeniem z wynikiemPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGCzas, przez jaki użytkownikowi będzie wyświetlane powiadomienie o dodatkowej sprzedaży, zanim zostanie ono automatycznie anulowane. Gdy powiadomienie zostanie anulowane, kolejne żądania będą ograniczane i zwrócą wynik
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGCzas, przez jaki kolejne prośby o zakup powinny być ograniczane po niepowodzeniu z powodu przekroczenia limitu czasu lub anulowania przez użytkownika. Jeśli użytkownik nie kliknie powiadomienia o dodatkowej ofercie zakupu w czasie określonym przez
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGlub jeśli anuluje powiadomienie albo je zamknie, rozpocznie się odliczanie czasu do ponowienia. Gdy ten licznik czasu jest aktywny, prośby o zakup kończą się niepowodzeniem z wynikiemPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGCzas, przez jaki kolejne żądania zakupu powinny być ograniczane po niepowodzeniu z powodu operatora lub sieci. Jeśli kontrola uprawnień zakończy się niepowodzeniem, adres URL jest niedostępny lub adres URL zakupu u operatora wskazuje na niepowodzenie, uruchamia się ten licznik czasu wycofania. Gdy ten minutnik jest aktywny, prośby o zakup kończą się niepowodzeniem z wynikiem
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONGCzas, w którym sieć musi skonfigurować podział sieci na potrzeby funkcji zakupu dostępu premium. W tym okresie kolejne prośby o zakup są blokowane i zwracają wynik
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Jeśli sieci nie uda się na czas skonfigurować podziału sieci, aplikacje mogą ponownie poprosić o zakup funkcji premium. Telefonia nie uznaje zakupu za zakończony, dopóki nie zostanie wysłana odpowiednia konfiguracja podziału, niezależnie od tego, czy użytkownik zapłacił operatorowi, czy nie.
Interfejs JavaScript
Gdy użytkownik kliknie powiadomienie o zwiększeniu szybkości sieci, wyświetli mu się obiekt WebView z adresem URL zakupu u operatora. Operatorzy mogą używać interfejsów API udostępnianych w DataBoostWebServiceFlow interfejsie JavaScript na swojej stronie zakupu, aby komunikować się z aplikacją do zakupu wycinka sieci.
Witryna przewoźnika może uzyskać dostęp do żądanej funkcji premium za pomocą metody
getRequestedCapability().
Jeśli zakup się powiedzie, witryna operatora musi powiadomić aplikację do zakupu wycinka za pomocą parametru notifyPurchaseSuccessful() lub notifyPurchaseSuccessful(duration), gdzie duration jest parametrem opcjonalnym wskazującym zamierzony czas trwania wycinka.
Jeśli zakup się nie powiedzie, witryna operatora musi powiadomić aplikację do zakupu wycinka za pomocą metody notifyPurchaseFailed(code, reason), gdzie code to kod błędu wskazujący przyczynę niepowodzenia, a reason to czytelna dla użytkownika przyczyna niepowodzenia, jeśli kod błędu jest nieznany.
Jeśli żadna z tych metod odpowiedzi nie zostanie wywołana, zakup nie zostanie uznany za zakończony, a prośba o zakup w końcu wygaśnie.
Poniżej znajdziesz prawidłowe kody błędów, które witryna przewoźnika może zwrócić w przypadku nieudanej transakcji:
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
Po zakończeniu zakupu operator musi zaktualizować reguły URSP na urządzeniu użytkownika o PRIORITIZE_LATENCY.
Automatyczne kierowanie segmentacji sieci 5G w przypadku połączeń głosowych i wideo OTT
Android 17 obsługuje automatyczne kierowanie połączeń głosowych i wideo OTT do połączeń sieciowych premium. Ta funkcja umożliwia systemowi automatyczne kierowanie ruchu z połączeń głosowych i wideo do dedykowanego interfejsu sieciowego premium (np. premium 5G slice lub premium 4G PDN) bez konieczności wprowadzania zmian w stosie sieciowym aplikacji.
To rozwiązanie na poziomie platformy eliminuje konieczność wyraźnego żądania przez deweloperów aplikacji możliwości sieciowych, zapewniając płynne działanie zarówno deweloperom, jak i użytkownikom.
Jak to działa
Android obsługuje automatyczne przekierowywanie połączeń dzięki dodatkom do platform łączności i telekomunikacji. Funkcja automatycznego kierowania działa w ten sposób:
- Wykrywanie połączeń: system korzysta z interfejsów API Telecom Jetpack używanych przez aplikacje OTT do wykrywania początku i końca połączeń głosowych lub wideo.
- Zarządzanie połączeniami: po wykryciu połączenia Android wyświetla wyznaczony interfejs sieci premium, np. ujednolicony wycinek komunikacyjny.
- Kierowanie ruchem: podczas połączenia platforma identyfikuje aplikację na podstawie jej identyfikatora UID i automatycznie kieruje jej ruch do połączenia sieciowego premium.
- Powrót po zakończeniu połączenia: po zakończeniu połączenia platforma usuwa regułę routingu, a ruch aplikacji wraca do domyślnej sieci systemowej w przypadku ruchu niezwiązanego z połączeniami (np. wiadomości).
Wymagania
Aby obsługiwać automatyczne przekierowywanie połączeń OTT, musisz spełniać te wymagania:
- Operatorzy: muszą oferować ujednoliconą część komunikacyjną, konfigurując odpowiednie reguły URSP (za pomocą możliwości połączenia lub identyfikatora OSAppId dla ruchu ujednoliconej komunikacji).
- Aplikacje: muszą używać interfejsów API Android Telecom Jetpack, aby umożliwić systemowi wykrywanie stanów połączeń.
- Producenci urządzeń: wymagany jest Android 17 lub nowszy.