Erste Schritte mit der gemeinsamen Nutzung von Tarifen für mobile Daten

Terminologie

  • GTAF: Google Traffic Application Function. Ein Google-Dienst, der die Data Plan Sharing API implementiert und im Namen von Google-Anwendungen mit DPAs interagiert. Google-Anwendungen können GTAF nach den Datenplaninformationen des Nutzers abfragen. Alternativ kann GTAF Updates zum Datentarif des Nutzers senden, wenn die Google-Anwendungen bei GTAF registriert sind.
  • MSISDN: Mobile Station International Subscriber Directory Number, eine Nummer, die ein Abo in einem Mobilfunknetzwerk eindeutig identifiziert. Wird auch als Telefonnummer bezeichnet.
  • CPID-Endpunkt: Ein von Mobilfunkanbietern implementierter Dienst, der eine CPID (Carrier Plan Identifier, Kennung des Mobilfunktarifs) generiert, mit der die Tarifinformationen des Nutzers abgerufen werden können. Mit der CPID kann eine Anwendung Details zum Datentarif eines Nutzers abfragen, ohne auf die MSISDN des Nutzers zuzugreifen. Unten wird beschrieben, wie Sie CPIDs generieren.
  • Benutzerschlüssel: Der Benutzerschlüssel ist ein String, mit dem der Datentarif eines Nutzers identifiziert werden kann. Dies kann entweder die CPID oder die MSISDN für Anwendungen sein, die Zugriff auf die MSISDN haben.
  • DPA: Data Plan Agent, ein von Mobilfunkanbietern implementierter Dienst, der Informationen zum Datentarif von Nutzern an GTAF weitergibt. Der DPA kann Informationen mit GTAF teilen, indem er Daten über die Google Mobile Data Plan Sharing API sendet und die Data Plan Agent API implementiert. Die DPA kann optional auch als CPID-Endpunkt fungieren.
  • UE: User Equipment (Nutzergerät), vom Nutzer verwendetes Gerät.

Anforderungssprache

Die Schlüsselwörter „MUSS“, „DARF NICHT“, „ERFORDERLICH“, „WIRD“, „WIRD NICHT“, „SOLLTE“, „SOLLTE NICHT“, „EMPFOHLEN“, „KANN“ und „OPTIONAL“ in diesen Anleitungen sind wie in RFC 2119 beschrieben zu interpretieren.

Tarif für mobile Daten freigeben

Auf übergeordneter Ebene umfasst die gemeinsame Nutzung von Tarifen für mobile Daten drei Teile:

  1. Mechanismus zum Einrichten und Aktualisieren einer CPID (Carrier Plan Identifier), die als Nutzer-Schlüssel verwendet werden kann. Anwendungen, die Zugriff auf die MSISDN haben, können sie als Nutzer-Schlüssel verwenden.
  2. Eine Google Mobile Data Plan Sharing API, mit der der DPA Informationen zum Datentarif eines Nutzers an Google senden kann. Wenn die DPA den Nutzer beispielsweise über ein Angebot informieren möchte, kann sie GTAF benachrichtigen, die wiederum den Nutzer benachrichtigt.
  3. Eine Data Plan Agent API, die vom DPA implementiert wird und mit der GTAF den DPA nach Informationen zum Datentarif des Nutzers fragen kann. Wenn eine Anwendung dem Nutzer beispielsweise das aktuelle Guthaben des Datentarifs anzeigen möchte, kann sie GTAF abfragen, das wiederum die DPA abfragt.

Im Rest dieser Seite werden die Begriffe für Datenpläne eingeführt und es wird beschrieben, wie Sie eine CPID erstellen. Die Google Mobile Data Plan Sharing API und die Data Plan Agent API-Spezifikation folgen als Nächstes.

Terminologie für Datentarife

