записи вариантов в сетевых репозиториях данных

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

1. Способ доступа к данным в каталоге от имени запрашивающего объекта, содержащий этапы, на которых:

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

идентифицируют, посредством процессора, одно или более применимых правил из набора правил, ассоциированных с первой записью;

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

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

- выполняют, посредством процессора, действие с данными в извлеченном втором местоположении.

2. Способ по п.1, в котором каталог постоянно размещается на множестве серверов каталогов и в котором извлечение второго местоположения в каталоге дополнительно содержит этап, на котором:

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

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

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

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

- выполняют действие над данными в извлеченном четвертом местоположении.

4. Способ по п.3, в котором третья запись равняется первой записи, а третье местоположение равняется первому местоположению.

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

- выполняют действие над данными в другом атрибуте первой записи;

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

6. Способ по п.5, в котором сообщение сконфигурировано так, что запрашивающий объект не принимает информацию об извлеченном втором местоположении.

7. Способ по п.1, дополнительно содержащий этап, на котором:

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

8. Способ по п.1, в котором запрашивающий объект ожидает, что данные запроса данных имеют первый формат, и при этом данные во второй записи имеют второй формат, при этом способ дополнительно содержит этап, на котором:

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

9. Способ по п.8, дополнительно содержащий этап, на котором:

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

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

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

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

12. Способ по п.11, в котором индикатор в пределах другого атрибута идентифицирует то, что атрибутом является класс объектов варианта.

13. Способ по п.1, дополнительно содержащий этап, на котором:

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

14. Способ по п.1, дополнительно содержащий этапы, на которых:

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

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

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

- выполняют запрошенное действие над данными в извлеченном третьем местоположении; и

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

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

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

17. Способ по п.1, в котором механизм хранения данных постоянно размещается на сервере, который постоянно размещается в сети, содержащей множество многоуровневых серверов, при этом способ дополнительно содержит этап, на котором:

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

18. Способ по п.1, в котором запросы, чтобы выполнять действия, принимаются в соответствии, по меньшей мере, с одним из протоколов LDAP и DAP.

19. Способ по п.1, в котором сообщения в запрашивающий объект сконфигурированы в соответствии, по меньшей мере, с одним из протоколов LDAP и DAP.

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

21. Способ по п.20, в котором запрашивающий объект реализует клиентское приложение, содержащее одно из реестра исходного местоположения (HLR), сервера собственных абонентов (HSS), системы голосовой почты, системы аутентификации, авторизации и учета (ААА), переносимости мобильного номера (MNP), причем способ дополнительно содержит этап, на котором обмениваются данными с клиентским приложением с использованием собственного протокола данных для клиентского приложения.

22. Способ по п.1, в котором действием является одно из считывания или записи, причем способ дополнительно содержит этап, на котором выполняют действие.

23. Способ по п.1, дополнительно содержащий этапы, на которых:

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

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

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

- процессор, выполненный, по меньшей мере, частично в виде аппаратного обеспечения и содержащий

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

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

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

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

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

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

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

27. Система по п.26, в которой третья запись равняется первой записи, а третье местоположение равняется первому местоположению.

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

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

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

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

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

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

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

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

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

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

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

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

40. Система по п.24, в которой механизм хранения данных постоянно размещается на сервере, который постоянно размещается в сети, содержащей множество многоуровневых серверов, при этом система дополнительно содержит:

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

41. Система по п.24, в которой запросы, чтобы выполнять действия, принимаются в соответствии, по меньшей мере, с одним из протоколов LDAP и DAP, и при этом приемник запросов данных дополнительно выполнен с возможностью обрабатывать запросы, по меньшей мере, в одном из протоколов LDAP и DAP.

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

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

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

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

46. Система по п.24, дополнительно содержащая:

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

47. Система доступа к данным от имени запрашивающего объекта, содержащая:

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

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

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

49. Система по п.47, в которой сервер операций с каталогом дополнительно выполнен с возможностью:

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

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

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

- выполнять запрошенное действие над данными в извлеченном третьем местоположении; и

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

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

- выполнять другое запрошенное действие с данными другого атрибута; и

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

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

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

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

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

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

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

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

Операторы мобильной и стационарной сети хотят становиться полностью интегрированными поставщиками услуг связи (CSP). Постоянно меняющиеся бизнес-стратегии и реализация новых абонентских услуг привели к оперативным и функциональным хранилищам данных в пределах типичного CSP. Множество традиционных сетей связи основано на неструктурированной компиляции функциональных наложений на базовую сеть, которая создана главным образом для речевого трафика. Дублирование данных зачастую существует в базах данных абонентов, процессах создания и предоставления услуг, в администрировании, поддержке и оплате абонентских услуг.

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

Фиг. 1 иллюстрирует характерную сетевую архитектуру 100, используемую посредством CSP в предшествующем уровне техники. Сетевая архитектура 100 включает в себя систему функциональной поддержки (OSS)/систему поддержки бизнес-операций (BSS)/систему IT-домена 102, одно или более приложений, таких как приложения 106a-106c, и базовую сеть 108 передачи служебной информации. OSS/BSS-система/IT-домена 102 включает в себя систему 110 инициализации и систему 112 управления сетью. Приложения 106a-106c содержат логический модуль 107a и модуль 107b данных. Логический модуль 107a каждого приложения 106a-106c осуществляет доступ главным образом, если не исключительно, к соответствующему модулю 107b данных. Модуль 107b данных каждого приложения 106 типично постоянно размещается в базе данных некоторого типа, к примеру в реляционной базе данных. Приложения 106a-106c могут предоставлять, например, реестр исходного местоположения (HLR), сервер собственных абонентов (HSS), систему голосовой почты, систему аутентификации, авторизации и учета (AAA), переносимость мобильного номера (MNP) и т.п. Эти приложения известны в данной области техники.

По мере того как CSP добавляют дополнительные новые услуги в свои системы, такие как мультимедийная подсистема на базе IP-протокола (IMS) и нелицензируемый диапазон для мобильной связи (UMA), они могут обнаруживать, что универсальные технологии реляционных баз данных являются слишком сложными в реализации вследствие значительной настройки, возникающей в ходе развертывания. Впоследствии, по мере того как новые услуги и типы абонентов появляются, их соответствующие схемы могут быть слишком сложными в улучшении. Другими словами, по мере того как число приложений 106a-106c возрастает все в большей степени, CSP встречаются с все большим числом оперативных проблем, таких как масштабируемость, производительность и управление. Эти проблемы увеличивают затраты и приводят к функциональным простоям, дополнительно увеличивая затраты. Универсальные дисковые платформы зачастую оказываются сложными в масштабировании, поскольку базовая технология накладывает практические ограничения на время доступа.

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

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

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

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

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

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

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

Фиг. 1 иллюстрирует характерную сетевую архитектуру 100, используемую посредством CSP в предшествующем уровне техники;

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

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

Фиг. 4 предоставляет функциональное представление хранилища данных в сетевой архитектуре 400, согласно варианту осуществления изобретения;

Фиг. 5 иллюстрирует информационную базу 500 каталогов (DIB), согласно варианту осуществления изобретения;

Фиг. 6 иллюстрирует информационное дерево 600 каталогов (DIT), согласно варианту осуществления изобретения;

Фиг. 7A иллюстрирует агент 702 системы каталогов (DSA) и пользовательский агент службы 704 каталогов (DUA), согласно варианту осуществления изобретения;

Фиг. 7B иллюстрирует распределенную иерархию, содержащую три DSA 702a, 702b и 702c, согласно варианту осуществления изобретения;

Фиг. 8 иллюстрирует оптимизированную маршрутизацию в распределенной иерархии DSA, показанной на фиг. 7B, согласно варианту осуществления изобретения;

Фиг. 9A иллюстрирует DIT 900, имеющее запись-псевдоним 902, согласно варианту осуществления изобретения;

Фиг. 9B иллюстрирует модуль 903 маскировки псевдонимов, взаимодействующий с DIT 900, включающим в себя псевдоним 903, чтобы выполнять маскировку псевдонимов в запросе данных от запрашивающего объекта 920, согласно варианту осуществления изобретения;

Фиг. 10A иллюстрирует DIT 1000 с записью 1002 варианта, согласно варианту осуществления изобретения;

Фиг. 10B иллюстрирует обработку вариантов в DIT 1000, включающем в себя вариант 1002 запроса данных от запрашивающего объекта 1020, согласно варианту осуществления изобретения;

Фиг. 11A иллюстрирует модуль 1107 адаптации протоколов, согласно варианту осуществления изобретения;

Фиг. 11B иллюстрирует пример последовательной или не поддающейся распараллеливанию обработки адаптации протоколов, согласно варианту осуществления изобретения;

Фиг. 11C иллюстрирует модуль 1107 адаптации протоколов, по существу выступающий в качестве сервера виртуальных каталогов (или прокси-сервера LDAP/DAP), отправляющий обмен данными (к примеру, операции LDAP или DAP) на сервер 1109 операций с каталогом, такой как DS 706a, показанный на фиг. 7A, согласно альтернативному варианту осуществления изобретения;

Фиг. 11D иллюстрирует DIT 1100, имеющее конфигурацию адаптивного именования, предоставленную посредством адаптации протоколов, согласно варианту осуществления изобретения;

Фиг. 11E иллюстрирует DIT 1150, имеющее адаптацию атрибутов, предоставленную посредством адаптации протоколов, согласно варианту осуществления изобретения;

Фиг. 12 иллюстрирует систему управления доступом (AC), реализованную с помощью формы адаптации протоколов, согласно варианту осуществления изобретения;

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

Фиг. 13B иллюстрирует характерные компоненты, содержащие информационную систему мобильных абонентов, такую как проиллюстрированная на фиг. 13A, согласно варианту осуществления изобретения;

Фиг. 13C иллюстрирует характерные конфигурационные данные 1310 для DSA, участвующего в информационной системе мобильных абонентов, согласно варианту осуществления изобретения;

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

Фиг. 14 иллюстрирует систему 1400 протоколирования, согласно варианту осуществления изобретения;

Фиг. 15A является блок-схемой, иллюстрирующей иерархию данных, хранимых в каталоге 1500, таких как данные, используемые посредством HSS 301, показанного на фиг. 3, согласно варианту осуществления изобретения;

Фиг. 15B является блок-схемой, иллюстрирующей архитектуру HSS, такую как HSS 301 из CN 206, показанный на фиг. 3, согласно варианту осуществления изобретения;

Фиг. 16A и фиг. 16B являются блок-схемами, соответственно, иллюстрирующими совместно размещенную систему 1600 и совмещенную систему 1620 для HSS 301 и HLR 307, согласно варианту осуществления изобретения;

Фиг. 16C иллюстрирует внешнюю часть 1601, которая выполнена с возможностью хранить данные 1619 об услугах для приложений, таких как HSS 301 и HLR 307, согласно варианту осуществления изобретения;

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

Фиг. 18A иллюстрирует сеть 1800 связи, использующую точку высокоскоростного доступа (HSAP), которая, возможно, может извлекать выгоду из улучшенного механизма синхронизации, согласно варианту осуществления изобретения;

Фиг. 18B предоставляет физическое представление сети 1800 связи, показанной на фиг. 18A, которая может извлекать выгоду из улучшенного механизма синхронизации, согласно варианту осуществления изобретения;

Фиг. 18C показывает запись 1841 абонента из каталога, такого как каталог, сохраненный посредством DSA 1831, согласно варианту осуществления изобретения;

Фиг. 18D показывает таймер 1850, имеющий запись 1851 таймера в каталоге, сохраненном посредством DSA 1831, согласно варианту осуществления изобретения; и

Фиг. 18E иллюстрирует механизм распределенной синхронизации, реализованный в DSA 1831, показанном на фиг. 18B, согласно варианту осуществления изобретения.

Подробное описание

Обзор

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

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

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

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

Как упомянуто, варианты осуществления изобретения могут использовать базу данных единых логических каталогов, содержащую один источник информации об абонентах или об услугах, доступной посредством элементов контроля и управления, которым требуется эта информация. Предпочтительная база данных каталогов, используемая посредством варианта осуществления изобретения, совместима с протоколом X.500. База данных каталогов может предоставлять открытую централизованную базу данных в соответствии со стандартом ITU-T X.500 для информационной системы каталогов, согласно варианту осуществления изобретения. База данных каталогов типично включает в себя абонента, услугу и сетевые данные, а также выполнимые программные процедуры, которые становятся доступными для приложений через стандартные протоколы каталога, такие как облегченный протокол доступа к каталогам (LDAP) и протокол доступа к каталогам (DAP) и т.п., согласно варианту осуществления изобретения.

Ориентированная на абонентов сеть может предоставлять возможность внесения качественных улучшений в традиционные сетевые компоненты, такие как сервер собственных абонентов (HSS) и реестр исходного местоположения (HLR), а также оказывает помощь в развертывании услуг мультимедийной подсистемы на базе IP-протокола (IMS). Соответственно, варианты осуществления изобретения могут содержать улучшенный HSS и/или улучшенные подсистемы HLR.

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

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

Вариант осуществления изобретения может работать вместе с репозиторием данных определенного типа, к примеру базой данных. Как другие репозитории данных, репозитории данных, используемые в вариантах осуществления изобретения, типично обслуживаются посредством системы управления базами данных (DBMS). DBMS типично выполняет различные высокоуровневые и низкоуровневые функции. Изобретение, раскрытое и заявленное в данном документе, не включает в себя низкоуровневые функции, традиционно выполняемые посредством DBMS. Эти низкоуровневые функции включают в себя самые элементарные действия, такие как физический процесс приема фрагмента данных, определение конкретного сектора в конкретном запоминающем устройстве конкретного типа и последующее взаимодействие с аппаратными средствами запоминающего устройства, чтобы сохранять принимаемые данные. Высокоуровневые компоненты DBMS, раскрытые и заявленные в данном документе, могут взаимодействовать с множеством низкоуровневых компонентов DBMS. Один такой низкоуровневый компонент DBMS известен как DirecTree , высокопроизводительная низкоуровневая система баз данных в оперативной памяти от компании Apertio Limited, являющейся правопреемником изобретения, раскрытого в данном документе. Структура и операции DirecTree сохраняются как секрет фирмы Apertio Limited. Хотя варианты осуществления изобретения могут работать вместе с DirecTree , эта конкретная низкоуровневая DBMS не является частью изобретения, раскрытого и заявленного в данном документе.

Фиг. 2 является блок-схемой, иллюстрирующей систему 200 связи, в которой могут работать варианты осуществления изобретения. Система 200 связи может быть функционально классифицирована как система 202 стационарной связи и система 204 мобильной связи. Примеры системы 202 стационарной связи включают в себя телефонную коммутируемую сеть общего пользования (PSTN). Система 204 мобильной связи предоставляет услуги мобильной связи, такие как две стороны, обменивающиеся данными друг с другом через мобильные телефоны. Система 204 мобильной связи взаимодействует с системой 202 стационарной связи через функциональные интерфейсы 216, чтобы обеспечивать, помимо прочего, обмен данными между мобильными абонентами и стационарными абонентами.

Система 204 мобильной связи логически делится на базовую сеть (CN) 206 и сеть доступа (AN) 208. CN 206 типично содержит эти три домена: домен 210 с коммутацией каналов (CS), домен 212 с коммутацией пакетов (PS) и домен 214 мультимедийной подсистемы на базе IP-протокола (IMS). Эти домены типично отличаются способом, которым они поддерживают абонентский трафик, и содержат аппаратные и программные системы, которые совместно выполняют конкретную техническую функцию этого домена. Например, PS-домен 212 содержит программные и аппаратные системы, которые выполняют обмен данными с коммутацией пакетов, типично в соответствии с признанным стандартом передачи данных.

CS-домен 210 относится к аппаратным и программным компонентам, которые обеспечивают соединение с коммутацией каналов, которое поддерживает служебный и абонентский трафик. CS-соединение типично выделяет сетевые ресурсы во время установления соединения и высвобождает эти сетевые ресурсы при разрыве соединения. Компонентами, типично включенными в CS-домен 210, являются центр коммутации мобильной связи (MSC), шлюзовой MSC (GMSC), MSC-сервер, функция шлюза CS-среды (MGW CS), GMSC-сервер и функция межсетевого взаимодействия (IWF). CS-домен 210 и эти компоненты известны в данной области техники.

PS-домен 212 относится к аппаратным и программным компонентам, которые обеспечивают PS-соединение, которое поддерживает служебный и абонентский трафик. PS-соединение типично транспортирует данные абонентов с использованием автономной конкатенации битов, группируемых в пакеты, при этом каждый пакет может маршрутизироваться независимо от других пакетов. PS-домен 212 типично включает в себя компоненты, которые относятся к общей службе пакетной радиопередачи (GPRS), такие как обслуживающий узел поддержки GPRS (SGSN) и шлюзовой узел поддержки GPRS (GGSN). PS-домен 212 также типично включает в себя компонент для выполнения граничного шлюзового протокола (BGP). CS-домен 212 и эти компоненты известны в данной области техники.

IMS-домен 214 относится к компонентам, которые предоставляют мультимедийные IP-услуги, такие как аудио, видео, текст, чат и т.п., а также комбинации вышеозначенного, доставляемые по PS-домену 212. IMS-домен 214 типично включает в себя компоненты, такие как функция управления сеансами и вызовами (CSCF), функция управления шлюзом среды (MGCF) и функция шлюза среды (MGF), функция шлюза среды IMS (MGW IMS), контроллер функции мультимедийных ресурсов (MRFC), процессор функции мультимедийных ресурсов (MRFP), функция управления шлюзами коммутации (BGCF), сервер приложений (AS) и функция выбора политики (PDF). IMS-домен 214 и эти компоненты известны в данной области техники.

AN 208 типично содержит систему базовой станции (BSS), выполненную с возможностью предоставлять обмен данными в соответствии со стандартной системой связи, такой как глобальная система мобильной связи (GSM) и/или система радиосети (RNS) для универсальной системы мобильной связи (UMTS). Эти традиционные системы известны в данной области техники.

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

Как упомянуто выше, CS-домен 210 типично включает в себя MSC-область 313 и GSMC-область 315. MSC-область 313 предоставляет телефонную станцию для вызова с коммутацией каналов, управление мобильностью и другие услуги мобильным абонентам, передвигающимся в пределах области, обслуживаемой посредством MSC-области 313. Хотя одна MSC-область 313 показана на фиг. 3, CS-домен 210 вероятно должен содержать множество MSC-областей 313s во многих реализациях системы 202 мобильной связи. Помимо прочего, MSC-область 313 предоставляет функциональный интерфейс для установления вызова в CS-домене 210 между системой 202 стационарной связи и системой 204 мобильной связи в рамках плана единой нумерации и плана единой маршрутизации. GSMC-область 315 обнаруживает MSC-область 313, которая включает в себя абонента, к которому осуществляется вызов. Таким образом, MSC-область 313 маршрутизирует вызовы из системы 202 стационарной связи в систему 204 мобильной связи, а также маршрутизирует вызовы в рамках системы 204 мобильной связи.

Как упомянуто выше, PS-домен 212 типично включает в себя SGSN-область 317 и GGSN-область 319. SGSN-область 317 предоставляет функциональные интерфейсы в PS-домене 212 между системой 202 стационарной связи и системой 204 мобильной связи для установления вызова в рамках плана единой нумерации и плана единой маршрутизации. Таким образом, SGSN-область 317 выполняет межсетевое взаимодействие с радиосетью, используемой в системе 204 мобильной связи. GGSN-область 319 предоставляет шлюз между беспроводной сетью и другой сетью, такой как Интернет или частная сеть.

Как упомянуто выше, IMS-домен 214 включает в себя функцию управления сеансами и вызовами (CSCF) 321. CSCF 321 типично содержит серверы и связанные прокси-серверы, которые обрабатывают служебные пакеты в IMS-домене 214. CSCF 321 обрабатывает множество функций, таких как IMS-регистрация, анализ сообщений, аутентификация абонентов, управление политиками, управление полосой пропускания, регистрация сведений о начислении. CSCF 321 может использовать один или более стандартных протоколов при выполнении своих функций, таких как протокол Diameter.

CN 206 также типично включает в себя компоненты, которые взаимодействуют с различными доменами в рамках CN 206, такие как CS-домен 210, PS-домен 212 и IMS-домен 214. Эти компоненты, которые известны в данной области техники, содержат сервер собственных абонентов (HSS) 301, реестр гостевых абонентов (VLR) 303 и реестр идентификации оборудования (EIR) 305.

HSS 301 содержит приложение, отвечающее за сохранение информации, связанной с абонентами системы 204 мобильной связи, показанной на фиг. 2. Различные домены используют эту информацию в различных целях, например установление вызовов/сеансов от имени абонентов. Например, HSS 301 поддерживает процедуру маршрутизации посредством выполнения и/или обеспечения производительности таких этапов, как аутентификация, авторизация, учет (AAA), именование/преобразование адресов, зависимости местоположения.

Соответственно, HSS 301 типично сохраняет связанную с абонентом информацию, такую как идентификация абонента, нумерация и адресация, информация защиты абонента для управления доступом к сети для AAA, информация местоположения абонента и информация профиля абонентов. Традиционные идентификаторы абонента, сохраненные в HSS 301, могут включать в себя одно или более из следующего: международный идентификатор абонента мобильной связи (IMSI) 323, международный номер мобильной ISDN-станции (MSISDN) 325, конфиденциальные идентификационные данные 327 и общедоступные идентификационные данные 329. Варианты осуществления HSS 301 могут быть основаны на стандартах, таких как 3GPP-стандарт.

HSS 301 взаимодействует с этими тремя доменами (CS-домен 210, PS-домен 212 и IMS-домен 214) и влияет на функциональность этих доменов. Хотя только один HSS 301 показан на фиг. 3, типичная базовая сеть 206 может включать в себя несколько HSS. Развертывание нескольких HSS типично основано на различных факторах, таких как число абонентов, производительность аппаратных средств, используемых в системе 200 связи, и общая организация системы 200 связи.

HSS 301 может включать в себя такие приложения, как реестр исходного местоположения (HLR) 307, центр аутентификации (AuC) 309 и HSS, логический функциональный (LF HSS) модуль 311. Эти приложения известны в данной области техники.

HLR 307 содержит репозиторий данных, такой как каталог, который сохраняет информацию о местоположении для данного набора абонентов. Другими словами, абонент системы связи назначается для HLR 307 в целях регистрации, такой как информация об абонентах. HLR 307 типично предоставляет поддержку компонентов PS-домена 212, таких как SGSN-область 317 и GGSN-область 319, чтобы разрешать абонентам осуществлять доступ к услугам в рамках PS-домена 212. Аналогично, HLR 307 предоставляет поддержку компонентов CS-домен 210, таких как MSC-область 313 и область GMSC 315, чтобы разрешать доступ абонентов к услугам, предоставленным посредством CS-домена 210, и поддерживать услуги, такие как роуминг в рамках CS-домена 210. Хотя только один HLR 307 показан на фиг. 3, типичная базовая сеть 206 может включать в себя несколько HLR.

