Erste Schritte mit dem Datentarif für mobile Daten

Terminologie

  • GTAF: Google Traffic Application Functions Ein Google-Dienst, der die Data Plan Sharing API implementiert und im Auftrag von Google mit Datenschutzaufsichtsbehörden interagiert. Google-Anwendungen können über GTAF die Datentarife der Nutzer abfragen. Wenn sich die Google-Anwendungen bei GTAF registrieren, kann GTAF alternativ Updates zum Datentarif des Nutzers senden.
  • MSISDN: Mobile Station International Abonnentverzeichnisnummer, eine Nummer, die ein Abo in einem Mobilfunknetz eindeutig identifiziert. Dies wird allgemein als Telefonnummer bezeichnet.
  • CPID-Endpunkt: Ein vom Mobilfunkanbieter implementierter Dienst, der eine CPID-ID generiert, die zum Abrufen der Datentarifinformationen des Nutzers verwendet werden kann. Mithilfe der CPID kann eine Anwendung Details zum Datentarif eines Nutzers abfragen, ohne auf die MSISDN des Nutzers zuzugreifen. Im Folgenden wird das Verfahren zum Generieren von CPIDs beschrieben.
  • Nutzerschlüssel: Nutzerschlüssel ist ein String, mit dem der Datentarif eines Nutzers identifiziert werden kann. Dies kann entweder die CPID oder MSISDN für Anwendungen sein, die Zugriff auf die MSISDN haben.
  • DPA: Data Plan Agent, ein von Mobilfunkanbietern implementierter Dienst, der Nutzerdaten mit GTAF teilt Die DPA kann Informationen mit GTAF teilen, indem sie eine Kombination aus dem Senden von Daten mithilfe der Google Mobile Data Plan Sharing API und der Implementierung der Data Plan Agent API verwendet. Der DPA kann auch als CPID-Endpunkt fungieren.
  • UE: Nutzergerät, vom Nutzer verwendetes Gerät.

Konventionen für die Formulierung von Anforderungen

Die Keywords MUSS & quot; , & quot; Darf NICHT quot; , "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", quot;UID, quot; und quot;1

Freigabe des mobilen Datentarifs

Grundsätzlich besteht der mobile Datentarif aus drei Teilen:

  1. Mechanismus zum Erstellen und Aktualisieren einer CPID (Carrier Plan Identifier), die als Nutzerschlüssel verwendet werden kann. Anwendungen, die Zugriff auf MSISDN haben, können von MSISDN als Nutzerschlüssel verwendet werden.
  2. Eine Google Mobile Data Plan Sharing API, mit der die DPA Informationen zu einem Datentarif eines Nutzers an Google senden kann. Wenn die Datenschutzaufsichtsbehörde beispielsweise den Nutzer über ein Angebot informieren möchte, kann er die GTAF darüber informieren, die den Nutzer wiederum benachrichtigt.
  3. Eine Datenplan-Agent-API, die von der Datenschutzaufsichtsbehörde implementiert wurde, damit GTAF die Datenabfrage für den Datentarif des Nutzers abfragen kann. Wenn eine Anwendung beispielsweise dem Nutzer das aktuelle Datentarif anzeigen möchte, kann er GTAF abfragen, das wiederum den DPA abfragt.

Im Folgenden werden die Terminologie für den Datenplan und eine CPID erläutert. Als Nächstes folgen die Google Mobile Data Plan Sharing API und die Data Plan Agent API-Spezifikation.

Datenterminologie

Das Schema eines in der API definierten planStatus MUSS Datentarife darstellen, die den Nutzern von Operatoren angeboten werden. Die API unterstützt das Definieren von Datentarifen, bei denen Nutzern für einen bestimmten Satz von URLs eine andere Gebühr für den gesamten Traffic in Rechnung gestellt wird (z.B. wird der gesamte Traffic an *.acmefake.com zu einem anderen Preis berechnet). Die API unterstützt auch Datentarife, die für bestimmte Arten von Aktionen in einer App unterschiedliche Preise anbieten. Diese werden als Sub-App-Datentarife bezeichnet. Ein Sub-App-Datentarif besteht z. B. darin, sich kostenlos Videodownloads anzusehen (z. B. mit einem Tarif von null), während Videos in der Anwendung Videos vom Daten-Abo des Abonnenten abziehen. Die Video-App MUSS dann diese Informationen bei der Abfrage von Informationen zum Datentarif lernen können.

Hier werden einige Begriffe für Datentarife eingeführt. Abbildung 1 enthält Beispiele für Datenpläne, die die zu erfassenden Konzepte darstellen.

Datentarif:Das Paket für den Mobilfunkdienst auf oberster Ebene, den ein Abonnent kauft. Die Daten können ganz einfach oder mobile Daten von bis zu 30 Tagen 10 GB umfassen oder als Sammlung von Komponenten oder Modulen definiert sein. Ein Datentarif hat:

  • Name des Datentarifs, z. B. &ACT;ACME Rot"
  • Datentarif-ID, die zum Verweis auf den Plan verwendet wird, z. B. während eines Kaufs.
  • Die Ablaufzeit, wenn der Datentarif abläuft.
  • Tarifkategorie: Gibt an, ob es sich um einen Prepaid- oder einen Postpaid-Tarif handelt.

