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

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

Иллюстрации

Показать все

Реферат

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

Заявляется приоритет согласно заявке на патент США № 60/698192, поданной 11 июля 2005 г. и озаглавленной "Способ и устройство для предоставления информации присутствия для поддержки служб беспроводной связи", которая включена в этот документ путем ссылки.

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

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

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

Системы радиосвязи, такие как сотовые системы (например, системы с расширенным спектром, такие как сети с многостанционным доступом с кодовым разделением каналов (CDMA) или сети с многостанционным доступом с временным разделением каналов (TDMA)) предоставляют абонентам преимущество мобильности наряду с широким набором услуг и функций. Благодаря этому преимуществу постоянно растущее число потребителей в значительной мере принимает способ связи как приемлемый для делового и личного использования. Для содействия дальнейшему росту телекоммуникационная отрасль, от производителей до провайдеров услуг, согласилась на большие затраты и усилия для развития стандартов протоколов связи, лежащих в основе различных сервисов и функций. Одна область обслуживания, привлекающая значительное внимание, - полудуплексная связь "Нажми и говори по сотовой" (РоС, Push-To-Talk Over Cellular). Традиционные подходы не обеспечивают адекватного указания на доступность абонента в сети.

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

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

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

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

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

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

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

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

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

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

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

Фиг.1 - схема системы радиосвязи для поддержания атрибутов расширенной информации присутствия в соответствии с изобретением.

Фиг.2 - схема процедуры регистрации для терминалов в системе на фиг.1.

Фиг.3А и 3В - блок-схемы процессов для предоставления расширенной информации присутствия в соответствии с изобретением.

Фиг.4 - схема типичной архитектуры "Нажми и говори по сотовой" (РоС), способной поддерживать службу присутствия, в соответствии с изобретением.

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

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

Фиг.7 - схема типичных компонентов мобильной станции, способной работать в системах на фиг.6А и 6В в соответствии с изобретением.

Фиг.8 - схема корпоративной сети, способной поддерживать процессы, описанные здесь, в соответствии с изобретением.

ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНОГО ВАРИАНТА ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

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

Хотя различные варианты осуществления изобретения описаны по отношению к службе "Нажми и говори по сотовой" (РоС) в сотовой сети с расширенным спектром, очевидно и предполагается, что изобретение имеет применение в других областях услуг связи и радиосетей. Кроме того, хотя изобретение обсуждается по отношению к сетям IMS (Служба Мультимедийных IP Подсистем) и MMD (мультимедийный домен), для обычного специалиста очевидно, что изобретение применимо к любому типу опорных сетей, базирующихся на IP, использующих другие коммуникационные протоколы. Также предполагается, что любой тип протокола установления сеанса, Протокол Инициирования Сеанса (SIP) Инженерной Группы по Развитию Интернета (IETF) или протокол Н.323 Международного Союза Электросвязи (ITU), могут быть использованы для выполнения на практике различных вариантов осуществления изобретения.

Кроме того, этот подход, в соответствии с различными примерами осуществления, описывает способы для распространения атрибутов информации присутствия по сетям IMS (Служба Мультимедийных IP Подсистем) 3GPP (Проект партнерства 3-го поколения) и по сетям MMD (мультимедийного домена) 3GPP2 (Проект 2 партнерства 3-го поколения). IMS обеспечивает мультимедийные IP службы, включая РоС, VoIP (Голос по Интернет-протоколу) или пакетированные голосовые вызовы, мгновенный обмен сообщениями (IМ), службу присутствия, групповую связь и т.д., для мобильных устройств. IMS использует, например, Протокол Инициирования Сеанса (SIP) в качестве сигнального протокола, который более полно описан в рабочих предложениях (RFC) 3261 (которые включены в этот документ путем ссылки) инженерной группы по развитию Интернета (IETF).

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

В примере осуществления беспроводная сеть 101 поддерживает службу групповой связи, например службу "Нажми и говори по сотовой" (РоС), при этом терминалы 103, 105 сконфигурированы как РоС-клиенты (т.е. РоС-терминалы). Для пояснения, РоС-терминал 105 обслуживается удаленной РоС-сетью 107.

