Способ и устройство для независимой от среды передачи эстафетной передачи обслуживания

Способ и устройство для независимой от среды передачи эстафетной передачи обслуживания

Иллюстрации

Показать все

Реферат

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

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

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

Мультимедийная подсистема (IMS) протокола сети Интернет (IP) является стандартизованной архитектурой построения сетей следующего поколения (NGN) для предоставления мобильных и стационарных мультимедийных услуг. IMS использует протокол инициации сеанса (SIP) и работает поверх IP. IMS может использоваться для многих разных услуг (например, мгновенного обмена сообщениями, потокового видео, передачи голоса поверх IP (VoIP), и любых других основанных на IP услуг).

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

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

В настоящее время нет интерфейсов или механизмов, которые описывают, каким образом службы IEEE 802.21 могут взаимодействовать с существующими функциональными возможностями управления мобильностью и эстафетной передачи обслуживания, уже определенными в рамках соответствующих спецификаций стандартов беспроводной связи Проекта партнерства третьего поколения (3GPP) или подобных. Нет процедур и функциональных возможностей для объединения служб IEEE 802.21 в пределах 3GPP или других стандартов беспроводной связи, пока не модифицированы существующие механизмы управления мобильностью и процедуры эстафетной передачи обслуживания. Поэтому требуется сервер приложений MIH (эстафетной передачи обслуживания, независимой от среды передачи), который способен к объединению служб MIH в основанной на 3GPP или других стандартах беспроводной связи сети.

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

Раскрыты способ и устройство для выполнения эстафетной передачи обслуживания. Клиент IMS регистрируется в сети IMS и устанавливает сеанс MIH с сервером приложений MIH с использованием SIP. Клиент IMS устанавливает сеанс для основанной на IP услуги (например, VoIP) с равноправным узлом связи с использованием SIP. Сообщения MIH обмениваются для эстафетной передачи обслуживания с сервером приложений MIH по IP. После эстафетной передачи обслуживания, сеанс возобновляется. S-CSCF приводит в действие сервер приложений MIH на основании строки «Службы MIH» и уникального идентификатора, включенного в запрос INVITE (ПРИГЛАШЕНИЯ). Клиент IMS может отправлять запрос REFER (ССЫЛКИ) на сервер приложений MIH после эстафетной передачи обслуживания для возобновления сеанса. В качестве альтернативы, клиент IMS может отправлять запрос RE-INVITE (ПОВТОРНОГО ПРИГЛАШЕНИЯ) на сервер приложений MIH и равноправный узел связи.

КРАТКИЙ ПЕРЕЧЕНЬ ЧЕРТЕЖЕЙ

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

фиг.1 - структурная схема сервера приложений MIH;

фиг.2A-2D - примерная последовательность операций вызова для эстафетной передачи обслуживания в соответствии с одним из вариантов осуществления;

фиг.3A-3D - примерная последовательность операций вызова для эстафетной передачи обслуживания в соответствии с еще одним вариантом осуществления;

фиг.4 - примерное сообщение запроса INVITE;

фиг.5 - примерное сообщение запроса REFER;

фиг.6 - примерное сообщение запроса RE-INVITE, предназначенное для клиента IMS;

фиг.7 - примерное сообщение запроса RE-INVITE, предназначенное для сервера приложений MIH; и

фиг.8 - изменения состояний регистрации клиента IMS.

ПОДРОБНОЕ ОПИСАНИЕ

Когда указывается ссылкой в дальнейшем, термин «блок беспроводной передачи/приема (WTRU)» включает в себя, но не ограничиваясь перечисленным, пользовательское оборудование (UE), мобильную станцию, стационарный или мобильный абонентский пункт, пейджер, сотовый телефон, персональный цифровой секретарь (PDA), компьютер, или любой другой тип пользовательского устройства, способного к работе в беспроводной среде.

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

Фиг.1 - структурная схема сервера 100 приложений MIH. Сервер 100 приложений MIH включает в себя сущность 105 функции MIH (MIHF), интерфейс 110 функции межсетевого обмена (IWF), интерфейс 115 SIP, сущность 120 функции стратегии мобильности и эстафетной передачи обслуживания (MHPF), механизм 125 транспортировки верхнего уровня (например, основанный на IP) и механизм 130 транспортировки L2 (например, основанный на IEEE 802.xx). Сервер 100 приложений MIH содействует бесшовной интеграции функций IP в и из клиента IMS (например, WTRU) по любой допускающей IMS сети через механизм 125 транспортировки верхнего уровня. Сервер 100 приложений MIH содействует бесшовной интеграции функций IEEE 802.xx в и из клиента IMS через сеть доступа 802.xx с помощью механизма 130 транспортировки L2. Сервер 100 приложений MIH также поддерживает сигнализацию и интерфейсы SIP с S-CSCF в сети IMS через интерфейс 115 SIP.

