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

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

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ

Данное изобретение относится к способу и устройству.

УРОВЕНЬ ТЕХНИКИ

Под устройством связи можно понимать устройство с соответствующими возможностями связи и управления для использования его для связи с другими сторонами. Связь может включать, например, голосовую связь, электронную почту (e-mail), текстовые сообщения, данные, мультимедиа и т.д. Устройство связи обычно предоставляет пользователю возможность принимать и передавать сообщения через систему связи и таким образом может использоваться для доступа к различным сервисным приложениям.

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

Соответствующая система доступа позволяет устройству связи получать доступ к более широкой системе связи. Доступ к более широкой системе связи может быть обеспечен посредством линии фиксированной связи, или интерфейса беспроводной связи, или их комбинации. Системы связи, обеспечивающие беспроводной доступ, обычно предоставляют по меньшей мере некоторую мобильность для своих пользователей. Примеры таких систем включают системы беспроводной связи, в которых доступ обеспечивается посредством размещения сотовых сетей доступа. Другие примеры технологий беспроводного доступа включают различные беспроводные локальные сети (Wireless Local Area Networks, WLAN) и спутниковые системы связи.

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

В сотовых системах связи сетевой объект в виде базовой станции обеспечивает узел для связи с мобильными устройствами в одной или более сотах или секторах. Следует отметить, что в некоторых системах базовую станцию называют "узлом В". Обычно работой базовой станции и других устройств системы доступа, необходимых для связи, управляет конкретный объект управления. Объект управления обычно взаимосвязан с другими объектами управления определенной сети связи. Примеры сотовых систем доступа включают универсальные наземные сети радиодоступа (Universal Terrestrial Radio Access Network, UTRAN) и сети радиодоступа GERAN (GSM (Global System for Mobile communications, глобальная система мобильной связи) EDGE (Enhanced Data Rates for GSM Evolution, повышенные скорости передачи данных для развития GSM) RAN (Radio Access Network, сеть радиодоступа).

Ранее было предложено обеспечить общую абонентскую базу данных, которая способна обслуживать множество приложений, осуществляющих доступ к общей абонентской базе данных. Один абонент может иметь множество различных идентификаторов. Приложения могут включать, например, домашний регистр местоположения (Home Location Register, HLR), домашний сервер абонентов (Home Subscriber Server, HSS) и аутентификацию, авторизацию и учет (Authentication Authorization and Accounting, AAA).

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

На фиг.2 показаны потоки сигналов, реализующие данное изобретение.

На фиг.3 показана база данных, реализующая данное изобретение.

На фиг.4 показан клиент конфигурирования, реализующий данное изобретение.

На фиг.5 показана блок-схема алгоритма согласно варианту осуществления данного изобретения.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

Имеется пользовательское устройство 2. Пользовательское устройство 2 может быть представлено в любом подходящем виде, например в виде мобильного телефона, персонального цифрового помощника (Personal Digital Assistant, PDA), компьютера, портативного компьютера или аналогичного устройства. Пользовательское устройство 2 сконфигурировано для связи с базовой станцией 4 через беспроводной интерфейс 6. Следует отметить, что каждая базовая станция 4 способна осуществлять связь с несколькими различными пользовательскими устройствами. В этом документе используется термин "базовая станция". Однако в некоторых стандартах связи используется термин "узел В". Должно быть понятно, что общий термин "базовая станция" предназначен для охвата любого такого объекта, а также любого другого объекта, обеспечивающего доступ к сети посредством беспроводной линии.

Базовые станции 4 выполнены с возможностью соединения с контроллером 8. В некоторых стандартах контроллер называют контроллером базовой станции, в то время как в других стандартах контроллер обозначают как контроллер радиосети (Radio Network Controller, RNC). Снова, термин "контроллер" предназначен для охвата любого из этих контроллеров или любого другого объекта, который сконфигурирован для управления базовыми станциями.

Контроллер подключен к узлу, такому как обслуживающий узел поддержки службы пакетной передачи данных общего назначения (General Package Radio Service, GPRS) (Signalling GPRS Service Node, SGSN) или центр коммутации подвижной связи (Mobile Switching Centre, MSC). Должно быть понятно, что обычно узел SGSN и центр MSC являются отдельными узлами. Типичными функциями, обеспечиваемыми узлом этого типа, являются доставка данных к подвижной станции и от нее, включая маршрутизацию и передачу, управление мобильностью, функции аутентификации и тарификации. Они приведены только в качестве примера, и такие узлы могут выполнять только одну или более этих функций или, альтернативно, обеспечивать другие функции.

Элемент SGSN/MSC 10 подключен к функции домашнего регистра 12 местоположения (HLR). Это объект, который управляет профилем пользователя, таким как указание того, на какие услуги подписан пользователь, применимый тариф, услуги, которые пользователю разрешается использовать, и информация о состоянии для этих услуг. Другие примеры информации, которая может быть включена в профиль пользователя:

Информация об идентификаторах (как уже описано).

Информация о местоположении (хранимый адрес регистра местоположения посетителя (Visitor Location Register, VLR)/узла SGSN и т.д.).

Информация аутентификации.

Ограничения роуминга (куда абоненту разрешается перемещаться).

Основные услуги и любые соответствующие международные номера подвижного абонента (Mobile Station International Subscriber Directory Number, MSISDN) (например, речь/факс/данные и т.д.).

Предоставляемые услуги перенаправления вызова/запрещения вызова/дополнительные услуги и их статус.

Предоставляемые услуги GPRS и их статус.

Предоставляемые услуги приложений для усовершенствованной логики мобильной сети/интеллектуальной сети (Customized Applications for Mobile Network Enhanced Logic/Intelligent Network, CAMEL/IN) и их статус.

Услуги установленного оператором запрещения на обслуживание вызовов и их статус.

Услуги службы передачи коротких сообщений (Short Message Service, SMS) и их статус.

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

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

На фиг.1 показан также узел домашнего сервера абонентов/аутентификации, авторизации и учета (HSS/AAA). Обе эти функциональные возможности являются возможностями мультимедийной IP-подсистемы (Internet Protocol Multimedia Subsystem, IMS). Могут быть представлены два узла: один для функции HSS и один для функции ААА. Домашний сервер абонентов (HSS), или функция сервера профилей пользователей (User Profile Server Function, UPSF), поддерживает сетевые объекты подсистемы IMS, которые фактически обрабатывают вызовы. Он управляет информацией, связанной с подпиской (профилями пользователей), аутентификацией и авторизацией пользователя, и может предоставлять информацию о физическом местоположении пользователя. Необходимые для этого данные хранятся в базе 16 данных. Функциональные возможности сервера HSS аналогичны функциональным возможностям регистра HLR 12, но для вызовов подсистемы IMS.

Как регистр HLR 12, так и сервер HSS/AAA 14 имеют доступ к общей базе 16 данных. Эта база данных будет описана более подробно в дальнейшем. База 16 данных подключена к клиенту 18 конфигурирования. Клиент конфигурирования связан, например, с доменом 20 оператора, включающим такие функции, как выставление 22 счетов, управление абонентами или аналогичные функции. Запросы конфигурирования могут относиться к профилю/данным об идентификаторах пользователя, хранящимся для регистра HLR, сервера HSS или других приложений (ААА и т.д.).

В этом примере домен оператора включает системы эксплуатационной поддержки/системы поддержки деятельности предприятия (Operational Support System/Business Support System, OSS/BSS), то есть системы поддержки абонентов/типа выставления счетов, которые будут инициировать запросы конфигурирования. Между элементом SGSN/MSC и доменом оператора может быть предусмотрен узел 24 или же элемент SGSN/MSC может быть подключен непосредственно к домену оператора. Подключение может осуществляться посредством двух или более узлов.

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

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

1. Добавить идентификатор.

2. Удалить идентификатор.

3. Заменить идентификатор.

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

1. Международный идентификатор абонента подвижной связи (International Mobile Subscriber Identity, IMSI).

2. Номер MSISDN.

3. Открытый идентификатор пользователя IMS.

4. Закрытый идентификатор пользователя IMS.

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

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

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

В вариантах осуществления настоящего изобретения данные размещаются так, чтобы сохранять ассоциацию между приложениями 54 и идентификаторами абонента 56, которые они используют. Приложение может быть любым подходящим приложением. Как пример, приложение может быть приложением HLR, приложением HSS или приложением переносимости мобильного номера (Mobile Number Portability, MNP).

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

список данных приложения

- индекс идентификатора. Индекс идентификатора является целым числом;

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

"1 | HLR"

"2 | HSS"

"3 | MNP"

"4 | HSS"

Список идентификаторов абонента

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

- идентификатор списка идентификаторов (Identifier, ID) абонента, который является целым числом;

- за ним следует доменное имя списка ID абонента, указывающее тип идентификатора. Это печатаемая строка в одном из вариантов осуществления изобретения;

- далее следует идентификатор списка ID абонента, который является печатаемой строкой.

Примеры этих значений представлены ниже:

"1|imsi|23480000012345"

"2|msisdn|44970000012345"

"3|publiclD|PUBID_01_0142210100001234512E070011@other_ims_provid er.co.uk"

Рассмотрим следующие примеры, в которых абонент имеет номер MSISDN, совместно используемый приложениями HLR и MNP:

dn:id=00 11 22 33 44 55 66 77 88 99 AA

BB, domainName=subsD, o=Apertio, c=UK

objectClass: subscription

lockFlag:FALSE

lockFlagTimestamp:01-01-1970 01:00:00

applicationDataList:1|HLR

applicationDataList:2|HLR

applicationDataList:2|MNP

subsldList:1|imsi|234860000012345

subsldList:2|msisdn449730000012345

Как можно видеть, имеются два идентификатора, связанные с абонентом: IMSI и MSISDN. Второй идентификатор, MSIDN, связан с приложением HLR и приложением MNP.

Следующий пример показывает случай, когда абонент имеет два идентификатора HSS:

dn:id=00 11 22 33 44 55 66 77 68 99 AA

BB, domainName=subsD, o=Apertio, c=UK

objectClass:subscription

lockFlag: FALSE

lockFlagTimestamp:01-01-1970 01:00:00

applicationDataLis:1|HSS

applicationDataList:2|HSS

subsIdList:

1|privatelD|PRlVID_01_014210100000000012E07011@

ims_provider.co.uk

subsIdList:

2|publiclD|PUBID_01_014210100001234512E07011@

other_ims_provider.co.uk

Как можно видеть, список ID абонента включает два идентификатора HSS: открытый и закрытый идентификаторы.

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

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

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

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

В одном из вариантов осуществления изобретения данного изобретения база данных работает в соответствии с упрощенным протоколом доступа к каталогам (Lightweight Directory Access Protocol, LDAP). Однако в альтернативных вариантах осуществления данного изобретения может использоваться другой протокол.

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

Например, функция сервера начальной загрузки (Bootstrapping Server Function, BSF) является функцией, которая осуществляет взаимную аутентификацию с пользовательским устройством (UE), используя процедуру аутентификации и соглашения о ключе (Authentication and Key Agreement, AKA) и осуществляет соглашение о ключах сеанса связи, которые затем применяются между устройством UE и управляемой оператором функцией приложения сети (Network Application Function, NAF). Функция BSF размещается в управляемом оператором сетевом элементе и может извлекать информацию, связанную с пользователем, из регистра HLR или сервера HSS.

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

Были приведены различные примеры идентификаторов. Должно быть понятно, что может быть включен любой альтернативный или дополнительный список идентификаторов. Например, могут использоваться адреса электронной почты в виде универсального указателя ресурса (Universal Resource Locator, URL) протокола инициирования сеанса связи (Session Initiated Protocol, SIP).

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

Обратимся к фиг.2, где показан поток сигналов согласно способу, осуществляющему данное изобретение.

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

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

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

Во втором сценарии, сценарии В, клиент конфигурирования определяет, что идентификатор IMSI 1 не используется совместно с другим приложением. Соответственно клиент конфигурирования передает базе данных команду для удаления идентификатора IMSI 1 и связанную с ним ссылку HLR. Эту команду передают на шаге S4B.

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

В третьем сценарии, сценарии С, клиент конфигурирования определяет, что идентификатор IMSI 1 используется совместно. Соответственно определяют, что должна быть удалена только ссылка HLR, другими словами, другое приложение использует этот идентификатор IMSI 1. Команды, передаваемые в сигнале S4C, должны удалить только ссылку HLR. На шаге S5C из базы данных передают подтверждение клиенту конфигурирования. Это подтверждение пересылается от клиента конфигурирования внешнему клиенту на шаге S6C.

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

Обратимся к фиг.5, где показана блок-схема алгоритма в соответствии с данным изобретением.

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

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

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

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

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

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

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

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

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

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

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

1) Считать данные идентификатора абонента.

