Способ и устройство доступа к подсистеме ip-мультимедиа

Способ и устройство доступа к подсистеме ip-мультимедиа

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

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

Услуги IP-Мультимедиа (IPMM - IP Multimedia) обеспечивают динамическое объединение голоса, видеосигнала, обмена сообщениями, данных и т.д. в пределах одного и того же сеанса связи. С ростом количества основных приложений и средств связи, которые допускают объединение, количество услуг, предлагаемых конечным пользователям, будет расти и практика межабонентской связи будет обогащаться. Это приведет к новому поколению индивидуализированных услуг связи с богатыми мультимедийными возможностями, включающими в себя так называемые услуги "комбинационного IP-Мультимедиа", которые подробнее рассматриваются ниже.

Подсистема IP-Мультимедиа (IMS - IP Multimedia Subsystem) является технологией, определяемой Проектом Партнерства по Системам Третьего поколения (3GPP - Third Generation Partnership Project), для предоставления услуг IP-Мультимедиа в мобильных 3G-системах связи (3GPP TS 23.228 и TS 24.229 Версия 5 и Версия 6). IMS обеспечивает ключевые возможности для обогащения практики связи между абонентами для конечного пользователя через интегрирование и взаимодействие услуг. IMS предоставляет новые богатые возможности взаимодействия между абонентами (клиент-клиент), а также взаимодействия абонента с информационными ресурсами (клиент-сервер) в IP-сети. IMS использует Протокол Инициации Сеанса (SIP - Session Initiation Protocol) для установления и управления вызовами или сеансами связи между пользовательскими терминалами (или пользовательскими терминалами и серверами сети). Протокол Описания Сеанса (SDP - Session Description Protocol), осуществляемый при передаче сигналов по протоколу SIP, используется для описания и согласования информационных компонентов сеанса связи. Для средств передачи данных и управления используются другие протоколы, такие как транспортный протокол реального времени (RTP - Real-time Transport Protocol) и протокол управления передачей в реальном времени (RTCP - Real-time Transport Control Protocol), протокол ретрансляции сеанса обмена сообщениями (MSRP - Message Session Relay Protocol), протокол передачи гипертекста (HTTP - Hyper Text Transfer Protocol). IMS нуждается в сети доступа, которая обычно представляет собой 2G/3G-сеть пакетной радиосвязи общего назначения (GPRS - General Packet Radio Service)/с пакетной коммутацией (PS - Packet Switched), но которая могла бы быть какой-либо другой сетью доступа, например сетью с фиксированной шириной полосы пропускания или сетью WiFi. Фиг. 1 схематично иллюстрирует, как IMS встраивается в архитектуру сети мобильной связи в случае GPRS/PS сети доступа.

Рабочая группа TISPAN европейского института стандартов по телекоммуникациям (ETSI - European Telecommunications Standards Institute) в настоящее время продолжает работать над рекомендациями для сети следующего поколения (NGN - Next Generation Network) для стационарных сетей, основанных на IMS. В качестве части этого проекта будет дано рассмотрение так называемого Домашнего Шлюза IMS (HIG - Home IMS Gateway), который позволит терминалам без поддержки IMS получать доступ к услугам IMS. Ожидается, что HIG обнаружит приложения при эксплуатации в доме и малом офисе, где пользователи могли бы захотеть получить доступ к услугам IMS, используя некоторые терминалы без возможностей IMS, которые могут быть, а могут не быть SIP-терминалами. Примерами терминалов без поддержки IMS, но с поддержкой SIP, являются SIP-телефоны и персональные компьютеры, тогда как примерами терминалов без поддержки IMS, которые не обладают функциями SIP, являются обычные телефоны, в том числе телефоны стандарта DECT. HIG может включать в себя SIP-шлюз, чтобы справляться с проблемами совместимости (например, перевод из SIP в другие протоколы передачи сигналов, требующиеся для пользовательского оборудования).