Сущность 105 MIHF принимает сообщения MIH (то есть события и информацию о MIH) через механизм 125 транспортировки верхнего уровня (например, по IP) и/или механизм 130 транспортировки L2 (например, IEEE 802.xx). Сущность 105 MIHF отправляет сообщение MIH (то есть события, информацию и команду MIH) через механизм 125 транспортировки верхнего уровня или механизм 130 транспортировки L2 в ответ на сообщения MIH. Сущность 105 MIHF также может выводить сигнализацию событий в сущность 120 MHPF (например, изменение текущего состояния технологии канального уровня, поддерживающей сеанс) или на интерфейс 110 IWF (например, указание успешного завершения эстафетной передачи обслуживания).

Интерфейс 110 IWF преобразует сообщения SIP, принятые через интерфейс 115 SIP, в сообщения MIH, и наоборот. Интерфейс 110 IWF принимает события из сущности 105 MIHF, сигнализацию SIP из интерфейса 115 SIP и команды из сущности 120 MHPF, и преобразует их в сигнализацию MIH или SIP.

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

Интерфейс 115 SIP принимает команды из сущности 120 MHPF для целей управления сеансом, и также может принимать события из сущности 120 MIHF через интерфейс 110 IWF. Интерфейс 115 SIP выводит сигнализацию SIP для целей управления вызовом/сеансом.

Фиг.2A-2D - примерная последовательность 200 операций вызова для эстафетной передачи обслуживания в соответствии с одним из вариантов осуществления. В дальнейшем предполагается, что клиент 160 IMS изначально присоединен к сотовой сети 150 доступа и выполняет эстафетную передачу обслуживания на сеть доступа 155 беспроводной локальной сети (WLAN). Должно быть отмечено, что противоположный сценарий также возможен, и эстафетная передача обслуживания может быть реализована между любыми типами сетей беспроводной связи. Клиент 160 IMS (например, WTRU) регистрируется в сети IMS (то есть у S-CSCF 145) после отыскания посреднической функции 140 управления вызовом и сеансом (P-CSCF) (этап 202). Сущность 164 стратегии обслуживания клиента 160 IMS инициирует сеанс MIH (этап 204). Стек 162 SIP клиента 160 IMS отправляет запрос INVITE в P-CSCF 140 (этап 206). P-CSCF 140 пересылает запрос INVITE в S-CSCF 145 (этап 208). S-CSCF 145 загружает профиль клиента 160 IMS и приводит в действие сервер приложений MIH на основании критериев фильтра (этап 210), которые будут подробно пояснены ниже.

Сервер 100 приложений MIH функционирует в режиме агента пользователя SIP. Интерфейс 115 SIP сервера 100 приложений MIH извлекает уникальный идентификатор и IP-адрес клиента 160 IMS, включенные в запрос INVITE и переправляет их в сущность 120 MHPF (этап 212). Сущность 120 MHPF создает привязку для клиента 160 IMS и указывает выполнение привязки в интерфейс 115 SIP (этап 214). Привязка может включать в себя уникальный идентификатор клиента 160 IMS (например, идентификатор (ID) MIHF), текущий IP-адрес клиента 160 IMS, а также состояние регистрации и таймер регистрации, ассоциативно связанный с состоянием регистрации, которые будут подробно пояснены ниже.

Интерфейс 115 SIP передает сообщение 200 OK (ОДОБРЕНИЯ) клиенту 160 IMS через S-CSCF 145 и P-CSCF 140 (этап 216). Клиент 160 IMS отправляет подтверждение (ACK) на сервер 100 приложений MIH (этап 217). Затем устанавливается сеанс MIH и клиент 160 IMS и сервер 100 приложений MIH могут непосредственно обмениваться сообщениями MIH по IP.

После того как завершение сеанса MIH указано сущности 164 стратегии обслуживания на этапе 218, сущность 164 стратегии обслуживания приводит в действие сущность 166 MIHF для отправки дистанционных сообщений MIH на сервер 100 приложений MIH. Сущность 166 MIHF на клиенте 160 IMS может выполнять процедуру отыскания возможности с сущностью 125 MIHF на сервере 100 приложений MIH (этапы 220, 222). Сущность 166 MIHF также может выполнять процедуру регистрации MIH для регистрации на определенные услуги (этапы 224, 226). Сущность 125 MIHF может выполнять процедуру подписки на события с сущностью 166 MIHF (этапы 228, 230). Сообщения MIH, обмениваемые на этапах 220-230, могут передаваться по IP и могут передаваться с использованием IPsec (протокола защиты сетевого трафика на IP-уровне) для защищенной транспортировки. Сущность 125 MIHF пересылает дистанционные сообщения MIH, принятые от клиента 160 IMS, на сущность 120 MHPF. Это вызывает обновления состояний для клиента 160 IMS. Сущность 120 MHPF также приводит в действие сущность 125 MIHF для отправки дистанционных сообщений MIH. Транспортировка сообщений MIH по IP может выполняться, как раскрыто в обычным образом переуступленной заявке № 60/801,786 на выдачу патента США, зарегистрированной 19 мая 2006 года, которая включена в состав посредством ссылки, как будто полностью изложенная.

