Начиная с 2026 года, в соответствии с нашей моделью стабильной разработки основной ветки и для обеспечения стабильности платформы для экосистемы, мы будем публиковать исходный код в AOSP во 2-м и 4-м кварталах. Для сборки и внесения вклада в AOSP используйте ветку android-latest-release . Ветка android-latest-release manifest всегда будет ссылаться на самый последний релиз, выпущенный в AOSP. Для получения дополнительной информации см. раздел «Изменения в AOSP» .

Эта страница переведена с помощью Cloud Translation API.

Нарезка сети 5G

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

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

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

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

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

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

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

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

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

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

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

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

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

В основной сетевой службе Android 12 внесены следующие изменения в модуль «Режим модема»:

Добавляет большинство общедоступных или системных классов 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 код со следующими возможностями перенесен в модуль Tethering:

Получение запросов от приложений на подключение к сети.
Получение запросов от системы (например, «разместить эти приложения на корпоративном сегменте»; эта функция появилась в Android 12).
Отправка запросов из системы в код телефонии, который пытается настроить сети или сегменты, используя API HAL и модем.
Предоставление 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 по умолчанию, определяющего соответствие всем параметрам. Telephony устанавливает это значение в true для сетей по умолчанию, но не для сегментов. Правило соответствия всем параметрам применяется к сетям по умолчанию. Когда приложение запрашивает определенный сегмент, который недоступен, этот сегмент сообщается как недоступный. Для корпоративных приложений платформа Telephony может переключаться на сеть по умолчанию, если корпоративная сеть недоступна.

Модемы также должны реализовывать API getSlicingConfig если только API getHalDeviceCapabilities не сообщает об отсутствии поддержки этой функции.

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

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

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

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

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

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

правила URSP

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

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

Типы OS Id и OS App Id, тип компонента 0x08 , поддерживаются в Android 12 и выше.
Тип возможностей подключения, тип компонента 0x90 , поддерживается в Android 17 и выше.

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

При настройке правил URSP с использованием компонента описания трафика типа OS Id и OS App Id операторы связи могут использовать следующие значения OS Id и OS App Id, специфичные для Android.

ИДЕНТИФИКАТОР	Ценить	Описание
Идентификатор ОС	`97a498e3-fc92-5c94-8986-0333d06e4e47`	Идентификатор ОС для Android — это UUID версии 5, сгенерированный с использованием пространства имен ISO OID и имени Android.

Операторы связи, настраивающие правила URSP с использованием типов OS Id и OS App Id, должны настроить трафик каждого сегмента с компонентом описания трафика как конкатенацию OS Id, длины OS App Id ( 0x0A ) и OS App Id. Например, для сегмента ENTERPRISE значение должно быть 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 . Для получения дополнительной информации о типе компонента описания трафика см. таблицу 5.2.1 стандарта 3GPP TS 24.526 .

В таблице ниже приведены значения 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)	Безопасное определение местоположения пользовательского уровня (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)	Унифицированные коммуникации (например, голосовые или видеозвонки через OTT-сервисы)

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

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

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

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

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

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

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

Предприятие 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: DNN	предприятие

Предприятие 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	предприятие2
Описание выбора маршрута №2
Приоритет	`2 (0x02)`
Компонент №1: DNN	предприятие2

Предприятие 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	предприятие3
Описание выбора маршрута №2
Приоритет	`2 (0x02)`
Компонент №1: DNN	предприятие3

Предприятие 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: DNN	enterprise4

Предприятие 5

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

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

CBS

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

Правило URSP 6 (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: DNN	задержка

Низкая задержка при использовании 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: DNN	задержка

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

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

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

Высокая пропускная способность с 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: DNN	полоса пропускания

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

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

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

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

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

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

По умолчанию

Правило URSP 13 (по умолчанию)
Приоритет	`13 (0x0D)`
Описание дорожной ситуации №1
совпасть все	Н/Д
Описание выбора маршрута №1
Приоритет	`1 (0x01)`
Компонент №1: S-NSSAI	SST:XX SD:YYYYYY

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

Для проверки работы функции сегментирования сети 5G используйте следующий ручной тест.

Для настройки устройства для тестирования выполните следующие действия:

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

Для проверки работы функции сегментирования сети 5G выполните следующие действия:

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

Дополнительные продажи 5G-сегментации

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

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

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

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

На рисунке 2 показана схема дополнительных продаж услуг по сегментированию сети 5G:

Процесс дополнительных продаж при сегментировании сетей 5G

Рисунок 2. Схема дополнительных продаж при сегментировании сети 5G.

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

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

Поля для покупки срезов

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

Статус права на получение льгот: Ключ: EntitlementStatus; Тип: int; Поддерживаемые значения: 0 (отключено), 1 (включено), 2 (несовместимо), 3 (подготовка), 4 (включено)
Статус предоставления ресурсов: Ключ: ProvStatus; Тип: int; Поддерживаемые значения: 0 (не подготовлено), 1 (подготовлено), 2 (недоступно), 3 (в процессе)

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

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

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

Поля потока обслуживания

В ответе TS.43 указываются URL-адрес, пользовательские данные и тип содержимого для настройки поведения веб-представления покупки у оператора связи. Если тип содержимого не указан, URL-адрес загружается как GET-запрос. Если пользовательские данные существуют, они добавляются к URL-адресу в качестве параметра запроса (например, https://www.android.com?encodedValue=Base64EncodedUserData ); если же они отсутствуют, URL-адрес используется как есть (например, https://www.android.com ).
Если тип содержимого указан в формате JSON или XML, URL-адрес загружается как POST-запрос, а данные пользователя (декодированные, если они закодированы в Base 64) отправляются в качестве данных для 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: Разрешать ли приобретение дополнительных возможностей при подключении устройства к сети Long-Term Evolution (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 на своих веб-сайтах для покупки, чтобы взаимодействовать с приложением для покупки отдельных пакетов услуг.

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

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

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

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

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

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

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

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

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

Как это работает

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

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

Требования

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

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