способ и устройство для распределения серверов приложений в ims

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

1. Способ распределения сервера приложений по Протоколу инициирования сеанса (SIP) для абонента в IP-мультимедийной подсистеме, причем способ содержит

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

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

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

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

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

посылку сообщения SIP от обслуживающей функции управления вызовом/сеансом на сервер приложений по распределенному адресу; и

после приема сообщения SIP на сервере приложений, запоминание адреса сервера приложений в качестве непрозрачных данных в домашнем абонентском сервере HSS через интерфейс обмена информацией между сервером приложений SIP и HSS (Sh интерфейс).

2. Способ по п.1, в котором идентификатором сервера приложений по Протоколу инициирования сеанса является идентификатор SIP-URI.

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

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

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

6. Способ по любому из пп.1-4, причем способ выполняется, когда абонент не зарегистрирован, но находится в конечной точке вызова по Протоколу инициирования сеанса.

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

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

средство обработки для преобразования общего идентификатора серверов приложений по Протоколу инициирования сеанса во множество адресов серверов приложений и для распределения одного из этих адресов для абонента для использования при предоставлении услуги упомянутому абоненту;

память для кэширования распределенного адреса в связи с абонентом; и

средство для последующей посылки сообщения SIP из обслуживающей функции управления вызовом/сеансом на сервер приложений по распределенному адресу.

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

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

кэширование связи между упомянутым адресом и упомянутым абонентом; и

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

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

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

запоминание принятого адреса (адресов) в центральном хранилище в связи с идентификатором абонента;

последующий прием запроса от абонента на сервере приложений IP-мультимедийной подсистемы и посылку в ответ запроса в центральное хранилище;

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

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

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

12. Сервер приложений для использования в IP-мультимедийной подсистеме, причем сервер приложений содержит

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

средство для посылки своего интерфейсного адреса (адресов) в центральное хранилище для сохранения в связи с идентификатором абонента.

13. Сервер приложений для использования в IP-мультимедийной подсистеме, причем сервер приложений содержит

вход для приема запроса, относящегося к абоненту;

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

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

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

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

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

Настоящее изобретение относится к способу и устройству для распределения серверов приложений в IP-мультимедийной подсистеме (IMS).

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

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

IP-мультимедийная подсистема (IMS) относится к технологии, определенной Проектом партнерства третьего поколения (3GPP), которая обеспечивает IP-мультимедийные слуги по сетям мобильной связи (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329, версии с 5 по 7). Подсистема IMS обеспечивает ключевые функции для обогащения форм персональной связи конечного пользователя посредством использования стандартизированных средств предоставления услуг IMS, которые обеспечивают новые услуги персональной связи (от клиента к клиенту) с расширенными возможностями, а также услуги «пользователь-контент» («клиент-сервер») по сетям, работающим на основе протокола IP. Подсистема IMS для установки и управления вызовами или сеансами между пользовательскими терминалами (или пользовательскими терминалами и серверами приложений) использует Протокол инициирования сеанса (SIP). Для описания и согласования медийных компонент сеанса используется Протокол описания сеанса (SDP), реализуемый в процессе передачи сигналов SIP. Хотя протокол SIP был создан как протокол типа «пользователь-пользователь», подсистема IMS позволяет операторам и поставщикам услуг управлять доступом пользователя к услугам и начислять пользователям соответствующую плату.

В качестве примера на фиг.1 схематически показано, как подсистема IMS вписывается в архитектуру сети мобильной связи в случае сети доступа GPRS/PS (подсистема IMS, конечно, может работать и с другими сетями доступа). Функции управления вызовом/сеансом (CSCF) действуют в подсистеме IMS в качестве посредников SIP. Архитектура 3GPP определяет три типа функций CSCF: CSCF-посредник (P-CSCF), которая является первой точкой контакта в подсистеме IMS для терминала SIP; обслуживающая CSCF (S-CSCF), которая обеспечивает пользователя услугами, на которые тот подписан; и опрашивающая CSCF (I-CSCF), роль которой заключается в идентификации правильной функции S-CSCF и направлении в эту функцию S-CSCF запроса, полученного от терминала SIP через функцию P-CSCF.

