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, które umożliwiają korzystanie z istniejących interfejsów API łączności wymaganych 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 do zasad 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 próśb o połączenie z siecią od 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ą interfejsów API, takich jak
NetworkCallback,getActiveNetwork,getNetworkCapabilities.ConnectivityManager
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 danych i zawiera te parametry
do obsługi segmentacji sieci 5G:
trafficDescriptor: Określa deskryptor ruchu wysyłany do modemusliceInfo: 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.
- Upewnij się, że w pełni zarządzane urządzenia lub urządzenia należące do pracowników z utworzonym profilem służbowym
obsługują 5G SA i mają modemy, które obsługują interfejs
setupDataCall_1_6API. - Współpraca z partnerem telekomunikacyjnym w zakresie konfiguracji i wydajności segmentu sieci lub charakterystyki umowy SLA.
Włączanie segmentacji sieci 5G na urządzeniach skonfigurowanych z profilem służbowym
W przypadku urządzeń z profilem służbowym funkcja podziału sieci 5G jest domyślnie wyłączona w AOSP. 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 sieci, w tym dla ruchu w sieciach korporacyjnych, CBS, o niskich opóźnieniach i o dużej przepustowości. Podczas konfigurowania reguł URSP dla różnych kategorii wycinków sieci operatorzy muszą używać tych wartości specyficznych dla Androida.
| Identyfikator | Wartość | Opis |
|---|---|---|
| OSId | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
Identyfikator OSId w przypadku Androida to identyfikator UUID w wersji 5 wygenerowany w przestrzeni nazw ISO OID i z nazwą „Android”. |
Operatorzy muszą skonfigurować reguły URSP dla każdego wycinka ruchu z komponentem deskryptora ruchu jako „Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym”. Na przykład wycinek „ENTERPRISE” musi mieć wartość 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
Ta wartość jest połączeniem identyfikatora OSId, długości identyfikatora OSAppId (0x0A) i identyfikatora OSAppId.
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 wycinkó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 |
Przykładowe reguły URSP
W tabelach poniżej przedstawiono przykładowe reguły URSP dla ruchu w sieciach firmowych, CBS, o niskim czasie oczekiwania, o dużej przepustowości 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 (firma1) | |
|---|---|
| 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 |
| Opis 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 URSP nr 2 (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 |
| Opis 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 3 URSP (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 |
| Opis 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 nr 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 | enterprise4 |
| Opis wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | enterprise4 |
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 URSP nr 5 (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 |
| Opis 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 |
| Opis wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | cbs |
Małe opóźnienie
Obsługa krótkiego czasu oczekiwania jest dostępna na urządzeniach z Androidem 13 i nowszym. Oto przykładowa reguła URSP dla ruchu LOW_LATENCY:
| Reguła URSP nr 7 (małe opóźnienie) | |
|---|---|
| Pierwszeństwo | 7 (0x07) |
| 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 |
| Opis wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | opóźnienie |
Duża przepustowość
Obsługa dużej przepustowości jest dostępna na urządzeniach z Androidem 13 i nowszym. Oto przykładowa reguła URSP dla ruchu HIGH_BANDWIDTH:
| Reguła URSP 8 (duża przepustowość) | |
|---|---|
| Pierwszeństwo | 8 (0x08) |
| Opis ruchu 1 | |
| Identyfikator systemu operacyjnego + identyfikator aplikacji w systemie operacyjnym | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Opis wyboru trasy 1 | |
| Pierwszeństwo | 1 (0x01) |
| Komponent 1. S-NSSAI | SST:XX SD:YYYYYY |
| Komponent 2: DNN | bandwidth, |
| Opis wyboru trasy 2 | |
| Pierwszeństwo | 2 (0x02) |
| Komponent 1: DNN | bandwidth, |
Domyślny
| Reguła URSP nr 9 (domyślna) | |
|---|---|
| Pierwszeństwo | 9 (0x09) |
| 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 dla przedsiębiorstw 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 wycinka:
- 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 udostępniono),1(udostępniono),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) |
Provisioned (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 | |
Wliczone w cenę (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żesz dostosować, aby zmienić działanie funkcji dodatkowej sprzedaży w przypadku 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 zostanie osiągnięty dzienny limit, powiadomienie o dodatkowej sprzedaży nie będzie wyświetlane, a żądania zakupu (w tym żądania serwera uprawnień) będą 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 się wyświetlać, a żądania zakupu (w tym żądania serwera uprawnień) będą ograniczane do pierwszego dnia następnego 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, żądania zakupu mogą być wysyłane 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, żądania zakupu 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 błąd, uruchamia się ten licznik czasu wycofywania. 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 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 sieci za pomocą notifyPurchaseSuccessful() lub notifyPurchaseSuccessful(duration), gdzie duration jest opcjonalnym parametrem 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 człowieka 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 ukończony, a prośba o zakup w końcu wygaśnie.
Poniżej znajdziesz prawidłowe kody błędów, które mogą być zwracane przez witrynę przewoźnika 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. do segmentu 5G premium lub połączenia PDN 4G premium) 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. ujednoliconą część komunikacyjną.
- 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. Operatorzy muszą wypełnić URSP konkretnym kodem
OSAppIDw przypadku ruchu związanego z komunikacją ujednoliconą. - Aplikacje: muszą używać interfejsów API Android Telecom Jetpack, aby system mógł wykrywać stany połączeń.
- Producenci urządzeń: wymagany jest Android 17 lub nowszy.