Важным аспектом службы РоС является определение присутствия (и, таким образом, доступности) терминалов 103, 105. Доступность информации присутствия поддерживается сервером присутствия 111, который является элементом, принимающим, хранящим и распространяющим информацию присутствия. Информация присутствия, в соответствии с одним из вариантов осуществления, может быть передана сервером приложений 109 на сервер присутствия 111 для публикации на терминалы 103, 105 (т.е. наблюдатели).

Каждый из РоС-терминалов 103, 105 может поддерживать такие аппаратные возможности, как устройство громкой связи и/или гарнитура, а также программные средства, обеспечивающие возможность абоненту конфигурировать терминалы 103, 105 для немедленного приема инициаций вызовов и воспроизведения информации, как только она получена, без вмешательства вызывающего абонента. Этот режим работы известен как автоответ или автоматический режим. Абонент может альтернативно сконфигурировать РоС-терминалы 103, 105 на начальное оповещение абонента и требование, чтобы абонент вручную принимал приглашение к сеансу, до того как информация будет принята. Этот режим работы называется режим ручного ответа. РоС-терминалы 103, 105 могут поддерживать оба или только один из этих режимов работы. Например, абонент может легко изменить конфигурацию режима ответа (AM) РоС-терминалов 103, 105, основываясь на текущих обстоятельствах и предпочтениях (например, абонент в настоящий момент занят или находится в месте общего пользования, поэтому использование громкой связи неприемлемо).

Каждый из РоС-терминалов 103, 105 может также быть сконфигурирован как агент пользователя (UA) Протокола Инициирования Сеанса (SIP). В качестве агента пользователя SIP РоС-терминал 103, 105 может установить сеанс с одним или несколькими агентами пользователя SIP одновременно, эта связь может быть инициирована абонентом путем нажатия кнопки «разговор». РоС-терминалы 103, 105 SIP могут поддерживать различные основанные на SIP службы связи в дополнение к "Нажми и говори" (например, VoIP телефонию, службы присутствия, службы обмена сообщениями и т.п.). Абонент может захотеть временно запретить прием сеансов "Нажми и говори", в то же время оставаясь SIP-зарегистрированным для одной или нескольких SIP-служб. Когда РоС-терминал сконфигурирован не принимать любые входящие сеансы "Нажми и говори", такая конфигурация называется Запрет Входящих Сеансов (ISB).

Кроме того, абонент может пожелать связаться с абонентом, который имеет РоС-терминал с активизацией Запрета Входящих Сеансов. При таком сценарии абонент может отправить Мгновенное Персональное Оповещение этому другому абоненту, чтобы показать, что предпринимаются попытки сеанса РоС. Это Мгновенное Персональное Оповещение принимается даже тогда, когда целевой РоС-терминал активизировал Запрет Входящих Сеансов. Если абонент хочет запретить Мгновенные Персональные Оповещения, абонент может сконфигурировать РоС-терминал не принимать любые входящие Мгновенные Персональные Оповещения, и это называется Запрет Мгновенных Персональных Оповещений (IAB).

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

Открытый Мобильный Альянс (ОМА) определил набор требований для поддержки службы РоС. В частности, спецификация «ОМА (Open Mobile Alliance) Presence SIMPLE enabler» определяет Элемент Информации Присутствия, называемый «Доступность для конкретного Приложения». Этот элемент показывает, возможно ли принять входящий запрос связи, используя определенную службу или устройство (если они определены). Например, если объект, выдающий информацию присутствия (например, терминал 103), обеспечен службой РоС и удовлетворяет одному или нескольким условиям (например, положение внутри покрытия сети 101, соответствие устройства (в смысле аппаратных и/или программных конфигураций) и т.д.), абонент будет «доступным» для службы РоС. Однако, если любое из этих условий было бы не выполнено, абонент был бы «недоступным».

