Сегментирование сетей 5G

На устройствах с Android 12 и более поздних версий поддерживается сегментирование сети 5G. Это технология виртуализации сети, которая позволяет разделить одно сетевое подключение на несколько отдельных виртуальных подключений, предоставляющих разным типам трафика разное количество ресурсов. Сегментирование сети 5G позволяет операторам выделять часть сети для предоставления определенных функций определенному сегменту клиентов. В Android 12 появились следующие возможности сегментирования корпоративных сетей 5G, которые операторы могут предоставлять своим корпоративным клиентам:

Корпоративное разделение на полностью управляемых устройствах

Если компания предоставляет сотрудникам полностью управляемые устройства, поставщики сетевых услуг могут предоставить ей один или несколько активных слайсов корпоративной сети, на которые будет направляться трафик с устройств компании. Начиная с Android 12 операторы могут предоставлять корпоративные фрагменты с помощью правил URSP, а не настраивать их через APN.

Разделение трафика корпоративных приложений на устройствах с рабочими профилями

На устройствах с рабочим профилем и Android 12 трафик из всех приложений в рабочем профиле можно направлять в корпоративный сегмент сети. Организации могут включить эту функцию с помощью контроллера политик устройств (DPC).

Решение для рабочего профиля обеспечивает автоматический уровень аутентификации и контроля доступа, необходимый предприятиям, чтобы трафик только из корпоративных приложений в рабочем профиле направлялся в сегмент корпоративной сети. Приложения в рабочем профиле не нужно изменять, чтобы явно запросить сегмент корпоративной сети.

Как работает сегментирование сети 5G в AOSP

В Android 12 добавлена поддержка сегментирования сетей 5G. Для этого в кодовую базу телефонии в AOSP и модуль точки доступа были добавлены существующие API подключения, необходимые для сегментирования сетей.

Платформа Android Telephony предоставляет HAL и API телефонии для поддержки сегментирования на основе сетевых запросов, отправленных основным сетевым кодом, и возможностей сегментирования сетей 5G в модеме. На рисунке 1 показаны компоненты функции сегментирования сети 5G.

Компоненты сегментирования сетей 5G

Рисунок 1. Архитектура сегментирования сетей 5G в AOSP.

Платформа телефонии и связи поддерживает:

  • Преобразование сетевых запросов для категорий слайсов в дескрипторы трафика, которые затем передаются в модем для сопоставления трафика URSP и выбора маршрута.
  • Переход на сеть по умолчанию, если сегмент корпоративной сети недоступен.
  • Направление трафика из всех приложений в рабочем профиле на соответствующее подключение.

  • Поддержка сегментирования для организаций

    • обнаруживать наличие рабочего профиля на устройстве;
    • Проверка разрешений или инструкций по маршрутизации, предоставленных контроллером политики устройств, который используется системным администратором компании.

В основной сетевой сервис в Android 12 были внесены следующие изменения в модуль Tethering:

  • Добавляет большинство общедоступных или системных классов API android.net.* в модуль Tethering.

  • Расширяет границы модуля "Режим модема", чтобы включить:

    • 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

  • Код VPN перенесен из модуля Tethering.

В Android 12 в модуль тетеринга перенесен код со следующими возможностями:

  • Получение запросов от приложений на подключение к сети
  • Получение запросов от системы (например, "поместить эти приложения в корпоративный фрагмент"; появилось в Android 12).
  • Отправка запросов из системы в код телефонии, который пытается настроить сети или сегменты через HAL API и модем.
  • Передача демону netd информации о том, как маршрутизировать трафик для каждого приложения (появилась в Android 12).
  • Информирование приложений о том, что происходит с их сетевым трафиком, с помощью API ConnectivityManager, таких как NetworkCallback, getActiveNetwork и getNetworkCapabilities.

Реализация