Текущее предложение для HIG находится до некоторой степени в противоречии с текущими требованиями ограничения доступа для IMS, которые определены в 3GPP Технической Спецификации 33.203. Эти требования предписывают, чтобы каждый терминал, получающий доступ к IMS, имел доступ к IMS SIM (модуль идентификации абонента) (ISIM) приложению. ISIM хранит идентификационную информацию абонента, а также другую информацию, необходимую для аутентификации абонента у сетевого оператора и разрешения доступа к сетевым услугам. ISIM-приложения предоставляются на универсальных смарт-картах (аналогичных сегодняшним SIM-картам GSM). Конечно, терминалы без поддержки IMS, такие как обычное оборудование, не будут обладать необходимым устройством считывания для универсальной смарт-карты или функциональными возможностями IMS.

Решением задачи предоставления для терминалов без поддержки IMS возможности получить доступ к услугам IMS, которое удовлетворяет требованиям безопасного доступа, является назначение каждому терминалу без поддержки IMS универсальной смарт-карты с ISIM-приложением. После этого пользователь должен вставить в HIG универсальную смарт-карту, соответствующую конкретному терминалу без поддержки IMS, если он или она хочет использовать этот терминал для получения доступа к услугам IMS. Такое решение имеет очевидные недостатки в том, что касается гибкости, удобства и стоимости.

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

регистрируют терминал без поддержки IMS в Домашнем шлюзе IMS и

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

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

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

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

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

регистрируют терминал без поддержки IMS в Домашнем шлюзе IMS и

в ответ на упомянутую регистрацию получают информацию от универсального SIM-приложения на смарт-карте UMTS, имеющейся в Домашнем шлюзе IMS, и выполняют IMS-регистрацию от имени упомянутого терминала в IMS с помощью этой информации.

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

по меньшей мере, один интерфейс для сопряжения Шлюза с упомянутыми терминалами без поддержки IMS;

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

первое средство обработки для регистрирования терминала без поддержки IMS в Шлюзе и

второе средство обработки для регистрирования терминала без поддержки IMS, зарегистрированного в Шлюзе, в IMS.

Интерфейс для сопряжения Шлюза с упомянутыми терминалами без поддержки IMS может быть, например, линейным интерфейсом для сопряжение шлюза с существующим оборудованием, таким как потребительские телефоны или телефон стандарта DECT, или интерфейсом ЛВС или беспроводной ЛВС.

Первое и второе средства обработки могут содержать средство для реализации SIP-Шлюза, который выполняет преобразования протоколов между Протоколом Инициации Сеанса, SIP, используемым в IMS, и протоколом, используемым терминалами без поддержки IMS. Для терминала без поддержки SIP SIP-Шлюз может регистрировать в IMS задаваемый по умолчанию открытый идентификатор пользователя, связанный с закрытым идентификатором пользователя с ISIM.

Первое и второе средства обработки могут содержать двусторонний агент пользователя SIP, который работает как в направлении от SIP-сервера к SIP-терминалам, так и в направлении от SIP-клиента к IMS. Двусторонний агент пользователя SIP может регистрировать в IMS персональный открытый идентификатор пользователя, связанный с закрытым идентификатором пользователя на ISIM.

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

Фиг.1 схематично иллюстрирует архитектуру IMS в 3G-сети;

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

Фиг.3 схематично иллюстрирует архитектуру Домашнего шлюза IMS;

Фиг.4 схематично иллюстрирует пример распределения открытого и закрытого идентификаторов пользователя;

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

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

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

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

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

Как уже упоминалось выше, предлагается ввести так называемый Домашний Шлюз IMS (HIG) в общую архитектуру IMS на Фиг. 1. Фиг. 2 иллюстрирует HIG (именующийся на чертежах как "Резидентный Шлюз"), расположенный на участке дома или малого предприятия и обслуживающий множество терминалов, включающих в себя и традиционное оборудование, и терминалы с поддержкой SIP. Фиг.3 подробно иллюстрирует функциональную архитектуру HIG, совместно с интерфейсами для различных внешних пользовательских терминалов. В частности, интерфейс Глобальной Вычислительной Сети (ГВС)/Локальной Вычислительной Сети (ЛВС) используется для подключения HIG к IMS.

