Wprowadzenie do udostępniania mobilnej transmisji danych

Terminologia

  • GTAF: funkcja aplikacji Google Traffic. Usługa Google, która implementuje interfejs API udostępniania planu danych i współpracuje z organami ochrony danych w imieniu aplikacji Google. Aplikacje Google mogą wysyłać zapytania o GTAF o dane użytkownika. Jeśli aplikacje Google są zarejestrowane w GTAF, GTAF może wysyłać aktualne informacje o abonamencie użytkownika.
  • numer MSISDN: numer jednoznacznie identyfikujący subskrypcję sieci komórkowej w sieci komórkowej. Znany jako numer telefonu.
  • Punkt końcowy CPI: usługa wdrażana przez operatorów sieci komórkowych, która generuje identyfikator planu operatora (CPI), którego można używać do wyszukiwania informacji o użyciu danych użytkownika. CPID umożliwia aplikacji tworzenie zapytań o szczegółowe informacje o planie danych użytkownika bez dostępu do numeru MSISDN użytkownika. Poniżej przedstawiamy procedurę generowania raportów CPID.
  • Klucz użytkownika: klucz użytkownika to ciąg znaków, który umożliwia identyfikację planu danych użytkownika. W przypadku aplikacji mających dostęp do MSISDN może to być identyfikator CPI lub MSISDN.
  • DPA: agent pakietu danych, usługa wdrażana przez operatorów sieci komórkowych, która udostępnia GTAF informacje o projekcie użytkownika. Organ ochrony danych może udostępniać dane GTAF za pomocą kombinacji wysyłania danych za pomocą interfejsu Google Mobile Plan Plan udostępniania API i implementacji interfejsu Data Plan Agent API. Organ ochrony danych może też pełnić funkcję punktu końcowego CPID.
  • UE: sprzęt użytkownika, urządzenie używane przez użytkownika.

Język wymagań

Słowa kluczowe &MUT", "MUST NOT", "REQUIRED", "SHALL","ShOULD NOT","RECOMMENDED";";

Udostępnianie mobilnej transmisji danych

Ogólnie rzecz biorąc, Udostępnianie mobilnej transmisji danych składa się z 3 części:

  1. Mechanizm określający i aktualizujący identyfikator abonamentu (CPI), którego można używać jako klucza użytkownika. Aplikacje mające dostęp do MSISDN mogą używać go jako klucza użytkownika.
  2. Interfejs API udostępniania mobilnej transmisji danych Google, który umożliwia organowi ochrony danych wysyłanie informacji o pakiecie danych użytkownika do Google. Jeśli organ ochrony danych na przykład chce powiadomić użytkownika o ofercie, może powiadomić GTAF, co z kolei powiadamia użytkownika.
  3. Wybrany przez Aneks o przetwarzaniu danych interfejs API agenta danych, który umożliwia GTAF wysyłanie zapytań do organu ochrony danych w celu uzyskania informacji o abonamencie. Jeśli na przykład aplikacja chce wyświetlić użytkownikowi aktualne saldo w usłudze, może wysłać zapytanie do GTAF, co z kolei spowoduje wysłanie zapytania do organu ochrony danych.

W pozostałej części tej strony opisujemy terminologię pakietu danych i szczegółowe informacje o stosowaniu CPI. Poniżej znajdziesz specyfikację interfejsu API udostępniania danych na urządzenia mobilne Google oraz specyfikację interfejsu Data Data Agent API.

Terminologia dotycząca pakietu danych

Schemat planStatus zdefiniowany w interfejsie API MUSI reprezentować plany danych oferowane przez operatorów użytkownikom. Interfejs API obsługuje definiowanie abonamentów, w których opłata za cały ruch w określonej grupie adresów URL jest inna (np. za cały ruch w domenie *.acmefake.com naliczana jest inna stawka). Interfejs API obsługuje również abonamenty z różnymi stawkami za określone rodzaje działań w aplikacjach. Nazywamy je subaplikacjami. Abonamentem może być np. subskrypcja podrzędnafilmów, które zawierają informację o odtwarzaniu filmów bez oglądania filmów; Aplikacja wideo musi mieć dostęp do tych informacji, gdy wysyła zapytanie o abonament.

Tutaj przedstawiamy wybrane terminy związane z pakietami danych. Rysunek 1 zawiera przykłady abonamentów danych odzwierciedlających koncepcje, które chcemy uchwycić.

Abonament: pakiet usług najwyższego poziomu kupiony przez subskrybenta. Może to być po prostu 10 GB danych mobilnych na 30 dni, a także zdefiniować je jako zbiór komponentów zwanych też modułami. Pakiet danych ma:

  • Nazwa pakietu danych, np. "ACME Red&quot.
  • Identyfikator abonamentu, odnoszący się do planu, na przykład podczas zakupów.
  • Data ważności: data wygaśnięcia abonamentu.
  • Kategoria planu: niezależnie od tego, czy jest to abonament przedpłacony czy abonament popłacony.

