Начало работы с общим доступом к тарифному плану мобильной связи

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

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

Требования к языку

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

Совместное использование тарифного плана мобильной связи

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

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

Далее на этой странице представлена терминология тарифного плана и подробная информация о создании идентификатора CPID . Далее следует API Google Mobile Data Plan Sharing и спецификация API Data Plan Agent.

Терминология тарифного плана

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

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

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

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

Модуль тарифного плана: компонент тарифного плана. В частности, модуль тарифного плана включает в себя:

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

  • Категория трафика модуля плана (PMTC) – описание трафика данных, к которому применяется модуль. PMTC может быть как общим, например, *весь интернет-трафик*, так и конкретным, например, трафик, генерируемый/потребляемый одним или несколькими приложениями, веб-сайтами или даже действиями пользователя в пределах одного приложения. Примерами последнего типа являются «неограниченная музыка», «100 МБ пакет видеоданных (VDP)», «неограниченные игровые данные» и «неограниченный просмотр видео». Для упрощения определения PMTC мы определили следующие PMTC: GENERIC, VIDEO, VIDEO_BROWSING, VIDEO_OFFLINE 1 , MUSIC, GAMING, SOCIAL, 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. Оператор МОЖЕТ использовать функцию глубокой проверки пакетов для идентификации запроса и добавления номера телефона пользователя в запрос в качестве HTTP-заголовка.
  4. Конечная точка CPID получает запрос, создает CPID и возвращает CPID в UE со временем жизни (TTL), указывающим, как долго UE может использовать этот CPID.

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

Оператор ОБЯЗАН предоставить Google следующую информацию в рамках процесса подключения: 1. URL-адрес CPID_URL, к которому будут обращаться приложения для получения идентификаторов CPID. Один URL-адрес CPID_URL обязателен, но оператор может предоставить несколько URL-адресов для повышения доступности. 1. Список префиксов IP-адресов, принадлежащих оператору, а также код страны мобильной связи (MCC) и код(ы) сети мобильной связи (MNC), которые оператор хочет сопоставить с предоставленными URL-адресами 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 Mobile Data Plan Sharing, ДОЛЖНЫ использоваться настройки, указанные в запросе 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. ↩