Различные существующие терминалы, которые не являются SIP-терминалами, подключаются к HIG через линейный интерфейс, который подсоединяется к SIP-шлюзу. Примерами существующих терминалов являются телефон стандарта DECT и традиционный телефон ("потребительский телефон"). HIG включает в себя шлюз Протокола Инициации Сеанса (SIP) (реализованный в соответствии с 3GPP TS 24.229 и IETF RFC 3261). SIP-шлюз предоставляет возможность взаимодействия между различными протоколами передачи сигналов клиентских терминалов и протоколом SIP, используемым IMS. Например, SIP-шлюз может обеспечить преобразование между протоколами передачи сигналов на основе ISDN, используемыми потребительскими телефонами, и SIP. SIP-шлюз соединяется с интерфейсом ГВС/ЛВС.

IMS, допускающая SIP-терминалы, такие как настольные и портативные ПК и SIP-телефоны, подключается к локальной вычислительной сети (ЛВС) и/или к беспроводной локальной вычислительной сети (БЛВС), к которой также подключается HIG через интерфейсы ЛВС/БЛВС. Уровень Преобразования Сетевых Адресов/Межсетевого Экрана используется для обеспечения преобразования адресов в HIG. Уровень ПСА/МЭ соединяется с интерфейсом ГВС/ЛВС. Каждый из этих терминалов имеет свои собственные универсальные смарт-карты, хранящие соответствующие ISIM-приложения.

SIP-терминалы без поддержки IMS, которые не имеют доступа к ISIM-приложениям, также подключаются к HIG через ЛВС/ГВС и интерфейсы ЛВС/ГВС HIG. Для этих терминалов доступ к услугам IMS облегчается с помощью Двустороннего Агента Пользователя (B2BUA - Back-to-Back User Agent) SIP вместе с модулями ПСА/МЭ. SIP B2BUA действует как в направлении от SIP-сервера к пользовательскому оборудованию, так и в направлении от SIP-клиента к IMS.

И SIP B2BUA, и SIP-шлюз имеют интерфейс для ISIM-приложения, хранящегося на универсальной смарт-карте. Эта универсальная смарт-карта может быть извлекаемой из аппаратного оборудования HIG или может закрепляться в HIG на постоянной основе. ISIM-приложение доступно и действительно для всех терминалов без ISIM, которые подсоединены к IMS через HIG. Конечно, терминалы, которые имеют доступ к своему собственному ISIM-приложению, не используют ISIM в HIG, а используют только ПСА/МЭ функции HIG, как описано выше. Заметим, что при последующем обсуждении все ISIM-приложения, т.е. которые доступны для HIG и доступны для терминалов пользовательского оборудования, ассоциативно связываются посредством IMS с одной учетной записью.

Перед дальнейшим рассмотрением функционирования HIG сначала введем понятия закрытого и открытого идентификаторов пользователя. Они являются функциональной частью IMS и рассматриваются в 3GPP TS 23.228 6.7.0. Закрытый идентификатор пользователя является идентификатором, который "связан" с ISIM и используется IMS для аутентификации и авторизации абонента. Закрытый идентификатор пользователя, как правило, не раскрывается третьим лицам и в некоторой степени является аналогом международного идентификатора абонента мобильной связи (IMSI - International Mobile Subscriber Identity), используемого в GSM-сетях. С другой стороны, открытый идентификатор пользователя используется для идентификации абонентов и/или их пользовательского оборудования для получения права пользоваться услугами IMS, в некоторой степени является аналогом адреса электронной почты или номера телефона. Открытый идентификатор пользователя используется, например, для идентификации адресата запроса сеанса услуги IMS. Абонент может иметь несколько открытых идентификаторов пользователя, связанных с единым закрытым идентификатором пользователя, в то время как разные закрытые идентификаторы пользователя, связанные с данной учетной записью, могут совместно использовать общий открытый идентификатор пользователя. В процессе IMS-регистрации и при условии успешной аутентификации IMS предоставляется информация об открытых идентификаторах пользователя, связанных с абонентом.

Фиг.4 иллюстрирует соответствие открытых и закрытых идентификаторов пользователя, которое могло бы быть реализовано с использованием HIG на Фиг.3. В этом примере имеются два закрытых идентификатора пользователя, связанных с одной и той же учетной записью IMS: "234150123456@operator.net" является закрытым идентификатором пользователя в ISIM в некоторых терминалах пользовательского оборудования с поддержкой SIP, а "234150654321@operator.net" является закрытым идентификатором пользователя в ISIM HIG.

