УСТРОЙСТВО ПОЛЬЗОВАТЕЛЯ, СПОСОБНОЕ ПЕРЕДАВАТЬ СООБЩЕНИЯ С ПОДТВЕРЖДЕНИЕМ ПРЕДОСТАВЛЕНИЯ УСЛУГ Российский патент 2021 года по МПК H04M15/00 H04W12/04 H04W12/06 H04W12/10 

Область техники

Настоящее изобретение относится к передаче сообщений с подтверждением предоставления услуги устройством пользователя (UE, User Equipment) в системе мобильной связи.

Уровень техники

Сети GSM, UMTS и EPC (Evolved Packet Core, усовершенствованное пакетное ядро) предоставляют функции, реализующие механизмы отложенной тарификации (offline charging) и/или механизмы тарификации в режиме реального времени (online charging) на уровне каналов, на уровне подсистем и на уровне услуг. Для поддержки этих механизмов тарификации сеть выполняет мониторинг использования ресурсов в режиме реального времени на трех упомянутых выше уровнях с целью обнаружения соответствующих событий тарификации.

При отложенной тарификации сообщение из сети в биллинговую зону (BD, Billing Domain) поступает после использования ресурса. При тарификации в режиме реального времени учетная запись абонента в системе тарификации в режиме реального времени (OCS, Online Charging System) запрашивается до предоставления разрешения на использование требуемых сетевых ресурсов.

Типичными примерами использования сетевых ресурсов являются голосовой вызов определенной длительности, передача определенного объема данных или отправка мультимедийного сообщения определенного размера. Запросы на использование сетевых ресурсов могут инициироваться устройством UE или сетью.

Отложенная тарификация - это процесс, при котором информация о стоимости использования сетевых ресурсов собирается одновременно с использованием этих ресурсов. Эта тарификационная информация затем проходит через цепочку логических функций, связанных с тарификацией. В конце этого процесса сеть формирует файлы записи тарификационных данных (CDR, Charging Data Record), которые затем передаются в зону BD оператора сети для выставления счетов абонентам и/или для расчетов между операторами (или для дополнительных функций по усмотрению оператора, например, для статистики). Зона BD обычно включает в себя такие системы последующей обработки, как биллинговая система или биллинговый медиатор оператора. Следует отметить, что отложенная тарификация - это механизм, при котором тарификационная информация не влияет в реальном времени на предоставляемую услугу.

Тарификация в режиме реального времени - это процесс, при котором тарификационная информация об использовании сетевых ресурсов собирается одновременно с использованием этих ресурсов тем же образом, что и при отложенной тарификации. Тем не менее, разрешение на использование сетевого ресурса должно быть получено сетью до фактического использования этих ресурсов. Это разрешение предоставляется системой OCS по запросу от сети.

При получении запроса на использование сетевых ресурсов сеть собирает соответствующую тарификационную информацию и формирует тарификационное событие для системы OCS. Затем система OCS передает разрешение на использование этих ресурсов. Разрешение на использование ресурсов может быть ограничено по объему (например, по объему данных или по длительности), поэтому время от времени может требоваться его возобновление до тех пор, пока продолжается использование этих сетевых ресурсов пользователем.

Тарификация в режиме реального времени - это механизм, в котором тарификационная информация в реальном времени может влиять на предоставляемую услугу, поэтому требуется непосредственное взаимодействие механизма тарификации с механизмом контроля использования сетевых ресурсов.

Функция фиксации событий тарификации (CTF, Charging Trigger Function) формирует тарификационные события на основе наблюдения за использованием сетевых ресурсов. Функция сбора данных тарификации (CDF, Charging Data Function) принимает эти тарификационные события от функции CTF через так называемую опорную точку Rf. Затем функция CDF использует информацию, содержащуюся в тарификационных событиях, для создания записей CDR. Записи CDR, создаваемые функцией CDF, немедленно передаются в функцию шлюза тарификации (CGF, Charging Gateway Function) через так называемую опорную точку Ga. Функция CGF действует как шлюз между сетью 3GPP и зоной BD. Она использует так называемую контрольную точку Bx для передачи файлов записей CDR в зону BD. Функция тарификации в режиме реального времени (OCF, Online Charging Function) состоит из двух отдельных модулей, а именно, из функции тарификации на основе сеанса (SBCF, Session Based Charging Function) и функции тарификации на основе события (EBCF, Event Based Charging Function).