Клиент 160 IMS отправляет запрос INVITE на клиента 170 IMS (то есть равноправный узел связи) для установления сеанса VoIP (этапы 232-236). Должно быть отмечено, что VoIP является примером, и может быть установлен сеанс любой другой услуги. Если клиент 170 IMS принимает приглашение, клиент 170 IMS отправляет сигнал 200 OK клиенту 160 IMS (этап 238). Клиент 160 IMS затем отправляет ACK клиенту 170 IMS (этап 239). Затем устанавливается сеанс VoIP между клиентом 160 IMS и клиентом 170 IMS (этап 240).

Клиент 160 IMS обнаруживает, что интенсивность сигнала на интерфейсе сотовой связи понижается. Сущность 166 MIHF отправляет отчет об интенсивности сигнала на сущность 125 MIHF сервера 100 приложений MIH (этап 242). Сущность 125 MIHF отправляет информацию о списке соседей на сущность 166 MIHF (этап 244). Сущность 164 стратегии обслуживания включает интерфейс WLAN клиента 160 IMS и детектирует линию связи на основании информации о списке соседей, и сущность 166 MIHF отправляет указание, что была обнаружена линия связи WLAN (этап 246). Сущность 125 MIHF отправляет команду на сущность 166 MIHF для выполнения эстафетной передачи обслуживания на WLAN (этап 248). Сущность 164 стратегии обслуживания завершает эстафетную передачу обслуживания на WLAN и получает новый IP-адрес (например, с использованием протокола динамического конфигурирования хост-узла (DHCP)), и сущность 166 MIHF указывает сущности 125 MIHF результат эстафетной передачи обслуживания с сотовой сети на WLAN (этап 250). Сообщения MIH, обмениваемые на этапах 242-250, могут передаваться по IP и могут передаваться с использованием IPsec для защищенной транспортировки. Сущность 125 MIHF пересылает дистанционные сообщения MIH от клиента 160 IMS на сущность 120 MHPF.

Сущность 164 стратегии обслуживания инициирует обновление сервера 100 приложений MIH и клиента 170 IMS (этап 252). Клиент 160 IMS отправляет запрос REFER на сервер 100 приложений MIH (этап 254). Запрос REFER может быть определен в способе REFER SIP по RFC 3535 или подавлении неявной подписки способа REFER SIP, как в RFC 4488. Интерфейс 115 SIP сервера 100 приложений MIH извлекает новый IP-адрес и уникальный идентификатор источника в запросе REFER и отправляет их в сущность 120 MHPF, которая обновляет привязку для клиента 160 IMS (этап 256). Сервер 100 приложений MIH отправляет сигнал 200 OK клиенту 160 IMS. Стек 162 SIP указывает обновление сервера приложений MIH в сущность 164 стратегии обслуживания (этапы 258, 260).

Сервер 100 приложений MIH отправляет запрос INVITE клиенту 170 IMS по требованию в запросе REFER (этап 262). Клиент 170 IMS отправляет сигнал 200 OK на сервер 100 приложений MIH, а сервер 100 приложений MIH отправляет ACK клиенту 170 IMS (этапы 264, 266). Сеанс VoIP между клиентом 160 IMS и клиентом 170 IMS возобновляется с использованием нового IP-адреса клиента 160 IMS (этап 268). Затем выполняется повторная регистрация IMS в сети IMS (этапы 270, 272, 274).