Спецификация «ОМА Presence SIMPLE enabler» также определяет, что «Доступность для конкретного Приложения» должна быть определена в формате данных Формат Данных Информации Присутствия (PIDF) с использованием следующей схемы: <tuple>→<status>→<basic>→open/closed и <service-description> (<кортеж>→<состояние>→<базовое>→открыто/закрыто и -<служба-описание>). Однако очевидно, что такая схема чрезмерно ограниченная. То есть при использовании двоичных величин <базовое> «открыто» и «закрыто» для доступности, сведения наблюдателя ограничены по отношению к тому, что можно ожидать для будущих значений доступности.

В случае РоС службы ОМА доступность абонента устанавливается на «закрыто», когда абонент дерегистрируется в сети, но также она устанавливается на «закрыто», когда абонент включает флаг (или указатель) Запрета Входящих Сеансов (ISB). Эти два случая представляют различные режимы абонента, но, используя модель ОМА, невозможно различить эти разные случаи. Когда абонент не зарегистрирован, наблюдатель может ожидать, что абонент РоС может быть в ближайшем будущем недоступен в любое время (например, абонент может быть в отпуске, и аппарат выключен). Однако когда флаг установлен, наблюдатель может ожидать, что недоступность абонента РоС только временная. Другими словами, абонент будет доступен относительно скоро (например, абонент может быть на важной встрече, и, следовательно, включил ISB, поскольку абонент не хочет, чтобы его кто-либо беспокоил).

Подход, в соответствии с одним из вариантов осуществления изобретения, расширяет базовый двойной тип доступности информацией состояния регистрации, состояния запрета и участия в сеансе, указывающей дополнительные детали информации доступности. В примере осуществления эта информация может быть получена из пакета событий состояния регистрации Протокола Инициирования Сеанса (SIP). Как пояснялось ранее, терминалы 103, 105 могут использовать SIP для установления и прекращения сеансов связи между ними. Важной функцией SIP является операция регистрации, которая обеспечивает связывание Унифицированного Идентификатора Ресурса SIP (URI) (т.е. запись адреса) и одного или нескольких контактов URI. Метод SIP REGISTER позволяет агенту пользователя управлять регистрациями, например контакты могут быть добавлены или удалены, а для предотвращения несанкционированного доступа могут быть применены установки. В SIP-протоколе регистрации заканчиваются по истечении определенного периода времени, и, таким образом, требуется производить обновление.

На фиг.2 показана схема процедуры регистрации для терминалов на фиг.1. Пакет событий состояния регистрации детально описан в документе IETF RFC 3680, озаглавленном «Пакет Событий для Регистрации Протокола Инициирования Сеансов (SIP)» и включенном в этот документ путем ссылки. RFC 3680 определяет следующие состояния событий. Состояние 201 Init (Начальное), состояние 203 Active (Активное), и состояние 205 Terminated (Завершенное). Однако только Активное состояние и Завершенное состояния полезны для определения наличия присутствия. Конечный автомат 200 для процедуры регистрации показан с событиями, которые имеют отношение к предоставлению информации присутствия. Конечный автомат 200 представляет собой конечный автомат для одного контакта, так что его экземпляр запускается, когда контакт регистрируется, и удаляется при удалении контакта. Когда в адресе записи нет зарегистрированных контактов, автомат находится в Начальном состоянии. Когда контакт регистрирует адрес записи, конечный автомат 200 переходит из Начального состояния 201 в Активное состояние 203. То есть, когда новый контакт добавлен, конечный автомат для этого контакта запускается и переходит в Активное состояние 203. Конечный автомат 200 остается в Активном состоянии 203, если есть хотя бы один контакт, привязанный к адресу записи. Когда срок последнего контакта истекает или его удаляют, регистрация переходит в Завершенное состояние 205.

В соответствии с вариантом осуществления изобретения сервер приложений 109 (на фиг.1) может быть абонентом пакета событий регистрации. Извещение генерируется абонентам, когда случается любое событие или в конечном автомате адреса записи, или конечном автомате контакта. Представляющие интерес события включают регистрацию, обновление, истечение срока, отсутствие регистрации и отклонение. Определенные состояния регистрации, например Активное состояние 203, Завершенное состояние 205, могут быть определены в информации присутствия.

