Diese Seite wurde von der Cloud Translation API übersetzt.

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

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.
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.
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.
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:

Die CPID_URL, die von Anwendungen kontaktiert wird, um CPIDs zu erhalten. Eine CPID_URL ist obligatorisch, aber der Operator kann mehrere URLs angeben, um die Verfügbarkeit zu erhöhen.
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, auch wenn ein Abonnent danach andere CPIDs angefordert hat. Google empfiehlt für eine optimale Nutzererfahrung einen TTL-Wert von 30 Tagen, jedoch nicht weniger als 14 Tagen. GTAF codiert die CPID nach RFC2396 in nachfolgenden Aufrufen der DPA.

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.

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.

CPID-Speicher

Eine CPID, die mit dem oben beschriebenen Mechanismus generiert wurde, muss nicht in einer Datenbank gespeichert werden. Relevante Informationen für die Verarbeitung von Aufrufen an die DPA können von der CPID abgeleitet werden.

Wenn die DPA von GTAF einen Tarifstatus oder Angebote erhält, kann die MSISDN abgeleitet werden, indem die CPID entschlüsselt und die MSISDN extrahiert wird.
Die Ablaufzeit der CPID kann abgeleitet werden, indem die CPID entschlüsselt und dann der Ablaufzeitstempel extrahiert wird.

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.

Fehler

Wenn ein Fehler auftritt, MUSS der CPID-Endpunkt einen HTTP-Fehler mit einem Antworttext zurückgeben, der eine Instanz von ErrorResponse enthalten muss. Eine gute Fehlermeldung enthält Informationen, die bei der Fehlerbehebung helfen können. Beispielsweise kann uns im Falle einer abgelaufenen CPID, einschließlich CPID-Generierung und Ablaufzeit, helfen, zu prüfen, ob der CPID-Endpunkt wie vorgesehen funktioniert.

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

Der CPID-Endpunkt MUSS je nach Szenario Folgendes zurückgeben:

Wenn eine CPID-Anfrage für einen Nutzer eingeht, der nicht zum Netzwerk des Betreibers gehört (z.B. ein Nutzer, der zu einem anderen Betreiber gehört, aber ein Roaming im Netzwerk dieses CPID-Endpunkts nutzt) oder der die Freigabe von Datenplandaten für Google nicht aktiviert hat, MUSS der CPID-Endpunkt den HTTP-Statuscode 403 mit USER_ROAMING, USER_OPT_OUT oder INELIGIBLE_FOR_SERVICE als Ursache senden.
Wenn eine CPID-Anfrage mit einer ungültigen Telefonnummer empfangen wird, MUSS der CPID-Endpunkt HTTP 400 mit der Fehlermeldung INVALID_NUMBER zurückgeben.
Wenn die Anfrage an den CPID-Endpunkt auf andere Weise fehlerhaft ist, MUSS der CPID-Endpunkt HTTP 400 mit ERROR_CAUSE_UNSPECIFIED als Ursache zurückgeben.
Für andere Fehlerursachen ist jeder kompatible HTTP-Fehlercode akzeptabel. HTTP 500 ist insbesondere eine geeignete Fehlerursache für interne Fehler am CPID-Endpunkt.