Introducción al uso compartido del plan de datos móviles

Terminología

  • GTAF: Función de aplicación de tráfico de Google Un servicio de Google que implementa la API de uso compartido de planes de datos y que interactúa con las DPA en nombre de las aplicaciones de Google Las aplicaciones de Google pueden consultar al GTAF para obtener información sobre el plan de datos del usuario. Como alternativa, si las aplicaciones de Google se registran con GTAF, GTAF puede enviar actualizaciones sobre el plan de datos del usuario.
  • MSISDN: número de directorio de suscriptores internacionales de Mobile Station, un número que identifica de forma única una suscripción en una red móvil Más comúnmente conocido como número de teléfono.
  • Extremo de CPID: un servicio implementado por operadores de red móvil que genera un identificador de plan de proveedor (CPID) que se puede usar para buscar la información del plan de datos del usuario. CPID permite que una aplicación consulte los detalles del plan de datos de un usuario sin acceder al MSISDN del usuario. A continuación, describimos el procedimiento para generar CPID.
  • Clave de usuario: La clave de usuario es una string que se puede usar para identificar el plan de datos de un usuario. Puede ser el CPID o el MSISDN para las aplicaciones que tienen acceso al MSISDN.
  • DPA: Agente de plan de datos, un servicio implementado por operadores de redes móviles que comparte la información del plan de datos del usuario con GTAF. La APD puede compartir información con el GTAF mediante una combinación de envío de datos mediante la API de uso compartido del plan de datos móviles de Google y la implementación de la API del agente del plan de datos. El DPA también puede actuar como el extremo CPID.
  • UE: Es el equipo del usuario y el dispositivo que usa el usuario.

Lenguaje de los requisitos

Las palabras clave DEBEN NO

Uso compartido de planes de datos móviles

En términos generales, el uso compartido del plan de datos móviles consta de tres partes:

  1. Mecanismo para establecer y actualizar un identificador de plan de proveedor (CPID) que se puede usar como clave de usuario. Las aplicaciones que tienen acceso al MSISDN pueden usarlo como clave del usuario.
  2. Una API de uso compartido del plan de datos móviles de Google que permite que la DPA envíe información sobre el plan de datos de un usuario a Google Por ejemplo, si la APD desea notificar al usuario sobre una oferta, puede notificar al GTAF, que, a su vez, le notifica al usuario.
  3. Una API de agente de planes de datos implementada por la APD que permite que GTAF consulte la APD para obtener información sobre el plan de datos del usuario Por ejemplo, si una aplicación quiere mostrar el saldo del plan de datos actual al usuario, puede consultar el GTAF, que a su vez consulta el APD.

En el resto de esta página, se presenta la terminología del plan de datos y se detalla cómo establecer un CPID. A continuación, se muestran las API de Google Mobile Data Plan Sharing y Data Agent Agent Specification.

Terminología del plan de datos

El esquema de un planStatus definido en la API DEBE representar los planes de datos que ofrecen los operadores a los usuarios. La API admite la definición de planes de datos que cobran a los usuarios a una tarifa diferente por todo el tráfico hacia un conjunto particular de URL (p.ej., todo el tráfico hacia *.acmefake.com se cobra con una tarifa diferente). La API también admite planes de datos que ofrecen diferentes tarifas para ciertos tipos de acciones en una app. Estos planes de datos se denominan subapps. Un ejemplo de un plan de datos subapp sería ofrecer navegación de video gratuita (es decir, tasa cero), mientras que para mirar videos dentro de la aplicación se deducen datos del saldo de datos del suscriptor. Luego, la app de video DEBE aprender esta información cuando consulte el plan de datos.

Aquí, presentamos algunos términos relacionados con los planes de datos. En la Figura 1, se proporcionan ejemplos de planes de datos que son representativos de los conceptos que queremos capturar.

Plan de datos: el paquete de servicio móvil de nivel superior que compra un suscriptor. Puede ser tan simple como los datos móviles durante 30 días o se puede definir como una colección de componentes, también conocidos como módulos. Un plan de datos tiene las siguientes características:

  • Nombre del plan de datos, como "ACME Red".
  • Identificador del plan de datos, que se usa para referirse al plan, por ejemplo, durante las compras.
  • Hora de vencimiento, cuando vence el plan de datos.
  • Categoría del plan, ya sea que se trate de un plan prepagado o uno pospago.

