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

Формула изобретения

1. Способ извлечения данных, связанных с абонентом, при этом способ выполняется в сети (100) связи и содержит выполнение в первом GUP-сервере этапов, на которых:

- принимают (1010) входящий запрос на получение данных, связанных с абонентом, от потребителя (102) данных в первом домене (101) связи;

- определяют то, что часть запрошенных данных является мигрирующей (1020);

- получают местоположение абонента (1022);

- определяют то, что, по меньшей мере, часть данных находится во втором домене (109) связи посредством извлечения идентификации второго домена (1025) связи;

- используют идентификацию второго домена связи, чтобы определять адрес второго GUP-сервера (1028);

- передают (1030) исходящий запрос во второй GUP-сервер во втором домене связи на получение, по меньшей мере, части данных;

- принимают (1060) ответ от второго GUP-сервера, содержащий запрошенную, по меньшей мере, часть данных; и

- перенаправляют (1070) запрошенные данные потребителю данных.

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

3. Способ по пп.1 и 2, в котором идентификация второго домена связи основана на идентификационных данных зоны обслуживания, сохраненных в базе (113) данных абонентов первого домена связи.

4. Способ по п.2, в котором перед этапом определения выполняют этапы, на которых:

- подписываются на уведомления об изменениях идентификации второго домена (800) связи;

- принимают эти уведомления об изменениях (802, 806);

- сохраняют эти уведомления об изменениях (803, 807).

5. Способ по п.2, в котором перед этапом передачи исходящего запроса во второй GUP-сервер выполняют дополнительные этапы, на которых:

- сохраняют (930) соответствие между входящим запросом (910) и исходящим запросом (940);

- в исходящем запросе (940) вставляют идентификационные данные первого GUP;

и после этапа приема ответа (970) выполняют дополнительный этап, на котором:

- устанавливают соответствие данных в ответе принимаемому входящему запросу (980).

6. Способ по п.2, в котором этап передачи исходящего запроса во второй GUP-сервер (1030) включает в себя этап, на котором отправляют идентификатор потребителя данных.

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

8. Способ по п.2, в котором этап передачи исходящего запроса во второй GUP-сервер выполняется по 3GPP GUP Rg (103) или 3GPP GUP, Rp (105) или интерфейсу межсетевого взаимодействия Ri (111).

9. Способ по п.2, в котором абонент находится в роуминге в первой или второй сети.

10. Способ п.2, в котором абонент является абонентом сети связи, отличной от сети связи HGUP.

11. Домашний GUP-сервер (104) для извлечения данных, связанных с абонентом, содержащий процессор (503) и память (504), имеющий инструкции, доступные из упомянутой памяти и обрабатываемые посредством упомянутого процессора, отличающийся тем, что он содержит:

- интерфейс (103) для приема (210) входящего запроса на получение данных, связанных с абонентом, от потребителя (102) данных в первом домене (101) связи;

- память, содержащую функцию (501) междоменного прокси-сервера, выполненную с возможностью принимать запросы на получение данных, которые принадлежат абоненту, причем данные в настоящий момент обрабатываются посредством GUP-сервера в домене, отличном от домена GUP-сервера потребителя данных, для определения (220) того, что, по меньшей мере, часть данных находится во втором домене (109) связи, при этом функция (501) междоменного прокси-сервера дополнительно содержит функцию (620) верификации удаленных данных для анализа запроса на получение данных, чтобы определять, могут ли данные находиться в домене, отличном от домена GUP-сервера потребителя данных, выполненную с возможностью извлекать идентификацию второго домена связи и функцию поиска, привязывающую идентификацию второго домена связи к адресу гостевого GUP;

- интерфейс (103, 105, 111) для передачи (230) исходящего запроса во второй GUP-сервер во втором домене связи на получение, по меньшей мере, части данных;

- интерфейс (103, 105, 111) для приема (260) ответа от второго GUP-сервера, содержащего запрошенную, по меньшей мере, часть данных; и