AuC 309 ассоциирован с HLR 307 и сохраняет ключ идентификации, такой как PrivateID 327, для каждого абонента, зарегистрированного в HLR 307. Этот ключ идентификации упрощает формирование данных безопасности для абонента, таких как PublicID 329. Помимо этого, AuC 309 может содержать информацию, связанную с аутентификацией IMSI 323 оборудования абонента и системы 204 мобильной связи. Дополнительно, AuC 309 включает в себя информацию, чтобы обеспечивать целостность и безопасность связи по радиотракту между мобильной станцией (MS) и системой 204 мобильной связи. Каждый AuC 309 типично обменивается данными только с ассоциированным HLR 307 по интерфейсу, обычно обозначаемому как H-интерфейс. HLR 307 запрашивает информацию от AuC 309 через H-интерфейс, сохраняет информацию и доставляет ее в соответствующие компоненты в базовой сети 206, как может потребоваться.

Модуль HSS-LF 311 включает в себя функциональные модули, которые предоставляют такие услуги, как управление мобильностью, поддержка установления сеанса, формирование информации защиты абонента, поддержка защиты абонента, обработка идентификации абонента, авторизация доступа, поддержка авторизации доступа и поддержка предоставления услуг.

VLR 303 типично управляет MSC-областью 313 в CS-домене 210 и эффективно управляет MS, передвигающимися в MSC-области 313. Когда MS "входит" в часть сети 204 мобильной связи, покрываемую посредством MSC-области 313, MSC-область 313 регистрирует MS в VLR 303. В процедуре регистрации MSC-область 313, управляющая данной частью сети 204 мобильной связи, обнаруживает MS и предоставляет информацию MS в VLR 303. Приняв информацию от MSC-области 313, VLR 303 проверяет состояние регистрации MS. Если MS не зарегистрирована в VLR 303, VLR 303 запрашивает HLR 307, чтобы предоставлять информацию, связанную с MS, чтобы упрощать надлежащее обслуживание вызовов, включающих в себя MS. VLR известны в данной области техники.

Информация, связанная с MS, к которой осуществляется доступ посредством VLR 303, типично включает в себя такие данные, как IMSI 323, MSISDN 325, роуминговый номер мобильной станции (MSRN), MSC-область 313, где MS зарегистрирована, идентификационные данные SGSN-области 317, где MS зарегистрирована (при этом мобильная сеть поддерживает GPRS и предоставляет интерфейс между VLR 303 и SGSN-областью 317). В варианте осуществления изобретения, VLR 303 может взаимодействовать с несколькими MSC-областями 313.

EIR 305 предоставляет логический объект, который отвечает за хранение международных идентификаторов мобильного оборудования (IMEI). Оборудование может быть классифицировано как "из белого списка", "из серого списка", "из черного списка" или оно может быть неизвестным. В традиционной CN 206, EIR 305 сохраняет, по меньшей мере, белый список.

Ориентированное на абонентов хранение данных

Фиг. 4 предоставляет функциональное представление хранения данных в сетевой архитектуре 400, согласно варианту осуществления изобретения. Сетевая архитектура 400 содержит систему функциональной поддержки (OSS)/систему поддержки бизнес-операций (BSS) 402, репозиторий 404 данных, одно или более приложений, таких как, например, приложения 406a-406e, и базовую сеть 408 передачи служебной информации.

OSS/BSS-система 402 включает в себя систему 410 инициализации и систему 412 управления сетью. OSS/BSS-система 402 содержит различные вычислительные системы, используемые посредством CSP. OSS/BSS-системы 402, включающие в себя систему 410 инициализации и систему 412 управления сетью, содержат "сетевые системы" сети мобильной связи, которые поддерживают такие процессы, как хранение сетевой учетной записи, предоставление услуг, конфигурирование компонентов сети и управление сбоями. BSS-системы содержат "системы бизнес-операций" для работы с абонентами, поддерживающие такие процессы, как принятие заказов, обработка счетов и сбор платежей.

Репозиторий 404 данных предоставляет централизованный домен данных, который поддерживает открытый доступ к данным, таким как данные об абонентах и услугах, посредством одного или более приложений, таких как приложения 406a, 406b, 406c, 406d и 406e, а также BSS/OSS-систем, таких как система 410 инициализации и системы 412 управления сетью, согласно варианту осуществления изобретения. Например, репозиторий 404 данных может включать в себя данные, хранимые для HSS, например данные, ассоциированные с HSS 301, показанным на фиг. 3, а также набор данных для всей сети 204 мобильной связи. Соответственно, приложения 406a-406e могут содержать HSS 301 и/или HLR 307, соответственно, согласно варианту осуществления изобретения. Приложения 406a-406e также могут включать в себя такие приложения, как система голосовой почты, система аутентификации, авторизации и учета (AAA), переносимость мобильного номера (MNP), согласно варианту осуществления изобретения. Эти приложения известны в данной области техники. Дополнительные приложения 406 также могут быть включены в сеть 400. Репозиторий 404 данных может быть выполнен как приложение работы с каталогами ITU-T X.500, согласно варианту осуществления изобретения.

В варианте осуществления изобретения, программная архитектура репозитория 404 данных предоставляет объект единого логического каталога. Каждый физический объект имеет доступ к каждой записи данных, предоставляя высокую надежность и производительность, согласно варианту осуществления изобретения. В различных вариантах осуществления изобретения, репозиторий 404 данных поддержки множества открытых интерфейсов, таких как протокол доступа к каталогам (DAP), облегченный протокол доступа к каталогам (LDAP), язык структурированных запросов (SQL), OBDC/JDBC и т.д. Эти открытые интерфейсы, которые известны в данной области техники, упрощают связывание данных, хранимых в репозитории 404 данных, с бизнес-приложениями, такими как системы управления взаимоотношениями с клиентами (CRM).

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

Фиг. 5 иллюстрирует информационную базу каталогов (DIB) 500, согласно варианту осуществления изобретения. Например, DIB 500 представляет структуру каталогов репозитория 404 данных, показанного на фиг. 4. DIB 500 включает в себя корень 502 и одну или более записей, таких как записи 504a, 504b, 504c, 504d и т.д. Записи 504a-504d в дальнейшем упоминаются как запись 504. Записи 504a-504d альтернативно могут упоминаться как "объекты". Каждая запись 504 в DIB 500 может включать в себя один или более атрибутов, например, запись 504c включает в себя атрибуты 506a, 506b, 506c, 506d и т.д. Атрибуты 506a-506d в дальнейшем упоминаются как атрибут 506. Каждый атрибут 506 может включать в себя тип 508 и одно или более значений 510. DIB 500 представляет набор данных, хранимых в каталоге. Например, DIB 500 может содержать данные, описывающие абонентов для сети связи, к примеру абонентов в сети 204 мобильной связи.

Фиг. 6 иллюстрирует информационное дерево каталогов (DIT) 600, согласно варианту осуществления изобретения. DIT 600 представляет структуру (схему) DIB 500, показанной на фиг. 5. DIT 600 включает в себя корневой узел 602 и записи 504, такие как записи 504a-504i и т.д. DIT 600 представляется здесь как иерархическая древовидная структура с корневым узлом 602 в основании. Каждый узел в дереве - это запись 504. Если DIT 600 структурировано так, чтобы придерживаться форматов различных стандартов, таких как стандарт X.500, то каждая запись 504 в DIB 500 уникально и однозначно идентифицируется посредством отличительного имени (DN). DN записи 504c, например, основано на DN вышестоящей записи, такой как запись 504a, в дополнение к конкретно идентифицированным атрибутам записи 504c (отличительным значениям). Отличительное значение и его ассоциированный тип также известны как относительное отличительное имя (RDN), которое уникально идентифицирует запись 504c относительно ее родителя, к примеру записи 504a. Следовательно, для описания RDN используются тип атрибута и отличительное значение записи 504c. Например, для записи 504a, если DN - это "c=UK", где "c" - это тип атрибута (сокращение от "страна"), а "UK" - это отличительное значение для записи, то для записи 504c с "o=MyCompany", где "o" - это тип атрибута (сокращение от "организации"), а "MyCompany" - это отличительное значение для записи, DN для 504c будет "o=MyCompany, c=UK" или "MyCompany. UK". DN аналогично URL, используемому во всемирной паутине.

Агенты системы каталогов - оптимизированная маршрутизация

Система 204 мобильной связи может содержать громадное количество абонентов. Например, некоторые системы связи содержат миллионы отдельных абонентов. Соответственно, хотя данные, ассоциированные с этими абонентами, могут логически представляться так, как показано в централизованном репозитории 404 данных по фиг. 4, физический вариант осуществления может заключаться в том, что данные секционируются на значимые подгруппировки, чтобы предоставлять большую скорость и полную отказоустойчивость для системы связи. Данные, например, могут быть сохранены и реплицированы в сети серверов, согласно варианту осуществления изобретения. В X.500 секционирование данных хранится (находится в распоряжении) посредством агента сервера каталогов (DSA).

Фиг. 7A иллюстрирует агента системы каталогов (DSA) 702 и пользовательского агента службы каталогов (DUA) 704, согласно варианту осуществления изобретения. DSA 702 включает в себя один или более серверов каталогов, таких как серверы 706a-706c каталогов и т.д. Каждый из одного или более серверов 706a-706c каталогов включает в себя репозиторий 708a-708c данных и т.д., в дальнейшем называемый репозиторием 708 данных, согласно варианту осуществления изобретения. Репозиторий 708 данных предпочтительно содержит базу данных в оперативной памяти. Серверы 706a-706c каталогов также включают в себя программное обеспечение сервера каталогов, такое как прикладное программное обеспечение 707a-707c сервера каталогов, согласно варианту осуществления изобретения.

DSA 702 выполнен с возможностью определять пропускную способность и нагрузку для каждого из своих соответствующих серверов 706a-706c каталогов, согласно варианту осуществления изобретения. DSA 702 также может обнаруживать, когда любой из серверов 706a-706c каталогов не обменивается данными, будь то вследствие запланированного технического обслуживания или вследствие сбоя связи, сбоя аппаратных средств или другого сбоя. Как показано на фиг. 7A, DSA 702 реализуется как кластер различных серверов каталогов, таких как серверы 706a-706c каталогов. Таким образом, DSA 702 может использовать свое знание состояния и пропускной способности серверов каталогов для того, чтобы быстро и эффективно обрабатывать запросы данных. В основном DSA 702 работает как более эффективный и более отказоустойчивый сервер каталогов, чем любой из серверов каталогов под его управлением, работающий автономно. Конечно, DSA 702 может реализовываться с большим или меньшим числом серверов 706 каталогов, чем показано на фиг. 7A. В варианте осуществления изобретения, каждый из серверов 706 каталогов выполняет одинаковые программные компоненты и сохраняет идентичную копию, по меньшей мере, части DIB 500 (показанной на фиг. 5) в репозитории 708 данных в оперативной памяти, за который отвечает DSA 702.

DUA 704 является традиционным термином для клиента служб каталогов, к примеру клиента LDAP или DAP. Например, DUA 704 осуществляет запросы данных как операции LDAP от имени различных клиентских приложений, согласно варианту осуществления изобретения. Как показано на фиг. 7B, типичное развертывание содержит несколько DSA 702. DUA 704 подключается к одному из DS 706 в одном из DSA 702. DSA 702 этого сервера может хранить данные, релевантные для запроса (при этом может обрабатывать запрос самостоятельно), или может иначе знать DSA 702, более приспособленный к тому, чтобы обрабатывать запрос. Во втором случае, DS 706 выбирает один из серверов 706 в этом альтернативном DSA 702 и перенаправлять запрос к нему (сцепление). Этот процесс также описывается в подразделе "Оптимальная маршрутизация" ниже.

Таким образом, DSA 702 определяет, какой сервер 706 каталогов должен отвечать на запрос данных. Операции DSA 702 и DS 706a-706c типично являются прозрачными для DUA 704. Соответственно, в различных вариантах осуществления изобретения, DUA 704 может подключаться к любому из серверов 706a-706c каталогов, чтобы извлекать идентичные данные. Если репозитории 708 данных DSA содержат только часть DIB 500, то полная DIB 500 может быть составлена с использованием одного или более дополнительных DSA, соответствующие репозитории 708 данных которых содержат другие части DIB 500. В этом варианте осуществления, в таком случае DSA 702 также требуется информация, чтобы помогать им выбирать соответствующий DSA 702 для данного действия.

Программное обеспечение, выполняющееся на серверах 706a-706c каталогов, содержит программное обеспечение 707a-707c сервера каталогов, согласно варианту осуществления изобретения. Программное обеспечение 707 сервера каталогов предоставляет распределенную инфраструктуру данных и программное обеспечение доступа к каталогам для серверов 706 каталогов. Как пояснено выше, низкоуровневые операции, выполняемые посредством репозиториев 708a-708c данных в оперативной памяти, не являются частью изобретения, раскрытого и заявленного в данном документе. Варианты осуществления изобретения могут быть выполнены с возможностью работать с различными низкоуровневыми программами репозитория данных.

Фиг. 7B иллюстрирует распределенную иерархию, содержащую три DSA 702a, 702b и 702c, согласно варианту осуществления изобретения. Эти DSA 702a-702c иллюстрируют, как данная DIB 500 может распределяться и реплицироваться для быстрого доступа в сети связи.

Например, DIT 600 может быть настолько большой, что ее следует рассредоточивать по нескольким DSA, к примеру DSA 702a-702c. HSS 301, например, не должен знать, насколько большим или небольшим является DIT 600 или на каком DSA сохраняется конкретный фрагмент данных. HSS 301, например, просто должен маршрутизировать свой запрос через DUA 704, который направляет запрос в DSA 702, который либо отвечает на запрос сам, либо обнаруживает DSA 702, который отвечает на запрос, согласно варианту осуществления изобретения.

Дополнительно допустим, что данная DIB 500 содержит данные, касающиеся абонентов в сети связи, включая соответствующие данные IMSI этих абонентов (уникальный номер, ассоциированный со всеми абонентами мобильных телефонов GSM- и UMTS-сети) и соответствующие данные MSISDN этих абонентов (фиксированное количество цифр, которое используется для того, чтобы ссылаться на конкретное мобильное устройство). Такая DIB 500 может развертываться в DSA 702a-702c следующим образом: данные абонента, такие как их имена и адреса, могут быть помещены в DSA 702a, который выступает в качестве корневого DSA. Соответствующие данные IMSI абонентов могут быть помещены в DSA 702b, который выступает в качестве IMSI-домена (такого как IMSI 323, показанный на фиг. 3) и соответствующие данные абонентов MSISDN могут быть помещены в DSA 702c, который выступает в качестве MSISDN-домена (такого как MSISDN 325, показанный на фиг. 3).

Таким образом, в этой примерной конфигурации, DSA 702a может выступать в качестве "корневого" DSA; DSA 702b может выступать в качестве DSA домена "IMSI", а DSA 702c может выступать в качестве DSA домена "MSISDN". Корневой DSA 702a включает в себя один или более серверов 706a-706c каталогов; сервер 702b домена "IMSI" включает в себя один или более серверов 706d-706f каталогов; и DSA 702c домена "MSISDN" включает в себя один или более серверов 706g-706i каталогов. Один или более серверов 706a-706i каталогов включают в себя программное обеспечение сервера каталогов, такое как программное обеспечение 707 сервера каталогов, показанное на фиг. 7A, и репозиторий данных, такой как репозиторий 708 данных, показанный на фиг. 7A, согласно варианту осуществления изобретения. Корневой DSA 702a сохраняет корневую запись; DSA 702b домена "IMSI" сохраняет связанные с IMSI данные, а DSA 702c домена "MSISDN" сохраняет связанные с MSISDN данные.

Таким образом, в различных вариантах осуществления изобретения, один или более DSA 702 могут быть реализованы вместе, чтобы сохранять DIB 500, такую как полная DIB для всей сети мобильной связи. Каждый DSA 702 типично отвечает за заданный поднабор данных, который содержит DIB 500. Таким образом, в примере выше, DUA 704 может подключаться к любому из доступных DSA 702, такому как корневой DSA 702a, DSA 702b домена "IMSI" и DSA 702c домена "MSISDN". Запрос от DUA 704 прозрачно обрабатывается посредством DSA, такого как, например, DSA 702b домена "IMSI", владеющего данными.

Оптимизированная маршрутизация

Фиг. 8 иллюстрирует оптимизированную маршрутизацию в распределенной иерархии DSA, показанных на фиг. 7B, согласно варианту осуществления изобретения. Как пояснено выше, DSA 702a-702c взаимодействуют, чтобы предоставлять распределенный каталог. Каждый DSA 702 хранит поднабор записей каталога в своем DS 706, наряду со знанием возможных местоположениях записей каталога, которые он не хранит. Как пояснено, DSA 702 может иметь возможность удовлетворять операции с каталогом локально, если она касается данных, обнаруженных в ее поднаборе каталога. В противном случае, DSA 702 (к примеру, DSA 702a) использует свое знание о каталоге для того, чтобы выбирать то, какой DSA (к примеру, DSA 702b) является оптимальным DSA, чтобы удовлетворять операции, и затем сцеплять операцию с другим DSA 702b.

Как пояснено выше, каждый DSA 702 реализуется как набор DS 706, каждый из которых типично хранит полностью реплицированную копию поднабора каталога. Таким образом, каждый из DS типично обрабатывает операцию с каталогом идентичным способом. В качестве части процесса сцепления, DS 706 первого DSA 702 должен выбирать DS 706 во втором DSA 702, чтобы принимать цепную операцию. Этот выбор традиционно реализует разделение нагрузки на основе циклического алгоритма или наименее используемого и может учитывать способность DS обрабатывать запрос. Например, если известно, что DS 706 имеет неполностью реплицированную версию каталога в результате более ранней проблемы, то он не выбирается.

Тем не менее, типичные физические реализации DS 706 таковы, что они являются географически распределенными. Кроме того, зачастую имеет место то, что на данном физическом узле (сайте) располагаются один или более DS для других DSA 702. Другими словами, DS 706 различных DSA 702 могут быть кластеризованы вместе при относительно близком физическом расположении и/или на расстоянии для поддержания связи.

Например, набор DSA 702, показанный на фиг. 8, физически размещается так, что DS 706a, DS 706d и DS 706g физически постоянно размещаются в узле 1 804a; DS 706b, DS 706e и DS 706h физически постоянно размещается в узле 2 804b, а DS 706c, DS 706f и DS 706i физически постоянно размещаются в узле 3 804c. Такое распределение предоставляет, помимо прочего, дополнительную способность сети связи противостоять ошибкам. Например, если возникает сбой питания в узле 1 804a, то операции могут равномерно продолжаться для DSA 702a-702c с использованием DS 706, обнаруженного в узле 2 804b и узле 3 804c.

Тракты связи (к примеру, WAN) от одного кластера DS (т.е. DS на одном узле) к другому кластеру DS типично имеют меньшую полосу пропускания и большее время задержки, чем обмен данными в рамках кластера DS (т.е. DS на одном узле). Другими словами, в общем, отнимает меньше времени для DS 706a то, чтобы обмениваться данными с DS 706d, чем для DS 706a то, чтобы обмениваться данными с DS 706e, поскольку как DS 706a, так и DS 706d находятся на одном узле, т.е. узле 1 804a.

При условии, что доступы данных распределяются по нагрузке по узлам DS, то выбор DS 706 для сцепления на основе физического местоположения этого DS 706 позволяет предоставлять оптимизированное использование обмена данными (к примеру, оптимальное использование WAN) и снижать времена отклика для операций с каталогом. Другими словами, DS 706a предпочтительно должен обмениваться данными с DS 706d, когда ему требуются данные, ассоциированные с DSA 702b, а не DS 706e или DS 706f, поскольку DS 706a и DS 706d находятся на одном узле, узле 1 704a. Конечно, если DS 706a требуются данные из DSA 702b, и DS 706d является недоступным, по любой причине, то DS 706a должен быть выполнен с возможностью сцепляться с DS 706e или DS 706f, которые также являются частью DSA 702b, но находятся в узле, отличном от DS 706a.

Агент 808 маршрутизации к узлу на DS 706 выполнен с возможностью определять, который второй DS 706 может выполнять данный запрос данных при наименьших затратах относительно набора других DS, согласно варианту осуществления изобретения. Агент 808 маршрутизации к узлу может быть выполнен с возможностью рассматривать расстояние между всеми возможными DS или данным поднабором DS. Например, может быть более неэффективным для агента маршрутизации к узлу в Великобритании вычислять расстояние до другого DS в Китае, когда DS зеркалирован на шести других узлах в Европе. Более простым подходом для агента 808 маршрутизации к узлу является то, чтобы вычислять периодически расстояние до других европейских узлов с правилом по умолчанию использовать узел в Китае, если другие европейские DS недоступны в какой-либо момент, согласно варианту осуществления изобретения.

Дополнительно, выбор агента 808 маршрутизации к узлу DS 706 может охватывать множество факторов, согласно варианту осуществления изобретения. Например, агент 808 маршрутизации к узлу может базировать свой выбор другого DS 706 с помощью ранжирования возможностей подключения между узлами (к примеру, узлов), при этом ранговые значения извлекаются из таких факторов, как полоса пропускания, время задержки и затраты. Допустим из примера выше, что DS 706a требует данных из DSA 702b, а DS 706d является недоступным. Дополнительно допустим, что узел 2 804b находится "значительно ближе" к узлу 1 804a, чем узел 3 804c - к узлу 1 804a, при этом "ближе" содержит составной показатель на основе, по меньшей мере, одного из полосы пропускания, времени задержки и затрат, к примеру наименьшая численная оценка для "полоса пропускания+время задержки+затраты". Соответственно, агент 808a маршрутизации к узлу может рекомендовать, чтобы DS 706a сцеплялся с DS 706e узла 2 804b. Если DS 706e является недоступным, то агент 808a маршрутизации к узлу может рекомендовать, чтобы DS 706a пытался завершать свою работу в DSA 702b с DS 706f узла 3 804c.