Чтобы устройство поддерживало сегментирование 5G, оно должно быть оснащено модемом, который поддерживает HAL IRadio 1.6 с API setupDataCall_1_6. Этот API настраивает подключение для передачи данных и включает следующие параметры для поддержки сегментирования сетей 5G:

  • trafficDescriptor: дескриптор трафика, отправленный модему
  • sliceInfo: указывает информацию о фрагменте сети, который будет использоваться при переключении с EPDG на 5G.
  • matchAllRuleAllowed – указывает, разрешено ли использовать правило URSP по умолчанию, которое соответствует всем запросам. Телефония устанавливает для этого параметра значение true для сетей по умолчанию, но не для фрагментов. Правило "Соответствовать всем" применяется к сетям по умолчанию. Если приложение запрашивает определенный фрагмент, который недоступен, то этот фрагмент будет отмечен как недоступный. Для корпоративных приложений фреймворк Telephony может переключиться на сеть по умолчанию, если корпоративная сеть недоступна.

Модемы также должны реализовывать API getSlicingConfig, если только API getHalDeviceCapabilities не сообщает, что он не поддерживается.

Требования для предприятий

Ниже описаны требования к использованию сегментирования сетей 5G на устройствах, развернутых в корпоративной среде Android.

  • Убедитесь, что полностью управляемые устройства или устройства сотрудников, настроенные с рабочим профилем, поддерживают 5G SA и оснащены модемами, которые поддерживают API setupDataCall_1_6.
  • Настройте сегменты и отслеживайте их производительность или характеристики SLA вместе с партнером по оператору связи.

Включить сегментирование сетей 5G на устройствах с рабочим профилем

На устройствах с рабочими профилями в AOSP по умолчанию отключено разделение сети 5G. Чтобы включить сегментирование сети, администраторы могут разрешить или запретить маршрутизацию трафика приложений рабочего профиля в сегмент корпоративной сети для каждого сотрудника с помощью контроллера политик на устройствах (DPC) EMM, который использует метод setPreferentialNetworkServiceEnabled в API DevicePolicyManager (DPM) (представлен в Android 12).

Поставщики EMM-решений с собственными контроллерами политик должны интегрировать API DevicePolicyManager, чтобы поддерживать корпоративных клиентов.

Правила URSP

В этом разделе приведена информация для операторов о том, как настраивать правила URSP для разных категорий сегментов, включая корпоративные, CBS, с низкой задержкой, с высокой пропускной способностью и трафик унифицированных коммуникаций.

При настройке правил URSP операторы могут использовать дескрипторы трафика на основе следующих факторов:

  • Идентификатор ОС и идентификатор приложения ОС, тип компонента 0x08, поддерживается в Android 12 и более поздних версиях
  • Тип возможности подключения, тип компонента 0x90, поддерживается в Android 17 и более поздних версиях

Идентификатор ОС и идентификатор приложения ОС

При настройке правил URSP с использованием компонента дескриптора трафика типа "Идентификатор ОС" и "Идентификатор приложения ОС" операторы могут использовать следующие значения идентификатора ОС и идентификатора приложения ОС, относящиеся к Android.

ID Значение Описание
Идентификатор ОС 97a498e3-fc92-5c94-8986-0333d06e4e47 Идентификатор ОС для Android – это UUID версии 5, созданный с использованием пространства имен ISO OID и названия Android.

Операторы, настраивающие правила URSP с использованием типа идентификатора ОС и идентификатора приложения ОС, должны настроить трафик каждого сегмента с компонентом дескриптора трафика как конкатенацию идентификатора ОС, длины идентификатора приложения ОС (0x0A) и идентификатора приложения ОС. Например, в сегменте ENTERPRISE должно быть указано значение 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345. Подробнее о типе компонента дескриптора трафика…

В таблице ниже описаны значения OSAppId для разных категорий фрагментов.