- интерфейс (103) для перенаправления (270) запрошенных данных потребителю данных.

12. Домашний GUP-сервер по п.11, отличающийся тем, что он содержит интерфейс (111) межсетевого взаимодействия GUP-сервера, выполненный с возможностью передачи исходящего запроса и приема ответа от второго GUP-сервера.

13. Домашний GUP-сервер по п.11, отличающийся тем, что функция (620) верификации удаленных данных содержит базу (650) данных уведомлений для сохранения уведомлений об изменениях в местоположении пользовательских данных.

14. Домашний GUP-сервер по пп.11-13, отличающийся тем, что функция междоменного прокси-сервера содержит репозиторий (610) для хранения параметра и функцию (630) поиска адресов, чтобы привязывать параметр идентификационных данных домена к допустимому адресу удаленного GUP.

15. Домашний GUP-сервер по п.14, отличающийся тем, что он выполнен с возможностью выполнения, перед этапом передачи исходящего запроса во второй GUP-сервер, дополнительных этапов:

- сохранения (930) соответствия между входящим запросом (910) и исходящим запросом (940);

- в исходящем запросе (940) вставки идентификационных данных первого GUP;

- и после этапа приема ответа (970) выполнения дополнительного этапа:

- установления соответствия данных в ответе принимаемому входящему запросу (980).

Описание изобретения к патенту

Область техники, к которой относится изобретение

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

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

Цель задания универсального пользовательского профиля (GUP) 3GPP состоит в том, чтобы предоставлять средство разрешения согласованного использования связанной с пользователем информации, исходящей от различных сущностей.

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

В сценарии GUP существуют следующие роли: 3GPP GUP-серверы, развертываемые операторами, конечные пользователи имеют один GUP-сервер, связанный с их профилями, а потребители данных (т.е. приложения), которые должны обрабатывать/потреблять профили конечного пользователя, контактируют с 3GPP GUP-серверами.

3GPP GUP описывает два интерфейса, а именно Rg и Rp, где первый - это интерфейс, который должен использоваться посредством потребителей данных (т.е. приложений), тогда как второй - это внутренний интерфейс оператора, который должен использоваться посредством GUP-серверов для репозиториев данных. Оба интерфейса основаны на протоколе Liberty Alliance DST; см. "Liberty ID-WSF Data Services Template Specification", Liberty Alliance Project, http://www.projectliberty.org/specs/liberty-idwsf-dst-v2.0.pdf.

Информация, которая должна обрабатываться посредством 3GPP GUP-серверов (логическая модель данных), в настоящий момент не задана, за исключением незначительной части касательно IMS-данных в рамках HSS-узла.

Потенциально данные любого конечного пользователя (статические и динамические), которые могут быть интересны потребителям данных, могут быть выбраны посредством операторов, чтобы стать доступными через 3GPP GUP-серверы.

Универсальный пользовательский профиль 3GPP (GUP) дополнительно описывается в 3GPP TS 22.240 v6.5.0, "Service requirement for the 3GPP generic user profile (GUP); Stage 1 (Release 6)" http://www.3gpp.org/ftp/Specs/html-info/22240.htm.

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

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

Универсальный пользовательский профиль 3GPP допускает внутрисетевое использование (т.е. обмен данными между приложениями в сети мобильного оператора) и межсетевое использование (между сетью мобильного оператора и поставщиками расширенных услуг). Мобильные виртуальные операторы MVNO и гостевые сети трактуются как поставщики расширенных услуг на основе обмена GUP-данными с сетью мобильного оператора.

Для каждого пользователя существует один пользовательский профиль, который может состоять из нескольких "компонентов". Эти компоненты могут быть распределены в домашней сети и в среде поставщика расширенных услуг. 3GPP GUP-данные являются распределенными по своей природе и, следовательно, хранятся в домашней сети и в оборудовании поставщика расширенных услуг.