Пользователь регистрируется в подсистеме IMS, используя заданный способ SIP REGISTER. Это обеспечивает механизм прикрепления пользователя к подсистеме IMS и предоставления подсистеме IMS адреса, по которому может быть найден идентификатор пользователя SIP. В проекте 3GPP при выполнении терминалом SIP регистрации подсистема IMS осуществляет аутентификацию пользователя и распределяет функцию S-CSCF для этого пользователя из набора доступных функций S-CSCF. Хотя в проекте 3GPP критерии для распределения функций S-CSCF не заданы, они могут включать в себя требования к услугам и разделению нагрузки. Заметим, что распределение функций S-CSCF является ключевым моментом при управлении доступом пользователей к услугам на основе IMS (и начисления платы за них). Операторы могут обеспечить механизм, предотвращающий прямые сеансы SIP «пользователь-пользователь», которые в противном случае игнорировали бы функцию S-CSCF.

Во время процесса регистрации функция I-CSCF отвечает за выбор функции S-CSCF, если та еще не выбрана. Функция I-CSCF получает необходимые характеристики S-CSCF от домашнего абонентского сервера (HSS) домашней сети и выбирает подходящую функцию S-CSCF на основе полученных характеристик. (Заметим, что распределение S-CSCF также выполняется для пользователя функцией I-CSCF в случае, когда пользователя вызывает другая сторона и этому пользователю в данный момент не выделена функция S-CSCF.) Когда зарегистрированный пользователь посылает затем в подсистему IMS запрос на сеанс, функция P-CSCF позволяет направить этот запрос в выбранную функцию S-CSCF на основе информации, полученной от функции S-CSCF во время процесса регистрации.

Для реализации функциональных возможностей услуг IMS в сети услуг IMS предусмотрены серверы приложений (AS). Серверы приложений предоставляют услуги конечным пользователям в системе IMS, причем они могут быть подсоединены либо как конечные точки через интерфейс Mr, определенный в проекте 3GPP, либо могут быть подключены функцией S-CSCF через интерфейс ISC, определенный в проекте 3GPP. В последнем случае для определения того, какие серверы приложений должны быть подключены во время установки сеанса SIP (или, конечно, для связанного способа SIP, с сеансом или без сеанса), используют критерии начальной фильтрации (IFC). Функция S-CSCF получает критерии IFC от сервера HSS во время процедуры регистрации в IMS как часть профиля пользователя.

На фиг.2 показан интерфейс управления услугами IMS (ISC) между сервером AS и функцией S-CSCF, а также другие интерфейсы в IMS. Хотя на фиг.2 показано, что сервер AS имеет только один интерфейс к S-CSCF, очевидно, что на практике интерфейс ISC распространяется на сеть связи, к которой подсоединены множество (или все) серверов CSCF данной операторской сети, что позволяет серверу AS осуществлять связь со всеми функциями CSCF. (Другие объекты, показанные на фиг.1, хорошо известны специалистам в данной области техники.)

Между сервером AS и пользовательским терминалом (TS23.002) существует дополнительный интерфейс (Ut), хотя он на этой фигуре не показан. Интерфейс Ut позволяет пользователю распоряжаться информацией, относящейся к его услугам, например: создание и присваивание идентификаторов услуг связи общего назначения; управление стратегиями авторизации, которые используются, например сервисом контроля присутствия; управление конференцией на основе заданных правил и т.д.

В подсистеме IMS, определенной в проекте 3GPP, хотя абоненты распределены к серверу HSS статически, именно серверы AS обеспечивают конкретное значение в случае предоставления услуг через сеть. Как следует из спецификации 3GPP по версиям 5 и 6, абоненты распределены по конкретным серверам SIP AS фиксированным образом. Базовая концепция заключается в том, что абонент обеспечен поддержкой конкретного сервера приложений SIP AS для данной услуги или услуг. Чтобы разрешить привязку распределенной функции S-CSCF к выделенному серверу AS через интерфейс ISC, критерии фильтрации (находящиеся в IFC, посланном в S-CSCF от сервера HSS) для абонента данной услуги содержат в качестве адреса адресата (закодированного в виде идентификатора SIP-URI) либо полностью определенное доменное имя (FQDN), либо IP-адрес. Это предполагает, например, что при идентификации функцией S-CSCF того, что серверу AS должно быть направлено конкретное приглашение (INVITE), функция S-CSCF обеспечивается адресом конкретного сервера AS через интерфейс Cx. Чтобы идентифицировать правильный сервер AS для других интерфейсов, например интерфейса Ut между пользовательскими терминалами и серверами SIP-AS, средства-посредники, выполняющие маршрутизацию, обеспечиваются адресом сервера AS для конкретного пользователя. Когда абоненты распределены по конкретным серверам AS, то либо терминал конфигурируется с адресом сервера AS для этого интерфейса и услуги, либо терминал посылает запрос тому объекту, который знает, как найти адрес сервера AS для данного абонента. Это может сделать средство предварительной обработки (front-end), и в указанном случае функциональные возможности маршрутизации будут сконфигурированы в этом средстве предварительной обработки.

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

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

