Начало работы с совместным использованием мобильных тарифных планов

Терминология

  • GTAF : Функция приложения Google Traffic. Служба Google, реализующая API совместного использования тарифных планов и взаимодействующая с DPA от имени приложений Google. Приложения Google могут запрашивать у GTAF информацию о тарифном плане пользователя. В качестве альтернативы, если приложения Google регистрируются в GTAF, GTAF может отправлять обновления о тарифном плане пользователя.
  • MSISDN : Международный абонентский номер мобильной станции, номер, однозначно идентифицирующий подписку в мобильной сети. Более известен как номер телефона.
  • Конечная точка CPID : служба, реализуемая операторами сетей мобильной связи, которая генерирует идентификатор тарифного плана (CPID), который можно использовать для поиска информации о тарифном плане пользователя. CPID позволяет приложению запрашивать сведения о тарифном плане пользователя без доступа к MSISDN пользователя. Мы опишем процедуру создания CPID ниже.
  • Ключ пользователя: ключ пользователя — это строка, которую можно использовать для идентификации тарифного плана пользователя. Это может быть либо CPID, либо MSISDN для приложений, имеющих доступ к MSISDN.
  • DPA : Агент плана данных, услуга, реализованная операторами мобильных сетей, которая передает информацию о плане данных пользователя в GTAF. DPA может обмениваться информацией с GTAF, используя комбинацию отправки данных с помощью Google Mobile Data Plan Sharing API и реализации Data Plan Agent API. DPA также может дополнительно выступать в качестве конечной точки CPID.
  • UE : Пользовательское оборудование, устройство, используемое пользователем.

Язык требований

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этих руководствах интерпретироваться, как описано в RFC 2119 .

Совместное использование мобильных тарифных планов

На высоком уровне совместное использование плана мобильных данных состоит из трех частей:

  1. Механизм для установки и обновления идентификатора тарифного плана (CPID), который можно использовать в качестве ключа пользователя . Приложения, имеющие доступ к MSISDN, могут использовать MSISDN в качестве ключа пользователя .
  2. Google Mobile Data Plan Sharing API, который позволяет DPA отправлять информацию о тарифном плане пользователя в Google. Например, если DPA хочет уведомить пользователя о предложении, он может уведомить GTAF, который, в свою очередь, уведомит пользователя.
  3. API агента плана данных, реализованный DPA, который позволяет GTAF запрашивать у DPA информацию о плане данных пользователя. Например, если приложение хочет отобразить текущий баланс тарифного плана для пользователя, оно может запросить GTAF, который, в свою очередь, запрашивает DPA.

Остальная часть этой страницы знакомит с терминологией тарифного плана и подробно описывает, как установить CPID . Далее следуют API совместного использования тарифных планов Google для мобильных устройств и Спецификация API агента тарифных планов.

Терминология плана данных

Схема planStatus , определенная в API, ДОЛЖНА представлять планы данных, которые операторы предлагают пользователям. API поддерживает определение планов передачи данных, которые взимают плату с пользователей по разным тарифам за весь трафик на определенный набор URL-адресов (например, весь трафик на *.acmefake.com оплачивается по другому тарифу). API также поддерживает планы данных, которые предлагают разные тарифы для определенных типов действий в приложении. Мы называем эти тарифные планы для дополнительных приложений . Примером тарифного плана для дополнительного приложения может быть предложение бесплатного просмотра видео (т. е. с нулевой скоростью), при этом просмотр видео в приложении вычитает данные из баланса данных подписчика. Видеоприложение ДОЛЖНО затем получить эту информацию при запросе информации о тарифном плане.

Здесь мы вводим некоторые термины, связанные с тарифными планами. На рис. 1 представлены примеры планов данных, которые отражают концепции, которые мы хотим зафиксировать.

Тарифный план: пакет мобильных услуг верхнего уровня, который приобретает абонент. Это может быть просто «10 ГБ мобильных данных на 30 дней» или набор компонентов, также известных как модули. Тарифный план имеет:

  • Название тарифного плана , например «ACME Red».
  • Идентификатор плана данных , используемый для ссылки на план, например, во время покупок.
  • Срок действия , когда истекает срок действия тарифного плана.
  • Категория плана , независимо от того, является ли план предоплатой или постоплатой.

