Primeros pasos con el uso compartido del plan de datos móviles

Terminología

• GTAF: Es la función de la aplicación de tráfico de Google. Es un servicio de Google que implementa la API de Data Plan Sharing y que interactúa con los DPA en nombre de las aplicaciones de Google. Las aplicaciones de Google pueden consultar GTAF para obtener información sobre el plan de datos del usuario. Como alternativa, si las aplicaciones de Google se registran en GTAF, este puede enviar actualizaciones sobre el plan de datos del usuario.
• MSISDN: Es el número de directorio internacional de suscriptor de estación móvil, un número que identifica de forma única una suscripción en una red móvil. Se conoce más comúnmente como número de teléfono.
• Extremo de CPID: Es un servicio implementado por los operadores de redes móviles que genera un identificador de plan del operador (CPID) que se puede usar para buscar la información del plan de datos del usuario. El CPID permite que una aplicación consulte los detalles del plan de datos de un usuario sin acceder a su MSISDN. A continuación, describimos el procedimiento para generar CPIDs.
• Clave del usuario: La clave del usuario es una cadena 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 los operadores de redes móviles que comparte información sobre el plan de datos del usuario con GTAF. El DPA puede compartir información con GTAF enviando datos a través de la API de Google Mobile Data Plan Sharing y, además, implementando la API de Data Plan Agent. De manera opcional, el DPA también puede actuar como el extremo del CPID.
• UE: Equipo del usuario, dispositivo que usa el usuario.

Lenguaje de los requisitos

Las palabras clave “DEBE”, “NO DEBE”, “OBLIGATORIO”, “DEBERÁ”, “NO DEBERÁ”, “DEBERÍA”, “NO DEBERÍA”, “RECOMENDADO”, “PUEDE” y “OPCIONAL” en estas guías se deben interpretar como se describe en RFC 2119.

Uso compartido de planes de datos móviles

En un nivel general, el uso compartido del plan de datos móviles consta de tres partes:

1. Mecanismo para establecer y actualizar un identificador de plan de operador (CPID) que se puede usar como clave de usuario. Las aplicaciones que tienen acceso al MSISDN pueden usarlo como clave de usuario.
2. Una API de Google Mobile Data Plan Sharing que permite que el DPA envíe información sobre el plan de datos de un usuario a Google. Por ejemplo, si el DPA quiere notificarle al usuario una oferta, puede notificar al GTAF, que, a su vez, le notificará al usuario.
3. Es una API de Data Plan Agent implementada por el DPA que permite que GTAF consulte al DPA para obtener información sobre el plan de datos del usuario. Por ejemplo, si una aplicación quiere mostrarle al usuario el saldo actual del plan de datos, puede consultar GTAF, que, a su vez, consulta la DPA.

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 incluyen la API de Google Mobile Data Plan Sharing y la especificación de la API de Data Plan Agent.

Terminología del plan de datos

El esquema de un planStatus definido en la API DEBE poder representar los planes de datos que los operadores ofrecen 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 a un conjunto particular de URLs (p.ej., todo el tráfico a *.acmefake.com se cobra a una tarifa diferente). La API también admite planes de datos que ofrecen diferentes tarifas para ciertos tipos de acciones en una app. A estos planes de datos los llamamos planes de datos de subaplicación. Un ejemplo de un plan de datos de subaplicación sería ofrecer navegación de video gratuita (es decir, con tarifa cero), mientras que mirar videos dentro de la aplicación deduce datos del saldo de datos del suscriptor. Luego, la app de video DEBE poder obtener esta información cuando consulte los datos del plan.

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: Es el paquete de servicios móviles de nivel superior que compra un suscriptor. Puede ser tan simple como "10 GB de datos móviles por 30 días" o definirse como una colección de componentes, también conocidos como módulos. Un plan de datos tiene los siguientes elementos:

• Nombre del plan de datos, como "ACME Red".
• Identificador del plan de datos, que se usa para hacer referencia al plan, por ejemplo, durante las compras.
• Hora de vencimiento, cuando vence el plan de datos
• Categoría del plan, que indica si el plan es prepagado o pospagado

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

• Nombre del módulo, como "Noches de video gratis".
• Max Rate: Es el ancho de banda que ofrece este módulo al usuario.
• Períodos flexibles: Son los períodos durante los cuales se le podría ofrecer un descuento al usuario.

• Plan Module Traffic Category (PMTC), una descripción del tráfico de datos que 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 recorridos del usuario dentro de una sola aplicación. Algunos ejemplos de este último tipo son “música ilimitada”, “paquete de datos de video (VDP) de 100 MB”, “datos ilimitados para juegos” y “navegación de videos ilimitada”. Para facilitar la definición de los PMTC, definimos los siguientes: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE¹, MUSIC, GAMING, SOCIAL, MESSAGING y PMTC_UNSPECIFIED.

