Premiers pas avec le partage de forfait Internet mobile

Terminologie

  • GTAF: fonction de l'application de trafic Google. Un service Google qui met en œuvre l'API Data Plan Sharing et interagit avec les APD pour le compte des applications Google. Les applications Google peuvent interroger la GTAF sur les informations du forfait Internet de l'utilisateur. Si les applications Google s'enregistrent auprès de la GTAF, celle-ci peut également envoyer des mises à jour sur le forfait Internet de l'utilisateur.
  • MSISDN : numéro de l'annuaire des abonnés à la station mobile internationale (numéro identifiant un abonnement de manière unique dans un réseau mobile). Plus communément appelé numéro de téléphone.
  • Point de terminaison CPID : service mis en œuvre par les opérateurs de réseau mobile qui génère un identifiant de forfait de l'opérateur (CPID) pouvant être utilisé pour rechercher les informations du forfait de données de l'utilisateur. CPID permet à une application d'interroger les détails du forfait de données d'un utilisateur sans accéder au fichier MSISDN. Vous trouverez ci-dessous la procédure à suivre pour générer des CPID.
  • Clé utilisateur: la clé utilisateur est une chaîne qui peut être utilisée pour identifier le forfait Internet d'un utilisateur. Il peut s'agir du CPID ou du MSISDN pour les applications qui ont accès au MSISDN.
  • DPA (Agent de forfait Internet) : service mis en œuvre par les opérateurs de réseau mobile qui partage les informations du forfait de données utilisateur avec le GTAF. L'APD peut partager des informations avec le GTAF en combinant l'envoi de données à l'aide de l'API Google Mobile Plans Sharing et l'implémentation de l'API Data Plan Agent. L'APD peut également servir de point de terminaison CPID.
  • UE : équipement de l'utilisateur

Vocabulaire de l'obligation

Les mots clés OBLIGATOIRES, NE DOIVENT PAS ÊTRE OBLIGATOIRES, NE DOIVENT ET NE DOIVENT PAS ÊTRE RÉCOMPENDÉS,

Partage de forfait mobile

De manière générale, le partage du forfait de données mobiles comprend trois parties:

  1. Mécanisme permettant d'établir et de mettre à jour un identifiant de forfait d'opérateur (CPID) pouvant être utilisé comme clé utilisateur. Les applications qui ont accès au fichier MSISDN peuvent l'utiliser comme clé utilisateur.
  2. API Google Mobile Data Plan Sharing qui permet à l'APD d'envoyer à Google des informations sur le forfait Internet de l'utilisateur. Par exemple, si le DPA souhaite informer l'utilisateur d'une offre, il peut en informer le GTAF, qui en est alors informé.
  3. API d'agent de forfait de données implémentée par le DPA, qui permet à la GTAF d'interroger le DPA pour obtenir des informations sur le forfait Internet de l'utilisateur. Par exemple, si une application souhaite présenter à l'utilisateur le solde de son forfait de données actuel, elle peut interroger le GTAF, qui interroge ensuite le DPA.

Le reste de cette page présente la terminologie du plan de données et explique comment établir un CPID. L'API de partage de forfait Google Mobile Data et les spécifications de l'API Data Plan Agent sont indiquées ci-dessous.

Terminologie du forfait Internet

Le schéma de planStatus défini dans l'API DOIT pouvoir représenter des forfaits de données proposés aux utilisateurs par les opérateurs. L'API accepte la définition de forfaits de données qui facturent les utilisateurs à un tarif différent pour tout le trafic vers un ensemble spécifique d'URL (par exemple, tout le trafic vers *.acmefake.com est facturé à un tarif différent). L'API est également compatible avec les forfaits de données qui proposent des tarifs différents pour certains types d'actions dans une application. Nous appelons ces forfaits de données sous-application. Un exemple de forfait Internet sous-application consiste à proposer un accès offert à la vidéo (c'est-à-dire, un débit de 0 €), tandis que le visionnage de vidéos dans l'application déduit les données du solde des données de l'abonné. L'application vidéo DOIT alors apprendre ces informations lors de l'interrogation d'informations sur un forfait de données.

Nous introduisons ici des termes liés aux forfaits de données. La figure 1 fournit des exemples de forfaits de données représentatifs des concepts que nous souhaitons capturer.

Forfait Internet:package de service mobile de premier niveau souscrit par un abonné. Il peut s'agir de 10 Go de données mobiles pendant 30 jours ou d'un ensemble de composants, également appelés modules. Un forfait Internet comprend:

  • Nom du forfait de données, par exemple Red ACME.
  • Identifiant de forfait Internet : utilisé pour désigner le forfait, par exemple lors des achats.
  • Date et heure d'expiration du forfait.
  • La catégorie du forfait, qu'il s'agisse d'un forfait prépayé ou d'un forfait au post-paiement

