Pemotongan jaringan 5G

Untuk perangkat yang menjalankan Android 12 atau yang lebih tinggi, Android menyediakan dukungan untuk network slicing 5G, penggunaan virtualisasi jaringan untuk membagi koneksi jaringan tunggal menjadi beberapa koneksi virtual yang berbeda yang menyediakan jumlah resource yang berbeda untuk berbagai jenis traffic. Network slicing 5G memungkinkan operator jaringan mendedikasikan sebagian jaringan untuk menyediakan fitur tertentu bagi segmen pelanggan tertentu. Android 12 memperkenalkan kemampuan pengirisan jaringan perusahaan 5G berikut, yang dapat disediakan oleh operator jaringan kepada klien perusahaan mereka:

Pengirisan perangkat perusahaan untuk perangkat terkelola sepenuhnya

Untuk perusahaan yang menyediakan perangkat perusahaan yang terkelola sepenuhnya kepada karyawannya, penyedia jaringan dapat menyediakan satu atau beberapa slice jaringan perusahaan aktif yang menjadi tujuan perutean traffic di perangkat perusahaan. Mulai Android 12, Android memungkinkan operator menyediakan slice perusahaan melalui aturan URSP, bukan menyiapkan slice melalui APN.

Pengelompokan aplikasi bisnis perusahaan untuk perangkat dengan profil kerja

Untuk perusahaan yang menggunakan solusi profil kerja, Android 12 memungkinkan perangkat merutekan traffic dari semua aplikasi di profil kerja ke slice jaringan perusahaan. Perusahaan dapat mengaktifkan kemampuan ini melalui Pengontrol Kebijakan Perangkat (DPC).

Solusi profil kerja menyediakan tingkat autentikasi dan kontrol akses otomatis yang diperlukan perusahaan untuk memastikan bahwa hanya traffic dari aplikasi perusahaan di profil kerja yang dirutekan ke slice jaringan perusahaan. Aplikasi di profil kerja tidak perlu dimodifikasi untuk meminta slice jaringan perusahaan secara eksplisit.

Cara kerja network slicing 5G di AOSP

Android 12 memperkenalkan dukungan untuk pengirisan jaringan 5G melalui penambahan pada codebase telepon di AOSP dan modul Tethering untuk menggabungkan API konektivitas yang ada yang diperlukan untuk pengirisan jaringan.

Platform teleponi Android menyediakan HAL dan API teleponi untuk mendukung slicing berdasarkan permintaan jaringan yang diajukan oleh kode jaringan inti dan kemampuan slicing 5G di modem. Gambar 1 menjelaskan komponen fitur slicing jaringan 5G.

Komponen segmentasi jaringan 5G

Gambar 1. Arsitektur segmentasi jaringan 5G di AOSP.

Platform teleponi dan konektivitas mendukung:

  • Mengonversi permintaan jaringan untuk kategori slice menjadi deskriptor traffic yang kemudian diteruskan ke modem untuk pencocokan traffic URSP dan pemilihan rute
  • Melakukan penggantian ke jaringan default jika slice jaringan perusahaan tidak tersedia
  • Merutekan traffic dari semua aplikasi di profil kerja ke koneksi yang sesuai
  • Mendukung pengelompokan perusahaan

    • Mendeteksi keberadaan profil kerja di perangkat
    • Memeriksa izin atau petunjuk rute yang diberikan dari DPC yang digunakan oleh admin IT perusahaan

Layanan jaringan inti mencakup perubahan berikut pada modul Tethering di Android 12:

  • Menambahkan sebagian besar class API publik atau sistem android.net.* ke modul Tethering
  • Memperluas batas modul Tethering untuk mencakup:

    • 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
  • Memindahkan kode VPN dari modul Tethering

Android 12 memindahkan kode dengan kemampuan berikut ke modul Tethering:

  • Menerima permintaan dari aplikasi untuk koneksi jaringan
  • Menerima permintaan dari sistem (misalnya, "tempatkan aplikasi ini di slice perusahaan"; diperkenalkan di Android 12)
  • Mengirim permintaan dari sistem ke kode telepon yang mencoba menyiapkan jaringan atau slice dengan melalui HAL API dan modem
  • Memberi tahu netd cara merutekan traffic berdasarkan per aplikasi (diperkenalkan di Android 12)
  • Memberi tahu aplikasi tentang apa yang terjadi pada traffic jaringannya melalui API ConnectivityManager seperti NetworkCallback, getActiveNetwork, getNetworkCapabilities.