• Límite de tiempo o volumen de datos: Una vez activado, el módulo del plan vence cuando se alcanza el límite de tiempo o de volumen de datos (en el caso de los planes basados en el tiempo, p.ej., Se superan los 600 minutos de acceso a Internet durante los próximos 7 días. En la siguiente figura 1, un suscriptor puede comprar un módulo de plan, como parte de "ACME Blue", que proporciona 1 GB de tráfico general del usuario que se debe usar dentro de la semana posterior a la activación antes de que venza.

Figura 1: Planes de datos de muestra.

Cómo establecer el CPID

La GTAF usa la clave del usuario para identificar a un suscriptor cuando se comunica con el DPA. 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 de plan de operador (CPID) sin descubrir el MSISDN del usuario. A continuación, describimos el mecanismo que establece un CPID.

Flujo de llamadas de CPID

Figura 2: Flujo de llamadas 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 de CPID de GTAF. El operador se identifica con 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á el SPN y el GID1 para determinar el MVNO.
2. El cliente emite una solicitud HTTP GET al extremo del CPID. El operador PUEDE admitir el envío de la solicitud a través de HTTPS.
3. El operador PUEDE emplear 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 de CPID recibe la solicitud, construye el CPID y lo devuelve al UE con un tiempo de actividad (TTL) que indica durante 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 lo prefiere. Las direcciones IP PUEDEN estar en un espacio de direcciones privadas, pero los clientes de Google deben poder acceder a ellas dentro de la red del operador.

El operador DEBE proporcionar la siguiente información a Google como parte del proceso de incorporación: 1. Es la CPID_URL a la que se conectarán las aplicaciones para adquirir CPIDs. Se requiere una CPID_URL, pero el operador puede proporcionar varias URLs para aumentar la disponibilidad. 1. Es la lista de prefijos de IP que posee el operador y los códigos de país móvil (MCC) y de red móvil (MNC) que el operador desea que se asignen a los CPID_URLs proporcionados. Si el operador usa el SPN o el GID1 para distinguir a los MVNO en su red, también DEBE proporcionar esta información. Google usará esta información para correlacionar los clientes con los extremos de 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 del CPID debe poder admitir una solicitud como la siguiente:

GET CPID_URL?app={app_id}

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

La solicitud al extremo de CPID PUEDE incluir el encabezado Accept-Language. Si se incluye el encabezado, las cadenas legibles para humanos en las actualizaciones que el DPA envía con la API de Mobile Data Plan Sharing 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 CPID nuevo. Si la creación del CPID se realiza correctamente, el endpoint del CPID DEBE devolver una respuesta 200 OK. El cuerpo de la respuesta DEBE contener una instancia de CPIDResponse.

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

El CPID que se devuelve DEBE ser válido durante ttlSeconds segundos. GTAF codificará el CPID por RFC2396 en las llamadas posteriores al DPA.

Si se produce un error, el extremo del CPID DEBE devolver un error HTTP con un cuerpo de respuesta que DEBE contener una instancia de ErrorResponse. La lista de posibles valores de cause 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 está en roaming en la red que proporciona este extremo de CPID) o que no habilitó el uso compartido de la información del plan de datos con Google, el extremo de CPID DEBE devolver el código de estado HTTP 403.

Generación de CPID

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

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

El extremo de 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 se codifica 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 al DPA o cuando el DPA llama a la API de Mobile Data Plan Sharing, el CPID DEBE estar codificado como URL. Una ventaja de generar el CPID con este enfoque es que el extremo del DPA y el 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 ser no trivial implementar el endpoint de CPID. Un desafío particular que se ha encontrado con frecuencia es obtener acceso al MSISDN en el extremo del CPID. Nos complace compartir las lecciones aprendidas durante la incorporación de operadores. 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 del CPID DEBE estar dentro de tu perímetro de seguridad. Además, en los casos en que el operador emplea DPI, DEBE encriptar el MSISDN antes de inyectarlo en la solicitud HTTP. Si el extremo del CPID no es tu perímetro de seguridad (p.ej., cuando el extremo del CPID se implementa en una nube pública), el operador NO DEBE transmitir el MSISDN a través de Internet pública sin encriptar. El operador puede establecer una VPN entre el DPI y el extremo del CPID (consulta la Figura 1) o encriptar el MSISDN antes de insertarlo en el encabezado. Este último enfoque supone que el extremo del CPID puede descifrar el encabezado insertado 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 rotar esta clave según las políticas de seguridad del operador.

Requisitos de disponibilidad y capacidad

Si los clientes no pueden recuperar un CPID, no podrán acceder a ninguna 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 del CPID. Estas medidas incluyen tener varias instancias de las funciones de CPID y DPI, y tener redundancia física, de sitio y de red para ambas funciones, además de garantizar que los recursos y la capacidad del sistema sean adecuados. Además, el extremo de CPID y la función de DPI que inserta el encabezado deben tener la capacidad adecuada para controlar la carga de todos los clientes de Google que solicitan CPID. El extremo de CPID puede usar valores más grandes en el campo ttlSeconds para reducir la frecuencia con la que genera CPIDs. Google recomienda usar un valor de TTL de 30 días.

Notas

---

1. El PMTC VIDEO_OFFLINE significa que este plan es adecuado solo para el uso sin conexión (p.ej., una calidad de experiencia de transmisión muy mala). Es independiente del período de FlexTime. ↩