Module "Planifier" : composant d'un plan de données Plus précisément, un module "Planifier" comporte les éléments suivants:

  • Nom du module, par exemple "Free Night Nights"
  • Taux maximal : bande passante offerte à l'utilisateur par ce module.
  • Périodes de flexibilité : périodes pendant lesquelles une remise peut être proposée à l'utilisateur.

  • Plan Module Traffic Category (PMTC) : description du trafic de données auquel un module s'applique. Le PMTC peut être aussi général que *tout le trafic Internet *ou aussi spécifique que le trafic généré/consommé par une ou plusieurs applications ou sites Web, ou même les parcours utilisateur dans une seule application. Exemples de ce type de musique : pack de données vidéo illimitées (VDP, Video Data Pack de 100 Mo) et navigation vidéo illimitée. Pour faciliter la définition des PGC, nous avons défini les PGC suivants : GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE1, MUSIC, GAMING, SOCIAL, MESSAGING et PMTC_UNSPECIFIED.

  • Volume de données ou limite de temps : une fois activé, le module de forfait expire lorsque le volume de données ou la limite de temps (dans le cas de forfaits basés sur l'heure, par exemple, 600 minutes d'accès à Internet au cours des sept prochains jours) sont dépassées. Dans la figure 1 ci-dessous, un abonné peut acheter un module de forfait, dans le cadre de la solution Blue ACME, qui fournit 1 Go de trafic utilisateur général à utiliser dans la semaine suivant l'activation avant qu'il n'expire.

Exemple de forfait de l'API Data Plan

Figure 1. Exemples de forfaits de données.

Établir le CPID

Le GTAF utilise une clé utilisateur pour identifier un abonné lorsqu'il communique avec l'APD. Les applications qui ont accès au fichier MSISDN peuvent l'utiliser comme clé utilisateur. D'autre part, les applications qui n'ont pas accès au fichier MSISDN doivent établir un identifiant de forfait de l'opérateur (CPID) sans découvrir le fichier MSISDN de l'utilisateur. Dans ce qui suit, nous décrivons le mécanisme qui établit un CPID.

Flux d'appel CPID

Figure 2: Flux d'appels pour établir le CPID

  1. Une application Google dans l'UE utilise une API interne à Google pour récupérer l'URL du point de terminaison CPID à partir du GTAF. L'opérateur est identifié à l'aide de l'adresse IP publique du client et du CM+MNC de la carte SIM active. Dans le cas des MVNO, Google utilise le SPN et le GID1 pour déterminer le MVNO.
  2. Le client envoie une requête HTTP GET au point de terminaison CPID. L'opérateur PEUT accepter l'envoi de la requête via HTTPS.
  3. L’opérateur PEUT utiliser sa fonction d’inspection approfondie de paquets pour identifier la requête et injecter le numéro de téléphone de l’utilisateur dans la requête en tant qu’en-tête HTTP.
  4. Le point de terminaison CPID reçoit la requête, construit le CPID et le renvoie à l'UE avec une valeur TTL (Time To Live) indiquant la durée pendant laquelle l'UE peut l'utiliser.

L'opérateur PEUT également utiliser des adresses IP au lieu de noms de domaine dans l'URL du point de terminaison CPID, si cela est préférable. Les adresses IP PEUVENT se trouver dans l'espace d'adresses privé, mais elles doivent être accessibles aux clients Google au sein du réseau des opérateurs.

L'opérateur DOIT fournir les informations suivantes à Google dans le cadre du processus d'intégration : 1. CPID_URL que les applications contactent pour obtenir les CPID. Une URL CPID_URL est obligatoire, mais l'opérateur peut fournir plusieurs URL pour accroître la disponibilité. 1. Liste des préfixes IP appartenant à l'opérateur, et des codes pays et code des réseaux mobiles (CM) que l'opérateur souhaite mapper aux URL CPID_URL fournies. Si l'opérateur utilise SPN ou GID1 pour distinguer les MVNO de son réseau, il DOIT également fournir ces informations. Google utilisera ces informations pour mettre les clients en correspondance avec les points de terminaison CPID correspondants, comme indiqué à l'étape 1 de la figure 2.

Le format de la requête est le suivant : GET CPID_URL Pour les anciennes raisons, le point de terminaison CPID doit être compatible avec les requêtes suivantes:

GET CPID_URL?app={app_id}

Le point de terminaison CPID peut ignorer le paramètre d'URL {app_id} lors de la génération du CPID. Toutefois, il DOIT pouvoir traiter une requête contenant le paramètre.

La requête envoyée au point de terminaison CPID PEUT inclure l'en-tête Accept-Language. Si l'en-tête est inclus, les chaînes lisibles dans les mises à jour envoyées par le DPA à l'aide de l'API Mobile Data Plan Sharing doivent impérativement utiliser les paramètres fournis dans la requête CPID.