Проблема состоит в том, что 3GPP GUP-данные потенциально распределены в тех случаях, когда конечный пользователь является абонентом или находится в роуминге в другой сети. В этой ситуации GUP-сервер может предоставлять только статические и динамические данные, которые хранятся в его собственной сети.

В сценарии роуминга потребители данных (приложения), находящиеся в домашней PLMN (далее HPLMN) и готовые использовать динамические данные конечного пользователя в роуминге, должны всегда контактировать с GUP-сервером, который хранит данные для этого конечного пользователя. В этом сценарии имеет место то, что некоторые части профиля конечного пользователя могут быть извлечены только посредством контактирования с гостевой PLMN (далее VPLMN). В таком случае потребители данных (приложения) могут выполнять запрос GUP-серверу в HPLMN (т.е. к серверу, с которым приложение установило коммерческие отношения) на эти данные, но не разрешает GUP-серверу выполнение запросов к репозиториям данных (к примеру, VLR или SGSN в VPLMN) в другой сети (Rp, внутренний интерфейс оператора требует высоких уровней надежности).

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

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

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

Эта проблема разрешается посредством способа и устройства для извлечения данных, связанных с абонентом в сети связи, при этом первый GUP-сервер принимает входящий запрос на связанные с абонентом данные от потребителя данных в первом домене связи и определяет, что, по меньшей мере, часть данных находится во втором домене связи. Исходящий запрос на, по меньшей мере, часть данных затем передается во второй GUP-сервер во втором домене связи. Второй GUP-сервер далее извлекает запрошенные связанные с абонентом данные, по меньшей мере, из одного сетевого репозитория и передает ответ с запрошенными данными в первый GUP-сервер. Первый GUP-сервер принимает ответ от второго GUP-сервера, содержащий запрошенную, по меньшей мере, часть данных, и перенаправляет запрошенные данные потребителю данных.

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

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

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

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

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

В одном варианте осуществления передача исходящего запроса и прием ответа от второго GUP-сервера осуществляется по интерфейсу межсетевого взаимодействия GUP-серверов.

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

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

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

Фиг.1a - это блок-схема, показывающая эталонную архитектуру GUP согласно предшествующему уровню техники.

Фиг.1b - это сетевая схема, показывающая случаи использования, где изобретение полезно.

Фиг.1c - это блок-схема, показывающая эталонную архитектуру GUP для межсетевого взаимодействия GUP-сервера согласно изобретению.

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

Фиг.3 - это схема последовательности операций, показывающая вариант осуществления домашнего GUP-сервера.

Фиг.4 - это схема последовательности операций, показывающая вариант осуществления гостевого GUP-сервера.

Фиг.5 - это блок-схема, показывающая домашний GUP-сервер согласно варианту осуществления изобретения.

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

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

Фиг.7 - это схема последовательности сообщений, показывающая механизм для запуска IPF согласно одному варианту осуществления изобретения при использовании проверки состояния роуминга для релевантных динамических данных.

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

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

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

Подробное описание изобретения

Фиг.1a - это блок-схема, показывающая эталонную архитектуру GUP. Сеть 100 связи включает в себя, по меньшей мере, домашний домен 101 и гостевой домен 109.

Домашний GUP-сервер HGUP 104 является собственным GUP-сервером конечного пользователя A, находящимся в домашнем домене такого пользователя. Этот HGUP является сервером, развернутым посредством доменного оператора, с которым конечный пользователь установил коммерческие отношения.

Потребители 102 данных в домашнем домене функционально подключаются к HGUP по внешнему интерфейсу Rg 103.

GUP-сервер - это функциональная сущность, предоставляющая одну точку доступа к данным универсального пользовательского профиля конкретного абонента. Эти данные находятся в сетевых репозиториях 106 и могут быть как статическими данными 107, так и динамическими данными 108. GUP-серверы подключаются к репозиториям данных в том же домене с помощью внутренних интерфейсов оператора Rp 105.

HGUP 104 может получать пользовательские данные, такие как информация о местоположении, из базы данных абонентов SDB 113, такой как сервер собственных абонентов HSS, реестр собственных абонентов HLR или реестр гостевых абонентов VLR.

