Інтеграція можливостей 5G Network Slicing у мобільному додатку

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1735 послуг
Інтеграція можливостей 5G Network Slicing у мобільному додатку
Складний
від 2 тижнів до 3 місяців
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    792
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    671
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1097
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    969
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    914
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    495

Інтеграція можливостей 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ками, повноцінне тестування неможливо. Вартість розраховується індивідуально після аналізу вимог та інфраструктури оператора.