Das in der API definierte Schema eines planStatus MUSS Datenpläne darstellen können, die von Mobilfunkanbietern für die Nutzer angeboten werden. Die API unterstützt die Definition von Datentarifen, bei denen Nutzern für den gesamten Traffic zu einer bestimmten Gruppe von URLs ein anderer Preis berechnet wird (z.B. wird für den gesamten Traffic zu *.acmefake.com ein anderer Preis berechnet). Die API unterstützt auch Datentarife, die unterschiedliche Preise für bestimmte Arten von Aktionen in einer App bieten. Diese nennen wir Unter-App-Datentarife. Ein Beispiel für einen Unter-App-Datentarif wäre das kostenlose (d.h. zum Nulltarif) Browsen von Videos, während beim Ansehen von Videos in der Anwendung Daten vom Datenvolumen des Abonnenten abgezogen werden. Die Video-App MUSS diese Informationen dann abrufen können, wenn sie nach Informationen zum Datentarif fragt.

Hier stellen wir einige Begriffe im Zusammenhang mit Datentarifen vor. Abbildung 1 enthält Beispiele für Datentarife, die repräsentativ für die Konzepte sind, die wir erfassen möchten.

Tarif:Das mobile Dienstpaket der obersten Ebene, das ein Abonnent erwirbt. Das kann so einfach sein wie „10 GB mobile Daten für 30 Tage“ oder als Sammlung von Komponenten (auch Module genannt) definiert werden. Ein Datenpaket hat:

  • Name des Datentarifs, z. B. „ACME Red“
  • Data Plan Identifier (Kennzeichnung des Datentarifs), die verwendet wird, um auf den Tarif zu verweisen, z. B. bei Käufen.
  • Ablaufzeit, wenn der Datentarif abläuft.
  • Tarifkategorie: Gibt an, ob es sich um einen Prepaid- oder Postpaid-Tarif handelt.

Tarifmodul:Eine Komponente eines Datentarifs. Ein Planmodul hat:

  • Modulname, z. B. „Kostenlose Videonächte“
  • Max. Rate: Bandbreite, die dem Nutzer von diesem Modul angeboten wird.
  • Flexible Zeitfenster: Zeitfenster, in denen dem Nutzer ein Rabatt angeboten werden könnte.

  • Plan Module Traffic Category (PMTC): eine Beschreibung des Datenverkehrs, auf den sich ein Modul bezieht. Der PMTC kann so allgemein wie *gesamter Internet-Traffic *oder so spezifisch wie Traffic sein, der von einer oder mehreren Anwendungen, Websites oder sogar User Journeys innerhalb einer einzelnen Anwendung generiert/verbraucht wird. Beispiele für die zweite Art sind „unbegrenzte Musik“, „100 MB Video Data Pack (VDP)“, „unbegrenzte Gaming-Daten“ und „unbegrenztes Video-Browsing“. Um die Definition von PMTCs zu erleichtern, haben wir die folgenden PMTCs definiert: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE1, MUSIC, GAMING, SOCIAL, MESSAGING und PMTC_UNSPECIFIED.

  • Datenvolumen oder Zeitlimit: Nach der Aktivierung läuft das Tarifmodul ab, wenn entweder das Datenvolumen oder das Zeitlimit erreicht ist (bei zeitbasierten Tarifen, z.B. 600 Minuten Internetzugang in den nächsten 7 Tagen) überschritten wird. In Abbildung 1 unten kann ein Abonnent im Rahmen von „ACME Blue“ ein Tarifmodul kaufen, das 1 GB allgemeinen Nutzertraffic bietet, der innerhalb einer Woche nach der Aktivierung verwendet werden muss, bevor er abläuft.

Data Plan API-Beispielabo

Abbildung 1. Beispieldatentarife.

CPID festlegen

GTAF verwendet den Nutzerschlüssel, um einen Abonnenten bei der Kommunikation mit der DPA zu identifizieren. Anwendungen, die Zugriff auf die MSISDN des Nutzers haben, können sie als „user_key“ verwenden. Andererseits müssen Anwendungen, die keinen Zugriff auf die MSISDN haben, eine Kennung für den Mobilfunktarif (Carrier Plan Identifier, CPID) erstellen, ohne die MSISDN des Nutzers zu ermitteln. Im Folgenden wird der Mechanismus beschrieben, mit dem eine CPID erstellt wird.

CPID-Anrufablauf