Moduł planu: komponent planu danych. Na przykład moduł planu zawiera:

  • Nazwa modułu, np. "bezpłatne wieczory wideo&.
  • Maksymalna przepustowość, czyli przepustowość, która jest oferowana użytkownikowi przez ten moduł.
  • Flex przedziały czasu, w których można oferować użytkownikom zniżki.

  • Kategoria ruchu modułu planu (PMTC) to opis ruchu danych, którego dotyczy moduł. Wartość PMTC może być tak ogólna jak *cały ruch w internecie *lub tak szczegółowa jak ruch generowany lub konsumowany przez co najmniej 1 aplikację, witrynę, a nawet ścieżkę użytkownika w 1 aplikacji. Przykładem może być "muzyka bez ograniczeń, &&tt;100 MB pakiet danych wideo (VDP), "nieograniczone dane o grach i "nieograniczone przeglądanie filmów&quot. Aby uprościć definicję PMTC, określiliśmy następujące standardy PMTC: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE1, MUSIC, GAMING, SOCIAL, MESSAGING i PMTC_UNSPECIFIED.

  • Ilość danych lub limit czasu po aktywowaniu modułu planu wygasa on po przekroczeniu limitu danych lub limitu czasu (w przypadku abonamentów czasowych, np. 600 minut dostępu do internetu w ciągu najbliższych 7 dni). Na rysunku 1 poniżej subskrybent może kupić moduł planu w ramach pakietu „ACME Blue&quot”, który zapewnia 1 GB ogólnego ruchu użytkowników, który należy wykorzystać w ciągu tygodnia od wygaśnięcia.

Przykładowy plan API Data Data API

Rysunek 1. Przykładowe pakiety danych.

Określanie CPI

GTAF używa klucza użytkownika do identyfikowania subskrybenta podczas komunikacji z Aneksem o przetwarzaniu danych. Aplikacje, które mają dostęp do pliku MSISDN użytkownika, mogą go używać jako klucza użytkownika. Z kolei aplikacje, które nie mają dostępu do MSISDN, muszą ustalić identyfikator abonamentu operatora (CPID) bez wykrywania numeru MSISDN użytkownika. W tym artykule opisujemy mechanizm, który pozwala ustalić CPI.

CPI – proces połączenia

Rysunek 2: Przebieg rozmowy pozwalający określić CPI

  1. Aplikacja Google w Unii Europejskiej używa wewnętrznego interfejsu Google API do pobierania adresu URL punktu końcowego CPI z GTAF. Operator jest rozpoznawany na podstawie publicznego adresu IP klienta oraz numeru MCK+MNC aktywnej karty SIM. W przypadku MVNO Google używa SPN i GID1 do określenia MVNO.
  2. Klient wysyła żądanie HTTP GET do punktu końcowego CPID. Operator MOŻE obsługiwać wysyłanie żądań przez HTTPS.
  3. Operator MAY może użyć swojej funkcji szczegółowego sprawdzania pakietów, by zidentyfikować żądanie i wstrzyknąć do niego numer telefonu użytkownika jako nagłówek HTTP.
  4. Punkt końcowy CPId otrzymuje żądanie, tworzy CPI i zwraca go do UE z czasem życia (TTL), który określa, jak długo UE może używać tego CPI.

W razie potrzeby operator MAY może także używać adresów IP zamiast nazw domen w adresie URL punktu końcowego CPID. Adresy IP MOGĄ być w przestrzeni prywatnej, ale muszą być osiągalne przez klientów Google wewnątrz sieci operatorów.

W ramach procesu rejestracji operator SHALL przekazuje te informacje: 1. CPID_URL, z którymi aplikacje będą się kontaktować, aby uzyskać CPID. Jeden parametr CPID_URL jest wymagany, ale operator może podać kilka adresów URL, aby zwiększyć dostępność. 1. Lista prefiksów adresów IP należących do operatora, a także kod urządzeń mobilnych (MCK) i kody sieci komórkowej, które mają być zmapowane do podanych adresów URL CPID. Jeśli operator używa SPN lub GID1 do odróżnienia MVNO w swojej sieci, również powinien podać te informacje. Google użyje tych informacji, aby dopasować klientów do odpowiednich punktów końcowych CPI, jak pokazano w kroku 1 na rysunku 2.

Format żądania: GET CPID_URL W przypadku starszych punktów końcowych punkt końcowy CPID powinien obsługiwać żądania podobne do tych:

GET CPID_URL?app={app_id}

Podczas generowania CPID punkt końcowy może ignorować parametr URL {app_id}. Musi jednak radzić sobie z żądaniem zawierającym parametr.

Żądanie do punktu końcowego CPID może zawierać nagłówek Accept-Language. Jeśli nagłówek zawiera nagłówek, wtedy zrozumiałe dla ludzi ciągi znaków w aktualizacjach wysyłane przez organ ochrony danych przy użyciu interfejsu API mobilnej transmisji danych MUSZĄ skorzystać z ustawień podanych w żądaniu CPID.