Если необходимо, клиент 160 IMS может завершать сеанс MIH с сервером 100 приложений MIH отправкой запроса BYE (ОСВОБОЖДЕНИЯ), как определено SIP. Если сущность 164 стратегии обслуживания решает завершить сеанс MIH с сервером приложений MIH, сущность 166 MIHF отправляет запрос для отмены регистрации в сущность 125 MIHF (этап 276). Сущность 125 MIHF отправляет запрос на отмену подписки на события в сущность 166 MIHF (этап 278). Сущность 166 MIHF отправляет сообщение подтверждения отмены подписки на события в сущность 125 MIHF (этап 280). Сущность 125 MIHF отправляет сообщение подтверждения отмены регистрации в сущность 166 MIHF (этап 282). Сообщения MIH на этапах 276-282 могут отправляться по IP и могут отправляться с использованием IPsec для защищенной транспортировки. Сущность 120 MHPF обновляет регистрационную запись для клиента 160 IMS. Сущность 164 стратегии обслуживания инициирует завершение сеанса MIH с сервером приложений MIH на этапе 284, и запрос BYE отправляется на сервер 100 приложений MIH на этапе 286. Сущности 120 MHPF указывается, что следует завершить сеанс MIH (этап 288). Сущность 120 MHPF указывает завершение обновления записи клиента IMS, и сигнал 200 OK отправляется клиенту 160 IMS (этапы 290, 292). Сеанс MIH, в таком случае, заканчивается, и завершение сеанса MIH указывается сущности 164 стратегии обслуживания (этап 294).

Фиг.3A-3D - примерная последовательность 300 операций вызова для эстафетной передачи обслуживания в соответствии с еще одним вариантом осуществления. В дальнейшем предполагается, что клиент 160 IMS изначально присоединен к сотовой сети 150 доступа и выполняет эстафетную передачу обслуживания на сеть доступа 155 беспроводной локальной сети (WLAN). Должно быть отмечено, что противоположный сценарий также возможен, и эстафетная передача обслуживания может быть реализована между любыми типами сетей беспроводной связи. Клиент 160 IMS (например, WTRU) регистрируется в сети IMS (то есть у S-CSCF 145) после отыскания посреднической функции 140 управления вызовом и сеансом (P-CSCF) (этап 302). Сущность 164 стратегии обслуживания клиента 160 IMS инициирует сеанс MIH (этап 304). Стек 162 SIP клиента 160 IMS отправляет запрос INVITE в P-CSCF 140 (этап 306). P-CSCF 140 пересылает запрос INVITE в S-CSCF 145 (этап 308). S-CSCF 145 загружает профиль клиента 160 IMS и приводит в действие сервер приложений MIH на основании критериев фильтра (этап 310), которые будут подробно пояснены ниже.

Сервер 100 приложений MIH функционирует в режиме агента пользователя SIP. Интерфейс 115 SIP сервера 100 приложений MIH извлекает уникальный идентификатор и IP-адрес клиента 160 IMS, включенные в запрос INVITE и переправляет их в сущность 120 MHPF (этап 312). Сущность 120 MHPF создает привязку для клиента 160 IMS и указывает выполнение привязки в интерфейс 115 SIP (этап 314). Привязка может включать в себя уникальный идентификатор клиента 160 IMS (например, ID MIHF), текущий IP-адрес клиента 160 IMS, а также состояние регистрации и таймер регистрации, ассоциативно связанный с состоянием регистрации, которые будут подробно пояснены ниже.

Интерфейс 115 SIP передает сообщение 200 OK (ОДОБРЕНИЯ) клиенту 160 IMS через S-CSCF 145 и P-CSCF 140 (этап 316). Клиент 160 IMS отправляет ACK на сервер 100 приложений MIH (этап 317). Затем, устанавливается сеанс MIH, и клиент 160 IMS и сервер 100 приложений MIH могут непосредственно обмениваться сообщениями MIH по IP.

После того, как завершение сеанса MIH указано сущности 164 стратегии обслуживания на этапе 318, сущность 164 стратегии обслуживания приводит в действие сущность 166 MIHF для отправки удаленных сообщений MIH на сервер 100 приложений MIH. Сущность 166 MIHF на клиенте 160 IMS может выполнять процедуру отыскания возможности с сущностью 125 MIHF на сервере 100 приложений MIH (этапы 320, 322). Сущность 166 MIHF также может выполнять процедуру регистрации MIH для регистрации на определенные услуги (этапы 324, 326). Сущность 125 MIHF может выполнять процедуру подписки на события с сущностью 166 MIHF (этапы 328, 330). Сообщения MIH, обмениваемые на этапах 320-330, могут передаваться по IP и могут передаваться с использованием IPsec для защищенной транспортировки. Сущность 125 MIHF пересылает дистанционные сообщения MIH, принятые от клиента 160 IMS, в сущность 120 MHPF. Это вызывает обновления состояний для клиента 160 IMS. Сущность 120 MHPF также приводит в действие сущность 125 MIHF для отправки дистанционных сообщений MIH. Транспортировка сообщений MIH по IP может выполняться, как определено в обычным образом переуступленной заявке № 60/801,786 на выдачу патента США, зарегистрированной 19 мая 2006 года.

