СПОСОБ СВЯЗИ, БАЗИРУЮЩЕЙСЯ НА ПОДСИСТЕМЕ IP-МУЛЬТИМЕДИА (IMS)

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

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

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

Услуги IP-мультимедиа (IPMM) обеспечивают функциональную комбинацию передачи речевых сигналов, видеосигналов, сообщений, данных и т.д. за одну сессию. Рост количества основных приложений и мультимедиа, которые возможно объединить, приводит к росту количества предлагаемых оконечным пользователям услуг, а также к улучшению коммуникации между отдельными пользователями. Это приводит к новому поколению индивидуализированных улучшенных услуг мультимедийной коммуникации, включая так называемые услуги «комбинационной 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 и 6). Подсистема IP-мультимедиа (IMS) предоставляет основные характеристики для улучшения связи между отдельными пользователями с оконечным пользователем посредством интеграции и взаимосвязи услуг. Подсистема IP-мультимедиа (IMS) делает возможной новую улучшенную связь между отдельными пользователями (клиент-клиент), а также связь пользователя в направлении содержания (клиент-сервер) по IP-сети. Подсистема IP-мультимедиа (IMS) использует протокол инициации сессии (SIP) для установления и управления вызовами или сессиями между пользовательскими (абонентскими) терминалами (или между пользовательскими терминалами и серверами приложений). Протокол описания сессии (SDP), транспортируемый посредством передачи SIP, используется для описания и договора о мультимедийных компонентах сессии. Если протокол инициации сессии (SIP) был создан в качестве протокола пользовательского режима, то подсистема IP-мультимедиа (IMS) предоставляет операторам и поставщикам услуг возможность управления абонентским доступом к услугам и соответственной тарификации пользователей.

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

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

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

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

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

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

Текущая архитектура подсистемы IP-мультимедиа (IMS) предоставляет серверу приложений (AS) возможность инициации сессии, базирующейся на подсистеме IP-мультимедиа (IMS), в ответ на прием сервером приложений (AS) соответствующего запроса по внешнему интерфейсу. Например, можно было предусмотреть то, что запрос на сессию, базирующуюся на подсистеме IP-мультимедиа (IMS), передается на сервер приложений (AS) по интерфейсу HTTP, где пользователь инициирует передачу запроса посредством обращения к web-странице в сети Интернет. В этом случае, при приеме запроса на сессию, сервер приложений (AS) сначала связывается с сервером домашних абонентов (HSS) инициирующего пользователя для определения того, действительно ли пользователь зарегистрирован в подсистеме IP-мультимедиа. Сервер приложений (AS) передает на сервер домашних абонентов (HSS) cформированный для пользователя идентификатор SIP, который сервер домашних абонентов (HSS) может использовать для определения того, действительно ли пользователь является зарегистрированным. Если это истинно, то сервер домашних абонентов (HSS) передает на сервер приложений (AS) идентификатор распределенной пользователю S-CSCF. Затем сервер приложений (AS) передает SIP INVITE на идентифицированную S-CSCF, и процедура установления сессии продолжается иллюстрированным на Фиг.3 способом. Иллюстративным сценарием, где эта ситуация могла бы иметь место, является то, когда абонент мобильной связи 3GPP, являясь зарегистрированным в подсистеме IP-мультимедиа (IMS), входит через домашний компьютер на web-страницу и запрашивает сессию, базирующуюся на подсистеме IP-мультимедиа (IMS), через тот канал.

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

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

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

Раскрытие изобретения

Было признано, что пользователи могут иметь желание получить доступ к услугам подсистемы IP-мультимедиа (IMS), даже в случае если они не зарегистрированы в подсистеме IP-мультимедиа (IMS), и, в особенности, когда средство, используемое ими для инициации запроса на коммуникацию, базирующуюся на подсистеме IP-мультимедиа (IMS), не облегчает регистрацию в подсистеме IP-мультимедиа (IMS).

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

приема запроса на установление связи от упомянутого пользователя на сервере приложений (AS) SIP по интерфейсу для внешней сети либо приема сформированных внутренним или внешним способом входных сигналов, запрашивающих установление связи, базирующейся на подсистеме IP-мультимедиа;

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

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

установления требуемой связи.

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

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

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

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

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

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

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

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

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

приема с сервера приложений запроса на установления связи, связанного с упомянутым пользователем;

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

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

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