Функция SBCF отвечает за тарификацию сетевых сессий или сессий пользователя в режиме реального времени, например, относящихся к голосовым вызовам, каналам сети доступа по протоколу IP (IP CAN bearer), сессиям сети доступа по протоколу IP (IP CAN session) или мультимедиа-службам (IMS).

Функция EBCF выполняет основанную на событиях тарификацию в режиме реального времени совместно с любым сервером приложений или сетевым узлом услуги (service NE), включая серверы приложений, предоставляющих услуги на базе протокола SIP (SIP application server).

Функция определения стоимости (RF, Rating Function) от имени функции OCF определяет стоимость использования сетевого ресурса (описанного в тарификационном событии, полученном функцией OCF от сети).

Система отложенной тарификации (OFCS, OFfline Charging System) представляет собой группу функций тарификации, используемых для отложенной тарификации. Система собирает и обрабатывает тарификационные события от одной или нескольких функций CTF и формирует записи CDR для последующих процессов отложенного биллинга.

Если абонент находится в роуминге и обслуживается гостевой сетью, две системы тарификации (в гостевой сети и в домашней сети) выполняют тарификацию абонента раздельно. Плата за роуминг обычно начисляется за каждую минуту для голосовых вызовов (при этом тарифы для входящих и исходящих голосовых вызовов различаются), за сообщение SMS и за мегабайт переданных данных. Для осуществления тарификации эти две сети связаны процедурой передачи счета (TAP, Transferred Account Procedure). Механизм передачи для процедуры TAP - это механизм, используемый специализированными приложениями для расширенной логики мобильной сети связи (CAMEL, Customized Applications for Mobile network Enhanced Logic).

Для всех услуг, предоставляемых гостевой сетью и маршрутизируемых через домашнюю сеть, таких как, например, голосовые вызовы, SMS, IMS, оператор домашней сети имеет возможность проверять всю тарификацию, передаваемую из гостевой сети по процедуре TAP. Существуют некоторые услуги, которые уже в настоящее время не маршрутизируются через домашнюю сеть, такие как доступ в Интернет с местным трафиком или локально маршрутизируемая передача речи по протоколу IP (VoIP, Voice over IP). Эти локально предоставляемые услуги, вероятно, станут более популярными. У оператора домашней сети отсутствует механизм проверки тарификации, передаваемой из гостевой сети по процедуре TAP, для локально маршрутизируемых услуг. В настоящее время операторы вынуждены доверять друг другу в том, что услуги, за которые гостевая сеть передает счет на оплату, фактически были предоставлены абоненту, находящемуся в роуминге. Необходим механизм, позволяющий оператору домашней сети проверять стоимость роуминга.

В документе US 20020161723 A1 описан способ, в котором идентичность устройства UE проверяется традиционным способом с использованием ключей, хранящихся в устройстве UE и в центре аутентификации. Когда устройство UE подключено к местной сети, отличной от его домашней сети, общий секретный ключ, используемый оператором домашней сети и устройством UE, используется для проверки устройства UE оператором местной сети. Если пользователь устройства UE желает совершить покупку, используя устройство UE для разрешения провести платеж, то выполняется обмен сообщениями с продавцом с использованием другой сети связи, при этом устройство UE подписывает сообщение от продавца, чтобы подтвердить приемлемость транзакции. Затем для проверки подписи используется сетевой сервис проверки подписи. Сервис проверки подписи не зависит от домашней сети и местной сети. Как описано в документе, устройство UE и сервис проверки подписи имеют ключи подписи.

В документе WO 2005004456 описан механизм тарификации пользователя устройства UE, использующего гостевую сеть, в котором домашняя сеть выдает учетные сертификаты, направляемые устройству UE, что дает возможность устройству UE предоставлять их поставщику услуг в гостевой сети.

Раскрытие изобретения

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