Категория фрагмента данных OSAppId Описание
ENTERPRISE 0x454E5445525052495345 OSAppId – это массив байтов, представляющий строку ENTERPRISE.
ENTERPRISE2 0x454E544552505249534532 OSAppId – это массив байтов, представляющий строку ENTERPRISE2.
ENTERPRISE3 0x454E544552505249534533 OSAppId – это массив байтов, представляющий строку ENTERPRISE3.
ENTERPRISE4 0x454E544552505249534534 OSAppId – это массив байтов, представляющий строку ENTERPRISE4.
ENTERPRISE5 0x454E544552505249534535 OSAppId – это массив байтов, представляющий строку ENTERPRISE5.
CBS 0x434253 OSAppId – это массив байтов, представляющий строку CBS.
PRIORITIZE_LATENCY 0x5052494f524954495a455f4c4154454e4359 OSAppId – это массив байтов, представляющий строку PRIORITIZE_LATENCY.
PRIORITIZE_BANDWIDTH 0x5052494f524954495a455f42414e445749445448 OSAppId – это массив байтов, представляющий строку PRIORITIZE_BANDWIDTH.
PRIORITIZE_UNIFIED_COMMUNICATIONS 0x5052494f524954495a455f554e49464945445f434f4d4d554e49434154494f4e53 OSAppId – это массив байтов, представляющий строку PRIORITIZE_UNIFIED_COMMUNICATIONS.

Мы не планируем добавлять новые значения OSAppId. Мы улучшим дескриптор трафика для возможностей подключения.

Возможности подключения

В Android 17 и более поздних версиях (Radio HAL AIDL 2.5 и более поздних версий) Android поддерживает компонент дескриптора трафика возможностей подключения (тип 0x90), определенный в таблице 5.2.1 спецификации 3GPP TS 24.526.

Когда приложение или системный сервис запрашивает сеть с определенной возможностью, стек данных телефонии Android сопоставляет запрошенную NetworkCapabilities со стандартным значением возможности подключения, которое указывается в TrafficDescriptor , отправляемом модему при настройке вызова данных (setupDataCall). Спецификация 3GPP позволяет использовать несколько возможностей подключения в одном дескрипторе, но фреймворк телефонии Android 17 сопоставляет несколько запрошенных возможностей подключения с одной возможностью подключения.

В таблице ниже описано сопоставление возможностей сети Android с возможностями подключения 3GPP по умолчанию.

Возможности сети Возможность подключения Значение (шестнадцатеричное или десятичное) Описание
NET_CAPABILITY_IMS CONNECTION_CAPABILITY_IMS 0x01 (1) Голосовые и видеозвонки IMS
NET_CAPABILITY_MMS CONNECTION_CAPABILITY_MMS 0x02 (2) Трафик MMS
NET_CAPABILITY_SUPL CONNECTION_CAPABILITY_SUPL 0x04 (4) Secure User Plane Location (SUPL)
NET_CAPABILITY_INTERNET CONNECTION_CAPABILITY_INTERNET 0x08 (8) Трафик мобильного интернета по умолчанию
NET_CAPABILITY_PRIORITIZE_LATENCY CONNECTION_CAPABILITY_REAL_TIME_INTERACTIVE 0xA6 (166) Интерактивный трафик в реальном времени (например, игры, дополненная и виртуальная реальность).
NET_CAPABILITY_PRIORITIZE_BANDWIDTH CONNECTION_CAPABILITY_DOWNLINK_STREAMING 0xA3 (163) Трафик потоковой передачи с высокой пропускной способностью в нисходящем канале
NET_CAPABILITY_PRIORITIZE_UNIFIED_COMMUNICATIONS CONNECTION_CAPABILITY_UNIFIED_COMMUNICATIONS 0xA7 (167) Унифицированные коммуникации (например, голосовые или видеозвонки через интернет).

Конфигурация URSP оператора и обратная совместимость

Чтобы обеспечить бесперебойную работу на устройствах с разными версиями HAL и ОС, операторам следует учитывать следующее поведение при инициализации правил URSP:

  • Устройства с Android 16 или более ранней версией (Radio HAL AIDL 2.4 и более ранние версии). Модем получает как минимум OSAppId в дескрипторе трафика.
  • Устройства с Android 17 или более поздней версии (AIDL 2.5 и более поздней версии). Для премиум-функций слайса (таких как низкая задержка, высокая пропускная способность и унифицированные коммуникации) платформа заполняет в дескрипторе трафика OSAppId, ConnectionCapability или оба поля.

