СИСТЕМА И СПОСОБ, ПРЕДНАЗНАЧЕННЫЕ ДЛЯ ОПЛАТЫ В ТЕЛЕКОММУНИКАЦИОННОЙ СЕТИ Российский патент 2005 года по МПК H04L29/06 H04Q7/30 H04M3/00 

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

Настоящее изобретение относится к оплате в телекоммуникационной сети.

Предшествующий уровень техники

Мобильная система связи третьего поколения называется в Европе UMTS (универсальная мобильная телекоммуникационная система). Она является частью системы IMT-2000 Международного союза электросвязи. UMTS/IMT-2000 является глобальной мультимедийной системой радиосвязи, которая обеспечивает более высокую скорость передачи (2 Мбит/сек), чем существующие мобильные сети.

UMTS и GPRS (общие услуги пакетной радиосвязи) в глобальной системе мобильной связи (GSM) разработаны для обеспечения услуг радиосвязи с коммутацией пакетов, а также с коммутацией каналов.

На Фиг.1 показана очень упрощенная схема сети UMTS. Изображены только те элементы сети, которые существенны для настоящего изобретения. Конечно, сеть может содержать один или более каждых сетевых элементов, описанных в дальнейшем, в зависимости от емкости элемента, числа мобильных абонентов и организации сети.

Пользовательские терминалы 100 могут быть многорежимными терминалами, которые могут работать с использованием, по меньшей мере, двух технологий доступа к радиосвязи, таких как, например, стандартов UMTS и GSM.

Шлюзовой узел поддержки GPRS (узел GGSN) 102 является шлюзом для внешних сетей, и он действует как маршрутизатор, направляющий пакеты данных в узел поддержки GPRS, обслуживающий в текущий момент данный терминал GPRS, и из этого узла.

Обслуживающий узел поддержки GPRS (узел SGSN) 101 находится на том же иерархическом уровне, что и центр коммутации мобильной связи (MSC). Он поддерживает информацию о местоположении терминала GPRS в его зоне обслуживания и выполняет функции обеспечения защищенности и управления доступом пользователя. Во время передачи данных обслуживающий узел поддержки GPRS посылает пакеты данных в конкретный терминал и принимает пакеты данных из этого терминала через подсистему базовой станции. Обслуживающий узел поддержки GPRS запрашивает информацию маршрутизации и абонентскую информацию из регистра 103 исходного местонахождения (HLR), где постоянно запоминается вся абонентская информация.

Спецификация UMTS позволяет абоненту сети иметь один или более адресов протокола пакетных данных (PDP). Каждый из адресов описан с помощью одного или более контекстов протокола пакетных данных в пользовательском терминале, обслуживающем узле поддержки GPRS и шлюзовом узле поддержки GPRS. Контекст протокола пакетных данных может быть избирательно и независимо активизирован, модифицирован и деактивизирован. Все контексты протокола пакетных данных пользователя связаны с одним и тем же контекстом управления мобильностью (ММ) для международного идентификационного кода абонента мобильной станции (IMSI) этого абонента. Когда протокол пакетных данных установлен, это значит, что установлен канал связи.

На фиг.1 обслуживающий узел поддержки GPRS и шлюзовой узел поддержки GPRS расположены в одном и том же домене А. Когда должно быть установлено соединение между абонентом и, например, Интернет 108, первый этап заключается в том, что мобильный терминал 100 посылает запрос активного контекста протокола пакетных данных через сеть 106 доступа к радиосвязи (RAN) в обслуживающий узел 101 поддержки GPRS. Сообщение включает в себя множество параметров, которые дополнительно включают в себя адрес протокола пакетных данных и имя точки доступа (APN). Имя точки доступа является логическим именем, относящимся к используемому шлюзовому узлу поддержки GPRS. В настоящем описании имя точки доступа относится к шлюзовому узлу 102 поддержки GPRS, через который пакеты данных маршрутизируются между мобильным терминалом и Интернет. Различные сообщения посылаются между упомянутыми элементами сети перед тем, как завершится соединение.