Модуль плана: компонент плана данных. В частности, модуль плана имеет:

  • Название модуля , например, «Бесплатные ночи видео».
  • Max Rate , пропускная способность, предлагаемая пользователю этим модулем.
  • Flex Time Windows , временные окна, в течение которых пользователю может быть предложена скидка.

  • Категория трафика модуля планирования (PMTC) — описание трафика данных, к которому применяется модуль. PMTC может быть как общим, как *весь интернет-трафик, так и конкретным, как трафик, генерируемый/потребляемый одним или несколькими приложениями, веб-сайтами или даже действиями пользователя в рамках одного приложения. Примерами последнего типа являются «неограниченная музыка», «пакет видеоданных 100 МБ (VDP)», «неограниченные игровые данные» и «неограниченный просмотр видео». Чтобы облегчить определение PMTC, мы определили следующие PMTC: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE 1 , MUSIC, GAMING, SOCIAL, MESSAGING MESSAGING и PMTC_UNSPECIFIED.

  • Объем данных или ограничение по времени После активации модуль плана истекает, когда превышен либо объем данных, либо ограничение по времени (в случае повременных планов, например, 600 минут доступа в Интернет в течение следующих 7 дней). На Рисунке 1 ниже подписчик может приобрести модуль плана как часть «ACME Blue», который предоставляет 1 ГБ обычного пользовательского трафика, который необходимо использовать в течение недели после активации до истечения срока их действия.

Data Plan API Sample Plan

Рисунок 1. Примеры планов данных.

Установление CPID

GTAF использует ключ пользователя для идентификации подписчика при общении с DPA. Приложения, имеющие доступ к MSISDN пользователя, могут использовать его как user_key. С другой стороны, приложения, не имеющие доступа к MSISDN, должны установить идентификатор тарифного плана (CPID), не обнаруживая MSISDN пользователя. Далее мы опишем механизм, который устанавливает CPID.

Поток вызовов CPID

Рисунок 2: Поток вызовов для установления CPID.

  1. Приложение Google в UE использует внутренний API Google для получения URL-адреса конечной точки CPID из GTAF. Оператор идентифицируется с помощью общедоступного IP-адреса клиента и MCC+MNC активной SIM-карты. В случае MVNO Google будет использовать SPN и GID1 для определения MVNO.
  2. Клиент отправляет запрос HTTP GET к конечной точке CPID. Оператор МОЖЕТ поддерживать отправку запроса через HTTPS.
  3. Оператор МОЖЕТ использовать свою функцию Deep Packet Inspection для идентификации запроса и добавления номера телефона пользователя в запрос в качестве заголовка HTTP.
  4. Конечная точка CPID получает запрос, формирует CPID и возвращает CPID в UE со временем жизни (TTL), указывающим, как долго UE может использовать этот CPID.

Оператор МОЖЕТ также использовать IP-адреса вместо доменных имен в URL-адресе конечной точки CPID, если это предпочтительно. IP-адреса МОГУТ находиться в частном адресном пространстве, но они должны быть доступны клиентам Google в сети оператора.

Оператор ДОЛЖЕН предоставить Google следующую информацию в рамках процесса регистрации: 1. CPID_URL, к которому приложения будут обращаться для получения CPID. Один CPID_URL является обязательным, но оператор может указать несколько URL-адресов для повышения доступности. 1. Список IP-префиксов, которыми владеет оператор, а также мобильный код страны (MCC) и код(ы) мобильной сети (MNC), которые оператор хочет сопоставить с предоставленными CPID_URL. Если оператор использует SPN или GID1 для различения MVNO в своей сети, оператор ДОЛЖЕН также предоставить эту информацию. Google будет использовать эту информацию для сопоставления клиентов с соответствующими конечными точками CPID, как показано на шаге 1 на рис. 2.

Формат запроса: GET CPID_URL По устаревшим причинам конечная точка CPID должна иметь возможность поддерживать следующий запрос:

GET CPID_URL?app={app_id}

Конечная точка CPID может игнорировать параметр URL-адреса {app_id} при создании CPID. Но он ДОЛЖЕН иметь возможность обрабатывать запрос, содержащий параметр.

Запрос к конечной точке CPID МОЖЕТ включать заголовок Accept-Language . Если заголовок включен, то удобочитаемые строки в обновлениях, которые DPA отправляет с использованием API совместного использования планов мобильных данных, ДОЛЖНЫ использовать настройки, указанные в запросе CPID.