Согласно первому аспекту настоящего изобретения предлагается способ распределения сервера приложений по Протоколу инициирования сеанса для абонента в IP-мультимедийной подсистеме, причем способ содержит:

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

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

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

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

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

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

Предпочтительно, чтобы идентификатором сервера приложений по Протоколу инициирования сеанса был идентификатор SIP-URI.

Предпочтительно, чтобы множество адресов серверов приложений представляли собой полностью определенные доменные имена или IP-адреса.

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

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

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

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

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

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

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

средство обработки для преобразования общего идентификатора серверов приложений по Протоколу инициирования сеанса во множество адресов серверов приложений и для распределения одного из адресов для абонента для его использования при предоставлении услуги указанному абоненту; и

память для кэширования распределенного адреса ассоциативной связи совместно с абонентом.

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

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

кэширование связи между указанным адресом и указанным абонентом; и

использование указанной связи для направления будущих сообщений по Протоколу инициирования сеанса, посланных абоненту или от абонента.

Согласно четвертому аспекту настоящего изобретения предлагается способ идентификации сервера приложений SIP, распределенного для абонента в IP-мультимедийной подсистеме, причем способ содержит:

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

запоминание полученного адреса (адресов) в центральном хранилище совместно с идентификатором абонента;

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

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

Используемый здесь термин «сервер приложений» охватывает стандартный сервер приложений SIP, а также другие серверы, которые имеют интерфейс SIP.

Предпочтительно, чтобы центральным хранилищем являлся домашний абонентский сервер, причем для пересылки интерфейсного адреса (адресов) на домашний абонентский сервер использовался интерфейс Sh. Для пересылки адреса (адресов) в другие центральные хранилища могут быть использованы такие протоколы, как Протокол доступа к каталогам (LDAP) и Язык структурированных запросов (язык SQL).

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

Запрос может быть получен на сервере приложений распределителем средства предварительной обработки, например средством предварительной обработки сервера XDMS.

Запрос может быть послан на сервер приложений от абонентского терминала через интерфейс Ut.

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

Согласно пятому аспекту изобретения предлагается сервер приложений для использования в IP-мультимедийной подсистеме, причем сервер приложений содержит:

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

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

Согласно шестому аспекту изобретения предлагается сервер приложений для использования в IP-мультимедийной подсистеме, причем сервер приложений содержит:

вход для приема запроса, относящегося к абоненту;

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

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

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

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

Фиг.1 - схематическая иллюстрация интеграции IP-мультимедийной подсистемы в систему 3G мобильной связи;

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

фиг.3 - схематическая иллюстрация процесса распределения сервера SIP-AS для абонента во время регистрации в IMS;

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

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

фиг.6 - схематическая иллюстрация процесса обработки запроса, принятого от абонента через интерфейс, не относящийся к ISC, где абонент зарегистрирован в IMS; и

фиг.7 - схематическая иллюстрация процесса обработки запроса, принятого от абонента через интерфейс, не относящийся к ISC, где абонент не зарегистрирован в IMS.

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

В технических стандартах 3GPP, на которые выше делались ссылки, описывается использование критериев начальной фильтрации (IFC), которые хранятся в сервере HSS и которые посылаются в узел обслуживающей функции управления вызовом/сеансом (S-CSCF) либо после регистрации абонента, либо при выполнении входящего вызова к незарегистрированным абонентам. Обычно критерии IFC для абонента содержат конкретный адрес сервера приложений (AS) SIP, например в виде полностью определенного доменного имени (FQDN). Это идентифицирует сервер AS, который распределен для данного абонента применительно к заданной услуге. (IFC может содержать два или более адресов AS, связанных с соответствующими услугами IMS.) Если адресом AS в IFC является идентификатор SIP-URL, то для преобразования SIP-URL в IP-адрес используется сервер DNS. Функция S-CSCF может кэшировать связь между конкретным адресом SIP-AS и IP-адресом с целью обеспечения эффективности. Такое кэширование выполняется, как правило, в клиенте DNS (в S-CSCF), причем кэширование выполняется по каждому узлу, а не по каждому пользователю.