Penerapan

Untuk mendukung slicing 5G di perangkat, perangkat harus memiliki modem yang mendukung HAL IRadio 1.6 yang memiliki API setupDataCall_1_6. API ini menyiapkan koneksi data dan menyertakan parameter berikut untuk mendukung slicing 5G:

  • trafficDescriptor: Menentukan deskriptor traffic yang dikirim ke modem
  • sliceInfo: Menentukan informasi untuk slice jaringan yang akan digunakan jika terjadi pengalihan dari EPDG ke 5G
  • matchAllRuleAllowed: Menentukan apakah penggunaan aturan URSP default yang cocok dengan semua diizinkan. Telephony menyetelnya ke benar (true) untuk jaringan default tetapi tidak untuk slice. Aturan cocokkan semua diterapkan ke jaringan default. Jika aplikasi meminta slice tertentu yang tidak tersedia, slice tertentu tersebut dilaporkan sebagai tidak tersedia. Untuk aplikasi perusahaan, framework Telephony dapat melakukan penggantian ke jaringan default jika jaringan perusahaan tidak tersedia.

Modem juga harus menerapkan getSlicingConfig API kecuali jika dilaporkan tidak didukung oleh getHalDeviceCapabilities API.

Persyaratan Enterprise

Berikut ini persyaratan bagi perusahaan untuk menggunakan pengirisan jaringan 5G di perangkat dalam deployment perusahaan Android.

  • Pastikan perangkat yang terkelola sepenuhnya atau perangkat milik karyawan yang disiapkan dengan profil kerja kompatibel dengan 5G SA dengan modem yang mendukung API setupDataCall_1_6.
  • Bekerja sama dengan partner operator dalam penyiapan dan performa slice atau karakteristik SLA.

Mengaktifkan slicing 5G di perangkat yang disiapkan dengan profil kerja

Untuk perangkat yang disiapkan dengan profil kerja, pengirisan jaringan 5G dinonaktifkan secara default di AOSP. Untuk mengaktifkan segmentasi jaringan, admin IT perusahaan dapat mengaktifkan atau menonaktifkan perutean traffic aplikasi profil kerja ke segmen jaringan perusahaan berdasarkan per karyawan melalui EMM DPC, yang menggunakan metode setPreferentialNetworkServiceEnabled di API DevicePolicyManager (DPM) (diperkenalkan di Android 12).

Vendor EMM dengan DPC kustom harus mengintegrasikan API DevicePolicyManager untuk mendukung klien perusahaan.

Aturan URSP

Bagian ini mencakup informasi bagi operator tentang cara mengonfigurasi aturan URSP untuk berbagai kategori slice, termasuk traffic komunikasi terpadu, CBS, latensi rendah, bandwidth tinggi, dan perusahaan.

Saat mengonfigurasi aturan URSP, operator dapat menggunakan deskriptor traffic berdasarkan faktor-faktor berikut:

  • Jenis ID OS dan ID Aplikasi OS, jenis komponen 0x08, didukung di Android 12 dan yang lebih tinggi
  • Jenis kemampuan koneksi, jenis komponen 0x90, didukung di Android 17 dan yang lebih tinggi

ID OS dan ID Aplikasi OS

Saat mengonfigurasi aturan URSP menggunakan komponen deskriptor traffic jenis ID OS dan ID Aplikasi OS, operator dapat menggunakan nilai ID OS dan ID Aplikasi OS khusus Android berikut.

ID Nilai Deskripsi
ID OS 97a498e3-fc92-5c94-8986-0333d06e4e47 ID OS untuk Android adalah UUID versi 5 yang dibuat dengan namespace ISO OID dan nama Android.