Настоящее изобретение реализует механизм, дающий оператору домашней сети степень контроля тарификации в роуминге по процедуре TAP. Согласие пользователя может быть частью этого механизма. Одним аспектом этого механизма является установление общего секретного ключа для устройства UE и оператора домашней сети и использование этого ключа для формирования сообщения с подтверждением предоставления услуги с защитой целостности. Этот общий секретный ключ также может использоваться для отправки сообщений с защитой целостности из домашней сети в устройство UE, например, списка предпочтительных или разрешенных гостевых сетей. Предусмотрено несколько способов передачи таких сообщений с подтверждением предоставления услуги от устройства UE оператору домашней сети. Наиболее полезный вариант заключается в усовершенствовании функции CTF гостевой сети, когда сообщения с подтверждением предоставления услуги, сформированные устройством UE в роуминге, добавляются к сформированным записям CDR в гостевой сети и пересылаются оператору домашней сети в виде тарификационных сообщений по процедуре TAP. Существует также несколько альтернативных вариантов для обмена секретным ключом между устройством UE и домашней сетью, неизвестной гостевой сети. Один из вариантов - дважды выполнить функцию соглашения об аутентификации и ключах (AKA, Authentication and Key Agreement), но не сообщать гостевой сети ключ защиты целостности при повторном выполнении. Преимущество этого способа заключается в том, что он не влияет на существующие SIM-карты. На более поздних этапах стандартизации систем 5G возможно, что функция формирования ключа (KDF, Key Derivation Function) будет использоваться для формирования всех сессионных ключей для гостевой сети из ключей для домашней сети, т.е. когда гостевая сеть не получает ключи из домашней сети, а ключи, предназначенные для гостевой сети, сформированы из ключей для домашней сети. В этом случае может использоваться ключ защиты целостности для домашней сети, остающийся неизвестным гостевой сети.

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

Краткое описание чертежей

Далее в качестве примера описаны предпочтительные варианты осуществления изобретения со ссылкой на следующие приложенные чертежи.

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

На фиг. 2 показано схематическое представление процедуры соглашения об аутентификации и ключах.

На фиг. 3 показана схема потока сообщений, иллюстрирующая вариант осуществления изобретения.

Осуществление изобретения

В первом варианте осуществления изобретения известный механизм ответа на начальный запрос, называемый соглашением AKA, при котором формируются сеансовые ключи, запускается на выполнение дважды, чтобы сформировать два разных ключа целостности. В существующем сценарии LTE-роуминга соглашение AKA выполняется между устройством UE и объектом управления мобильностью (MME, Mobility Management Entity) обслуживающей сети один раз. Объект MME запрашивает вектор аутентификации у оператора домашней сети, включающий в себя запрос, корневой сессионный ключ K_ASME и ожидаемый ответ на запрос. Объект MME пересылает запрос устройству UE, устройство UE вычисляет ответ на этот запрос и соответствующий корневой сессионный ключ. Устройство UE отправляет ответ объекту MME. Объект MME проверяет ответ с использованием ожидаемого ответа. Сформированный сессионный ключ сохраняется вместе с идентификатором KSI_ASME в устройстве UE и в объекте MME и используется при установлении контекста безопасности для устройства UE. Процедура соглашения AKA описана в документе 3GPP TS 33.401 v15.0.0.

В этом варианте осуществления изобретения процедура соглашения AKA выполняется дважды. Первый раз она выполняется так, как описано выше. При повторном ее выполнении из домашней сети в обслуживающую сеть передаются только запрос и ожидаемый ответ, т.е. корневой сессионный ключ K_ASME2 хранится в домашней сети и не передается обслуживающей (гостевой) сети. Корневым ключом в иерархии сессионных ключей для контекста безопасности между обслуживающей сетью и устройством UE является K_ASME1, а ключ защиты целостности для сообщения с подтверждением предоставления услуги получается из ключа K_ASME2. Поскольку обслуживающая сеть не знает о ключе K_ASME2, то сообщения с подтверждением предоставления услуги, имеющие защиту целостности и подписанные ключом защиты целостности, известным только устройству UE и оператору домашней сети, не могут формироваться обслуживающей сетью, а могут формироваться только устройством UE. Если обслуживающая сеть изменяет содержимое сообщения с подтверждением предоставления услуги, это выявляется проверкой целостности в домашней сети.

На фиг. 1 показан объект MME, запрашивающий один или несколько векторов аутентификации из базы данных абонентов в среде домашней сети (HE, Home Environment) оператора домашней сети. Процедура соглашения AKA представлена на фиг. 2 (известный уровень техники).

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