Сбор подробных данных события (вызова/сеанса) всегда используется, когда требуется определенная подробная информация о событии (вызове/сеансе) для составления счетов или для контроля детальных особенностей события (вызова/сеанса). Таким образом, каждый из сетевых элементов собирает данные, относящиеся к каждому вызову/сеансу до тех пор, пока не будет достигнут определенный заранее установленный предел. Пределом являются определенное количество данных, времени или другие определяемые величины сигнала запуска, например мегабайт. Затем сетевой элемент генерирует подробную запись события и посылает ее с использованием активного протокола через сеть 107 протокола Интернет (IP) в функцию 104 шлюза оплаты (CGF1). Обычно, по меньшей мере, следующие сетевые элементы генерируют подробные записи вызова события: обслуживающий узел поддержки GPRS, шлюзовой узел поддержки GPRS, функция управления состоянием вызова (CSCF) и сервер (серверы) приложений в сетях доступа к радиосвязи, таких как сеть доступа к GPRS (GERAN) или наземная сеть доступа к UMTS (UTRAN), причем последняя является широкополосной сетью множественного доступа к радиосвязи, описанной в настоящее время в документе 3GPP (проект партнерства третьего поколения). Обычно во время одного сеанса каждый из упомянутых элементов сети генерирует ряд подробных записей вызова события, относящихся к сеансу.

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

Возникает ряд проблем, если способ, описанный выше, используется как таковой в последней версии мобильной системы связи третьего поколения. Некоторые из проблем кратко описаны в дальнейшем со ссылкой на фиг.1b.

Несколько миллионов подробных записей событий постоянно генерируются в каждом из элементов сети, таких как обслуживающий узел 101 поддержки GPRS, шлюзовой узел 102 поддержки GPRS, функция 109 управления состоянием вызова CSCF, сервер 110 приложений или некоторые другие сетевые элементы N 111. Затем каждый из сетевых элементов независимо передает подробные записи вызовов в функцию 112 шлюза оплаты CGF1-CGFN. Проблема заключается в том, что в настоящее время нет механизма, который мог бы автоматически в реальном времени централизовать непосредственно все подробные записи событий, относящиеся к одному сеансу, для определенной функции шлюза оплаты (например, CGF1) в сети/домене, представляющем интерес. Наоборот, подробные записи событий направляются в большое число различных функций шлюза оплаты. Это приводит к проблеме, заключающейся в том, как объединить эти подробные записи событий, относящиеся к одному и тому же сеансу/вызову. Одним из решений является использование автономного устройства, так называемого, медиатор, для сбора и объединения подробных записей событий перед посылкой их для дополнительной обработки в центр 106 составления счетов. Объединение подробных записей событий в медиаторе является достаточно сложным и требующим много времени.

Одним из решений является использование уникального идентификатора сеанса для объединения корректных подробных записей событий. Этот тип решения описан в предыдущей патентной заявке США 09/577152 того же заявителя, которая не была опубликована к дате регистрации настоящей заявки. Идентификатор называется глобальным ИД транзакции (уникальный идентификатор сеанса).

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

Сущность изобретения

Настоящее изобретение относится, в целом, к сбору и управлению подробными записями событий (ПЗС) (относящимся к оплате, контролю, законному прослушиванию и т.д.) в телекоммуникационной сети и, конкретно, к отсроченной и предварительно выполненной оплате на основании подробных записей событий в мобильной сети связи третьего поколения.

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

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

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

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

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

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

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

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

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

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

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

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

Предложенное решение является динамическим и упрощает передачу подробных записей событий в сети независимо от того, находятся ли сетевые объекты в одних и тех же или разных сетях/доменах.

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

Изобретение описано более подробно со ссылками на чертежи, на которых представлено следующее:

фиг.1а - упрощенная схема мобильной системы связи третьего поколения;

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

фиг.2 - блок-схема примера реализации способа в соответствии с изобретением;

фиг.3 - диаграмма сигнализации, изображающая пример установки основного соединения;

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

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

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

Подробное описание предпочтительного варианта осуществления

В дальнейшем описаны динамический сбор и управление в реальном времени подробными записями событий в мобильной системе связи третьего поколения или сети ALL-IP (версия 5 3GPP). Однако понятно, что изобретение не ограничено сетями ALL-IP UMTS, но также может быть применено в любом типе сети, где имеется потребность использовать динамический сбор и управление в реальном времени подробными записями событий.

Идеей, описанного ниже способа, является сконцентрировать передачу подробных записей событий, созданных в различных сетевых элементах телекоммуникационной сети, в определенном сетевом объекте, осуществляющем сбор данных. Далее подробные записи событий будут также называться ПЗС, обслуживающий узел поддержки услуг GPRS будет называться ОУПУ, шлюзовой узел поддержки услуг GPRS будет называться ШУПУ, функция шлюза оплаты будет называться ФШО, сервер приложения будет называться СП и функция управления состоянием вызова будет называться либо ФУСВ, либо СОВ (сервер обработки вызова).