Операторы могут настраивать правила URSP одним из следующих способов:

  1. Правила на основе приоритета (рекомендуется)
    • Правило А (более высокий приоритет, меньшее числовое значение приоритета, например 10): соответствие возможностям подключения (например, 0xA6 для низкой задержки, 0xA3 для высокой пропускной способности или 0xA7 для унифицированных коммуникаций). Устройства с Android 17 и более поздних версий сначала применяют это правило.
    • Правило Б (более низкий приоритет, более высокое число приоритета, например 20): сопоставление по идентификатору ОС и типу идентификатора приложения ОС (например, PRIORITIZE_LATENCY). Более старые устройства, которые не поддерживают возможность подключения в HAL, соответствуют этому резервному правилу.
  2. Правило на основе идентификатора приложения ОС (устаревшее):
    • Операторы связи могут продолжать использовать существующие правила URSP на основе идентификатора ОС и идентификатора приложения ОС. Поскольку устройства с Android 17 и более поздними версиями ОС по-прежнему проходят проверку OSAppId, и новые, и старые устройства успешно соответствуют этим правилам.
  3. Комбинированное правило (условие "И")
    • Операторы связи могут указать идентификатор ОС, идентификатор приложения ОС и возможности подключения в одном дескрипторе трафика. Это правило применяется только к устройствам с Android 17 или более поздней версии и AIDL 2.5 или более поздней версии.

Примеры правил URSP

В таблицах ниже приведены примеры правил URSP для корпоративного трафика, трафика CBS, трафика с низкой задержкой, трафика с высокой пропускной способностью, трафика унифицированных коммуникаций и трафика по умолчанию.

Enterprise 1

Поддержка Enterprise 1 доступна в Android 12 и более поздних версиях. Ниже приведен пример правила URSP для трафика ENTERPRISE1:

Правило URSP 1 (ENTERPRISE1)
Приоритет 1 (0x01)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения ОС 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN Для бизнеса
Дескриптор выбора маршрута № 2
Приоритет 2 (0x02)
Компонент 1. Глубокая нейронная сеть Для бизнеса

Enterprise 2

Поддержка Enterprise 2 доступна в Android 13 и более поздних версиях. Ниже приведен пример правила URSP для трафика ENTERPRISE2:

Правило URSP 2 (ENTERPRISE2)
Приоритет 2 (0x02)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения для ОС 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532
Описание выбора маршрута № 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN enterprise2
Дескриптор выбора маршрута 2
Приоритет 2 (0x02)
Компонент 1. Глубокая нейронная сеть enterprise2

Enterprise 3

Enterprise 3 поддерживается в Android 13 и более поздних версиях. Ниже приведен пример правила URSP для трафика ENTERPRISE3:

Правило URSP 3 (ENTERPRISE3)
Приоритет 3 (0x03)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения ОС 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN enterprise3
Дескриптор выбора маршрута 2
Приоритет 2 (0x02)
Компонент 1. Глубокая нейронная сеть enterprise3

Enterprise 4

Поддержка Enterprise 4 доступна в Android 13 и более поздних версиях. Ниже приведен пример правила URSP для трафика ENTERPRISE4:

Правило URSP 4 (ENTERPRISE4)
Приоритет 4 (0x04)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения ОС 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534
Дескриптор выбора маршрута № 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN enterprise4
Дескриптор выбора маршрута 2
Приоритет 2 (0x02)
Компонент 1. Глубокая нейронная сеть enterprise4

Enterprise 5

Поддержка Enterprise 5 доступна в Android 13 и более поздних версиях. Ниже приведен пример правила URSP для трафика ENTERPRISE5:

Правило URSP 5 (ENTERPRISE5)
Приоритет 5 (0x05)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения ОС 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN enterprise5
Дескриптор выбора маршрута 2
Приоритет 2 (0x02)
Компонент 1: DNN enterprise5