Кроме того, для РоС-службы ОМА определена дополнительная информация доступности для представления следующей информации о состоянии: ISB (Запрет Входящего Сеанса), IАВ (Запрет Мгновенного Персонального Оповещения) и максимальное число одновременно разрешенных (или конкурентных) РоС-сеансов, которое может быть достигнуто.

На фиг.3А и 3В показаны блок-схемы процессов для предоставления расширенной информации присутствия в соответствии с осуществлением изобретения. В соответствии с осуществлением изобретения сервер приложений 109 может придерживаться архитектуры IP Мультимедиа Подсистем (IMS). Взаимодействие в предоставлении информации присутствия между сервером приложений 109 (например, РоС-сервером) и сервером 111 будет объяснено ниже.

На этапе 301 сервер приложений 109 может запросить пакет событий состояния регистрации, чтобы получать обновления об изменении событий (или состояний). Понятно, что состояние регистрации может быть рассмотрено как один из видов информации присутствия, но оно не непосредственно используется для службы присутствия, так как сервер присутствия 111 ожидает, что все публикации должны быть предоставлены в определенном, заданном формате, например, Формате Данных Информации Присутствия (PIDF). Процедуры запроса сервером приложений пакета событий состояния регистрации детализированы в 3GPP TS 34.229 и 3GPP2 X.S0013-004-A, включенных в этот документ путем ссылки.

В соответствии с осуществлением изобретения сервер приложений 109 использует состояние регистрации (например, как определено в RFC 3680) как ввод данных для информации присутствия. Другими словами, состояние регистрации отображается в наличии присутствия (на этапе 303), таким образом, предоставляя дополнительное значение доступности. Далее информация присутствия публикуется в соответствии с заданным форматом на этапе 305.

Альтернативно сервер приложений 109 сам может иметь сведения об информации состояния (сценарий, показанный на фиг.3 В). Например, полагая сервер приложений 109 РоС-сервером, индикаторы ISB или IAB могут быть установлены непосредственно на РоС-сервере 109, используя РоС-установки пакета событий. По этому сценарию индикаторы состояния запрета, т.е. индикаторы ISB или IAB, определяются (этап 311) как установки мобильного терминала 103. В другой момент, полагая, что сервер приложений 109 является РоС-сервером, РоС-сервер определяет, достиг ли РоС-абонент максимального числа разрешенных одновременных РоС-сеансов (этап 311).

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

В соответствии с осуществлением изобретения сервер присутствия 111 использует Формат Данных Информации Присутствия (PIDF) для сбора информации присутствия. PIDF определен в документе RFC 3863, озаглавленном как Формат Данных Информации Присутствия (PIDF) (включен в этот документ путем ссылки). Таким образом, формат PIDF, в примере осуществления изобретения, может быть расширен состоянием регистрации, состоянием запрета и информацией участия в сеансе. Структура Расширяемого Языка Разметки (XML) для этой информации может быть определена как расширение PIDF. В примере осуществления могут быть заданы три значения расширения: <registration-state>, <barring-state> и <session-participation> (<состояние регистрации>, <состояние запрета> и <информация участия в сеансе>).

Таблица 1 описывает пример задания структуры XML (расширяемого языка разметки):

В одном из примеров абонент РоС становится недоступен из-за нерегистрации: <registration-state>terminated</registration-state> отображается из пакета событий состояний регистрации, <barring-state>terminated</barring-state> отображается из пакета событий установок РоС. В таблице 2 показан соответствующий XML.

В другом примере служба сеанса РоС становится недоступной из-за установки флага ISB. <registration-state>active</registration-state> отображается из пакета событий состояний регистрации, <barring-state>active</barring-state> отображается из пакета событий установок РоС. В таблице 3 показан соответствующий XML:

В другом примере служба сеанса РоС становится недоступной из-за того, что было достигнуто максимальное число одновременных сеансов РоС: РоС-сервер публикует элемент <session-participation>, чтобы сообщить об этом. В таблице 4 показан соответствующий XML:

По еще одному сценарию служба экстренного оповещения РоС недоступна из-за того, что флаг IАВ установлен во включенное состояние "on": <registration-state>active</registration-state> отображается из пакета событий состояний регистрации, <barring-state>active</barring-state> отображается из пакета событий установок РоС. В таблице 5 показан соответствующий XML:

На фиг.4 представлена схема примера осуществления архитектуры связи "Нажми и говори по сотовой" (РоС), способной поддерживать службу присутствия в соответствии с одним из примеров осуществления изобретения. Для поддержки РоС-службы РоС-клиент и РоС-сервер связываются с модулем 405 присутствия, чтобы убедиться, что информация присутствия о РоС-клиенте известна. Модуль 405 присутствия (который может быть использован как сервер присутствия) является объектом, который принимает, хранит и распространяет информацию присутствия о РоС-клиентах. Информация присутствия может быть опубликована РоС-сервером 403 по поручению РоС-клиента 401. Эта информация может быть запрошена наблюдателем или РоС-сервером 403 по поручению РоС-клиента 401. В соответствии с различными осуществлениями изобретения информация состояния (например, состояние регистрации, состояние запрета и информация участия в сеансе) факторизирована в определение доступности присутствия РоС-клиента 401. Как показано, например, ISB флаг 407а или IAB флаг 407b могут быть использованы для предоставления дополнительной информации доступности.

Модуль присутствия 405 взаимодействует с модулем 409 Управления Документированием XML (XDM), который управляет документами XML, хранящимися в сети (например, специальные документы РоС, контакт-лист URI и т.д.). Среди других функций управления модуль 409 XML может подписываться на изменения, сделанные в этих XML-документах, так что когда изменения в документе происходят, получают извещение. Модуль 409 XDM может быть выполнен в виде фиксированного терминала или абонентского оборудования.

Возможности РоС-клиента 401 и сервера присутствия 405 по поддержке РоС-службы поясняются далее. РоС-клиент 401 может получить доступ к РоС-службе и может находиться внутри терминала доступа (например, мобильного), как показано на фиг.1. РоС-клиент 401 сконфигурирован для обеспечения инициирования РоС-сеанса и разблокировки, так же как выполнения регистрации в, например, SIP/IP ядре 411. РоС-клиент 401 может также выполнить аутентификацию абонента SIP/IP сети 411. Кроме того, РоС-клиент 401 генерирует и обменивается речевым графиком (т.е. РоС-графиком), используя совместно действующие процедуры и протоколы, например процедуры управления речевым графиком, согласование протокола управления речевым графиком, возможность установить Индикацию Режима Ответа (Ручной ответ, Автоответ), Запрет Входящего Сеанса и Запрет Входящих Мгновенных Персональных Оповещений, поддержку одновременных РоС-сеансов и процедуры адаптации в плоскости абонента, если они инициированы РоС-сервером 403.

РоС-сервер 403 обеспечивает две основные функции, разрешающие РоС-службу: функцию РоС-управления и функцию РоС-участия. Конкретная роль (управления или участия) РоС-сервера 403 определяется во время установки РоС-сеанса и остается установленной на всем продолжении сеанса. В течение РоС-сеанса один РоС-сервер 403 выполняет функцию РоС-управления, однако, может быть один или несколько РоС-серверов, выполняющих функцию РоС-участия в РоС-сеансе.

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

Кроме того, как упоминалось, РоС-сервер 403 может брать на себя роль наблюдателя, в этой функции сервер 403 может запрашивать информацию присутствия от службы присутствия (например, модуля присутствия 405), чтобы обеспечить посредничество в отношении атрибутов присутствия в принудительном применении политики для РоС-сеанса (например, при статусе «недоступен» РоС-клиента, принуждение к установкам РоС-присутствия РоС-клиентов и т.д.). Отметим, что РоС-сервер 403 может поддерживать принудительную политику для управления РоС-сеансом, основанную на относящейся к РоС или общей информации присутствия.