Abbildung 2: Anrufablauf zum Einrichten der CPID.

  1. Eine Google-Anwendung auf dem UE verwendet eine Google-interne API, um die URL des CPID-Endpunkts aus GTAF abzurufen. Der Betreiber wird anhand der öffentlichen IP-Adresse des Clients und des MCC+MNC der aktiven SIM-Karte identifiziert. Bei MVNOs verwendet Google die SPN und GID1, um den MVNO zu ermitteln.
  2. Der Client sendet eine HTTP-GET-Anfrage an den CPID-Endpunkt. Der Betreiber KANN die Anfrage über HTTPS senden.
  3. Der Betreiber KANN seine Deep Packet Inspection-Funktion verwenden, um die Anfrage zu identifizieren und die Telefonnummer des Nutzers als HTTP-Header in die Anfrage einzufügen.
  4. Der CPID-Endpunkt empfängt die Anfrage, erstellt die CPID und gibt die CPID an das UE mit einer Gültigkeitsdauer (TTL) zurück, die angibt, wie lange das UE diese CPID verwenden kann.

Der Betreiber KANN in der CPID-Endpunkt-URL auch IP-Adressen anstelle von Domainnamen verwenden, wenn dies bevorzugt wird. Die IP-Adressen KÖNNEN im privaten Adressbereich liegen, müssen aber für Google-Clients im Netzwerk des Betreibers erreichbar sein.

Der Betreiber MUSS Google im Rahmen des Onboarding-Prozesses die folgenden Informationen zur Verfügung stellen: 1. Die CPID_URL, über die Anwendungen CPIDs abrufen. Eine CPID_URL ist obligatorisch, der Betreiber kann jedoch mehrere URLs angeben, um die Verfügbarkeit zu erhöhen. 1. Die Liste der IP-Präfixe, die dem Mobilfunkanbieter gehören, sowie der Mobile Country Code (MCC) und der/die Mobile Network Code(s) (MNC), die dem Mobilfunkanbieter zugeordnet werden sollen. Wenn der Betreiber SPN oder GID1 verwendet, um MVNOs in seinem Netzwerk zu unterscheiden, MUSS er diese Informationen ebenfalls angeben. Google verwendet diese Informationen, um Clients den entsprechenden CPID-Endpunkten zuzuordnen, wie in Schritt 1 von Abbildung 2 dargestellt.

Das Format der Anfrage ist: GET CPID_URL Aus Legacy-Gründen sollte der CPID-Endpunkt eine Anfrage wie die folgende unterstützen:

GET CPID_URL?app={app_id}

Der CPID-Endpunkt kann den URL-Parameter {app_id} beim Generieren der CPID ignorieren. Die Anwendung MUSS jedoch eine Anfrage mit dem Parameter verarbeiten können.

Die Anfrage an den CPID-Endpunkt KANN den Accept-Language-Header enthalten. Wenn der Header enthalten ist, MÜSSEN in Updates, die der DPA über die Mobile Data Plan Sharing API sendet, die Einstellungen verwendet werden, die in der CPID-Anfrage angegeben sind.

Jedes Mal, wenn der Client eine GET CPID_URL-Anfrage sendet, MUSS er eine neue CPID erhalten. Wenn die CPID erfolgreich erstellt wurde, MUSS der CPID-Endpunkt eine 200 OK-Antwort zurückgeben. Der Antworttext MUSS eine Instanz von CPIDResponse enthalten.

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

Die zurückgegebene CPID MUSS für ttlSeconds Sekunden gültig sein. GTAF codiert die CPID gemäß RFC2396 in nachfolgenden Aufrufen der DPA.

Wenn ein Fehler auftritt, MUSS der CPID-Endpunkt einen HTTP-Fehler mit einem Antworttext zurückgeben, der eine Instanz von ErrorResponse enthalten MUSS. Eine Liste der möglichen cause-Werte und HTTP-Fehlercodes finden Sie hier.

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

Insbesondere wenn eine CPID-Anfrage für einen Nutzer eingeht, der nicht zum Betreibernetzwerk gehört (z.B. ein Nutzer eines anderen Betreibers, der im Netzwerk dieses CPID-Endpunkts roamt) oder der nicht zugestimmt hat, Daten zu seinem Tarif mit Google zu teilen, MUSS der CPID-Endpunkt den HTTP-Statuscode 403 zurückgeben.

CPID-Generierung

Die EMPFOHLENE Methode zum Erstellen einer CPID über den CPID-Endpunkt ist:

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