Если сообщения с подтверждением предоставления услуги являются опциональной функцией, выполняемой устройством UE и обслуживающей сетью только в случае запроса из домашней сети, то необходимо передавать сигналы запроса от оператора домашней сети в обслуживающую сеть. Полезно добавить эту информацию в ответ на запрос аутентификации от среды HE к объекту MME обслуживающей сети. В третьем варианте осуществления изобретения оператор домашней сети запрашивает сообщения с подтверждением предоставления услуги в одном или нескольких выделенных сообщениях для обслуживающей сети. В четвертом варианте осуществления изобретения среда HE запрашивает сообщения с подтверждением предоставления услуги от обслуживающей сети неявным образом, отвечая одним вектором аутентификации больше, чем запрашивалось.

Кроме того, устройству UE необходимо принять запрос для формирования сообщений с подтверждением предоставления услуги. Этот запрос может быть отправлен как дополнительная часть информации от оператора домашней сети или обслуживающей сети в процессе аутентификации, например, в сообщении с командой режима безопасности слоя, не связанного с доступом (NAS, Non-Access Stratum). В другом варианте осуществления изобретения сообщения с подтверждением предоставления услуги запрашиваются обслуживающей сетью от устройства UE в одном или нескольких выделенных сообщениях. В одном варианте осуществления изобретения обслуживающая сеть запрашивает сообщения с подтверждением предоставления услуги во время процедуры соединения, например, во время процесса аутентификации или установки контекста безопасности. В другом варианте осуществления изобретения обслуживающая сеть запрашивает сообщения с подтверждением предоставления услуги для каждого канала во время процедуры установления канала. Для обслуживающей сети полезно запрашивать соответствующую периодичность формирования сообщений с подтверждением предоставления услуги в устройстве UE. В другом варианте осуществления изобретения устройство UE определяет периодичность на основе сохраненной информации о политике, предоставленной оператором домашней сети.

Вопрос о том, запрашивать ли сообщения с подтверждением предоставления услуги и с какой периодичностью запрашивать у устройства UE формирование сообщений с подтверждением предоставления услуги, остается на усмотрение оператора домашней сети. Это может определяться политикой для каждого абонента, политикой для каждого класса доступа или может зависеть от возможностей устройства UE. В одном варианте осуществления изобретения политика относительно сообщений с подтверждением предоставления услуги хранится в среде HE оператора домашней сети. В другом варианте осуществления изобретения политика относительно сообщений с подтверждением предоставления услуги является частью функции управления политикой и тарификации (PCCF, Policy Control and Charging Function).

Сообщения с подтверждением предоставления услуги, отправленные из устройства UE через гостевую сеть в домашнюю сеть, должны быть защищены от атак повторного воспроизведения (replay attacks). Это может обеспечиваться с помощью меток времени или с помощью присвоения сообщениям порядковых номеров или с помощью и того, и другого. Первое сообщение с подтверждением предоставления услуги может быть запрошено заранее, т.е. оно позволяет проверять настройку или прием конфигурации для настройки услуги без подтверждения значительного по объему предоставления услуги. Это первое сообщение с подтверждением предоставления услуги должно содержать метку времени или порядковый номер сообщения «1», и указание на то, когда можно ожидать второе сообщение с подтверждением предоставления услуги, например, через одну минуту или через 100 килобайтов данных при роуминге или в конце телефонного вызова. Начиная со второго сообщения с подтверждением предоставления услуги (для каждой услуги), сообщения могут содержать дополнительную информацию обратной связи за предыдущий период предоставления услуги, такую как качество голосового вызова за предыдущую минуту голосового вызова или скорость передачи данных последних 100 килобайтов данных при роуминге.

Ниже приведен пример такого сообщения с подтверждением предоставления услуги.

ID Ver SEQ TS P SID FB MAC

ID: идентификатор абонента, например, глобальный уникальный временный идентификатор (GUTI, Global Unique Temporary ID)

Ver: информация о версии протокола

SEQ: порядковый номер сообщения, например, длиной 16 битов

TS: метка времени

P: ожидаемая периодичность сообщений с подтверждением предоставления услуги для этой услуги

