Ut интерфейс доступен что это
Технология VoLTE
VoLTE (по англ. Voice over LTE — голос по LTE) — технология передачи голоса по сети LTE, основанная на IP Multimedia Subsystem (IMS). Позволяет предоставлять голосовые услуги и доставлять их как поток данных по сети LTE. В сетях VoLTE (в отличии от публичной сети Интернет, характеризуемой значительными задержками, джитером, потерей пакетов и нарушением порядка их следования) нижележащие транспортный уровень и уровень доступа обеспечивают необходимый уровень качества услуги (QoS) до пользовательского терминала (end-to-end).
При установке (либо модификации) SIP сессии через IMS абонентский терминал (UE) согласовывает свои возможности (capabilities) и запрашивает необходимый уровень QoS, включая тип доступа (media type), битовую скорость, размер пакетов и пр. Эта информация перенаправляется IMS в PCRF, который формирует соответствующие PCC политики (включая требуемую полосу, класс качества, IP фильтры) и транслирует их в P-GW/PCEF. Последний выполняет необходимые действия для установления выделенного потока (dedicated EPS bearer) с требуемыми параметрами качества в рамках существующего пакетного соединения.
Посредством PCRF IMS имеет возможность управлять утилизацией виртуального соединения (EPS bearer), предназначенного для media трафика. Это требует взаимодействия между IP CAN и IMS. Данное взаимодействие разделено на три категории (3GPP TS 22.228, 23.203, 23.228):
На рисунке ниже приведена сетевая модель предоставления услуг VoLTE.
Взаимодействие с другими сетями
Очевидно, что IMS системы не могут едино-моментно вытеснить существующие платформы и сервисы. При этом пользователь IMS должен иметь возможность взаимодействовать с пользователями прочих платформ и архитектур (голосовая связь, видео, SMS и пр.). Поэтому IMS поддерживает взаимодействие с PSTN, ISDN и пр. Кроме того, возможно взаимодействие с не 3GPP Internet приложениями (3GPP TS 22.228).
Тарификация
IMS архитектура допускает использование различных тарифных моделей, основываясь в т.ч. на задействованных транспортных ресурсах, используемых медиа компонентах (audio, video) и т.д. Кроме того, IMS архитектура предполагает обмен информацией о тарификации между различными IMS сетями.
Ожидаемые коммерческие соглашения о тарификации на коммерческих сетях:
Возможности терминалов для поддержки VoLTE (UE RA Capabilities)
Абонентский терминал (UE) сигнализирует сети о поддерживаемом функционале посредством поля FGI (feature group indicators) – в соответствии с 3GPP TS 36.331. За поддержку каждой функции (возможности) отвечает свой бит в FGI:
Установка PDN связанности
Для получения услуг VoLTE абонентский терминал должен установить пакетное (PDN) соединение через «ims» точку доступа (Access Point Name – APN). В типовой схеме взаимодействия – это дополнительное пакетное (PDN) соединение по отношению к соединению через «internet» точку доступа, используемому для передачи данных и выхода в сеть Интернет. При установлении соединения абонентскому терминалу пакетным шлюзом (P-GW) назначается IP адрес в соответствии с профилем абонента в HSS (IPv4/IPv6/оба, динамический/статический адрес). Дополнительно, в соответствии с запросом от абонентского терминала (UE), через опции конфигурации протокола (protocol configuration options – PCO) P-GW может сообщить абонентскому терминалу (UE) адрес (или список адресов) P-CSCF соответствующего IMS домена.
В качестве механизма аутентификации используется EPS authentication and key agreement (AKA). После аутентификации создаются две ассоциации безопасности (Security Association) – на уровне NAS (NAS Security Association) между абонентским терминалом (UE) и MME, а также на уровне AS (AS Security Association) между абонентским терминалом (UE) и базовой станцией (eNodeB). Первая ассоциация используется для шифрования и контроля целостности сигнальных сообщений NAS, вторая – для шифрования и контроля целостности сигнальных сообщений RRC, а также пользовательского трафика. Таким образом, обеспечивается безопасное IP соединение для передачи VoLTE трафика.
В процессе установления пакетного (PDN) соединения создается дефолтное виртуальное соединение (default EPS bearer), которое используется для переноса IMS сигнализации. Поток создается либо с QoS параметрами, определенными профилем абонента в HSS (статические политики), либо в соответствии с политиками, полученными от PCRF (динамические политики). В последнем случае P-GW устанавливает сессию с PCRF через Gx интерфейс; после чего PCRF формирует политики на основании APN и/или абонентских данных, полученных из абонентского репозитория (subscription profile repository – SPR). В таблице ниже приведен пример контекста пакетного подключения абонентского профиля в HSS.
Real Time Communication
4G/5G, VoLTE, RCS, IMS, SIP, WebRTC, IoT/M2M for engineers
Ut interface – what is it for?
VoLTE and RCS support plenty of services – e.g. Call Forwarding, Call Barring or Presence. Some of these services can’t be pre-configured for the subscribers as each of them wants to provision his/her own forwarding/barred numbers or maybe doesn’t want to use the functionality at all. That means we need to have a way how to do a self-provisioning. In IMS we have a dedicated interface and network functionalities which allow to modify the setting of Supplementary Services and Presence Information directly from client (UE) via http/XCAP protocol. For VoLTE this is defined in the GSMA IR.92 and 3GPP TS 24.623, TS 24.423 and 3GPP TS 33.222. GSMA IR.92 directly says:
For supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.
What is the network architecture then?
Ut Reference Point
As we can see the http traffic does’t go through the SBC but through an Authentication Proxy (AP) instead. Its main purpose is to authenticate user requests. It is also used to separate the authentication procedure and the Application Server (AS) specific logic (e.g. Supplementary Service provisioning) to different network entities.
(In case of presence and OMA XDMS architecture we talk about so-called Aggregation Proxy, which is described in its own post.)
The AP is configured as an HTTP reverse proxy. That means that the FQDN of the AS (e.g. MMTel) is configured to the AP in such a way that the IP traffic intended to the AS is routed to the AP. The AP performs the authentication of the UE. After the authentication procedure has been successfully completed, the AP assumes the typical role of a reverse proxy, i.e. the AP forwards HTTP requests originating from the UE to the correct AS, and returns the corresponding HTTP responses from the AS to the originating UE.
As mentioned the protocol for the Ut reference point is the XML Configuration Access Protocol (XCAP). XCAP defines two logical roles: XCAP client (UE) and XCAP servers (MMTel). XCAP protocol allows the client to read, write and modify application configuration data, stored in the server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. XCAP uses the HTTP methods PUT, GET, and DELETE to operate on XML documents stored in the server.
Authentication Proxy – Call Flow
For the Supplementary Services the XML document is called simserv and it is defined in 3GPP TS 24.623. The simservs XML document is composed of a common part, defined by the present document, and a number of XML fragments corresponding to each of the supplementary services.
The UE must configure only settings of one supplementary service per XCAP request. If the supplementary service to be configured contains an element with multiple elements (RFC 4745) (e.g. as for CDIV or CB), then the UE must modify at most one element of the supplementary service per XCAP request.
In order to keep the state of supplementary services synchronized with the network elements and other terminals that the user might be using, the UE should subscribe to changes in the XCAP simserv documents by generating a SUBSCRIBE request. More information about XCAP can be found in the XCAP Protocol post.
MMTel/TAS does not persistently store the simservs XML document. The information from the simserv document is written to a backend database. E.g. over Sh Interface or Service Provisioning Markup Language (SPML) which is an XML-based framework for exchanging user, resource and service provisioning information.
For VoLTE an operator needs to ensure that supplementary service settings are the same in both VoLTE and CS networks. This can be achieved by synchronization between the CS and IMS/MMTEL. This is has been studied in 3GPP but finally no solution was standardized due to the complexity and different ways that such data is stored internally within the likes of the HSS/HLR and VoLTE MMTel AS. A potential solution could be to utilize User Data Convergence (UDC) architecture.
» data-medium-file=»https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=300″ data-large-file=»https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=594″ src=»https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=594&h=341″ alt=»Authentication Proxy + Sh Interface» width=»594″ height=»341″ srcset=»https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=594&h=341 594w, https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=1188&h=682 1188w, https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=150&h=86 150w, https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=300&h=172 300w, https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=768&h=441 768w, https://realtimecommunication.files.wordpress.com/2015/05/ut-sh.png?w=1024&h=588 1024w» sizes=»(max-width: 594px) 100vw, 594px» />
Authentication Proxy + Sh Interface
Authentication
For the authentication and security we usually use the TLS in the Generic Authentication Architecture (GAA) described in ETSI TS 33.220. Internally we divide the AP into two parts:
NAF is the reverse http proxy and handles the TLS security relation with the UE and relieves the application server (AS) of this task. Based on Generic Bootstrapping Architecture (GBA) the NAF can assure the AS that the request is coming from an authorized subscriber.
BSF and the UE shall mutually authenticate using the AKA protocol, and agree on session keys (KS_NAF) that are afterwards applied between UE and NAF. The BSF shall be able to acquire the GBA user security settings (GUSS) from the HSS (via Zh).
Note that physically the NAF and BSF can be different servers. Actually the BSF is in the home network whereas the NAF can be located in a visited network.
The call flow with the GBA AKA looks as follows:
More details about bootstrapping procedure can found in the Aggregation Proxy and Bootstraping post or in ETSI TS 33.220 and 3GPP TS 29.109.
With the next request the UE doesn’t need to do the bootstraping again as the UE and NAF have already established the secure session.
Ut интерфейс доступен что это
- VoLTE (по англ. Voice over LTE — голос по LTE) — технология передачи голоса по сети LTE, основанная на IP Multimedia Subsystem (IMS). Позволяет предоставлять голосовые услуги и доставлять их как поток данных по LTE. VoLTE имеет в три раза больше голосовую ёмкость и ёмкость данных, чем сети 3G UMTS и до шести раз больше, чем сети 2G GSM. Кроме того, она высвобождает пропускную способность, поскольку заголовки пакетов меньше, чем у неоптимизированной VoIP/LTE.
Wi-Fi Calling — технология, позволяющая совершать голосовые и видеовызовы, обмениваться текстовыми сообщениями по базовой сети сотового оператора через подключение к любой Wi-Fi-сети. Фактически таким образом решается проблема плохого качества голосовой услуги или ее полное отсутствие в помещениях, и при этом отсутствует необходимость развития мобильной сети в отдельных зданиях. Технологически Wi-Fi Calling (или Voice-over-Wi-Fi) – это продолжение услуги Voice-over-LTE (передача голосовых данных по сетям LTE), в основе которой – передача голоса по IP-протоколу. Принципиальное отличие Wi-Fi Calling от существующих сервисов IP-телефонии (Skype или множества приложений, таких как WhatsApp, Viber, Facebook Messenger и пр.) заключается в том, что вызов осуществляется по базовой сети мобильного оператора и является обыкновенным телефонным вызовом с мобильного номера абонента. Для работы VoWiFi должны пропускаться вот такие порты/протоколы: UDP/4500, UDP/500, ESP.
- Территория действия VoLTE в сети Билайн: Москва и Московская область, Санкт-Петербург и Ленинградская область, Калужская область, Смоленская область
Территория действия VoWIFI в сети Билайн: Москва и Московская область
Подключить VoLTE теперь можно через оператора по 0611.
Теперь и звонки в сети 4G! (Билайн)
Билайн запустил VoLTE в Москве и Санкт-Петербурге
Услуга VoLTE
Билайн официально запустил VoWIFI (NEW)
- Территория действия VoLTE и VoWiFi в сети МегаФон
Территория действия с разбивкой по филиалам (VoLTE & WFC)
Услуга подключается автоматически. Если этого не произошло, следует обратиться к оператору с просьбой подключить «IMS-сервисы».
Проверить подключение ims-сервисов и тех.пакета: *105*1*3*2*1# или *105*2*1*2*1#
Альтернативная операторская услуга передачи голоса: приложение eMotion)
VoLTE не совместима с услугами: Персональный гудок, МультиФон Бизнес, МАС, ВАТС, Звонок за счёт друга
Услуга подключается автоматически. Если этого не произошло, воспользуйтесь командой *111*6# для активации услуги «Интернет-звонки».
Для отключения услуги можно воспользоваться командой *111*6*01#.
Услуга «Интернет звонки» в части VoLTE и WiFi-Calling доступен и для абонентов МГТС
- СБЕРМобайл
Оператор работает на базе Теле2. Поддерживается технология VoWiFi в Москве и Санкт-Петербурге
МГТС
Оператор работает на базе МТС. Поддерживаются технологии VoLTE/VoWiFi
Tinkoff Mobile
Оператор работает на базе Теле2. VoLTE не поддерживается. Фактов разработки поддержки VoLTE не обнаружено.
Территория действия VoLTE: Свердловская область
Для подключения набрать *111*6#
Ссылка на услугу
Конфигурация услуг подсистемы ip мультимедиа
Владельцы патента RU 2447602:
Изобретение относится к области передачи цифровой информации, а именно к конфигурации услуг Подсистемы IP Мультимедиа и, в частности, к конфигурации таких услуг пользователями через Ut интерфейс. Технический результат заключается в обеспечении возможности абоненту управлять информацией, относящейся к его услугам, например созданию и назначению идентификаторов услуг общего пользования, управлению политиками авторизации, которые используются, например, сервисами присутствия, управлению политиками конференций и т.д. Для этого способ управления представлением изменяемых пользователем условий услуг Подсистемы IP Мультимедиа в пользовательском терминале, где условия услуг определяются в XML документе, поддерживаемом в сети Подсистемы IP Мультимедиа, содержит включение в XML документ одного или более информационных элементов, определяющих эти условия, которые пользователь может изменять, и, при приеме XML документа или его фрагмента в пользовательском терминале, интерпретирование упомянутого(ых) информационного(ых) элемента(ов) и представление абоненту только тех условий, которые могут изменяться. 3 н. и 6 з.п. ф-лы, 7 ил.
Настоящее изобретение относится к конфигурации услуг Подсистемы IP Мультимедиа и, в частности, к конфигурации таких услуг пользователями через Ut интерфейс.
Услуги IP Мультимедиа обеспечивают динамическое объединение звука, видео, передачи сообщений, данных и т.д. в одной сессии. С ростом числа основных приложений и мультимедиа, которые можно объединять, число услуг, предлагаемых конечным абонентам, будет расти, и использование персональной связи будет расширяться. Это приведет к новому поколению персонализированных, расширенных услуг мультимедийной связи, включая так называемые «объединенные IP Мультимедиа» услуги.
Подсистема (IMS) IP Мультимедиа является технологией, определенной Проектом Партнерства Третьего Поколения (3GPP) и группой ETSI TISPAN для обеспечения услуг IP Мультимедиа по сетям мобильной передачи (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329, выпуски 5-7 и TS24.173, выпуск 7). IMS предоставляет ключевые функции для расширения опыта использования персональной связи конечного пользователя посредством использования стандартизованных средств обеспечения услуг IMS, которые облегчают реализацию новых расширенных услуг персональной связи (клиент с клиентом), а также услуг типа «человек-контент» (клиент-сервер) по IP сети. IMS использует Протокол Инициации Сессии (SIP) для установления и управления вызовами или сессиями между абонентскими терминалами (или абонентскими терминалами и серверами приложений). Протокол Описания Сессии (SDP), выполняемый SIP сигнализацией, используется для описания и согласования мультимедиа компонент сессии. Хотя SIP был создан как протокол коммуникации от абонента к абоненту, IMS позволяет операторам и поставщикам услуг управлять доступом к услугам и оплатой от абонентов, соответственно.
В качестве примера, на фиг. 1 схематично показано, как IMS встраивается в архитектуру мобильной сети в случае сети доступа GPRS/PS (IMS может, конечно, работать в пределах других сетей доступа). Функции Управления Вызовом/Сессией (CSCF) функционируют как SIP-прокси в IMS. Архитектура 3GPP определяет три типа CSCF: Прокси CSCF (P-CSCF), которая является первой точкой контакта в IMS для SIP терминала; Сервисную CSCF(S-CSCF), которая обеспечивает услуги абоненту, на которые абонент подписывается; и запрашивающую CSCF (I-CSCF), чья роль заключается в идентификации корректной S-CSCF и направления на эту S-CSCF запроса, принятого от SIP терминала через P-CSCF.
В сети обслуживания IMS Серверы Приложений (AS) предоставляются для реализации функций обслуживания IMS. Серверы Приложений предоставляют услуги конечным пользователям в системе IMS и могут соединяться или как конечные пункты через определенный 3GPP Mr интерфейс, или «связываться» посредством S-CSCF через определенный 3GPP ISC интерфейс. Во втором случае Критерии Начальной Фильтрации (IFC) используются посредством S-CSCF для определения, какие серверы приложений будут «связываться» во время установления Сессии SIP (или фактически для целей любого соответствующего метода SIP, связанного или не связанного с сессией). IFC принимаются посредством S-CSCF от HSS во время процедуры регистрации IMS в качестве части Абонентского Профиля абонента.
Ut Интерфейс (или более корректно «опорная точка») определен между AS и абонентским терминалом (TS23.002). Ut интерфейс позволяет абоненту управлять информацией, относящейся к его услугам, например созданию и назначению идентификаторов услуг общего пользования, управлению политиками авторизации, которые используются, например, сервисами присутствия, управлению политиками конференций и т.д.
Ut интерфейс, в частности, позволяет абоненту управлять XML данными, связанными с AS, которые определяют, как определенные услуги предоставляются этому абоненту. XML документы обрабатываются Серверами Управления Документами XML (XDMS), которые обычно совмещены с AS. Например, XDMS, отвечающий за управление данными услуг, относящимися к услугам Мультимедийной Телефонии, может совмещаться с Сервером Приложений Мультимедийной Телефонии (MTAS). При использовании XDMS сохраняет данные услуг в HSS (как прозрачные данные), которые затем извлекаются AS при активации услуг.
ETSI TSIPAN принял Протокол Доступа к XML Конфигурации (XCAP), как определено в IETF RFC4825, для использования по Ut интерфейсу, и который облегчает использование методов http, т.е. GET, PUT и DELETE, для работы с XML данными, сохраненными в HSS, через XDMS. ETSI 183 023 представляет улучшенный протокол XCAP для управления данными, относящимися конкретно к услугам моделирования PSTN/ISDN, которые будут предоставляться в Сетях Следующего Поколения (NGN). Такие услуги включают в себя, например, голосовую почту, пересылку вызова, запрет вызова и т.д., причем каждая услуга определяется в стандарте посредством XML «схемы», которая представляет XML шаблон для встраивания в XML документы абонента.
В этом отношении фиг. 2 схематично показывает сеть управления IMS. XML документы, определяющие услуги пользователя и настройки, управляются посредством XDMS 1. Так называемый «Sh» интерфейс позволяет XDMS связываться с Домашним Сервером Абонента. (HSS) 2. Система 3 снабжения позволяет сетевому оператору изначально устанавливать предварительно сконфигурированные XML данные на основе стандартизованной XML схемы, на основе «по каждому абоненту» в HSS, и затем изменять установленные XML данные через XDMS. Сеть управления дополнительно обеспечивает механизм, посредством которого абонент может редактировать связанный с ним XML документ. Для этой цели Ut клиент 4 инсталлируется в абонентском оборудовании или UE. Как обсуждалось выше, Ut клиент использует XCAP протокол для извлечения (всего документа или его фрагмента) и изменяет XML документ (или фрагмент). Будет очевидно, что XDMS реагирует на соответствующий запрос от UE посредством получения соответствующих XML данных от HSS и доставки их на UE по Ut интерфейсу.
Прокси-сервер агрегирования (AP) 5 предназначен для «перехвата» XCAP трафика, следующего между Ut клиентом 4 и XDMS. Роль AP заключается, прежде всего, в аутентификации запросов, создаваемых абонентом, и, в частности, для определения, имеет ли конкретный пользователь право доступа к XDMS. Во-вторых, AP предоставляет общую точку соединения для Ut клиента, распределяя XCAP запросы на соответствующие XDMS.
Ut клиент выбирает сохраненные данные из XDMS посредством отправки запроса XCAP GET на XDMS через Ut интерфейс (предполагая авторизацию посредством AP и перенаправление посредством точки агрегирования). XDMS выбирает данные из HSS через Sh интерфейс и отправляет их обратно на Ut клиент в Ut ответном сообщении. Ut клиент отображает информацию и опции для пользователя посредством Графического Пользовательского Интерфейса (GUI). Обычно GUI предварительно конфигурируется для представления определенной информации, зависящей от принятых данных. Хотя XDMS имеет возможность разрешить и отклонить запросы с помощью абонента для изменения XML данных, как в текущее время определено, соответствующий стандарт не имеет никакого механизма для ограничения возможных условий, которые могут быть доступны абоненту. Другими словами, абонент может загружать свой XML документ, относящийся к набору услуг, причем GUI визуализирует его пользователю, включая отображение всех настроек услуг, независимо от того, будет ли XDMS действительно принимать запрос для изменения этих настроек. Такой подход неизбежно приводит к недовольству и запутыванию пользователей.
Для разрешения проблемы, определенной выше, предлагается ввести в структуру XML документа (т.е. стандартизованную схему) информационный элемент или элементы, которые определяют (идентифицируют) условия, которые абоненту разрешается изменять. Эти элементы интерпретируются посредством GUI в терминале абонента, и только эти условия, которые являются изменяемыми, отображаются.
В соответствии с первым аспектом настоящего изобретения обеспечивается способ управления представлением изменяемых пользователем условий услуг Подсистемы IP Мультимедиа в пользовательском терминале, где условия услуг определены в XML документе, поддерживаемом в сети Подсистемы IP Мультимедиа. Способ содержит включение в XML документ одного или более информационных элементов, идентифицирующих те условия, которые пользователь может изменять, и, при приеме XML документа или его фрагмента в пользовательском терминале, интерпретирование упомянутого(ых) информационного(ых) элемента(ов) и представление абоненту только тех условий, которые могут изменяться.
Варианты осуществления настоящего изобретения обеспечивают механизм для препятствования отображению пользователю тех условий, которые не изменяются, или по меньшей мере для препятствования их отображению в качестве изменяемых условий. Таким образом, абонент не будет пытаться изменять неизменяемые условия, что позволит избежать разочарования абонента.
В соответствии со вторым аспектом настоящего изобретения обеспечивается устройство, конфигурированное для работы в сети Подсистемы IP Мультимедиа, в качестве сервера XDMS. Устройство конфигурировано для управления XML документом, сохраненным в Домашнем Сервере Абонента сети Подсистемы IP Мультимедиа, и определения условий услуг для ассоциированного пользователя, причем устройство также конфигурировано для приема или отклонения создаваемых пользователем запросов на изменение XML документа на основе информационных элементов, содержащихся в документе.
В соответствии с третьим аспектом настоящего изобретения обеспечивается пользовательский терминал для использования с сетью Подсистемы IP Мультимедиа и содержащий Ut клиент для взаимодействия с XDMS сервером сети Подсистемы IP Мультимедиа. Терминал содержит Графический Пользовательский Интерфейс, конфигурированный для представления пользователю изменяемых условий услуг Подсистемы IP Мультимедиа на основе информационного элемента или элементов, содержащихся в XML документе или фрагменте документа, доставленного на терминал через Ut интерфейс, при этом элемент(ы) определяет(ют) разрешенные и/или неразрешенные условия.
Краткое описание чертежей
Фиг. 1 показывает схематично интеграцию Подсистемы IP Мультимедиа в систему мобильной связи 3G;
Фиг. 2 показывает схематично архитектуру сети управления IMS в соответствии с предшествующим уровнем техники;
Фиг. 3 показывает схематично структуру XML документа, поддерживаемого XDMS архитектурой сети управления по фиг. 2;
Фиг. 4 показывает схематично UE;
Фиг. 6 показывает часть XML документа, содержащего дополнительные информационные элементы; и
Фиг. 7 показывает часть XML документа, содержащего дополнительные информационные элементы в соответствии с оптимизированным форматом.
Со ссылкой на предшествующий уровень техники архитектуры сети управления IMS, показанной на фиг. 2, как уже было описано выше, XDMS (Сервер Приложений SIP) предоставляется для поддержания XML документов, определяющих предоставление услуг для соответствующих абонентов. XML документы сохранены в Домашнем Сервере Абонента (HSS) и извлекается соответствующими SIP Серверами Приложений (AS) при вызове услуги для разрешения AS предоставить услуги абонентам в соответствии с пользовательскими подписками и сетевой политикой.
Например, XML документ создается для каждого сетевого абонента, определяя услуги моделирования PSTN/ISDN, предоставленные для этого абонента. Каждая доступная услуга моделирования определяется в XML документе в соответствии с XML «схемой» (схемы определяются в соответствующем стандарте). Дополнительно, XML документ может содержать секцию «общие части» (снова в соответствии со стандартизированными общими частями), которая импортируется в каждую из схем конкретных услуг. Структура XML документа иллюстрируется на фиг. 3. XCAP протокол используется Ut клиентом (в UE) для доступа к и изменения разных секций, представленных в его XML документе(ах).
Здесь предложено расширить стандартизованную схему услуги дополнительными информационными элементами, которые указывают, какие условия абонент может изменять. GUI, предоставленный в абонентских терминалах (UE), имеет возможность интерпретировать информационный(е) элемент(ы), содержащийся(еся) в извлеченном XML документе или фрагменте документа, и отображать для пользователя только те условия, которые могут изменяться. Если этот параметр расширения не включен, тогда Ut клиент будет представлять все доступные опции для данной услуги, гарантируя, что Ut клиенты, поддерживающие расширения, совместимые с XDMS, не сделают это. Расширение будут добавляться, так что унаследованные клиенты Ut, не поддерживающие это расширение, не отклоняют ответ, создаваемый в XDMS, который поддерживает расширения. Отметим, что, если Ut клиент не поддерживает расширение и пытается изменить условие услуги, что не разрешается подпиской, XDMS будет отклонять этот запрос в соответствии с обычной практикой. Общая архитектура для UE показана на фиг. 4 и содержит Ut клиент 10, GUI 11 и дисплей 12.
Фиг. 5 является блок-схемой, показывающей основные этапы, связанные с представлением изменяемых условий для пользователя, а именно:
Этап 100) Отправление запроса GET из Ut клиента на XDMS через Ut интерфейс;
Этап 200) Прием запроса GET в XDMS и получение XML документа от HSS в Sh интерфейсе;
Этап 300) Доставка XML документа на Ut клиент через Ut интерфейс; и
Этап 400) В Ut клиенте, идентификация изменяемых условий, используя информационный(е) элемент(ы), и отображение условий.
Фиг. 6 показывает секцию XML документа, связанного с конкретным абонентом, которая определяет условия для услуги перенаправления вызова (cdiv). В соответствии с обычной структурой документа документ определяет набор правил для услуги, включая «Правило 1» и т.д. Кроме того, документ содержит информационный элемент, перечисляющий эти условия и действия для услуги, которые разрешаются абоненту изменять. GUI в Ut клиенте способен понимать этот новый элемент и будет отображать пользовательский интерфейс соответствующим образом.
Фиг. 7 показывает оптимизированную структуру XML, в соответствии с которой информационный элемент перечисляет только неразрешенные условия и действия. В этом примере единственным условием, которое не разрешено пользователю изменять, являются условие «присутствия». Поэтому GUI в Ut клиенте будет представлять все другие действия и условия для абонента как изменяемые.
Специалисту в данной области техники будет понятно, что различные модификации могут быть сделаны для описанного выше варианта осуществления без отхода от объема настоящего изобретения.
1. Способ управления представлением изменяемых пользователем условий услуг Подсистемы IP Мультимедиа в пользовательском терминале, где условия услуг определяются в XML документе, поддерживаемом в сети Подсистемы IP Мультимедиа, причем способ содержит:
включение в XML документ одного или более информационных элементов, идентифицирующих те условия, которые пользователь может изменять; и
при приеме XML документа или его фрагмента в пользовательском терминале интерпретацию упомянутого(ых) информационного(ых) элемента(ов) и представление абоненту только тех условий, которые могут изменяться.
2. Способ по п.1, в котором упомянутый(е) информационный(е) элемент(ы) определяет(ют) условия, для которых изменения разрешены и/или не разрешены.
3. Способ по п.1 или 2, в котором упомянутый XML документ или его фрагмент доставляется на пользовательский терминал посредством сервера XDMS через Ut интерфейс сети Подсистемы IP Мультимедиа.
4. Способ по п.1 или 2, в котором упомянутый XML документ сохраняется как прозрачные данные в Домашнем Сервере Абонента сети Подсистемы IP Мультимедиа.
5. Способ по п.3, в котором упомянутый XML документ сохраняется как прозрачные данные в Домашнем Сервере Абонента сети Подсистемы IP Мультимедиа.
6. Устройство, сконфигурированное для работы в сети Подсистемы IP Мультимедиа в качестве XDMS сервера, причем устройство выполнено с возможностью использования для управления XML документом, сохраненным в Домашнем Сервере Абонента сети Подсистемы IP Мультимедиа, и определения условий услуг для ассоциированного пользователя, причем устройство дополнительно выполнено с возможностью приема или отклонения создаваемых пользователем запросов на изменение XML документа на основе информационных элементов, содержащихся в документе.
7. Устройство по п.6, содержащее Ut интерфейс для приема упомянутых запросов, создаваемых пользователем.
8. Устройство по п.6 или 7, содержащее Sh интерфейс для сохранения измененных XML данных как прозрачных данных в Домашнем Сервере Абонента.
9. Пользовательский терминал для использования с сетью Подсистемы IP Мультимедиа и содержащий Ut клиент для взаимодействия с XDMS сервером сети Подсистемы IP Мультимедиа, причем терминал содержит Графический Пользовательский Интерфейс, выполненный с возможностью представления пользователю изменяемых условий услуг Подсистемы IP Мультимедиа на основе информационного элемента или элементов, содержащихся в XML документе или фрагменте документа, доставленного на терминал через Ut интерфейс, при этом элемент(ы) определяет(ют) разрешенные и/или неразрешенные условия.