Задаваемый по умолчанию открытый идентификатор пользователя ассоциируется с абонентом и может рассматриваться как групповой идентификатор, который идентифицирует семью или малый офис, которые получают доступ к IMS через HIG и которые имеют свою учетную запись. Задаваемый по умолчанию открытый идентификатор пользователя сохраняется в HIG, связывается в SIP B2BUA только с закрытым идентификатором пользователя 234150654321@operator.net на ISIM в HIG. По меньшей мере, все терминалы без поддержки SIP, т.е. те терминалы, которые неспособны предоставить HIG информацию о соответствующих открытых идентификаторах пользователя, будут доступны другим сторонним пользователям IMS, если эти пользователи используют заданный по умолчанию открытый идентификатор. В примере на Фиг.4 заданным по умолчанию открытым идентификатором пользователя является smith@operator.net. Этот заданный по умолчанию открытый идентификатор пользователя может быть ассоциирован с неявным открытым идентификатором в виде числа E.164, в этом примере "+44113111123456". Неявный идентификатор линии формируется в сети, и B2BUA загружает этот идентификатор в рамках процедуры регистрации.

Пользователь (например, член семьи) Алиса Смит хочет быть доступной на двух терминалах, терминале пользовательского оборудования, которому присвоен закрытый идентификатор пользователя 234150123456@operator.net, и домашнем персональном компьютере без поддержки IMS, соединенном с HIG, который поддерживает SIP. Следовательно, в пределах IMS-сети открытый идентификатор пользователя Алисы "alice.smith@operator.net" должен быть связан с обоими закрытыми идентификаторами пользователя. Алиса имеет дополнительный открытый идентификатор пользователя "alice@operator.net", который она выдает только близким родственникам и друзьям. Она хочет быть доступной по этому персональному идентификатору только на своем терминале пользовательского оборудования. Следовательно, этот идентификатор связывается только с закрытым идентификатором пользователя 234150123456@operator.net.

Муж Алисы Боб хочет быть доступным только через свой портативный компьютер с поддержкой SIP, но без поддержки IMS. Следовательно, открытый идентификатор пользователя Боба "bob.smith@operator.net" связывается в пределах IMS-сети только с закрытым идентификатором пользователя 234150654321@operator.net с ISIM в HIG.

Агенты пользователя (UA - user agent) SIP в терминалах Боба и Алисы регистрируют их персональные идентификаторы, связанные с закрытыми идентификаторами пользователя, в IMS-сети, через SIP B2BUA в HIG. Как уже отмечалось, заданный по умолчанию открытый идентификатор пользователя также связывается с закрытыми идентификаторами пользователя и тоже регистрируется в IMS-сети. Заданный по умолчанию идентификатор может быть зарегистрирован до или после регистрации персональных идентификаторов.

Фиг.5 показывает передачу сигналов, связанную с регистрацией пары терминалов, UA1 и UA2, с поддержкой SIP, но без поддержки IMS, в B2BUA HIG, и с последующими процедурами авторизации между B2BUA и IMS. На чертеже проиллюстрированы узлы прокси-сервера управления состоянием вызовов (P-CSCF - Proxy Call State Control Function) и сервера управления состоянием вызовов (S-CSCF - Serving Call State Control Function) IMS-сети, так же как Домашней Подсистемы Абонентов (HSS - Home Subscriber Subsystem), которая принадлежит сетевому оператору и которая содержит данные об учетных записях и доступе. Процедура передачи сигналов основывается на 3GPP TS24.229 и TS24.228.

1. UA1 регистрируется в SIP B2BUA HIG с заголовком "To" ("Получатель"), включающим в себя локальное имя пользователя ("bob"), которое связано с учетной записью для ISIM.

2. B2BUA необязательно опрашивает пользователя. Абонент может непосредственно задавать, должны ли опрашиваться локальные пользователи и устанавливать пароли для использования локальными пользователями.

3. UA1 повторно посылает сообщение регистрации, если был опрошен. В таком случае сообщение содержит заголовок "Authorization" ("Авторизация"), включающий в себя идентификатор (bob) опрашиваемого пользователя, включенный в состав параметра имени пользователя.