Za każdym razem, gdy klient wysyła żądanie GET CPID_URL, MUSI otrzymać nowy identyfikator CPID. Jeśli CPID zostanie utworzony, punkt końcowy CPI MUSI zwrócić odpowiedź 200 OK. Treść odpowiedzi MUSI zawierać instancję CPIDResponse.

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

Zwrócone wartości CPI MUSZĄ być prawidłowe przez ttlSeconds sekund. GTAF będzie kodować CPID według RFC2396 w kolejnych wywołaniach organu ochrony danych.

Jeśli wystąpi błąd, punkt końcowy CPID MUSI zwracać błąd HTTP z treścią odpowiedzi, która MUSI zawierać instancję ErrorResponse. Lista możliwych przyczyn i kodów błędów HTTP jest dostępna tutaj.

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

W szczególności jeśli żądanie CPID otrzyma użytkownik, który nie należy do sieci operatora (np. należy do innego operatora, ale korzysta z roamingu w sieci obsługiwanej przez ten punkt końcowy CPID), lub nie chce udostępniać Google informacji o planie danych, jego punkt końcowy MUSI zwrócić kod stanu HTTP 403.

Generowanie CPI

ZALECANY sposób tworzenia punktu CPI w punkcie końcowym CPID:

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

Punkt końcowy CPID łączy parametr MSISDN, język wysyłany przez klienta w nagłówku Accept-Language i sygnaturę czasową o wysokiej rozdzielczości oraz szyfruje je za pomocą klucza AES za pomocą klucza secret. Sygnatura czasowa powinna odpowiadać czasowi CPI. Zaszyfrowane dane wyjściowe są zakodowane w formacie Base64. Jeśli w adresie URL używa się CPI, MUSI ono być zakodowane w adresie URL do obsługi znaków specjalnych (/+=) używanych w standardzie Base64. W szczególności, gdy obiekt GTAF wywołuje funkcję Aneksu o przetwarzaniu danych lub wywołuje interfejs API udostępniania danych na urządzenia mobilne, CPI musi być zakodowany na potrzeby adresu URL. Zaletą generowania CPI za pomocą tej metody jest to, że punkt końcowy DPA i CPID nie musi mieć bazy danych prawidłowych identyfikatorów CPID i MSISDN.

W zależności od sytuacji poszczególnych operatorów zastosowanie punktu końcowego CPI może nie być proste. Częstym wyzwaniem, który często napotykamy, jest uzyskanie dostępu do MSISDN w punkcie końcowym CPID. Chętnie podzielimy się zdobytą wiedzą na temat operatorów wprowadzających do Google Analytics. Skontaktuj się z nami, jeśli natrafisz na jakieś wyzwania.

Wymagania dotyczące bezpieczeństwa

Operator SHALL stosuje wszystkie środki ostrożności, aby chronić prywatne informacje subskrybentów. Aby zminimalizować ekspozycję numerów telefonów subskrybentów, punkt końcowy CPID powinien znajdować się wewnątrz granicy bezpieczeństwa. Ponadto w przypadkach, w których operator wykorzystuje DPI, operator powinien zaszyfrować plik MSISDN przed wstrzyknięciem go do żądania HTTP. Jeśli punkt końcowy CPI nie jest granicą zabezpieczeń (na przykład gdy punkt końcowy CPID jest wdrażany w chmurze publicznej), operator NIE powinien w bezpiecznym przypadku przekazywać numeru MSISDN przez publiczny internet. Operator może nawiązać połączenie VPN między punktami DPI i punktem końcowym CPId (zobacz rysunek 1) lub zaszyfrować MSISDN przed wstrzyknięciem kodu do nagłówka. Przyjęto założenie, że punkt końcowy CPID może odszyfrowywać wstrzykiwany nagłówek, aby odzyskać numer MSISDN przed wygenerowaniem CPID. Dodatkowo operator TREŚĆ chroni tajny klucz używany do generowania CPI i rotuje go zgodnie z zasadami zabezpieczeń operatora.

Wymagania dotyczące dostępności i pojemności

Jeśli klient nie może pobrać CPI, nie może uzyskać dostępu do żadnych informacji z API mobilnej transmisji danych. Dlatego w celu zapewnienia dostępności punktu końcowego CPI operator SHALL musi podjąć odpowiednie kroki. Obejmuje to m.in. posiadanie wielu wystąpień punktu końcowego CPI i funkcji DPI oraz zapewnienie nadmiarowości fizycznej, witryny i sieci dla obu funkcji, a także zapewnienie odpowiednich zasobów i możliwości systemu. Dodatkowo punkt końcowy CPID oraz funkcja DPI, które wstawiają nagłówek, muszą mieć odpowiednie uprawnienia do obsługi wszystkich klientów Google żądających CPID. Punkt końcowy CPID może używać większych wartości w polu ttlSeconds, aby ograniczyć częstotliwość generowania CPID. Google zaleca używanie TTL na 30 dni.

Uwagi

  1. PMTC VIDEO_OFFLINE oznacza, że ten abonament nadaje się tylko do oglądania w trybie offline (np. kiepsko transmitowany QoE). Są one niezależne od okna FlexTime.↩