Ссылаясь на фиг.1b, изобретение предлагает определение новых механизмов в архитектуре 3GPP GUP, которые разрешают потребителю 102 данных, например, поставщику расширенных услуг, получать пользовательские данные (статические или динамические) 3GPP GUP-профиля независимо от местоположения конечного пользователя.

Примеры случаев использования, когда пользовательские данные находятся вне домашнего домена GUP-сервера

Первый пользователь A находится в первой позиции pos1 в своем домашнем домене 101, который является наземной мобильной сетью общего пользования PLMN1 151, но осуществляет доступ к услуге, которой нужны данные о пользователе B, где пользователь B является абонентом домена, отличного от PLMN1, к примеру PLMN2 152. Пользователь B может находиться в третьей позиции pos3 в PLMN2 или в роуминге в четвертой позиции pos4 в PLMN3 153.

Первый пользователь A находится в роуминге во второй позиции pos2 в гостевом домене 109, например PLMN2 152, и осуществляет доступ к услуге в своем домашнем домене 101, т.е. PLMN1 151, при этом услуге необходимы динамические данные от гостевой PLMN2.

Первый пользователь A находится в роуминге во второй позиции pos2 в гостевой PLMN2 и осуществляет доступ к услуге от потребителя 160 данных в гостевой PLMN2, которой необходимы статические данные от домашней PLMN1.

Примерами таких данных являются относящиеся к SGSN данные, недоступные в HLR, но находящиеся в гостевом SGSN: область маршрутизации, идентификация соты, возраст идентификации соты, код зоны обслуживания, возможность радиодоступа в MS, возможность организации сети MS, состояние PDP, используемой APN, используемого адреса GGSN, согласование QoS, идентификатор оплаты, используемый адрес RNC, запрет на сжатие рабочих данных, ограничение APN. Примерами относящихся к GGSN данных, когда находятся в VPLMN, являются используемые APN, согласование QoS и используемые адреса SGSN. Другими примерами являются релевантные динамические данные в гостевом домене (например, согласование QoS в v-SGSN/GGSN, идентификатор оплаты в v-SGSN/GGSN, TMSI и PTMSI в VLR, контактный IP/SIP-адрес конечного пользователя в v-P-CSCF и т.д.).

Фиг.1c - это блок-схема, показывающая эталонную архитектуру GUP для межсетевого взаимодействия GUP-сервера согласно изобретению. Как показано на фиг.1a, сеть 100 связи включает в себя, по меньшей мере, домашний домен 101 и гостевой домен 109. Когда пользователь находится в роуминге, интересующий пользовательский профиль для услуги распределен по различным доменам 101, 109. Согласно изобретению, гостевой GUP-сервер VGUP 110 является GUP-сервером, который временно обслуживает HGUP 104 от имени потребителей 102 данных (т.е. приложений), готовых запрашивать динамические данные, которые могут быть извлечены только из гостевого домена (т.е. оператора).

Интерфейс межсетевого взаимодействия Ri 111 используется для обмена данными с VGUP 110, чтобы иметь возможность осуществлять доступ к данным, находящимся в сетевом репозитории 112 в гостевом домене.

GUP-сервер обычно может функционировать и как HGUP, и как VGUP, поскольку он будет работать как HGUP-сервер для базы собственных абонентов, к примеру потребителей 160 данных, и как VGUP-сервер для пользователей, находящихся в роуминге в его домене.

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