SID: идентификатор услуги, например, услуга с местным трафиком (local breakout data service), услуга голосового вызова, канальная сессия или PDU-сессия

FB: информация обратной связи для текущей услуги

MAC: код аутентификации сообщения для защиты целостности с общим сессионным ключом.

Приведенная в качестве примера схема потока сообщений представлена на фиг. 3. Пользователь включает свое устройство UE в зарубежной стане. На шаге 1 устройство UE находит во время процедуры регистрации обслуживающую сеть, с которой оператор домашней сети имеет соглашение о роуминге. Список разрешенных сетей, контролируемый оператором домашней сети, хранится в SIM-карте. На шаге 2 обслуживающая сеть запрашивает у оператора домашней сети вектор аутентификации для пользователя в роуминге. На шаге 3 объект MME обслуживающей сети запрашивает один или несколько векторов аутентификации (AV, Authentication Vector) из среды HE оператора домашней сети. На шаге 4 среда HE отвечает запрошенным вектором аутентификации и еще одним дополнительным вектором аутентификации. На шаге 5 объект MME в домашней сети передает сессионный ключ защиты целостности, полученный из дополнительного вектора AV, в функцию CGF. На шаге 6 обслуживающая сеть принимает два вектора AV. Один вектор AV - полный, как в известном уровне техники, а во втором векторе AV, согласно изобретению, отсутствует корневой ключ в иерархии сессионных ключей (по меньшей мере сессионный ключ защиты целостности). Получение дополнительного вектора аутентификации может неявно сигнализировать обслуживающей сети о том, что домашней сетью запрашиваются сообщения с подтверждением предоставления услуги. Этот запрос также может быть сделан явно в виде запроса на подтверждение предоставления услуги слоя NAS в сообщениях между объектом MME и средой HE в соответствии с документом 3GPP TS 33.401. Процедура соглашения AKA, выполняемая как часть процедуры аутентификации в известном уровне техники согласно документу TS 33.401, на чертежах не показана. Затем на шаге 7 обслуживающая сеть повторно выполняет процедуру соглашения AKA (или ее потенциального преемника - АКА*), при этом обслуживающая сеть сигнализирует устройству UE в сообщении с командой режима безопасности слоя NAS о том, что сессионный ключ защиты целостности этой дополнительной процедуры соглашения AKA должен использоваться для подписания сообщений с подтверждением предоставления услуги, и о том, что запрашиваются эти сообщения с подтверждением предоставления услуги. На шаге 8 устройство UE подтверждает этот запрос в сообщении о выполнении режима безопасности слоя NAS, направляемом в обслуживающую сеть. Ключ защиты целостности, полученный в результате повторного выполнения процедуры соглашения AKA, сохраняется в устройстве UE для формирования поля кода MAC в сообщении с подтверждением предоставления услуги.

Далее пользователь инициирует локально маршрутизируемый голосовой вызов и, следовательно, в устройстве UE формируется первое сообщение с подтверждением предоставления услуги и на шаге 9 сообщение с подтверждением предоставления услуги слоя NAS отправляется в объект MME обслуживающей сети. Первое сообщение с подтверждением предоставления услуги содержит идентификатор GUTI пользователя, порядковый номер сообщения «1», текущую метку времени, ожидаемую периодичность, равную одной минуте, идентификатор услуги местного голосового вызова, пустое поле информации обратной связи и действительный код аутентификации сообщения для первых семи полей сообщения.

На шаге 10 объект MME обслуживающей сети пересылает сообщение с подтверждением в функцию CDF. На шаге 11 функция CDF принимает сообщение о тарифицируемых событиях от функции CTF и формирует записи CDR, а также в соответствии с этим изобретением выполняет конкатенацию сообщения с подтверждением предоставления услуги с записями CDR. Сообщения с подтверждением предоставления услуги автономно формируются устройством UE, они не конфигурируются домашней сетью или гостевой сетью и не находятся под их влиянием. Полезно синхронизировать сообщение с подтверждением предоставления услуги с записями CDR так, чтобы каждая запись CDR подвергалась конкатенации с соответствующим сообщением с подтверждением предоставления услуги, но также возможно и решение без такой синхронизации. В этом случае одна запись CDR может содержать ноль, одно или несколько сообщений с подтверждением, в зависимости от доступности таких сообщений в записи CDR. Если в одной записи CDR содержится более одного сообщения с подтверждением предоставления услуги, могут проверяться некоторые предыдущие записи CDR, которые не содержали сообщений с подтверждением предоставления услуги.