Operator yang mengonfigurasi aturan URSP menggunakan jenis ID OS dan ID Aplikasi OS harus mengonfigurasi setiap traffic slice dengan komponen deskriptor traffic sebagai gabungan ID OS, panjang ID Aplikasi OS (0x0A), dan ID Aplikasi OS. Misalnya, slice ENTERPRISE harus memiliki nilai 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345. Untuk mengetahui informasi selengkapnya tentang jenis komponen deskriptor traffic, lihat 3GPP TS 24.526 Tabel 5.2.1.

Tabel berikut menjelaskan nilai OSAppId untuk berbagai kategori slice.

Kategori slice OSAppId Deskripsi
ENTERPRISE 0x454E5445525052495345 OSAppId adalah representasi array byte dari string ENTERPRISE
ENTERPRISE2 0x454E544552505249534532 OSAppId adalah representasi array byte dari string ENTERPRISE2
ENTERPRISE3 0x454E544552505249534533 OSAppId adalah representasi array byte dari string ENTERPRISE3
ENTERPRISE4 0x454E544552505249534534 OSAppId adalah representasi array byte dari string ENTERPRISE4
ENTERPRISE5 0x454E544552505249534535 OSAppId adalah representasi array byte dari string ENTERPRISE5
CBS 0x434253 OSAppId adalah representasi array byte dari string CBS
PRIORITIZE_LATENCY 0x5052494f524954495a455f4c4154454e4359 OSAppId adalah representasi array byte dari string PRIORITIZE_LATENCY
PRIORITIZE_BANDWIDTH 0x5052494f524954495a455f42414e445749445448 OSAppId adalah representasi array byte dari string PRIORITIZE_BANDWIDTH
PRIORITIZE_UNIFIED_COMMUNICATIONS 0x5052494f524954495a455f554e49464945445f434f4d4d554e49434154494f4e53 OSAppId adalah representasi array byte dari string PRIORITIZE_UNIFIED_COMMUNICATIONS

Kami tidak berencana memperkenalkan nilai OSAppId baru. Kami akan meningkatkan deskriptor traffic kemampuan koneksi sesuai kebutuhan.

Kemampuan koneksi

Mulai Android 17 dan yang lebih tinggi (Radio HAL AIDL 2.5 dan yang lebih tinggi), Android mendukung komponen deskriptor traffic kemampuan koneksi (jenis 0x90), yang ditentukan dalam 3GPP TS 24.526 Tabel 5.2.1.

Saat aplikasi atau layanan sistem meminta jaringan dengan kemampuan tertentu, stack data teleponi Android memetakan NetworkCapabilities yang diminta ke nilai kemampuan koneksi standar yang diisi dalam TrafficDescriptor yang dikirim ke modem selama penyiapan panggilan data (setupDataCall). Meskipun spesifikasi 3GPP mengizinkan beberapa kemampuan koneksi dalam satu deskriptor, framework teleponi Android 17 memetakan beberapa kemampuan koneksi yang diminta ke satu kemampuan koneksi.

Tabel berikut menjelaskan pemetaan default dari kemampuan jaringan Android ke kemampuan koneksi 3GPP:

Kemampuan jaringan Kemampuan koneksi Nilai (hex atau desimal) Deskripsi
NET_CAPABILITY_IMS CONNECTION_CAPABILITY_IMS 0x01 (1) Komunikasi suara dan video IMS
NET_CAPABILITY_MMS CONNECTION_CAPABILITY_MMS 0x02 (2) Traffic MMS
NET_CAPABILITY_SUPL CONNECTION_CAPABILITY_SUPL 0x04 (4) Secure User Plane Location (SUPL)
NET_CAPABILITY_INTERNET CONNECTION_CAPABILITY_INTERNET 0x08 (8) Traffic data internet default
NET_CAPABILITY_PRIORITIZE_LATENCY CONNECTION_CAPABILITY_REAL_TIME_INTERACTIVE 0xA6 (166) Traffic interaktif real-time (misalnya, game, AR/VR)
NET_CAPABILITY_PRIORITIZE_BANDWIDTH CONNECTION_CAPABILITY_DOWNLINK_STREAMING 0xA3 (163) Lalu lintas streaming bandwidth tinggi downlink
NET_CAPABILITY_PRIORITIZE_UNIFIED_COMMUNICATIONS CONNECTION_CAPABILITY_UNIFIED_COMMUNICATIONS 0xA7 (167) Komunikasi terpadu (misalnya, panggilan suara atau video OTT)

