Primeiros passos com o compartilhamento do plano de dados móveis

Terminologia

  • GTAF: função de aplicativo de tráfego do Google. Um serviço do Google que implementa a API Data Plan Sharing e interage com DPAs em nome dos aplicativos do Google. Os aplicativos do Google podem consultar o GTAF para ver as informações do plano de dados do usuário. Como alternativa, se os aplicativos do Google se registrarem no GTAF, ele poderá enviar atualizações sobre o plano de dados do usuário.
  • MSISDN (link em inglês): número de diretório de assinante internacional da estação móvel, um número que identifica exclusivamente uma assinatura em uma rede móvel. Mais conhecido como número de telefone.
  • Endpoint do PCID: um serviço implementado por operadores de rede móvel que gera um identificador do plano da operadora (CPID, na sigla em inglês) que pode ser usado para procurar as informações do plano de dados do usuário. O CPID permite que um aplicativo consulte os detalhes do plano de dados do usuário sem acessar o MSISDN do usuário. Descrevemos o procedimento para gerar CPIDs abaixo.
  • Chave do usuário: uma chave do usuário pode ser usada para identificar um plano de dados do usuário. Pode ser o CPID ou o MSISDN para aplicativos que têm acesso ao MSISDN.
  • DPA: agente de plano de dados, um serviço implementado por operadoras de rede móvel que compartilha informações do plano de dados do usuário com o GTAF. A DPA pode compartilhar informações com o GTAF usando uma combinação de envio de dados usando a API Google Mobile Data Plan Sharing e a implementação da API Data Plan Agent. A DPA também pode atuar como o endpoint do CPID.
  • UE: equipamento do usuário, dispositivo usado pelo usuário.

Linguagem dos requisitos

As palavras-chave "quo"

Compartilhamento de plano de dados móveis

Basicamente, o compartilhamento de planos de dados móveis é composto por três partes:

  1. Mecanismo para estabelecer e atualizar um identificador de plano de operadora (CPID, na sigla em inglês) que pode ser usado como chave de usuário. Aplicativos com acesso a MSISDN, MSISDN, podem usá-lo como chave de usuário.
  2. Uma API de compartilhamento de planos de dados móveis do Google que permite que a DPA envie informações sobre o plano de dados de um usuário ao Google. Por exemplo, se a DPA quer notificar o usuário sobre uma oferta, ela pode notificar o GTAF, que, por sua vez, notifica o usuário.
  3. Uma API de agente de plano de dados implementada pela DPA. Ela permite que a GTAF consulte a DPA para ver informações sobre o plano de dados do usuário. Por exemplo, se um aplicativo quiser exibir o saldo atual do plano de dados para o usuário, ele pode consultar o GTAF, que por sua vez consulta a DPA.

Na outra parte desta página você verá a terminologia do plano de dados e os detalhes sobre como estabelecer um CPID. A API Google Mobile Data Plan Sharing e a especificação da API Data Plan Agent a seguir.

Terminologia do plano de dados

O esquema de um planStatus definido na API PRECISA representar os planos de dados oferecidos pelos operadores aos usuários. A API é compatível com a definição de planos de dados que cobram dos usuários uma taxa diferente para todo o tráfego para um conjunto específico de URLs (por exemplo, todo o tráfego para *.acmefake.com é cobrado a uma taxa diferente). A API também oferece suporte a planos de dados que oferecem taxas diferentes para determinados tipos de ações em um app. Chamamos esses planos de dados de subapps. Um exemplo de um plano de dados de sub-apps seria oferecer navegação de vídeo sem custo financeiro (ou seja, sem taxa), enquanto assistir vídeos no aplicativo deduzirá dados do saldo de dados do assinante. O app de vídeo PRECISA saber essas informações ao consultar as informações do plano de dados.

Neste curso, apresentamos alguns termos relacionados a planos de dados. A Figura 1 apresenta exemplos de planos de dados que representam os conceitos que queremos capturar.

Plano de dados: o pacote de serviço móvel de nível superior comprado por um assinante. Pode ser simples como "10 GB de dados móveis por 30 dias" ou pode ser definido como uma coleção de componentes, também conhecidos como módulos. Um plano de dados tem:

  • Nome do plano de dados, como "quot;ACME Red"
  • Identificador do plano de dados, usado para se referir ao plano, por exemplo, durante compras.
  • Prazo de validade, quando o plano de dados expira.
  • Categoria do plano: se é um plano pré-pago ou pós-pago.