Здесь предполагается замена конкретного адреса сервера приложений на общий идентификатор AS, например SIP-AS.operator.com. Это идентифицирует заранее определенную группу серверов AS, каждый из которых способен обеспечить заданную услугу IMS. В частности, критерии начальной фильтрации (IFC), которые хранятся в сервере HSS, снабжаются общим именем сервера приложений (например, SIP-AS.operator.com.). При регистрации абонента (или после завершения вызова для незарегистрированного абонента) в S-CSCF через интерфейс Cx загружается IFC в соответствии с процедурами, описанными в 3GPP TS 23.228; 3GPP TS 29.228 и 3GPP TS 29.229. Общий идентификатор SIP-AS преобразуется либо в конкретное имя (например, SIP-AS1.operator.com.), которое дополнительно преобразуется в IP-адрес, либо общий идентификатор преобразуется непосредственно в несколько IP-адресов. Для процесса преобразования используются существующие методы службы DNS. (В случае, когда общий идентификатор преобразуется в конкретное имя, которое, кроме того, преобразуется в IP-адрес, между функцией S-CSCF и службой DNS потребуется двойной двухсторонний обмен данными.) IFC инициирует передачу сообщения о регистрации третьей стороны (например, сообщение SIP-REGISTER) функцией S-CSCF на выбранный сервер SIP-AS. Функция S-CSCF запоминает связь между абонентом и выбранным адресом AS и направляет все последующие сообщения для этого набора фильтров по конкретному адресу SIP-AS.

Для поддержки этого процесса служба DNS обеспечивается общим доменным именем, которое может быть преобразовано в несколько полностью определенных доменных имен или IP-адресов. Общее доменное имя (например, SIP-AS.operator.com., соответствующее конкретной услуге IMS) может представлять большое количество серверов приложений. Полностью определенное доменное имя или IP-адрес представляет конкретный сервер приложений (например, SIP-AS32.operator.com. в случае FQDN). Чтобы дать возможность получения запросов пользователей через интерфейс, который не содержит функцию S-CSCF, при описанном здесь гибком подходе к распределению SIP-AS, распределенному серверу SIP-AS желательно предоставить возможность кэшировать свой контактный адрес (адреса) в центральном хранилище, как правило, сервере HSS, совместно с профилем абонента. Это позволяет направить на распределенный сервер SIP-AS более поздний запрос, полученный через указанный интерфейс.

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

1а. Абонентский терминал инициирует процесс REGISTRATION (регистрации) путем посылки сообщения SIP-REGISTER в функцию S-CSCF (через функцию P-CSCF).

1b. Во время процесса регистрации в функцию S-CSCF из HSS загружается профиль услуг для данного абонента. Этот профиль услуг содержит критерии начальной фильтрации, включающие в себя общий идентификатор серверов приложений.

2а. После завершения процесса регистрации функция S-CSCF на основе IFC узнает, что следует послать запрос REGISTRATION третьей стороны на сервер приложений. Однако функция S-CSCF сначала должна запросить IP-адреса у сервера DNS, послав ему общий идентификатор. Сервер DNS посылает в ответ несколько IP-адресов, соответствующих имеющимся соответствующим серверам AS. Эти адреса сопровождаются соответствующими весовыми коэффициентами, отражающими приоритеты.

2b. Функция S-CSCF выбирает один из возвращенных IP-адресов для направления по нему сообщения REGISTER. Выбор основан на круговом выборе с взвешиванием в соответствии с приоритетом, назначенным службой DNS. Функция S-CSCF кэширует отображение между абонентом и IP-адресом выбранного сервера AS.

2с. Сообщение о регистрации третьей стороны посылается функцией S-CSCF на выбранный сервер AS.

3. После приема сообщения о регистрации третьей стороны сервер AS выполняет следующие действия.