Каждый раз, когда клиент отправляет запрос GET CPID_URL, он ДОЛЖЕН получить новый CPID. Если создание CPID прошло успешно, конечная точка CPID ДОЛЖНА вернуть ответ 200 OK. Тело ответа ДОЛЖНО содержать экземпляр CPIDResponse .

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

Возвращенный CPID ДОЛЖЕН быть действительным в течение ttlSeconds секунд. GTAF будет кодировать CPID в соответствии с RFC2396 при последующих обращениях к DPA.

Если происходит ошибка, конечная точка CPID ДОЛЖНА вернуть ошибку HTTP с телом ответа, которое ДОЛЖНО содержать экземпляр ErrorResponse . Список возможных значений причин и кодов ошибок HTTP доступен здесь .

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

В частности, если запрос CPID получен для пользователя, который не принадлежит к сети оператора (например, пользователь, принадлежащий другому оператору, но находящийся в роуминге в сети, обслуживаемой этой конечной точкой CPID) или который не решил делиться информацией о тарифном плане с Google, конечная точка CPID ДОЛЖНА возвращать код состояния HTTP 403.

Генерация CPID

РЕКОМЕНДУЕМЫЙ способ для конечной точки CPID создать CPID:

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

Конечная точка CPID объединяет MSISDN, язык, отправленный клиентом в заголовке Accept-Language, и отметку времени с высоким разрешением и шифрует ее через AES с использованием secret ключа. Временная метка ДОЛЖНА соответствовать времени истечения срока действия CPID. Зашифрованный вывод имеет кодировку Base64. Кроме того, когда CPID используется в URL-адресе, он ДОЛЖЕН быть закодирован в URL-адресе для обработки специальных символов (/+=), используемых в Base64. В частности, когда GTAF вызывает DPA или когда DPA вызывает API совместного использования планов мобильных данных, CPID ДОЛЖЕН быть закодирован в URL-адресе. Преимущество создания CPID с использованием этого подхода заключается в том, что конечной точке DPA и CPID не требуется база данных действительных CPID и MSISDN.

В зависимости от ситуации конкретного оператора реализация конечной точки CPID может быть нетривиальной. Особой проблемой, с которой часто приходится сталкиваться, является получение доступа к MSISDN в конечной точке CPID. Мы рады поделиться уроками, извлеченными операторами на борту. Пожалуйста, свяжитесь с нами, если вы столкнетесь с какими-либо трудностями.

Требования безопасности

Оператор ДОЛЖЕН принимать все необходимые меры предосторожности для защиты личной информации своих абонентов. В частности, чтобы свести к минимуму раскрытие телефонных номеров абонентов, конечная точка CPID ДОЛЖНА находиться внутри вашего периметра безопасности. Кроме того, в случаях, когда оператор использует DPI, оператору СЛЕДУЕТ зашифровать MSISDN перед его внедрением в HTTP-запрос. Если конечная точка CPID не является вашим периметром безопасности (например, когда конечная точка CPID развернута в общедоступном облаке), оператору НЕ СЛЕДУЕТ передавать MSISDN через общедоступный Интернет в открытом виде. Оператор может установить VPN между DPI и конечной точкой CPID (см. рис. 1) или зашифровать MSISDN перед его внедрением в заголовок. Последний подход предполагает, что конечная точка CPID может расшифровать внедренный заголовок, чтобы восстановить MSISDN до создания CPID. Кроме того, оператор ДОЛЖЕН охранять секретный ключ, используемый для генерации CPID, и менять этот ключ в соответствии с политиками безопасности оператора.

Требования к доступности и емкости

Если клиенты не могут получить CPID, они не могут получить доступ к какой-либо информации из API плана мобильных данных. По этой причине оператор ДОЛЖЕН принять необходимые меры для обеспечения доступности конечной точки CPID. Такие меры включают в себя наличие нескольких экземпляров конечной точки CPID и функций DPI, а также физическую, локальную и сетевую избыточность для обеих функций, а также обеспечение адекватности системных ресурсов и пропускной способности. Кроме того, конечная точка CPID, а также функция DPI, которая внедряет заголовок, должны иметь достаточную мощность для обработки нагрузки всех клиентов Google, запрашивающих CPID. Конечная точка CPID может использовать большие значения в поле ttlSeconds, чтобы уменьшить частоту генерации CPID. Google рекомендует использовать значение TTL, равное 30 дням.

Заметки

  1. VIDEO_OFFLINE PMTC означает, что этот план хорош только для автономного режима (например, очень плохое качество потоковой передачи). Это не зависит от окна FlexTime. ↩