Plano do plano: um componente de um plano de dados. Especificamente, um módulo de plano tem:

  • Nome do módulo, como "quot;Video Video Nights"
  • Max Rate (largura máxima), largura de banda oferecida ao usuário por este módulo.
  • Janelas de tempo flexíveis, períodos em que um desconto pode ser oferecido ao usuário.

  • Categoria do tráfego do módulo de planejamento (PMTC, na sigla em inglês), uma descrição do tráfego de dados ao qual um módulo se aplica. O PMTC pode ser tão geral quanto *todo o tráfego da Internet *ou tão específico quanto o tráfego gerado/consomedo por um ou mais aplicativos, sites ou até mesmo jornadas do usuário em um único aplicativo. Alguns exemplos desse tipo são: "quot;unlimited music ", "100 MB Video Data Pack (VDP)", "unlimited game data" & "unlimited video navigation" Para facilitar a definição de PMTCs, definimos o seguinte: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE1, MUSIC, GAMING, SOCIAL, MESSAGING e PMTC_UNSPECIFIED.

  • Volume de dados ou limite de tempo: depois de ativado, o módulo de plano expira quando o volume de dados ou o limite de tempo (no caso de planos baseados em tempo, por exemplo, 600 minutos de acesso à Internet nos próximos 7 dias) é ultrapassado. Na Figura 1 abaixo, um assinante pode comprar um módulo de plano, como parte da "ACME Blue", que fornece 1 GB de tráfego geral de usuário que precisa ser usado até uma semana após a ativação antes que expire.

Exemplo de plano da API Data Plan

Figura 1. Exemplos de planos de dados.

Estabelecer CPID

O GTAF usa a chave do usuário para identificar um assinante ao se comunicar com a DPA. Aplicativos que têm acesso ao MSISDN do usuário podem usá-lo como user_key. Por outro lado, os aplicativos que não têm acesso ao MSISDN precisam estabelecer um identificador do plano de operadora (CPID, na sigla em inglês) sem descobrir o MSISDN do usuário. Descrevemos a seguir o mecanismo que estabelece um CPID.

Fluxo de chamadas do CPID

Figura 2: fluxo de chamadas para estabelecer o CPID.

  1. Um aplicativo do Google na UE usa uma API interna do Google para recuperar o URL do endpoint do CPID do GTAF. O operador é identificado usando o endereço IP público do cliente e o MCC+MNC do chip ativo. No caso de MVNOs, o Google usará o SPN e o GID1 para determinar o MVNO.
  2. O cliente emite uma solicitação HTTP GET para o endpoint CPID. O operador pode oferecer suporte ao envio da solicitação por HTTPS.
  3. O operador pode usar a função de inspeção de pacotes profundos para identificar a solicitação e injetar o número de telefone do usuário na solicitação como um cabeçalho HTTP.
  4. O endpoint do CPID recebe a solicitação, cria o CPID e retorna o CPID à UE com um time to live (TTL) indicando por quanto tempo a UE pode usar esse CPID.

Se preferir, o operador PODE usar endereços IP em vez de nomes de domínios no URL do endpoint do CPID. Os endereços IP PODEM estar em um espaço de endereço particular, mas precisam ser acessados pelos clientes do Google dentro da rede do operador.

O operador SHALL fornecerá as seguintes informações ao Google como parte do processo de integração: 1. O CPID_URL com que os aplicativos entrarão em contato para adquirir CPIDs. Um CPID_URL é obrigatório, mas o operador pode fornecer vários URLs para aumentar a disponibilidade. 1. A lista de prefixos de IP que o operador tem e o código de país para dispositivos móveis (MCC) e códigos de rede móvel (MNC, na sigla em inglês) que o operador quer mapear para os CPID_URLs informados. Se o operador usar SPN ou GID1 para distinguir MVNOs na rede, o operador SHALL também fornecerá essas informações. O Google usará essas informações para fazer a correspondência dos clientes com os endpoints do CPID correspondentes, conforme mostrado na Etapa 1 da Figura 2.

O formato da solicitação é: GET CPID_URL Por motivos legados, o endpoint do CPID precisa ser compatível com uma solicitação como a seguinte:

GET CPID_URL?app={app_id}

O endpoint do CPID pode ignorar o parâmetro de URL {app_id} ao gerar o CPID. No entanto, PRECISAM processar uma solicitação que contenha o parâmetro.

A solicitação para o endpoint CPID PODE incluir o cabeçalho Accept-Language. Se o cabeçalho for incluído, strings legíveis por humanos nas atualizações que a DPA enviar usando a API Mobile Data Plan Sharing PRECISAM usar as configurações fornecidas na solicitação de IPID.