4. SIP B2BUA устанавливает TCP-соединение (как правило, через порт 5061) с P-CSCF.

5. SIP B2BUA устанавливает TLS-соединение с подтверждением установления TLS-связи. Подтверждение установления TLS-связи может возобновить существующий сеанс TLS-связи. Протокол IPsec, как в настоящее время определено в 3GPP, не является опцией, поскольку он не препятствует ПСА. Поэтому TLS используется в этом примере.

6. B2BUA использует закрытый идентификатор пользователя (234150654321@operator.net), сохраненный в ISIM HIG в качестве имени пользователя. Заголовок Contact (Контакт) содержит IP-адрес (или доменное имя) B2BUA. Как правило, этот IP-адрес назначается протоколом динамического управления узла (DHCP - Dynamic Host Control Protocol). Адрес или имя P-CSCF также назначается протоколом DHCP. Выбранный открытый идентификатор пользователя в заголовке To является значением в заголовке To, отправленном от UA1, или преобразованным именем (т.е. bob.smith@operator.net) в случае, если локальное имя пользователя, используемое UA1, отображается HIG на открытый идентификатор пользователя. Абонент может локально конфигурировать любое такое отображение.

7. После исключения некоторых заголовков (Proxy-Require (Требование прокси-сервера) и Security-Client (Механизмы безопасности, поддерживаемые клиентом)) и некоторого содержимого заголовков (например, соответствие безопасности из заголовка Require (Требование)) P-CSCF посылает запрос S-CSCF.

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

9. HSS возвращает S-CSCF один или несколько векторов аутентификации.

10. S-CSCF опрашивает B2BUA/ISIM, посылая SIP-сообщение 401, включающее в себя параметры RAND (случайное число) и AUTN (метка аутентификации), в случае, если требуется аутентификация клиента.

11. P-CSCF добавляет некоторые заголовки к сообщению 401 перед его отправкой B2BUA.

12. B2BUA формирует RES (ответ) и проверяет AUTN, если получен опрос посредством сообщения 401. Затем B2BUA посылает новое сообщение REGISTER (регистрация), включающее в себя заголовок Authorization с профилем в случае, если RES использовался в качестве общего ключа.

13. После исключения некоторых заголовков (Proxy-Require, Security-Verify (Проверка безопасности) и Security-Client) и некоторого содержимого заголовков (например, соответствие безопасности из заголовка Require) P-CSCF посылает запрос S-CSCF. S-CSCF проверяет профиль, основанный на RES от B2BUA с профилем, вычисленным по XRES (ожидаемый ответ). Это необходимо, только если B2BUA был опрошен.

14. S-CSCF посылает в ответ SIP-сообщение 200, включающее в себя заголовки PATH (путь прохождения сообщения), Service-Route (маршрут обслуживания) и P-Associated-URI (унифицированный идентификатор ресурса для определенного зарегистрированного пользователя).

15. B2BUA сохраняет содержимое заголовков Service-Route и P-Associated-URI и затем удаляет заголовки PATH, Service-Route и P-Associated-URI перед отправкой к UA1 сообщения 200.

На этом завершается процедура регистрации для UA1.

16. UA2 регистрируется в SIP B2BUA HIG с заголовком "To", включающим в себя локальное имя пользователя ("alice"), которое связано с учетной записью для ISIM.

17. B2BUA необязательно опрашивает пользователя.

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

19. B2BUA использует закрытый идентификатор пользователя (234150654321@operator.net), сохраненный на ISIM, в качестве имени пользователя. Выбранный открытый идентификатор пользователя в заголовке To является отображенным именем (alice.smith@operator.net).

20. После исключения некоторых заголовков (Proxy-Require, Security-Verify и Security-Client) и некоторого содержимого заголовков (например, соответствие безопасности из заголовка Require) P-CSCF посылает запрос S-CSCF.

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

22. S-CSCF посылает в ответ SIP-сообщение 200, включающее в себя заголовки PATH, Service-Route и P-Associated-URI.

23. B2BUA сохраняет содержимое заголовков Service-Route и P-Associated-URI и затем удаляет заголовки PATH, Service-Route и P-Associated-URI перед отправкой UA1 сообщения 200.