Planmodul:Komponente eines Datentarifs. Ein Planmodul hat Folgendes:

  • Modulname, z. B. „Kostenlose Videoübernachtungen“.
  • Maximale Rate: die Bandbreite, die dem Nutzer von diesem Modul angeboten wird.
  • Flex Zeitfenster: Zeitfenster, in denen dem Nutzer ein Rabatt angeboten werden kann.

  • Traffic-Kategorie des Moduls (PMTC): Eine Beschreibung des Daten-Traffics, für den ein Modul gilt. Das PMTC kann so allgemein sein wie *alle Internetzugriffe *oder so spezifisch wie der von einer oder mehreren Anwendungen, Websites oder sogar Nutzerpfaden innerhalb einer einzelnen Anwendung generierte oder sogar konsumierte Traffic. Beispiele sind „Video Music Pack (VDP)“, „Unlimited Gaming Data“ und „Unlimited Video Browsing“. Zur Definition von PMTCs 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 Planmodul ab, wenn entweder das Datenvolumen oder das Zeitlimit abläuft (bei zeitbasierten Plänen, z.B. 600 Minuten Internetzugriff in den nächsten 7 Tagen) überschritten wird. In Abbildung 1 unten kann ein Abonnent im Rahmen von „ACME Blue“ ein Tarifmodul erwerben, das 1 GB allgemeinen Nutzerzugriff umfasst, der innerhalb einer Woche nach der Aktivierung verwendet werden muss, bevor er abläuft.

Data Plan API-Beispielplan

Abbildung 1. Beispiel für Datentarife

CPID wird eingerichtet

GTAF verwendet einen Nutzerschlüssel, um bei der Kommunikation mit dem Datenschutzaufsichtsbehörde einen Abonnenten zu identifizieren. Anwendungen, die Zugriff auf die MSISDN des Nutzers haben, können ihn als user_key verwenden. Anwendungen, die keinen Zugriff auf MSISDN haben, müssen hingegen eine CPID (Carrier Plan Identifier) einrichten, ohne die MSISDN des Nutzers zu ermitteln. Im Folgenden wird der Mechanismus beschrieben, der eine CPID einrichtet.

CPID-Anrufablauf

Abbildung 2: Aufrufablauf zum Einrichten der CPID

  1. Eine Google-Anwendung in der UE verwendet eine Google-interne API, um die URL des CPID-Endpunkts von GTAF abzurufen. Der Mobilfunkanbieter wird anhand der öffentlichen IP-Adresse des Clients und des Kundencenters (MNC) der aktiven SIM-Karte ermittelt. Bei MVNOs verwendet Google den SPN und GID1, um den MVNO zu bestimmen.
  2. Der Client gibt eine HTTP GET-Anfrage an den CPID-Endpunkt aus. Der Operator unterstützt unter Umständen das Senden der Anfrage über HTTPS.
  3. Der Operator MAY kann seine Deep Packet Inspection-Funktion verwenden, um die Anfrage zu identifizieren und die Telefonnummer des Nutzers als HTTP-Header in die Anfrage einzuschleusen.
  4. Der CPID-Endpunkt empfängt die Anfrage, konstruiert die CPID und gibt die CPID an die UE mit einer Gültigkeitsdauer (TTL) zurück, die angibt, wie lange die UE diese CPID verwenden kann.

Der Operator Darf in der CPID-Endpunkt-URL auch IP-Adressen anstelle von Domainnamen verwenden, wenn dies vorzuziehen ist. Die IP-Adressen können sich im privaten Adressbereich befinden, müssen aber für Google-Clients innerhalb des Netzwerks des Anbieters erreichbar sein.

Der Operator stellt Google im Rahmen des Onboarding-Prozesses die folgenden Informationen zur Verfügung: 1. Die CPID_URL, die von Anwendungen kontaktiert wird, um CPIDs zu erhalten. Eine CPID_URL ist obligatorisch, aber der Betreiber kann mehrere URLs angeben, um die Verfügbarkeit zu erhöhen. 1. Die Liste der IP-Präfixe, die dem Betreiber gehören, sowie der Mobile Country Code (Kundencenter) und Mobile Network Code(s) (MNC), die der Betreiber den angegebenen CPID_URLs zuordnen möchte. Wenn der Operator SPN oder GID1 verwendet, um MVNOs in seinem Netzwerk zu unterscheiden, sollte er diese Informationen ebenfalls bereitstellen. Google verwendet diese Informationen, um Clients den entsprechenden CPID-Endpunkten zuzuordnen, wie in Schritt 1 von Abbildung 2 gezeigt.

Das Format der Anfrage ist: GET CPID_URL Aus Legacy-Gründen sollte der CPID-Endpunkt eine Anfrage wie diese unterstützen können:

GET CPID_URL?app={app_id}