Konfigurasi URSP operator dan kompatibilitas mundur

Untuk memastikan operasi yang lancar di seluruh perangkat dengan versi HAL dan OS yang berbeda, operator harus mempertimbangkan perilaku berikut saat menyediakan aturan URSP:

  • Perangkat yang menjalankan Android 16 atau yang lebih lama (Radio HAL AIDL 2.4 dan yang lebih lama): Modem menerima setidaknya OSAppId dalam deskriptor traffic.
  • Perangkat yang menjalankan Android 17 atau yang lebih tinggi (AIDL 2.5 dan yang lebih tinggi): Untuk kemampuan slice premium (seperti latensi rendah, bandwidth tinggi, dan komunikasi terpadu), platform mengisi OSAppId, ConnectionCapability, atau keduanya dalam deskriptor traffic.

Operator dapat mengonfigurasi aturan URSP menggunakan salah satu pendekatan berikut:

  1. Aturan berbasis preseden (Direkomendasikan):
    • Aturan A (lebih diutamakan, angka prioritas lebih rendah, misalnya, 10): Cocokkan kemampuan koneksi (misalnya, 0xA6 untuk latensi rendah, 0xA3 untuk bandwidth tinggi, atau 0xA7 untuk komunikasi terpadu). Perangkat Android 17 dan yang lebih tinggi akan mencocokkan aturan ini terlebih dahulu.
    • Aturan B (presedensi lebih rendah, nomor presedensi lebih tinggi, misalnya, 20): Cocokkan jenis ID OS dan ID Aplikasi OS (misalnya, PRIORITIZE_LATENCY). Perangkat lama yang tidak mendukung kemampuan koneksi di HAL cocok dengan aturan penggantian ini.
  2. Aturan khusus ID Aplikasi OS (lama):
    • Operator dapat terus menggunakan aturan URSP yang ada berdasarkan jenis ID OS dan ID Aplikasi OS. Karena perangkat Android 17 dan yang lebih tinggi terus lulus OSAppId, perangkat baru dan lama berhasil mencocokkan aturan ini.
  3. Aturan gabungan (kondisi AND):
    • Operator dapat menentukan ID OS dan ID Aplikasi OS serta kemampuan koneksi dalam satu deskriptor traffic. Aturan ini hanya cocok pada perangkat yang menjalankan Android 17 atau yang lebih tinggi dengan AIDL 2.5 dan yang lebih tinggi.

Contoh aturan URSP

Tabel berikut menunjukkan contoh aturan URSP untuk traffic perusahaan, CBS, latensi rendah, bandwidth tinggi, komunikasi terpadu, dan default.

Enterprise 1

Dukungan untuk Enterprise 1 tersedia di Android 12 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic ENTERPRISE1:

Aturan URSP 1 (ENTERPRISE1)
Prioritas 1 (0x01)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN perusahaan
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN perusahaan

Enterprise 2

Dukungan untuk Enterprise 2 tersedia di Android 13 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic ENTERPRISE2:

Aturan URSP 2 (ENTERPRISE2)
Prioritas 2 (0x02)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN enterprise2
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN enterprise2

Enterprise 3

Dukungan untuk Enterprise 3 tersedia di Android 13 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic ENTERPRISE3:

Aturan URSP 3 (ENTERPRISE3)
Prioritas 3 (0x03)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN enterprise3
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN enterprise3

Enterprise 4

Dukungan untuk Enterprise 4 tersedia di Android 13 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic ENTERPRISE4:

Aturan URSP 4 (ENTERPRISE4)
Prioritas 4 (0x04)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN enterprise4
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN enterprise4

Enterprise 5

Dukungan untuk Enterprise 5 tersedia di Android 13 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic ENTERPRISE5:

Aturan URSP 5 (ENTERPRISE5)
Prioritas 5 (0x05)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN enterprise5
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN enterprise5

CBS

Dukungan untuk CBS tersedia di Android 13 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic CBS:

Aturan URSP 6 (CBS)
Prioritas 6 (0x06)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E4703434253
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN cbs
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN cbs

Latensi rendah dengan kemampuan koneksi

Dukungan untuk kemampuan koneksi dalam aturan URSP tersedia di Android 17 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic latensi rendah menggunakan deskriptor kemampuan koneksi:

Aturan URSP 7 (latensi rendah dengan kemampuan koneksi)
Prioritas 7 (0x07)
Deskripsi traffic #1
Jenis kemampuan koneksi 0xA6 (166: Interaktif real-time)
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN latensi
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN latensi

Latensi rendah dengan OSAppId

Dukungan untuk latensi rendah tersedia di Android 13 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic LOW_LATENCY menggunakan OSAppId:

Aturan URSP 8 (latensi rendah dengan penggantian OSAppId)
Prioritas 8 (0x08)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN latensi
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN latensi

Bandwidth tinggi dengan kemampuan koneksi

Dukungan untuk kemampuan koneksi dalam aturan URSP tersedia di Android 17 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic bandwidth tinggi yang menggunakan deskriptor kemampuan koneksi:

Aturan URSP 9 (bandwidth tinggi dengan kemampuan koneksi)
Prioritas 9 (0x09)
Deskripsi traffic #1
Jenis kemampuan koneksi 0xA3 (163: Streaming downlink)
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN bandwidth
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN bandwidth

Bandwidth tinggi dengan OSAppId

Dukungan untuk bandwidth tinggi tersedia di Android 13 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic HIGH_BANDWIDTH menggunakan OSAppId:

Aturan URSP 10 (bandwidth tinggi dengan penggantian OSAppId)
Prioritas 10 (0x0A)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY
Komponen #2: DNN bandwidth
Deskripsi pemilihan rute #2
Prioritas 2 (0x02)
Komponen #1: DNN bandwidth

Komunikasi terpadu dengan kemampuan koneksi

Dukungan untuk komunikasi terpadu tersedia di Android 17 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic UNIFIED_COMMUNICATIONS menggunakan kemampuan koneksi. Karena traffic komunikasi terpadu dirutekan melalui koneksi data internet default, APN (DNN) khusus tidak diperlukan dalam deskriptor pemilihan rute:

Aturan URSP 11 (komunikasi terpadu dengan kemampuan koneksi)
Prioritas 11 (0x0B)
Deskripsi traffic #1
Jenis kemampuan koneksi 0xA7 (167: Unified communications)
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY

Komunikasi terpadu dengan OSAppId

Dukungan untuk komunikasi terpadu tersedia di Android 17 dan yang lebih tinggi. Berikut adalah contoh aturan URSP untuk traffic UNIFIED_COMMUNICATIONS menggunakan OSAppId:

Aturan URSP 12 (komunikasi terpadu dengan penggantian OSAppId)
Prioritas 12 (0x0C)
Deskripsi traffic #1
Jenis OS Id + OS App Id 0x97A498E3FC925C9489860333D06E4E47215052494F524954495A455F554E49464945445F434F4D4D554E49434154494F4E53
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY

Default

Aturan URSP 13 (default)
Prioritas 13 (0x0D)
Deskripsi traffic #1
match-all T/A
Deskripsi pemilihan rute #1
Prioritas 1 (0x01)
Komponen #1: S-NSSAI SST:XX SD:YYYYYY

Pengujian

Untuk menguji network slicing 5G, gunakan pengujian manual berikut.

Untuk menyiapkan perangkat untuk pengujian, lakukan hal berikut:

  1. Pastikan kebijakan URSP dikonfigurasi dengan aturan non-default yang cocok dengan kategori perusahaan dan deskriptor pemilihan rute yang sesuai memetakan kategori perusahaan ke slice perusahaan; dan aturan default yang mengarahkan traffic ke slice internet default.

  2. Pastikan profil kerja dikonfigurasi di perangkat.

  3. Memilih untuk menggunakan network slicing melalui DPC