Chaque fois que le client émet une requête CPID_URL GET, il DOIT recevoir un nouveau CPID. Si la création du CPID aboutit, le point de terminaison CPID DOIT renvoyer une réponse "200 OK". Le corps de la réponse DOIT contenir une instance de CPIDResponse.

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

Le CPID renvoyé DOIT être valide pendant ttlSeconds secondes. GTAF encodera le CPID conformément à la RFC2396 lors des prochains appels à l'APD.

Si une erreur se produit, le point de terminaison CPID DOIT renvoyer une erreur HTTP avec un corps de réponse DOIT contenir une instance de ErrorResponse. La liste des valeurs cause et des codes d'erreur HTTP possibles est disponible sur cette page.

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

En particulier, si une requête CPID est reçue pour un utilisateur qui n'appartient pas au réseau de l'opérateur (par exemple, un utilisateur appartenant à un autre opérateur, mais en itinérance sur le réseau desservi par ce point de terminaison CPID), ou qui n'a pas accepté de partager les informations du forfait avec Google, le point de terminaison CPID DOIT renvoyer le code d'état HTTP 403.

Génération du CPID

Pour que le point de terminaison CPID crée un CPID, il est RECOMMANDÉ:

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

Le point de terminaison CPID concatène le MSISDN, la langue envoyée par le client dans l'en-tête Accept-Language, ainsi qu'un horodatage de haute résolution et le chiffre via AES à l'aide d'une clé secret. L'horodatage DOIT correspondre à l'expiration du CPID. La sortie chiffrée est encodée en base64. De plus, lorsque le CPID est utilisé dans une URL, il DOIT être encodé en URL pour gérer les caractères spéciaux (/+=) utilisés en base64. En particulier, lorsque la GTAF appelle le DPA ou lorsque le DPA appelle l'API Mobile Data Plan Sharing, le CPID DOIT être encodé au format URL. L'avantage de générer une adresse CPID avec cette approche est que les points de terminaison DPA et CPID n'ont pas besoin de disposer d'une base de données de CPID et de MSISDN valides.

En fonction de la situation des opérateurs, l'implémentation du point de terminaison CPID peut s'avérer complexe. L'accès au fichier MSISDN au niveau du point de terminaison CPID est un défi courant. Nous sommes ravis de partager les enseignements tirés des opérateurs d'intégration. N'hésitez pas à nous contacter si vous rencontrez des problèmes.

Exigences de sécurité

L’opérateur DOIT prendre toutes les précautions nécessaires pour protéger les informations privées de ses abonnés. Plus précisément, pour minimiser l'exposition des numéros de téléphone des abonnés, le point de terminaison CPID DOIT se trouver dans votre périmètre de sécurité. De plus, dans les cas où l'opérateur utilise la DPI, il DOIT chiffrer le fichier MSISDN avant de l'injecter dans la requête HTTP. Si le point de terminaison CPID ne constitue pas votre périmètre de sécurité (par exemple, lorsque le point de terminaison CPID est déployé sur un cloud public), l'opérateur NE DOIT PAS transmettre le MSISDN sur le réseau Internet public en clair. L'opérateur peut établir un VPN entre la DPI et le point de terminaison CPID (voir Figure 1) ou chiffrer le fichier MSISDN avant de l'injecter dans l'en-tête. La seconde approche suppose que le point de terminaison CPID peut déchiffrer l'en-tête injecté pour récupérer le MSISDN avant de générer le CPID. De plus, l'opérateur doit protéger la clé secrète utilisée pour générer le CPID, et la faire pivoter en fonction des règles de sécurité de l'opérateur.

Disponibilité et capacité requises

Si les clients ne peuvent pas récupérer de CPID, ils ne peuvent accéder à aucune information de l'API Mobile Data Plan. Pour cette raison, l'opérateur DOIT prendre les mesures nécessaires pour garantir la disponibilité du point de terminaison CPID. Ces mesures incluent la possibilité d'avoir plusieurs instances du point de terminaison CPID et des fonctions PPP, ainsi qu'une redondance physique, de site et de réseau pour les deux fonctions, et de garantir que les ressources système et la capacité sont adéquates. De plus, le point de terminaison CPID ainsi que la fonction PPP qui injecte l'en-tête doivent disposer d'une capacité suffisante pour gérer la charge de tous les clients Google demandant des CPID. Le point de terminaison CPID peut utiliser des valeurs plus élevées dans le champ ttlSeconds afin de réduire la fréquence à laquelle il génère des CPID. Google recommande d'utiliser une valeur TTL de 30 jours.

Remarques

  1. Le PMTC VIDEO_OFFLINE signifie que ce plan n'est approprié que pour le visionnage hors connexion (ex. : mauvaise qualité du streaming QoE). Il est indépendant de la fenêtre FlexTime. ↩