На шаге 12 запись CDR (с конкатенированным сообщением с подтверждением предоставления услуги), созданная функцией CDF, немедленно передается в функцию CGF через опорную точку Ga. На шаге 13 функция CDF формирует тарификационное сообщение по процедуре TAP, содержащее сообщение с подтверждением предоставления услуги, которое через интерфейс CAMEL с использованием сигнализации SS7 передается в функцию CDF оператора домашней сети. На шаге 14 функция CDF оператора домашней сети, прежде чем продолжить процедуру тарификации, проверяет запрошенное сообщение с подтверждением предоставления услуги.

Альтернативным вариантом является формирование сообщения с подтверждением предоставления услуги, инициируемое гостевой сетью. Функция CDF или любой другой объект системы тарификации в гостевой сети может запросить устройство UE с помощью нового сообщения слоя NAS или с помощью новой информации в известном сообщении слоя NAS для формирования сообщения с подтверждением предоставления услуги, гарантируя таким образом, что каждое тарификационное сообщение по процедуре TAP содержит одно сообщение с подтверждением предоставления услуги, подтверждающее оказание тарифицируемой услуги. Поскольку устройство UE не контролирует время формирования сообщений с подтверждением предоставления услуги, то в этом альтернативным варианте сообщения могут не содержать информации об ожидаемом следующем сообщении с подтверждением предоставления услуги, т.е. информация о периодичности может отсутствовать.

Сообщения с подтверждением предоставления услуги могут быть сформированы в устройстве UE для проверки настройки или предоставления услуги в гостевой (роуминговой) сети. Сообщение с подтверждением предоставления услуги может содержать информацию для домашней сети о предоставлении услуги, относящуюся к настройке или к планированию услуги гостевой сетью, и подпись, подтверждающую эту информацию о предоставлении услуги.

В одном аспекте изобретение предусматривает передачу сообщения с подтверждением предоставления услуги в гостевую сеть для его передачи в домашнюю сеть в отношении тарификационной информации (записи CDR), направляемой из гостевой сети в домашнюю сеть, касающейся настраиваемой или планируемой услуги, подлежащей тарификации.

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

Изобретение относится к области аутентификации транзакции, выполняемой устройством (UE) пользователя мобильной связи, выполнившим процедуру соглашения об аутентификации и ключах между устройством UE и объектом управления мобильностью гостевой сети для установления контекста безопасности между устройством UE и гостевой сетью. Техническим результатом является реализация механизма, дающего оператору домашней сети большую степень контроля тарификации в роуминге по процедуре TAP за счет установления общего секретного ключа для устройства UE и оператора домашней сети и использование этого ключа для формирования сообщения с подтверждением предоставления услуги с защитой целостности. Для этого способ включает в себя отправку устройством UE в гостевую сеть сообщения с подтверждением предоставления услуги, подписанного устройством UE цифровой подписью с использованием ключа защиты целостности, используемого устройством UE и домашней сетью, и пересылку сообщения с подтверждением предоставления услуги из гостевой сети в домашнюю сеть. 8 з.п. ф-лы, 3 ил.

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

- отправку устройством UE в гостевую сеть сообщения с подтверждением предоставления услуги, подписанного устройством UE цифровой подписью с использованием ключа защиты целостности, используемого устройством UE и домашней сетью; и

- пересылку сообщения с подтверждением предоставления услуги из гостевой сети в домашнюю сеть.

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

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

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

5. Способ по любому из предыдущих пунктов, в котором сообщение с подтверждением предоставления услуги содержит метку времени и/или порядковый номер сообщения.

6. Способ по любому из предыдущих пунктов, в котором сообщение с подтверждением предоставления услуги передается в ответ на запрос.

7. Способ по п. 6, в котором запрос передается как часть сообщения слоя, не связанного с доступом.

8. Способ по любому из пп. 1-6, в котором сообщение с подтверждением предоставления услуги передается устройством UE автономно.

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