Módulo de plan: un componente de un plan de datos. Específicamente, un módulo del plan tiene:

  • Module Name, como "Noches de video gratis"
  • Tasa máxima, ancho de banda que ofrece este módulo al usuario.
  • Períodos flexibles: Períodos durante los cuales se puede ofrecer un descuento al usuario.

  • Planifica la categoría de tráfico del módulo (PMTC), una descripción del tráfico de datos al que se aplica un módulo. El PMTC puede ser tan general como *todo el tráfico de Internet *o tan específico como el tráfico generado o consumido por una o más aplicaciones, sitios web o incluso los recorridos del usuario dentro de una sola aplicación. Algunos ejemplos de este último tipo son "música ilimitada", "paquete de datos de video de 100 MB" (VDP), "datos de videojuegos ilimitados" y "navegación de video ilimitada". Para facilitar la definición de PMTC, definimos las siguientes: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE1, MUSIC, GAMING, SOCIAL, MESSAGING y PMTC_UNSPECIFIED.

  • Volumen de datos o límite de tiempo: Una vez activado, el módulo del plan vence cuando el volumen de datos o el límite de tiempo (en el caso de los planes basados en el tiempo, p.ej., 600 minutos de acceso a Internet durante los próximos 7 días) En la Figura 1 a continuación, un suscriptor puede comprar un módulo de plan, como parte de "ACME Blue", que proporciona 1 GB de tráfico general de usuarios que debe usarse dentro de una semana de activación antes de su vencimiento.

Plan de muestra de la API del plan de datos

Figura 1 Planes de datos de muestra.

Cómo establecer el CPID

GTAF usa una clave de usuario para identificar a un suscriptor cuando se comunica con el APD. Las aplicaciones que tienen acceso al MSISDN del usuario pueden usarlo como user_key. Por otro lado, las aplicaciones que no tienen acceso al MSISDN, deben establecer un identificador del plan del proveedor (CPID) sin descubrir el MSISDN del usuario. A continuación, describimos el mecanismo que establece un CPID.

Flujo de llamada CPID

Figura 2: Flujo de llamada para establecer el CPID

  1. Una aplicación de Google en la UE usa una API interna de Google para recuperar la URL del extremo CPID de GTAF. El operador se identifica mediante la dirección IP pública del cliente y el MCC+MNC de la tarjeta SIM activa. En el caso de los MVNO, Google usará SPN y GID1 para determinar el MVNO.
  2. El cliente emite una solicitud HTTP GET al extremo CPID. El operador PUEDE admitir el envío de la solicitud a través de HTTPS.
  3. El operador PUEDE usar su función de inspección profunda de paquetes para identificar la solicitud y, luego, insertar el número de teléfono del usuario en la solicitud como un encabezado HTTP.
  4. El extremo CPID recibe la solicitud, construye el CPID y lo muestra al UE con un tiempo de actividad (TTL), que indica por cuánto tiempo el UE puede usar este CPID.

El operador también puede usar direcciones IP en lugar de nombres de dominio en la URL del extremo del CPID si eso es preferible. Las direcciones IP PUEDEN estar en el espacio de direcciones privadas, pero deben ser accesibles para los clientes de Google dentro de la red del operador.

El operador DEBE proporcionar la siguiente información a Google como parte del proceso de integración: 1. El CPID_URL con el que las aplicaciones se comunicarán para adquirir los CPID. Una CPID_URL es obligatoria, pero el operador puede proporcionar varias URL para aumentar la disponibilidad. 1. La lista de prefijos de IP que posee el operador y el código de país móvil (MCC) y los códigos de red móvil (MNC) que el operador desea asignar a las CPID_URL proporcionadas. Si el operador usa SPN o GID1 para distinguir los MVNO en su red, también debe proporcionar esta información. Google usará esta información para hacer coincidir a los clientes con los extremos CPID correspondientes, como se muestra en el Paso 1 de la figura 2.

El formato de la solicitud es el siguiente: GET CPID_URL Por motivos heredados, el extremo CPID debería poder admitir una solicitud como la siguiente:

GET CPID_URL?app={app_id}

El extremo CPID puede ignorar el parámetro de URL {app_id} cuando genera el CPID. Sin embargo, DEBE poder manejar una solicitud que contiene el parámetro.

La solicitud al extremo CPID PUEDE incluir el encabezado Accept-Language. Si se incluye el encabezado, las strings legibles en las actualizaciones que envía la APD mediante la API de uso compartido del plan de datos móviles DEBEN usar la configuración proporcionada en la solicitud de CPID.

