Інтеграція можливостей 5G Network Slicing у мобільному додатку
5G Network Slicing — можливість оператора зв'язку виділити мобільному додатку окремий віртуальний сетевий ресурс з гарантованими параметрами: пропускна здатність, затримка, надійність. Не «швидше», а «гарантовано». Різниця принципова для медичних, промислових та AR-додатків.
Що таке Network Slicing на практиці
Фізична 5G-мережа ділиться на ізольовані «зрізи». Кожен зріз — окремий мережевий контейнер з виділеними ресурсами RAN (Radio Access Network), транспорту та ядра. Для додатка це означає:
- eMBB (Enhanced Mobile Broadband) — максимальна пропускна здатність, до 10 Гбіт/с. Для 4K/8K стрімінгу, VR.
- URLLC (Ultra-Reliable Low-Latency Communication) — затримка <1 мс, надійність 99.999%. Для управління промисловим обладнанням, дистанційної хірургії.
- mMTC (Massive Machine-Type Communication) — низьке енергоспоживання, тисячі пристроїв. Для IoT-сенсорів, телеметрії.
Важливо: у 2024 році Network Slicing доступний тільки через API операторів, які його підтримують. У Росії — МТС, Ростелеком у пілотних зонах. У Європі — Deutsche Telekom, Telefonica, Vodafone. Без договору з оператором та без підтримки у SIM-карті зріз недоступний.
Доступ до Network Slicing з мобільного додатка
Прямого OS-API для запиту зрізу у розробника немає. Механізм залежить від платформи та партнерства з оператором:
Android (API 33+): TelephonyManager.isDataCapable(), NetworkCapabilities.NET_CAPABILITY_PRIORITIZE_LATENCY, NET_CAPABILITY_PRIORITIZE_BANDWIDTH. З Android 13 можливість вказати якісні вимоги — ОС транслює їх у запит зрізу через оператора.
val networkRequest = NetworkRequest.Builder()
.addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
.addCapability(NetworkCapabilities.NET_CAPABILITY_PRIORITIZE_LATENCY)
.addTransportType(NetworkCapabilities.TRANSPORT_CELLULAR)
.build()
val connectivityManager = getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
connectivityManager.requestNetwork(networkRequest, object : ConnectivityManager.NetworkCallback() {
override fun onAvailable(network: Network) {
// зріз надано, біндимо сокети до цієї мережі
network.bindSocket(mySocket)
}
override fun onUnavailable() {
// зріз недоступний, fallback на стандартний bearer
}
})
iOS: прямого API для запиту зрізу немає. Apple не надає доступ до PDN connection parameters з CoreTelephony. Партнерські інтеграції через Carrier App Extensions — тільки для операторських додатків (eSIM, параметри SIM). Для iOS Network Slicing реалізується через VPN-профіль або спеціалізований APN, який оператор налаштовує на рівні мережі, а не через SDK.
React Native: виклик нативного Android API через Kotlin Native Module.
Біндинг сокетів до конкретної мережи
Ключовий момент: отримавши Network-об'єкт через NetworkCallback, потрібно явно привязати всі мережеві операції до цієї мережі. Інакше система вибере дефолтний bearer (LTE/5G generic).
// OkHttp: передаємо network.socketFactory()
val client = OkHttpClient.Builder()
.socketFactory(network.socketFactory)
.build()
// Стандартний Socket
val socket = Socket()
network.bindSocket(socket)
socket.connect(InetSocketAddress(host, port))
Для React Native нативний модуль біндит сокет та повертає networkHandle, з яким працює JS-сторона. Абстракція виглядає як звичайний HTTP-клієнт, але під капотом — зріз.
Мониторинг якості зрізу
Після отримання зрізу мониторимо фактичні параметри через LinkProperties та NetworkCapabilities:
connectivityManager.registerNetworkCallback(networkRequest, object : ConnectivityManager.NetworkCallback(
FLAG_INCLUDE_LOCATION_INFO
) {
override fun onCapabilitiesChanged(
network: Network,
capabilities: NetworkCapabilities
) {
val downBandwidth = capabilities.linkDownstreamBandwidthKbps // кбіт/с
val upBandwidth = capabilities.linkUpstreamBandwidthKbps
val latency = capabilities.transportInfo // TransportInfo з latency на Android 12+
}
})
Якщо реальні параметри відрізняються від SLA зрізу — логуємо аномалію та повідомляємо сервер мониторингу. Для URLLC-додатків деградація зрізу може вимагати негайного fallback на хмарну обробку.
Архітектура додатка під слайсинг
Network Slicing не заміняє адаптивну логіку — він доповнює. Рекомендована архітектура:
| Шар | Компонент | Відповідальність |
|---|---|---|
| Транспортний | SliceNetworkManager |
Запит зрізу, біндинг сокетів |
| Адаптивний | QoSMonitor |
Мониторинг параметрів, детекція деградації |
| Бізнес-логіка | ContentQualityAdapter |
Вибір якості/режиму під поточний QoS |
| Fallback | StandardNetworkFallback |
Деградація до LTE/5G generic при втраті зрізу |
Типові помилки
Запрашувати URLLC-зріз для задач, де він не потрібен. Зріз з гарантованою затримкою <1 мс — дорогий ресурс оператора. Запрашувати для відеоконференції — немає смислу. Правильно: URLLC тільки для real-time управління фізичними системами, eMBB — для медіа.
Не обробляти onUnavailable. Зріз може бути недоступний (пристрій поза зоною покриття 5G SA, оператор не підтримує). Додаток обов'язково має деградувати до стандартного bearer без втрати функціональності.
Оцінка
Android Native Module для запиту зрізу + мониторинг QoS + адаптивна бізнес-логіка: 5–9 тижнів (при наявності тестової інфраструктури оператора). Без доступу до тестової 5G SA мережі — розробка тільки з moками, повноцінне тестування неможливо. Вартість розраховується індивідуально після аналізу вимог та інфраструктури оператора.