Изобретение теперь описано подробно с помощью некоторых примеров со ссылкой на фиг.2-6. В следующих примерах данные событий являются данными оплаты, а сетевые объекты являются сетевыми элементами.

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

Для решения проблемы объединения данных оплаты, требующего много времени, и излишней передачи подробных записей событий между различными функциями шлюза оплаты каждый сетевой элемент в домене/сети посылает ПЗС, связанные с одним сеансом/вызовом, в одну и ту же ФШО. Таким образом, сетевые элементы ОУПУ 201, ШУПУ 202, сервер 203 приложения и СОВ 204 передают все ПЗС через интерфейс Ga в сети ALL-IP UMTS в ФШО 205.

Важно заметить, что это просто очень упрощенный пример. Глобально сеть UMTS содержит различные сетевые элементы, каждый из которых постоянно формирует миллионы подробных записей событий.

На фиг.3 в качестве примера рассмотрена установка речевого вызова. Диаграмма сигнализации изображает установку основного соединения в сети 3GPP версии 5. Сообщения сигнализации, упомянутые в настоящем описании, являются просто примерами, и могут также использоваться многие другие типы сообщений сигнализации. Этот пример указывает только один из возможных способов передачи адреса ФШО между сетевыми элементами, обменивающимися сообщениями сигнализации, относящимися к вызову/сеансу. Альтернативно пользовательский терминал также мог бы участвовать в процессе передачи уникального идентификатора сеанса и адреса ФШО.

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

Предполагается, что контекст протокола пакетных данных (PDP) активизирован. Как уже упомянуто выше, каждый контекст протокола пакетных данных может быть выборочно и независимо активизирован, модифицирован и деактивизирован.

Вызывающая сторона, мобильный абонент А, желает сделать речевой вызов вызываемой стороне, которая в этом конкретном примере может быть другим мобильным абонентом В. Несмотря на речевой вызов, соединение также может быть сеансом, т.е. от абонента на видеосервер, или сетевой игрой и т.д., в зависимости от пользовательского терминала и поставщиков услуг.

Пользовательский терминал посылает через обслуживающую сеть радиодоступа СР ОУПУ и ШУПУ и сообщение 300 ПРИГЛАШЕНИЕ в функцию управления состоянием вызова ФУСВ или, точнее, в уполномоченную функцию управления состоянием вызова У-ФУСВ.

Функция управления состоянием вызова ФУСВ может быть разделена на две логические части, т.е. ФУСВ может действовать как уполномоченная ФУСВ или обслуживающая ФУСВ (О-ФУСВ). ФУСВ управляет несколькими функциональными возможностями: действуя как первая точка входа, выполняет маршрутизацию входящих вызовов; она сообщает события вызовов для составления счетов, ревизии, прослушивания или других целей; она может обеспечить механизм запуска сервера; она принимает и обрабатывает регистрацию уровня приложения; она извещает базовый домен о первоначальном доступе пользователя (например, адрес передачи сигнала ФУСВ и ИД пользователя).

У-ФУСВ является первой контактной точкой для пользовательского терминала в мультимедийной подсистеме протокола Internet. Каждый пользовательский терминал всегда имеет уполномоченную ФУСВ, связанную с ним и расположенную в той же самой сети.

Сообщение 300 "ПРИГЛАШЕНИЕ" является запросом "Я желаю установить соединение речевого вызова с абонентом В". В ответ на принятое сообщение уполномоченная ФУСВ генерирует уникальный ИД вызова, идентифицирует из конфигурированного списка шлюз оплаты, используемый в качестве первоначального шлюза оплаты, в который посылаются все ПЗС, сформированные во время вызова (этап 301). Эти два уникальных параметра запоминаются в памяти, и параметры также добавляются к принятому сообщению. ИД вызова доступен для ПЗС мультимедийной подсистемы базовой сети IP.

С этого момента упомянутый шлюз оплаты должен вызываться по имени предложенной функции шлюза оплаты, предложенной ФШО, или предложенного адреса ФШО IРv6 (IРv6 = версия 6 протокола Internet).

На этапе 302 У-ФУСВ посылает сообщение приглашения протокола SIP, включая ИД вызова и адрес IPv6 предложенного шлюза оплаты в О-ФУСВ, где обрабатываются состояния вызова/сеанса. Затем У-ФУСВ начинает устанавливать соединение вызова. ИД вызова доступен для ПЗС мультимедийной подсистемы базовой сети IP.