Как показано, модуль 413 Обнаружения и Регистрации выполняет SIP регистрацию в SIP/IP ядре 411, показывая поддержку РоС-службы в запросе регистра. После успешной регистрации РоС-абонента связь может начинаться. Кроме того, модуль 415 аутентификации/авторизации обеспечивает аутентификацию для РоС-клиента 401 для доступа к РоС-службе.

В целях пояснения конкретные элементы информации присутствия РоС и процедуры присутствия описаны в контексте ОМА РоС-службы. Набор элементов присутствия задан, чтобы выразить статус присутствия РоС-абонента. В таблице 6 перечислены элементы присутствия, отображаемые в соответствующие элементы информации присутствия.

Таблица 6
Элемент присутствия	Элементы информации присутствия	Описание
Готовность к службе РоС-сеанса	«Готовность конкретного приложения к РоС-сеансу»	Указывает, готов ли РОС-абонент в настоящее время принять новый входящий РОС-сеанс (Да/Нет)
Готовность к РоС-службе оповещения	«Готовность в конкретном приложении к РоС-службе оповещения»	Указывает, готов ли РОС-абонент в настоящее время принимать входящее Мгновенные Персональные Оповещения (Да/Нет)
Доступность для службы РоС-сеанса (Способен принять новый входящий РоС-сеанс)	«Доступность конкретного приложения для службы РоС-сеанса»	Указывает, способен ли РОС-абонент принять новый входящий РоС-сеанс (Истина/Ложь)
Доступность для РоС-службы оповещения (Способен принимать входящие Мгновенные Персональные	«Доступность конкретного приложения для службы РоС-сеанса»	Указывает, способен ли РОС-абонент принимать входящие Мгновенные Персональные Оповещения (Истина/Ложь)
Участие в РОС-сеансе (В настоящий момент по меньшей мере в одном РОС-сеансе)	«Участие в сеансе»	Указывает, занят ли РОС-абонент в настоящий момент в одном или нескольких РОС-сеансах или РОС-абонент достиг своего максимального числа одновременных РОС-сеансов (Истина/Ложь/Мах)

«Доступность для службы РоС-сеанса» может быть отображена в элементе информации присутствия «Доступность конкретного приложения», имеющем отношение к службе «РОС-сеанса», согласно таблице 7.

Элемент информации присутствия «Доступность для службы РоС-сеанса» может быть отображен в следующий обязательный элемент <status> (статус) с подчиненным элементом <basic> (основной) со значением "open", опциональный элемент <registration-state> (состояние регистрации) со значением "active" (активное); и опциональный элемент <barring-state> (состояние запрета) со значением "terminated" (завершенное)

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

Кроме того, элемент информации присутствия «Доступность для службы РОС-сеанса» может быть преобразован в следующий обязательный элемент <status> с подчиненным элементом <basic> со значением "closed" и опциональный элемент <registration-state> со значением "terminated", или опциональный элемент <barring-state> со значением "active", или опциональный элемент <registration-state> со значением "terminated" и опциональный элемент <barring-state> со значением "terminated". По этому сценарию информация присутствия недоступна для входящих РОС-сеансов. Это происходит, когда РОС-абонент не зарегистрирован, ISB активирован или достигнуто максимальное число одновременных РОС-сеансов.

«Доступность для РоС-службы оповещения» может быть преобразована в элемент информации присутствия «Доступность для конкретного приложения», принадлежащий службе «РОС-оповещение», согласно таблице 8.

Если информация присутствия доступна для входящих Мгновенных Персональных Оповещений РОС, элемент информации присутствия «Доступность для РоС-службы оповещения» может быть преобразован в следующий обязательный элемент <status> с подчиненным элементом <basic> со значением "open" и опциональный элемент <registration-state> со значением "active" или опциональный элемент <barring-state> со значением "terminated".

Указанное состояние случается, когда РОС абонент зарегистрирован, и Запрет Мгновенных Персональных Оповещений (IАВ) не активирован.

Однако, если информация присутствия недоступна для входящих Мгновенных Персональных Оповещений РОС, элемент информации присутствия «Доступность для РоС-службы оповещения» может быть преобразован в следующий обязательный элемент <status> с подчиненным элементом <basic> со значением "closed" и опциональный элемент <registration-state> со значением "terminated" или опциональный элемент <barring-state> со значением "active ". Этот сценарий происходит, когда РОС-абонент не зарегистрирован или Запрет Мгновенных Персональных Оповещений (IАВ) активирован.

«Участие в РОС-сеансе» может быть преобразовано в элемент информации присутствия «Участие в Сеансе», принадлежащий службе «РОС-сеанса», согласно таблице 9.

Элемент информации присутствия «Участие в РОС-сеансе» может быть преобразован в элемент «Участие в сеансе» с подчиненным элементом <basic> со значением "open", если информация присутствия участвует в, по меньшей мере, одном РОС-сеансе, но максимальное число разрешенных одновременных РОС-сеансов не достигнуто. Элемент информации присутствия «Участие в РОС-сеансе» может быть преобразован в элемент «Участие в сеансе» с подчиненным элементом <basic> со значением "open" подчиненным элементом <mах>, если информация присутствия достигла максимума по числу разрешенных одновременных РОС-сеансов.

Что касается процедуры РОС-сервера, если РОС-сервер 403 выполняет функцию РОС-участия, например, собственная РОС-сеть РОС-абонента поддерживает публикацию Информации Присутствия по поручению РОС-клиента 401, РОС-сервер 403 может предоставить элементы информации присутствия, указанные в параметре инициализации 'PRES-SRV-CAP', посылаемом РОС-клиенту 401.

Таблица 10 определяет типичные элементы присутствия, которые могут быть опубликованы РОС-сервером 403.

Таблица 10
РОС-процедура	Элементы информации присутствия	Значение элемента информации присутствия
Общие процедуры
Регистрация	«Доступность конкретного приложения для РОС-сеансов»	- basic: open (обязательный)
		- registration-state: active (Опциональный)
		- barring-state: terminated (Опциональный)
	«Доступность конкретного приложения для РОС-	- basic: open (обязательный)
	оповещений»	- registration-state: active (Опциональный)
		- barring-state: terminated (Опциональный)
	Участие в сеансе	- basic: closed (обязательный)
Дерегистрация	«Доступность конкретного	- basic: closed (обязательный)
	приложения для РОС-сеансов»	- registration-state: terminated (опциональный)
		- barring-state: terminated (опциональный)
	«Доступность конкретного приложения для РОС-	- basic: closed (обязательный)
	оповещений»	- registration-state: terminated (опциональный)
		- barring-state: terminated (опциональный)
Установка: ISB:ON принят	«Доступность для конкретного приложения для РОС-сеансов»	- basic: closed (обязательный)
		- registration-state: active (опциональный)
		- barring-state: active (опциональный)
Установка: ISB: OFF принят	«Доступность конкретного приложения для РОС-сеансов»	- basic: open (обязательный)
		- registration-state: active (опциональный)
		- barring-state: terminated (опциональный)
Установка: IАВ:ON принят	«Доступность конкретного приложения для РОС-	- basic: closed (обязательный)
	оповещений»	- registration-state: active (опциональный)
		- barring-state: active (опциональный)
Установка: IАВ: OFF принят	«Доступность конкретного приложения для РОС-	- basic: open (обязательный)
	оповещений»	- registration-state: active (опциональный)
		- barring-state: terminated (опциональный)
Режим одиночного РОС-сеанса
Инициация РОС-сеанса	«Доступность для конкретного приложения для РОС-сеансов»	- basic: closed (обязательный)
		- registration-state: active (опциональный)
		- barring-state: terminated (опциональный)
	«Участие в сеансе»	- basic: open (обязательный)
		- max (опциональный)
Завершение РОС-сеанса	«Доступность конкретного приложения для РОС-сеансов»	- basic: open (обязательный)
		- registration-state: active (опциональный)
		- barring-state: terminated (опциональный)
	«Участие в сеансе»	- basic: closed (обязательный)
Режим одновременных РОС-сеансов
Инициация РОС-сеанса AND Nsession	«Доступность конкретного приложения для РОС-сеансов»	- basic: open (обязате