Para dispositivos que ejecutan Android 12 o superior, Android brinda soporte para la división de red 5G, el uso de virtualización de red para dividir conexiones de red únicas en múltiples conexiones virtuales distintas que proporcionan diferentes cantidades de recursos para diferentes tipos de tráfico. La división de la red 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 presenta las siguientes capacidades de división de redes empresariales 5G, que los operadores de red pueden proporcionar a sus clientes empresariales:
División de dispositivos empresariales para dispositivos totalmente administrados
Para las empresas que proporcionan dispositivos empresariales totalmente administrados a sus empleados, los proveedores de red pueden proporcionarles uno o más segmentos de red empresarial activos a los que se dirige el tráfico de los dispositivos de la empresa. A partir de Android 12, Android permite a los operadores proporcionar segmentos empresariales a través de reglas URSP, en lugar de configurar segmentos a través de APN.
División de aplicaciones empresariales para dispositivos con perfiles de trabajo
Para las empresas que utilizan la solución de perfil de trabajo , Android 12 permite que los dispositivos enruten el tráfico de todas las aplicaciones en el perfil de trabajo a una porción de la red empresarial. Las empresas pueden habilitar esta capacidad a través de un Controlador de políticas de dispositivos (DPC) .
La solución de perfil de trabajo proporciona un nivel automático de autenticación y control de acceso que las empresas necesitan para garantizar que solo el tráfico de las aplicaciones empresariales en el perfil de trabajo se enrute al segmento de red empresarial. No es necesario modificar las aplicaciones en el perfil de trabajo para solicitar explícitamente el segmento de red empresarial.
Cómo funciona la división de redes 5G en AOSP
Android 12 introduce soporte para la división de redes 5G mediante adiciones al código base de telefonía en AOSP y el módulo Tethering para incorporar las API de conectividad existentes que se requieren para la división de redes.
La plataforma de telefonía Android proporciona HAL y API de telefonía para admitir la división basada en solicitudes de red presentadas por el código de red central y las capacidades de división 5G en el módem. La Figura 1 describe los componentes de la función de división de red 5G.
Figura 1. Arquitectura de corte de red 5G en AOSP.
La plataforma de telefonía y conectividad soporta:
- Convertir solicitudes de red para categorías de sectores en descriptores de tráfico que luego se pasan al módem para la comparación del tráfico URSP y la selección de rutas.
- Recurrir a la red predeterminada si el segmento de red empresarial no está disponible
- Dirigir el tráfico de todas las aplicaciones bajo el perfil de trabajo a la conexión correspondiente
Apoyando el corte empresarial
- Detectar la presencia de un perfil de trabajo en el dispositivo
- Comprobación de permisos o direcciones de enrutamiento proporcionadas por el DPC utilizado por el administrador de TI de la empresa
El servicio de red principal incluye los siguientes cambios en el módulo Tethering en Android 12:
- Agrega la mayoría de las clases API públicas o del sistema
android.net.*al módulo Tethering Amplía los límites del módulo Tethering para incluir:
-
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
-
Mueve el código VPN fuera del módulo Tethering
Android 12 mueve código con las siguientes capacidades al módulo Tethering:
- Recibir solicitudes de aplicaciones para conexiones de red
- Recibir solicitudes del sistema (por ejemplo, "colocar estas aplicaciones en una porción empresarial"; introducido en Android 12)
- Envío de solicitudes desde el sistema al código de telefonía que intenta configurar redes o segmentos pasando por la API HAL y el módem.
- Informar a Netd sobre cómo enrutar el tráfico por aplicación (introducido en Android 12)
- Informar a las aplicaciones qué está sucediendo con el tráfico de su red a través de las API
ConnectivityManager, comoNetworkCallback,getActiveNetwork,getNetworkCapabilities.
Implementación
Para admitir la división 5G en un dispositivo, el dispositivo debe tener un módem que admita IRadio 1.6 HAL que tenga la API setupDataCall_1_6 . Esta API configura una conexión de datos e incluye los siguientes parámetros para admitir el corte 5G:
-
trafficDescriptor: especifica el descriptor de tráfico enviado al módem. -
sliceInfo: especifica información para el segmento de red que se utilizará en caso de transferencia de EPDG a 5G. -
matchAllRuleAllowed: especifica si se permite el uso de una regla URSP predeterminada que coincida con todos. Telefonía establece esto en verdadero para las redes predeterminadas, pero no para los segmentos. La regla de coincidir todo se aplica a las redes predeterminadas. Cuando una aplicación solicita un segmento específico que no está disponible, el segmento específico se informa como no disponible. Para aplicaciones empresariales, el marco 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 getSlicingConfig a menos que la API getHalDeviceCapabilities indique que no es compatible.
Requisitos empresariales
A continuación se describen los requisitos para que las empresas utilicen la división de red 5G en dispositivos en una implementación empresarial de Android.
- Asegúrese de que los dispositivos totalmente administrados o de los empleados configurados con un perfil de trabajo sean compatibles con 5G SA con módems que admitan la API
setupDataCall_1_6. - Trabaje con el socio operador en la configuración y el rendimiento del segmento o las características del SLA.
Habilitar el corte 5G en dispositivos configurados con un perfil de trabajo
Para los dispositivos configurados con perfiles de trabajo, la división de red 5G está desactivada de forma predeterminada en AOSP. Para habilitar la división de red, los administradores de TI empresariales pueden activar o desactivar el enrutamiento del tráfico de la aplicación de perfil de trabajo hacia la división de red empresarial por empleado a través del EMM DPC, que utiliza el método setPreferentialNetworkServiceEnabled en la API DevicePolicyManager (DPM) (introducida en Android). 12).
Los proveedores de EMM con DPC personalizados deben integrar la API DevicePolicyManager para admitir clientes empresariales.
reglas de la URSP
Esta sección incluye información para los operadores sobre la configuración de reglas URSP para diferentes categorías de segmentos, incluido el tráfico empresarial, CBS, de baja latencia y de alto ancho de banda. Al configurar reglas URSP para diferentes categorías de sectores, los operadores deben utilizar los siguientes valores específicos de Android.
| IDENTIFICACIÓN | Valor | Descripción |
|---|---|---|
| OSID | 97a498e3-fc92-5c94-8986-0333d06e4e47 | El OSId para Android es un UUID versión 5 generado con el espacio de nombres ISO OID y el nombre "Android". |
Los operadores deben configurar reglas URSP para cada segmento de tráfico con el componente descriptor de tráfico como "ID de sistema operativo + tipo de ID de aplicación de sistema operativo". Por ejemplo, el segmento "EMPRESA" debe tener un valor de 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 . Este valor es una concatenación del OSId, la longitud del OSAppId ( 0x0A ) y el OSAppId. Para obtener más información sobre el tipo de componente del descriptor de tráfico, consulte la Tabla 5.2.1 de 3GPP TS 24.526 .
La siguiente tabla describe los valores de OSAppId para diferentes categorías de sectores.
| categoría de rebanada | ID de aplicación OS | Descripción |
|---|---|---|
| EMPRESA | 0x454E5445525052495345 | OSAppId es una representación de matriz de bytes de la cadena "ENTERPRISE" |
| EMPRESA2 | 0x454E544552505249534532 | OSAppId es una representación de matriz de bytes de la cadena "ENTERPRISE2" |
| EMPRESA3 | 0x454E544552505249534533 | OSAppId es una representación de matriz de bytes de la cadena "ENTERPRISE3" |
| EMPRESA4 | 0x454E544552505249534534 | OSAppId es una representación de matriz de bytes de la cadena "ENTERPRISE4" |
| EMPRESA5 | 0x454E544552505249534535 | OSAppId es una representación de matriz de bytes de la cadena "ENTERPRISE5" |
| CBS | 0x434253 | OSAppId es una representación de matriz de bytes de la cadena "CBS" |
| PRIORITIZE_LATENCY | 0x5052494f524954495a455f4c4154454e4359 | OSAppId es una representación de matriz de bytes de la cadena "PRIORITIZE_LATENCY" |
| PRIORIZAR_ANCHO DE BANDA | 0x5052494f524954495a455f42414e445749445448 | OSAppId es una representación de matriz de bytes de la cadena "PRIORITIZE_BANDWIDTH" |
Ejemplos de reglas URSP
Las siguientes tablas muestran ejemplos de reglas URSP para empresas, CBS, baja latencia, alto ancho de banda y tráfico predeterminado.
Empresa 1
La compatibilidad con Enterprise 1 está disponible en Android 12 y versiones posteriores. A continuación se muestra un ejemplo de regla URSP para el tráfico ENTERPRISE1:
| Regla URSP n.º 1 (empresa1) | |
|---|---|
| Precedencia | 1 (0x01) |
| Descriptor de tráfico n.° 1 | |
| ID del sistema operativo + tipo de ID de la aplicación del sistema operativo | 0x97A498E3FC925C9489860333D06E4E470A454E5445525052495345 |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
| Componente #2: DNN | empresa |
| Descriptor de selección de ruta #2 | |
| Precedencia | 2 (0x02) |
| Componente #1: DNN | empresa |
Empresa 2
La compatibilidad con Enterprise 2 está disponible en Android 13 y versiones posteriores. A continuación se muestra un ejemplo de regla URSP para el tráfico ENTERPRISE2:
| Regla URSP n.º 2 (empresa2) | |
|---|---|
| Precedencia | 2 (0x02) |
| Descriptor de tráfico n.° 1 | |
| ID del sistema operativo + tipo de ID de la aplicación del sistema operativo | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534532 |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
| Componente #2: DNN | empresa2 |
| Descriptor de selección de ruta #2 | |
| Precedencia | 2 (0x02) |
| Componente #1: DNN | empresa2 |
Empresa 3
La compatibilidad con Enterprise 3 está disponible en Android 13 y versiones posteriores. A continuación se muestra un ejemplo de regla URSP para el tráfico ENTERPRISE3:
| Regla URSP n.º 3 (empresa3) | |
|---|---|
| Precedencia | 3 (0x03) |
| Descriptor de tráfico n.° 1 | |
| ID del sistema operativo + tipo de ID de la aplicación del sistema operativo | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534533 |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
| Componente #2: DNN | empresa3 |
| Descriptor de selección de ruta #2 | |
| Precedencia | 2 (0x02) |
| Componente #1: DNN | empresa3 |
Empresa 4
La compatibilidad con Enterprise 4 está disponible en Android 13 y versiones posteriores. A continuación se muestra un ejemplo de regla URSP para el tráfico ENTERPRISE4:
| Regla URSP n.º 4 (empresa4) | |
|---|---|
| Precedencia | 4 (0x04) |
| Descriptor de tráfico n.° 1 | |
| ID del sistema operativo + tipo de ID de la aplicación del sistema operativo | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534534 |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
| Componente #2: DNN | empresa4 |
| Descriptor de selección de ruta #2 | |
| Precedencia | 2 (0x02) |
| Componente #1: DNN | empresa4 |
Empresa 5
La compatibilidad con Enterprise 5 está disponible en Android 13 y versiones posteriores. A continuación se muestra un ejemplo de regla URSP para el tráfico ENTERPRISE5:
| Regla URSP n.° 5 (empresa 5) | |
|---|---|
| Precedencia | 5 (0x05) |
| Descriptor de tráfico n.° 1 | |
| ID del sistema operativo + tipo de ID de la aplicación del sistema operativo | 0x97A498E3FC925C9489860333D06E4E470B454E544552505249534535 |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
| Componente #2: DNN | empresa5 |
| Descriptor de selección de ruta #2 | |
| Precedencia | 2 (0x02) |
| Componente #1: DNN | empresa5 |
CBS
La compatibilidad con CBS está disponible en Android 13 y versiones posteriores. El siguiente es un ejemplo de regla URSP para el tráfico CBS:
| Regla URSP #6 (CBS) | |
|---|---|
| Precedencia | 6 (0x06) |
| Descriptor de tráfico n.° 1 | |
| ID del sistema operativo + tipo de ID de la aplicación del sistema operativo | 0x97A498E3FC925C9489860333D06E4E4703434253 |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
| Componente #2: DNN | cbs |
| Descriptor de selección de ruta #2 | |
| Precedencia | 2 (0x02) |
| Componente #1: DNN | cbs |
Baja latencia
La compatibilidad con baja latencia está disponible en Android 13 y versiones posteriores. A continuación se muestra un ejemplo de regla URSP para tráfico de LOW_LATENCY:
| Regla URSP n.º 7 (baja latencia) | |
|---|---|
| Precedencia | 7 (0x07) |
| Descriptor de tráfico n.° 1 | |
| ID del sistema operativo + tipo de ID de la aplicación del sistema operativo | 0x97A498E3FC925C9489860333D06E4E47125052494f524954495a455f4c4154454e4359 |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
| Componente #2: DNN | latencia |
| Descriptor de selección de ruta #2 | |
| Precedencia | 2 (0x02) |
| Componente #1: DNN | latencia |
Alto ancho de banda
La compatibilidad con alto ancho de banda está disponible en Android 13 y versiones posteriores. A continuación se muestra un ejemplo de regla URSP para tráfico HIGH_BANDWIDTH:
| Regla URSP n.º 8 (gran ancho de banda) | |
|---|---|
| Precedencia | 8 (0x08) |
| Descriptor de tráfico n.° 1 | |
| ID del sistema operativo + tipo de ID de la aplicación del sistema operativo | 97A498E3FC925C9489860333D06E4E47145052494f524954495a455f42414e445749445448 |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
| Componente #2: DNN | banda ancha |
| Descriptor de selección de ruta #2 | |
| Precedencia | 2 (0x02) |
| Componente #1: DNN | banda ancha |
Por defecto
| Regla URSP n.º 9 (predeterminada) | |
|---|---|
| Precedencia | 9 (0x09) |
| Descriptor de tráfico n.° 1 | |
| combinar todos | N / A |
| Descriptor de selección de ruta #1 | |
| Precedencia | 1 (0x01) |
| Componente #1: S-NSSAI | SST:XX SD:AAAAAA |
Pruebas
Para probar la división de la red 5G, utilice la siguiente prueba manual.
Para configurar un dispositivo para realizar pruebas, haga lo siguiente:
Asegúrese de que la política URSP esté configurada con una regla no predeterminada que coincida con la categoría empresarial y que el descriptor de selección de ruta correspondiente asigne la categoría empresarial al segmento empresarial; y una regla predeterminada que dirige el tráfico al segmento de Internet predeterminado.
Asegúrese de que haya un perfil de trabajo configurado en el dispositivo.
Opte por utilizar la división de red a través del DPC
Para probar el comportamiento de división de la red 5G, haga lo siguiente:
- Verifique que se establezca una sesión de PDU con el segmento empresarial (por ejemplo, mediante el uso de una dirección IP específica) y que las aplicaciones en el perfil de trabajo usen esa sesión de PDU.
- Verifique que se establezca una sesión de PDU separada con el segmento de Internet predeterminado y que las aplicaciones en el perfil personal utilicen la sesión de PDU.
Venta adicional de rodajas de 5G
La función de venta adicional de divisió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 división de red 5G.
La función de ventas adicionales de segmentación 5G utiliza la respuesta TS.43 del servidor de derechos del operador para impulsar el flujo de compras. Los operadores pueden usar la respuesta para especificar la URL de la vista web de compra del operador, enviar datos adicionales a la vista web e indicar si el segmento está aprovisionado y disponible en la red del operador.
Los operadores pueden personalizar el comportamiento de la función de venta adicional de división de 5G utilizando configuraciones de operador, que controlan si se pueden realizar solicitudes de compra, cuándo se permite que las aplicaciones soliciten capacidades premium y cuánto tiempo espera el marco de telefonía por respuestas del usuario o de la red.
La función de venta adicional de segmentación 5G proporciona una interfaz, llamada DataBoostWebServiceFlow , para permitir la comunicación entre Android y la vista web del operador.
La Figura 2 muestra el flujo de compras de ventas adicionales de segmentación 5G:
Figura 2. Flujo de compras de ventas adicionales de segmentación 5G.
Proceso de titularidad TS.43
Cuando un usuario realiza una solicitud de capacidades de red mejoradas, el marco de Telefonía solicita la configuración de derecho de servicio para la capacidad premium solicitada. Si la respuesta TS.43 es válida, el marco de telefonía utiliza los campos de la respuesta HTTP para impulsar la solicitud de compra.
Cortar campos de compra
La configuración de derechos TS.43 incluye los siguientes campos de compra de sectores:
- Estado de derecho
Clave:
EntitlementStatusTipo:
intValores admitidos:
0(deshabilitado),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 marco de telefonía utiliza la combinación del estado de derecho y el estado de aprovisionamiento para determinar el estado actual de compra del segmento. El resultado puede ser uno de los siguientes:
-
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_PURCHASED -
PURCHASE_PREMIUM_CAPABILITY_RESULT_ALREADY_IN_PROGRESS -
PURCHASE_PREMIUM_CAPABILITY_RESULT_ENTITLEMENT_CHECK_FAILED -
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_ERROR
Si el estado del derecho es 1 (habilitado) y el estado de aprovisionamiento es 0 (no aprovisionado), el marco de telefonía muestra una notificación de venta adicional al usuario para que compre el impulso a través de la vista web del operador. La siguiente tabla describe el comportamiento del marco de telefonía para diferentes combinaciones de valores de estado de aprovisionamiento y derechos.
| Estado de aprovisionamiento | |||||
|---|---|---|---|---|---|
No aprovisionado ( 0 ) | Aprovisionado ( 1 )1 ) | No disponible ( 2 ) | En curso ( 3 ) | ||
| Estado de derecho | Deshabilitado ( 0 ) | Fallido | Fallido | Fallido | Fallido |
Habilitado ( 1 ) | Mostrar vista web | Ya comprado | Ya comprado | En curso | |
Incompatible ( 2 ) | Fallido | Fallido | Fallido | Fallido | |
Aprovisionamiento ( 3 ) | Error del operador | Error del operador | En curso | En curso | |
Incluido ( 4 ) | Error del operador | Ya comprado | Ya comprado | Error del operador | |
Campos de 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 vista web 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 parámetro de consulta (por ejemplo, https://www.android.com?encodedValue=Base64EncodedUserData ); y si no existe, 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 Base 64) se envían como datos para 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 del operador
Las siguientes son las configuraciones de operador disponibles para personalizar el comportamiento de la función de venta adicional de división de 5G.
-
KEY_SUPPORTED_PREMIUM_CAPABILITIES_INT_ARRAY Una lista de capacidades premium compatibles. Esta es una matriz int de
TelephonyManager.PremiumCapability. Estas capacidades premium comparten el mismo valor que la claseNetworkCapabilities.NetCapabilitycorrespondiente. Si se solicita una capacidad premium y no está incluida 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_INT El número máximo diario de veces que se muestra al usuario la notificación de compra adicional. Si se alcanza el máximo diario, la notificación de ventas adicionales no se muestra y las solicitudes de compra (incluidas las solicitudes del servidor de derechos) se limitan 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_INT El número máximo mensual de veces que se muestra al usuario la notificación de compra adicional. Si se alcanza el máximo mensual, la notificación de ventas adicionales no se muestra y las solicitudes de compra (incluidas las solicitudes del servidor de derechos) se limitan 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_STRING La URL de compra del operador de respaldo que se mostrará al usuario cuando haga clic en la notificación de venta adicional. Si la URL de compra no se encuentra en la respuesta TS.43 del servidor de derechos, se utiliza este valor. Si ni la URL de la respuesta TS.43 ni la configuración del operador son válidas, la solicitud de compra falla con el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_CARRIER_DISABLED.-
KEY_PREMIUM_CAPABILITY_SUPPORTED_ON_LTE_BOOL Si se permite la compra de capacidades premium cuando el dispositivo está conectado a Long-Term Evolution (LTE). Si es
true, las solicitudes de compra se pueden realizar tanto en LTE como en 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_LONG La cantidad de tiempo para mostrar la notificación de compra adicional 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_LONG La cantidad de tiempo que se deben limitar las solicitudes de compra posteriores después de un error debido al tiempo de espera o la cancelación del usuario. Si el usuario no hace clic en la notificación de compra adicional dentro del tiempo de espera especificado por
KEY_PREMIUM_CAPABILITY_NOTIFICATION_DISPLAY_TIMEOUT_MILLIS_LONGo 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_LONG La cantidad de tiempo que se deben limitar las solicitudes de compra posteriores después de una falla debida al operador o la red. Si la verificación de derechos falla, 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_LONG La cantidad de tiempo dentro del cual la red debe establecer una configuración de división para la capacidad premium de compra. Durante este período, las solicitudes de compra posteriores se bloquean y devuelven el resultado
PURCHASE_PREMIUM_CAPABILITY_RESULT_PENDING_NETWORK_SETUP. Si la red no logra establecer una configuración de división a tiempo, las aplicaciones pueden solicitar comprar capacidades premium nuevamente. Telefonía no considera una compra completa hasta que se envía la configuración de slicing correspondiente, independientemente de si el usuario pagó al operador o no.
interfaz javascript
Cuando el usuario hace clic en la notificación de aumento de red, se le muestra un objeto WebView con la URL de compra del operador. Los operadores pueden utilizar las API proporcionadas en la interfaz Javascript DataBoostWebServiceFlow en su sitio web de compra para comunicarse con la aplicación de compra por porción.
El sitio web del operador puede obtener la capacidad premium solicitada mediante el método getRequestedCapability() .
Si la compra se realiza correctamente, el sitio web del operador debe notificar a la aplicación de compra de fragmentos 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 aplicación de compra de porciones a través del método notifyPurchaseFailed(code, reason) , donde 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 Se desconoce el código de falla.
Si no se llama a ninguno de estos métodos de respuesta, la compra no se considerará completada y la solicitud de compra eventualmente expirará.
Los siguientes son los códigos de falla válidos que el sitio web del operador puede devolver por falla en la compra:
-
FAILURE_CODE_UNKNOWN -
FAILURE_CODE_CARRIER_URL_UNAVAILABLE -
FAILURE_CODE_AUTHENTICATION_FAILED -
FAILURE_CODE_PAYMENT_FAILED -
FAILURE_CODE_NO_USER_DATA
Cuando se completa la compra, el operador debe actualizar las reglas URSP con el segmento PRIORITIZE_LATENCY en el dispositivo del usuario.