Premiers pas avec le partage de forfait de données mobiles

Terminologie

  • GTAF : Google Traffic Application Function (fonction d'application de trafic Google). Service Google qui implémente l'API Data Plan Sharing et interagit avec les DPA au nom des applications Google. Les applications Google peuvent interroger GTAF pour obtenir des informations sur le forfait de données de l'utilisateur. Si les applications Google s'enregistrent auprès de GTAF, GTAF peut envoyer des informations sur le forfait de données de l'utilisateur.
  • MSISDN : Mobile Station International Subscriber Directory Number, un numéro permettant d'identifier de manière unique un abonnement dans un réseau mobile. (plus couramment connu sous le nom de numéro de téléphone)
  • Point de terminaison CPID : service implémenté par les opérateurs de réseau mobile qui génère un identifiant de forfait de l'opérateur (CPID, carrier plan identifier) pouvant être utilisé pour rechercher les informations sur le forfait de données de l'utilisateur. Le CPID permet à une application d'interroger les détails du forfait de données d'un utilisateur sans accéder à son MSISDN. Nous décrivons ci-dessous la procédure de génération des CPID.
  • Clé utilisateur : la clé utilisateur est une chaîne qui peut être utilisée pour identifier le forfait de données d'un utilisateur. Il peut s'agir du CPID ou du MSISDN pour les applications ayant accès au MSISDN.
  • DPA (Data Plan Agent) : service mis en œuvre par les opérateurs de réseau mobile qui partage les informations sur le forfait de données des utilisateurs avec GTAF. Le FPD peut partager des informations avec GTAF en envoyant des données à l'aide de l'API Google Mobile Data Plan Sharing et en implémentant l'API Data Plan Agent. Le DPA peut également servir de point de terminaison CPID (facultatif).
  • UE : équipement utilisateur, appareil utilisé par l'utilisateur.

Vocabulaire de l'obligation

Les mots clés "DOIT", "NE DOIT PAS", "REQUIS", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "FACULTATIF" dans ces guides doivent être interprétés selon leur description dans la RFC 2119.

Partage de forfait de données mobiles

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

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

Le reste de cette page présente la terminologie des forfaits de données et explique comment établir un CPID. Vous trouverez ci-dessous l'API Google Mobile Data Plan Sharing et la spécification de l'API Data Plan Agent.

Terminologie des forfaits Internet

Le schéma d'un planStatus défini dans l'API DOIT pouvoir représenter les forfaits de données proposés par les opérateurs aux utilisateurs. L'API permet de définir des forfaits de données qui facturent les utilisateurs à un tarif différent pour l'ensemble du trafic vers un ensemble particulier 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 de données sous-application serait de proposer la navigation vidéo sans frais (c'est-à-dire sans frais), tandis que le visionnage de vidéos dans l'application déduit des données du solde de données de l'abonné. L'application vidéo DOIT ensuite être en mesure d'apprendre ces informations lors de la requête d'informations sur le forfait de données.

Nous allons maintenant présenter certains 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 de données : forfait de services mobiles de premier niveau qu'un abonné achète. Il peut s'agir d'un simple forfait de "10 Go de données mobiles pendant 30 jours" ou d'un ensemble de composants, également appelés modules. Un forfait de données comprend :

  • Nom du forfait de données, par exemple "ACME Red".
  • Identifiant du forfait de données, utilisé pour faire référence au forfait, par exemple lors d'achats.
  • Heure d'expiration : heure d'expiration du forfait de données.
  • Catégorie du forfait : indique si le forfait est prépayé ou post-payé.

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

  • Nom du module, par exemple "Soirées vidéo sans frais".
  • Débit max : bande passante proposée à l'utilisateur par ce module.
  • Plages horaires flexibles : plages horaires pendant lesquelles une remise peut être proposée à l'utilisateur.

  • Catégorie de trafic du module de planification (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, sites Web ou même parcours utilisateur au sein d'une même application. Par exemple, "musique illimitée", "forfait de données vidéo de 100 Mo", "données de jeu illimitées" et "navigation vidéo illimitée". Pour faciliter la définition des PMTC, nous avons défini les PMTC suivants : GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE1, MUSIC, GAMING, SOCIAL, MESSAGING et PMTC_UNSPECIFIED..

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

Exemple de forfait de l'API Data Plan

Figure 1. Exemples de forfaits de données.

Établir un CPID

GTAF utilise une clé utilisateur pour identifier un abonné lorsqu'il communique avec le DPA. Les applications qui ont accès au MSISDN de l'utilisateur peuvent l'utiliser comme user_key. En revanche, les applications qui n'ont pas accès au MSISDN doivent établir un identifiant de forfait mobile (CPID) sans découvrir le MSISDN de l'utilisateur. Nous décrivons ci-dessous le mécanisme qui établit un CPID.

Processus d'appel CPID

Figure 2 : Flux d'appel pour établir le CPID.

  1. Dans l'UE, une application Google utilise une API interne à Google pour récupérer l'URL du point de terminaison CPID à partir de GTAF. L'opérateur est identifié à l'aide de l'adresse IP publique du client et du code MCC+MNC de la carte SIM active. Dans le cas des MVNO, Google utilisera le SPN et le GID1 pour déterminer le MVNO.
  2. Le client émet 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 des 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 durée de vie (TTL) indiquant la durée pendant laquelle l'UE peut utiliser ce CPID.

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 un espace d'adressage privé, mais elles doivent être accessibles par les clients Google au sein du réseau de l'opérateur.

L'opérateur DOIT fournir les informations suivantes à Google lors du processus d'intégration : 1. URL CPID que les applications contacteront pour obtenir des CPID. Une URL CPID est obligatoire, mais l'opérateur peut en fournir plusieurs pour augmenter la disponibilité. 1. Liste des préfixes IP appartenant à l'opérateur, ainsi que le code pays mobile (MCC) et le ou les codes réseau mobile (MNC) que l'opérateur souhaite mapper aux CPID_URL fournis. Si l'opérateur utilise le SPN ou le GID1 pour distinguer les MVNO sur son réseau, il DOIT également fournir ces informations. Google utilisera ces informations pour faire correspondre les clients aux 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 des raisons d'héritage, le point de terminaison CPID doit pouvoir accepter une requête comme celle-ci :

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 être en mesure de 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 par l'homme dans les mises à jour que le DPA envoie à l'aide de l'API Mobile Data Plan Sharing DOIVENT utiliser les paramètres fournis dans la requête CPID.

Chaque fois que le client émet une requête GET CPID_URL, il DOIT recevoir un nouveau CPID. Si la création du CPID réussit, 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. Le GTAF encodera le CPID par RFC2396 lors des appels ultérieurs au DPA.

En cas d'erreur, le point de terminaison CPID DOIT renvoyer une erreur HTTP avec un corps de réponse qui DOIT contenir une instance de ErrorResponse. La liste des valeurs cause possibles et des codes d'erreur HTTP est disponible ici.

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

En particulier, si une demande de 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 choisi de partager les informations sur son forfait de données avec Google, le point de terminaison CPID DOIT renvoyer le code d'état HTTP 403.

Génération de CPID

La méthode RECOMMANDÉE pour que le point de terminaison CPID crée un CPID est la suivante :

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 et un code temporel haute résolution, puis le chiffre à l'aide d'AES avec la clé secret. L'horodatage DOIT correspondre à l'heure d'expiration du CPID. Le résultat chiffré est encodé en base64. De plus, lorsque le CPID est utilisé dans une URL, il DOIT être encodé au format URL pour gérer les caractères spéciaux (/+=) utilisés dans Base64. En particulier lorsque GTAF appelle la DPA ou lorsque la DPA appelle l'API de partage de forfait de données mobiles, le CPID DOIT être encodé au format URL. L'un des avantages de la génération de CPID à l'aide de cette approche est que le point de terminaison DPA et CPID n'a pas besoin d'avoir une base de données de CPID et de MSISDN valides.

Selon la situation d'un opérateur donné, l'implémentation du point de terminaison CPID peut être complexe. L'un des problèmes les plus fréquemment rencontrés est l'accès au MSISDN au niveau du point de terminaison CPID. Nous sommes heureux de partager les enseignements tirés de l'intégration des opérateurs. N'hésitez pas à nous contacter si vous rencontrez des difficultés.

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 l'inspection approfondie des paquets, il DOIT chiffrer le MSISDN avant de l'injecter dans la requête HTTP. Si le point de terminaison CPID ne fait pas partie de 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 en clair sur l'Internet public. L'opérateur peut établir un VPN entre le DPI et le point de terminaison CPID (voir la figure 1) ou chiffrer le MSISDN avant de l'injecter dans l'en-tête. Cette dernière 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 faire tourner cette clé conformément aux règles de sécurité de l'opérateur.

Disponibilité et exigences de capacité

Si les clients ne peuvent pas récupérer de CPID, ils ne peuvent accéder à aucune information de l'API Mobile Data Plan. C'est pourquoi l'opérateur DOIT prendre les mesures nécessaires pour assurer la disponibilité du point de terminaison CPID. Ces mesures incluent la présence de plusieurs instances du point de terminaison CPID et des fonctions DPI, ainsi que la redondance physique, du site et du réseau pour les deux fonctions. Elles garantissent également que les ressources et la capacité du système sont adéquates. De plus, le point de terminaison CPID ainsi que la fonction DPI qui injecte l'en-tête doivent avoir une capacité suffisante pour gérer la charge de tous les clients Google qui demandent des CPID. Le point de terminaison CPID peut utiliser des valeurs plus élevées dans le champ "ttlSeconds" pour 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 code PMTC VIDEO_OFFLINE signifie que ce forfait n'est valable qu'hors connexion (par exemple, une très mauvaise qualité de streaming). Elle est indépendante de la fenêtre FlexTime. ↩