Клиент 160 IMS отправляет запрос INVITE на клиента 170 IMS (то есть равноправный узел связи) для установления сеанса VoIP (этапы 332-336). Должно быть отмечено, что VoIP является примером, и может быть установлен сеанс любой другой услуги. Если клиент 170 IMS принимает приглашение, клиент 170 IMS отправляет сигнал 200 OK клиенту 160 IMS (этап 338). Клиент 160 IMS затем отправляет ACK клиенту 170 IMS (этап 339). Затем устанавливается сеанс VoIP между клиентом 160 IMS и клиентом 170 IMS (этап 340).

Клиент 160 IMS обнаруживает, что интенсивность сигнала на интерфейсе сотовой связи понижается. Сущность 166 MIHF отправляет отчет об интенсивности сигнала на сущность 125 MIHF сервера 100 приложений MIH (этап 342). Сущность 125 MIHF отправляет информацию о списке соседей на сущность 166 MIHF (этап 344). Сущность 164 стратегии обслуживания включает интерфейс WLAN клиента 160 IMS и детектирует линию связи на основании информации о списке соседей, и сущность 166 MIHF отправляет указание, что была обнаружена линия связи WLAN (этап 346). Сущность 125 MIHF отправляет команду на сущность 166 MIHF для выполнения эстафетной передачи обслуживания на WLAN (этап 348). Сущность 164 стратегии обслуживания завершает эстафетную передачу обслуживания на WLAN и получает новый IP-адрес (например, с использованием DHCP), и сущность 166 MIHF указывает сущности 125 MIHF результат эстафетной передачи обслуживания с сотовой сети на WLAN (этап 350). Сообщения MIH, обмениваемые на этапах 342-350, могут передаваться по IP и могут передаваться с использованием IPsec для защищенной транспортировки. Сущность 125 MIHF пересылает дистанционные сообщения MIH от клиента 160 IMS на сущность 120 MHPF.

Сущность 164 стратегии обслуживания инициирует обновление сервера 100 приложений MIH и клиента 170 IMS (этап 352). Клиент 160 IMS отправляет запрос RE-INVITE клиенту 170 IMS (этап 354). Клиент 160 IMS указывает новый IP-адрес и идентификатор вызова, имеющий отношение к продолжающемуся сеансу VoIP. Клиент 170 IMS принимает запрос RE-INVITE и отправляет сообщение 200 OK клиенту 160 IMS (этап 356). Клиент 160 IMS отправляет ACK клиенту 170 IMS (этап 357).

Клиент 160 IMS затем отправляет запрос RE-INVITE на сервер 100 приложений MIH (этап 358). Интерфейс 115 SIP сервера 100 приложений MIH извлекает новый IP-адрес и уникальный идентификатор источника в запросе RE-INVITE и отправляет их в сущность 120 MHPF, которая обновляет привязку для клиента 160 IMS (этап 360). Сущность 120 MHPF указывает завершение обновления в интерфейс 115 SIP (этап 362). Сервер 100 приложений MIH отправляет сигнал 200 OK клиенту 160 IMS (этап 364). Клиент 160 IMS отправляет ACK на сервер 100 приложений MIH (этап 365). Завершение обновления клиента 170 IMS и сервера 100 приложений MIH указывается сущности 164 стратегии обслуживания на этапе 366, и сеанс VoIP между клиентом 160 IMS и клиентом 170 IMS возобновляется с использованием нового IP-адреса клиента 160 IMS (этап 368). Затем выполняется повторная регистрация IMS в сети IMS (этапы 370, 372, 374).

Если необходимо, клиент 160 IMS может завершать сеанс MIH с сервером 100 приложений MIH отправкой запроса BYE, как определено SIP. Если сущность 164 стратегии обслуживания решает завершить сеанс MIH с сервером приложений MIH, сущность 166 MIHF отправляет запрос для отмены регистрации в сущность 125 MIHF (этап 376). Сущность 125 MIHF отправляет запрос на отмену подписки на события в сущность 166 MIHF (этап 378). Сущность 166 MIHF отправляет сообщение подтверждения отмены подписки на события на сущность 125 MIHF (этап 380). Сущность 125 MIHF отправляет сообщение подтверждения отмены регистрации в сущность 166 MIHF (этап 382). Сообщения MIH на этапах 376-382 могут отправляться по IP и могут отправляться с использованием IPsec для защищенной транспортировки. Сущность 120 MHPF обновляет регистрационную запись для клиента 160 IMS. Сущность 164 стратегии обслуживания инициирует завершение сеанса MIH с сервером приложений MIH на этапе 384, и запрос BYE отправляется на сервер 100 приложений MIH на этапе 386. Сущности 120 MHPF указывается, что следует завершить сеанс MIH (этап 288). Сущность 120 MHPF указывает завершение обновления записи клиента IMS, и сигнал 200 OK отправляется клиенту 160 IMS (этапы 390, 392). Сеанс MIH заканчивается, и завершение сеанса MIH указывается сущности 164 стратегии обслуживания (этап 394).