Cada vez que el cliente emite una solicitud GET CPID_URL, DEBE recibir un nuevo CPID. Si la creación del CPID se realiza correctamente, el extremo CPID DEBE mostrar una respuesta 200 OK. El cuerpo de la respuesta DEBE contener una instancia de CPIDResponse.

{
    "cpid": "<CPID_string>",
    "ttlSeconds": 2592000
}

El CPID que se muestra DEBE ser válido durante ttlSeconds segundos. GTAF codificará el CPID según RFC2396 en llamadas posteriores a la APD.

Si se produce un error, el extremo CPID DEBE mostrar un error HTTP con un cuerpo de respuesta que DEBE contener una instancia de ErrorResponse. La lista de valores de causa posibles y códigos de error HTTP está disponible aquí.

{
    "errorMessage": "<error message>",
    "cause": "INVALID_NUMBER"
}

En particular, si se recibe una solicitud de CPID para un usuario que no pertenece a la red del operador (p.ej., un usuario que pertenece a otro operador, pero que roaming en la red entregada por este extremo de CPID) o que no optó por compartir información del plan de datos con Google, el extremo de CPID DEBE mostrar el código de estado HTTP 403.

Generación del CPID

La forma RECOMENDADA para que el extremo CPID cree un CPID es la siguiente:

CPID_string = Base64(AES(MSISDN + TimeStamp + language, secret))

El extremo CPID concatena el MSISDN, el idioma que envía el cliente en el encabezado Accept-Language y una marca de tiempo de alta resolución, y lo encripta a través de AES con la clave secret. La marca de tiempo DEBE corresponder a la fecha de vencimiento del CPID. El resultado encriptado está codificado en Base64. Además, cuando el CPID se usa en una URL, DEBE codificarse como URL para controlar los caracteres especiales (/+=) que se usan en Base64. En particular, cuando GTAF llama a la DPA o cuando llama a la API de Mobile Data Plan Sharing, el CPID DEBE codificarse como URL. Una ventaja de generar un CPID mediante este enfoque es que el DPA y el extremo de CPID no necesitan tener una base de datos de CPID y MSISDN válidos.

Según la situación de un operador en particular, puede que no sea trivial implementar el extremo CPID. Un desafío en particular que se ha encontrado con frecuencia es obtener acceso a MSISDN en el extremo CPID. Nos complace compartir las lecciones aprendidas sobre los operadores de integración. Comunícate con nosotros si tienes algún problema.

Requisitos de seguridad

El operador DEBE tomar todas las precauciones necesarias para proteger la información privada de sus suscriptores. Específicamente, para minimizar la exposición de los números de teléfono de los suscriptores, el extremo CPID DEBE estar dentro de tu perímetro de seguridad. Además, para los casos en los que el operador utiliza DPI, el operador DEBE encriptar el MSISDN antes de insertarlo en la solicitud HTTP. Si el extremo de CPID no es tu perímetro de seguridad (p.ej., cuando el extremo de CPID se implementa en una nube pública), el operador DEBE no transmitir el MSISDN a través de la Internet pública sin problemas. El operador puede establecer una VPN entre los DPI y el extremo CPID (consulta la Figura 1) o encriptar el MSISDN antes de insertarlo en el encabezado. El último enfoque supone que el extremo CPID puede desencriptar el encabezado inyectado para recuperar el MSISDN antes de generar el CPID. Además, el operador DEBE proteger la clave secreta que se usa para generar el CPID y rotarla según las políticas de seguridad del operador.

Requisitos de disponibilidad y capacidad

Si los clientes no pueden recuperar un CPID, no pueden acceder a la información de la API de Mobile Data Plan. Por este motivo, el operador DEBE tomar las medidas necesarias para garantizar la disponibilidad del extremo CPID. Estas medidas incluyen tener varias instancias del extremo CPID y las funciones de DPI, y tener redundancia física, de sitio y de red para ambas funciones, y garantizar que los recursos del sistema y la capacidad sean adecuados. Además, el extremo CPID y la función de DPI que inyecta el encabezado deben tener la capacidad adecuada para manejar la carga de todos los clientes de Google que solicitan CPID. El extremo CPID puede usar valores más grandes en el campo ttlSeconds para reducir la frecuencia que genera los CPID. Google recomienda usar un valor de TTL de 30 días.

Notas

  1. El VIDEO_OFFLINE PMTC significa que este plan es válido solo para el uso sin conexión (p.ej., una muy mala transmisión de QoE). Es independiente de la ventana FlexTime. ↩