Untuk menguji perilaku network slicing 5G, lakukan hal berikut:

  1. Pastikan sesi PDU dibuat dengan slice perusahaan (misalnya, dengan menggunakan alamat IP tertentu) dan aplikasi di profil kerja menggunakan sesi PDU tersebut.
  2. Pastikan sesi PDU terpisah dibuat dengan slice internet default dan aplikasi di profil pribadi menggunakan sesi PDU tersebut.

Peningkatan penjualan segmentasi 5G

Fitur peningkatan penjualan irisan 5G, yang tersedia mulai Android 14 QPR1, memungkinkan operator menawarkan kemampuan jaringan yang ditingkatkan (latensi dan bandwidth) kepada pengguna mereka melalui irisan jaringan 5G.

Fitur penawaran upgrade slicing 5G menggunakan respons TS.43 dari server hak operator untuk mendorong alur pembelian. Operator dapat menggunakan respons untuk menentukan URL untuk webview pembelian operator, mengirim data tambahan ke webview, dan menunjukkan apakah slice disediakan dan tersedia di jaringan operator.

Operator dapat menyesuaikan perilaku fitur penawaran 5G slicing menggunakan konfigurasi operator, yang mengontrol apakah permintaan pembelian dapat dilakukan, kapan aplikasi diizinkan untuk meminta kemampuan premium, dan berapa lama framework Telephony menunggu respons dari pengguna atau jaringan.

Fitur peningkatan penjualan slicing 5G menyediakan antarmuka, yang disebut DataBoostWebServiceFlow, untuk memungkinkan komunikasi antara Android dan webview operator.

Gambar 2 menunjukkan alur pembelian penawaran upgrade slicing 5G:

Alur pembelian penawaran upgrade segmentasi 5G

Gambar 2. Alur pembelian penawaran upgrade segmentasi 5G.

Proses pemberian hak TS.43

Saat pengguna membuat permintaan untuk kemampuan jaringan yang ditingkatkan, framework Telephony akan meminta konfigurasi hak layanan untuk kemampuan premium yang diminta. Jika respons TS.43 valid, framework Telephony akan menggunakan kolom dari respons HTTP untuk mendorong permintaan pembelian.

Kolom pembelian slice

Konfigurasi hak TS.43 mencakup kolom pembelian slice berikut:

Status hak

Tombol: EntitlementStatus

Jenis: int

Nilai yang didukung: 0 (dinonaktifkan), 1 (diaktifkan), 2 (tidak kompatibel), 3 (penyediaan), 4 (disertakan)

Status penyediaan

Tombol: ProvStatus

Jenis: int

Nilai yang didukung: 0 (tidak disediakan), 1 (disediakan), 2 (tidak tersedia), 3 (sedang diproses)

Framework Telephony menggunakan kombinasi status hak dan status penyediaan untuk menentukan status pembelian slice saat ini. Hasilnya dapat berupa salah satu dari berikut:

Jika status hak adalah 1 (diaktifkan) dan status penyediaan adalah 0 (tidak disediakan), framework Telephony akan menampilkan notifikasi peningkatan penjualan kepada pengguna untuk membeli peningkat melalui webview operator. Tabel berikut menjelaskan perilaku framework Telephony untuk berbagai kombinasi nilai status penyediaan dan hak.

Status penyediaan
Tidak disediakan (0) Disediakan (1) Tidak tersedia (2) Sedang berlangsung (3)
Status hak Dinonaktifkan (0) Gagal Gagal Gagal Gagal
Diaktifkan (1) Tampilkan webview Sudah dibeli Sudah dibeli Dalam proses
Tidak kompatibel (2) Gagal Gagal Gagal Gagal
Penyediaan (3) Error operator Error operator Dalam proses Dalam proses
Disertakan (4) Error operator Sudah dibeli Sudah dibeli Error operator

Kolom alur layanan