S-CSCF 145 приводит в действие сервер приложений MIH после приема запроса INVITE от клиента 160 IMS. Тело сообщения запроса INVITE составлено с использованием протокола описания сеанса (SDP). Кодирование многоцелевых расширений электронной почты в сети Интернет (MIME) может использоваться для тела сообщения. В заголовок 's' сообщения запроса INVITE могут быть включены константная строка «Службы MIH» и уникальный идентификатор клиента 160 IMS. Уникальным идентификатором может быть ID MIHF.

S-CSCF приводит в действие сервер приложений MIH на основании способа запроса, универсального идентификатора ресурса (URI) SIP пункта назначения и существования специальной строки (то есть константной строки «Службы MIH» и уникального идентификатора) в теле сообщения запроса INVITE. Способ запроса указывает ссылкой на то, является ли запрос сообщением запроса INVITE или сообщением запроса REFER. URI SIP указывает ссылкой на URI для услуги приложения MIH в этом случае. Например, URI может быть ieee802.21@domain.com.

Фиг.4 - примерное сообщение 400 запроса INVITE. Сообщение 400 включает в себя примерный общедоступный URI 402 сервера приложений MIH и заголовок 404 s, включающий в себя строку «Службы MIH» и уникальный ID клиента IMS (например, ID MIHF).

Фиг.5 - примерное сообщение 500 запроса REFER. Сообщение 500 включает в себя примерный общедоступный URI 502 сервера приложений MIH и заголовок 504 s, включающий в себя строку «Службы MIH» и уникальный ID клиента IMS (например, ID MIHF). Сообщение 500 также включает в себя ID 506 вызова продолжающегося сеанса данных с другим клиентом 170 IMS. Сервер 100 приложений MIH использует это при построении запроса INVITE клиенту 170 IMS.

Фиг.6 - примерное сообщение 600 запроса RE-INVITE, предназначенное для клиента 170 IMS.

Фиг.7 - примерное сообщение 700 запроса RE-INVITE, предназначенное для сервера 100 приложений MIH. Сообщение 700 включает в себя примерный общедоступный URI 702 сервера приложений MIH и заголовок 704 s, включающий в себя строку «Службы MIH» и уникальный ID клиента IMS (например, ID MIHF).

Сервер 100 приложений MIH (то есть сущность 120 MHPF) создает привязку для клиента 160 IMS. Привязка включает в себя уникальный идентификатор клиента IMS (например, ID MIHF), текущий IP-адрес клиента IMS и состояние регистрации клиента IMS, а также таймер регистрации, ассоциативно связанный с состоянием регистрации. Определено пять состояний регистрации (незарегистрированное, ожидания регистрации MIH, зарегистрированное и активное MIH, зарегистрированное и неактивное MIH, и ожидания отмены регистрации MIH), и состояние регистрации изменяется, если истекает соответствующий таймер, или если принято определенное сообщение MIH/SIP, дающее ему команду на изменение.

Фиг.8 - изменения состояний регистрации клиента IMS. В незарегистрированном состоянии, клиент не имеет никакой записи на сервере приложений MIH. Никакой таймер не связан с незарегистрированным состоянием.

По приему начального запроса INVITE состояние меняется на состояние ожидания регистрации MIH. В состоянии ожидания регистрации MIH клиент IMS создал сеанс, но не выполнил регистрацию MIH. Регистрация MIH является последовательностью операций по регистрации на конкретные договорные услуги. Состояние ожидания регистрации MIH ассоциативно связано с таймером A. Регистрация MIH должна быть завершена в пределах значения таймера A; иначе сервер приложений MIH завершает сеанс (то есть незарегистрированное состояние). Если состояние клиента IMS меняется на незарегистрированное состояние, вся имеющая отношение к пользователю информация удаляется. Если регистрация MIH выполняется за значение таймера A, состояние меняется на зарегистрированное и активное состояние MIH.

В зарегистрированном и активном состоянии MIH клиент IMS выполнил регистрацию MIH и поддерживает связь с сервером приложений MIH. Зарегистрированное и активное состояние ассоциативно связано с таймером B. Если никакого обмена информацией не происходит до того, как истекает таймер B, состояние меняется на зарегистрированное и неактивное состояние MIH. Если принят запрос отмены регистрации MIH, состояние меняется на состояние ожидания отмены регистрации MIH.