На этапе 210 потребитель 102 данных, т.е. запрашивающий приложения/данные, выполняет запрос к HGUP 104, с которым имеет коммерческие отношения, на предмет пользовательских данных. Потребитель данных находится в домашнем домене 101 и обменивается данными с помощью интерфейса 103 Rg, как показано на фиг.1c. При приеме запроса GUP-сервер проверяет на этапе 220, находятся ли запрашиваемые пользовательские данные, к примеру динамические данные, такие как местоположение пользователя, в другой сети, например, вследствие нахождения конечного пользователя в роуминге или вследствие того, что конечный пользователь, данные которого запрашиваются, принадлежит другой сети. Если пользовательские данные находятся в другой сети, HGUP модифицирует входящее сообщение запроса и включает в него информацию для ответа, в том числе сетевой источник и адрес ответа, чтобы перенаправлять его VGUP. На этапе 230 сообщение перенаправляется в VGUP, в настоящий момент хранящий эти динамические данные, с помощью интерфейса 111 Ri.

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

На этапе 250 VGUP извлекает пользовательские данные из релевантного репозитория с использованием интерфейса 105 Rp по фиг.1c.

На этапе 260 ответ с пользовательскими данными отправляется обратно в HGUP по интерфейсу 111 Ri.

На этапе 270 ответ с пользовательскими данными отправляется обратно запрашивающему потребителю данных по интерфейсу 103 Rg.

Фиг.3 - это схема последовательности операций способа, показывающая вариант осуществления HGUP 104. HGUP, после запуска на этапе 300, принимает запрос от потребителя 102 данных, т.е. запрашивающего приложения/данные, на этапе 310. При приеме запроса GUP-сервер проверяет на этапе 320, находятся ли запрашиваемые пользовательские данные, к примеру динамические данные, такие как местоположение пользователя, в другой сети, например вследствие нахождения конечного пользователя в роуминге или вследствие того, что конечный пользователь, данные которого запрашиваются, принадлежит другой сети. HGUP также определяет местоположение пользовательских данных. Если они не находятся в другой сети, обработка заканчивается на этапе 340. Если пользовательские данные находятся в другой сети, HGUP модифицирует входящее сообщение запроса на этапе 330 и включает в него информацию для ответа, в том числе сетевой источник и адрес ответа, чтобы запрашивать данные от VGUP. На этапе 370 ответ с пользовательскими данными отправляется обратно запрашивающему потребителю данных перед завершением на этапе 380.

Фиг.4 - это схема последовательности операций способа, показывающая вариант осуществления VGUP 110. VGUP, после запуска на этапе 400, принимает запрос от HGUP на этапе 430. На этапе 440 VGUP обрабатывает запрос на получение данных. На этапе 450 VGUP извлекает пользовательские данные из релевантного репозитория(ев) и отвечает с пользовательскими данными для HGUP на этапе 460 перед завершением на этапе 470.

Фиг.5 показывает HGUP 104 согласно одному варианту осуществления изобретения, имеющий процессор 503 и память 504, имеет инструкции, доступные из памяти и обрабатываемые посредством упомянутого процессора. Функциональность междоменного прокси-сервера IPF 501 является функциональным блоком, загруженным в память, имеющим возможность принимать запросы на получение данных для данных, которые принадлежат конечному пользователю, причем эти данные в данный момент обрабатываются посредством GUP-сервера в домене, отличном от домена HGUP, например в гостевом домене 109. Память также содержит другие функции 502 GUP-сервера.

Фиг.6a - это блок-схема, показывающая функцию 501 междоменного прокси-сервера изобретения, имеющего возможность принимать запросы на получение данных для данных, которые принадлежат конечному пользователю HGUP, но при этом данные в настоящий момент обрабатываются посредством GUP-сервера, развернутого в гостевом домене/сети, в котором конечный пользователь находится в роуминге (т.е. VGUP).

IPF-репозиторий IPFR 610 является внутренним компонентом, обрабатывающим хранение релевантных параметров. Он должен обрабатывать, по меньшей мере, ResourceId, PLMN-Id, DataReference и унифицированный указатель ресурса VGUP URL.

IPFR доступен через интерфейс 615 с помощью, например, языка структурированных запросов URL или баз данных согласно облегченному протоколу доступа к каталогу LDAP.

