En los dispositivos que ejecutan Android 12 o versiones posteriores, Android admite la segmentación de redes 5G, el uso de la virtualización de red para dividir las conexiones de una sola red en varias conexiones virtuales distintas que proporcionan diferentes cantidades de recursos a distintos tipos de tráfico. El segmentado de redes 5G permite a los operadores de red dedicar una parte de la red a proporcionar funciones específicas para un segmento particular de clientes. Android 12 introduce las siguientes capacidades de segmentación de redes empresariales 5G, que los operadores de redes pueden proporcionar a sus clientes empresariales:
Segmentación de dispositivos empresariales para dispositivos completamente administrados
En el caso de las empresas que proporcionan dispositivos empresariales completamente administrados a sus empleados, los proveedores de redes pueden proporcionarles una o más segmentaciones de red empresarial activas a las que se dirige el tráfico en los dispositivos empresariales. A partir de Android 12, Android permite que los operadores proporcionen segmentos empresariales a través de reglas de URSP, en lugar de configurar segmentos a través de APN.
Segmentación de apps empresariales para dispositivos con perfiles de trabajo
En el caso de las empresas que usan la solución de perfil de trabajo, Android 12 permite que los dispositivos enruten el tráfico de todas las apps del perfil de trabajo a una segmentación de red empresarial. Las empresas pueden habilitar esta capacidad a través de un controlador de política de dispositivo (DPC).
La solución de perfil de trabajo proporciona un nivel automático de autenticación y control de acceso que las empresas requieren para garantizar que solo el tráfico de las apps empresariales en el perfil de trabajo se enrute a la segmentación de red empresarial. No es necesario modificar las apps del perfil de trabajo para solicitar explícitamente la segmentación de red empresarial.
Cómo funciona la segmentación de red 5G en AOSP
Android 12 incorpora compatibilidad con el segmentación de redes 5G a través de adiciones al código base de telefonía en AOSP y el módulo de Tethering para incorporar las APIs de conectividad existentes que se requieren para la segmentación de redes.
La plataforma de telefonía de Android proporciona HAL y APIs de telefonía para admitir el segmentado basado en las solicitudes de red presentadas por el código de red principal y las capacidades de segmentado 5G en el módem. En la Figura 1, se describen los componentes de la función de segmentación de redes 5G.
Figura 1: Arquitectura de segmentación de red 5G en AOSP.
La plataforma de telefonía y conectividad admite lo siguiente:
- Convierte las solicitudes de red para las categorías de segmentos en descriptores de tráfico, que luego se pasan al módem para la coincidencia de tráfico de URSP y la selección de rutas.
- Volver a la red predeterminada si la segmentación de red empresarial no está disponible
- Enruta el tráfico de todas las apps del perfil de trabajo a la conexión correspondiente.
Compatibilidad con la segmentación empresarial
- Detectar la presencia de un perfil de trabajo en el dispositivo
- Verificación de permisos o indicaciones de ruta proporcionadas por el DPC que usa el administrador de TI de la empresa
El servicio de redes principal incluye los siguientes cambios en el módulo de Tethering en Android 12:
- Se agregan la mayoría de las clases de API públicas o del sistema de
android.net.*al módulo Tethering. Se expanden los límites del módulo de conexión mediante dispositivo móvil para incluir lo siguiente:
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.javaf/b/services/core/java/com/android/server/TestNetworkService.java
Mueve el código de VPN fuera del módulo Tethering
Android 12 mueve el código con las siguientes capacidades al módulo de Tethering:
- Recibir solicitudes de apps para conexiones de red
- Recibir solicitudes del sistema (por ejemplo, "coloca estas apps en una segmentación empresarial"; se introdujo en Android 12)
- Envía solicitudes del sistema al código de telefonía, que intenta configurar redes o segmentos a través de la API de HAL y el módem.
- Informa a netd cómo enrutar el tráfico por app (se introdujo en Android 12).
- Informar a las apps lo que sucede con su tráfico de red a través de las APIs de
ConnectivityManager, comoNetworkCallback,getActiveNetworkygetNetworkCapabilities
Implementación
Para admitir la segmentación de 5G en un dispositivo, este debe tener un módem que admita la HAL de IRadio 1.6, que tiene la API de setupDataCall_1_6. Esta API configura una conexión de datos y, para admitir la segmentación de 5G, incluye los siguientes parámetros:
trafficDescriptor: Especifica el descriptor de tráfico que se envía al módem.sliceInfo: Especifica la información del segmento de red que se usará en caso de transferencia de EPDG a 5G.matchAllRuleAllowed: Especifica si se permite usar una regla de URSP predeterminada que coincida con todo. Telefonía establece este valor como verdadero para las redes predeterminadas, pero no para las segmentaciones. La regla de coincidencia con todo se aplica a las redes predeterminadas. Cuando una app solicita un segmento específico que no está disponible, se informa que el segmento específico no está disponible. En el caso de las apps empresariales, el framework de telefonía puede recurrir a la red predeterminada si la red empresarial no está disponible.
Los módems también deben implementar la API de getSlicingConfig, a menos que la API de getHalDeviceCapabilities indique que no es compatible.
Requisitos de Enterprise
A continuación, se describen los requisitos para que las empresas usen la segmentación de red 5G en dispositivos en una implementación de Android Enterprise.
- Asegúrate de que los dispositivos completamente administrados o de empleados configurados con un perfil de trabajo sean compatibles con 5G SA y tengan módems que admitan la API de
setupDataCall_1_6. - Trabaja con el socio operador en la configuración y el rendimiento de la segmentación, o bien en las características del ANS.
Habilita la segmentación de 5G en dispositivos configurados con un perfil de trabajo
En los dispositivos configurados con perfiles de trabajo, la segmentación de redes 5G está desactivada de forma predeterminada en AOSP. Para habilitar el segmentación de red, los administradores de TI empresariales pueden activar o desactivar el enrutamiento del tráfico de las apps del perfil de trabajo al segmento de red empresarial por empleado a través del DPC de EMM, que usa el método setPreferentialNetworkServiceEnabled de la API de DevicePolicyManager (DPM) (introducida en Android 12).
Los proveedores de EMM con DPCs personalizados deben integrar la API de DevicePolicyManager para admitir clientes empresariales.
Reglas de la URSP
En esta sección, se incluye información para los operadores sobre la configuración de reglas de URSP para diferentes categorías de segmentos, como tráfico empresarial, de CBS, de baja latencia, de alto ancho de banda y de comunicaciones unificadas.
Cuando configuran reglas de la URSP, los operadores pueden usar descriptores de tráfico basados en los siguientes factores:
- Tipo de ID de SO y de ID de app del SO, tipo de componente
0x08, compatible con Android 12 y versiones posteriores - Tipo de capacidades de conexión, tipo de componente
0x90, compatible con Android 17 y versiones posteriores
ID del SO y de la app del SO
Cuando configuren reglas de la URSP con el componente del descriptor de tráfico de tipo ID del SO y ID de la app del SO, los operadores pueden usar los siguientes valores de ID del SO y de ID de la app del SO específicos de Android.
| ID | Valor | Descripción |
|---|---|---|
| ID de SO | 97a498e3-fc92-5c94-8986-0333d06e4e47 |
El ID del SO para Android es un UUID de versión 5 generado con el OID de ISO del espacio de nombres y el nombre Android. |
Los operadores que configuren reglas de URSP con el tipo de ID de SO y de ID de app del SO deben configurar el tráfico de cada segmento con el componente del descriptor de tráfico como una concatenación del ID de SO, la longitud del ID de app del SO (0x0A) y el ID de app del SO. Por ejemplo, la segmentación ENTERPRISE debe tener un valor de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345.
Para obtener más información sobre el tipo de componente del descriptor de tráfico, consulta la Tabla 5.2.1 de 3GPP TS 24.526.
En la siguiente tabla, se describen los valores de OSAppId para diferentes categorías de segmentación.
| Categoría de segmentación | OSAppId | Descripción |
|---|---|---|
ENTERPRISE |
0x454E5445525052495345 |
El OSAppId es una representación de matriz de bytes de la cadena ENTERPRISE. |
ENTERPRISE2 |
0x454E544552505249534532 |
El OSAppId es una representación de matriz de bytes de la cadena ENTERPRISE2. |
ENTERPRISE3 |
0x454E544552505249534533 |
El OSAppId es una representación de matriz de bytes de la cadena ENTERPRISE3. |
ENTERPRISE4 |
0x454E544552505249534534 |
El OSAppId es una representación de matriz de bytes de la cadena ENTERPRISE4. |
ENTERPRISE5 |
0x454E544552505249534535 |
El OSAppId es una representación de matriz de bytes de la cadena ENTERPRISE5. |
CBS |
0x434253 |
El OSAppId es una representación de matriz de bytes de la cadena CBS. |
PRIORITIZE_LATENCY |
0x5052494f524954495a455f4c4154454e4359 |
El OSAppId es una representación de matriz de bytes de la cadena PRIORITIZE_LATENCY. |
PRIORITIZE_BANDWIDTH |
0x5052494f524954495a455f42414e445749445448 |
El OSAppId es una representación de matriz de bytes de la cadena PRIORITIZE_BANDWIDTH. |
PRIORITIZE_UNIFIED_COMMUNICATIONS |
0x5052494f524954495a455f554e49464945445f434f4d4d554e49434154494f4e53 |
El OSAppId es una representación de matriz de bytes de la cadena PRIORITIZE_UNIFIED_COMMUNICATIONS. |
No tenemos planes para introducir nuevos valores de OSAppId. Mejoraremos el descriptor de tráfico de las capacidades de conexión según sea necesario.
Capacidades de conexión
A partir de Android 17 y versiones posteriores (AIDL de HAL de radio 2.5 y versiones posteriores), Android admite el componente de descriptor de tráfico de capacidades de conexión (tipo 0x90), definido en la Tabla 5.2.1 de 3GPP TS 24.526.
Cuando una app o un servicio del sistema solicitan una red con una capacidad específica, la pila de datos de telefonía de Android asigna el NetworkCapabilities solicitado a un valor de capacidad de conexión estándar que se propaga en el TrafficDescriptor que se envía al módem durante la configuración de la llamada de datos (setupDataCall). Si bien la especificación de 3GPP permite múltiples capacidades de conexión en un solo descriptor, el framework de telefonía de Android 17 asigna las múltiples capacidades de conexión solicitadas a una sola capacidad de conexión.
En la siguiente tabla, se describe la asignación predeterminada de las capacidades de red de Android a las capacidades de conexión de 3GPP:
| Capacidad de red | Capacidad de conexión | Valor (hexadecimal o decimal) | Descripción |
|---|---|---|---|
NET_CAPABILITY_IMS |
CONNECTION_CAPABILITY_IMS |
0x01 (1) |
Comunicaciones de voz y video por IMS |
NET_CAPABILITY_MMS |
CONNECTION_CAPABILITY_MMS |
0x02 (2) |
Tráfico de MMS |
NET_CAPABILITY_SUPL |
CONNECTION_CAPABILITY_SUPL |
0x04 (4) |
Ubicación segura del plano de usuario (SUPL) |
NET_CAPABILITY_INTERNET |
CONNECTION_CAPABILITY_INTERNET |
0x08 (8) |
Tráfico de datos de Internet predeterminado |
NET_CAPABILITY_PRIORITIZE_LATENCY |
CONNECTION_CAPABILITY_REAL_TIME_INTERACTIVE |
0xA6 (166) |
Tráfico interactivo en tiempo real (por ejemplo, videojuegos, RA/RV) |
NET_CAPABILITY_PRIORITIZE_BANDWIDTH |
CONNECTION_CAPABILITY_DOWNLINK_STREAMING |
0xA3 (163) |
Tráfico de transmisión de alto ancho de banda de vínculo descendente |
NET_CAPABILITY_PRIORITIZE_UNIFIED_COMMUNICATIONS |
CONNECTION_CAPABILITY_UNIFIED_COMMUNICATIONS |
0xA7 (167) |
Comunicaciones unificadas (por ejemplo, llamadas de voz o videollamadas OTT) |
Configuración de URSP del operador y retrocompatibilidad
Para garantizar un funcionamiento perfecto en dispositivos con diferentes versiones de HAL y SO, los operadores deben tener en cuenta el siguiente comportamiento cuando aprovisionan reglas de URSP:
- Dispositivos con Android 16 o versiones anteriores (AIDL de HAL de radio 2.4 y versiones anteriores): El módem recibe al menos el
OSAppIden el descriptor de tráfico. - Dispositivos que ejecutan Android 17 o versiones posteriores (AIDL 2.5 y versiones posteriores): Para las capacidades de segmentación premium (como baja latencia, alto ancho de banda y comunicaciones unificadas), la plataforma completa
OSAppId,ConnectionCapabilityo ambos en el descriptor de tráfico.
Los operadores pueden configurar reglas de URSP con uno de los siguientes enfoques:
- Reglas basadas en la precedencia (recomendadas):
- Regla A (mayor precedencia, número de precedencia más bajo, por ejemplo, 10): Coincide con las capacidades de conexión (por ejemplo,
0xA6para baja latencia,0xA3para ancho de banda alto o0xA7para comunicaciones unificadas). Los dispositivos con Android 17 y versiones posteriores cumplen primero con esta regla. - Regla B (precedencia inferior, número de precedencia superior, por ejemplo, 20): Coincide con el ID del SO y el tipo de ID de la app del SO (por ejemplo,
PRIORITIZE_LATENCY). Los dispositivos más antiguos que no admiten la capacidad de conexión en la HAL coinciden con esta regla de resguardo.
- Regla A (mayor precedencia, número de precedencia más bajo, por ejemplo, 10): Coincide con las capacidades de conexión (por ejemplo,
- Regla solo para el ID de la app del SO (heredada):
- Los operadores pueden seguir usando las reglas existentes de la URSP según el tipo de ID del SO y el ID de la app del SO. Dado que los dispositivos con Android 17 y versiones posteriores siguen pasando el
OSAppId, tanto los dispositivos nuevos como los más antiguos cumplen con éxito estas reglas.
- Los operadores pueden seguir usando las reglas existentes de la URSP según el tipo de ID del SO y el ID de la app del SO. Dado que los dispositivos con Android 17 y versiones posteriores siguen pasando el
- Regla combinada (condición AND):
- Los operadores pueden especificar el ID del SO, el ID de la app del SO y las capacidades de conexión en un solo descriptor de tráfico. Esta regla solo coincide con dispositivos que ejecutan Android 17 o versiones posteriores con AIDL 2.5 o versiones posteriores.
Ejemplo de reglas de la URSP
En las siguientes tablas, se muestran ejemplos de reglas de URSP para tráfico empresarial, de CBS, de baja latencia, de alto ancho de banda, de comunicaciones unificadas y predeterminado.
Enterprise 1
La compatibilidad con Enterprise 1 está disponible en Android 12 y versiones posteriores.
A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE1:
| Regla 1 de URSP (ENTERPRISE1) | |
|---|---|
| Prioridad | 1 (0x01) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise |
Enterprise 2
La compatibilidad con Enterprise 2 está disponible en Android 13 y versiones posteriores.
A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE2:
| Regla 2 de URSP (ENTERPRISE2) | |
|---|---|
| Prioridad | 2 (0x02) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise2 |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise2 |
Enterprise 3
La compatibilidad con Enterprise 3 está disponible en Android 13 y versiones posteriores.
A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE3:
| Regla de URSP 3 (ENTERPRISE3) | |
|---|---|
| Prioridad | 3 (0x03) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise3 |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise3 |
Enterprise 4
La compatibilidad con Enterprise 4 está disponible en Android 13 y versiones posteriores.
A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE4:
| Regla URSP 4 (ENTERPRISE4) | |
|---|---|
| Prioridad | 4 (0x04) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise4 |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise4 |
Enterprise 5
La compatibilidad con Enterprise 5 está disponible en Android 13 y versiones posteriores.
A continuación, se muestra un ejemplo de regla de URSP para el tráfico de ENTERPRISE5:
| Regla 5 de URSP (ENTERPRISE5) | |
|---|---|
| Prioridad | 5 (0x05) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | enterprise5 |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | enterprise5 |
CBS
La compatibilidad con CBS está disponible en Android 13 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de CBS:
| Regla 6 de URSP (CBS) | |
|---|---|
| Prioridad | 6 (0x06) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | cbs |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | cbs |
Baja latencia con capacidad de conexión
La compatibilidad con las capacidades de conexión en las reglas de URSP está disponible en Android 17 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de baja latencia que usa el descriptor de capacidades de conexión:
| Regla 7 de URSP (baja latencia con capacidad de conexión) | |
|---|---|
| Prioridad | 7 (0x07) |
| Descriptor de tráfico núm. 1 | |
| Tipo de capacidades de conexión | 0xA6 (166: Interactivo en tiempo real) |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | latencia |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | latencia |
Latencia baja con OSAppId
La compatibilidad con baja latencia está disponible en Android 13 y versiones posteriores.
A continuación, se muestra un ejemplo de regla de URSP para el tráfico de LOW_LATENCY que usa OSAppId:
| Regla 8 de URSP (baja latencia con respaldo de OSAppId) | |
|---|---|
| Prioridad | 8 (0x08) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | latencia |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | latencia |
Ancho de banda alto con capacidad de conexión
La compatibilidad con las capacidades de conexión en las reglas de URSP está disponible en Android 17 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de banda ancha alta que usa el descriptor de capacidades de conexión:
| Regla 9 de la URSP (ancho de banda alto con capacidad de conexión) | |
|---|---|
| Prioridad | 9 (0x09) |
| Descriptor de tráfico núm. 1 | |
| Tipo de capacidades de conexión | 0xA3 (163: Transmisión de enlace descendente) |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | bandwidth |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | bandwidth |
Ancho de banda alto con OSAppId
La compatibilidad con un ancho de banda alto está disponible en Android 13 y versiones posteriores.
A continuación, se muestra un ejemplo de regla de URSP para el tráfico de HIGH_BANDWIDTH que usa OSAppId:
| Regla 10 de la URSP (ancho de banda alto con respaldo de OSAppId) | |
|---|---|
| Prioridad | 10 (0x0A) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
| Componente 2: DNN | bandwidth |
| Descriptor de selección de ruta núm. 2 | |
| Prioridad | 2 (0x02) |
| Componente 1: DNN | bandwidth |
Comunicaciones unificadas con capacidad de conexión
La compatibilidad con comunicaciones unificadas está disponible en Android 17 y versiones posteriores. A continuación, se muestra un ejemplo de una regla de URSP para el tráfico de UNIFIED_COMMUNICATIONS que usa la capacidad de conexión.
Dado que el tráfico de comunicaciones unificadas se enruta a través de la conexión de datos predeterminada de Internet, no se requiere un APN (DNN) dedicado en el descriptor de selección de ruta:
| Regla 11 de la URSP (comunicaciones unificadas con capacidad de conexión) | |
|---|---|
| Prioridad | 11 (0x0B) |
| Descriptor de tráfico núm. 1 | |
| Tipo de capacidades de conexión | 0xA7 (167: Comunicaciones unificadas) |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
Comunicaciones unificadas con OSAppId
La compatibilidad con comunicaciones unificadas está disponible en Android 17 y versiones posteriores. A continuación, se muestra un ejemplo de regla de URSP para el tráfico de UNIFIED_COMMUNICATIONS que usa OSAppId:
| Regla 12 de URSP (comunicaciones unificadas con respaldo de OSAppId) | |
|---|---|
| Prioridad | 12 (0x0C) |
| Descriptor de tráfico núm. 1 | |
| ID de SO + tipo de ID de app para SO | 0x97A498E3FC925C9489860333D06E4E47215052494F524954495A455F554E49464945445F434F4D4D554E49434154494F4E53 |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
Predeterminado
| Regla 13 de URSP (predeterminada) | |
|---|---|
| Prioridad | 13 (0x0D) |
| Descriptor de tráfico núm. 1 | |
| match-all | N/A |
| Descriptor de selección de ruta núm. 1 | |
| Prioridad | 1 (0x01) |
| Componente 1: S-NSSAI | SST:XX SD:YYYYYY |
Pruebas
Para probar el segmentado de red 5G, usa la siguiente prueba manual.
Para configurar un dispositivo para pruebas, haz lo siguiente:
Asegúrate de que la política de URSP esté configurada con una regla no predeterminada que coincida con la categoría empresarial y de que el descriptor de selección de ruta correspondiente asigne la categoría empresarial a la división empresarial, y una regla predeterminada que dirija el tráfico a la división de Internet predeterminada.
Asegúrate de que haya un perfil de trabajo configurado en el dispositivo.
Habilita el uso de segmentación de red a través del DPC
Para probar el comportamiento de la segmentación de red 5G, haz lo siguiente:
- Verifica que se haya establecido una sesión de PDU con la segmentación empresarial (por ejemplo, usando una dirección IP específica) y que las apps del perfil de trabajo usen esa sesión de PDU.
- Verifica que se establezca una sesión de PDU independiente con la porción de Internet predeterminada y que las apps del perfil personal usen la sesión de PDU.
Venta incremental de segmentación de 5G
La función de venta incremental de segmentación de 5G, disponible a partir de Android 14 QPR1, permite a los operadores ofrecer capacidades de red mejoradas (latencia y ancho de banda) a sus usuarios a través de la segmentación de la red 5G.
La función de venta incremental de segmentación de 5G usa la respuesta TS.43 del servidor de derechos del operador para impulsar el flujo de compra. Las empresas de telefonía celular pueden usar la respuesta para especificar la URL de la WebView de compra de la empresa, enviar datos adicionales a la WebView y, además, indicar si la segmentación está aprovisionada y disponible en la red de la empresa.
Los operadores pueden personalizar el comportamiento de la función de venta sugerida de segmentación de 5G con configuraciones del operador, que controlan si se pueden realizar solicitudes de compra, cuándo se permite que las apps soliciten capacidades premium y cuánto tiempo espera el framework de Telephony las respuestas del usuario o la red.
La función de venta adicional de segmentación de 5G proporciona una interfaz, llamada DataBoostWebServiceFlow, para permitir la comunicación entre Android y la WebView del operador.
En la figura 2, se muestra el flujo de compra de la venta incremental de segmentación de 5G:
Figura 2: Flujo de compra de la venta incremental de segmentación de 5G.
Proceso de derechos de TS.43
Cuando un usuario solicita capacidades de red mejoradas, el framework de Telephony solicita la configuración de derechos del servicio para la capacidad premium solicitada. Si la respuesta TS.43 es válida, el framework de Telephony usa los campos de la respuesta HTTP para controlar la solicitud de compra.
Segmenta los campos de compra
La configuración de derechos de TS.43 incluye los siguientes campos de compra de segmentos:
- Estado de autorización
Clave:
EntitlementStatusTipo:
intValores admitidos:
0(inhabilitado),1(habilitado),2(incompatible),3(aprovisionamiento),4(incluido)- Estado de aprovisionamiento
Clave:
ProvStatusTipo:
intValores admitidos:
0(no aprovisionado),1(aprovisionado),2(no disponible),3(en curso)
El framework de Telephony usa la combinación del estado de derechos y el estado de aprovisionamiento para determinar el estado actual de la compra de la segmentación. El resultado puede ser uno de los siguientes:
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASEDPURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESSPURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILEDPURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Si el estado del derecho es 1 (habilitado) y el estado de aprovisionamiento es 0 (no aprovisionado), el framework de Telephony muestra una notificación de aumento de ventas al usuario para que compre el aumento a través de la WebView del operador. En la siguiente tabla, se describe el comportamiento del framework de Telephony para diferentes combinaciones de valores de aprovisionamiento y estado de derechos.
| Estado de aprovisionamiento | |||||
|---|---|---|---|---|---|
No aprovisionado (0) |
Aprovisionado (1) |
No disponible (2) |
En curso (3) |
||
| Estado del derecho | Inhabilitado (0) |
Con errores | Con errores | Con errores | Con errores |
Habilitado (1) |
Mostrar WebView | Ya compré ese producto | Ya compré ese producto | En curso | |
Incompatible (2) |
Con errores | Con errores | Con errores | Con errores | |
Aprovisionamiento (3) |
Error de la empresa de transporte | Error de la empresa de transporte | En curso | En curso | |
Incluido (4) |
Error de la empresa de transporte | Ya compré ese producto | Ya compré ese producto | Error de la empresa de transporte | |
Campos del flujo de servicio
La respuesta TS.43 especifica la URL, los datos del usuario y el tipo de contenido para personalizar el comportamiento de la WebView de compra del operador. Si no se especifica el tipo de contenido, la URL se carga como una solicitud GET. Si los datos del usuario existen, se agregan a la URL como un parámetro de consulta (por ejemplo, https://www.android.com?encodedValue=Base64EncodedUserData). Si no existen, la URL se usa tal cual (por ejemplo, https://www.android.com).
Si el tipo de contenido se especifica en formato JSON o XML, la URL se carga como una solicitud POST y los datos del usuario (decodificados si están codificados en Base64) se envían como los datos de la solicitud POST.
- URL
Clave:
ServiceFlow_URLTipo:
StringEjemplo:
"https://www.android.com"- Datos del usuario
Clave:
ServiceFlow_UserDataTipo:
StringEjemplo:
"encodedValue=Base64EncodedUserData"- Tipo de contenido
Clave:
ServiceFlow_ContentsTypeTipo:
StringValores admitidos:
0(sin especificar),1(JSON),2(XML)
Configuraciones de la empresa de transporte
A continuación, se muestran las configuraciones del operador disponibles para personalizar el comportamiento de la función de venta superior de segmentación de 5G.
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAYEs una lista de las capacidades premium admitidas. Es un array de números enteros de
TelephonyManager.PremiumCapability. Estas capacidades premium comparten el mismo valor que la claseNetworkCapabilities.NetCapabilitycorrespondiente. Si se solicita una función premium y no se incluye en esta configuración, la solicitud de compra falla con el resultadoCARRIER_DISABLED.En Android 14, solo se admite
PREMIUM_CAPABILITY_PRIORITIZE_LATENCY.KEY_PREMIUM_CAPABILITY_MAXIMUM_DAILY_NOTIFICATION_COUNT_INTEs la cantidad máxima diaria de veces que se muestra la notificación de aumento de ventas de compra al usuario. Si se alcanza el máximo diario, no se muestra la notificación de venta sugerida y se limitan las solicitudes de compra (incluidas las solicitudes del servidor de derechos) hasta la medianoche del día siguiente. Las solicitudes de compra realizadas después de alcanzar el máximo diario fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_MAXIMUM_MONTHLY_NOTIFICATION_COUNT_INTEs la cantidad máxima mensual de veces que se muestra la notificación de aumento de ventas de compra al usuario. Si se alcanza el máximo mensual, no se muestra la notificación de aumento de ventas y se limitan las solicitudes de compra (incluidas las solicitudes del servidor de derechos) hasta el primer día del mes siguiente. Las solicitudes de compra realizadas después de alcanzar el máximo mensual fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_URL_STRINGEs la URL de compra de la empresa de telefonía celular de respaldo que se mostrará al usuario cuando haga clic en la notificación de venta sugerida. Si no se encuentra la URL de compra en la respuesta TS.43 del servidor de derechos, se usa este valor. Si no es válida la URL de la respuesta TS.43 ni la configuración del operador, la solicitud de compra falla con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOLIndica si se permite comprar funciones premium cuando el dispositivo está conectado a la evolución a largo plazo (LTE). Si es
true, se pueden realizar solicitudes de compra en LTE y New Radio (NR). Si esfalse, las solicitudes de compra solo se pueden realizar en NR, y las solicitudes realizadas en LTE fallan con el resultadoPURCHASE_PREMIUM_CAPABILITY_RESULT_NETWORK_NOT_AVAILABLE.KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGEs la cantidad de tiempo que se muestra la notificación de aumento de ventas de compra al usuario antes de que se cancele automáticamente. Cuando se cancela la notificación, las solicitudes posteriores se limitan y fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NOTIFICATION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGEs la cantidad de tiempo durante la que se deben limitar las solicitudes de compra posteriores después de una falla debido a un tiempo de espera agotado o a la cancelación del usuario. Si el usuario no hace clic en la notificación de venta adicional de compra dentro del tiempo de espera especificado por
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONG, o si cancela o descarta la notificación, se inicia este temporizador de espera. Mientras este temporizador está activo, las solicitudes de compra fallan con el resultadoPURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_PURCHASE_CONDITION_BACKOFF_HYSTERESIS_TIME_MILLIS_LONGEs la cantidad de tiempo durante la que se deben limitar las solicitudes de compra posteriores después de una falla debido al operador o la red. Si falla la verificación de derechos, la URL no está disponible o la URL de compra del operador indica una falla, se inicia este temporizador de espera. Mientras este temporizador está activo, las solicitudes de compra fallan con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_THROTTLED.KEY_PREMIUM_CAPABILITY_NETWORK_SETUP_TIME_MILLIS_LONGEs la cantidad de tiempo dentro de la cual la red debe configurar una configuración de segmentación para la capacidad premium de compra. Durante este período, se bloquean las solicitudes de compra posteriores y se devuelve el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Si la red no logra configurar la segmentación a tiempo, las apps pueden volver a solicitar la compra de capacidades premium. La telefonía no considera que una compra se haya completado hasta que se envía la configuración de segmentación correspondiente, independientemente de si el usuario pagó al operador o no.
Interfaz de JavaScript
Cuando el usuario hace clic en la notificación de refuerzo de red, se le muestra un objeto WebView con la URL de compra del operador. Las empresas de transporte pueden usar las APIs proporcionadas en la interfaz de JavaScript DataBoostWebServiceFlow en su sitio web de compra para comunicarse con la app de compra de segmentos.
El sitio web de la empresa de transporte puede obtener la capacidad premium solicitada a través del método getRequestedCapability().
Si la compra se realiza correctamente, el sitio web del operador debe notificar a la app de compra de segmentos a través de notifyPurchaseSuccessful() o notifyPurchaseSuccessful(duration), donde duration es un parámetro opcional que indica la duración prevista del segmento.
Si la compra no se realiza correctamente, el sitio web del operador debe notificar a la app de compra de segmentos a través del método notifyPurchaseFailed(code, reason), en el que code es el código de error que indica el motivo del error y reason es el motivo del error legible por humanos si el código de error es desconocido.
Si no se llama a ninguno de estos métodos de respuesta, la compra no se considerará completada y, finalmente, se agotará el tiempo de espera de la solicitud de compra.
A continuación, se indican los códigos de error válidos que puede devolver el sitio web de la empresa de transporte en caso de falla en la compra:
FAILURE_CODE_UNKNOWNFAILURE_CODE_CARRIER_URL_UNAVAILABLEFAILURE_CODE_AUTHENTICATION_FAILEDFAILURE_CODE_PAYMENT_FAILEDFAILURE_CODE_NO_USER_DATA
Cuando se completa la compra, el operador debe actualizar las reglas de URSP con la división PRIORITIZE_LATENCY en el dispositivo del usuario.
Enrutamiento automático de segmentación de 5G para voz y video de OTT
Android 17 admite el enrutamiento automático de llamadas de voz y videollamadas de transmisión libre (OTT) a conexiones de red premium. Esta función permite que el sistema dirija automáticamente el tráfico de las llamadas de voz y video a una interfaz de red premium dedicada (como una porción 5G premium o una conexión PDN 4G premium) sin necesidad de realizar cambios en la pila de redes de la app.
Esta solución a nivel de la plataforma elimina la necesidad de que los desarrolladores de apps soliciten explícitamente capacidades de red, lo que proporciona una experiencia fluida tanto para los desarrolladores como para los usuarios finales.
Cómo funciona
Android incorpora compatibilidad con el enrutamiento automático a través de adiciones a los frameworks de conectividad y telecomunicaciones. La función de enrutamiento automático funciona de la siguiente manera:
- Detección de llamadas: El sistema aprovecha las APIs existentes de Telecom Jetpack que usan las apps de OTT para detectar el inicio y el final de las llamadas de voz o video.
- Administración de conexiones: Cuando se detecta una llamada, Android muestra una interfaz de red premium designada, como una división de comunicación unificada.
- Direccionamiento del tráfico: Durante la llamada, la plataforma identifica la aplicación por su UID y enruta automáticamente su tráfico a la conexión de red premium.
- Respaldo posterior a la llamada: Cuando finaliza la llamada, la plataforma quita la regla de enrutamiento y el tráfico de la app vuelve a la red predeterminada del sistema para el tráfico que no es de llamadas (como la mensajería).
Requisitos
Para admitir el enrutamiento automático de llamadas OTT, se deben cumplir los siguientes requisitos:
- Operadores: Deben ofrecer un segmento de comunicación unificado configurando reglas de URSP adecuadas (con capacidad de conexión o OSAppId para el tráfico de comunicación unificada).
- Apps: Deben usar las APIs de Android Telecom Jetpack para permitir que el sistema detecte los estados de las llamadas.
- Fabricantes de dispositivos: Se requiere Android 17 o una versión posterior.