В зарегистрированном и неактивном состоянии MIH клиент IMS выполнил регистрацию MIH, но не был на связи с сервером приложений MIH в течение определенного периода времени. Зарегистрированное и неактивное состояние MIH ассоциативно связано с таймером C. Сеанс истекает, если никакого обмена информацией не происходит с сервером приложений MIH до того, как истекает таймер C (то есть состояние меняется на незарегистрированное состояние). Если принята передача, иная, чем запрос отмены регистрации, до того, как истекает таймер C, состояние меняется на зарегистрированное и активное состояние MIH. Если запрос отмены регистрации принят до того, как истекает таймер C, состояние меняется на состояние ожидания отмены регистрации MIH.

В состоянии ожидания отмены регистрации MIH клиент IMS выполнил отмену регистрации и собирается завершить сеанс. Состояние ожидания отмены регистрации ассоциативно связано с таймером D. Сообщение BYE SIP должно приниматься сервером приложений MIH в пределах значения таймера D; иначе, сервер приложений MIS выполняет «ручное» завершение сеанса (то есть удаляет все записи клиента IMS).

Таблица 1 показывает примерные значения таймеров.

Таблица 1
Состояние регистрации	Ассоциативно связанный таймер	Примерное значение таймера
Незарегистрированное	Ни один	Нет
Ожидание регистрации MIH	Таймер A	10 секунд
Зарегистрированное и активное MIH	Таймер B	3000 секунд
Зарегистрированное и неактивное MIH	Таймер C	2000 секунд
Ожидание отмены регистрации MIH	Таймер C	10 секунд

Варианты осуществления

1. Способ выполнения эстафетной передачи обслуживания.

2. Способ по варианту 1 осуществления, содержащий регистрацию в сети IMS.

3. Способ по варианту 2 осуществления, содержащий установление сеанса MIH с сервером приложений MIH с использованием SIP.

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

5. Способ по любому одному из вариантов 2-4 осуществления, содержащий обнаружение необходимости в эстафетной передаче обслуживания.

6. Способ по варианту 5 осуществления, содержащий обмен сообщением MIH для эстафетной передачи обслуживания с сервером приложений MIH по IP.

7. Способ по варианту 6 осуществления, содержащий выполнение эстафетной передачи обслуживания и возобновление сеанса для основанной на IP услуги.

8. Способ по любому одному из вариантов 3-7 осуществления, в котором сеанс MIH устанавливается отправкой запроса INVITE в S-CSCF, которая приводит в действие сервер приложений MIH.

9. Способ по варианту 8 осуществления, в котором запрос INVITE включает в себя строку «Службы MIH» и уникальный идентификатор клиента IMS.

10. Способ по варианту 9 осуществления, в котором уникальным идентификатором является идентификатор MIHF.

11. Способ по любому одному из вариантов 2-10 осуществления, дополнительно содержащий выполнение процедуры отыскания возможности с сервером приложений MIH по IP.

12. Способ по любому одному из вариантов 3-11 осуществления, дополнительно содержащий выполнение процедуры регистрации MIH с сервером приложений MIH по IP.

13. Способ по варианту 12 осуществления, дополнительно содержащий процедуру подписки на события с сервером приложений MIH по IP.

14. Способ по любому одному из вариантов 5-13 осуществления, дополнительно содержащий отправку отчета об интенсивности сигнала на сервер приложений MIH по IP.

15. Способ по варианту 14 осуществления, содержащий прием информации о списке соседей с сервера приложений MIH по IP.

16. Способ по варианту 15 осуществления, содержащий отправку отчета об интенсивности сигналов соседних сот на сервер приложений MIH по IP.

17. Способ по варианту 16 осуществления, содержащий прием команды эстафетной передачи обслуживания с сервера приложений MIH по IP.

18. Способ по варианту 17 осуществления, содержащий отправку результата эстафетной передачи обслуживания на сервер приложений MIH по IP.

19. Способ по любому одному из вариантов 7-18 осуществления, в котором запрос REFER отправляется на сервер приложений MIH после эстафетной передачи обслуживания с использованием SIP, и сервер приложений MIH отправляет запрос INVITE на равноправный узел связи для возобновления сеанса для основанной на IP услуги.

20. Способ по варианту 19 осуществления, в котором запрос REFER включает в себя строку «Службы MIH» и уникальный идентификатор клиента IMS.

21. Способ по варианту 20 осуществления, в котором уникальным идентификатором является идентификатор MIHF.

22. Способ по любому одному из вариантов 7-18 осуществления, в котором запрос RE-INVITE отправляется на сервер приложений MIH и равноправный узел связи после эстафетной передачи обслуживания для возобновления сеанса для основанной на IP услуги.

23. Способ по варианту 22 осуществления, в котором запрос RE-INVITE включает в себя строку «Службы MIH» и уникальный идентификатор клиента IMS.

24. Способ по варианту 23 осуществления, в котором уникальным идентификатором является идентификатор MIHF.