CBS

Поддержка CBS доступна в Android 13 и более поздних версиях. Ниже приведен пример правила URSP для трафика CBS:

Правило 6 URSP (CBS)
Приоритет 6 (0x06)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения ОС 0x97A498E3FC925C9489860333D06E4E4703434253
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN cbs
Дескриптор выбора маршрута 2
Приоритет 2 (0x02)
Компонент 1: DNN cbs

Низкая задержка и возможность подключения

Поддержка возможностей подключения в правилах URSP доступна в Android 17 и более поздних версиях. Ниже приведен пример правила URSP для трафика с низкой задержкой, в котором используется дескриптор возможностей подключения:

Правило URSP 7 (низкая задержка с возможностью подключения)
Приоритет 7 (0x07)
Описание трафика № 1
Тип возможностей подключения 0xA6 (166: интерактивный контент в реальном времени)
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN задержка
Дескриптор выбора маршрута 2
Приоритет 2 (0x02)
Компонент 1. Глубокая нейронная сеть задержка

Малая задержка с OSAppId

Поддержка низкой задержки доступна в Android 13 и более поздних версиях. Ниже приведен пример правила URSP для трафика LOW_LATENCY с использованием OSAppId.

Правило URSP 8 (низкая задержка с резервным OSAppId)
Приоритет 8 (0x08)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения ОС 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN задержка
Дескриптор выбора маршрута 2
Приоритет 2 (0x02)
Компонент 1. Глубокая нейронная сеть задержка

Высокая пропускная способность с возможностью подключения

Поддержка возможностей подключения в правилах URSP доступна в Android 17 и более поздних версиях. Ниже приведен пример правила URSP для трафика с высокой пропускной способностью, в котором используется дескриптор возможностей подключения:

Правило URSP 9 (высокая пропускная способность с возможностью подключения)
Приоритет 9 (0x09)
Описание трафика № 1
Тип возможностей подключения 0xA3 (163: стриминг в нисходящем канале)
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN пропускная способность
Дескриптор выбора маршрута № 2
Приоритет 2 (0x02)
Компонент 1. Глубокая нейронная сеть пропускная способность

Высокая пропускная способность с OSAppId

Поддержка высокой пропускной способности доступна в Android 13 и более поздних версиях. Ниже приведен пример правила URSP для трафика HIGH_BANDWIDTH с использованием OSAppId.

Правило URSP 10 (высокая пропускная способность с резервным OSAppId)
Приоритет 10 (0x0A)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения ОС 0x97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY
Компонент 2: DNN пропускная способность
Дескриптор выбора маршрута № 2
Приоритет 2 (0x02)
Компонент 1. Глубокая нейронная сеть пропускная способность;

Унифицированные коммуникации с возможностью подключения

Поддержка унифицированных коммуникаций доступна в Android 17 и более поздних версиях. Ниже приведен пример правила URSP для трафика UNIFIED_COMMUNICATIONS, использующего возможность подключения. Поскольку трафик унифицированных коммуникаций передается через подключение к интернету по умолчанию, в дескрипторе выбора маршрута не требуется указывать отдельную точку доступа (DNN):

Правило URSP 11 (унифицированные коммуникации с возможностью подключения)
Приоритет 11 (0x0B)
Описание трафика № 1
Тип возможностей подключения 0xA7 (167: единая система связи)
Описание выбора маршрута № 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY

Унифицированные коммуникации с OSAppId

Поддержка унифицированных коммуникаций доступна в Android 17 и более поздних версиях. Ниже приведен пример правила URSP для трафика UNIFIED_COMMUNICATIONS с использованием OSAppId:

Правило URSP 12 (унифицированные коммуникации с резервным идентификатором приложения ОС)
Приоритет 12 (0x0C)
Описание трафика № 1
Идентификатор ОС + тип идентификатора приложения ОС 0x97A498E3FC925C9489860333D06E4E47215052494F524954495A455F554E49464945445F434F4D4D554E49434154494F4E53
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY

По умолчанию