IPF включает в себя функцию верификации удаленных данных RVF 620, которая является программным компонентом, отвечающим за анализ запрошенных данных, чтобы определять, могут ли они быть параметром, выделенным в домене, отличном от домена GUP-сервера, связанного с потребителем данных. Примерами являются гостевой домен для абонента в роуминге или то, что запрошенные данные касаются абонента, являющегося абонентом другого домена. RVF также определяет предмет запроса конечного пользователя. Чтобы выполнять эту функциональность, RVF использует входной параметр DataReference, содержащийся в первоначальном сообщении запроса Rg, как показано на этапе 710 фиг.7. Она также должна использовать информацию, содержащуюся в IPF-репозитории, а именно, предмет запроса и текущий PLMN-Id, местонахождения пользователя. Предметом запроса, т.е. идентификационными данными пользователя, является, например, ResourceId согласно терминологии http://www.3gpp.org/ftp/Specs/html-info/23240.htm.

Введение этих параметров в IPFR зависит от установленного механизма запуска IPF и может требовать дополнительного взаимодействия со стандартными функциональностями GUP, например запроса Rp к SDB, для получения информации о местоположении.

IPF также включает в себя функцию URL-указателя ULF 630, который является программным компонентом, который просматривает/привязывает параметр PLMN-Id, полученный от IPFR, к допустимому VGUP URL, т.е. адресу VGUP. Эта информация в качестве альтернативы также может быть извлечена непосредственно в RVF.

IPF дополнительно включает в себя компоновщик сообщений MB 640, который является программным компонентом, отвечающим за формирование сообщений Ri как между HGUP, так и между VGUP.

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

Фиг.7 описывает механизм для запуска IPF согласно одному варианту осуществления изобретения при использовании проверки состояния роуминга для релевантных динамических данных. В этом варианте осуществления, ссылаясь на фиг.1b и 1c, пользователь A находится в роуминге в местоположении pos2 гостевого домена 109, здесь PLMN2 152. На этапе 710 HGUP 104 принимает запрос на получение данных от потребителя 102 данных по интерфейсу Rg. Проверка осуществляется с использованием IPF 501 на этапе 720 на предмет того, ссылается ли запрос на динамические данные, которые являются мигрирующими, т.е. могут находиться в другой сети, как, к примеру, в гостевом домене 109 на фиг.1c. Если да, HGUP сверяется с SDB 113 на этапе 722 с помощью сообщений ReadData или Sh-Pull(LocationInformation) интерфейса Rp и принимает ответ на этапе 724 с релевантными информационными элементами. Это может быть, к примеру, идентификатор зоны обслуживания SAI, содержащийся в значении LocationInformation, сохраненном в SDB, чтобы узнавать идентификацию сети, в которой конечный пользователь в настоящий момент находится.

На этапе 726 ответ оценивается для анализа того, находится ли пользователь в роуминге, и если да, PLMN-Id привязывается к URL для рассматриваемого VGUP на этапе 728. На этапе 730 запрос на получение пользовательских данных отправляется в идентифицированный VGUP по интерфейсу Ri 111. На этапе 750 VGUP должен извлекать запрошенные данные из сетевого репозитория 112. На этапе 755 пользовательские данные отправляются в ответе обратно в VGUP, который должен обрабатывать и перенаправлять их в HGUP на этапе 760. На этапе 770 данные дополнительно перенаправляются запрашивающему потребителю данных.

Фиг.6b - это блок-схема, показывающая альтернативный вариант осуществления IPF 501. Этот вариант осуществления идентичен варианту осуществления по фиг.6a с отличием в том, что RVF 620 выполнена с возможностью осуществления подписки на уведомления об изменениях в местоположении пользовательских данных и принимать такие уведомления. Дополнительно, RVF включает в себя базу данных уведомлений NDB 650, выполненную с возможностью сохранять такие уведомления.

Фиг.8 - это схема последовательности сообщений, показывающая механизм для запуска IPF согласно варианту осуществления изобретения при использовании уведомления о состоянии роуминга. Также в этом варианте осуществления, ссылаясь на фиг.1b и 1c, пользователь A находится в роуминге в местоположении pos2 гостевого домена 109, здесь PLMN2 152.