Теперь терминал UA2 зарегистрирован в IMS.

Фиг.6 иллюстрирует передачу сигналов, связанную с регистрацией существующего телефона или "традиционного телефона". Поскольку традиционный телефон не является SIP-терминалом, регистрация терминала в HIG производится SIP-шлюзом после включения питания HIG (или подсоединения традиционного телефона к HIG). Для открытого идентификатора пользователя в заголовке To сообщения REGISTER HIG выбирает задаваемый по умолчанию открытый идентификатор пользователя, т.е. smith@operator.net (Фиг. 6).

Вновь рассмотрим сценарий терминала с поддержкой SIP, Фиг. 7 иллюстрирует передачу сигналов, связанную с установлением IMS-сеанса в случае, когда сеанс начинается UA1 за HIG. Этапы передачи сигналов следующие:

1. UA1 посылает SIP-запрос INVITE (приглашение к сеансу связи) на B2BUA.

2. B2BUA посылает ответ 100 Trying (установка таймеров на нуль).

3. B2BUA добавляет некоторые заголовки к сообщению INVITE. Заголовок From (отправитель) преобразуется в открытый идентификатор пользователя, который идентичен персональному идентификатору для пользователя. Заголовок P-Preferred-Identity (предпочтительный идентификатор) также заключает в себе персональный идентификатор. Заголовок P-Access-Network-Info (информация о типе доступа к сети) заключает в себе наименование типа доступа. В некоторых случаях он не известен из приложения, тогда это может быть добавлено где-нибудь в сети доступа или сформировано абонентом. Номер телефона может быть добавлен, основываясь на идентификаторе линии, сохраненном на ISIM. B2BUA изменяет заголовок Contact и посылает запрос INVITE на P-CSCF.

4. Ответ 100 Trying.

5. P-CSCF удаляет заголовок P-Preferred-Identity и вставляет вместо него заголовок P-Asserted-Identity (утвержденный идентификатор), который заключает в себе содержимое заголовка P-Preferred-Identity, если это разрешено с точки зрения сети. Затем P-CSCF посылает запрос INVITE на S-CSCF.

6. Ответ 100 Trying.

7. S-CSCF удаляет P-Access-Network-Info перед тем, как запрос INVITE отправляется из сети.

8. Ответ 100 Trying.

9. Другая сторона посылает ответ 180 Ringing (контроль посылки вызова).

10. Другая сторона посылает ответ 200 OK (запрос успешно обработан).

11. UA1 подтверждает прием ответа 200 OK с помощью ACK (подтверждение приема).

Фиг. 8 иллюстрирует передачу сигналов, связанную с установлением IMS-сеанса в случае, когда UA1 завершает сеанс связи. Этапы передачи сигналов следующие:

1. Удаленный UA посылает SIP-запрос INVITE на S-CSCF.

2. S-CSCF посылает ответ 100 Trying.

3. S-CSCF выбирает контактный адрес, сохраненный при регистрации, и вставляет его в виде поля Request-URI (унифицированный идентификатор запрошенного ресурса). S-CSCF вставляет исходное поле Request-URI в заголовок P-Called-Party-ID (идентификатор вызываемого абонента) и посылает запрос INVITE на P-CSCF.

4. P-CSCF посылает ответ 100 Trying.

5. P-CSCF удаляет заголовок P-Charging-Vector (идентификатор начисления оплаты) и посылает запрос INVITE на B2BUA.

6. B2BUA посылает ответ 100 Trying.

7. B2BUA удаляет заголовок P-Asserted-Identity (возможно, что содержимое заголовка From заменено содержимым заголовка P-Asserted-Identity). Заголовки Record-Route (запись маршрута) удаляются. Возможно, что B2BUA использует содержимое заголовка P-Called-Party-ID, чтобы заменить содержимое заголовка To. B2BUA использует поле Request-URI в принятом запросе для поиска домашнего пользователя, который предварительно зарегистрировался. Поле Request-URI заменяется на локально сохраненный контактный адрес. B2BUA посылает запрос INVITE на UA1.

8. UA1 посылает ответ 100 Trying.