Протокол инициализации сеанса (SIP) является протоколом сигнализации уровня приложения для установления сеансов в сети IP. Сеанс может быть простым двусторонним телефонным вызовом или сеансом коллективной мультимедийной конференции. SIP является протоколом для создания, модифицирования и завершения сеансов с одним или более участниками. Он также поддерживает мобильность пользователя и переадресует запросы в текущее местоположение пользователя.

У-ФУСВ анализирует адрес назначения и определяет, относится ли абонент к оператору той же самой или другой сети. У-ФУСВ также проверяет, соответствует ли предложенный адрес ФШО первоначальному адресу ФШО в конфигурированном списке адресов ФШО. Если результат сравнения положителен, т.е. адреса являются одинаковыми, все ПЗС, созданные в У-ФУСВ, относящейся к этому конкретному вызову, будут переданы на предложенный адрес ФШО. Предложенный адрес ФШО включен в сообщения между различными сетевыми элементами, относящимися к этому конкретному вызову, в начале и во время фазы установки вызова. Проверка предложенного адреса ФШО из конфигурированного списка ФШО повторяется с этого момента каждым сетевым элементом, принимающим сообщения, относящиеся к этому вызову.

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

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

Затем на этапе 303 посылается сообщение "ПРИГЛАШЕНИЕ" протокола SIP вместе с ИД вызова и адресом IPv6 предложенного шлюза оплаты из У-ФУСВ в сервер приложения. ИД вызова доступен для ПЗС сервера приложения. Сервер приложения подтверждает принятое сообщение с помощью посылки сообщения 304 ОТВЕТ в У-ФУСВ.

В ответ У-ФУСВ посылает сообщение 305 "ПРИГЛАШЕНИЕ" протокола SIP, включающее в себя ИД вызова и адрес IРv6 предложенного шлюза оплаты, во взаимосвязанную ФУСВ (У-ФУСВ). У-ФУСВ является точкой контакта в сети оператора для всех соединений, направленных абоненту этого оператора сети. ИД вызова доступен для ПЗС мультимедийной подсистемы базовой сети IP.

Первым заданием является определить, где находится вызываемый абонент и является ли мобильный терминал абонента свободным для принятия речевого вызова.

Когда местоположение мобильного терминала стало известным и он свободен для приема вызова, сообщение 306 "ПОДТВЕРЖДЕНИЕ", информирующее о том, что соединение может быть установлено, посылается из сетевого элемента, такого как У-ФУСВ, расположенного в сети некоторого другого оператора. Сообщение посылается через ФУСВ, ШУПУ и ОУПУ в пользовательский терминал абонента А.

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

На этапе 307 пользовательский терминал посылает в ФУСВ сообщение "ЗАПРОС-активизировать вторичный контекст протокола PDP", и ФУСВ передает сообщение 308 "ЗАПРОС-создать контекст протокола PDP" в ШУПУ. В ответ на принятое сообщение ШУПУ генерирует ИД оплаты, который доступен для ОУПУ и ПЗС ШУПУ. После этого ШУПУ посылает сообщение 309 "ЗАПРОС-аутентификация" в У-ФУСВ, которое может основываться, например, на сообщениях протокола COPS (протокол стратегии общих открытых услуг).

Функция управления стратегией является логическим элементом, и она контролирует, каким пакетам разрешено проходить через ШУПУ. В ответ на сообщение У-ФУСВ информирует ШУПУ о своем решении относительно разрешения активизации контекста протокола PDP с помощью посылки сообщения 310 "РЕШЕНИЕ", включающего в себя ИД вызова и адрес IРv6 предложенного шлюза оплаты. Этот ИД вызова доступен для ПЗС СО (сервер обработки).

Следующий этап заключается в том, что ШУПУ отвечает ОУПУ сообщением 311 "ОТВЕТ-создать контекст протокола PDP", включающим в себя ИД вызова, ИД оплаты и адрес IРv6 предложеного шлюза оплаты. ИД вызова и ИД оплаты доступны для ПЗС СО. На этапе 312 ОУПУ посылает сообщение "ПРИЕМ-активизировать вторичный контекст протокола PDP" в пользовательский терминал.

Все ПЗС, относящиеся к этому вызову, посылаются автоматически из каждого из сетевых элементов, описанных выше, в предложенную ФШО.

В дальнейшем настоящее изобретение проиллюстрировано с помощью трех примеров со ссылкой на фиг.4-6.