В еще одном дополнительном варианте осуществления изобретения, агент 808 маршрутизации к узлу может быть выполнен с возможностью динамического выбора DS 706. Например, допустим из примера, что устройство 806 дискретизации, ассоциированное с каждым из узлов, периодически отслеживает "расстояние" между узлом и любыми другими интересующими узлами. Например, модуль 806a дискретизации узла 1 804a может периодически отслеживать "расстояние" к узлу 2 804b, причем "расстояние" измеряется, по меньшей мере, посредством одного из полосы пропускания, времени задержки и затрат, к примеру наименьшая численная оценка для "полоса пропускания+время задержки+затраты". Модуль 806a дискретизации затем может делать результаты этого вычисления "расстояния" доступными для агентов 808a, 808d, 808g маршрутизации к узлу в узле 1 804a. Модуль 806a дискретизации сам может быть конфигурируемым с точки зрения того, как он измеряет "расстояние" и как часто он измеряет это расстояние. Дополнительно, модуль 806a дискретизации может базировать свое определение "расстояния" на фактических измерениях, таких как время отклика, принимаемых от DS 706 и сообщенных в модуль 806a дискретизации. Этот динамический подход принимает во внимание изменяющиеся характеристики сети и проблемы с данными DS или трактами связи. Альтернативно, модуль 806a дискретизации может находиться в рамках DS 706, к примеру в рамках самого агента 808 маршрутизации к узлу.

В еще одном дополнительном варианте осуществления изобретения, допустим, например, что агент 808 маршрутизации к узлу вычисляет "расстояние" или "близость" между двумя DS с точки зрения "затрат". Дополнительно допустим, что элементы затрат - это полоса пропускания, время задержки и стоимость доступа, согласно варианту осуществления изобретения. Конечно, другие компоненты могут содержать основные задающие компоненты затрат. Дополнительно допустим, что взвешенное уравнение затрат может быть выражено как формула, к примеру: (Вес1×полоса пропускания)+(Вес2×время задержки)+(Вес3×стоимость доступа). Агент 808 маршрутизации к узлу может быть выполнен с возможностью вычислять новые результаты для этого уравнения периодически, к примеру ежедневно, ежечасно, каждую минуту и т.д. Агент 808 маршрутизации к узлу затем может удостоверяться, что DS 706 сначала пытался выбирать DS 706 с наименьшими затратами, когда требовалось сцепление. Это, конечно, может означать DS, который не находится на том же узле. Альтернативно, модуль 806 дискретизации может выполнять эти уравнения и затем предоставлять результаты в релевантный набор агентов 808 маршрутизации к узлу, согласно варианту осуществления изобретения.

Псевдонимы и маскировка псевдонимов

Фиг. 9A иллюстрирует DIT 900, имеющее запись-псевдоним 902, согласно варианту осуществления изобретения. DIT 900 включает в себя одну или более записей, таких как записи 504a-504g и т.д., корневой узел 602 и запись-псевдоним 902.

Как пояснено ранее, в DIB 500, показанном на фиг. 5, экземпляр записи или объект уникально и однозначно идентифицируется посредством DN. Тем не менее, DN не обязательно должно быть единственным именем, посредством которого на запись, такую как запись 504f, может ссылаться клиентское приложение. Запись-псевдоним, такая как запись-псевдоним 902, является записью в DIT, таком как DIT 900, которая имеет атрибут, такой как "aliasedEntryName", который содержит имя другой записи в DIT 900. Так, например, запись-псевдоним 902 может иметь атрибут с названием "aliasedEntryName", значение которого - имя "запись 504f". Вторая запись (к примеру, запись 504f) не обязательно должна существовать в DIT 900, хотя она существует в этом примере. Также следует отметить, что структура записи-псевдонима 902 в DIT 900 не обязательно существенно отличается от записей 504a-504g, причем различие в именах ("запись" по сравнению с "записью-псевдонимом") представляется здесь в качестве помощи для понимания функции записи-псевдонима.

Записи псевдонимов, такие как запись-псевдоним 902, предоставляют альтернативные имена для записи, такой как запись 504f. Псевдоним - это специальная запись в DIB 500, которая указывает на другую запись, такую как запись 504f. Псевдонимы аналогичны символьной ссылке в файловой системе. Следовательно, псевдоним - это полезный способ обеспечения записи базы данных, такой как запись 504f, несколькими идентификационными данными без дублирования данных. Псевдонимы, в частности, являются полезными, если данные сохраняются под уникальным именем (или ключом), который не меняется часто (возможно, выделяемом посредством системы 410 инициализации), но который должен быть публично доступным посредством множества различных идентификационных данных, таких как, например, приложения, ассоциированные с IMSI 323, MSISDN 325, унифицированным указателем ресурса (URL) и т.п., которые могут изменяться, согласно варианту осуществления изобретения. Использование псевдонимов дает возможность сохранения данных один раз и последующей ссылки через множество различных идентификационных данных, реализуемых как псевдонимы. Записи псевдонимов, такие как запись-псевдоним 902, могут добавляться, модифицироваться и/или удаляться без затрагивания данных.

Новые псевдонимы могут реализовываться в DIT 900 посредством модуля 905 создания псевдонима. Модуль 905 создания псевдонима может быть выполнен с возможностью составлять псевдоним в DIT 900 так, что другие компоненты, такие как модуль 909 преобразования имен, показанный на фиг. 9B, затем могут выполнять разыменование (снятие косвенности) псевдонимов для запросов данных, принимаемых от клиентского приложения, согласно варианту осуществления изобретения. Модуль 905 создания псевдонима может включать в себя пользовательский интерфейс с тем, чтобы псевдонимы могли создаваться после первоначальной инициализации (к примеру, "на лету"), чтобы предоставлять возможность быстрого развертывания новых псевдонимов. Альтернативно, модуль 905 создания псевдонима может активироваться через традиционную операцию с каталогом "addEntry", например, посредством LDAP или DAP.

В некоторых вариантах осуществления изобретения, модуль 905 создания псевдонима реализует псевдоним как запись в DIB 500 с обязательным атрибутом, который предоставляет DN записи, на которую указывает псевдоним. Например, допустим, что запись 504a имеет DN "c=UK", запись 504c имеет DN "o=MyCompany, c=UK", а запись 504d имеет DN "o=CompanyX, c=UK". Запись 504f имеет DN "employeeId=111, o=MyCompany, c=UK". Следовательно, запись-псевдоним 902 может иметь альтернативное имя "cn=Joe, o=MyCompany, c=UK" и ссылаться на запись 504f.

Поставщик службы каталогов, такой как CSP, возможно, захочет использовать псевдонимы, но делать это способом, отличным от предусмотренного в соответствии с различными известными протоколами и технологиями совмещения имен. Например, такой поставщик службы каталогов, возможно, захочет предоставлять услуги совмещения имен для клиентских приложений, таких как HSS 301, которые могут не быть выполнены с возможностью использовать псевдонимы. Дополнительно, поставщик службы каталогов также, возможно, захочет маскировать от одного или более приложений то, что совмещение имен выполнено, даже когда само клиентское приложение может выполнять совмещение имен. Эта маскировка псевдонимов может выполняться, например, по соображениям безопасности.

Фиг. 9B иллюстрирует модуль 903 маскировки псевдонимов, взаимодействующий с DIT 900, включающий в себя псевдоним 903, чтобы выполнять маскировку псевдонимов в запросе данных от запрашивающего объекта 920, такого как клиентское приложение, согласно варианту осуществления изобретения.

Модуль 903 маскировки псевдонимов, находящийся на сервере каталогов, таком как DS 706, показанный на фиг. 7A, выступает в качестве посредника во время запросов данных посредством запрашивающего объекта 920 и управляет разыменованием псевдонимов, как для запросов, так и для обновлений, независимо от ожиданий запрашивающего объекта 920, согласно варианту осуществления изобретения. Соответственно, запрашивающий объект 920 может представлять объект, такой как клиентское приложение, конечный пользователь или удаленный DSA, которому могут требоваться данные для того, чтобы выполнять процедуру сцепления, инициированную для части каталога под управлением этого DSA. Например, запрашивающим объектом 920 может быть HSS 301, который не сконфигурирован управлять самим совмещением имен, и/или HSS 301, для которого CSP хочет маскировать совмещение имен.

Соответственно, модуль 903 маскировки псевдонимов может заменять в результатах, представляемых в запрашивающий объект 920, имена в записях на имена, которые соответствуют представлению запрашивающего объекта DIT 900, согласно варианту осуществления изобретения.

Используя модуль 903 маскировки псевдонимов, записи, такие как запись 504f, могут содержать данные, к которым может осуществляться доступ посредством запрашивающего объекта 920, такого как HSS 301, с использованием другого имени, такого как имя записи-псевдонима 902. Запрашивающий объект 920, например, должен адресовать запись, такую как запись 504f, посредством имени, которое является уникальным для запрашивающего объекта 920. Тем не менее, допустим, что запрашивающий объект 920 не сконфигурирован так, что он может использовать совмещение имен, поскольку подход развертывается традиционно. Модуль 903 маскировки псевдонимов, таким образом, эффективно предоставляет такие запрашивающие объекты 920 с возможностью использовать совмещение имен, не требуя никаких модификаций в запрашивающий объект 920.

Фактически, запись, такая как запись 504f, может иметь множество записей псевдонимов (к примеру, несколько экземпляров псевдонима 902), при этом каждая запись-псевдоним представляет имя, используемое посредством различных запрашивающих объектов 920 для того, чтобы осуществлять доступ к данным, содержащимся в записи 504f. Этот подход обеспечивает возможность централизованного размещения данных, ассоциированных с сетью связи, к примеру репозитории 404 данных, без необходимости изменять существующие запрашивающие объекты 920 (к примеру, клиентские приложения), согласно варианту осуществления изобретения. Таким образом, модуль 903 маскировки псевдонимов дает возможность CSP использовать унаследованные приложения, такие как унаследованный HSS 301, даже после переключения на другую архитектуру для сети связи.

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

Маскировка псевдонимов - это механизм, который может использоваться на основе приложений для того, чтобы маскировать наличие псевдонима, согласно варианту осуществления изобретения. Инструкции маскировки псевдонимов для данного приложения могут быть включены в файл 914 данных маскировки псевдонимов, согласно варианту осуществления изобретения. Когда маскировка псевдонимов выполняется для запрашивающего объекта 920, операции, запрошенные посредством запрашивающего объекта 920, включающего в себя псевдоним, такой как запись-псевдоним 902, отображаются для запрашивающего объекта 920 как операция с обычной записью, такой как запись 504f. Модуль 903 маскировки псевдонимов может принудительно задавать разыменование всех псевдонимов и после этого выполняет преобразование имени для всех возвращаемых имен записей, которые должен быть связанными с исходным базовым именем в запросе запрашивающего объекта, а не действительного имени записи. Следовательно, результаты поиска, представляемые в запрашивающий объект 920, могут включать в себя имя псевдонима, а не действительное имя в DIT 900 записей, возвращенных в поиске. С точки обзора запрашивающего объекта, псевдоним отображается как действительная запись. Аналогично, все записи, подчиненные действительной записи, отображаются как записи, подчиненные псевдониму. Таким образом, запрашивающий объект 920, такой как HSS 301, может обновлять и запрашивать запись с использованием имени псевдонима.

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

- управление разыменованием псевдонимов посредством модуля 909 преобразования имен, возможно в отличие от ожиданий запрашивающего объекта 920 (к примеру, клиентского приложения), который инициировал запрос данных, и/или

- управление разыменованием псевдонимов посредством модуля 911 поиска/обновления или операции с каталогом, сцепляемой посредством модуля 917 сцепления, возможно в отличие от ожиданий запрашивающего объекта 920 (к примеру, клиентского приложения), который инициировал запрос данных, и/или

- модификация имен в результатах, формируемых посредством модуля 911 поиска/обновления, или возвращаемых посредством модуля 917 сцепления так, чтобы они относились к базовому имени, предоставляемому посредством запрашивающего объекта 920 (к примеру, клиентского приложения), который инициировал запрос данных, а не к разрешенному базовому имени (RDN), и помимо этого, для всех псевдонимов, встречающихся во время поиска по поддеревьям, рекурсивная замена относительных действительных имен записей на относительные имена записей псевдонимов, так чтобы они отображались, как будто есть одно поддерево ниже разрешенной базовой записи без псевдонимов.

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

Запросы на доступ к данным в каталоге могут являться результатом множества объектов или источников. Например, доступы к данным, такие как поиски и обновления, могут исходить от клиентского приложения, конечного пользователя или даже агента системы каталогов, такого как DSA 702, показанный на фиг. 7A. Соответственно, как отмечено выше, запрашивающий объект 920 может представлять объект, такой как клиентское приложение, конечный пользователь или удаленный DSA, которому могут требоваться данные для того, чтобы выполнять процедуру сцепления, инициированную для части каталога под управлением этого DSA.

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

Сервер 907 операций с каталогом принимает от запрашивающего объекта 920 запрос, связанный с данными, хранимыми в каталоге, таком как DIT 900, и передает этот запрос в модуль 903 маскировки псевдонимов (этап A). Модуль 903 маскировки псевдонимов затем передает этот запрос в модуль 909 преобразования имен после модификации запроса данных, чтобы отражать все действующие режимы маскировки псевдонимов (этап B). При определении действующего режима маскировки псевдонимов модуль 903 маскировки псевдонимов может анализировать файл 914 данных маскировки псевдонимов, который может содержать связанные с совмещением имен выборы конфигурации данных на такой основе, как для каждого приложения, для каждого пользователя, на уровне всей системы и т.д. Таким образом, модуль 903 маскировки псевдонимов может модифицировать запрос данных, чтобы управлять разыменованием псевдонимов, возможно, способами, отличными от ожиданий запрашивающего объекта 920, согласно варианту осуществления изобретения. В случае цепного запроса от удаленного DSA, действующий режим(ы) маскировки псевдонимов также может указываться в параметрах запроса на сцепление, причем эквивалентная обработка с этим удаленным DSA уже определила действующий режим маскировки псевдонимов, возможно, из собственного файла 914 данных маскировки псевдонимов или из входящей цепной операции.

Модуль 909 преобразования имен затем разрешает имя, предоставляемое посредством модуля 903 маскировки псевдонимов, согласно варианту осуществления изобретения. Модуль 909 преобразования имен, находящийся на сервере каталогов, таком как DS 706, показанный на фиг. 7A, выполняет обработку преобразования имен, которая является начальной частью обработки для входящей операции с каталогом, согласно варианту осуществления изобретения. Модуль 909 преобразования имен обнаруживает базовую запись операции с каталогом в DIT 900 с помощью имени, предоставляемого в качестве параметра для операции с каталогом посредством модуля 903 маскировки псевдонимов. Модуль 909 преобразования имен рассматривает каждый RDN по очереди и обнаруживает запись, совпадающую с тем RDN, который является непосредственным подчиненным ранее обнаруженной записи (или корневой записи для первого RDN). Этот процесс продолжается до тех пор, пока все RDN не рассмотрены или пока имя не может быть полностью разрешено локально, но встречена ссылка, чтобы разрешать сцепление операции к удаленному DSA, который может иметь возможность полностью разрешать имя, согласно варианту осуществления изобретения.

Если во время преобразования имен модуль 909 преобразования имен встречает запись-псевдоним, процесс преобразования имен может быть перезапущен, причем текущая разрешенная часть имени заменяется на значение записи-псевдонима, такое как атрибут записи "aliasedEntryName", упомянутый выше согласно варианту осуществления изобретения. Этот перезапуск операции, который известен в данной области техники как "разыменование псевдонимов", может осуществляться несколько раз, чтобы полностью разрешать имя.

Преобразование имен - это традиционный процесс в протоколах, таких как X.500, хотя преобразование имен, согласно варианту осуществления изобретения, не обязательно должно выполняться согласно какому-либо конкретному протоколу. Традиционный LDAP-протокол, например, ограничивает разыменование псевдонимов так, чтобы только запрашивать операции, хотя это ограничение не обнаружено в традиционном протоколе X.500. Что еще более важно, этот традиционный процесс выполняется под управлением запрашивающего объекта 902, такого как клиентское приложение как HSS 301, а не модуля 903 маскировки псевдонимов. Другими словами, клиентское приложение должно указывать то, что операция разыменования псевдонимов должна осуществляться. Помимо этого результат традиционного разыменования псевдонимов должен указывать, что разыменование псевдонимов осуществлялось посредством включения, помимо прочего, полностью разыменованных имен записей в результаты, предоставляемые в клиентское приложение. Согласно варианту осуществления изобретения, запрашивающий объект 920 не имеет необходимости указания того, должно ли осуществляться разыменование псевдонимов, и запрашивающий объект 920 не обязательно должен принимать полностью разыменованные имена записей в предоставляемых результатах.

Допустим, например, что модуль 909 преобразования имен принимал запрос на считывание для данных, находящихся в "Root.Entry1.Entry2.Alias" в DIT 900. Модуль 909 преобразования имен сначала осуществляет доступ к корню 602 (этап C1). Модуль 909 преобразования имен затем осуществляет доступ к записи 504a для этого конкретного запроса (этап C2) до осуществления доступа к записи 504c (этап C3). Модуль 909 преобразования имен затем осуществляет доступ к записи-псевдониму 902 и обнаруживает индикатор, что запись-псевдоним 902 является записью-псевдонимом, и что запись-псевдоним имеет имя "Root.Entry1.Entry2.Entry3" (этап C4). Соответственно, модуль 909 преобразования имен перезапускает процесс преобразования имен и повторяет этапы C1, C2, C3, согласно варианту осуществления изобретения. Модуль 909 преобразования имен затем осуществляет доступ к записи 504f и определяет, что она является действительной записью и поэтому имеет полностью разрешенное исходное имя (этап C5).

Модуль 909 преобразования имен сообщает обнаруженную запись 504f наряду с осуществленным трактом в модуль 903 маскировки псевдонимов (этап D). Модуль 903 маскировки псевдонимов сохраняет разыменованную информацию о тракте, по меньшей мере, моментально, согласно варианту осуществления изобретения.

Если локальная обработка поиска/обновления необходима, чтобы выполнять запрос (т.е. имя полностью разрешено локально), то модуль 903 маскировки псевдонимов передает обнаруженную запись (к примеру, запись 504f) и исходный запрос, модифицированный для ранее определенного действующего режима(ов) маскировки псевдонимов, в модуль 911 поиска/обновления (этап E).