приема с сервера приложений запроса на установление связи, связанного с упомянутым пользователем;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема, на решение которой направлено настоящее изобретение, заключается в том, что согласно уровню техники сервер приложений (AS) SIP не может инициировать запрос SIP от имени незарегистрированного пользователя в подсистеме IP-мультимедиа (IMS) и в то же время допускает ввод обслуживающей функции управления сессиями вызовов в путь передачи для выполнения анализа происхождения услуги. Однако это может потребоваться в случае, если сервер приложений (AS) использует другой протокол (отличный от SIP) для установления связи с пользователем (например, HTTP, SMS, ММ или другой мультимедийный протокол) [либо на сервере приложений (AS) возникают внутренние входные сигналы, например, касающиеся обновления статуса контроля присутствия в указанное время], а пользователь требует инициацию запроса SIP от своего лица.

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

Распределение S-CSCF, выполняемое сервером приложений

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

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

2. Сервер приложений (AS) запрашивает необходимые характеристики S-CSCF с сервера домашних абонентов (HSS).

3. Сервер домашних абонентов (HSS) возвращает запрашиваемые характеристики S-CSCF серверу приложений по интерфейсу Sh. Эти функциональные возможности являются новыми, поскольку текущие характеристики S-CSCF могут быть переданы только по интерфейсу Cx.

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

5. Сервер приложений (AS) формирует запрос SIP (например, SIP INVITE), содержащий идентификатор пользователя (например, sip:username@operator.com). Запрос SIP передается на выбранную S-CSCF по интерфейсу ICS. [IP-адрес сервера приложений (AS) идентифицируется S-CSCF в заголовке IP.]

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

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

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

9. Запрос SIP передается соответствующему адресату.

10. Ответ SIP принимается от адресата.

11. Ответ SIP передается на сервер приложений (AS). Это устанавливает сессию SIP.

Распределение S-CSCF, выполняемое посредством I-CSCF

Поток передачи, связанный со вторым вариантом осуществления, иллюстрирован на Фиг.5, где этапы процесса являются следующими:

1. Сервер приложений (AS) пытается найти адрес S-CSCF для пользователя на сервере домашних абонентов (HSS). Сервер приложений (AS) определяет, что пользователь не зарегистрирован и что S-CSCF не была распределена пользователю, как описано выше.

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

3. Сервер домашних абонентов (HSS) отвечает серверу приложений (AS) маркером безопасности. Сервер домашних абонентов (HSS) должен аутентифицировать сервер приложений (AS), а также должен разрешить серверу приложений (AS) функционировать от имени пользователя до формирования маркера безопасности.

4. Сервер приложений (AS) передает запрос SIP, содержащий маркер безопасности (а также идентификатор пользователя и IP-адрес сервера приложений (AS)) на предварительно определенную I-CSCF.

5. I-CSCF выполняет обмен Cx-query и Cx-select-pull с сервером домашних абонентов (HSS) для получения необходимых характеристик S-CSCF.

6. Сервер домашних абонентов (HSS) отвечает на Cx-query и Cx-select-pull, предоставляя необходимые характеристики S-CSCF.

7. I-CSCF выбирает S-CSCF с использованием предварительно определенных критериев.

8. Запрос SIP с маркером безопасности передается с I-CSCF на выбранную S-CSCF. I-CSCF не должна записывать маршрут этого запроса, поскольку он не должен оставаться в пути передачи SIP после установления сессии.

9. S-CSCF выполняет поиск профиля пользователя на сервере домашних абонентов (HSS) и информирует сервер домашних абонентов (HSS) о том, что S-CSCF теперь является распределенной пользователю, пока поддерживается статус незарегистрированного пользователя. Маркер безопасности включен в запросы Cx-put/Cx-pull. Если подлинность маркера подтверждена сервером домашних абонентов (HSS), то S-CSCF известно, что запрос SIP пришел с верного сервера приложений (AS). К тому же этот профиль может содержать информацию о профиле незарегистрированного происхождения.

10. Сервер домашних абонентов (HSS) возвращает профиль пользователя на S-CSCF (предполагая, что маркер является подлинным).

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

12. Запрос SIP передается адресату.

13. Ответ SIP принимается от адресата.

14. Ответ SIP передается на I-CSCF.

15. Ответ SIP передается на сервер приложений (AS).

[SIP определяет, что ответ SIP должен пройти все те же узлы, которые были пройдены запросом SIP. Следовательно, S-CSCF не передает ответ непосредственно на сервер приложений (AS).]

Распределение S-CSCF, выполняемое посредством S-CSCF

Поток передачи, связанный с третьим вариантом осуществления, иллюстрирован на Фиг.6, этапы процесса являются следующими:

1. Сервер приложений (AS) пытается найти адрес S-CSCF для пользователя. Сервер приложений (AS) определяет, что пользователь не зарегистрирован и что S-CSCF не была распределена пользователю.

2. Сервер приложений (AS) запрашивает маркер безопасности с сервера домашних абонентов (HSS). Он необходим S-CSCF (см. ниже) для подтверждения того, что запрос пришел с верного сервера приложений (AS).

3. Сервер домашних абонентов (HSS) отвечает маркером безопасности. Сервер домашних абонентов (HSS) должен аутентифицировать сервер приложений (AS), а также должен разрешить серверу приложений (AS) функционировать от имени пользователя до формирования маркера безопасности.

4. Сервер приложений (AS) передает запрос SIP, содержащий маркер безопасности, на подходящую S-CSCF, например, сервер приложений (AS) может сделать обоснованное предположение относительно наиболее вероятной S-CSCF на основе накопленных данных для данного пользователя.

5. S-CSCF выполняет обмен Cx-query и Cx-select-pull с сервером домашних абонентов (HSS) для получения необходимых характеристик S-CSCF.

6. Сервер домашних абонентов (HSS) отвечает на Cx-query и Cx-select-pull, предоставляя обслуживающей функции управления сессиями вызовов (S-CSCF) необходимые характеристики S-CSCF. Это является новой функциональной возможностью, поскольку предварительно необходимые характеристики S-CSCF включены только в процедуры Cx для I-CSCF.

7. S-CSCF осуществляет выбор S-CSCF. Она может выбрать саму себя, в случае если она имеет необходимые характеристики S-CSCF.

8. Запрос SIP передается с распределяющей S-CSCF на распределенную S-CSCF совместно с маркером безопасности. [Выбор S-CSCF не должен записывать маршрут запроса.]

9. Распределенная S-CSCF выполняет поиск профиля пользователя на сервере домашних абонентов и информирует сервер домашних абонентов (HSS) о том, что теперь она (S-CSCF) является распределенной пользователю, пока поддерживается статус незарегистрированного пользователя. Маркер безопасности включен запросы Cx-put/Cx-pull. Если подлинность маркера подтверждена сервером домашних абонентов (HSS) для того пользователя, то S-CSCF известно о том, что запрос SIP пришел с верного сервера приложений (AS).

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

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

12. Запрос SIP передается соответствующему адресату.

13. Ответ SIP принимается от адресата.

14. Ответ SIP передается на первую S-CSCF.

15. Ответ SIP передается на сервер приложений (AS).

В то время как вышеописанные процедуры касались сервера приложений (AS), инициирующего сессию SIP с пользователем, связанным с публичным идентификатором пользователя (PUI), они также применимы к серверу приложений (AS), инициирующему сессию SIP с «пользователем», связанным с публичным идентификатором услуги (PSI). Публичный идентификатор услуги (PSI) описан в 3GPP TS 23.228.

Специалистам в данной области будет очевидно то, что различные модификации могут быть применены к вышеупомянутым описанным вариантам осуществления, не отступая от объема настоящего изобретения. В иллюстративной модификации вышеописанный со ссылкой на второй и третий варианты осуществления механизм использования маркера безопасности также может быть использован с первым вариантом осуществления для предоставления серверу домашних абонентов (HSS) (от имени распределенной S-CSCF) возможности подтверждения подлинности сервера приложений (AS), от которого был принят запрос SIP. Также специалистам в данной области техники будет очевидно, что маркер безопасности, выданный сервером домашних абонентов (HSS), может быть использован для защиты коммуникации, базирующейся на подсистеме IP-мультимедиа (IMS), кроме коммуникации, базирующейся на предоставлении услуг подсистемы IP-мультимедиа (IMS) незарегистрированным пользователям. Например, маркер безопасности, выданный сервером домашних абонентов (HSS), может использоваться в целом для обеспечения наилучшего средства обеспечения безопасности для передачи, посланной с S-CSCF на сервер приложений (AS) (то есть для защиты всей передачи ISC). В частности, если S-CSCF принимает профиль пользователя с сервера домашних абонентов (HSS) (то есть при регистрации пользователя SIP), то она также принимает маркер безопасности. После того как сервер приложений (AS) принял этот маркер, сервер приложений (AS) должен выполнить проверку того, что маркер безопасности является подлинным (посредством коммуникации с сервером домашних абонентов (HSS) по интерфейсу Sh). Маркер безопасности, вероятно, имеет ограниченный срок действия.