- Запоминает свой собственный адрес в HSS. Этот адрес может в действительности содержать массив адресов для различных интерфейсов, например могут быть разные адреса для приема сообщений SIP, трафика HTTP и т.д. (Этот адрес (или один из этих адресов) может являться адресом SIP-AS, предоставленным для функции S-CSCF во время выполнения шага разрешения идентификаторов, хотя в данном случае в этом нет необходимости.)

- Извлекает из HSS абонентские данные, необходимые для конкретного приложения.

- Сервер AS указывает серверу HSS, что ему необходима информация о последующих изменениях в абонентских данных.

В краткосрочном плане сервер SIP-AS может запомнить свой адрес в HSS с использованием «прозрачных данных» через интерфейс Sh. В долгосрочном плане адрес SIP-AS может быть добавлен к непрозрачным данным в сервере HSS.

Заметим, что, хотя в этом примере сервер HSS является репозиторием для адреса AS (и абонентских данных), вместо него можно использовать какой-либо другой центральный репозиторий. Это может быть база данных, которая (непосредственно) связана с набором серверов AS, реализующих услугу IMS, или которая является общей для всех серверов AS в домене оператора/поставщика услуг.

После завершения этого процесса для абонента будет выбран сервер SIP-AS. Сервер SIP-AS извлечет копию абонентских данных из сервера HSS, а функция S-CSCF кэширует адрес сервера SIP-AS, распределенного данному пользователю. Сервер SIP-AS также запомнит свои адреса в HSS совместно с идентификатором абонента. Во время отмены регистрации сервер SIP-AS удалит запомненный адрес AS из HSS.

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

1. Функция S-CSCF получает запрос SIP для абонента.

2. Функция S-CSCF анализирует запрос SIP. Функция S-CSCF идентифицирует IP-адрес сервера AS, кэшированный ранее для этого абонента.

3. Запрос SIP посылается на сервер SIP-AS. Сервер SIP-AS, имея копию конкретных прикладных данных для абонента, загруженных во время предыдущего процесса регистрации, переходит к обработке запроса SIP.

Далее со ссылками на фиг.5 описывается процедура обработки входящих вызовов для незарегистрированного абонента. Когда абонент еще не зарегистрирован, функция S-CSCF не имеет кэшированного IP-адреса SIP-AS для этого абонента и также не требует, чтобы сервер SIP-AS имел абонентские данные для конкретного приложения от HSS. Процесс протекает следующим образом.

1. Функция S-CSCF получает входящий запрос SIP.

2. Функция S-CSCF загружает профиль услуг из HSS. Он содержит критерии начальной фильтрации, включая общий идентификатор для SIP-AS.

3а. Функция S-CSCF анализирует запрос SIP. Если один из критериев IFC удовлетворяется, то функция S-CSCF понимает, что следует послать входящий запрос SIP на сервер приложений. Идентификатором сервера приложений, находящимся в IFC, является общее имя. Таким образом, функция S-CSCF запрашивает IP-адрес у сервера DNS. Сервер DNS высылает в ответ несколько IP-адресов.

3b. Функция S-CSCF выбирает один из возвращенных IP-адресов для направления по нему сообщения REGISTER. Функция S-CSCF кэширует отображение между абонентом и IP-адресом выбранного сервера AS.

4. Входящий запрос SIP направляется на выбранный сервер SIP-AS.

5. После приема входящего запроса SIP сервер AS выполняет следующие действия.

- Запоминает свой собственный адрес (адреса) для пользователя в HSS.

- Извлекает из HSS абонентские данные, необходимые для конкретного приложения.

- Сервер AS указывает серверу HSS, что ему необходима информация о последующих изменениях в абонентских данных.

Во время отмены регистрации сервер SIP-AS удаляет запомненный адрес AS из HSS. Сервер SIP-AS и функция S-CSCF могут (необязательно) иметь таймер, который указывает, что данные могут храниться в течение некоторого периода времени после отмены регистрации. В этом случае сервер SIP-AS по истечении времени, указанного таймером, удалит запомненный адрес AS.