Правило URSP 13 (по умолчанию)
Приоритет 13 (0x0D)
Дескриптор трафика № 1
match-all Н/Д
Дескриптор выбора маршрута 1
Приоритет 1 (0x01)
Компонент 1. S-NSSAI SST:XX SD:YYYYYY

Тестирование

Чтобы проверить сегментирование сети 5G, выполните следующие действия:

Чтобы настроить устройство для тестирования, выполните следующие действия:

  1. Убедитесь, что в правиле выбора маршрута трафика (URSP) настроено нестандартное правило, которое соответствует категории предприятия, и что соответствующий дескриптор выбора маршрута сопоставляет категорию предприятия с сегментом предприятия, а также что задано правило по умолчанию, направляющее трафик в сегмент интернета по умолчанию.

  2. Убедитесь, что на устройстве настроен рабочий профиль.

  3. Включите использование сегментирования сети через контроллер политик на устройствах.

Чтобы проверить поведение сегментирования сети 5G, выполните следующие действия:

  1. Убедитесь, что сеанс PDU установлен с корпоративным слайсом (например, с использованием определенного IP-адреса) и что приложения в рабочем профиле используют этот сеанс PDU.
  2. Убедитесь, что для сегмента интернета по умолчанию установлен отдельный сеанс PDU и что приложения в личном профиле используют этот сеанс.

Предложение сегментирования сетей 5G

Функция дополнительной продажи сегментирования 5G, доступная в Android 14 QPR1, позволяет операторам связи предлагать пользователям расширенные возможности сети (задержку и пропускную способность) с помощью сегментирования сети 5G.

Функция дополнительной продажи сегментирования 5G использует ответ TS.43 от сервера прав оператора, чтобы управлять процессом покупки. Операторы могут использовать ответ, чтобы указать URL для веб-просмотра покупки, отправить дополнительные данные в веб-просмотр и указать, подготовлен ли фрагмент и доступен ли он в сети оператора.

Операторы могут настраивать поведение функции продвижения сегментирования сетей 5G с помощью конфигураций оператора, которые определяют, можно ли отправлять запросы о покупке, когда приложениям разрешено запрашивать премиум-возможности и как долго фреймворк Telephony ожидает ответа от пользователя или сети.

Функция дополнительной продажи сегментирования 5G предоставляет интерфейс DataBoostWebServiceFlow, который позволяет обмениваться данными между Android и WebView оператора.

На рисунке 2 показан процесс покупки сегментирования сетей 5G:

Процесс покупки сегментирования сетей 5G

Рисунок 2. Процесс покупки сегментирования сетей 5G.

Процесс предоставления прав на использование по спецификации TS.43

Когда пользователь запрашивает расширенные возможности сети, фреймворк Telephony запрашивает конфигурацию права на использование сервиса для запрашиваемой платной функции. Если ответ TS.43 действителен, фреймворк Telephony использует поля из HTTP-ответа, чтобы выполнить запрос о покупке.

Поля для покупки фрагментов

Конфигурация прав TS.43 включает следующие поля для покупки фрагментов:

Дальнейший доступ

Клавиша: EntitlementStatus

Тип: int

Допустимые значения: 0 (отключено), 1 (включено), 2 (несовместимо), 3 (подготовка), 4 (включено).

Статус синхронизации

Клавиша: ProvStatus

Тип: int

Поддерживаемые значения: 0 (не предоставлено), 1 (предоставлено), 2 (недоступно), 3 (в процессе).

Платформа телефонии использует сочетание статуса права и статуса инициализации, чтобы определить текущий статус покупки сегмента. Результат может быть одним из следующих:

Если статус права – 1 (включено), а статус инициализации – 0 (не инициализировано), фреймворк Telephony показывает пользователю уведомление с предложением купить дополнительный трафик через веб-представление оператора. В таблице ниже описано поведение фреймворка телефонии для разных комбинаций значений статусов инициализации и прав.