25. Способ по любому одному из вариантов 7-24 осуществления, дополнительно содержащий отправку запроса отмены регистрации на сервер приложений MIH по IP.

26. Способ по варианту 25 осуществления, содержащий отправку запроса BYE на сервер приложений MIH для завершения сеанса MIH.

27. Способ выполнения эстафетной передачи обслуживания.

28. Способ по варианту 27 осуществления, содержащий прием запроса INVITE от клиента IMS через S-CSCF.

29. Способ по варианту 28 осуществления, содержащий создание привязки для клиента IMS.

30. Способ по варианту 29 осуществления, содержащий установление сеанса MIH с клиентом IMS с использованием SIP.

31. Способ по варианту 30 осуществления, содержащий обмен сообщением MIH для эстафетной передачи обслуживания с клиентом IMS по IP.

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

33. Способ по варианту 32 осуществления, содержащий прием результата эстафетной передачи обслуживания от клиента IMS.

34. Способ по варианту 33 осуществления, дополнительно содержащий прием запроса REFER от клиента IMS.

35. Способ по варианту 34 осуществления, содержащий обновление привязки.

36. Способ по варианту 35 осуществления, содержащий отправку запроса INVITE на равноправный узел связи согласно требованию в запросе REFER.

37. Способ по любому одному из вариантов 34-36 осуществления, в котором запрос REFER включает в себя строку «Службы MIH» и уникальный идентификатор клиента IMS.

38. Способ по варианту 37 осуществления, в котором уникальным идентификатором является идентификатор MIHF.

39. Способ по любому одному из вариантов 34-36 осуществления, дополнительно содержащий прием запроса RE-INVITE от клиента IMS.

40. Способ по варианту 39 осуществления, содержащий обновление привязки.

41. Способ по любому одному из вариантов 39-40 осуществления, в котором запрос RE-INVITE включает в себя строку «Службы MIH» и уникальный идентификатор клиента IMS.

42. Способ по варианту 41 осуществления, в котором уникальным идентификатором является идентификатор MIHF.

43. Способ по варианту 36 осуществления, в котором запрос INVITE включает в себя строку «Службы MIH» и уникальный идентификатор клиента IMS.

44. Способ по варианту 43 осуществления, в котором уникальным идентификатором является идентификатор MIHF.

45. Способ по любому одному из вариантов 29-44 осуществления, в котором состояние регистрации и таймер регистрации поддерживаются в привязке для клиента IMS.

46. Способ по варианту 45 осуществления, в котором состояние регистрации является одним из незарегистрированного состояния, состояния ожидания регистрации, зарегистрированного и активного состояния, зарегистрированного и неактивного состояния, и состояния ожидания отмены регистрации.

47. WTRU для выполнения эстафетной передачи обслуживания.

48. WTRU варианту 47 осуществления, содержащий уровень приложения IMS, сконфигурированный для установления сеанса для основанной на IP услуги с равноправным узлом связи с использованием SIP.

49. WTRU по варианту 48 осуществления, содержащий сущность стратегии обслуживания, сконфигурированную для установления сеанса MIH с сервером приложений MIH с использованием SIP и выполнения эстафетной передачи обслуживания, так что сеанс для основанной на IP услуги возобновляется после эстафетной передачи обслуживания.

50. WTRU по варианту 49 осуществления, содержащий сущность функции MIH, сконфигурированную для обмена сообщением MIH с сервером приложений MIH по IP.

51. WTRU по любому одному из вариантов 49-50 осуществления, при этом сеанс MIH устанавливается отправкой запроса INVITE в S-CSCF, который приводит в действие сервер приложений MIH.

52. WTRU по варианту 51 осуществления, при этом запрос INVITE включает в себя строку «Службы MIH» и уникальный идентификатор клиента IMS.

53. WTRU по варианту 52 осуществления, при этом уникальным идентификатором является идентификатор MIHF.

54. WTRU по любому одному из вариантов 50-53 осуществления, в котором сущность функции MIH сконфигурирована для выполнения процедуры отыскания возможности с сервером приложений MIH по IP.

55. WTRU по любому одному из вариантов 50-54 осуществления, в котором сущность функции MIH сконфигурирована для выполнения процедуры регистрации MIH с сервером приложений MIH по IP.

56. WTRU по любому одному из вариантов 50-55 осуществления, в котором сущность функции MIH сконфигурирована для выполнения процедуры подписки на события с сервером приложений MIH по IP.

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

58. WTRU по любому одному из вариантов 49-57 осуществления, при этом запрос REFER отправляется на сервер приложений MIH после эстафетной передачи обслуживания с использованием SIP с требованием, чтобы сервер приложений MIH отправлял запрос INVITE на равнопра