Der CPID-Endpunkt verkettet die MSISDN, die vom Client im Accept-Language-Header gesendete Sprache und einen hochauflösenden Zeitstempel und verschlüsselt sie mit AES unter Verwendung des secret-Schlüssels. Der Zeitstempel SOLLTE der Zeit entsprechen, zu der die CPID abläuft. Die verschlüsselte Ausgabe ist Base64-codiert. Wenn die CPID in einer URL verwendet wird, MUSS sie URL-codiert werden, um Sonderzeichen (/+=) zu verarbeiten, die in Base64 verwendet werden. Insbesondere wenn GTAF die DPA aufruft oder die DPA die Mobile Data Plan Sharing API aufruft, MUSS die CPID URL-codiert sein. Ein Vorteil dieser Methode ist, dass für den DPA- und den CPID-Endpunkt keine Datenbank mit gültigen CPIDs und MSISDNs erforderlich ist.

Je nach Situation eines bestimmten Betreibers kann die Implementierung des CPID-Endpunkts schwierig sein. Ein besonderes Problem, das häufig auftritt, ist der Zugriff auf die MSISDN am CPID-Endpunkt. Wir möchten Ihnen gern unsere Erfahrungen bei der Einrichtung von Betreibern mitteilen. Wenden Sie sich an uns, wenn Sie Probleme haben.

Sicherheitsanforderungen

Der Betreiber MUSS alle erforderlichen Vorkehrungen treffen, um die privaten Informationen seiner Abonnenten zu schützen. Um die Offenlegung der Telefonnummern der Abonnenten zu minimieren, SOLLTE sich der CPID-Endpunkt innerhalb Ihres Sicherheitsbereichs befinden. Außerdem SOLLTE der Betreiber in Fällen, in denen er DPI verwendet, die MSISDN verschlüsseln, bevor er sie in die HTTP-Anfrage einfügt. Wenn der CPID-Endpunkt nicht Ihr Sicherheitsperimeter ist (z.B. wenn der CPID-Endpunkt in einer öffentlichen Cloud bereitgestellt wird), SOLLTE der Betreiber die MSISDN nicht unverschlüsselt über das öffentliche Internet übertragen. Der Betreiber kann eine VPN-Verbindung zwischen dem DPI und dem CPID-Endpunkt herstellen (siehe Abbildung 1) oder die MSISDN verschlüsseln, bevor er sie in den Header einfügt. Bei diesem Ansatz wird davon ausgegangen, dass der CPID-Endpunkt den eingefügten Header entschlüsseln kann, um die MSISDN abzurufen, bevor die CPID generiert wird. Außerdem MUSS der Betreiber den geheimen Schlüssel schützen, der zum Generieren der CPID verwendet wird, und diesen Schlüssel gemäß den Sicherheitsrichtlinien des Betreibers rotieren.

Verfügbarkeit und Kapazitätsanforderungen

Wenn Clients keine CPID abrufen können, können sie nicht auf Informationen aus der Mobile Data Plan API zugreifen. Aus diesem Grund MUSS der Betreiber die erforderlichen Maßnahmen ergreifen, um die Verfügbarkeit des CPID-Endpunkts sicherzustellen. Zu diesen Maßnahmen gehören mehrere Instanzen des CPID-Endpunkts und der DPI-Funktionen sowie physische, Standort- und Netzwerkredundanz für beide Funktionen. Außerdem muss sichergestellt werden, dass Systemressourcen und ‑kapazität angemessen sind. Außerdem müssen der CPID-Endpunkt und die DPI-Funktion, die den Header einfügt, ausreichend Kapazität haben, um die Last aller Google-Clients zu bewältigen, die CPIDs anfordern. Für den CPID-Endpunkt können größere Werte im Feld „ttlSeconds“ verwendet werden, um die Häufigkeit zu verringern, mit der CPIDs generiert werden. Google empfiehlt einen TTL-Wert von 30 Tagen.

Hinweise

  1. Der PMTC VIDEO_OFFLINE bedeutet, dass dieser Plan nur für die Offline-Wiedergabe geeignet ist (z.B. bei sehr schlechter Streaming-QoE). Sie ist unabhängig vom FlexTime-Zeitraum. ↩