Cada vez que o cliente emite uma solicitação GET CPID_URL, ele PRECISA receber um novo CPID. Se a criação do CPID for bem-sucedida, o endpoint do CPID PRECISA retornar uma resposta de 200 OK. O corpo da resposta PRECISA conter uma instância de CPIDResponse.

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

O CPID retornado PRECISA ser válido por ttlSeconds segundos. O GTAF codificará o CPID de acordo com o RFC2396 nas chamadas subsequentes para a DPA.

Se ocorrer um erro, o endpoint do CPID PRECISA retornar um erro HTTP com um corpo de resposta que PRECISA conter uma instância de ErrorResponse. A lista de possíveis valores de causa e códigos de erro HTTP estão disponíveis nesta página.

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

Especificamente, se uma solicitação de CPID for recebida para um usuário que não pertence à rede do operador (por exemplo, um usuário que pertence a outro operador, mas está em roaming na rede veiculada por este endpoint do CPID) ou que não optou por compartilhar informações do plano de dados com o Google, o endpoint do CPID PRECISA retornar o código de status HTTP 403.

Geração de CPID

A forma RECOMENDADA para que o endpoint do CPID crie um CPID é:

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

O endpoint CPID concatena o MSISDN, a linguagem enviada pelo cliente no cabeçalho Accept-Language, um carimbo de data/hora de alta resolução e o criptografa pelo AES usando secret. O carimbo de data/hora DEVE corresponder ao horário em que o CPID expira. A saída criptografada é codificada em Base64. Além disso, quando o CPID é usado em um URL, ele PRECISA estar codificado para processar caracteres especiais (/+=) usados em Base64. Em especial, quando a GTAF chama a DPA ou quando a DPA chama a API Mobile Data Plan Sharing, o CPID PRECISA ser codificado para URL. Uma vantagem de gerar CPID usando essa abordagem é que os endpoints da DPA e CPID não precisam ter um banco de dados de CPIDs e MSISDNs válidos.

Dependendo da situação de determinado operador, pode ser difícil implementar o endpoint do CPID. Um desafio específico que foi encontrado com frequência é receber o MSISDN no endpoint do CPID. Temos o prazer de compartilhar as lições aprendidas com os operadores de integração. Entre em contato conosco se tiver problemas.

Requisitos de segurança

O operador SHALL tomará todas as precauções necessárias para proteger as informações particulares dos assinantes. Especificamente, para minimizar a exposição dos números de telefone dos assinantes, o endpoint do CPID DEVE estar dentro do perímetro de segurança. Além disso, para os casos em que o operador emprega DPI, o operador PRECISA criptografar o MSISDN antes de injetá-lo na solicitação HTTP. Se o endpoint do CPID não for seu perímetro de segurança (por exemplo, quando o endpoint do CPID for implantado em uma nuvem pública), o operador NÃO poderá transmitir o MSISDN pela Internet pública de maneira clara. O operador pode estabelecer uma VPN entre o DPI e o endpoint CPID (consulte a Figura 1) ou criptografar o MSISDN antes de injetá-lo no cabeçalho. A última abordagem pressupõe que o endpoint do CPID pode descriptografar o cabeçalho injetado para recuperar o MSISDN antes de gerar o CPID. Além disso, o operador deve Proteger a chave secreta usada para gerar o CPID e alternar essa chave de acordo com as políticas de segurança do operador.

Requisitos de disponibilidade e capacidade

Se os clientes não conseguirem recuperar um CPID, eles não poderão acessar nenhuma informação da API do plano de dados para dispositivos móveis. Por esse motivo, o operador SHALL tomará as medidas necessárias para garantir a disponibilidade do endpoint do CPID. Essas medidas incluem ter várias instâncias do endpoint CPID e funções DPI e ter redundância física, de site e de rede para ambas as funções e garantir que os recursos e a capacidade do sistema sejam adequados. Além disso, o endpoint do CPID e a função DPI que injeta o cabeçalho precisam ter capacidade adequada para processar a carga de todos os clientes do Google que solicitam CPIDs. O endpoint do CPID pode usar valores maiores no campo ttlSeconds para reduzir a frequência com que gera CPIDs. O Google recomenda o uso de um valor de TTL de 30 dias.

Observações

  1. O PMTC VIDEO_OFFLINE significa que esse plano é bom apenas para uso off-line (por exemplo, QoE de streaming muito ruim). Ele é independente da janela FlexTime. ↩