Универсальная подписка выполняется посредством GUP-сервера на этапе 800 на уведомления об изменениях информационных элементов, которые предоставляют информацию роуминга. Эта подписка может быть сообщением Rp SubscribeToData или Sh-Subs-Notif(id). На этапе 802 ответ принимается посредством HGUP. Процесс подписки осуществляется только один раз для каждого абонента. На этапе 803 этот ответ сохраняется в NDB 650. Впоследствии, когда состояние роуминга пользователя изменяется, это обнаруживается на этапе 804, уведомление об этом отправляется от SDB на этапе 806 с помощью сообщения Rp NotifyData или Sh-Subs-Notif, и результат сохраняется/обновляется в NDB на этапе 807. Запрос на получение данных об этом пользователе A принимается на этапе 808 и автоматически запускает IPF 501. На этапе 810 посредством RVF осуществляется проверка того, являются ли данные мигрирующими и могут находиться в другой сети, к примеру, вследствие роуминга, и если утвердительно, HGUP должен проверять NDB 650 на этапе 812 на предмет того, находится ли пользователь действительно в роуминге. Если да, PLMN-Id привязывается к URL для рассматриваемого VGUP посредством ULF 630 на этапе 814. На этапе 816 запрос на получение пользовательских данных компилируется посредством MB 640, отправляется в идентифицированный VGUP по интерфейсу 111 Ri. На этапе 818 VGUP должен извлекать запрошенные пользовательские данные из сетевого репозитория 112 с помощью сообщения ReadData по интерфейсу Rp. На этапе 820 пользовательские данные посылаются в ответе обратно в VGUP, который должен обрабатывать и перенаправлять их в HGUP на этапе 822. На этапе 824 данные дополнительно перенаправляются запрашивающему потребителю данных.

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

На этапе 910 HGUP принимает запрос от приложения (запрашивающего данные).

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

На этапе 930 HGUP сохраняет, по меньшей мере, части первоначального запроса.

На этапе 940 HGUP удаляет информацию, которая идентифицирует потребителя данных как запрашивающего данные, и вставляет вместо этого собственный идентификатор приложения HGUP (это предполагает, что HGUP разрешен - т.е. коммерческие отношения, для запроса VGUP, существуют). Также точка доступа VGUP (т.е. URL) изменяется, и соответствие между первоначальным и новым запросом сохраняется. Модифицированный запрос затем отправляется в VGUP с помощью интерфейса Rg или интерфейса Rp.

На этапе 950 VGUP проверяет идентификационные данные потребителя данных, т.е. HGUP, и обрабатывает запрос, если запрашивающий HGUP - это HGUP, где соглашение существует. VGUP выбирает запрошенные данные на этапе 960 и отвечает в запрашивающий HGUP по интерфейсу Rg или интерфейсу Rp на этапе 970.

На этапе 980 при приеме ответа от VGUP HGUP привязывает ответ к первоначальному запросу и отвечает первоначальному приложению информацией, предоставленной посредством VGUP, на этапе 990.

Фиг.10 - это схема последовательности сообщений, более подробно описывающая вариант осуществления изобретения. Также в этом варианте осуществления, ссылаясь на фиг.1b и 1c, пользователь A находится в роуминге в местоположении pos2 гостевого домена 109, здесь PLMN2 152.

На этапе 1010 приложение, т.е. потребитель 102 данных, запрашивает GUP-сервер HGUP 104, с которым он установил коммерческие отношения. Запрос включает в себя идентификационные данные конечного пользователя, т.е. user_roaming@3gpp.org, и идентификационные данные потребителя данных, т.е. http://application.com.

При приеме сообщения HGUP-сервер должен проверять на этапе 1020, является ли запрошенная часть пользовательского профиля мигрирующей и может ли она находиться в другом домене. С этой целью он должен использовать RVF 620 в рамках IPF 501.