Альтернативно, если сцепление необходимо, чтобы выполнять запрос (т.е. имя не полностью разрешено), то модуль 903 маскировки псевдонимов передает исходную операцию, с ранее определенным действующим режимом(ами) маскировки псевдонимов и всей разыменованной информацией о псевдониме, в модуль 917 сцепления (этап E').

Модуль 911 поиска/обновления действует в соответствии с обнаруженной записью (к примеру, записью 504f). Находящийся на сервере каталогов, таком как DS 706, показанный на фиг. 7A, модуль 911 поиска/обновления выполняет операцию, запрошенную посредством модуля 903 маскировки псевдонимов для разрешенной записи, предоставляемой посредством модуля 909 преобразования имен, согласно варианту осуществления изобретения. В случае обновления, модуль 911 поиска/обновления выполняет обновление для записи, к примеру, записи 504f (этап F1). В случае поиска, модуль 911 поиска/обновления выполняет поиск, начиная с найденной записи, предоставляемой посредством модуля 909 преобразования имен, к примеру записи 504f (этап F1), и также может выполнять поиск для поднабора или всех своих подчиненных записей, к примеру записи 504g (этап F2). При анализе поддерева ниже разрешенной записи модуль 911 поиска/обновления может встречать другие псевдонимы (к примеру, допустим, что запись 504g - это псевдоним) и выполнять разыменование псевдонимов способом, аналогичным выполняемому посредством модуля 909 преобразования имен.

Модуль 911 поиска/обновления также может встречать подчиненные ссылки на удаленные DSA, которые указывают, что поддерево секционировано, и что все подчиненные записи с этой точки хранятся дистанционно. В таких случаях новая операция поиска сцепляется (с действующим режимом(ами) маскировки псевдонимов) с удаленным DSA (через модуль 917 сцепления) (этап I), и все результаты (этап J) из этой цепной операции добавляются к сформированным локально.

Модуль 911 поиска/обновления сообщает о предпринятых действиях, извлекаемой информации (локально и/или от цепных поисков) и осуществленном тракте в модуль 903 маскировки псевдонимов (этап G). Модуль 911 поиска/обновления типично сообщает информацию о тракте в модуль 903 маскировки псевдонимов с помощью полностью разыменованных имен для записей в поиске.

Модуль 917 сцепления выступает в качестве запрашивающего объекта для указанного ссылкой удаленного DSA, передавая цепные операции на удаленный сервер 931 операций с каталогом. Находящийся на сервере каталогов, таком как DS 706, показанный на фиг. 7A, модуль 917 сцепления работает вместе с модулем 909 преобразования имен, в качестве альтернативы модулю 911 поиска/обновления в случае, если каталог распределен, и если модуль 909 преобразования имен не может полностью разрешать имя локально и встретил подходящую ссылку, которая указывает, что удаленный DSA может иметь возможность полностью разрешать имя. Модуль 917 сцепления перенаправляет входящую операцию с каталогом и все разыменованные псевдонимы на сервер 931 операций с каталогом, который аналогичен серверу 907 операций с каталогом, но постоянно размещается в удаленном DSA. Модуль 917 сцепления сообщает результаты, принимаемые обратно от удаленного DSA, в модуль 903 маскировки псевдонимов (этап G') или модуль 911 поиска/обновления (этап J), в зависимости от того, какой модуль отправлял запрос на сцепление.

Модуль маскировки псевдонимов сообщает результаты запроса данных обратно на сервер 907 операций с каталогом (этап H), который, в свою очередь, передает обратно информацию в запрашивающий объект 920. Модуль 903 маскировки псевдонимов может быть выполнен с возможностью удалять все индикаторы того, что обнаружение запрошенной информации заключало в себе псевдоним, и просто отправлять запрос данных обратно на сервер 907 операций с каталогом. Модуль 903 маскировки псевдонимов, в зависимости от его инструкций, может восстанавливать дерево, как если бы оно не содержало псевдонимов, и изменять имена соответствующим образом, к примеру, дерево: entry1.entry2.alias902.entry4 (дерево, возможно ожидаемое посредством запрашивающего объекта 920, а не фактическое дерево в каталоге: root.entry1.entry2.entry3.entry4). Таким образом, модуль 903 маскировки псевдонимов может модифицировать имена в результатах, формируемых посредством модуля 911 поиска/обновления, так чтобы они относились к базовому имени, предоставляемому посредством запрашивающего объекта 920, а не к разрешенному базовому имени (RDN), а также так, чтобы все записи, найденные как результат записи-псевдонима, подчиненной базовой записи, представлялись "на месте", а не в рамках явного дополнительного поддерева, согласно варианту осуществления изобретения.

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

Как показано на фиг. 4, решение проблемы нескольких независимых хранилищ данных для каждой операции приложения в сети состоит в том, чтобы комбинировать данные в одном репозитории данных. Как пояснено ранее, в некоторых случаях, совершенно одинаковые данные существуют в различных существующих ранее репозиториях данных, к примеру оба репозитория данных имеют абонента "John Smith". Тем не менее, в некоторых случаях, приложение может требовать, чтобы DN имело имя "Customer", тогда как другое приложение может требовать, чтобы DN имело имя "Subscriber". DN в репозитории данных может иметь имя "Name". Во всех трех экземплярах "Subscriber", "Customer" и "Name" для DN все указывают на запись данных, имеющую значение "John Smith". Вместо того, чтобы воспроизводить "John Smith" три раза в базе данных, DN может быть "Name", с двумя псевдонимами "Subscriber" и "Customer". Допустим, что приложение, требующее имени "Subscriber", удаляется из системы, в таком случае псевдоним для "Subscriber" может быть удален, согласно варианту осуществления изобретения. Дополнительно допустим, что добавляется новое приложение, которое использует "Name" DN для имени абонента, в таком случае псевдоним "Name" может быть просто добавлен.

Варианты

Фиг. 10A иллюстрирует DIT 1000 с записью 1002 варианта, согласно варианту осуществления изобретения. DIT 1000 включает в себя одну или более записей, таких как записи 504a-504e и т.д., корневой узел 602 и запись 1002 варианта. Записи вариантов, такие как запись 1002 варианта, предоставляют альтернативные представления данных, хранимых в репозитории 404 данных. Запись 1002 варианта задает запись, которая группирует атрибуты из различных записей в DIT 1000, таких как записи 504c и 504d. Следовательно, когда запрашивающий объект, такой как клиентское приложение, осуществляет доступ к записи 1002 варианта, запрашивающий объект принимает доступ к атрибутам от других записей, таких как записи 504c и 504d. Доступ к этим другим записям может быть прозрачным для запрашивающего объекта, который не знает, как структурированы базовые данные.

Таким образом, пока запрашивающий объект извлекает данные ожидаемым способом, то запрашивающий объект может работать, как если бы данные по-прежнему постоянно размещались, например, в одном собственном хранилище данных. Другими словами, изменения не требуется выполнять в запрашивающем объекте, чтобы приспосабливать наличие варианта, согласно варианту осуществления изобретения. Что еще более важно, реализация записи варианта иногда может быть важной для того, чтобы не допускать необходимости выполнять изменение в запрашивающий объект, чтобы запрашивающий объект надлежащим образом взаимодействовал с DIT 1000. Аналогично, изменения потребностей в данных запрашивающего объекта могут быть выполнены посредством создания записи варианта, которая совпадает с новыми потребностями в данных запрашивающего объекта. В основном варианты перенаправляются на уровне атрибута, тогда как псевдонимы, такие как псевдоним 902, показанный на фиг. 9B, перенаправляются на уровне записи, согласно варианту осуществления изобретения.

Запись 1002 варианта является записью в DIT 1000, которая не имеет обрабатываемых атрибутов, за исключением атрибута "класс объектов", согласно варианту осуществления изобретения. Ассоциированное определение "класса объектов" отмечается как "вариант" и включает в себя определенное число атрибутов. Принадлежность класса объектов вариантов означает, что к правилу должен осуществляться доступ при обработке одного или более атрибутов записи. Например, как показано на фиг. 10A, значение атрибута класса объектов "вариант" означает, что атрибуты "My Company Contact" и "Company X Contact" имеют правило для извлечения значений из других атрибутов ("действительных" атрибутов) в других записях ("конкретных" записях) в DIT 1000, таких как запись 504c. Таким образом, например, в записи 1002 варианта значение для "My Company Contact" находится в атрибутах "Address, Contact и Website" записи 504c.

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

Экземпляр данного варианта (к примеру, варианта 1002) может создаваться в DIT 1000 с помощью модуля 1005 создания вариантов, согласно варианту осуществления изобретения. Например, как показано на фиг. 10A, модуль 1005 создания вариантов может создавать вариант 1002 так, что он является членом класса объектов вариантов, который включает в себя атрибут "my company contact" и атрибут "company X contact", при этом атрибут "my company contact" принимает данные от записи 504c, атрибутами которой являются "address", "contact" и "website", и атрибут "company x contact" принимает данные от записи 504d, атрибутами которой являются "address", "contact" и "website". Модуль 1005 создания вариантов может предоставлять пользовательский интерфейс так, чтобы варианты могут создаваться "на лету", чтобы предоставлять возможность быстрого развертывания новых вариантов. Альтернативно, модуль 1005 создания вариантов может активироваться через традиционную операцию работы с каталогом addEntry, например, по LDAP или DAP.

Как только модуль 1005 создания вариантов создал вариант 1002 в DIT 1000, затем запросы на предмет атрибутов варианта 1002 могут прозрачно предоставляться в запрашивающие объекты, запрашивающие данные, представляемые посредством этих атрибутов, согласно варианту осуществления изобретения. Предположим, например, что запрашивающий объект запрашивает данные для атрибута адреса "My Company Contact", поскольку класс объектов вариантов задает атрибут адреса для "My Company Contact" как атрибут адреса записи 504c, в таком случае это данные, которые вариант 1002 возвращает в запрашивающий объект.

Фиг. 10B иллюстрирует обработку вариантов в DIT 1000, включающее в себя вариант 1002 запроса данных от запрашивающего объекта 1020, такого как клиентское приложение, согласно варианту осуществления изобретения. Запрашивающий объект 1020 может представлять объект, такой как клиентское приложение, конечный пользователь или удаленный DSA, которому могут требоваться данные для того, чтобы выполнять процедуру сцепления, инициированную для части каталога под управлением этого DSA.

Сервер 1007 операций с каталогом представляет объект, выполненный с возможностью принимать запросы данных и затем предоставлять их в соответствующие процессоры, ассоциированные с сервером каталогов, так что запрошенная операция может выполняться, согласно варианту осуществления изобретения. Например, LDAP-сервер представляет типичный сервер операций с каталогом, такой как сервер 1007 операций с каталогом. Сервер 1007 операций с каталогом находится на расстоянии доступа (к примеру, совмещен) с механизмом хранения данных, выступающим в качестве хоста для данных для DIT 1000. Таким образом, обработка записи варианта (к примеру, извлечение значения атрибута), такого как вариант 1002, может выполняться в точке доступа в/из базового механизма хранения данных. Например, обработка записи варианта на сервере 1007 операций с каталогом может осуществляться в агенте системы каталогов, таком как DSA 702, показанный на фиг. 7A, где данные фактически сохраняются. Уровни протокола, такого как, например, X.500, не должны знать о присутствии или наличии записей вариантов. Эта обработка вариантов может предоставлять повышенную производительность в требовательных окружениях реального времени, таких как система 204 мобильной связи, но эта повышенная производительность может требовать, чтобы вариант и его конкретные записи располагались в рамках одного DSA, согласно варианту осуществления изобретения.

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

Приемник 1009 запросов данных предоставляет местоположение для варианта 1002 наряду с соответствующими правилами для обработки вариантов в модуль 1011 извлечения местоположения. Модуль 1011 извлечения местоположения затем извлекает местоположение для запрошенных данных в рамках механизма хранения данных с использованием соответствующих правил для извлечения местоположения для данных, согласно варианту осуществления изобретения. Например, при извлечении местоположения для атрибута "My Company Contact" варианта 1002, модуль 1011 извлечения местоположения должен находить правило, проясняющее то, что эти данные могут извлекаться из атрибутов "Address", "Contact" и "Web Site", сохраненных для записи, обнаруженной в Root.Entry1.Entry2. Аналогично, при извлечении местоположения для "Company X Contact", модуль 1011 извлечения местоположения должен находить правило, указывающее, что эти данные могут извлекаться из атрибутов "Address", "Contact" и "Web Site", сохраненных для записи, обнаруженной в Root.Entry1.Entry3.

Правила, применяемые посредством модуля 1011 извлечения местоположения для извлечения DN конкретной записи в DIT 1000, могут включать в себя переменные данные, извлекаемые из DN исходной записи варианта, такой как запись 1002 варианта, согласно варианту осуществления изобретения. Например, допустим, что запись 504a имеет DN "c=UK", запись 504c имеет DN "o=MyCompany, c=UK", а запись 504d имеет DN "o=CompanyX, c=UK". Запись 1002 варианта имеет DN "varianto=MyCompany, c=UK". Правило DN для конкретной записи - это "o=valueof (varianto), c=UK". Поскольку значением "varianto" является "CompanyX", конкретная запись имеет DN "o=MyCompany, c=UK", другими словами, его значение находится в записи 504c.

Модуль 1011 извлечения местоположения затем должен предоставлять извлеченные местоположения в модуль 1013 считывания/обновления данных, который затем должен выполнять запрошенную процедуру для данных, сохраненных посредством механизма хранения данных, согласно варианту осуществления изобретения. Модуль 1013 считывания/обновления данных применяет все действующие правила (к примеру, преобразования значений), связанные с данными (к примеру, его форматом), при выполнении своих задач. Для атрибутов в классе объектов вариантов (к примеру, атрибут "My Company Contact" варианта 1002), имеется действительный атрибут(ы) в конкретной записи (к примеру, атрибуты "Address", "Contact", "Web Site" entry2), которые содержат извлеченные значения атрибутов, подвергнутые преобразованию значений или функции, согласно варианту осуществления изобретения. Например, модуль 1013 считывания/обновления данных может применять правило преобразования значений, которое изменяет целочисленное значение из атрибута, приведенного из действительного атрибута, на действительное значение для атрибута в записи варианта, к примеру с "1" на "1,0". Модуль 1013 считывания/обновления данных может применять функцию, например, к атрибуту, приведенному из действительного атрибута к атрибуту в записи варианта, к примеру 12, может быть добавлено ко времени, чтобы преобразовывать его формат из ожидаемого американского времени ("1 p.m.") к ожидаемому европейскому формату ("1300"). Модуль 1013 считывания/обновления предоставляет информацию, касающуюся своих действий, о которых можно сообщать обратно в запрашивающий объект 1020, согласно варианту осуществления изобретения. Кроме того, как упомянуто выше, сообщения могут быть структурированы так, что фактический характер DIT 1000 является прозрачным (к примеру, маскируемым) от запрашивающего объекта 1020, согласно варианту осуществления изобретения.

Модуль 1011 извлечения местоположения может определять для данного запроса данных, что определенная часть данных для варианта постоянно размещается в удаленном каталоге. Соответственно, модуль 1011 извлечения местоположения перенаправляет эту часть запроса данных в модуль 1017 сцепления, который взаимодействует с удаленным сервером 1031 операций с каталогом, чтобы осуществлять доступ к запрошенным данным. Удаленный сервер 1031 операций с каталогом, аналогично серверу 1007 операций с каталогом, выполнен с возможностью обрабатывать операции для записей вариантов, согласно варианту осуществления изобретения.

В альтернативном варианте осуществления, модуль 1011 извлечения местоположения может анализировать операцию поиска каталога в варианте в одной или более операций поиска каталога для ассоциированных конкретных записей. Эти извлеченные операции сцепляются посредством модуля 1017 сцепления либо на удаленном сервере 1031 операций с каталогом, либо на этом же сервере 1007 операций с каталогом для обработки как обычных операций с каталогом. Сцепленные результаты затем используются посредством модуля 1013 считывания/обновления данных для того, чтобы создавать исходящие результаты. Например, входящий базовый поиск в варианте 1002 базовой записи (все пользовательские атрибуты) должен разбираться на два базовых поиска, один по записи 504c и один по записи 504d. Значения атрибутов, содержащиеся в результатах этих двух поисков, используются посредством модуля 1013 считывания/обновления данных для того, чтобы извлекать значения атрибутов, возвращаемые в исходящем результате. Модуль 1011 извлечения местоположения может аналогично разбирать операцию обновления каталога для варианта на одну или более операций обновления каталога для ассоциированных конкретных записей и после этого сцеплять их, согласно варианту осуществления изобретения.

В другом альтернативном варианте осуществления, эта процедура разложения может быть обработана посредством модуля извлечения местоположения как часть адаптации протоколов, которая поясняется ниже. Модуль 1107 адаптации протоколов, который поясняется дополнительно на фиг. 11A, может работать с обработкой вариантов, согласно варианту осуществления изобретения. Адаптация протоколов является необязательной для обработки вариантов, согласно варианту осуществления изобретения.

Принцип записей вариантов может быть дополнен так, что запись 1002 варианта может содержать смешение действительных значений атрибутов и извлеченных значений атрибутов, согласно варианту осуществления изобретения. Это может быть результатом смешения действительных классов объектов и классов объектов вариантов, членом которых является запись, или поскольку один класс объектов может иметь смешение действительных и извлеченных атрибутов. Кроме того, один атрибут может иметь действительные значения, сохраненные в записи 1002 варианта, а также значения, извлеченные из других конкретных записей. Например, запись 1002 варианта может иметь дополнительный действительный атрибут "Alternative Contact", и этот атрибут сам может хранить фактические данные для альтернативного контакта. В этом случае модуль 1011 извлечения местоположения должен просто предоставлять это конкретное местоположение в модуль 1013 считывания/обновления данных.

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

- Использование действительных значений атрибутов в рамках записи 1002 варианта, и/или

- Использование контекстной информации, такое как время дня и запрашивающий пользователь, и/или

- Альтернативные правила хранят себя как действительные значения атрибутов в рамках записи варианта.

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

Записи вариантов, такие как вариант 1002, могут упрощать обновление данных в DIT 1000. Например, поскольку атрибут адреса "My Company Contact" является атрибутом адреса записи 504c данных, то обновление адресной записи для "My Company Contact" и для записи 504c данных не сложнее обновления адресной записи для записи 504c данных. Простота этого подхода может быть видна, если предполагать, что DIT 1000 содержит не только один вариант 1002, а множество записей вариантов, каждая из которых, возможно, ассоциирована с различным запрашивающим объектом, но все из которых указывают на запись 504c данных.

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

Адаптация - адаптация протоколов

Фиг. 11A иллюстрирует модуль 1107 адаптации протоколов, согласно варианту осуществления изобретения. Модуль 1107 адаптации протоколов может предоставлять нестандартную обработку операций с каталогом, таких как LDAP или DAP.

Запросы на данные в каталоге могут проистекать из множества источников. Например, доступы к данным могут исходить из клиентского приложения, от конечного пользователя или даже агента системы каталогов, такого как DSA 702, показанный на фиг. 7A. Соответственно, запрашивающий объект 1115 может представлять объект, такой как клиентское приложение, конечный пользователь или удаленный DSA, которому могут требоваться данные для того, чтобы выполнять процедуру сцепления, инициированную для части каталога под управлением этого DSA, согласно варианту осуществления изобретения. В любом случае, запрашивающий объект 1115 отправляет запрос данных на сервер 1109 операций с каталогом. Сервер 1109 операций с каталогом представляет объект, выполненный с возможностью принимать запросы данных и затем предоставлять их в соответствующие процессоры, ассоциированные с сервером каталогов, так что запрошенная операция может выполняться, согласно варианту осуществления изобретения. Например, LDAP-сервер должен представлять сервер операций с каталогом, такой как сервер 1109 операций с каталогом.

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

Модуль 1135 выбора правил может использовать любое поле или комбинацию полей во входящей операции для того, чтобы идентифицировать применимый набор правил, согласно варианту осуществления изобретения. Помимо этого инициирующий пользователь (к примеру, запрашивающий объект 1115), может использоваться в процессе выбора правил, как могут и другие контекстные данные, такие как время дня. Модуль 1135 выбора правил также может использовать текущие "рабочие" данные, связанные с самим запросом данных, в качестве части процесса выбора правил, например, когда процесс адаптации осуществляется после того, как обработка входящей операции начата. Например, содержимое разыменованных псевдонимов может использоваться при выборе правил, если адаптация протоколов осуществляется после преобразования имен. Соответственно, модуль 1135 выбора правил может работать вместе с модулем 909 преобразования имен, показанным на фиг. 9B, согласно варианту осуществления изобретения. Хотя не показано на фиг. 11A, модуль 1107 адаптации протоколов может быть выполнен с возможностью работать с другой функциональностью, такой как компоненты, ассоциированные с маскировкой псевдонимов, как показано на фиг. 9B, согласно варианту осуществления изобретения.

Все эти данные, которые могут использоваться в процессе выбора правил, называются данными выбора правил. Выбор набора правил типично заключает в себе сопоставление данных выбора правил с утверждениями значений в предполагаемых правилах, заключающих в себе либо одиночные значения, либо в логических комбинациях, таких как "AND" и "OR". Утверждения значений могут быть простыми равенствами или неравенствами или могут заключать в себе другие критерии, такие как "наилучшее совпадение" по ряду предполагаемых правил. Например, если правило должно быть выбрано посредством имени записи во входящей операции, правило, выбираемое посредством модуля 1135 выбора правил, может быть таким, в котором максимальное число упорядоченных RDN совпадают с RDN имени во входящей операции, другими словами, самое длинное совпадение префикса имени. Утверждения значений также могут включать в себя переменные правила или правила подстановочных символов и являются расширяемыми таким образом, чтобы позволять добавление новых типов утверждений по мере необходимости, согласно варианту осуществления изобретения. Например, при совпадении RDN, утверждение может быть составлено так, что только тип атрибута должен совпадать с любым значением атрибута, предоставляющего совпадение.

Набор правил, выбираемый посредством модуля 1135 выбора правил, указывает набор продолжающейся операции(й), выполняемой под управлением модуля 1107 адаптации протоколов, согласно варианту осуществления изобретения. Набор правил также может указывать результаты или ошибки, которые должны сразу возвращаться в запрашивающий объект 1115, и/или набор действий, таких как "регистрация операции". Продолжающиеся операции могут обрабатываться или последовательно, или параллельно. В случае последовательной обработки результаты одной операции могут использоваться посредством модуля 1107 адаптации протоколов в качестве вводов для последующей операции, как в примере, показанном на фиг. 11B ниже. Поля продолжающихся операций могут быть заполнены посредством модуля 1107 адаптации протоколов комбинацией переменных данных, извлекаемых из любого поля во входящей операции, необязательно подвергнутых преобразованию, и/или любых других данных выбора правил и/или фиксированных данных, предоставляемых посредством выбранных правил, согласно варианту осуществления изобретения. Аналогично, модуль адаптации протоколов может заполнять поля исходящего результата комбинацией переменных данных, извлекаемых из любого поля в результатах, необязательно подвергаемых преобразованию, и фиксированных данных, предоставляемых посредством выбранных правил.

Фиг. 11B иллюстрирует пример последовательной или не поддающейся распараллеливанию обработки адаптации протоколов, согласно варианту осуществления изобретения. BSS 402 отправляет запрос на девичью фамилию жены абонента. Здесь, BSS 402 выступает в качестве запрашивающего объекта 1115, показанного на фиг. 11A. Модуль 1135 выбора правил, ассоциированный с модулем 1107 адаптации протоколов, анализирует входящую операцию ("Получить девичью фамилию жены"), принимаемую посредством сервера 1109 операций с каталогом, и идентифицирует правило, которое указывает две продолжающихся операции. Первая продолжающаяся операция, "Получить имя жены", извлекает имя жены абонента, к примеру, "Becky Jones". Результаты первой продолжающейся операции предоставляют данные для второй продолжающейся операции, "Найти девичью фамилию", которая извлекает девичью фамилию для "Becky Jones". Модуль 1107 адаптации протоколов помогает серверу 1109 операций с каталогом в возвращении ответа "Becky Romanov" в BSS 402. Используя этот подход, BSS 402 не знает или не должна знать все этапы, которые осуществлены посредством модуля 1107 адаптации протоколов при ответе на запрос.

Модуль 1107 адаптации протоколов может быть выполнен с возможностью работать на различных стадиях в рамках обработки, осуществляемой под управлением сервера операций с каталогом с 1109. Таким образом, например, адаптация протоколов может осуществляться после обработки преобразования имен, например, предоставляемой посредством модуля 909 преобразования имен, показанного на фиг. 9B, но до обработки поиска/обновления, например, предоставляемой посредством модуля 911 поиска/обновления, показанного на фиг. 9B.

Поскольку запрашивающим объектом 1115 может быть удаленный DSA, модуль 1107 адаптации протоколов может обрабатывать цепные операции, предоставляя полностью распределенную адаптацию протоколов, согласно варианту осуществления изобретения. Выполнение адаптации протоколов в цепных операциях подразумевает несколько уровней такой адаптации - другими словами, возможный дополнительный проход адаптации для каждого этапа сцепления.

Модуль 1107 адаптации протоколов может быть выполнен с возможностью взаимодействовать с вариантами, такими как вариант 1002, показанный на фиг. 10. Таким образом, например, запись варианта может вовлекаться в адаптированные под протокол операции, как указано посредством наличия модуля 1107 адаптации протоколов на фиг. 10B, согласно варианту осуществления изобретения.

Как показано на фиг. 11A, модуль 1107 адаптации протоколов выступает в качестве дополнительного модуля к серверу 1109 операций с каталогом, согласно варианту осуществления изобретения. В этом варианте осуществления модуль 1107 адаптации протоколов постоянно размещается на сервере физически рядом с сервером 1109 операций с каталогом. В некоторых вариантах осуществления модуль 1107 адаптации протоколов может даже постоянно размещаться на той же машине (к примеру, сервере), выступающей в качестве хоста для сервера 1109 операций с каталогом. Этот вариант осуществления с "дополнительным модулем" может предлагать повышенную производительность, особенно в определенных требовательных окружениях реального времени, по сравнению с вариантом осуществления, в котором модуль 1107 адаптации протоколов выступает в качестве сервера операций с виртуальным каталогом, таким как вариант осуществления, показанный на фиг. 11C.

В альтернативном варианте осуществления изобретения, показанном на фиг. 11C, модуль 1107 адаптации протоколов по существу выступает в качестве сервера виртуальных каталогов (или прокси-сервера LDAP/DAP), отправляющего данные (к примеру, операции LDAP или DAP) на сервер 1109 операций с каталогом, такой как DS 706a, показанный на фиг. 7A. В этом варианте осуществления модуль 1107 адаптации протоколов предоставляет модифицированные запросы на сервер 1109 операций с каталогом для обработки в каталоге, представляемом посредством DIT 1160. Таким образом, модуль 1107 адаптации протоколов анализирует все входящие операции на сервер 1109 операций с каталогом, согласно варианту осуществления изобретения. Модуль 1135 выбора правил преобразует входящую операцию в нуль, одну или более продолжающихся операций. Модуль 1107 адаптации протоколов затем объединяет результаты каждой из преобразованных операций в один результат и отправляет его обратно в инициирующий запрашивающий объект 1115. Правила для преобразования входящей операции и исходящего результата выбираются посредством одного или более из полей входящей операции, таких как "тип операции", и "имя записи в операции", согласно варианту осуществления изобретения. Правила для преобразования входящей операции и исходящего результата также могут сохраняться в конфигурационных данных 1121. В этом варианте осуществления, данные выбора правил ограничиваются внешним представлением содержимого DIT 1160, к примеру, сообщение LDAP и адаптация протоколов осуществляются до и/или после обработки сервера 1109 операций с каталогом.

Адаптация - адаптация имен

Фиг. 11D иллюстрирует DIT 1100, имеющее конфигурацию адаптивного именования, предоставленную посредством адаптации протоколов, согласно варианту осуществления изобретения. DIT 1100 включает в себя одну или более записей, таких как записи 504a-504f и т.д., виртуальные записи 504g-504i и корневой узел 602. 1100 DIT также включает в себя запись, помеченную как запись 1102a адаптивного имени, которая является действительной записью, аналогичной записям 504a-504f, которые подвергаются преобразованию в виртуальную запись, помеченную как запись 1102b адаптивного имени.

Адаптивное именование предоставляет другой механизм для альтернативных имен для записей в DIT 1100. Тем не менее, в отличие от псевдонимов и вариантов, адаптивные имена не являются непосредственно записями каталога. Адаптивное именование реализуется через конфигурационные данные, к примеру конфигурационные данные 1121. Модуль 1135 выбора правил в модуле 1107 адаптации протоколов использует данные выбора правил и конфигурационные данные 1121 для того, чтобы идентифицировать набор преобразований 1104 адаптивных имен между альтернативными именами и их "действительным" эквивалентным именем, согласно варианту осуществления изобретения. В случае поисков, поиск глобального контекста с фильтром может быть адаптирован к поиску с намного более узким контекстом, если критерии фильтрации могут быть адаптированы в часть базового имени поиска; например, чтобы использовать преимущество псевдонимов, которые могут существовать, но о которых запрашивающий объект 1115 не знает. Поиск с комплексным фильтром, содержащим определенное число выражений "или", может быть адаптирован к числу поисков, по одному для каждой из альтернатив "или", согласно варианту осуществления изобретения.

В ходе извлечения данных и других операций, использование адаптивного именования может быть прозрачным для запрашивающего объекта (к примеру, клиентского приложения), который использовал имя, согласно варианту осуществления изобретения. Таким образом, запрашивающий объект (к примеру, запрашивающий объект 1115) использует то, что, как он полагает, является действительным именем, и принимает обратно запрошенную информацию. Например, допустим, что DN записи 1102a - это "employeeId=112, o=MyCompany, c=UK", и дополнительно допустим, что запись адаптивного имени существует между 1102a и 1102b. Наконец, предположим, что запрашивающий объект осуществляет доступ к данным в записи 1102b с использованием того, что, как он полагает, является соответствующим именем, к примеру, "employeeId=112, area=employeeAdmin, o=AnotherCompany, c=DE", вследствие адаптивного преобразования между 1102a и 1102b, идентичные данные должны быть извлечены. Таким образом, имя для 1102b является альтернативным именем для данных в 1102a.

Адаптация - адаптация атрибутов

Фиг. 11E иллюстрирует DIT 1150, имеющее адаптацию атрибутов, предоставленную посредством адаптации протоколов, согласно варианту осуществления изобретения. DIT 1150 включает в себя одну или более записей, таких как записи 504a-504f и т.д., и корневой узел 602. DIT 1150 также включает в себя запись 1105a, имеющую действительные атрибуты 1108a-1108e, которые подвергнуты преобразованию в адаптированную к виртуальным атрибутам запись 1105b, имеющую виртуальные атрибуты 1108f-1108j.

Действительная запись 1105a включает в себя один или более атрибутов, такие как атрибуты 1108a-1108e, а адаптированная к атрибутам запись 1102b включает в себя один или более атрибутов, такие как атрибуты 1108f-1108j, и т.д. В варианте осуществления изобретения один или более атрибутов 1108a-1108e записи 1105a содержат данные, такие как, например, данные абонентов, к примеру "имя", "фамилия", "адрес", "округ" и "почтовый индекс". Аналогично, один или более атрибутов 1108f-1108j адаптированной к атрибутам записи 1105b содержат данные, такие как, например, любое из "имени", "фамилии", "адреса", "штата", "почтового индекса" и т.п.

Адаптация атрибутов предоставляет альтернативные имена и/или значения для атрибутов, таких как атрибуты 1108a-1108e. В варианте осуществления изобретения, модуль 1135 выбора правил в модуле 1107 адаптации протоколов идентифицирует преобразование 1106 адаптации атрибутов между различными атрибутами с использованием конфигурационных данных 1121. Например, конфигурационные данные 1121 инструктируют модулю 1107 адаптации протоколов выполнять набор преобразований из имени 1108a атрибута в альтернативное имя 1108f атрибута. В различных вариантах осуществления изобретения, когда запрашивающий объект (к примеру, клиентское приложение) выполняет операцию, которая относится к атрибуту, имеющему преобразование атрибутов, преобразования атрибутов преобразуют имена атрибутов, таких как атрибуты 1108a-1108e, и значения, понятные посредством приложения, в соответствующие имена атрибутов и значения, понятные посредством DIT 1150. Например, допустим, что атрибут 1108a имеет "действительный" формат, и допустим, что его значение равно "1,0". Дополнительно допустим, что адаптированный атрибут 1108f имеет "целочисленный" формат, и допустим, что 1108f адаптирован к атрибуту 1108a. Если приложение, ассоциированное с 1108f, выполняет запрос на считывание для 1108f, то приложение, как ожидается, возвращает целое число "1", а не действительное "1,0". Вследствие адаптации атрибутов, выполняемой посредством модуля 1107 адаптации атрибутов, запрашивающий объект, осуществляющий доступ к адаптированному атрибуту 1108f, принимает данные в ожидаемом целочисленном формате.

В варианте осуществления изобретения, когда адаптация атрибутов реализуется вместе с адаптивным именованием, эта комбинация предоставляет средство не только для использования альтернативных имен для записи, но также и для преобразования имен и/или значений атрибутов записи. Дополнительно, в некоторых вариантах осуществления изобретения, адаптивное именование и адаптация атрибутов могут быть комбинированы, чтобы достигать независимости приложения от базовой структуры базы данных. Адаптивное именование и адаптация атрибутов предоставляют возможность проектировать и именовать основные объекты в репозитории данных с учетом неотложных потребностей основного бизнеса по сравнению с другими соображениями, таких как потребности унаследованного приложения, согласно варианту осуществления изобретения. Впоследствии, адаптивные имена и преобразования атрибутов могут добавляться так, чтобы предоставлять полные иерархии альтернативного именования относительно конкретных приложений, таких как HLR 307, HSS 301 и т.д. Эти альтернативные иерархии могут использовать различное DN, а также альтернативные имена атрибута, чтобы ссылаться на основные записи базы данных. Репозиторий 404 данных с DIB 500 преобразует запросы приложений с использованием заданных преобразований в записи DIB 500 и приписывает имя. Преобразования могут быть заданы на основе приложений (или на основе абонентов DIB 500), согласно варианту осуществления изобретения. Когда несколько приложений требуют различных иерархий именования, то каждое из этих приложений может связываться с различным именем абонента с надлежащими заданными преобразованиями, в варианте осуществления изобретения.

Упрощенное управление доступом для поддеревьев

Фиг. 12 иллюстрирует систему управления доступом (AC), реализованную с помощью формы адаптации протоколов, согласно варианту осуществления изобретения.

AC-системы типично являются частью протоколов связи, используемых в сетях (к примеру, совместимой LDAP сети связи), и могут быть реализованы как модуль управления доступом (ACU) 1201. ACU типично включают в себя различные модули разрешений, такие как модуль выдачи разрешений абонентам, модуль аутентификации и модуль старшинства. ACU затем комбинирует различные файлы разрешений, чтобы формировать непротиворечивый и полезный набор разрешений. ACU может группировать несколько разрешений, чтобы создавать набор разрешений для нескольких различных групп/пользователей. Например, в протоколе X.500 традиционный ACU предоставляет гибкие схемы управления доступом, которые дают возможность управления доступом с очень высокой степенью детализации вплоть до уровня отдельных записей, или он может применяться к поддеревьям каталога, такого как каталог 600, показанный на фиг. 6. Такие традиционные схемы управления доступом, хотя и являются гибкими, могут приводить к значительным затратам ресурсов обработки на администрирование при поддержании данных, управляющих ACU (информации управления доступом (ACI) 1217), а также значительным затратам ресурсов на обработку посредством ACU при применении управления доступом в среде выполнения. Это особенно ненадежно для каталога, содержащего много миллионов записей, которые, возможно, придется по отдельности администрировать для управления доступом, и если к тем записям доступ должен осуществляться в режиме реального времени. Большие ресурсы обработки на администрирование также имеют импликации безопасности в том, что чем более комплексную схему приходится администрировать, тем более вероятно происходит так, что она содержит ошибки и, следовательно, потенциальные упущения в системе безопасности.

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

В варианте осуществления изобретения, административная область в DSA, таком как DSA 702, показанный на фиг. 7A, предоставляет управление доступом на уровне схемы, так что ACI 1217 конфигурируется на основе класса объектов и типа атрибута, а не на основе отдельных записей каталога, и применяется ко всем записям, администрируемым посредством этого DSA. Это управление доступом на уровне схемы проще администрировать и проверять его достоверность на предмет корректности, и оно может быть оптимизировано для доступа в реальном масштабе времени. В варианте осуществления изобретения, административная область использует подход коллективной аренды для управления доступом. Таким образом, каждому "арендатору" (к примеру, клиентское приложение) выделяется одно или более поддеревьев в рамках административной области, и он имеет доступ только к записям в рамках тех поддеревьев, даже когда записи совместно используют общие классы объектов и типы атрибутов с записями в других поддеревьях и, следовательно, совместно используют ACI 1217.

ACU 1201 выполнен с возможностью принимать решения по управлению доступом от имени сервера 1213 операций с каталогом при обработке операций с каталогом, принимаемых от запрашивающих объектов, таких как клиентские приложения, конечные пользователи и другой DSA, пытающийся выполнять операцию сцепления, согласно варианту осуществления изобретения. Например, пользователь 1203 может запрашивать операцию для записи 504c, тогда как пользователь B 1205 может запрашивать изменение записи 504e. Сервер 1213 операций с каталогом, аналогично серверу 1109 операций с каталогом, показанному на фиг. 11A и фиг. 11C, представляет объект, выполненный с возможностью принимать запросы данных и затем предоставлять их в соответствующие процессоры, ассоциированные с сервером каталогов, с тем, чтобы запрошенная операция могла выполняться, согласно варианту осуществления изобретения. Например, LDAP-сервер должен представлять сервер операций с каталогом, такой как сервер 1213 операций с каталогом. Сервер 1213 операций с каталогом использует ACU 1201 для того, чтобы принимать решения о том, разрешено ли всем, части или ни одной из запрошенных операций продолжаться, и аналогично, разрешен ли возврат всех, части или ни одного из результатов отправителю, согласно варианту осуществления изобретения.

Модуль 1215 адаптации протоколов безопасности анализирует входящие операции на сервере 1213 операций с каталогом, согласно варианту осуществления изобретения. Модуль 1215 адаптации протоколов безопасности работает способом, образом, аналогичным способу модуля 1107 адаптации протоколов, показанного на фиг. 11A и фиг. 11C. Как и модуль 1107 адаптации протоколов, модуль 1215 адаптации протоколов безопасности может модифицировать входящие операции с каталогом согласно одному или более выбранных правил (набору правил). Модуль адаптации протоколов безопасности выполнен с возможностью работать до взаимодействия между 1213 сервером операций с каталогом и ACU 1201. Следует отметить, что использование модуля 1215 адаптации протоколов безопасности не препятствует использованию модуля 1107 адаптации протоколов на тех же или других этапах обработки входящих операций. Аналогично, модуль 1107 адаптации протоколов может быть выполнен с возможностью предлагать расширенный набор функциональности, предлагаемой посредством модуля 1215 адаптации протоколов безопасности.

Модуль 1215 адаптации протоколов безопасности может быть выполнен с возможностью сопоставлять базовое имя входящей операции с набором префиксов имен, согласно варианту осуществления изобретения. Набор префиксов имен, которые должны сопоставляться, может быть выполнен для запрашивающего объекта (к примеру, клиентского приложения, такого как пользователь 1203), который инициировал запрошенную операцию. Набор префиксов имен предоставляет критерии выбора правил и может постоянно размещаться в конфигурационных данных 1210 и/или постоянно размещаться в модуле каталога, таком как DIT 600.

Согласно варианту осуществления изобретения, самый длинный совпадающий префикс имени идентифицирует правило, которое должно использоваться. Например, если клиентское приложение запрашивает операцию для записи "A, B, C, D, E", где A-E - это RDN в LDAP-команде и есть правила, сконфигурированные с префиксами имен "E", "C, D, E", "B, C, D, E" и "Z, B, C, D, E", то выбранное правило - это правило с префиксом имени "B, C, D, E", поскольку он представляет самый длинный префикс в наборе правил, который совпадает с вводом "A, B, C, D, E". Согласно варианту осуществления изобретения, выбранный набор правил может содержать ассоциированное действие, такое как: "ответ с ошибкой", "регистрация попытки операции", или "продолжать работу по мере приема, но при условии другого пользователя и/или уровня аутентификации (эффективного пользователя) в целях управления доступом". Во втором случае, когда ACU 1201 впоследствии используется для того, чтобы принимать решения по управлению доступом, эффективный пользователь используется, приводя к различным решениям по управлению доступом, принимаемым в зависимости от комбинации исходного пользователя и совпадающего префикса имени. Другими словами, результатом является схема управления доступом на уровне схемы, которая, однако, предоставляет управление доступом на уровне поддерева, согласно варианту осуществления изобретения. В принципе, этот подход может применяться вниз вплоть до уровня отдельных записей.

Например, как показано на фиг. 12, пользователь A 1203 и пользователь B 1205 - это внешние пользователи. Дополнительно допустим, что ACU 1201 административной области сконфигурирован так, что ни пользователь A 1203, ни пользователь B 1205 не имеют разрешение на чтение или запись для любой записи в DIT 1200. Дополнительно допустим, что созданы два специальных пользователя, пользователь R 1207 и пользователь W 1209. Пользователь R 1207 имеет разрешения на чтение для любых записей абонента в DIT 1200, а пользователь W 1209 имеет разрешения на чтение или записи для любых записей абонента в DIT 1200. Еще дополнительно допустим, что внешним клиентским приложениям, таким как пользователь А 1203, не разрешено связываться ни как пользователь R 1207, ни как пользователь W 1209.

Соответственно, модуль 1215 адаптации протоколов безопасности обнаруживает правило в конфигурационных данных 1210 так, что если пользователь A выполняет операцию для записи в рамках поддерева с префиксом имени "P1" (т.е. любой из записей 504a, 504c, 504d), эффективный пользователь берется как пользователь W 1209. Для всех других операций эффективным пользователем остается пользователь А 1203. Модуль 1215 адаптации протоколов безопасности также включает в себя второе правило так, что если пользователь B 1205 выполняет операцию для записи в рамках поддерева с префиксом имени "P1", эффективный пользователь берется как пользователь R 1207, и третье правило, что если пользователь B 1205 выполняет операцию для записи в рамках поддерева с префиксом "P2", (т.е. любой из записей 504b, 504e), эффективный пользователь берется как пользователь W 1209. Для всех других операций эффективный пользователь остается как пользователь B 1205.

Результат этих трех правил заключается в том, что пользователь A 1203 имеет доступ на чтение/запись только к записям в рамках поддерева P1, а пользователь B 1205 имеет доступ на чтение к записям в рамках поддерева P1, а также имеет доступ на чтение/запись к записям в рамках поддерева P2.

Как в случае с модулем 1107 адаптации протоколов, модуль 1215 адаптации протоколов безопасности может быть выполнен с возможностью работать после преобразования имен, но до оставшейся части обработки операции, согласно варианту осуществления изобретения. Это означает, что результирующее управление доступом поддерева может быть основано на полностью разыменованных псевдонимах, без необходимости конфигурировать какое-либо управление доступом по самим именам псевдонимов. Таким образом, если абоненты имеют множество идентификационных данных, и доступ к ним осуществляется через псевдонимы, представляющие эти идентификационные данные, только действительные записи, представляющие абонентов, должны группироваться в поддеревья в целях управления доступом, согласно варианту осуществления изобретения. Соответственно, модуль 1215 адаптации протоколов безопасности, аналогично модулю 1107 адаптации протоколов, может взаимодействовать с модулем 909 преобразования имен, показанным на фиг. 9B, согласно варианту осуществления изобретения. Аналогично, хотя и не показано на фиг. 12, модуль 1215 адаптации протоколов безопасности может взаимодействовать с другими компонентами маскировки псевдонимов, показанными на фиг. 9B, согласно варианту осуществления изобретения. Аналогично, хотя не показано на фиг. 12, модуль 1215 адаптации протоколов безопасности может взаимодействовать с обработкой вариантов, такой как обработка вариантов, показанная на фиг. 10B, согласно варианту осуществления изобретения. Таким образом, например, компоненты обработки вариантов, ассоциированные с сервером 1007 операций с каталогом, показанным на фиг. 10B, могут быть ассоциированы с сервером 1213 операций с каталогом, показанным на фиг. 12, согласно варианту осуществления изобретения.

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

Информационная система мобильных абонентов

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

Проблема зачастую возникает при попытке реализовывать крупномасштабную систему сервера каталогов с пересечением географических/сетевых границ, где производительность сети/время задержки является непрогнозируемой, негарантируемой и/или, в общем, ограниченной. Эта ситуация зачастую возникает в развертываниях, где используются линии спутниковой связи (к примеру, Индонезийские острова) или соединения на дальние расстояния (к примеру, Северная Америка с Европой/Великобританией). В таком развертывании репликация в реальном времени данных на дальние расстояния зачастую является непрактичной, и сцепление в реальном времени запросов согласно X.500, чтобы поддерживать "единый логический каталог" для всех местоположений, также зачастую является непрактичным вследствие больших времен задержки передачи для IP-пакетов. Например, передача IP-пакета в одну сторону из Нью-Йорка, штат Нью-Йорк в Сиэтл, штат Вашингтон может превышать 50 мс в любой данной сети североамериканского оператора. Однозначно, время задержки передачи, не включая времена обработки каталога, превышает максимальное время, в течение которого клиентские приложения могут ожидать ответа на обновление или на запрос во многих случаях.

Решения этой проблемы связи должны минимизировать ширину полосы пропускания, требуемую между узлами развертывания, имеющими проблемы с полосой пропускания/временем задержки, при этом одновременно предлагая единый логический каталог, в котором любая система сервера каталогов может обслуживать все данные, развернутые посредством распределенного решения, согласно варианту осуществления изобретения. Такое решение, например, может поддерживать HSS, который охватывает Северную Америку и Великобританию, или один логический HLR, охватывающий Индонезийские Острова.

В варианте осуществления информационной системы мобильных абонентов, данные профиля абонента динамически хостятся посредством DSA 1302 на основе локальности ссылки/доступа способом, аналогичным способу, которым традиционные беспроводные сети поддерживают перемещающиеся части беспроводного профиля абонента (к примеру, заданный согласно GSM или ANSI-41 профиль абонента) из HLR 307 (базы данных мобильности в собственной сети) в VLR 303 (базы данных мобильности, размещенной совместно с коммутирующими средствами в сети, к которой абонентское устройство в настоящий момент присоединено) на основе точки подключения к сети/доступа абонента. После начального присоединения к сети VLR содержит все необходимые данные об абоненте и устройстве, чтобы давать возможность локальной коммутационной системе осуществлять вызовы; если данные не находятся локально, время установления соединения может становиться чрезмерным, если с удаленным HLR необходимо контактировать каждый раз, когда вызов должен обрабатываться. Этот принцип HLR-VLR и ассоциированные профили являются очень специфичными для беспроводной технологии и технических требований (GSM/ANSI-41) и не могут быть, в целом, применены к каким-либо данным профиля абонента для какого-либо типа сети связи. Данные абонентов совершенствуют этот принцип до намного более универсального уровня, который является независимым от типа сети доступа, в которой он развертывается, а также предоставляют универсальный профиль абонента, который допускает обслуживание потребностей в данных любого приложения базовой сети для обмена данными в реальном времени, согласно варианту осуществления изобретения. Информационная система мобильных абонентов основана на сильно распределенном и масштабируемом каталоге X.500, согласно варианту осуществления изобретения. Каталог X.500 дает возможность географического распределения данных профиля абонента, при этом одновременно отображаясь для сетевого клиента как единая логическая база данных, в которой любые данные могут извлекаться из любого сервера каталога X.500. В случае если развертывание помещает различные DSA в различные географические регионы, что приводит к значительным временам задержки передачи, как описано выше, варианты осуществления информационной системы мобильных абонентов обнаруживают, когда клиентский доступ к данным превышает конфигурируемые минимальные пороги качества обслуживания, и динамически передает данные профиля абонента из удаленного DSA в локальный DSA, где к ней в настоящий момент осуществляется доступ. Таким образом, в информационной системе мобильных абонентов, данные хостятся в DSA близко к тому месту, где они используются, когда они используются, исключая необходимость реплицироваться или сцепляться по скрытым соединениям для каждого запроса, при этом одновременно предоставляя объединенный каталог для инициализации. Дополнительные варианты осуществления информационной системы мобильных абонентов предоставляют возможность независимого перемещения конкретных для услуги или приложения частей или поднаборов данных профиля абонента на основе аналогичных принципов, описанных выше. Таким образом, это конкретное для абонента и услуги расширение информационной системы мобильных абонентов делает возможным перемещение конкретных для приложения/услуги данных и дает возможность нахождения различных данных абонентов в различных DSA, одновременно давая возможность осуществления доступа к ним локально, где они необходимы, согласно варианту осуществления изобретения.

В этом подходе, данные первоначально инициализируются в конкретном DSA, таком как DSA 1302a; тем не менее, при начальном доступе, например, из запроса или обновления, от удаленного DSA, такого как DSA 1302c, данные абонентов переносятся один раз на удаленный DSA в поддержку запроса/обновления. Удаленный DSA предположительно является локальным DSA для абонента или приложения, действующего от имени абонента. После передачи данных все локальные запросы, заключающие в себе эти данные абонентов, выполняются локально в DSA, согласно варианту осуществления изобретения. По сути, вариант осуществления информационной системы мобильных абонентов реализует универсальный профиль пользователя абонента, типично задаваемый посредством CSP, и данные являются мобильными на основе точки доступа к базе данных (к примеру с использованием такого протокола, как LDAP или DAP). Таким образом, например, данные перемещаются, если качество обслуживания не удовлетворяется вследствие чрезмерных времен задержки передачи и других характеристик передачи, и показатели удовлетворяются или не удовлетворяются, согласно варианту осуществления изобретения.

Допустим, например, что данные абонентов для HSS 1305 первоначально инициализированы в DSA 1302a. Дополнительно допустим, что часть этих данных абонентов, ассоциированных с абонентом 1309a, сконфигурирована так, чтобы подходить для передачи. Когда абонент 1309a (и/или устройство или сервер, представляющий абонента) взаимодействует с HSS 1305 так, что запрос и/или обновление данных должно быть запрошено, то DSA 1302a передает данные абонента в DSA 1302c, который находится ближе (и, следовательно, предоставляет более быстрый доступ вследствие меньших времен задержки передачи) к абоненту 1309a, чем DSA 1302a. После этой передачи DSA 1302c должен хранить и отвечать за данные абонента 1309a, связанные с HSS 1305.

Аналогично, допустим, что данные абонентов для HLR 1307 первоначально инициализированы в DSA, 1302d, расположенном на острове 1303. Дополнительно допустим, что часть этих данных абонентов, ассоциированных с абонентом 1309b, сконфигурирована как подходящая для передачи. Когда абонент 1309b (устройство или сервер, представляющий абонента) взаимодействует с HLR 1307 так, что запрос и/или обновление данных должно быть запрошено, то DSA 1302d передает данные абонента в DSA 1302e, который находится на острове 1304 и ближе абоненту 1309b, чем DSA 1302e, тем самым предоставляя более быстрый доступ к данным. После этой передачи DSA 1302e должен хранить и отвечать за данные абонента 1309b, связанные с HLR 1307.

Фиг. 13B иллюстрирует характерные компоненты, содержащие информационную систему мобильных абонентов, такую как проиллюстрированная на фиг. 13A, согласно варианту осуществления изобретения.

Модуль 1312a перенаправления событий NSD постоянно размещается в точке доступа репозитория данных в DSA 1302a и отслеживает запросы на доступ к профилям абонентов (к примеру, мониторинг доступа LDAP) в репозитории 1318a, а затем измеряет времена отклика в сравнении с конфигурационными данными 1320, такими как предварительно сконфигурированный профиль качества обслуживания, согласно варианту осуществления изобретения. Если модуль 1312a перенаправления событий NSD обнаруживает, что доступ абонента (к примеру, операции LDAP) превышает пороги для допустимой производительности клиентских приложений, заданной посредством конфигурационных данных 1320, то модуль перенаправления событий NSD отправляет эти события, с соответствующими сведениями для конкретных данных профиля абонента, в диспетчер 1314 переноса NSD. Модуль 1312a перенаправления событий NSD типично постоянно размещается в DSA, выполненных с возможностью предоставлять доступ к хранилищу профилей абонентов, таких как DSA 1302, показанные на фиг. 13A. Таким образом, информационная система мобильных абонентов может содержать несколько экземпляров модуля 1312 перенаправления событий NSD, согласно варианту осуществления изобретения.

Диспетчер 1314 переноса NSD предоставляет централизованную точку сбора для событий, перенаправляемых из распределенных модулей 1312 перенаправления событий NSD, согласно варианту осуществления изобретения. Диспетчер 1314 переноса NSD сопоставляет события, принимаемые от модулей 1312 перенаправления событий NSD, и определяет на основе конфигурационных данных 1320, таких как предварительно сконфигурированное качество обслуживания и профили производительности, когда/как перемещать данные профиля абонента из одного DSA в другой, к примеру из DSA 1302a в DSA 1302b, показанный на фиг. 13B. Диспетчер 1314 переноса NSD может постоянно размещаться в одном или более специализированных DSA или может существовать на отдельной и/или внешней платформе управления/инициализации, согласно варианту осуществления изобретения.

Контроллер 1316 переноса NSD управляет перемещением профилей абонента из исходного DSA (к примеру, DSA 1318a) в целевой DSA (к примеру, DSA 1312b), как инструктировано посредством диспетчера 1314 переноса NSD. Контроллер 1316 переноса NSD обеспечивает, что корректные данные абонентов или поднабор абонента перемещаются неповрежденными без ошибок в новый DSA, согласно варианту осуществления изобретения. Контроллер 1316 переноса NSD может одновременно обеспечивать, что все соответствующие привязки каталога (привязки к иерархическим объектам - HOBS) надлежащим образом изменены и/или сохранены, согласно варианту осуществления изобретения. Если ошибка, такая как перебой в работе сети, сбой сервера DSA или другая проблема, не допускает успешную передачу данных профиля абонента, контроллер 1316 переноса NSD обеспечивает, чтобы исходное местоположение данных абонентов сохранялось таким, как было до того, как предпринята передача. Контроллер 1316 переноса NSD использует традиционные возможности для того, чтобы выполнять такие перемещения (к примеру, поддержка транзакций с каталогом и LDAP), согласно варианту осуществления изобретения. Таким образом, весь профиль абонента или поднабор профиля абонента может быть безопасно передан из одного DSA в другой. Аналогично диспетчеру 1314 переноса NSD, контроллер 1316 переноса NSD может постоянно размещаться в одном или более специализированных DSA или может существовать на отдельной и/или внешней платформе управления/инициализации, согласно варианту осуществления изобретения.

Подход NSD, в общем, не предназначается для границ между DSA 1302, где точка доступа к данным изменяется в реальном времени, к примеру, для ситуации, которая может возникать для абонента, ведущего машину вдоль граничной сети, обслуживаемой посредством двух соседних точек доступа. В таких ситуациях, более традиционное развертывание сервера данных (т.е. немобильно), вероятно, должно быть предпочтительным, поскольку любой из соседних DSA, вероятно, обслуживает запросы на доступ к данным и обновления данных с соответствующим QOS. В этой ситуации, система NSD может быть выполнена с возможностью препятствовать тому, чтобы данные становились мобильными, с использованием нескольких подходов. Диспетчер 1314 переноса NSD может быть выполнен с возможностью запрещать передачу профилей абонента между двумя географически смежными DSA или между DSA, время задержки на обмен данными которых является очень низким (т.е. нет реального преимущества в перемещении данных). Дополнительно, диспетчер 1314 переноса NSD может быть выполнен с возможностью определять, когда возникает перегрузка между двумя узлами DSA. Здесь, перегрузка, в общем, означает частое перемещение профилей абонента туда и обратно между этими DSA. В этой ситуации диспетчер 1314 переноса NSD может сужать или сокращать перемещение посредством более строгих критериев передачи, например повышения приоритета, требуемого посредством клиентского приложения для того, чтобы инструктировать передачу, увеличение числа запросов посредством клиента для того, чтобы инструктировать осуществление передачи, или просто вообще запрещать передачи между DSA.

Фиг. 13C иллюстрирует характерные конфигурационные данные 1310 для DSA, участвующего в информационной системе мобильных абонентов, согласно варианту осуществления изобретения. Конфигурационные данные 1310 могут постоянно размещаться в файле 1320 конфигурационных данных, показанном на фиг. 13B. Конфигурационные данные 1310 для информационной системы мобильных абонентов могут включать в себя такие данные, как:

- Данные, указывающие то, разрешено/запрещено ли DSA участвовать в обменах данными по запросу 1312a. Как показано в данных 1310, DSA 1302a разрешено участвовать в обменах по запросу. В частности, DSA 1302a разрешено участвовать в обменах с DSA 1302c.

- Ограничения 1312b на секции или поднаборы DIT, такого как DIT 600, которыми можно обмениваться между конкретными DSA. Ограничения 1312b, показанные для данных 1310, указывают то, что можно обмениваться только данными для абонентов в Калифорнии, Вашингтоне, Орегоне, Неваде и Аризоне для этого конкретного DSA, и

- Другие ограничения 1312c на такие факторы, как диапазоны значений данных, максимальный размер данных, время дня и т.д., которые могут оцениваться перед тем, как выполняется обмен данными между DSA. Другие примерные ограничения 1312c, показанные для данных, указывают, что запрещены передачи защищенных данных, таких как пароли, и одна передача данных не может превышать 50 Мегабайт. Эти ограничения представляют просто примеры некоторых из других ограничений, которые могут накладываться на передачи данных, согласно вариантам осуществления изобретения.

Другие ограничения 1312c, которые могут использоваться, включают в себя размер передаваемых данных, который может быть конфигурируемым, и эта настройка может быть определена на основе времен задержки, вовлеченных в передачу, и передачу размера данных как допустимого для клиентских приложений, например, 50 Кбайт, 500 КБ, 1 МБ, 10 МБ, согласно варианту осуществления изобретения. Другим ограничением могут быть конфиденциальные и/или защищенные данные/атрибуты, которые не могут передаваться вследствие ограничений безопасности. Например, паролям пользователя может быть запрещено передаваться по соединениям, которые не защищены и/или зашифрованы. Еще одним ограничением могут быть уровни нагрузки в сети. Например, уровни занятости линии связи могут отслеживаться с тем, чтобы определять, что данные не должны передаваться в течение конкретных периодов времени данных, когда уровни занятости достигают максимума. Еще дополнительно, может приниматься во внимание режим работы DSA. Например, передачи данных могут быть запрещены в течение состояний, когда связанные DSA находятся в состоянии перегрузки, или связанные DSA находятся в состоянии сниженной пропускной способности (к примеру, один из узлов DSA поврежден). Наконец, другие части данных профиля абонента могут быть заданы, чтобы быть немобильными или статическими по характеру, так что данные не должны быть перемещены в точке доступа. Они могут включать в себя статическую информацию, используемую посредством BSS, такую как адрес абонента.

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

Компоненты NSD предварительно сконфигурированы для обмена данными абонентов по требованию (этап 1320). Участвующие DSA D1 и D2, такие как DSA 1302a и 1302c, показанные на фиг. 13A, предварительно сконфигурированы так, чтобы обмениваться данными абонентов друг с другом по требованию. Дополнительно, релевантный модуль(и) перенаправления событий NSD, такой как модуль 1312a перенаправления событий NSD, диспетчер 1314 переноса NSD и контроллер переноса NSD, наряду с конфигурационными данными 1320, должны быть подготовлены, согласно варианту осуществления изобретения. Процесс предварительного конфигурирования должен включать в себя данные, такие как конфигурационные данные 1310, показанные на фиг. 13B.

Данные абонентов для S1 находятся в распоряжении DSA D1 (к примеру, DSA 1302a) и сконфигурированы для передачи в DSA D2 (к примеру, DSA 1302c) (этап 1322). Здесь, S1 представляет тот поднабор DIT, связанного с абонентом или услугой/приложением абонента, которой может передаваться из DSA D1 в DSA D2 (к примеру, из DSA 1302a в DSA 1302c).

Как пояснено на фиг. 13B, правила и приемлемость конкретных данных, которые должны передаваться, управляются посредством модуля перенаправления событий NSD и диспетчера переноса NSD, согласно варианту осуществления изобретения. Условия, если таковые вообще имеются, для этой передачи могут задаваться в конфигурационных данных, таких как конфигурационные данные 1310, показанные на фиг. 13C. Например, данные S1 абонентов могут быть ограничены конкретным поднабором профиля абонента, таким как запись (или записи) конкретной услуги/приложения, либо даже конкретным поднабором атрибутов записи профиля абонента. S1 также может включать в себя ограничения на то, является ли весь профиль абонента передаваемым как единой целое, или отдельные поднаборы профиля (к примеру, конкретные данные для приложения) являются отдельно и одновременно передаваемыми. Здесь, например, S1 может разрешать мобильность всего профиля абонента, в том числе всех поддеревьев/поднаборов и всех включенных данных приложений/услуг. Другой пример может запрещать мобильность всего профиля абонента, а разрешать мобильность только сконфигурированных поддеревьев/поднаборов конкретных для приложений/услуг профилей. Как пояснено на фиг. 13B, каждый DSA, участвующий в информационной системе мобильных абонентов, имеет модуль перенаправления событий NSD, сконфигурированный с конкретным качеством обслуживания (QoS) и профилем критериев передачи для доступа к данным абонентов, согласно варианту осуществления изобретения. Этот профиль задает, например, порог на время задержки запроса (к примеру, время задержки запроса LDAP), в котором передача профиля абонента может рассматриваться.

DSA D1 принимает запрос (к примеру, LDAP-поиск или обновление) для набора данных абонентов в пределах S1, которые в настоящий момент сохранены в DSA D2 (этап 1324). Как правило, анализ QOS и критериев передачи и последующее перемещение данных абонентов является конкретным для одного запроса по одному профилю абонента. Тем не менее, должно быть возможным конфигурировать DSA D1 так, чтобы передавать соответствующие данные абонентов, согласно S1, для данного набора абонентов при запросе на данные для одного абонента в рамках набора, согласно варианту осуществления изобретения.

Запрос данных типично обрабатывается так, как любой другой запрос должен обрабатываться посредством DSA D1 и DSA D2. Например, при использовании принципов протоколов X.500, запрос может сцепляться из DSA D1 через корневой DSA с DSA D2, где запрос выполняется, и ответ возвращается через тот же самый тракт запроса.

Согласно варианту осуществления изобретения, модуль перенаправления событий NSD DSA D1 анализирует запрос данных и ассоциированные характеристики быстроты отклика и производительность и ассоциированные характеристики быстроты отклика и производительность и определяет то, превышен ли порог для передачи набора S1 данных (этап 1326). Примерный порог может заключаться, например, в том, что допустимое время задержки запроса LDAP превышено. Если порог не превышен (этап 1326), то модуль перенаправления событий NSD возвращается к обычной обработке.

Если порог превышен (этап 1326), то модуль перенаправления событий NSD DSA D1 инициирует событие перенаправления для диспетчера переноса NSD (этап 1328).

Диспетчер переноса NSD принимает событие перенаправления, наряду с другими, возникающими одновременно в системе, определяет то, гарантирована ли передача, и если да, то инструктирует контроллеру переноса NSD инициировать передачу профиля абонента из DSA D1 в DSA D2 (этап 1330). При определении того, оправдана ли передача, диспетчер переноса NSD может проверять такие элементы, как степень исправности и состояние перегрузки компонентов затронутой системы и сети, согласно варианту осуществления изобретения. Если передача не оправдана (этап 1330), то диспетчер переноса NSD возвращается к обычной обработке.

Если передача оправдана (этап 1330), то диспетчер переноса NSD запрашивает контроллер переноса NSD считывать набор данных абонентов, заданный и/или ограниченный посредством S1, который должен быть передан из DSA D1, инициировать транзакцию базы данных, чтобы удалять набор S1 данных абонентов из DSA D1, и затем инициировать транзакцию, чтобы добавлять набор S1 данных абонентов в DSA D2 (этап 1332). После успешного завершения транзакции, чтобы добавлять набор S1 данных абонентов в DSA D2, диспетчер переноса NSD запрашивает, чтобы транзакция удаления в DSA D1 была зафиксирована, завершая передачу (этап 1332).

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

Когда S1 предоставляет возможность независимой и одновременной передачи поддеревьев/поднаборов профиля абонента в различные DSA, специализированная процедура может использоваться для того, чтобы обеспечивать то, что локальный доступ к перенесенному поддереву/поднабору профиля абонента, например поддереву HSS-приложения, не вызывает лишних сцеплений X.500 обратно в исходный DSA, где располагается корневая запись абонента, согласно варианту осуществления изобретения. Эта корневая запись абонента считается корнем всего поддерева профиля абонента и, следовательно, является вышестоящей для всех поднаборов или поддеревьев профиля абонента. Когда S1 диктует, чтобы весь профиль абонента немобильно перемещался из одного DSA в другой, корень абонента перемещается как часть профиля, и все ссылки/привязки на тот корень изменяются соответствующим образом, согласно варианту осуществления изобретения. Тем не менее, когда поднабор или поддерево профиля абонента перемещается, корень абонента не перемещается с поддеревом, поскольку, возможно, есть другие поддеревья, которые должны оставаться нетронутыми в DSA, в котором они в настоящий момент сохранены, согласно варианту осуществления изобретения. Чтобы исключать сцепления X.500 обратно к исходному DSA, где находится корень абонента, при локальном осуществлении доступа к перемещенному поддереву приложений в целевом DSA, корневая запись абонента дублируется в локальное теневое запоминающее устройство или копируется в локальный DSA, когда поддерево перемещается через процедуры, описанные в данном документе, согласно варианту осуществления изобретения. Это дает возможность локально инициированным запросам или обновлениям на конкретном для приложений поддереве выполняться локально, поскольку все DN (отличительное имя) целевой записи существуют в локальном DSA. Если DN поддерева приложений включает в себя другие записи между корнем абонента и корнем поддерева приложений, они также могут быть помещены в теневое запоминающее устройство, чтобы обеспечивать то, что локальная обработка данных возможна без сцеплений X.500, согласно варианту осуществления изобретения.

Дополнительный специализированный механизм может использоваться для того, чтобы обеспечивать то, что доступ к локально перенесенному профилю абонента или поддереву профиля абонента, от одного из многих возможных псевдонимов корневой записи абонента, приводит к локально удовлетворяемому ответу, согласно варианту осуществления изобретения. Корневые записи псевдонимов абонентов реализуются как стандартные записи псевдонимов в соответствии с X.500 или LDAP, согласно варианту осуществления изобретения. Эти записи псевдонимов содержат эталонный DN для записи, на которую они указывают. В этом варианте осуществления, корневой псевдоним абонента указывает на конкретную корневую запись абонента. Например, корневая запись абонента может иметь RDN "cn=William" с записью-псевдонимом, как RDN "cn=Bill", которое также содержит ссылку на корневую запись с "cn=William". В этом примере, если профиль абонента перемещается из DSA D1 в D2, псевдоним к нему остается в DSA D1. Запросы с использованием псевдонима записи приводят к запросу, сначала идущему в DSA D1, чтобы извлекать и разрешать псевдоним "cn=Bill" на корневую запись "cn=William", которая теперь располагается в DSA D2. Чтобы исключать необходимость извлекать псевдоним из D1, когда корень абонента находится в D2, псевдоним также перемещается наряду с профилем абонента или поддеревом профиля с использованием идентичных процедур NSD, заданных в данном документе. То, какой из множества псевдонимов должен быть перемещен, также может быть включено как часть критериев передачи и конфигурации, заданной в модуле перенаправления событий NSD, диспетчере переноса NSD и контроллере переноса NSD, согласно варианту осуществления изобретения. Таким образом, только конкретные псевдонимы могут передаваться на основе идентификационных данных клиента, осуществляющего доступ, приоритета клиента, осуществляющего доступ, или на основе псевдонима, используемого клиентом при инициировании доступа, активирующего мобильное перемещение данных абонентов.

В качестве альтернативы удалению набора S1 данных абонентов из DSA D1, контроллер переноса NSD может помечать профили абонента как остающиеся в теневом запоминающем устройстве (или кэшированные) в DSA D1 после того, как профиль успешно передан в целевой DSA, DSA D12, согласно варианту осуществления изобретения. "Неактивное" состояние должно указывать, что данные могут быть неактуальными и что есть "активная" копия, находящаяся в другом DSA. Этот подход может поддерживать восстановление после сбоев и снижение трафика, когда/если точка доступа для записей S1 в сети связи возвращается из DSA D2 в DSA D1 или, как показано на фиг. 13A, из DSA 1302c в DSA 1302a.

Все последующие доступы к DSA D1 для набора S1 данных абонентов затем могут выполняться локально из DSA D2, согласно варианту осуществления изобретения.

Система NSD может работать на основе профиля абонента, согласно варианту осуществления изобретения. Как правило, определенный процент абонентов CSP передвигается по территории покрытия. Следовательно, профиль абонента изменяется с изменением местоположения фактического пользователя-абонента при условии, что изменение вызывает недопустимое время задержки в сети. Альтернативно, набор S1 ограничений на данные абонентов может содержать группу абонентов, хотя может быть сложным определять то, как группировать абонентов в мобильные наборы. Аналогично, набор S1 может содержать часть профиля абонента или даже части профилей абонентов из набора абонентов.

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

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

Альтернативно, как описано выше, функциональность NSD может включать в себя возможность изменять степень детализации передаваемых данных абонентов. Как пояснено выше, весь профиль абонента переносится из одного DSA в другой. Тем не менее, допустим, что два различных клиента с высоким приоритетом осуществляют доступ к профилю абонента согласованно из двух различных точек доступа, каждый из которых требует различных поднаборов данных абонентских услуг. Соответственно, функциональность NSD, такая как модуль перенаправления событий NSD и/или диспетчер переноса NSD, может включать в себя возможность разбиения самого профиля абонента на поднаборы или поддеревья компонентов услуг (к примеру, данные об HSS-услугах, данные об HLR-услугах, данные о предоплатных услугах) и иметь каждый из отдельных поднаборов, который может быть независимо мобильным на основе таких факторов, как точка доступа, клиентская система, осуществляющая доступ, профиль QOS, конечно, согласно варианту осуществления изобретения. В этом альтернативном варианте осуществления, только одна копия профиля абонента должна существовать в любое время (с возможным исключением корневых или подкорневых записей в теневом запоминающем устройстве, которые хранят локально сохраненные DN, чтобы исключать сцепления X.500), но ее составные части (услуги) должны быть распределены по различным DSA на основе локальности доступа и QOS.

В качестве еще одной другой альтернативы, вместо передачи и удаления набора S1 данных абонентов система NSD может быть выполнена с возможностью кэшировать набор S1 данных абонентов в нескольких DSA на основе таких факторов, как точка доступа и профили QOS, согласно варианту осуществления изобретения. В этом варианте осуществления, система NSD также должна включать в себя механизм, чтобы синхронизировать несколько копий, чтобы обеспечивать целостность данных. Механизм синхронизации может быть добавлен в компонент, такой как диспетчер 1314 переноса NSD, согласно варианту осуществления изобретения.

Процессы протоколирования и резервирования

Фиг. 14 иллюстрирует систему 1400 протоколирования, согласно варианту осуществления изобретения. Система 1400 протоколирования включает в себя базу 1403 данных в оперативной памяти, такую как репозиторий 708a данных, показанный на фиг. 7A, обновление 1402, журнал 1404 в оперативной памяти, файл 1409 с резервной копией и один или более журнальных файлов 1406a-1406c, модуль 1411 репликации/синхронизации, модуль 1413 записи информации резервной копии и т.д. Журнал 1404 в оперативной памяти включает в себя список обновлений 1408a-1408g и т.д.

В ходе применения реплицированных обновлений, модуль 1411 репликации/синхронизации может управлять процессом репликации обновлений одного или более DS. Модуль 1411 репликации/синхронизации типично ассоциирован с сервером каталогов, таким как DS 706, показанный на фиг. 7A. В частности, DS модуля 1411 репликации/синхронизации может быть основным DS в рамках DSA, такого как DSA 702. Как упомянуто выше, DSA типично имеет первичный DS с любым числом вторичных DS, каждый из которых имеет собственную базу 1403 данных в оперативной памяти, согласно варианту осуществления изобретения. Обновления 1402 типично выполняются в основном DS в рамках DSA и затем реплицируются на другие DS в DSA, согласно варианту осуществления изобретения. Конечно, модуль 1411 репликации/синхронизации может находиться на любом из DS в рамках DSA, согласно варианту осуществления изобретения.

Модуль 1411 репликации/синхронизации применяет обновления 1408a-1408g к базе 1403 данных в оперативной памяти. Дополнительно, в различных вариантах осуществления изобретения, сервер каталогов также сохраняет подробности транзакций в репозитории данных, представляемом посредством базы 1403 данных в оперативной памяти в журнале 1404 в оперативной памяти. Информация, сохраненная в журнале в оперативной памяти, может включать в себя изменения, произведенные в записях, время изменений и увеличивающийся идентификатор для каждого изменения и состояние записи до изменения (к примеру, значение изменялось в обновлении), согласно варианту осуществления изобретения. Далее, в варианте осуществления изобретения, через равные интервалы времени или максимально быстро данные факторы, такие как ограничения дисковой подсистемы, выполненные транзакции из журнала 1404 в оперативной памяти записываются в дисковый журнальный файл 1406 в качестве постоянной записи транзакции.

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

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

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

Журнальные файлы 1406 являются ключевым компонентом при восстановлении узла после планового отключения или сбоя сервера, согласно варианту осуществления изобретения. В различных вариантах осуществления изобретения, когда модуль 1411 репликации/синхронизации использует журнальные файлы 1406 вместе с файлом 1409 с резервной копией, база 1403 данных в оперативной памяти может быть восстановлена к последней транзакции, успешно выполненной перед запланированным отключением (или сбоем), тем самым минимизируя число транзакций, которые первичный сервер впоследствии должен повторно передавать, чтобы синхронизировать восстановленный вторичный сервер (к примеру, DS, хранящий базу 1403 данных в оперативной памяти).

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

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

При восстановлении из резервной копии модулю 1411 репликации/синхронизации, ассоциированному с базой 1403 данных в оперативной памяти, необходимы файл 1409 с резервной копией и журнальные файлы 1406, по меньшей мере, для операций обновления, выполненных в течение периода резервирования. В варианте осуществления изобретения, модуль 1411 репликации/синхронизации сначала восстанавливает записи из их описаний в файле 1409 с резервной копией. Модуль 1411 репликации/синхронизации затем воспроизводит из ассоциированных журнальных файлов 1406 все операции обновления, которые осуществлялись в течение периода резервирования, в порядке, в котором они осуществлялись, допуская возможность того, что обновление применено или не применено к записи к тому времени, когда описание этой записи записано в файл 1409 с резервной копией. Модуль 1411 репликации/синхронизации необязательно может применять обновления, которые осуществлялись после периода резервирования, в порядке, в котором они осуществлялись либо до фиксированной точки во времени, либо до фиксированного идентификатора изменения, либо до тех пор, пока все доступные обновления не применены. Восстановленный DS теперь находится в позиции, чтобы синхронизироваться с обновлениями, которые осуществлялись на других DS в рамках DSA после того, как последнее обновление применено из журнального файла.

Модуль 1411 репликации/синхронизации может анализировать и использовать информацию, сохраненную в модуле 1413 записи информации резервной копии, во время процедуры восстановления, согласно варианту осуществления изобретения. Модуль 1413 записи информации резервной копии выполнен с возможностью записывать начальное время и конечное время для периода резервирования, ассоциированного с файлом 1409 с резервной копией, и идентификатор начала изменения, который идентифицирует первое обновление 1402 для базы 1403 данных в оперативной памяти после того, как резервирование начато, и идентификатор окончания изменения, который идентифицирует конечное обновление базы 1403 данных в оперативной памяти до того, как резервирование завершено. Эта информация может использоваться для того, чтобы идентифицировать минимальный набор обновлений, которые должны применяться, чтобы обеспечивать непротиворечивость восстановленной резервной копии, согласно варианту осуществления изобретения.

Ориентированный на абонентов каталог

Фиг. 15A является блок-схемой, иллюстрирующей иерархию данных, хранимых в каталоге 1500, таких как данные, используемые посредством HSS 301, показанного на фиг. 3, согласно варианту осуществления изобретения. Когда HSS 301 запущен, обновления в каталог 1500 типично добавляют или модифицируют данные абонентов и инициируются из различных доменов, таких как IMS-домен 214, показанный на фиг. 2. Например, каталог 1500 может предоставлять информацию для аутентификации во время процедур AAA, предоставлять информацию о профиле услуг во время регистрации и хранить прозрачные данные об услугах для различных услуг.

Каталог 1500 типично предоставляет единый логический каталог для сети мобильной связи, такой как каталог, соответствующий стандарту каталога ITU-T X.500. Каталог 1500 использует иерархическую древовидную структуру данных, обычно называемую информационным деревом каталогов (DIT), которое содержит различные записи каталога. Записи размещаются в форме дерева, при этом каждая запись может быть старшей для некоторого числа записей. Каталог 1500 начинается с корневого узла 1501. Разумеется, в некоторых вариантах осуществления каталога 1500, корневой узел 1501 сам может содержать несколько подкорневых узлов, которые совместно предоставляют корень каталога 1500. Например, один подкорневой узел может представлять модуль DIT, который относится только к данным абонентов для HSS - или даже только к части данных абонентов, используемых посредством одного HSS из множества HSS в большой системе мобильной связи.

Каталог 1500 хранит записи для абонентов в сети связи, такой как сеть 200 связи, согласно варианту осуществления изобретения. В каталоге 1500 идентификационные данные абонента могут быть секционированы на несколько доменов 1503a-1503d идентификационных данных. Чтобы отражать данные, ассоциированные с HSS 301, по меньшей мере, четыре конкретных записи домена могут предоставляться: IMSI-домен (IMSID), MSISDN-домен (MSISDND), домен конфиденциальных идентификаторов (privateD) и домен общедоступных идентификаторов (publicD). Эти домены представляются посредством записей псевдонимов, таких как запись 1505 MSISDNAlias, запись 1507 IMSIAlias, запись 1509 PublicIdAlias и запись 1511 PrivateIdAlias. Так, например, запись 1505 MSISDNAlias дает возможность осуществления доступа к подписке, такой как запись 1517 Subscription, через MSISDN 325, а также посредством уникального идентификатора, такого как предоставляемый посредством записи 1503c Domain. Аналогично, запись 1507 IMSIAlias дает возможность осуществления доступа к записи подписки, такой как запись 1517 Subscription, через IMSI 323, а также посредством уникального идентификатора. Аналогично, запись 1511 PrivateIDAlias дает возможность осуществления доступа к записи подписки, такой как запись 1517 Subscription, через PrivateID 327, а также посредством уникального идентификатора. Запись 1509 PublicIDAlias дает возможность осуществления доступа к записи подписки, такой как запись 1513 Subscription, через PublicID 329, а также посредством уникального идентификатора.

Запись 1513 Subscription представляет верхний уровень (или корень) данных абонентов. Запись 1513 Subscription представляет корень данных инициализации абонента для услуг, таких как HSS- или HLR-услуги. Соответственно, данные для HSS-услуги, HLR-услуги и других услуг хранятся как дочерние записи для записи 1513 Subscription. Например, эти записи могут содержать запись 1515 hssService, запись 1517 hlrService и другие услуги 1519. В варианте осуществления изобретения, глобально уникальный идентификатор, показанный посредством Domain 1503c, идентифицирует запись 1513 Subscription в показателях, распознанных посредством конкретного стандарта, такого как отличительное имя (DN) X.500. К записи 1513 Subscription также может осуществляться доступ через идентификационные данные с псевдонимом, такие как IMSI 323, MSISDN 325, PublicId 327 и PrivateId 329, как пояснено здесь.

Фиг. 15B является блок-схемой, иллюстрирующей архитектуру HSS, такого как HSS 301 CN 206, показанный на фиг. 3, согласно варианту осуществления изобретения.

HSS 301 может содержать несколько серверов, каждый из которых включает в себя HSS-приложение 1521, интегрированное с платформой 1523 сервера каталогов (DS), согласно варианту осуществления изобретения. Платформа 1523 сервера каталогов содержит, по меньшей мере, один DSA и DUA, как, к примеру, DS-платформа, показанная на фиг. 7A. Конечно, DS-платформа 1523 может содержать больше или меньше DSA, чем показано на фиг. 7A и на фиг. 7B. HSS 301 может включать в себя TCP/IP-интерфейс, чтобы запрашивать и обновлять данные в DS-платформе 1523 с использованием стандартных протоколов обмена данными, таких как DAP и LDAP. TCP/IP-интерфейс также может использоваться, например, чтобы инициализировать базу данных, когда новый абонент присоединяется к IMS-домену 214. Платформа 1523 сервера каталогов тем самым отвечает за такие задачи, как репликация и синхронизация данных, резервирование данных, предоставление автоматического обнаружения отказов и восстановления после сбоев.

HSS-приложение 1521 упрощает обработку транзакций абонентов и служебного трафика из различных доменов в базовой сети, таких как IMS-домен 214. В варианте осуществления изобретения, HSS-приложение 1521 типично принимает сообщение от данного домена, отформатированное согласно распознанному протоколу, к примеру сообщение, отформатированное согласно протоколу Diameter из IMS-домена 214. Сообщение Diameter, например, может запрашивать данные репозитория на сервере 1523 каталогов для данных, связанных с конкретным абонентом.

HSS 301 типично сохраняет и использует два основных типа данных. Во-первых, HSS 301 включает в себя данные инициализации, т.е. данные, связанные с абонентами и доступными услугами. Сохраненные данные инициализации типично включают в себя традиционные данные абонентов, такие как идентификационные данные CSCF 321 в IMS-домене 214, где подписка зарегистрирована, текущее состояние запрещения и данные профиля услуг. Во-вторых, HSS 301 включает в себя конфигурационные и управляющие данные, т.е. данные, связанные с общей операцией услуг HSS 301 и самой системой HSS 301, соответственно. Конфигурационные данные HSS 301, сохраненные на сервере 1523 каталогов, включают в себя следующее: правила удаленных объектов IMS, требуемые характеристики сервера и AS-разрешения.

Соответственно, вариант осуществления изобретения в данном документе предусматривает улучшенный HSS, который помогает CSP в реализации гибкой сетевой инфраструктуры, которая может реализовывать такие технологии как IMS, нелицензируемый диапазон для мобильной связи (UMA) и другие IP-услуги. В некоторых вариантах осуществления изобретения, улучшенный HSS совместим с HLR-платформами других поставщиков, выполнен с возможностью минимизировать нарушения в работе сети, предоставляет поддержку для нескольких параллельных способов доступа к сети и предоставлять гибкость пакетирования услуг для большего числа абонентов. Дополнительно, улучшенный HSS дает возможность CSP легко реализовывать новые услуги, консолидировать и конкретизировать бизнес-процессы и уменьшать оперативные затраты.

Совместно размещенная HSS/HLR и совмещенная HSS/HLR

Фиг. 16A и фиг. 16B являются блок-схемами, соответственно, иллюстрирующими совместно размещенную систему 1600 и совмещенную систему 1620 для HSS 301 и HLR 307, согласно варианту осуществления изобретения. Как в совместно размещенной системе 1600, так и в совмещенной системе 1620, HLR 307 и HSS 301 совместно используют каталог 1605, находящийся во внутреннем сервере 1603. Каталог 1605 содержит каталог, реализованный в одном или более DSA, таких как DSA 702, показанный на фиг. 7B, согласно варианту осуществления изобретения.

Варианты осуществления изобретения могут предоставлять один логический HSS и HLR. HSS 301 и HLR 307, показанные на фиг. 16A и фиг. 16B, фактически предоставляют единую логическую комбинацию HSS и HLR, как поясняется ниже. Поскольку CSP комбинируют новые услуги и используют IP-коммутацию, HLR 307 может становиться фокусной точкой для дополнительных улучшений в сети этих CSP. Дополнительно, HSS 301 может помогать CSP совершенствовать свои взаимоотношения с абонентами. Следовательно, единый логический HSS и HLR здесь могут улучшать традиционные сети.

Когда HSS 301 и HLR 307 устанавливаются на одном сервере, установка называется как "совместно размещенная установка HSS/HLR". Как показано на фиг. 16A, HSS 301 и HLR 307 находятся на внешнем сервере 1601. HSS 301 и HLR 307 совместно используют каталог 1605, установленный на внутреннем сервере 1603.

В варианте осуществления изобретения, внешний сервер 1601 может иметь распределенную архитектуру, так что HSS 301 и HLR 307 развертываются на нескольких серверах 1609, 1611, которые вместе составляют логический внешний сервер 1613. Как показано на фиг. 16B, когда HSS 301 и HLR 307 установлены на раздельных внешних серверах 1609, 1611, но совместно используют общий каталог 1605, установленный на внутреннем сервере 1603, установка упоминается как "совмещенная установка HSS/HLR". Таким образом, HSS 301 и HLR 307 совместно используют каталог 1605, установленный на внутреннем сервере 1603.

Если HSS 301 не использует каталог 1605 совместно с HLR 307, установка называется "автономный HSS". В таких установках HLR-данные типично постоянно размещаются в удаленном репозитории HLR-данных. Автономный HSS не иллюстрируется в данном документе, но эта архитектура известна в данной области техники.

Абонент мобильного домена, который имеет HLR-данные или либо в совместно размещенной системе 1600, или в совмещенной системе 1620, называется "находящимся в собственной сети абонентом". Абонент мобильного домена, который имеет HLR-данные в удаленном репозитории HLR-данных, называется "находящимся вне собственной сети абонентом".

UMS-режим

HSS 301 взаимодействует с HLR 307, чтобы предоставлять различные услуги для абонентов в IMS-домене 214, PS-домене 212 и CS-домене 210, как пояснено ранее. Это упоминается как режим работы сервера пользовательской мобильности (UMS) HSS 301.

UMS-режим обеспечивает плавную работу HSS как для совместно размещенных систем 1600, так и для совмещенных систем 1620, а также для автономного HSS. UMS-режим также обеспечивает плавную работу, если возникает ситуация, что некоторые абоненты в совместно размещенной системе 1600 или совмещенной системе 1620 находятся вне собственной сети по любой причине. То считается данный абонент "находящимся в собственной сети" или нет, определяется посредством того, доступны ли HLR-данные для этого абонента в каталоге 1605 во внутренней части 1603, согласно варианту осуществления изобретения. Другими словами, типичный процесс заключается в том, чтобы выполнять попытку считывания HLR-данных. Если это считывание выполняется, то абонент является "находящимся в собственной сети". Иначе абонент является находящимся вне собственной сети.

В UMS-режиме, HSS 301 работает в трех сценариях. В сценарии I, HSS 301 взаимодействует с удаленным HLR 307, который является режимом, который, в общем, хорошо приспосабливается посредством традиционных подходов. В сценарии II, HSS 301 взаимодействует с данными из HLR 307 в совместно размещенной системе 1600. В сценарии III, HSS 301 взаимодействует с данными из HLR 307 в совмещенной системе 1620.

Интерфейс подсистемы мобильных приложений (MAP) между HLR 307 и HSS 301 обеспечивает UMS-режим. MAP-интерфейс упрощает извлечение данных, таких как векторы аутентификации, повторную синхронизацию порядковых номеров аутентификации и/или извлечение информации о состоянии и местоположении пользователя в CS-домене 210 и PS-домене 212.

MAP-интерфейс, который известен в данной области техники, предоставляет обмен данными между HSS и удаленным HLR. Таким образом, HSS контактирует при необходимости с удаленным HLR с использованием MAP-интерфейса 1609. Например, в таких конфигурациях, HSS выполняет операцию отправки информации для аутентификации (SAT) MAP на удаленном HLR, чтобы извлекать порядковые номера повторной синхронизации и векторы аутентификации. В таких конфигурациях, HSS выполняет операцию опрашивания в любое время (ATI) MAP на удаленном HLR, чтобы извлекать информацию о состоянии и местоположении пользователя CS-домена/PS-домена.

MAP-сообщения из HSS традиционно маршрутизируются в удаленный HLR с использованием IMSI или MSISDN абонента. Для PrivateID находящегося вне собственной сети абонента и соответствующий IMSI сохраняется в HSS-данных. Этот IMSI используется для того, чтобы контактировать с удаленным HLR по получении сообщения Cx-MAR. Для общедоступного идентификатора находящегося в собственной сети или находящегося вне собственной сети абонента соответствующий MSISDN сохраняется в HSS-данных. Этот MSISDN используется для того, чтобы контактировать с удаленным HLR при получении Sh-UDR. Согласно варианту осуществления изобретения, преобразование может быть выполнено между PrivateID абонента и IMSI. Таким образом, преобразование фактически дает возможность IMSI выполнять операции для HLR 301 и HSS 307.

Тем не менее, абоненты фактически являются находящимися в собственной сети как в совместно размещенной системе 1600, так и в совмещенной системе 1620. Таким образом, SAI и ATI не требуются для совместно размещенной системы 1600 и совмещенной системы 1620, и нет необходимости дублирования данных, используемых посредством HSS 301 и HLR 307. Как для совместно размещенной системы 1600, так и для совмещенной системы 1620, данные 1607 аутентификации сохраняются в каталоге 1605 таким образом, что они могут использоваться как посредством HSS 301, так и посредством HLR 307. Следовательно, данные 1607 аутентификации не обязательно должны дублироваться для того, чтобы обслуживать каждое из этих приложений. Другими словами, процессы SAI и ATI необязательно должны выполняться в системе, сконфигурированной так, как показано на фиг. 16A и фиг. 16B. Соответственно, общая производительность сети связи может предоставляться посредством простой деактивации UMS-режима. Таким образом, данные 1607 аутентификации могут быть совместно использованы HSS 301 и HLR 307, согласно варианту осуществления изобретения.

В варианте осуществления изобретения, система управления сетью, такая как система 412 управления сетью, может задавать UMS-режим на HSS 301, чтобы работать в режиме активации или режиме деактивации для данной комбинации HSS и HLR. UMS-режим может быть активирован или деактивирован, например, посредством задания флага "только данные о себе" равным значению TRUE (т.е. "нет HLR") или FALSE (т.е. "есть HLR"). Если UMS-режим деактивирован, то SAI и ATI, например, не должны использоваться посредством HSS 301 для того, чтобы контактировать с HLR 307. Когда задана деактивация, состояние аутентификации может быть доступным как для HSS 301, так и для HLR 307 посредством простого осуществления доступа к каталогу 1605.

Фиг. 16C иллюстрирует внешнюю часть 1601, которая выполнена с возможностью хранить данные 1619 об услугах для приложений, таких как HSS 301 и HLR 307, согласно варианту осуществления изобретения.

Данные, сохраненные в каталоге, таком как каталог 1605, типично содержат смесь данных абонентов и данных 1619 об услугах. Данные 1619 об услугах, такие как не конкретные для абонента данные 1607 аутентификации и флаг UMS-режима, могут отделяться от данных абонентов и помещаться рядом с приложениями (к примеру, HSS 301 и HLR 307), которые часто применяют эти данные, согласно варианту осуществления изобретения. Посредством перемещения данных 1619 об услугах во внешнюю часть 1601 после этого доступ к не конкретным для абонента данным 1607 аутентификации и флагу UMS-режима посредством приложений, таких как HSS 301 и HLR 307, выполняется практически мгновенно, согласно варианту осуществления изобретения.

Данные 1619 об услугах типично включают в себя такие элементы, как флаг UMS-режима и схемы аутентификации. Согласно варианту осуществления изобретения, схемы аутентификации быть могут быть псевдонимом для других схем аутентификации. Таким образом, этот подход может использовать псевдонимы, обрабатываемые изнутри HSS 301, согласно варианту осуществления изобретения. Преобразование, поясненное выше, т.е. PrivateID и IMSI также может выполняться, когда данные 1619 об услугах перемещены во внешнюю часть 1601, согласно варианту осуществления изобретения.

DSA внутренней части в противном случае работает как внутренняя часть 1603, показанная на фиг. 16A, и как DSA 702, показанный на фиг. 7A, согласно варианту осуществления изобретения. Аналогично, DS 1625a-DS 1625c работают аналогично DS 706, показанному на фиг. 7A.

DUA 1627 работает способом, аналогичным DUA 704, показанному на фиг. 7A, согласно варианту осуществления изобретения.

Статические записи для косвенных способов

Фиг. 17 является блок-схемой, иллюстрирующей иерархию данных, хранимых в каталоге 1700, облегчающую статический доступ к записям, согласно варианту осуществления изобретения. Каталог 1700 может сохраняться на одном или более серверов 1721 каталогов, сконфигурированных так, как DS 706, показанный на фиг. 7A. DS 1721 может работать в рамках DSA, такого как DSA 702, показанный на фиг. 7A. Аналогично, операции в каталоге 1700 могут приниматься и обрабатываться посредством приложения 1723 сервера каталогов, которое работает аналогично прикладному программному обеспечению 707 сервера каталогов, показанному на фиг. 7A. Компоненты, оперирующие с каталогом 1700, привлекают компьютеризированные компоненты на сервере каталогов для того, чтобы обрабатывать действия, к примеру, через CPU.

Запрашивающий объект (к примеру, приложение, такое как HSS 301 или HLR 307) активирует один или более способов для записей 1703-1715, присутствующих в каталоге 1700, чтобы выполнять различные функции. Запрашивающий объект может представлять любой объект, допускающий осуществление запроса к каталогу 1700, такой как клиентское приложение или конечный пользователь. Способы инкапсулируют знание приложением взаимосвязей данных в схеме каталога 1700 и предоставляют простые интерфейсы, такие как системы инициализации. Характерными способами могут быть способы для: добавления абонента, добавления абонентской услуги, такой как HSS-услуга для существующего абонента и/или модификация настроек абонентского обслуживания, к примеру модификация настроек переадресации вызовов.

Посредством вызова косвенных способов, таких как записи 1703-1715, внешнее приложение может оперировать с данными в каталоге 1700 без наличия конкретного знания структуры каталога. Это может быть, в частности, полезным в каталогах, схемы которых подвергаются частому изменению, и/или для унаследованных программ, которые спроектированы так, чтобы работать с конкретной схемой. Хотя примеры, предоставленные здесь, относятся к развертыванию линий связи, этот подход должен быть применимым ко многим настройкам, в которых приложение должно выполнять задачи в каталоге, но не выполняет, или не может знать фактическую структуру каталога, согласно варианту осуществления изобретения.

Приложение, такое как HSS 301 или HLR 307, активирует способ, ассоциированный с записью, такой как запись 1703, с использованием отличительного имени (DN) записи. DN отражает действительное или адаптированное дерево записей, которое формирует предков записи, для которой активирован способ. Например, DN записи 1707 - это "Root.EntryA.EntryB", поскольку корень 1701 и запись 1703 являются предками записи 1707 в каталоге 1700. Такой способ в дальнейшем называется "действительным способом". Использование действительных способов в структурах каталогов известно в данной области техники.

Поскольку DN отражает имена записей действительного или адаптированного дерева, состоящие из различных предков, DN может становиться проблематичным, когда схема каталога 1700 изменяется по любой причине. Эти изменения могут затрагивать именование записей и, следовательно, могут изменять имена записей, при которых способы инициализации должны выполняться. Это оказывает влияние на систему инициализации, заставляя изменения программного обеспечения согласовывать с именования в схеме именования. Например, допустим, что схема изменяется так, что запись 1709 добавляется в каталог 1700 между записью 1707 и записью 1711, и дополнительно допустим, что соединение между записью 1707 и записью 1711 удаляется. Таким образом, DN записи 1711 изменяется с "Root.EntryA.EntryB.EntryB.2" на "Root.EntryA.EntryB.EntryB1.EntryB2".

Согласно варианту осуществления изобретения, действительный способ может быть ассоциирован с "косвенным способом". Косвенный способ - это способ, который принадлежит системной записи, такой как корень 1701. Системная запись является общей для всех приложений и не должна изменяться, когда возникают изменения в схеме. Следовательно, системная запись является "статической", и косвенный способ может быть активирован с использованием статической системной записи. В варианте осуществления изобретения, косвенный способ постоянно размещается в точке, где приложение подключается к каталогу 1700. Например, запись 1705 представляет "статическую запись C.2". Таким образом, приложение может использовать соответствующий протокол (к примеру, дополненный согласно LDAP операции) для того, чтобы активировать запись 1705 (т.е. способ, представляемый посредством записи 1705), чтобы активировать способ, представляемый посредством записи 1715, независимо от изменений схемы, которая может изменять DN записи 1715. Другими словами, приложение вызывает способ записи 1715. Приложение, которое должно вызывать способ статической записи (к примеру, записи 1715), должно знать DN этой записи. Таким образом, имя записи (к примеру, его DN) должно быть именем, которое не потребуется изменять.

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

- Реконструкция DN может быть "жестко закодированной", т.е. форма DN осуществляется в программной логике в статической записи, такой как статическая запись C2 1705, и/или

- Реконструкция DN может быть "мягко закодированной", например, с использованием DN шаблона, сохраненного как конфигурируемые данные об услугах, в котором конкретная информация RDN, предоставленная через API, заменяется посредством статической записи, такая как статическая запись C2 1705. Эти конфигурируемые данные об услугах типично должны храниться внутри самого каталога, аналогично способу, которым хранится схема каталога.

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

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

Поскольку косвенный способ постоянно размещается в точке, где приложения подключаются к серверу каталогов (к примеру, статической записи C2 705), дополнительная связь между DSA не требуется для пути доступа между приложением и косвенным способом, согласно варианту осуществления изобретения. Хотя одна запись для каждого приложения с несколькими конкретными для приложения способами зачастую является наиболее изящным подходом, можно использовать статическую запись с несколькими приложениями. Это означает, что точка связи может находиться точно в DSA, к примеру в DSA 702, показанном на фиг. 7A, где внешние приложения, использующие способ, соединяются. Соответственно, затраты по производительности для данного подхода тем самым являются минимальными. Внешние приложения, осуществляющие доступ к косвенным способам, должны подключаться к корневому DSA.

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

Статические записи, которые выполняют косвенные способы, такие как статическая запись C2 1705, могут создаваться практически в любое время в каталоге 1700 с использованием модуля 1720 создания статических записей, согласно варианту осуществления изобретения. Конечно, создание этих записей и способов является задачей, типично выполняемой во время установки системы/обновления программного обеспечения. Эта задача типично включает в себя установку расширенной схемы, которая задает новые или измененные классы объектов приложений и определения способов, наряду с установкой библиотек коллективного доступа, которые включают в себя код способа. Таким образом, эта задача по сути своей является операцией установки программного обеспечения и должна выполняться с использованием стандартных технологий установки программного обеспечения (к примеру, с использованием UNIX, пакетных или rpm-файлов, с ассоциированными или включенными сценариями оболочки, конфигурационными файлами, файлами загрузки в базу данных, двоичными файлами и т.д.). Модуль 1720 создания статических записей может компоновать статическую запись, связывать ее в каталог 1700 и оснащать статическую запись, чтобы восстанавливать DN записи, для которой действительный способ может быть активирован с использованием либо жестко кодированного, или мягко кодированного подхода, описанных выше. Модуль 1720 создания статических записей также может включать в себя интерфейс оператора, который упрощает задачу создания статических записей.

Механизм таймера

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

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

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

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

Фиг. 18A иллюстрирует сеть 1800 связи, использующую точку высокоскоростного доступа (HSAP), которая, возможно, может извлекать выгоду из улучшенного механизма синхронизации, согласно варианту осуществления изобретения. Механизм таймера, раскрытый в данном документе, применим к множеству окружений, и сеть 1800 связи, описанная здесь, предоставляет только одно такое окружение, которое может извлекать выгоду из улучшенного механизма синхронизации.

В сети 1800, по мере того как мобильный абонент 1810 перемещается, ответственность за поддержание его установления соединения в конечном счете переходит от базовой станции 1812a к базовой станции 1812b. Базовые станции 1812a-1812d передают различную информацию об абонентах и услуги через высокоскоростную точку доступа (HSAP) 1814. Сеть 1800 может быть выполнена с возможностью поддерживать, например, базовые станции 1812a-1812d от различных изготовителей в настройке для малого офиса, чтобы предоставлять беспроводную LAN с поддержкой мобильного роуминга.

HSAP 1814 может обмениваться данными с базовыми станциями 1812a-1812d с помощью AAA-протокола, такого как Cx-протокол, который используется в 3GPP-совместимых IMS-сетях для того, чтобы обмениваться данными между I-CSCF/S-CSCF и HSS, такими как CSCF 321 и HSS 301, показанные на фиг. 3. Эти протоколы известны в данной области техники и задаются посредством таких стандартов, как RFC 3588, 3GPP TS 29.228 и 3GPP TS 29.229.

В конфигурации, показанной на фиг. 18A, HSAP 1814 фактически постоянно размещается на границе базовой сети 1812 и включает в себя эмулированный SGSN 1816, эмулятор для SGSN 317, показанного на фиг. 3. Таким образом, HSAP 1814 и эмулированный SGSN 1816 могут фактически инструктировать все сети 1800 работать и конфигурироваться как традиционная сеть связи. Таким образом, сеть 1800 работает способом, аналогичным сети 204 мобильной связи, показанной на фиг. 2.

HSAP 1814 может использовать эмулированный SGSN 1816 для того, чтобы обмениваться данными с HLR 307 с помощью традиционного MAP-интерфейса. MAP-интерфейс предоставляет прикладной уровень для различных узлов в базовой сети 1822, чтобы обмениваться данными друг с другом, чтобы предоставлять услуги абонентам мобильных телефонов. Базовая сеть 1812 может включать в себя несколько HLR, и эмулированный SGSN может быть выполнен с возможностью обмениваться данными с HLR в базовой сети 1812.

HSAP 1814, использующая эмулированный SGSN 1816, также может включать в себя функцию данных начисления (CDF), которая агрегирует события начисления, сообщаемые посредством базовых станций (BS 1812), в записи данных по начислению (CDR), и перенаправляет их в систему 1818 начисления, согласно варианту осуществления изобретения. CDR - отформатированная совокупность информации об оплачиваемом событии (к примеру, время установления вызова, длительность вызова, объем переданных данных, и т.д.) для использования в учете и начислении абонентских услуг. Если CSP предоставляет абонентам счета с детализацией, CDR используются для того, чтобы составлять элементы строки в счете абонента.

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

Фиг. 18B предоставляет физическое представление сети 1800 связи, показанной на фиг. 18A, которая может извлекать выгоду из улучшенного механизма синхронизации, согласно варианту осуществления изобретения. Как упомянуто выше, сеть 1800 может быть выполнена таким образом, чтобы поддерживать беспроводную LAN, которая предоставляет поддержку мобильного роуминга. Допустим, что базовые станции сети, такие как BS 1812a и BS 1812b, выполнены с возможностью поддерживать обмен данными через протокол высокоскоростного пакетного доступа по нисходящей линии связи (HSDPA). Иногда называемый высокоскоростном протокольным доступом по нисходящей линии связи, HSDPA является протоколом мобильной телефонной связи 3G в семействе HSPA и обеспечивает высокие скорости передачи данных. HSDPA достигает увеличения скоростей передачи данных посредством задания нового канала W-CDMA или TD-CDMA, высокоскоростного совместно используемого канала нисходящей линии связи (HS-DSCH), который используется для передачи данных по нисходящей линии связи к мобильной станции. HSDPA известен в данной области техники.

Допустим, что BS 1812a-1812b обмениваются данными с DSA 1831. DSA 1831 может быть сформирован аналогично DSA 702, показанному на фиг. 7A. DSA 1831 может оперировать с данными, ассоциированными с HSDPA-узлом 1834a, совместно с DS-узлом 1836a. DS-узел 1836a может работать способом, аналогичным DS 706a, показанному на фиг. 7A. Таким образом, HSDPA-узел 1834a и DS-узел 1836a вместе предоставляют физический уровень для задач, выполняемых посредством логического уровня, показанного на фиг. 18A, согласно варианту осуществления изобретения.

Как показано, DSA 1831 также может быть сформирован из нескольких HSDPA-узлов 1834a-1834c, причем каждый HSDPA-узел 1834a-1834c имеет ассоциированный DS-узел 1836a-1836c. DSA 1831 может содержать больше или меньше HSDPA-узлов и DS-узлов, чем показано. Дополнительно, HSDPA- и DS-узлы не обязательно должны быть соединены друг с другом, хотя во многих сетях такие соединения являются желательными.

Сеть может содержать больше базовых станций, чем просто BS 1812a-1812b. Каждая базовая станция обменивается данными с первичным HSDPA-узлом и при необходимости с вторичным HSDPA-узлом. Например, как показано, BS 1812a имеет HSDPA 1834a в качестве своего первичного HSDPA-узла и HSDPA 1834b в качестве своего вторичного HSDPA-узла, как показано посредством сплошных и пунктирных линий. Аналогично, BS 1812b имеет HSDPA 1834c в качестве своего первичного HSDPA-узла и HSDPA 1834b в качестве своего вторичного HSDPA-узла, как показано посредством сплошных и пунктирных линий.

В этой конфигурации сети базовая станция, такая как BS 1812a, должна типично поддерживать непрерывно выполняющиеся обмены данными Diameter, чтобы записи, такие как CDR, поддерживались надлежащим образом. Неудивительно, что иногда может быть трудно непрерывно поддерживать активным сеанс Diameter. Следовательно, возникают проблемы с поддержанием непротиворечивого набора CDR.

По мере того как MS 1810 передвигается, базовые станции 1812a, 1812b в сети не могут все совместно использовать один HSDPA-узел. Таким образом, сеть включает в себя процедуру передачи обслуживания между базовыми станциями, которая дает возможность вызовам быть бесперебойными.

Тем не менее, события начисления, ассоциированные с вызовом, могут сообщаться в различные узлы HSDPA в зависимости от того, находится MS 1810 в базовой станции 1812a или 1812b. Решение этой проблемы состоит в том, чтобы сохранять события начисления, касающиеся абонента, в общей базе данных абонентов, доступной посредством всех HSDPA-узлов. Она может либо являться частью DSA 1831, либо содержаться в рамках одного или более отдельных внутренних интерфейсных DSA.

К сожалению, даже это решение имеет проблемы, поскольку ассоциированный защитный таймер для данного вызова в данном DS не может принимать "событие завершения вызова" по различным причинам. Защитный таймер - это традиционный таймер, используемый в телефонной связи для того, чтобы удостоверяться в том, что события начисления, ассоциированные с данным вызовом, не теряются сетью. Возможно то, что определенные ключевые события, такие как событие завершения вызова, теряются по отношению к вызову, что может иметь вид, что вызов вообще не выполнялся или что вызов имел значительно меньшую или большую длительность, чем фактическая продолжительность вызова. Например, "событие завершения вызова" представляет завершение вызова (когда одна сторона разъединяется), что может быть важной информацией в CDR, поскольку многие вызовы тарифицируются посредством CSP на основе продолжительности вызова абонента и/или полной продолжительности, представляемой посредством вызовов абонента в данном интервале времени, к примеру за месяц. Таким образом, есть потребность передавать таймеры наряду с другой информацией о вызове от HSDPA-узла в HSDPA-узел или так или иначе удостоверяться в том, что эта информация предоставляется в соответствующую обработку внутренней части.

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

Фиг. 18C показывает запись 1841 абонента из каталога, такого как каталог, поддерживаемый посредством DSA 1831, согласно варианту осуществления изобретения. Запись 1841 абонента включает в себя запись 1843 по начислению. Запись 1843 по начислению включает в себя запись 1845 события начисления и запись 1847 защитного таймера.

Так, например, в варианте осуществления изобретения, применяемом к сети связи, данные, сохраненные посредством DS 1836 в DSA, 1831, представляют HSDPA-узел для каждого импульса синхросигнала псевдозащитного таймера. Аналогично, данные представляют каждое "событие в процессе вызова" для HSDPA-узла для абонента и его ассоциированного "мультимедийного сеанса". Событие в процессе вызова типично представляет требование стандартов начисления, чтобы обеспечивать то, что регулярные записи сохраняются в CDR для вызовов в ходе выполнения. Событие в процессе вызова не обязательно отражает изменение состояния в вызове, хотя может отражать. События в процессе вызова типично формируются достаточно часто и могут помогать в определении завершения вызова, если событие завершения вызова не записано. Следовательно, событие в процессе вызова может помогать системе начисления абонентских услуг в надлежащем выставлении счетов за продолжительные вызовы, которые охватывают несколько периодов начисления. События вызова, такие как события в процессе вызова и события завершения вызова, должны регулярно приниматься посредством HSAP 1814 в соответствии с установленными стандартами связи, и HSAP 1814, следовательно, должна выполнять защитный таймер, чтобы обеспечивать то, что они действительно принимаются быстро.

Фиг. 18D показывает таймер 1850, имеющий запись 1851 таймера в каталоге, сохраненном посредством DSA 1831, согласно варианту осуществления изобретения. Запись 1847 защитного таймера, показанная на фиг. 18C, предоставляет время, которое может использоваться для того, чтобы "перемещать" запись 1848a-d защитного таймера CD абонента, ассоциированную с записью данных 1843 по начислению по "импульсам сигнала времени" псевдотаймера, сохраненным посредством таймера 1851. Таким образом, запись 1851 таймера предоставляет динамическое дерево таймера, согласно варианту осуществления изобретения.

Запись 1851 таймера сохраняет набор записей 1855a-1855d "импульса сигнала времени" таймера. Эти записи импульса сигнала времени представляют различные времена в рамках таймера 1851. События вызова могут постоянно размещаться в таймере от времени начала ("Сейчас +XX") до времени завершения ("Сейчас"). Таким образом, защитный таймер 1848d CD абонента может сначала быть ассоциирован с максимальной длительностью защитного таймера, представляемой здесь посредством записи 1855d "Сейчас +XX". Например, запись 1855d может представлять 60 секунд от времени "Сейчас" и, таким образом, должна быть названа "Сейчас +60".

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

Если клиентское приложение принимает соответствующий ответ (к примеру, событие в процессе вызова), то клиентское приложение может удалять выполняющийся в настоящее время таймер и запускать другой таймер, в случае необходимости. Другими словами, каждый раз, когда новое событие в процессе вызова принимается, защитный таймер 1848a-d CD абонента должен быть удален и заменен на новый таймер в "Сейчас +60". Каждый раз, когда событие завершения вызова принимается, текущий защитный таймер CD абонента просто должен удаляться.

До того как событие в процессе вызова или вызова конца принято, данный защитный таймер 1848a-d CD абонента продвигается через таймер, в конечном счете достигая записи 1855a "Сейчас", согласно варианту осуществления изобретения. Когда клиентское приложение опрашивает запись 1855a "Сейчас", клиентское приложение может находить все записи, такие как защитный таймер 1848a CD абонента, которые истекли, без необходимости приема события в процессе вызова или события завершения вызова. Клиентское приложение затем может выполнять соответствующее корректирующее действие в соответствии со стандартами начисления.

Чтобы предоставлять возможность успешного выполнения всех этих действий в варианте осуществления изобретения, должны быть приспособлены следующие принципы именования записей:

- таймер 1851: именуется согласно DSA, в котором постоянно размещаются он и абонент 1841.

- защитный таймер 1848a-d CD абонента: именуется согласно идентификационным данным абонента и идентификатору записи 1843 данных по начислению.

- защитный таймер 1847: именуется согласно таймеру 1851 и записи 1855a-d "Сейчас +XX", в которой в настоящий момент находится защитный таймер 1848a-d CD абонента.

В варианте осуществления изобретения, показанном на фиг. 18D, таймер 1851 задан с детализацией в 10 секунд, и именно поэтому запись импульса сигнала времени продвигается с приращениями по 10, к примеру, запись 1855b импульса сигнала времени "Сейчас +10". Тем не менее, детализация записей импульса сигнала времени может задаваться на другом уровне времени, таком как 1 секунда или 20 секунд, в зависимости от требований синхронизации. Отсечка для таймера 1851 (к примеру, продолжительность, представляемая посредством таймера), может составлять фактическую любую продолжительность, при этом менее точные результаты (к примеру, большие времена) приравниваются к менее строгим условиям предоставления услуг для CSP, к примеру, таймер с детализацией 10 секунд и длительностью 2 минуты является менее точным, чем таймер с детализацией 1 секунда и длительностью 30 секунд. Запись таймера 1851 может быть сконфигурирована для большей или меньшей детализации посредством наличия большего или меньшего количества записей для различных времен, согласно варианту осуществления изобретения.

Таким образом, приложение, такое как первичный HSDPA-узел 1834a, должно периодически искать свой временной квант таймера "сейчас", который должен содержать только записи для защитных таймеров, которые должны извлекаться. Альтернативно, механизм таймера может быть составлен так, чтобы уведомлять приложение о вызовах во временном кванте таймера "сейчас". Все события, находящиеся во временном кванте 1855a "сейчас", представляют таймеры, которые истекли, и, таким образом, должны обрабатываться надлежащим образом (к примеру, посредством добавления анормального события в процессе вызова в CDR), а затем удаляться. Другими словами, приложение, такое как приложение для HSDPA-узла 1834a, старается выбирать защитные потерянные события начисления.

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

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

Фиг. 18E иллюстрирует механизм распределенной синхронизации, реализованный в DSA 1831, показанном на фиг. 18B, согласно варианту осуществления изобретения. Как пояснено ранее, этот механизм распределенной синхронизации может использоваться для синхронизации любого события и не обязательно ограничен событиями синхронизации, связанными с системами связи.

DSA 1831 аналогичен DSA 702, показанному на фиг. 7A. Аналогично, DS 1836 аналогичен DS 706, а DUA 1864 работает аналогично DUA 704, показанному на фиг. 7A. Клиентское приложение 1866 может быть любым клиентским приложением или другим запрашивающим объектом, но в механизме синхронизации, описанном в данном документе для мобильной связи, наиболее вероятно является объектом, отвечающим за поддержание событий синхронизации, таких как приложение, ассоциированное с HSAP 1814, согласно варианту осуществления изобретения.

Каждый DS 1836 сохраняет копию таймера 1850, показанного на фиг. 18D. Следовательно, любой DS может обрабатывать входящие события. Как правило, любой DS 1836 может обрабатывать входящие события считывания/поиска, при этом один первичный DS (к примеру, DS 1836a) отвечает за добавления/удаления в таймере 1850. Первичный DS 1836 также может отвечать за контакт с клиентским приложением 1866 (к примеру, когда запись достигает позиции "Сейчас" без обработки нового события), согласно варианту осуществления изобретения. Таким образом, модуль 1861 синхронизации может быть выполнен с возможностью передавать события синхронизации и связанную информацию в другие модули 1861 синхронизации на других DS. Например, только один модуль 1861 синхронизации должен передавать результаты синхронизации в запрашивающий объект (к примеру, клиентское приложение), хотя все хранилища синхронизации могут быть доступными для запрашивающего объекта, согласно варианту осуществления изобретения. Таким образом, модули 1861 распределенной синхронизации могут быть выполнены так, что только один модуль синхронизации уведомляет запрашивающий объект о запрошенном событии, если указанное время события наступает, согласно варианту осуществления изобретения.

Каждый DS 1836 может включать в себя модуль 1861 синхронизации, чтобы помогать с обработкой таймера 1850, согласно варианту осуществления изобретения. Модуль 1861 синхронизации может помогать, например, в проверке того, что записи синхронизации поддерживаются актуальными. Модуль 1861 синхронизации также может помогать в обработке фактических таймаутов в таймере 1850 посредством анализа истекших записей времени и перенаправления индикаторов относительно истекшего таймера в клиентское приложение 1866 для соответствующей обработки тайм-аута защиты, согласно варианту осуществления изобретения. Модуль 1861 синхронизации также может удалять истекшие записи времени из таймера 1850.

Конечно, несколько DSA 1831 могут использоваться в обработке потоков событий, связанных с таймерами. В некоторых вариантах применения, можно захотеть развертывать каждый экземпляр приложения, чтобы обрабатывать его потоки событий посредством локального DSA, к примеру, экземпляр HSAP 1814, находящийся в Японии, возможно, хочет, чтобы локальный DSA обрабатывал его таймеры, вместо того, чтобы удаленный DSA (к примеру, в Великобритании) обрабатывал эти таймеры, согласно варианту осуществления изобретения. Дополнительно, также, возможно захотеть секционировать группы абонентов так, что есть DSA, назначенный конкретной группе абонентов. В этом варианте осуществления, первичный DS 1836 фактически обрабатывает таймеры для вызовов, связанных с этой группой абонентов.

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

Варианты осуществления механизма таймера могут применяться к множеству распределенных приложений, где нельзя гарантировать, что внешние события поступают в один локальный узел. Аналогично, как пояснено, запись 1851 таймера может постоянно размещаться в нескольких хранилищах данных, так что в случае сбоя одного конкретного хранилища данных, такого как каталог, сохраненный на DS 1836a, точная синхронизация может по-прежнему продолжать использование хранилища данных из другого устройства, такого как каталог, сохраненный на DS 1836b.

В варианте осуществления изобретения, компоненты изобретения содержат программное обеспечение на основе совокупности различных задач, написанное на машинном языке "C". Программное обеспечение, тем не менее, может быть написано на множестве других вычислительных языков. Задачи в рамках программного обеспечения обмениваются данными друг с другом через комбинацию очередей и совместно используемой памяти. Например, сервер 706a каталогов обменивается данными с другими серверами 706b и 706c каталогов в DSA 702, а также другими серверами каталогов в удаленных DSA через линию связи TCP/IP, согласно варианту осуществления изобретения. Компоненты изобретения также могут быть основаны на аппаратных средствах и/или комбинациях аппаратных средств и программного обеспечения.

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