Установление 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-адресов для повышения доступности.
  2. Список 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 секунд, даже если подписчик впоследствии запросил другие CPID. Google рекомендует использовать значение TTL 30 дней, но не менее 14 дней для лучшего взаимодействия с пользователем. GTAF будет кодировать CPID в соответствии с RFC2396 при последующих обращениях к DPA.

Генерация 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 может быть нетривиальной. Особой проблемой, с которой часто приходится сталкиваться, является получение доступа к MSISDN в конечной точке CPID. Мы рады поделиться уроками, извлеченными операторами на борту. Пожалуйста, свяжитесь с нами, если вы столкнетесь с какими-либо трудностями.

Хранилище CPID

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

  1. Когда DPA получает запрос от GTAF о статусе плана или предложениях, MSISDN может быть получен путем расшифровки CPID и извлечения MSISDN.
  2. Время истечения срока действия CPID может быть получено путем расшифровки CPID и последующего извлечения метки времени истечения срока действия.

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

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

Случаи ошибок

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

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

Конечная точка CPID ДОЛЖНА возвращать следующее в зависимости от сценария:

  1. Если запрос CPID получен для пользователя, который не принадлежит к сети оператора (например, пользователь, принадлежащий другому оператору, но находящийся в роуминге в сети, обслуживаемой этой конечной точкой CPID) или который не решил делиться информацией о тарифном плане с Google, Конечная точка CPID ДОЛЖНА возвращать код состояния HTTP 403 с USER_ROAMING, USER_OPT_OUT или INELIGIBLE_FOR_SERVICE в качестве причины.
  2. Если получен запрос CPID с недопустимым номером телефона, конечная точка CPID ДОЛЖНА вернуть HTTP 400 с причиной ошибки INVALID_NUMBER.
  3. Если запрос к конечной точке CPID искажен каким-либо другим образом, конечная точка CPID ДОЛЖНА вернуть HTTP 400 с ERROR_CAUSE_UNSPECIFIED в качестве причины.
  4. Для других причин ошибки допустим любой совместимый код ошибки HTTP. В частности, HTTP 500 является подходящей причиной ошибки для любого внутреннего сбоя в конечной точке CPID.