Заметим, что в некоторых случаях, например когда сервер SIP AS направляет запрос (полученный от S-CSCF) на другой сервер SIP AS, адреса, запомненные в HSS сервером AS, упомянутым первым, могут являться адресами для другого сервера AS. Эта ситуация может возникнуть тогда, когда сервер AS имеет функциональные возможности распределения, реализуемые средством предварительной обработки, или когда не было ответа от первоначально выбранного сервера AS, и был сделан новый выбор. Эта ситуация может возникнуть также тогда, когда имеет место несоответствие между адресом, запомненным функцией S-CSCF, и сервером AS, обслуживающим пользователя. В этом случае сервер AS, который первоначально получает запрос, должен проверить, распределен ли абонент для другого сервера AS, путем просмотра связей «пользователь-сервер AS» в сервере HSS. Если это имеет место, то запрос должен быть направлен нужному серверу AS. Если данный пользователь не распределен для сервера AS (в HSS для него нет связи «пользователь-сервер AS»), сервер AS должен записать свой адрес в HSS. Это позволяет направить трафик из сети FE на нужный сервер AS.

После регистрации абонента в IMS у него есть возможность инициировать некоторое действие, например изменить данные и характеристики конкретной услуги IMS, послав запрос на сервер AS через интерфейс Ut. Функциональный объект, который обрабатывает трафик Ut, называется сервером XDMS (сервер управления документами на языке XML), который обычно находится вместе с конкретным сервером AS. Адрес этого сервера AS может быть запомнен в терминале заранее как адрес по умолчанию для интерфейса Ut. Аналогично тому, как обрабатывается трафик ISC, когда функция S-CSCF маршрутизирует сигнализацию на сервер AS, обслуживающий конкретного пользователя, для обеспечения маршрутизации трафика Ut на сервер XDMS, находящийся вместе с сервером AS, обслуживающим пользователя, потребуется функциональный объект, реализуемый средством предварительной обработки.

Запрос от абонентского терминала, посланный через интерфейс Ut, принимается средством предварительной обработки сервера XDMS. Средство предварительной обработки сервера XDMS через интерфейс Sh ищет адрес сервера AS, который относится к функциональным возможностям XDMS. (Заметим, что это один из адресов AS, который был запомнен в вышеописанных процедурах.) В случае, когда адрес SIP-AS не запомнен, средство предварительной обработки само выберет сервер SIP-AS и направит запрос на этот SIP-AS. Затем сервер SIP-AS, которому направлен запрос, сохранит свой адрес в HSS, извлечет абонентские данные из HSS (или по месту другого центрального хранилища) и перейдет к обработке запроса.

Далее со ссылками на фиг.5 описывается общий процесс обработки запросов от других интерфейсов (включая интерфейс Ut), когда абоненту уже выделен сервер AS.

1. От абонентского терминала через интерфейс принимается запрос. Запрос завершается в «распределителе средства предварительной обработки» (FE-DIST) для услуги, представленной этим средством предварительной обработки.

2. FE-DIST запрашивает из HSS (или другого центрального места хранения) адрес AS для данного приложения.

3. Адрес AS возвращается в FE-DIST.

4. FE-DIST направляет запрос на сервер XDMS.

Далее со ссылками на фиг.6 описывается общий процесс обработки запросов от других интерфейсов (включая интерфейс Ut), когда абоненту еще не выделен сервер AS.

1. От абонентского терминала через конкретный интерфейс принимается запрос. Запрос завершается в «распределителе средства предварительной обработки» для услуги, представляемой этим средством предварительной обработки.

2. FE-DIST запрашивает из HSS адрес AS для данной услуги.

3. В FE-DIST возвращается указание о том, что нет распределенного сервера AS.

4. FE-DIST выбирает сервер AS (для получения имен действительных серверов AS можно использовать другие базы данных).

5. Запрос направляется на выбранный сервер AS.

6. Выбранный сервер AS выполняет следующее.

- Сервер SIP-AS может сохранить свое имя в HSS. (Заметим, что это может не потребоваться, если данная транзакция должна произойти только один раз, и не ожидается появления последующих запросов.)

- Считывает абонентские данные из HSS.

- Обрабатывает запрос.

В случае, когда запрос SIP фактически принимается в S-CSCF, вопрос решается с помощью функции S-CSCF, выбирающей новый сервер SIP-AS с использованием общего идентификатора AS согласно вышеописанному подходу. HSS информируется об этом выборе и, в свою очередь, информирует ранее распределенный сервер AS о том, что он больше не распределен и что он может сбросить запомненные данные и «забыть» о данном пользователе (в результате учета сервером AS изменений в элементе данных в HSS).

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