Если результат предыдущей проверки является положительным, т.е. параметр потенциально подлежит извлечению из другой сети, запрос к SDB выполняется на этапе 1022, чтобы получить местоположение пользователя. Этот запрос может осуществляться по-разному: с помощью интерфейса Rp GUP или существующего интерфейса Sh (HGUP, выступающий в качестве сервера приложений AS).

На этапе 1024 SDB отвечает в HGUP, предоставляя SAI или другую информацию о местоположении.

На этапе 1025 HGUP определяет на основе информации SAI домен (идентификатор PLMN), в котором пользователь в настоящий момент находится, который оказывается в роуминге в PLMN2.

На этапе 1026 HGUP проверяет, что идентифицированная PLMN - это PLMN, с которой существует действующее соглашение по роумингу.

После этого на этапе 1028 HGUP использует ULF 630 в рамках IPF для того, чтобы привязать PLMN-Id к допустимому URI VGUP, куда следует отправлять запрос.

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

Запрос включает в себя:

- данные запрашивающего, т.е. http://application.com, которые привязываются к атрибуту providerID протокола Liberty DST и идентифицируют приложение, фактически запрашивающее данные;

- атрибут RequestorGUPServerID должен быть включен в заголовок Provider, как указано в Liberty DST. RequestorGUPServerID идентифицирует промежуточную систему/прокси-сервер, т.е. HGUP URI, действующий от имени первоначального запрашивающего на получение данных, который помещает запросы в VGUP;

- идентификационные данные ресурса, т.е. user_roaming@3gpp.org, которые привязываются к атрибуту ResourceID протокола DST Liberty и идентифицируют конечного пользователя, данные которого запрашиваются;

- состояние роуминга конечного пользователя, на котором основан запрос. Информационный элемент состояния роуминга может быть реализован либо посредством модификации текущего типа ResourceIDType, либо посредством введения нового элемента RoamingStatus как части QueryType в Liberty DST. HGUP, перенаправляющий запросы в гостевые домены, должен включать в себя этот новый атрибут и должен задавать значение согласно следующему правилу: RoamingStatus="1", указывая то, что конечный пользователь, данные которого запрашиваются, находится в роуминге. VGUP-сервер должен обрабатывать входящий запрос, даже если он ссылается не на его конечного пользователя. RoamingStatus="0", указывая то, что конечный пользователь принадлежит VGUP-серверу. Это также разрешает мобильным операторам виртуальной сети (MVNO) с собственным развернутым GUP-сервером (выступающим в качестве HGUP) перенаправлять запросы в GUP-сервер, развернутый посредством сетевого оператора (выступающего в качестве VGUP). В этом случае использования атрибут RoamingStatus задан равным "1", чтобы указывать то, что конечный пользователь, данные которого запрашиваются, находится в роуминге.

Новый запрос на получение удаленных пользовательских данных отправляется в VGUP 110 по интерфейсу 111 Ri на этапе 1030.

На этапе 1031 VGUP принимает сообщение и проверяет наличие параметра RoamingStatus для различения того, как он должен обрабатывать входящий запрос. Его наличие указывает, что хотя запрос релевантен для конечного пользователя, который в принципе не принадлежит этой сети, запрос должен быть обработан вследствие нахождения в роуминге. VGUP также проверяет RequestorGUPServerID, чтобы узнавать, по какому URI релевантный ответ должен быть отправлен обратно.

На этапе 1050 VGUP извлекает пользовательские данные из релевантного сетевого репозитория 112 с помощью GUP Rp интерфейса 105.

На этапе 1055 соответствующий сетевой репозиторий отвечает с пользовательскими данными в VGUP.

VGUP отвечает с пользовательскими данными в HGUP на этапе 1060 на основе информации, предоставленной в RequestorGUPServerID, с релевантными данными.

На этапе 1065 HGUP обрабатывает ответ от VGUP и удаляет RequestorGUPServerID и RoamingStatus из заголовка сообщения.

На этапе 1070 HGUP отвечает потребителю 102 данных (т.е. приложению).