Respons TS.43 menentukan URL, data pengguna, dan jenis konten untuk menyesuaikan perilaku web view pembelian operator. Jika jenis konten tidak ditentukan, URL dimuat sebagai permintaan GET. Jika data pengguna ada, data tersebut ditambahkan ke URL sebagai parameter kueri (misalnya, https://www.android.com?encodedValue=Base64EncodedUserData); dan jika tidak ada, URL digunakan apa adanya (misalnya, https://www.android.com).
Jika jenis konten ditentukan dalam format JSON atau XML, URL dimuat sebagai permintaan POST, dan data pengguna (didekode jika dienkode dalam Base 64) dikirim sebagai data untuk permintaan POST.

URL

Tombol: ServiceFlow_URL

Jenis: String

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

Data pengguna

Tombol: ServiceFlow_UserData

Jenis: String

Contoh: "encodedValue=Base64EncodedUserData"

Jenis konten

Tombol: ServiceFlow_ContentsType

Jenis: String

Nilai yang didukung: 0 (tidak ditentukan), 1 (JSON), 2 (XML)

Konfigurasi operator

Berikut adalah konfigurasi operator yang tersedia untuk menyesuaikan perilaku fitur penawaran 5G slicing.

KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY

Daftar kemampuan premium yang didukung. Ini adalah array int dari TelephonyManager.PremiumCapability. Kemampuan premium ini memiliki nilai yang sama dengan class NetworkCapabilities.NetCapability yang sesuai. Jika kemampuan premium diminta dan tidak disertakan dalam konfigurasi ini, permintaan pembelian akan gagal dengan hasil CARRIER_DISABLED.

Di Android 14, hanya PREMIUM_CAPABILITY_PRIORITIZE_LATENCY yang didukung.

KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT

Jumlah maksimum harian berapa kali notifikasi penawaran pembelian ditampilkan kepada pengguna. Jika jumlah maksimum harian tercapai, notifikasi peningkatan penjualan tidak ditampilkan dan permintaan pembelian (termasuk permintaan server hak) akan dibatasi hingga tengah malam pada hari berikutnya. Permintaan pembelian yang dilakukan setelah jumlah maksimum harian tercapai akan gagal dengan hasil PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT

Jumlah maksimum bulanan berapa kali notifikasi penawaran peningkatan pembelian ditampilkan kepada pengguna. Jika maksimum bulanan tercapai, notifikasi penawaran upgrade tidak ditampilkan dan permintaan pembelian (termasuk permintaan server hak) dibatasi hingga hari pertama bulan berikutnya. Permintaan pembelian yang dilakukan setelah batas maksimum bulanan tercapai akan gagal dengan hasil PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING

URL pembelian operator cadangan untuk ditampilkan kepada pengguna saat mereka mengklik notifikasi penawaran peningkatan. Jika URL pembelian tidak ditemukan dalam respons TS.43 dari server hak, nilai ini akan digunakan. Jika URL dari respons TS.43 atau konfigurasi operator tidak valid, permintaan pembelian akan gagal dengan hasil PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.

KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL

Apakah akan mengizinkan kemampuan premium dibeli saat perangkat terhubung ke Long-Term Evolution (LTE). Jika true, permintaan pembelian dapat dilakukan di LTE dan New Radio (NR). Jika false, permintaan pembelian hanya dapat dilakukan di NR dan permintaan yang dilakukan di LTE akan gagal dengan PURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE hasil.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG

Durasi untuk menampilkan notifikasi penawaran peningkatan pembelian kepada pengguna sebelum dibatalkan secara otomatis. Jika notifikasi dibatalkan, permintaan berikutnya akan dibatasi dan gagal dengan hasil PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Jumlah waktu permintaan pembelian berikutnya harus di-throttle setelah kegagalan karena waktu tunggu habis atau pembatalan pengguna. Jika pengguna tidak mengklik notifikasi penawaran pembelian dalam batas waktu yang ditentukan oleh KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG atau jika mereka membatalkan atau menutup notifikasi, timer mundur ini akan dimulai. Saat timer ini aktif, permintaan pembelian akan gagal dengan hasil PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Jumlah waktu permintaan pembelian berikutnya harus dibatasi setelah kegagalan karena operator atau jaringan. Jika pemeriksaan hak gagal, URL tidak tersedia, atau URL pembelian operator menunjukkan kegagalan, timer mundur ini akan dimulai. Saat timer ini aktif, permintaan pembelian akan gagal dengan hasil PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG

Jumlah waktu yang diperlukan jaringan untuk menyiapkan konfigurasi slicing untuk kemampuan premium pembelian. Selama periode ini, permintaan pembelian berikutnya diblokir dan menampilkan hasil PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Jika jaringan gagal menyiapkan konfigurasi slicing tepat waktu, aplikasi dapat meminta untuk membeli kemampuan premium lagi. Telefoni tidak menganggap pembelian selesai hingga konfigurasi slicing yang sesuai dikirim, terlepas dari apakah pengguna membayar operator atau tidak.

Antarmuka JavaScript

Saat pengguna mengklik notifikasi peningkatan jaringan, objek WebView dengan URL pembelian operator akan ditampilkan kepada pengguna. Operator dapat menggunakan API yang disediakan di antarmuka JavaScript DataBoostWebServiceFlow di situs pembelian mereka untuk berkomunikasi dengan aplikasi pembelian slice.

Situs operator dapat memperoleh kemampuan premium yang diminta melalui metode getRequestedCapability().

Jika pembelian berhasil, situs operator harus memberi tahu aplikasi pembelian slice melalui notifyPurchaseSuccessful() atau notifyPurchaseSuccessful(duration), dengan duration adalah parameter opsional yang menunjukkan durasi slice yang diinginkan.

Jika pembelian tidak berhasil, situs operator harus memberi tahu aplikasi pembelian slice melalui metode notifyPurchaseFailed(code, reason), dengan code adalah kode kegagalan yang menunjukkan alasan kegagalan dan reason adalah alasan kegagalan yang mudah dibaca jika kode kegagalan tidak diketahui.

Jika salah satu metode respons ini tidak dipanggil, pembelian tidak akan dianggap selesai dan permintaan pembelian akan habis waktunya.

Berikut adalah kode kegagalan valid yang dapat ditampilkan situs operator untuk kegagalan pembelian:

Setelah pembelian selesai, operator harus memperbarui aturan URSP dengan slice PRIORITIZE_LATENCY ke perangkat pengguna.

Perutean otomatis segmentasi 5G untuk suara dan video OTT

Android 17 menyediakan dukungan untuk perutean otomatis panggilan suara dan video over-the-top (OTT) ke koneksi jaringan premium. Fitur ini memungkinkan sistem mengarahkan traffic dari panggilan suara dan video secara otomatis ke antarmuka jaringan premium khusus (seperti slice 5G premium atau koneksi PDN 4G premium) tanpa memerlukan perubahan pada stack jaringan aplikasi.

Solusi tingkat platform ini menghilangkan kebutuhan developer aplikasi untuk meminta kemampuan jaringan secara eksplisit, sehingga memberikan pengalaman yang lancar bagi developer dan pengguna akhir.

Cara kerjanya

Android menyertakan dukungan untuk perutean otomatis melalui penambahan pada framework konektivitas dan telekomunikasi. Fitur perutean otomatis beroperasi sebagai berikut:

  • Deteksi panggilan: Sistem memanfaatkan API Jetpack Telecom yang ada yang digunakan oleh aplikasi OTT untuk mendeteksi awal dan akhir panggilan suara atau video.
  • Pengelolaan koneksi: Setelah mendeteksi panggilan, Android akan menampilkan antarmuka jaringan premium yang ditetapkan, seperti slice komunikasi terpadu.
  • Pengarahan traffic: Selama panggilan, platform mengidentifikasi aplikasi berdasarkan UID-nya dan secara otomatis mengarahkan traffic-nya ke koneksi jaringan premium.
  • Penggantian setelah panggilan: Saat panggilan berakhir, platform akan menghapus aturan perutean, dan traffic aplikasi akan kembali ke jaringan default sistem untuk traffic non-panggilan (seperti pesan).

Persyaratan

Untuk mendukung perutean otomatis untuk panggilan OTT, persyaratan berikut harus dipenuhi:

  • Operator: Harus menawarkan slice komunikasi terpadu dengan mengonfigurasi aturan URSP yang sesuai (menggunakan kemampuan koneksi atau OSAppId untuk traffic komunikasi terpadu).
  • Aplikasi: Harus menggunakan Android Telecom Jetpack API agar sistem dapat mendeteksi status panggilan.
  • Produsen perangkat: Android 17 atau yang lebih tinggi diperlukan.