2) Если новый идентификатор уже используется другой (отличной) подпиской, отклонить запрос.

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

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

Обратимся к фиг.3, где показана структурная схема объекта 16 базы данных. Объект базы данных содержит базу 60 данных для хранения флагов 50, информации 52 об отметках времени, информации 56 об абоненте и информации 54 о приложении, как было описано ранее.

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

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

Обратимся к фиг.4, где показана структурная схема клиента конфигурирования, реализующего данное изобретение. Клиент 18 конфигурирования имеет первый интерфейс 70 для приема запроса, например, от домена выставления счетов. Первый интерфейс пересылает первый запрос в процессор 72. Процессор проверяет в запросе информацию, идентифицирующую приложение, или выполняет определение приложения из источника. Процессор сконфигурирован для запроса из базы данных информации об абоненте и приложении для абонента, идентификатор которого включен в запрос. Процессор может переформулировать запрос или просто перенаправить запрос базе данных. Запрос от процессора 72 пересылается базе данных через второй интерфейс 74, который также сконфигурирован для приема информации из базы данных. Процессор будет анализировать данные для определения того, может ли быть выполнено изменение, и если да, изменять данные и передавать их обратно в базу данных через второй интерфейс 74. В противном случае процессор передаст сообщение обратно запрашивающей стороне через первый интерфейс.

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

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

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

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

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

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

Например, варианты осуществления изобретения могут быть по меньшей мере частично реализованы в виде набора микросхем (чипсета), другими словами, в виде ряда интегральных схем, взаимодействующих друг с другом. Набор микросхем может включать микропроцессоры, сконфигурированные для выполнения кода, специализированные интегральные схемы (Application Specific Integrated Circuits, ASIC) или программируемые процессоры для цифровой обработки сигналов для выполнения описанных выше операций.

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

Программы, такие как поставляемые фирмами Synopsys, Inc., Mountain View, California и Cadence Design, San Jose, California, автоматически трассируют проводники и размещают компоненты на полупроводниковой подложке, используя хорошо установившиеся правила проектирования, а также библиотеки заранее сохраненных модулей проектирования. Как только проект для полупроводниковой схемы закончен, полученный в результате проект в стандартизированном электронном формате (например, Opus, GDSII или аналогичном формате) может быть передан для изготовления на предприятие по изготовлению полупроводников.

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

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

2. Способ по п