Фиг.4 иллюстрирует процесс посылки уникального адреса шлюза оплаты, используемого в одном домене в мобильной системе связи третьего поколения. Уникальный ИД вызова также передается вместе с адресом шлюза оплаты, как описано выше.

Нумерация на фиг. 4 соответствует нумерации на фиг. 1, так что сетевые элементы и сети 100-108 соответствуют сетевым элементам и сетям 400-408. Регистр 403 исходных абонентских услуг расширен регистром исходного местонахождения.

Контекст протокола пакетных данных PDP активизируется, т.е. канал сигнализации создается между пользовательским терминалом 400 и функцией 409 управления состоянием вызова. Пользовательский терминал запросил установку соединения с вызываемым абонентом. Альтернативно абонентскому или пользовательскому терминалу может быть желательным соединиться с сервером приложения, который обслуживает мультимедиа, видео, игры и т.д. Сообщения сигнализации, необходимые, когда устанавливается соединение, посылаются через ОУПУ 401 и ШУПУ 402 в ФУСВ. ФУСВ анализирует содержание принятого сообщения, например запрос установки вызова, и выполняет действия, такие как передача запроса в ФУСВ, находящуюся в сети другого оператора. На фиг. 4 изображено, что каждый из сетевых элементов, т.е. ОУПУ 401, ШУПУ 402 и ФУСВ 409, имеет конфигурированный список адресов 410-412 функций шлюза оплаты. ФУСВ выбирает из списка 410 адрес функции шлюза оплаты ФШО1, используемый всеми сетевыми элементами, участвующими в данном сеансе. Предложенный адрес функции шлюза оплаты посылается вместе с сообщением в ОУПУ, который, в свою очередь, посылает его вместе с сообщением в ОУПУ. Передача сообщения и проверка предложенного адреса оплаты выполняется как описано выше. Списки в сетевых элементах соответствуют друг другу.

Фиг.5 также иллюстрирует процесс посылки уникального адреса шлюза оплаты в одном домене в мобильной системе связи третьего поколения. На чертеже контекст протокола пакетных данных ППД активизирован между пользовательским терминалом и приложением 500, и соединение между пользовательским терминалом и приложением установлено и активизировано. ФУСВ информирует приложение в сообщении (описанном на фиг.3) о предложенной ФШО, используемой во время соединения. Сообщения между ФУСВ и приложением посылаются на уровне приложения.

Фиг.6 иллюстрирует процесс посылки уникального адреса шлюза оплаты в двух доменах сети третьего поколения.

Оператор А владеет сетью в домене А, а оператор В владеет сетью в домене В. Конфигурированные списки отличаются друг от друга в сетевых элементах разных владельцев сети. ФУСВ 409 предлагает адрес ФШО5 в ШУПУ 402, но ШУПУ не находит предложенного адреса из своего собственного списка. В этом случае ШУПУ выбирает из своего списка первичную функцию шлюза оплаты ФШО1, заменяет адрес ФШО5 ее адресом и передает сообщение в ШУПУ.

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

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

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

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

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