9. UA1 посылает ответ 180 Ringing.

10. Удаленный UA посылает UA1 ACK через S-CSCF и P-CSCF.

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

- Терминалы, которые не имеют ISIM, используют преимущества защищенного тоннеля от HIG и внешней защиты с использованием ПСА и межсетевого экрана в HIG.

- Оператор не должен предоставлять и обслуживать какие-либо пароли. Локальные пароли полностью определяются абонентом.

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

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

1. Способ обеспечения доступа к услугам Подсистемы IP-Мультимедиа (IMS) посредством терминалов без поддержки IMS, причем способ содержит этапы, на которых:регистрируют терминал без поддержки IMS в Домашнем шлюзе IMS; ив ответ на упомянутую регистрацию выполняют IMS-регистрацию, от имени упомянутого терминала между Домашним шлюзом IMS и IMS, используя информацию регистрации, полученную от приложения модуля идентификации абонента (ISIM-приложения) со смарт-карты универсальной системы мобильной связи (UMTS), имеющейся в Домашнем шлюзе IMS.

2. Способ по п.1, в котором Домашний Шлюз IMS содержит двусторонний агент пользователя протокола инициации сеанса (SIP), обладающий интерфейсом для упомянутого ISIM на универсальной смарт-карте.

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

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

5. Способ по п.3, в котором терминал предоставляет локальный идентификатор, который преобразуется двусторонним агентом пользователя SIP в предварительно сохраненный открытый идентификатор пользователя.

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

7. Способ по п.1, в котором терминал без поддержки IMS не является SIP-терминалом, и этап регистрации терминала в Домашнем Шлюзе IMS содержит этап, на котором обнаруживают цикл на входной линии оконечной аппаратуры терминала.

8. Способ по п.1 или 7, в котором Шлюз имеет предварительно сохраненный задаваемый по умолчанию открытый идентификатор пользователя, который назначается терминалам без поддержки SIP и который используется при регистрации в IMS.

9. Способ по п.1, в котором регистрация терминала в Домашнем Шлюзе IMS выполняется SIP-Шлюзом, обладающим интерфейсом для упомянутого ISIM на универсальной смарт-карте.

10. Способ функционирования Домашнего Шлюза Подсистемы IP-Мультимедиа для обеспечения доступа к услугам Подсистемы IP-Мультимедиа (IMS) посредством терминалов без поддержки IMS, причем способ содержит этапы, на которых:регистрируют терминал без поддержки IMS в Домашнем шлюзе IMS; и в ответ на упомянутую регистрацию получают информацию регистрации от ISIM-приложения со смарт-карты UMTS, имеющейся в Домашнем шлюзе IMS, и выполняют IMS-регистрацию от имени упомянутого терминала в IMS с помощью этой информации.

11. Домашний Шлюз Подсистемы IP-Мультимедиа для обеспечения доступа к услугам Подсистемы IP-Мультимедиа, IMS посредством терминалов без поддержки IMS, причем устройство содержит:по меньшей мере, один интерфейс для сопряжения Шлюза с упомянутыми терминалами без поддержки IMS;устройство считывания для универсальной смарт-карты для считывания данных ISIM-приложения с универсальной смарт-карты;первое средство обработки для регистрирования терминала без поддержки IMS в Шлюзе; ивторое средство обработки для регистрирования терминала без поддержки IMS, зарегистрированного в Шлюзе, в IMS.

12. Шлюз по п.11, в котором интерфейс для сопряжения Шлюза с упомянутыми терминалами без поддержки IMS является линейным интерфейсом для сопряжения шлюза с существующим оборудованием или интерфейсом локальной вычислительной сети (ЛВС) или беспроводной ЛВС.

13. Шлюз по п.11 или 12, в котором первое и второе средство обработки содержит средство для реализации SIP-Шлюза, который выполняет преобразования протоколов между протоколом SIP, используемым в IMS, и протоколом, используемым терминалами без поддержки IMS.

14. Шлюз по п.11 или 12, в котором первое и второе средство обработки содержит средство для реализации двустороннего агента пользователя SIP, который работает в качестве SIP-сервера в направлении к SIP-терминалам, и в качестве SIP-клиента в направлении к IMS.