Der CPID-Endpunkt kann den URL-Parameter {app_id} ignorieren, wenn die CPID generiert wird. Es MUSS aber in der Lage sein, eine Anfrage mit diesem Parameter zu verarbeiten.

Die Anfrage an den CPID-Endpunkt darf den Header Accept-Language enthalten. Wenn der Header enthalten ist, MÜSSEN die für die DPA über die Mobile Data Plan Sharing API gesendeten menschenlesbaren Strings die in der CPID-Anfrage angegebenen Einstellungen verwenden.

Jedes Mal, wenn der Client eine GET CPID_URL-Anfrage ausstellt, MUSS er eine neue CPID erhalten. Wenn die CPID 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 ttlSeconds Sekunden lang gültig sein. GTAF codiert die CPID nach 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 möglicher Ursachenwerte und HTTP-Fehlercodes finden Sie hier.

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

Wenn eine CPID-Anfrage für einen Nutzer empfangen wird, der nicht zum Operatornetzwerk gehört (z.B. zu einem anderen Operator, aber zu einem Roaming in einem von diesem CPID-Endpunkt bereitgestellten Netzwerk), oder der sich dafür entschieden hat, Informationen zu Datentarifen für Google freizugeben, muss der CPID-Endpunkt den HTTP-Statuscode 403 zurückgeben.

CPID-Generierung

Für den CPID-Endpunkt wird die Verwendung einer empfohlenen CPID empfohlen:

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

Der CPID-Endpunkt verkettet MSISDN, die vom Client im Header"Accept-Language"gesendete Sprache, und einen hochauflösenden Zeitstempel und verschlüsselt ihn über AES mit dem Schlüssel secret. Der Zeitstempel MUSS 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 außerdem URL-codiert werden, um Sonderzeichen (/+=) zu verarbeiten, die in Base64 verwendet werden. Insbesondere wenn GTAF die DPA aufruft oder die Mobile Data Plan Sharing API aufruft, muss die CPID URL-codiert sein. Die CPID generiert so den Vorteil, dass der DPA und der CPID-Endpunkt keine Datenbank mit gültigen CPIDs und MSISDNs haben müssen.

Abhängig von der Situation eines bestimmten Betreibers kann es schwierig sein, den CPID-Endpunkt zu implementieren. Eine besondere Herausforderung, die uns häufig aufgezeigt wird, ist der Zugriff auf MSISDN am CPID-Endpunkt. Gerne teilen wir die gewonnenen Erkenntnisse mit den Operatoren für das Onboarding. Bitte wenden Sie sich an uns, falls Probleme auftreten.

Sicherheitsanforderungen

Der Operator ergreift alle erforderlichen Vorkehrungen, um die privaten Informationen seiner Abonnenten zu schützen. Insbesondere sollte sich der CPID-Endpunkt innerhalb Ihres Sicherheitsbereichs befinden, um die Offenlegung der Telefonnummern des Abonnenten zu minimieren. Wenn der Operator DPI verwendet, muss der Operator außerdem die MSISDN verschlüsseln, bevor er sie in die HTTP-Anfrage einfügt. Wenn der CPID-Endpunkt nicht Ihr Sicherheitsbereich ist (z.B. wenn der CPID-Endpunkt in einer öffentlichen Cloud bereitgestellt wird), darf der Operator den MSISDN nicht unverschlüsselt über das öffentliche Internet übertragen. Der Operator kann ein VPN zwischen der DPI und dem CPID-Endpunkt einrichten (siehe Abbildung 1) oder die MSISDN verschlüsseln, bevor sie in den Header eingeschleust wird. Beim letzten Ansatz wird davon ausgegangen, dass der CPID-Endpunkt den eingeschleusten Header entschlüsseln kann, um die MSISDN wiederherzustellen, bevor die CPID generiert wird. Außerdem muss der Operator den geheimen Schlüssel schützen, der zum Generieren der CPID verwendet wurde, und diesen Schlüssel gemäß den Sicherheitsrichtlinien des Operators rotieren.

Verfügbarkeit und Kapazitätsanforderungen

Wenn Clients keine CPID abrufen können, haben sie auch keinen Zugriff auf Informationen der Mobile Data Plan API. Aus diesem Grund SOLLTE 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 von DPI-Funktionen sowie eine physische, Standort- und Netzwerkredundanz für beide Funktionen und die Sicherstellung, dass die Systemressourcen und Kapazitäten angemessen sind. Darüber hinaus müssen der CPID-Endpunkt und die DPI-Funktion, die den Header einschleust, eine ausreichende Kapazität haben, um die Last aller Google-Clients zu bewältigen, die CPIDs anfordern. Der CPID-Endpunkt kann größere Werte im Feld „ttlSeconds“ verwenden, um die Häufigkeit der CPIDs zu reduzieren. Google empfiehlt einen TTL-Wert von 30 Tagen.

Hinweise

  1. Der VIDEO_OFFLINE-PMTC bedeutet, dass dieser Tarif nur für die Offlinenutzung geeignet ist (z.B. eine schlechte Streamingqualität). Sie ist unabhängig vom FlexTime-Fenster. ↩