1. Способ сбора данных событий, относящихся к сеансу связи в сети, при котором соединения пользователя во время сеанса связи устанавливаются через ряд сетевых объектов, генерирующих данные событий и имеющих взаимное соединение сигнализации, отличающийся тем, что включает в себя следующие этапы, выполняемые в каждом из сетевых объектов, генерирующих данные событий, относящихся к соединению: запоминают множество адресов для сетевых объектов, осуществляющих сбор данных событий, выбирают один адрес из множества адресов во время установки соединения и посылают данные событий, генерируемые во время соединения, в сетевой объект, осуществляющий сбор данных событий, имеющий выбранный адрес.2. Способ по п.1, отличающийся тем, что адрес объекта, осуществляющего сбор данных, является универсально уникальным.3. Способ по п.2, отличающийся тем, что включает в себя следующие этапы, выполняемые во время установки соединения в сетевом объекте, генерирующем данные событий: принимают запрос установки сеанса связи/соединения и предлагают выбранный адрес в качестве предлагаемого адреса, по меньшей мере, другому сетевому объекту, генерирующему данные событий, путем вставки выбранного адреса в сообщение сигнализации.4. Способ по п.3, отличающийся тем, что универсально уникальный идентификатор, относящийся к упомянутому сеансу, вставляют в сообщение сигнализации.5. Способ по п.3 или 4, отличающийся тем, что включает в себя следующие этапы, выполняемые в другом сетевом объекте, генерирующем данные событий: принимают сообщение сигнализации, включающее в себя предлагаемый адрес, и сравнивают предлагаемый адрес, по меньшей мере, с первичным адресом из сохраненного множества адресов, при этом на упомянутом этапе выбора адресов выбранный адрес является предлагаемым адресом, если предлагаемый адрес найден в сохраненном множестве адресов, и выбранный адрес является адресом из сохраненного множества адресов, если предлагаемый адрес не найден в сохраненном множестве адресов. 6. Способ по п.5, отличающийся тем, что выбранный адрес является первичным адресом из сохраненного множества адресов, если предлагаемый адрес не найден в сохраненном множестве адресов.7. Способ по п.6, отличающийся тем, что включает в себя посылку сообщения сигнализации, содержащего выбранный адрес, по меньшей мере, следующему сетевому объекту.8. Способ по п.1, отличающийся тем, что включает в себя выбор следующего адреса из сохраненного множества адресов, если сетевой объект, осуществляющий сбор данных событий, не отвечает или не используется.9. Способ по п.1, отличающийся тем, что сетевые объекты являются сетевыми элементами.10. Способ по п.1, отличающийся тем, что включает в себя использование пользовательского терминала для пересылки выбранного адреса между сетевыми объектами, генерирующими данные событий.11. Способ по п.1, отличающийся тем, что содержимое множества адресов является идентичным, по меньшей мере, в сетевых объектах в одном и том же домене.12. Способ по п.1, отличающийся тем, что содержимое множества адресов является идентичным, по меньшей мере, в сетевых объектах в одной и той же сети.13. Способ по п.1, отличающийся тем, что сохраненное множество адресов объектов сети, генерирующих данные событий, представляют в виде таблицы.14. Способ по п.1, отличающийся тем, что данные событий включают в себя данные оплаты.15. Система связи, содержащая, по меньшей мере, сетевые объекты маршрутизации, сетевые объекты, генерирующие данные событий, и сетевые объекты, осуществляющие сбор данных событий, отличающаяся тем, что каждый из сетевых объектов, генерирующих данные событий, содержит средство памяти для хранения множества адресов сетевых объектов, осуществляющих сбор данных событий, средство выбора, предназначенное для выбора из множества адресов одного адреса сетевого объекта, осуществляющего сбор данных, средство сигнализации, предназначенное для передачи сигнализации о выбранном адресе в качестве предлагаемого адреса между сетевыми объектами, генерирующими данные событий, средство посылки, предназначенное для посылки данных событий, генерированных во время сеанса, в адрес, выбранный средством выбора.16. Система связи по п.15, отличающаяся тем, что сетевые объекты, генерирующие данные событий, содержат средство сравнения для сравнения предлагаемого адреса с множеством адресов в средстве памяти, а средство выбора выполнено с возможностью выбора предлагаемого адреса, если предлагаемый адрес найден в сохраненном множестве адресов, и адреса из сохраненного множества адресов, если предлагаемый адрес не найден в сохраненном множестве адресов.17. Система связи по п.16, отличающаяся тем, что средство выбора выполнено с возможностью выбора первичного адреса из сохраненного множества адресов в качестве выбранного адреса, если предлагаемый адрес не найден в сохраненном множестве адресов.18. Сетевой объект для системы связи, содержащий средство генерации, предназначенное для генерации данных событий, отличающийся тем, что сетевой объект дополнительно содержит средство памяти для хранения множества адресов сетевых объектов, осуществляющих сбор данных событий, средство выбора, предназначенное для выбора из множества адресов одного адреса сетевого объекта, осуществляющего сбор данных, средство сигнализации, предназначенное для передачи сигнализации о выбранном адресе в качестве предлагаемого адреса между сетевыми объектами, генерирующими данные событий, и средство посылки, предназначенное для посылки данных событий, генерированных во время сеанса, в адрес, выбранный средством выбора.19. Сетевой объект по п.18, отличающийся тем, что содержит средство сравнения для сравнения предлагаемого адреса с множеством адресов в средстве памяти, а средство выбора выполнено с возможностью выбора предлагаемого адреса, если предлагаемый адрес найден в сохраненном множестве адресов, и адреса из сохраненного множества адресов, если предлагаемый адрес не найден в сохраненном множестве адресов.20. Сетевой объект по п.19, отличающийся тем, что средство выбора выполнено с возможностью выбора первичного адреса из сохраненного множества адресов в качестве выбранного адреса, если предлагаемый адрес не найден в сохраненном множестве адресов.