Статус инициализации
Не настроено (0) Инициализировано (1) Недоступно (2) В процессе (3)
Статус прав на использование Отключено (0) Сбой Сбой Сбой Сбой
Включено (1) Показать WebView Приобретено Приобретено Выполняется
Несовместимо (2) Сбой Сбой Сбой Сбой
Инициализация (3) Ошибка оператора связи Ошибка оператора Выполняется Выполняется
Включено (4) Ошибка оператора Приобретено Приобретено Ошибка оператора

Поля для потока услуг

В ответе TS.43 указывается URL, пользовательские данные и тип контента, чтобы настроить поведение компонента webview при покупке у оператора. Если тип контента не указан, URL загружается как GET-запрос. Если данные пользователя существуют, они добавляются в URL в качестве параметра запроса (например, https://www.android.com?encodedValue=Base64EncodedUserData). Если данных нет, URL используется как есть (например, https://www.android.com).
Если тип контента указан в формате JSON или XML, URL загружается как запрос POST, а данные пользователя (декодированные, если они закодированы в Base64) отправляются как данные для запроса POST.

URL

Клавиша: ServiceFlow_URL

Тип: String

Пример: "https://www.android.com"

Пользовательские данные

Клавиша: ServiceFlow_UserData

Тип: String

Пример: "encodedValue=Base64EncodedUserData"

Тип контента

Клавиша: ServiceFlow_ContentsType

Тип: String

Поддерживаемые значения: 0 (не указано), 1 (JSON), 2 (XML).

Конфигурации операторов связи

Ниже перечислены конфигурации операторов, которые можно использовать для настройки функции продвижения 5G-сетей.

KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY

Список поддерживаемых платных функций. Это массив целых чисел TelephonyManager.PremiumCapability. Эти функции премиум-класса имеют ту же ценность, что и соответствующий класс NetworkCapabilities.NetCapability. Если запрошена премиум-функция, которая не включена в эту конфигурацию, запрос о покупке завершится неудачей с результатом CARRIER_DISABLED.

В Android 14 поддерживается только PREMIUM_CAPABILITY_PRIORITIZE_LATENCY.

KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INT

Максимальное количество показов уведомления о дополнительной продаже в день. Если дневной лимит достигнут, уведомление о допродаже не показывается, а запросы о покупке (включая запросы к серверу прав) ограничиваются до полуночи следующего дня. Если лимит превышен, запросы о покупке будут отклоняться с результатом PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INT

Максимальное количество показов уведомления о дополнительной покупке в месяц. Если месячный лимит достигнут, уведомление о дополнительной покупке не показывается, а запросы о покупке (в том числе запросы к серверу разрешений) ограничиваются до первого дня следующего месяца. Если вы превысите месячный лимит, запросы о покупке будут отклоняться с результатом PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRING

Резервный URL для покупки у оператора, который будет показываться пользователю, когда он нажимает на уведомление о дополнительном предложении. Если URL покупки не найден в ответе TS.43 от сервера прав, используется это значение. Если ни URL из ответа TS.43, ни конфигурация оператора недействительны, запрос о покупке завершается с ошибкой PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.

KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL

Разрешить ли покупку премиум-функций, когда устройство подключено к сети LTE. Если true, запросы о покупке можно отправлять через LTE и New Radio (NR). Если выбрано значение false, запросы о покупке можно отправлять только через NR, а запросы, отправленные через LTE, будут завершаться с ошибкой PURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG

Время, в течение которого пользователю будет показываться уведомление о покупке, прежде чем оно будет автоматически отменено. Если уведомление отменено, последующие запросы регулируются и завершаются с ошибкой PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Время, в течение которого последующие запросы на покупку должны быть заблокированы после сбоя из-за тайм-аута или отмены пользователем. Если пользователь не нажмет на уведомление в течение времени, указанного в KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG, или отменит или закроет уведомление, запустится таймер отсрочки. Когда таймер активен, запросы о покупке завершаются с ошибкой PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONG

Время, в течение которого последующие запросы на покупку должны быть ограничены после сбоя из-за оператора или сети. Если проверка прав не пройдена, URL недоступен или URL покупки у оператора указывает на ошибку, запускается таймер отсрочки. Пока этот таймер активен, запросы о покупке завершаются с ошибкой PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.

KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONG

Период времени, в течение которого сеть должна настроить конфигурацию фрагментации для функции покупки премиум-инвентаря. В течение этого периода последующие запросы о покупке блокируются и возвращают результат PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Если сети не удается вовремя настроить сегментирование, приложения могут снова запросить покупку премиум-функций. Телефония не считает покупку завершенной, пока не будет отправлена соответствующая конфигурация сегментирования, независимо от того, заплатил пользователь оператору или нет.

Интерфейс JavaScript

Когда пользователь нажимает на уведомление об улучшении сети, ему показывается объект WebView с URL покупки у оператора. Операторы связи могут использовать API, предоставленные в интерфейсе JavaScript DataBoostWebServiceFlow, на своих сайтах для связи с приложением для покупки фрагментов.

Сайт оператора может получить доступ к запрошенной функции Premium с помощью метода getRequestedCapability().

Если покупка прошла успешно, сайт оператора должен уведомить приложение для покупки фрагментов с помощью notifyPurchaseSuccessful() или notifyPurchaseSuccessful(duration), где duration – необязательный параметр, указывающий на предполагаемую продолжительность фрагмента.

Если покупка не удалась, сайт оператора должен уведомить приложение для покупки фрагментов с помощью метода notifyPurchaseFailed(code, reason), где code – код ошибки, указывающий на причину сбоя, а reason – человекочитаемая причина сбоя, если код ошибки неизвестен.

Если ни один из этих методов ответа не вызывается, покупка не считается завершенной, и запрос о покупке в конечном итоге превышает время ожидания.

Ниже перечислены допустимые коды ошибок, которые сайт оператора может возвращать при сбое покупки:

После завершения покупки оператор должен обновить правила URSP, добавив в устройство пользователя фрагмент PRIORITIZE_LATENCY.

Автоматическая маршрутизация сегментирования сетей 5G для голосовых и видеозвонков OTT

В Android 17 поддерживается автоматическая маршрутизация голосовых и видеовызовов, совершаемых через интернет, на премиум-подключения к сети. Эта функция позволяет системе автоматически перенаправлять трафик голосовых и видеозвонков на выделенный интерфейс сети премиум-класса (например, сегмент 5G или подключение PDN 4G премиум-класса), не требуя изменений в сетевом стеке приложения.

Это решение на уровне платформы избавляет разработчиков приложений от необходимости явно запрашивать сетевые возможности, обеспечивая удобство как для них, так и для конечных пользователей.

Принцип работы

В Android добавлена поддержка автоматической маршрутизации с помощью изменений в фреймворках Connectivity и Telecom. Функция автоматической маршрутизации работает следующим образом:

  • Обнаружение звонков. Система использует существующие API Telecom Jetpack, которые применяются в OTT-приложениях для обнаружения начала и окончания голосовых и видеовызовов.
  • Управление подключением. При обнаружении вызова Android открывает специальный интерфейс премиум-сети, например фрагмент унифицированных коммуникаций.
  • Управление трафиком. Во время звонка платформа определяет приложение по его UID и автоматически направляет его трафик на премиум-сетевое подключение.
  • Резервный вариант после звонка. Когда звонок завершается, платформа удаляет правило маршрутизации, и трафик приложения возвращается к системной сети по умолчанию для трафика, не связанного со звонками (например, для обмена сообщениями).

Требования

Чтобы поддерживать автоматическую маршрутизацию для вызовов по технологии OTT, должны выполняться следующие требования:

  • Операторы связи. Должны предлагать фрагмент для унифицированных коммуникаций, настраивая соответствующие правила URSP (с помощью возможности подключения или OSAppId для трафика унифицированных коммуникаций).
  • Приложения должны использовать Android Telecom Jetpack API, чтобы система могла определять статус звонка.
  • Производители устройств. Требуется Android 17 или более поздней версии.