На каком уровне функционируют медиашлюзы преобразующие базовые потоки voip в телефонный формат tdm
Несмотря на постоянно растущую сложность телекоммуникационных устройств и систем, протоколов и приложений, работы в направлении создания универсальной сетевой инфраструктуры продолжаются, проходя последовательно этапы узкополосных цифровых сетей интегрального обслуживания (сетей ISDN ), широкополосных сетей ISDN ( B-ISDN ), сетей следующего поколения ( ССП ). Наконец, создание концепции IMS – мультимедийной IP-ориентированной подсистемы связи, – по мнению разработчиков оборудования, операторов и организаций стандартизации, открывает путь к построению такой универсальной сетевой инфраструктуры.
Ключевые факторы перехода к IMS
Концепция IP Multimedia Subsystem (IMS) описывает новую сетевую архитектуру, основным элементом которой является пакетная транспортная сеть, поддерживающая все технологии доступа и обеспечивающая реализацию большого числа инфокоммуникационных услуг. Ее авторство принадлежит международному партнерству Third Generation Partnership Project (3GPP) , объединившему European Telecommunications Standartization Institute ( ETSI ) и несколько национальных организаций стандартизации.
IMS изначально разрабатывалась применительно к построению мобильных сетей 3-го поколения на базе протокола IP. В дальнейшем концепция была принята Комитетом ETSI-TISPAN , усилия которого были направлены на спецификацию протоколов и интерфейсов, необходимых для поддержки и реализации широкого спектра услуг в стационарных сетях с использованием стека протоколов IP.
В настоящее время архитектура IMS рассматривается многими операторами и сервис-провайдерами, а также поставщиками оборудования как возможное решение для построения сетей следующего поколения и как основа конвергенции мобильных и стационарных сетей на платформе IP.
Причину возникновения концепции IMS именно в среде разработчиков стандартов для мобильных сетей можно объяснить следующим образом.
Как известно, в последние годы операторы стационарных сетей активно поддерживают переход от традиционных телефонных сетей к ССП , связывая с ними определенные надежды на сокращение операционных расходов и капитальных вложений, а также на развитие новых услуг, ожидая, как следствие, существенного повышения доходов.
Естественно, идея построения ССП оказалась привлекательной и для мобильных операторов, которые в последние годы столкнулись с резким падением доходов, что связано, в том числе, и с дерегулированием рынка, ростом конкуренции, тарифными войнами, высоким оттоком абонентов и т. д.
Однако следует признать, что основная технологическая идея ССП – разделение транспортных процессов и процессов управления вызовами и сеансами на базе элементов платформы Softswitch – не была поддержана своевременной разработкой соответствующего набора стандартов. Это привело к тому, что основные сетевые элементы ССП , поставляемые различными производителями, зачастую оказываются несовместимыми между собой.
В сетях мобильных операторов, где одним из основных источников доходов является роуминг, такая несовместимость оказывается куда более значительным недостатком, чем в стационарных сетях. Именно это и определило активность международных организаций (в первую очередь ETSI и 3GPP ), которые начали разработку новых принципов построения и стандартов мобильных сетей 3G, основываясь на уровневой архитектуре ССП .
По существу концепция IMS возникла в результате эволюции сетей UMTS , когда область управления мультимедийными вызовами и сеансами на базе протокола SIP добавили к архитектуре сетей 3G. Среди основных свойств архитектуры IMS можно выделить следующие:
- многоуровневость – разделяет уровни транспорта, управления и приложений;
- независимость от среды доступа – позволяет операторам и сервис-провайдерам конвергировать фиксированные и мобильные сети;
- поддержка мультимедийного персонального обмена информацией в реальном времени (например голос, видео-телефония) и аналогичного обмена информацией между людьми и компьютерами (например игры);
- полная интеграция мультимедийных приложений реального и нереального времени (например потоковые приложения и чаты);
- возможность взаимодействия различных видов услуг;
- возможность поддержки нескольких служб в одном сеансе или организации нескольких одновременных синхронизированных сеансов.
Стандартизация IMS
Стандартизация архитектуры IMS является предметом внимания широкого круга международных организаций, благодаря ключевой роли IMS в эволюции сетей в направлении к ССП . Концепция IMS в ее настоящем виде является, главным образом, результатом работ трех международных организаций по стандартизации – 3GPP , 3GPP2 и ETSI .
Партнерство 3GPP было создано в конце 1998 г. по инициативе института ETSI с целью разработки технических спецификаций и стандартов для мобильных сетей связи 3-го поколения (сетей UMTS ), базирующихся на развивающихся сетях GSM.
Партнерство 3GPP2 появилось в 1998 г. также по инициативе ETSI и Международного союза электросвязи (МСЭ) для разработки стандартов сетей 3G (сети CDMA-2000) в рамках проекта IMT-2000, созданного под эгидой МСЭ. Оно было образовано практически теми же организациями, что и в случае 3GPP . Основным вкладом организации 3GPP2 в развитие стандартов для мобильных сетей 3G явилось распространение концепции IMS на сети CDMA2000 (IP-транспорт, SIP-сигнализация), описанное в спецификации под общим названием MultiMedia Domain ( MMD ).
Оба партнерства разрабатывают стандарты сетей 3G, ориентируясь на широкое применение IP-ориентированных протоколов, стандартизованных Комитетом IETF, и используя основные идеи архитектуры ССП .
Впервые концепция IMS была представлена в документе 3GPP Release 5 (март 2002 г.). В нем была сформулирована основная ее цель – поддержка мультимедийных услуг в мобильных сетях на базе протокола IP – и специфицированы механизмы взаимодействия мобильных сетей 3G на базе архитектуры IMS с беспроводными сетями 2G.
Архитектура сетей 3G в соответствии с концепцией IMS имеет несколько уровней (плоскостей) с разделением по уровням транспорта, управления вызовами и приложений. Подсистема IMS должна быть полностью независима от технологий доступа и обеспечивать взаимодействие со всеми существующими сетями – мобильными и стационарными, телефонными, компьютерными и т. д.
В документе 3GPP Release 6 (декабрь 2003 г.) ряд положений концепции IMS был уточнен, добавлены вопросы взаимодействия с беспроводными локальными сетями и защиты информации (использование ключей, абонентских сертификатов).
В релизах 6 и 7 определена идеология осуществления IP-коммуникаций посредством SIP. В соответствии с ней SIP начинается непосредственно с мобильного терминала.
Спецификация Release 7 добавляет две основные функции, которые являются ключевыми в стационарных сетях:
- Network Attachment, которая обеспечивает механизм аутентификации абонентов и необходима в стационарных сетях, поскольку в них отсутствуют SIM-карты идентификации пользователя;
- Resource Admission, резервирующая сетевые ресурсы в стационарных сетях для обеспечения сеансов связи.
Работы, направленные на расширение концепции IMS на стационарные сети, проводятся Комитетом TISPAN . Интерес к архитектуре IMS со стороны ETSI привел к созданию новой рабочей группы (2003 г.), объединившей известную группу TIPHON ( Telecommunications and Internet Protocol Harmonization Over Networks) и Технический комитет SPAN (Services and Protocols for Advanced Networks), который отвечает за стандартизацию стационарных сетей.
Новая группа, получившая название TISPAN ( Telecommunications and Internet converged Services and Protocols for Advanced Networking), отвечает за стандартизацию современных и перспективных конвергируемых сетей, включая VoIP и ССП , а также все, что связано с архитектурой IMS .
IMS – спецификация стандартной архитектуры по управлению мультимедийными услугами на основе IP-протокола для сетей следующего поколения (NGN), обеспечивающая конвергенцию услуг передачи речи и данных, предоставляемых различными поставщиками, через общую инфраструктуру IP-сети, а также через различные типы мобильных и фиксированных сетей доступа.
IMS – это концепция, касающаяся, в основном, услуг и приложений. Она дает возможность предоставлять единый унифицированный доступ к сервисам абонентам мобильных и фиксированных сетей через единую опорную сеть на базе протокола IP-MPLS.
Основная цель – конвергенция (объединение) услуг и работа по IP протоколу.
IMS (IP Multimedia Subsystem, мультимедийная IP-подсистема) – комплексное решение, которое в перспективе призвано заменить все существующие сети электросвязи. Ядро сети по технологии IMS основано на коммутации пакетов и обеспечивает транзит (обмен) трафика, независимо от его происхождения (голос, мультимедийные файлы, видео), т.е. работает с различными сетями доступа. На "входе" в сеть, независимо от "последней мили" (фиксированной или беспроводной), любой трафик преобразуется в IP, и затем платформа управляет потоками пакетов.
Отличие IMS ver 6 от NGN
- Предоставление сервисов организовано на контроле сессий
- Для взаимодействия используется только IP
- SOFTSWITCH – все построено на одной аппаратной платформе, на которой работают несколько софтовых приложений, определяющих различные функции архитетуры IMS
Архитектура IMS
Архитектура IMS определена в стандартах 3GPP (3rd Generation Partnership Project), Европейского института стандартов связи ETSI и Форума Parlay.
схема проектируемой сети включает в себя следующее оборудование:
1) ядро IMS (Core IMS), состоящее из оборудования, реализующего функции:
а) управления сеансом (CSCF);
б) управления медиашлюзом (MGCF);
в) управления ресурсами мультимедиа (MRFC);
г) управления выбором сети (BGCF);
д) управления пограничным взаимодействием (IBCF);
е) управления шлюзом доступа (AGCF);
2) окружение IMS, состоящее из оборудования, реализующего функции:
а) процессора ресурсов мультимедиа (MRFP);
б) медиашлюза (MGF);
в) шлюза сигнализации (SGF);
г) пограничного шлюза (BGF);
д) подсистемы управления доступом и ресурсами (RACS);
е) сервера профиля пользователя (UPSF/HSS);
ж) определения местонахождения подписки (SLF);
з) учета данных для начисления платы (CCF);
и) взаимодействия (IWF);
к) подсистемы присоединения сети (NASS);
л) подсистемы эмуляции телефонной сети (PES);
м) подсистемы симуляции телефонной сети (PSS).
Уровень доступа
На этом уровне инициируется и терминируется сигнализация SIP, необходимая для установления сеансов и предоставления базовых услуг, таких как преобразование речи из аналоговой или цифровой формы в IP-пакеты с использованием протокола RTP (Realtime Transport Protocol). На этом уровне функционируют медиашлюзы, преобразующие базовые потоки VoIP в телефонный формат TDM.
Медиасервер предоставляет различные медиасервисы, в том числе конференц-связь, воспроизведение оповещений, сбор тоновых сигналов, распознавание речи, синтез речи и т.п.
На этом уровне функционируют медиашлюзы, преобразующие базовые потоки VoIP в телефонный формат TDM. Основным элементами является оборудование Уровня доступа СПД, через которое осуществляется подключение абонентов в ядру IMS (IAD, MSAN, DSLAM, OLT и др)
Уровень контроля сессиями
Один из двух основных логических блоков IMS — “сердце” всей системы — это блок управления сеансами связи (Call Session Control Function — CSCF), или, попросту говоря, SIP-серверы. Их основная задача реализация функциии управления сеансом (CSCF), -- устанавливает, отслеживает, поддерживает и разъединяет мультимедийные сессии и обслуживает пользовательские взаимодействия, связанные с услугами. Оборудование CSCF выполняет три типа функций: прокси CSCF (P-CSCF), обслуживающая CSCF (S-CSCF) и запрашивающая CSCF (I CSCF). Прокси CSCF (P-CSCF) Proxy (обеспечивает доступ к сервисам из других сетей), обслуживающая CSCF (S-CSCF) Serving (осуществляет регстрацию и аутентификацию) запрашивающая CSCF (I CSCF) Interrogation (поределяет местонахождение абонента и роутинг).
MRFC (Media Resource Function Controller) На данном уровне реализуются функции контроллера ресурсов мультимедиа (MRFC), в соединении с оборудованием, реализующим функции процессора ресурсов мультимедиа (MRFP), располагающимся на транспортном уровне, обеспечивают набор ресурсов в основной сети для поддержки услуг. MRFC интерпретирует информацию, приходящую от сервера приложений (AS) через S-CSCF и соответствующим образом управляет MRFP. MRFC, в соединении с MRFP, обеспечивают мосты для многосторонних конференций, выдачу уведомлений абоненту, транскодирование информации.
Уровень приложений IMS
элементы уровня приложений и услуг в архитектуре коммутационной платформы IMS
1. Уровень приложений и услуг относится к верхнему уровню сетевой архитектуры IMS и предназначен для предоставления, обеспечения доступа и получения услуг как традиционной VoIP телефонии, так и мультимедийных услуг на базе IP и услуг интеллектуальных сетей.
2. Общая архитектура IMS соответствовует стандартам ETSI, 3GPP, TISPAN (не ниже 8 релиза) и включать на уровне услуг следующие функциональные компоненты:
a. Базу данных профилей абонентов:
блок определения местоположения абонента (Subscriber Location Function, SLF) - в случае использования нескольких HSS позволяет нахождение HSS с данными конкретного пользователя.
Серверы приложений AS (Application Server):
• сервер приложений SIP(SIP AS), который обеспечивает реализацию услуг платформы IMS;
• сервер коммутации мультимедийных услуг IP (IP Multimedia Service Switching Function, IM -SSF), который обеспечивает выполнение приложений расширенной логики сетей мобильной связи (Customized Application for Mobile Network Enhanced Logic, CAMEL), разработанных для сетей стандарта GSM;
• сервер приложений телефонии (Telephony AS TAS), который выполняет роль SIP User-agent, обеспечивает базовые возможности по обработке вызовов, включая маршрутизацию, установление, ожидание и перенаправление вызовов, конференц-связь и другие традиционные услуги.
• сервер обеспечения открытого доступа к услугам (Open Servise Access-Service Capability Server, OSA - SCS), который выполняет роль интерфейса для серверов приложений, построенных на основе OSA;
Сервер SCIM (Serviсe Capability Integration Manager), который обеспечивают взаимодействие серверов приложений с серверами управления вызовами и сеансами (CSCF).
Ускорить внедрение операторами новых услуг, как на сетях с коммутацией каналов использующих традиционные решения телефонии, так и на сетях с коммутацией пакетов использующих программные коммутаторы, призваны решения Lucent Accelerate? VoIP. Эти решения включают системы передачи голоса и данных следующего поколения, программное обеспечение и профессиональные услуги, которые необходимы операторам как мобильных, так и проводных сетей связи.
В настоящей статье рассматривается сервисная архитектура подсистемы IP-мультимедиа (IP Multimedia Subsystem, IMS), которая составляет фундамент решений Lucent Accelerate?. Решения Lucent Accelerate? позволяют реализовать сервисную интеллектуальность на всех уровнях проводных и беспроводных сетей, обеспечивая комплексный подход к внедрению VoIP.
Архитектура IMS
Архитектура IMS, удовлетворяющая изложенным выше требованиям, определена в стандартах 3GPP (3rd Generation Partnership Project), Европейского института стандартов связи ETSI и Форума Parlay [1]. На рис. 1 представлен упрощенный вариант архитектуры IMS.
Общие сведения о IMS
Сервисная архитектура представляет собой набор логических функций, которые можно разделить на три уровня: уровень абонентских устройств и шлюзов, уровень управления сеансами и уровень приложений.
Уровень абонентских устройств и транспорта
На этом уровне инициируется и терминируется сигнализация SIP, необходимая для установления сеансов и предоставления базовых услуг, таких как преобразование речи из аналоговой или цифровой формы в IP-пакеты с использованием протокола RTP (Realtime Transport Protocol). На этом уровне функционируют медиашлюзы, преобразующие базовые потоки VoIP в телефонный формат TDM. Медиасервер предоставляет различные медиасервисы, в том числе конференц-связь, воспроизведение оповещений, сбор тоновых сигналов, распознавание речи, синтез речи и т.п. Ресурсы медиасервера доступны всем приложениям, т.е. любое приложение (голосовая почта, бесплатный номер 800, интерактивные VXML-сервисы и т.д.), которому необходимо воспроизвести оповещение или получить цифры набранного номера, может использовать общий сервер. Медиасерверы также поддерживают и нетелефонные функции, например, тиражирование голосовых потоков для оказания сервиса мгновенной многоточечной связи (PTT). При использовании для различных сервисов общего пула медиасерверов отпадает необходимость в планировании и инжиниринге медиаресурсов для каждого отдельного приложения.
Уровень управления вызовами и сеансами
На уровне управления вызовами и сеансами также располагается функция управления медиашлюзами MGCF (Media Gateway Control Function), которая обеспечивает взаимодействие сигнализации SIP с сигнализацией других медиашлюзов (например, H.248). Функция MGCF управляет распределением сеансов по множеству медиашлюзов, для медиасерверов это выполняется функцией MSFC (Media Server Function Control).
Уровень серверов приложений
Этот уровень содержит серверы приложений, которые обеспечивают обслуживание конечных пользователей. Архитектура IMS и сигнализация SIP обеспечивают достаточную гибкость для поддержки разнообразных телефонных и других серверов приложений. Так, разработаны стандарты SIP для сервисов телефонии [2] и сервисов IM [3].
Сервер приложений телефонии
TAS также обеспечивает сервисную логику для обращения к медиасерверам при необходимости воспроизведения оповещений и сигналов прохождения вызова. Если вызов инициирован или терминирован в ТфОП, сервер TAS обеспечивает сигнализацию SIP к функции MGCF для выдачи команды медиашлюзам на преобразование битов речевого потока TDM (ТфОП) в поток IP RTP и направление его на IP-адрес соответствующего IP-телефона.
Функция коммутации услуг IM-SSF
Дополнительные серверы телефонных приложений
Прикладной уровень может также содержать автономные независимые серверы, предоставляющие дополнительные услуги в любой стадии вызова посредством триггеров. К таким услугам относятся набор номера, переадресация и установление конференц-связи щелчком мыши, услуги голосовой почты, услуги интерактивного речевого взаимодействия (IVR), VoIP VPN, предоплаченный биллинг, блокирование входящих и исходящих вызовов.
Другие серверы приложений
На прикладном уровне также могут находиться серверы приложений SIP, не использующие модель телефонного вызова. Такие серверы взаимодействуют с клиентами абонентских устройств для предоставления сервисов IM, PTT, сервисов присутствия и т.п. Реализация сервисов на базе SIP (нетелефонных сервисов) в общей архитектуре IMS позволяет осуществлять взаимодействие двух видов сервисов и создавать новые смешанные услуги. В качестве примера можно привести вывод на дисплей списка абонентов с указанием статуса присутствия в сети, причем набор номера и доступ к другим услугам (телефония, IM, PTT) осуществляется щелчком мыши. Другой пример ? использование одного предоплаченного счета для оплаты услуг телефонии и видео по запросу.
Шлюз открытого сервисного доступа OSA-GW
Развитие архитектуры IMS
Большинство из описанных в предыдущих разделах сервисов являлись узкополосными сервисами передачи голоса и данных. Однако сигнализация SIP и архитектура IMS поддерживают и широкополосные мультимедийные сервисы, такие как вещательное ТВ с многоадресными (IP multicast) видеопотоками, видео по запросу, видеонаблюдение, видеотелефония, видеоконференцсвязь, виртуальные лекционные залы и многое другое. Для реализации таких сервисов в сети должны быть установлены дополнительные мультимедийные серверы приложений и абонентские устройства (см. рис. 2).
С расширением сферы применения мультимедийных услуг появится необходимость перейти от используемых сегодня базовых механизмов обеспечения качества обслуживания на более высокий уровень. Кроме мониторинга доступной полосы пропускания необходимо контролировать количество активных сеансов связи реального времени. В архитектуре IMS абонентские устройства и серверы приложений VoIP и широкополосных мультимедийных услуг посылают запросы на инициирование сеанса через общий элемент CSCF. Функция CSCF определяет уровни трафика, взаимодействуя с сетью транспорта и доступа, и может отказать в установлении дополнительных сеансов.
С точки зрения Lucent, необходимы расширения архитектуры IMS, которые обеспечили бы поддержку расширенного спектра услуг. Многие современные абонентские устройства VoIP, например, IP-УАТС, не поддерживают сигнализацию SIP, используя обычно протокол H.323. Интегрированные устройства доступа IAD с поддержкой VoIP поверх DSL часто используют протокол MGCP.
Соответственно, для поддержки этих распространенных абонентских устройств в сети IMS необходимо обеспечить взаимодействие поддерживаемых ими стандартов сигнализации и протокола SIP. С этой целью уже предложены новые граничные сигнальные шлюзы.
Планы Lucent по продуктам IMS
Обширный, полнофункциональный портфель продуктов Lucent Accelerate? основан на сервисной архитектуре и технологиях IMS. Как видно из рис. 3, составляющие его элементы используются на всех уровнях сервисной архитектуры IMS и во многих приложениях, о которых упоминалось выше. Сервисы, создаваемые партнерами Lucent, занимающимися разработкой приложений, встраиваются в открытую архитектуру IMS и могут использоваться сервис-провайдерами для ускоренного предоставления новых услуг.
Как показано на рис. 3, Lucent Softswitch (LSS) объединяет ряд функциональных элементов IMS: CSCF, TAS, MFRC, MGCF и IM-SSF. Кроме того LSS усиливает стандартную архитектуру IMS, выполняя функцию сигнального шлюза, которая обеспечивает прохождение сторонней сигнализации (H.323 или MGCP) в сервисную архитектуру IMS.
Дополнительную функциональность IMS обеспечивает портфель продуктов Lucent MiLIfe? Service Platform. Сервер медиаресурсов MiLife? Lucent Media Resource Server (LMRS) выступает в роли медиасервера. Абонентский регистр MiLIfe? Super Distributed Home Location Register (SDHLR) выполняет функции абонентской базы данных HSS, а шлюз MiLIfe? Intelligent Services Gateway (ISG) ? функции OSA-GW для взаимодействия с серверами приложений Parlay.
Медиашлюзы Lucent APX? и MaxTNT? , управляемые LSS, обеспечивают взаимодействие с ТфОП и поддержку телефонных соединений с УАТС.
В поисках путей снижения издержек и увеличения доходов сервис-провайдеры все чаще задумываются о переводе голосовых услуг на рельсы VoIP, где коммуникационные сервисы реального времени могли бы бесшовно взаимодействовать друг с другом. Определенная стандартами архитектура подсистема IP Multimedia обеспечивает надежную реализацию всех требований, определенных в данной статье для создания новых конвергентных сервисов с поддержкой качества обслуживания. Эта архитектура лежит в основе решений Lucent Accelerate? VoIP, что обеспечивает использование интеллектуальных сервисов на всех функциональных уровнях проводных и беспроводных сетей. Более того, Lucent создает расширения архитектуры IMS, которые обеспечат ее развитие и поддержку широкополосных мультимедийных сервисов с помощью новых граничных сигнальных шлюзов. Вместе со своими партнерами Lucent предлагает решения, которые позволяют сервис-провайдерам повышать эффективность и ускоренными темпами выводить на рынок новые услуги.
Многообразие сетевых протоколов и методов доставки контента заставляет операторов искать надежные и эффективные механизмы для организации новых услуг. Производители обычно предлагают их как «универсальную, интегрированную, комплексную платформу» (сервисную платформу), но на поверку они не всегда соответствуют чаяниям клиентов.
Сейчас эволюционную цепочку концептуальных разработок для организации сетевых сервисов замыкает модная архитектура IMS (IP Multimedia Subsystem).
Вначале была IN
В 1993 году Международный союз электросвязи (ITU-T) утвердил первые спецификации технологии Intelligent Network (IN). Основным принципом построения интеллектуальной сети стало логическое разделение уровня коммутации и предоставления услуг, благодаря чему появилась возможность создавать новые телекоммуникационные сервисы в соответствии со специфическими для каждого из них требованиями к сети и абонентским устройствам.
Концепция IN позволила телефонным операторам значительно расширить спектр услуг, но имела ряд недостатков. Основной из них заключается в том, что номенклатура услуг оказалась полностью зависимой от возможностей INAP (Intelligent Network Application Protocol) — прикладного протокола, посредством которого реализуются функции интеллектуальных платформ. В случае доработки INAP при добавлении новой услуги оператору требовалась модернизация всех сетевых узлов коммутации и управления услугами — SSP (Service Switching Point) и SCP (Service Control Point). В сетях, где таких узлов насчитывалось несколько сотен, процедура модернизации была сопряжена с большими сложностями и затратами.
Кроме того, программно-аппаратная платформа IN «по определению» находится в ведении базового оператора связи, и ее ресурсы не всегда могут выделяться третьей стороне — поставщикам услуг с добавленной стоимостью или разработчикам последних. К очевидным недостаткам IN также относятся низкая совместимость платформенных решений и узлов SSP разных производителей и значительная стоимость проектов.
Пропуск в мир VoIP
В 1995 году компания Dialogic впервые представила специализированную сигнальную плату для ПК, которая изначально позиционировалась как персональный шлюз IP-телефонии. Позже, когда была разработана основа прикладного программного интерфейса к таким платам, у провайдеров появилась возможность организовывать на базе средств компьютерно-телефонной интеграции (CTI) новые гибкие услуги, практически не зависящие от технологий транспортного уровня самой операторской сети.
Появившееся вскоре оборудование операторского класса на основе продуктов Dialogic имело низкую стоимость (поскольку базировалось на промышленных серверах), но ему бы присущ ряд существенных недостатков. Во-первых, телефонный оператор не мог участвовать в разделе доходов от предоставления услуг с добавленной стоимостью. Иными словами, он получал выручку исключительно за пропущенный трафик, а фактическая стоимость услуги при этом не учитывалась. Во-вторых, решения CTI характеризуются низким уровнем защищенности и генерацией нехарактерно высоких нагрузок на отдельных участках ТфОП.
Разделяй и властвуй
В 1998 году появились концепция открытого сервисного доступа (Open Service Access, OSA) и технология Parlay, созданная одноименной рабочей группой, которая включает в себя представителей крупнейших поставщиков телекоммуникационных решений (Parlay Group). Эта технология позволила разрабатывать и внедрять услуги в распределенной ИКТ-среде, в которой одна часть функционала механизмов предоставления услуг обеспечивалась сетью телефонного оператора, а другая передавалась внешним сервис-провайдерам. Взаимодействие обеих частей архитектуры реализовывалось через специальные программные шлюзы. С инфраструктурой доступа они взаимодействовали по сетевым протоколам (CAP, MAP, H.323 и т.д.), а с серверами приложений — при помощи открытых прикладных программных интерфейсов API, совместимых с требованиями OSA и Parlay.
Предназначенные для максимально гибкого использования специфических сетевых сервисов шлюзы Parlay гарантировали прозрачный безопасный сетевой доступ. Они позволяли создавать сервисы как внутри сетевого домена оператора связи, так и во внешних сетевых доменах. Таким образом, провайдеры приложений и независимые разработчики ПО могли разрабатывать, тестировать и внедрять специализированные сервисы за пределами инфраструктуры оператора.
Концепция OSA/Parlay обеспечила трансформацию отношений между операторами и независимыми поставщиками услуг из конкурентных в партнерские. Владельцы сетей смогли участвовать в распределении доходов от дополнительных сервисов (VAS). Наличие шлюза между сетевыми ресурсами оператора и сервером приложений контент-провайдера обусловило возможность перехода на принципиально новую бизнес-модель предоставления услуг, в которой нашлось место и оператору, и поставщику услуг, и их агрегатору. Вдобавок технология Parlay гарантировала высокий уровень совместимости решений и переносимости услуг разных разработчиков. Основные недостатки Parlay в первой реализации состояли в ориентации на сети фиксированной связи и в сложности организации роуминга услуг.
В преддверии IMS
Через год после появления технологии Parlay Европейский институт исследований проблем в области телекоммуникаций (Eurescom) приступил к реализации проекта P909 «Анализ развития концепции IN и интеграция услуг IN с приложениями Internet». Был поставлен вопрос: можно ли так доработать технологию IN, чтобы на ее базе предоставлять телефонные услуги, интегрированные с приложениями Internet? Ответом на него стал разработанный в рамках проекта P909 новый вид оборудования, получивший название SCP-IP.
По сути, в обычный узел SCP был добавлен ряд стандартизованных функций, позволяющих организовать управление интеллектуальными услугами через Internet, взаимодействие с Web-серверами и системами электронной почты. Но, невзирая на успешное завершение проекта, многие сочли, что сама идеология IN не отвечает современным требованиям операторов, а по уровню гибкости и эффективности эта технология не может конкурировать с Parlay, Java, VoiceXML и прочими открытыми платформами.
Тогда тот же Eurescom, но уже в партнерстве с 3GPP (Third Generation Partnership Project), в сентябре 2001 года инициировал новый проект — P1110 «Архитектура OSA — выгоды и возможности для сетей 3G». Была предпринята попытка проанализировать Parlay на соответствие современным и перспективным требованиям телефонных операторов. Кроме того, по инициативе 3GPP набор функций Parlay был расширен за счет механизмов для организации услуг в мобильных сетях связи. В частности, именно тогда в Parlay появились блоки, отвечающие за отправку SMS и MMS, а также за определение параметров пользовательских терминалов и их доступности в сети.
Однако тут же проявился еще один недостаток Parlay: с помощью данной технологии практически невозможно организовать роуминг услуг в сотовых сетях. Кроме того, шлюзы Parlay создавались, прежде всего, для упрощения доступа сторонних провайдеров к сетевой инфраструктуре операторов, но уровень этого упрощения оказался намного ниже требуемого. Дальнейшее развитие и совершенствование IN-платформ до так называемых Advanced IN с поддержкой протоколов фиксированных и мобильных сетей, IP-сетей RADIUS и Diameter, SIP и H.323 (для обработки вызовов VoIP) свели к минимуму преимущества Parlay с точки зрения конвергенции разнородных сетей связи. В результате, по словам ведущего консультанта по техническим решениям Siemens Communications Владимира Шапорова, сейчас в мире действуют лишь единицы решений на основе Parlay. Возможно, именно по этой причине в 2002 году партнерство 3GPP предложило новую архитектуру для организации услуг — IMS (IP Multimedia Subsystem).
Знакомые слова
Цели разработки IMS были довольно традиционными. Во главу угла ставилась задача обеспечить операторов эффективными средствами для предоставления разных услуг связи на общей платформе. В качестве единого сигнального протокола для управления соединениями предполагалось использовать SIP (Session Initiation Protocol). Но ведь и прежние консорциумы разработчиков заявляли о намерении предоставить операторам эффективные механизмы реализации услуг, базирующиеся на стандартных протоколах. А на деле различные сервисы (передачи голоса, SMS, Internet-ориентированные приложения и т. д.) предоставляются посредством отдельных подсистем с применением всевозможных сетевых протоколов и способов транспортировки данных.
Еще одна задача IP Multimedia Subsystem обозначена в самом названии технологии: предоставить операторам средства для организации мультимедийных услуг, интегрированных с Internet-приложениями. Требование мультимедийности обозначает конвергенцию таких видов трафика, как голос и видео, а также данных разного типа в сетях фиксированной и мобильной телефонии, WLAN и других проводных и беспроводных средах. Эта задача также заслуживает комментария: попробуйте найти здесь пресловутые десять отличий от концепции сетей следующего поколения (NGN).
Наконец, IMS должна была обеспечить доступ к услугам при помощи максимально большого числа типов терминалов, а также общую платформу управления и контроля над качеством сервиса в мобильных и фиксированных сетях. Использование единой «базовой платформы» призвано снизить затраты на эксплуатацию сети и обеспечить интеграцию таких возможностей, как Presence, Instant Messaging, Push-To-Talk. Можно сказать, что IMS должна рассматриваться как базовая платформа для создания и доставки услуг нового поколения на базе протокола SIP.
Архитектурные особенности
Структура IMS представляет собой набор логических функций, которые можно разделить на три уровня: абонентских устройств и шлюзов, управления сеансами и приложений. Так, в частности, считает Андрей Боровков, старший системный инженер отдела технологий и развития бизнеса Lucent Technologies в России и СНГ.
На первом уровне инициируется и терминируется сигнализация SIP, необходимая для установления сеансов и предоставления базовых услуг, таких как передача речи поверх IP. На этом уровне функционируют медиашлюзы, преобразующие потоки VoIP в традиционный формат TDM и наоборот.
Централизованное хранение этих сведений позволяет приложениям использовать их для поддержки персональных справочников, получения информации о присутствии в сети абонентов различных категорий, а также оказания совмещенных услуг. Кроме того, централизация существенно упрощает администрирование пользовательских данных. В некотором роде HSS выполняет функции HLR, но поддерживает роуминг услуг и оперирует данными о свойствах терминалов разного типа — стационарных и мобильных телефонов, SIP-устройств и КПК. На уровне управления вызовами и сеансами архитектура IMS также предусматривает наличие средств MGCF (Media Gateway Control Function), которые управляют распределением сеансов по множеству медиашлюзов.
На третьем уровне архитектуры IMS расположены серверы приложений, обеспечивающие обслуживание конечных пользователей.
Помимо проведения фактической стандартизации IMS консорциум 3GPP определил термин IM CN (IP Multimedia Core Network) как среду, к которой непосредственно подключаются серверы, отвечающие за выполнение логики услуг. Для соединения IM CN с этими серверами могут использоваться разные протоколы, в том числе CAMEL, INAP, VoiceXML и OSA/Parlay.
Нестандартные взгляды
Хотя архитектура, функционал и большинство характеристик IMS стандартизованы 3GPP, ее практические реализации, а также взгляды производителей на некоторые вопросы эксплуатации систем довольно сильно различаются. Ряд специалистов, в том числе менеджер по маркетингу MERA Systems Наталья Селифанова, считают, что концепция IMS является логическим продолжением IN. Владимир Шапоров из Siemens согласен с тем, что на концептуальном уровне IMS можно сравнивать с IN, поскольку в обоих случаях подразумевается разделение логики услуг и сетевой сигнализации. Вот только в интеллектуальных сетях сигнализация осуществляется на базе протокола ОКС-7 (SS7), а в IMS эти функции переложены на SIP. А сотрудник подразделения «Мультисервисные сети и широкополосный доступ» компании Ericsson в Восточной Европе и Центральной Азии Игорь Быков, напротив, полагает, что IMS не является развитием платформ IN, CTI и OSA/Parlay, а представляет собой самостоятельную концепцию.
Различаются позиции и в определении роли Parlay в архитектуре IMS. Некоторые эксперты считают, что Parlay продолжит играть ключевую роль в развитии IMS. По мнению Игоря Быкова, различные технологии (в том числе Parlay, JAIN и VoiceXML) не заменяют, а, скорее, дополняют друг друга при разработке услуг и реализации иных операторских задач. В Siemens же полагают, что Parlay уже «доказала» свою нежизнеспособность. Кстати, три года назад немецкая корпорация активно продвигала решение Parlay@vantage, но в дальнейшем отказалась от его развития. Как и прежде, выбор большинства операторов все еще приходится на оригинальные, адаптированные под конкретные нужды протоколы организации услуг, такие как SMPP, MM7, WAP, PAM, MLP и Ro/DIAMETER, а целесообразность использования промежуточного уровня в виде функций Parlay многие из них ставят под сомнение.
Барьеры для IMS
Так или иначе, концепция IMS была принята основными игроками рынка телекоммуникационного оборудования, после чего Форум UMTS официально предложил заменить в архитектуре сетей следующего поколения регистр HLR на базу данных абонентов HSS. Европейский институт ETSI также заявил, что центром сети оператора должна быть платформа IMS, а транспортное ядро, инфраструктура доступа и даже терминальное оборудование нужно строить с учетом возможностей платформы IMS. Пока это — неофициальная позиция ETSI, но представители института неоднократно озвучивали ее на конференциях.
Активному внедрению IMS, тем не менее, препятствует малое количество терминалов с поддержкой SIP (прежде всего, мобильных). «Интегрировать поддержку данного протокола в смартфоны пользователи могут и самостоятельно, — отмечает Шапоров, — но реализация SIP в обычных сотовых телефонах осуществима лишь в заводских условиях». Многие современные IP-УАТС до сих пор не поддерживают сигнализацию SIP, используя протокол H.323, а интегрированные устройства доступа с поддержкой VoIP поверх DSL обычно базируются на протоколе MGCP. Соответственно, для поддержки этих довольно распространенных устройств в сетях IMS необходима конвертация поддерживаемых ими сигнальных команд и протокола SIP. С данной целью некоторые производители выпустили оборудование нового типа — граничные сигнальные шлюзы.
Не выработаны единые стандарты на IMS-приложения. По этой причине операторы также не торопятся с покупкой готовых промышленных IMS-платформ, хотя большинство телекоммуникационных вендоров, таких как Lucent, Nokia, Motorola, Siemens и Ericsson, приступили к их активному рыночному продвижению. Ряд отечественных поставщиков, например MERA Systems, также предлагают собственные версии платформ, выполненных по стандартам IMS. Хотя комплексные инсталляции IMS-платформ во всем мире пока можно пересчитать по пальцам, дело, кажется, сдвинулось с мертвой точки, и отдельные услуги на основе элементов IMS внедряют десятки зарубежных операторов. Многие эксперты полагают, что 2006 год пройдет в мире телекоммуникаций под знаком IP Multimedia Subsystem.
От концепции — к решениям
Для наглядности реализацию концепции IMS стоит более подробно рассмотреть на примере нескольких решений разных производителей, которые считают себя приверженцами новой архитектуры сервисных платформ. Отрадно, что в их числе присутствует и российская фирма MERA Systems.
Lucent
Продукты семейства Lucent Accelerate основаны на сервисной архитектуре и технологиях IMS. Так, решение Lucent Softswitch (LSS) объединяет ряд функциональных элементов IMS: CSCF (Call Session Control Function), MGCF (Media Gateway Control Function), TAS (Telephony Application Server), MFRC и IM-SSF (IP Multimedia — Services Switching Function). Кроме того, LSS расширяет стандартную архитектуру IMS, выполняя задачи сигнального шлюза, который поддерживает обработку сторонней сигнализации (H.323 или MGCP) в сервисной платформе Lucent.
Дополнительную функциональность IMS обеспечивает линейка Lucent MiLIfe Service Platform. В нее входят сервер медиаресурсов MiLife Lucent Media Resource Server (LMRS), абонентский регистр MiLIfe Super Distributed Home Location Register (SDHLR), который, по сути, является эквивалентом абонентской базы данных HSS, и шлюз MiLIfe Intelligent Services Gateway (ISG). Последний отвечает за взаимодействие с серверами приложений по протоколу Parlay. Медиашлюзы Lucent APX и MaxTNT, управляемые LSS, поддерживают взаимодействие IP-сети с ТфОП и телефонные соединения с УАТС.
В рамках проекта модернизации сети «Скай Линк» санкт-петербургского оператора «Дельта Телеком» планируется установить первый в России распределенный регистр местоположения абонентов S-DHLR — элемент архитектуры IMS из семейства решений Lucent Accelerate.
Siemens
«Сердцем» продуктовой линейки Siemens IMS@vantage является Multimedia Session Controller @vantage CFX-5000. Он обеспечивает контроль над мультимедийными сессиями для голосовых и видеосервисов, а также над услугами на базе технологии push-to-talk, многопользовательскими играми и конференциями. Кроме того, CFX-5000 реализует функции контроля над качеством услуг.
Второй по значимости элемент платформы — Multimedia Gateway Controller @vantageCFX-5200 — обеспечивает сопряжение сетей с разными типами сигнализации (SIP, H.323, SS7 и др.). Функционал абонентской базы HSS в решении Siemens IMS@vantage поддерживает сервер Core Mobility Server @vantage CMS-8200. А продукт @vantage CMG-3000 играет роль классического медиашлюза (Media Gateway) между IP- и TDM-средами. Он конвертирует голосовые потоки в формат VoIP и обратно. Функции медиасервера реализует решение @vantageCCS-1000.
Siemens является стратегическим партнером нидерландского оператора KPN, строящего полнофункциональную гибридную сеть на базе архитектуры IMS в рамках проекта Fixed Mobile Convergence.
MERA Systems
MERA объявила о появлении нового поколения решений MVTS. Основная цель этих разработок — создать единую платформу, объединяющую интеллектуальное управление трафиком, биллинг и сервисные приложения в IP-сетях. Предлагаемое решение обеспечит плавный переход операторов к концепции IMS, а его архитектура включает в себя два уровня — коммутации и приложений. По мнению инженеров MERA, ключевым звеном управления вызовами в архитектуре IMS является программный коммутатор (Softswitch) с расширенным возможностями, среди которых — поддержка сигнализации SIP, H.323 и SS7, встроенная система биллинга, интеллектуальная маршрутизация вызовов.
На уровне серверов приложений MERA разработала компонент MERA SIPrise, который служит для внедрения как традиционных, так и современных услуг связи. Сегодня этот продукт используется автономно как платформа карточной телефонии, а также для подключения к VoIP сетей широкополосного доступа и предоставления VoIP-услуг корпоративным клиентам. В ближайших планах — реализация функционала «виртуальной» IP-АТС (IP Centrex) и возможностей единого персонального номера. Платформа MERA SIPrise применяется некоторыми операторами для предоставления услуг нового поколения (например, в одной из региональных сетей Golden Telecom), а программный коммутатор MVTS — для эффективного сопряжения SIP-сетей (скажем, в сетях «Зебра Телекома», LANK Telecom, «РТКомма» и «Экванта»).
IBM Information Management System — система управления иерархическими базами данных с транзакционными возможностями [1] .
Компания IBM работает над этой СУБД с 1968 года.
IMS создана при участии IBM в сотрудничестве с Rockwell и Caterpillar для космической программы Аполлон в 1966 году. В задачу IMS входила обработка спецификации изделия для ракеты Сатурн-5 и кораблей Аполлон.
14 августа 1968 считается датой выпуска системы. Система создавалась как технология для платформы IBM System/360 и позднее перенесена на более современные операционные системы от IBM, в том числе на z/OS.
С конца 1990-х система поддерживает доступ на языке программирования Java, интерфейсы JDBC, обработку XML, в 2000-х годах включена поддержка веб-служб.
Построенное на IBM System z программное обеспечение дает возможность управления и распределения данных. Оно состоит из двух частей: менеджера баз данных и менеджера транзакций. Оба обеспечивают высокую скорость обработки, производительность и надежность.
Возможности IMS [2]
- Быстрый доступ к критическим данным с помощью мощных функций управления данными и распределения данных.
- Сокращение сроков разработки и уменьшение затрат на разработку приложений благодаря упрощенным интерфейсам и инструментам.
- Интеграция с другими продуктами от IBM для улучшения производительности и управления данными.
Быстрый доступ к критически важным данным
- Включает поддержку 64-битного менеджера буфера Fast Path для устранения "узких мест" и улучшения скорости обработки транзакций.
- Предоставляет поддержку расширенного адресного объема (EAV) для уменьшения ограничений на дисковое хранилище, обеспечивая большую масштабируемость.
- Предлагает полнофункциональные буферные пулы баз данных для уменьшения времени простоя системы и улучшения доступности.
- Обеспечивает расширенные команды запросов и обновлений для улучшения доступности данных.
- Предоставляет связь с Multiple Systems Coupling (MSC) TCP/IP для повышения пропускной способности и улучшения производительности.
Сокращение сроков разработки и уменьшение затрат на разработку приложений
Какая модель данных используется в субд ibm ims information management system
Обращаюсь по следующему вопросу: дали задание написать реферат по IBM Information Management. Я в этой области вообще ни в зуб ногой (НЕ РУГАТЬСЯ!), стал гуглить, в итоге пришел к следующему:
1. IMS — Information Management System
2. IMS — Information Management Softwere
3. IMS — то-то типа с мультимедиа связано.
3 пункт отметаю, 2 — слишком много продуктов входит — отметаю, остается 1.
А вот тут загвоздка! Загадка ребус блин.
Как я понял, то IMS — это нечто вроде технологического решения, на основе которого существует DB2 и IMS v13.
По DB2 информации много, на русском и с картинками — то, что надо прямо, а вот по IMS V13 — дуля! Все на английском и то в виде обрубков. =((
А теперь сам вопрос — может кто-то знает некие источники, желательно на русском, само собой с картинками, ну или на худой конец нормальный обзор на английском, чтобы был со всеми деталями и со всеми раскрытыми возможностями IMS? Или я вообще не в ту степь понесся и достаточно просто написать о DB2 т.к. это и есть IMS.
В целом, я так и сделал пока — дал ссыль на хабру, где написали, что специалисты по IMS вымирающая категория, и написал про DB2, да и интереснее оказалось. Но вдруг я недотумкал до чего нибудь, или ошибся.
За книжку спасибо! Жалко, что не на русском, а то переводить информацию, которая уже устарела и не пригодится никому в будущем как-то не хочется. Цитаты надергаю. чтобы более уверенно вырулить на ДБ2 =))) А может и так прокатит =))
То есть, типичный цикл обслуживания клиента (это может быть вызов сервиса из Business Process Service или вызов из J2EE например) выглядит следующим образом
Вызов "транзакции" — журналирование факта вызова с помещением вызова в очередь — диспетчеризация, определение приоритетов и прочих условий, распределение на выполнение — передача приложению вызова по требованию приложения (начинается контекст Unit of Work), короче чего-то там делает, и отправляет ответ, который поступает в выходную очередь до извлечения клиентом, выполняется commit, которые делает кучу вещей, таких как удаление запроса на выполнение из входной очереди, подтверждение всех изменений в базы данных, помещение ответа в выходную очередь, и возврат нового поступившего на выполнение запроса приложению.
Описано далеко не всё, например, между базой данных и приложением есть такое понятие как PSB — Program Specification Block, который содержит несколько PCB — Program Control Block, который содержит логическое представление базы данных и входных/выходных очередей. Чем то напоминает объект View в реляционках. Если приложение пишет кодер, то PSB делает для него администратор, определяя в том числе и тип обработки данных, который может делать приложение, и какие данные он может поиметь для обработки, и "намерение" на использование данных. Так же администратор создаёт "транзакцию" — SLA, то есть объект, который определяет качество выполнение приложения.
Да, одно приложение может послать запрос во входную очередь другого приложения, чем прикольно и полезно пользоваться для экономии ресурсов и повышение производительности.
И вообще, технологических особенностей и вкусностей очень много. Что, собственно, и сделало платформу практически монополистом в финасовой индустрии, допустим. И широко используемой во многих других отраслях.
Уж рудиментом то она точно не является — например, все вновь возникающие крупные финансовые учреждения внедряют и системы на IMS, просто они нечасто создаются, новые то.
Но есть и много сравнительно мелких, но чрезвычайно успешных внедрений. Например, очень крупная металлургическая компания Saarah Steel, так что ли, название. Там всего-то 10 MSU, примерно 3 ЦПУ z114 машины.
А чрезвычайно успешные — по совокупности характеристик, прежде всего эффективности — количество выполняемой работы по отношению к затраченным ресурсам на выполнение работы и на обслуживание систем.
Система чрезвычайно устойчива — чему там ломаться то?
Если написали приложение и оно заработало — то будет работать всегда.
Чрезвычайно предсказуемая система — точно известно, за какое количество времени будет предоставлен каждый сегмент данных, сколько времени потребуется на выполнение каждого запроса, и так далее, без всяких неожиданностей.
ну и ещё:
в реляционках, отвечают на вопрос "какие данные", гавнякают быстро запросы, тестируют. кодируют приложения, тестируют, сдают в эксплуатацию. набираются данные. начинаются тормоза. мониторинг. explain. начинаем думать. переписываем запросы. изменяем структуру данных. и так в цикле.
в ИМС, отвечают на 2 вопроса "какие данные" и "какой порядок доступа к данным" (иначе даже структуру не создать), если на второй вопрос ответа нет — то и делать нечего, не ваша платформа, вам к реляционщикам. строится структура, которая задаёт единственно возможный — он же наиболее эффективный — способ доступа к данным. кодируется приложение. тестируют. сдают в эксплуацию. всё
1. Аааааааааааааа. Какой ужас. Боже, во что я вляпался! А ведь выбирал что попроще. теперь придется угробить на это дело около месяца и копать копать копать.
2. Встречаются же профи своего дела! Не знаю как долго Вы к этому шли и чего Вам это стоило, но это офигенно! Сразили наповал этой поэтикой! Откуда такие познания, если не секрет?
Думаю, если цель — сдать реферат, то выбирай чего попроще, про DB2 уверен полно работ в каких-нибудь базах рефератов, накопипастишь. Без производственного опыта понять плюсы IMS тяжело. После пары лет работы в отделе эксплуатации какой-нибудь АСУ банка/предприятия осознание о плюсах и минусах реляционного подхода придет само.
Идти к этому не долго — я начал с InfoCenter, конечно, аглицкий надо знать, а вот выше есть упоминание классной книжки — очень рекомендую, там Методика, именно Методика использования продукта. Многое тех пор изменилось в лучшую сторону, но это основа.
В принципе, в Бауманке семинары проводили четырёхдневные — студенты врубались быстро. Но знание аглицкого таки надо.
Я пока не профи, профи приезжает в Бауманку на семинары, будет вот в конце апреля. Вот он профи, таких как он на планете человек пять максимум.
В IMS нет ничего сложного, я бы так сказал, она в разы проще реляционок — но!
Это если смотреть с точки зрения кодера бизнес-приложений, а не со стороны разработчика самой IMS 🙂
А то некоторые тут сейчас возбудятся 🙂
Если не брать во внимание ещё и аспект системного программирования — отдельная специальность на мэйнфрейме — то работа с IMS проста и приятна. Системное программирование тоже не бог весть что, но таки знание HLASM вообще и z/OS надо иметь.
Но системное программирование вряд ли входит в реферат.
Да и книгу по Методике не обязательно читать для реферата. Пару дней полазить по азам, можно в InfoCenter, отдельно по базам данных — типы баз, типы ссылок между сегментами, логические ссылки, вторичные индексы, иерархическая последовательность выборки, и отдельно по монитору транзакций, там ещё меньше — транзакция, входная/выходная очереди, приложение, регион, MPP, IFP, BMP, JMP. Системные сервисы — DBRC, журналирование, т.д. т.п.
В принципе, реферат сделать можно, не думаю, что будет сложнее сделать, чем по той же ДБ2, вся информация в одном месте, лишнего читать не надо, но всё по английски. Хотя, может, по ДБ2 и проще — SQL, bufferpools, табличное пространство, контейнер, таблица, партиции, оптимизатор, типы хранимых процедур, журналирование, image copy, ну полазить по infocenter, выбрать перечень понятий и объектов.
Представители IBM у нас действительно бывают, в этом году даже планировали вести лекции, им нужны бизнес архитекторы, хотят теперь все сращивать в некую единую систему и проектировать "умный город". Проблема только в дикой нагрузке и в плавающем расписании =((
Какая модель данных используется в субд ibm ims information management system
IMS – спецификация стандартной архитектуры по управлению мультимедийными услугами на основе IP-протокола для сетей следующего поколения (NGN), обеспечивающая конвергенцию услуг передачи речи и данных, предоставляемых различными поставщиками, через общую инфраструктуру IP-сети, а также через различные типы мобильных и фиксированных сетей доступа.
IMS – это концепция, касающаяся, в основном, услуг и приложений. Она дает возможность предоставлять единый унифицированный доступ к сервисам абонентам мобильных и фиксированных сетей через единую опорную сеть на базе протокола IP-MPLS.
Основная цель – конвергенция (объединение) услуг и работа по IP протоколу.
IMS (IP Multimedia Subsystem, мультимедийная IP-подсистема) – комплексное решение, которое в перспективе призвано заменить все существующие сети электросвязи. Ядро сети по технологии IMS основано на коммутации пакетов и обеспечивает транзит (обмен) трафика, независимо от его происхождения (голос, мультимедийные файлы, видео), т.е. работает с различными сетями доступа. На "входе" в сеть, независимо от "последней мили" (фиксированной или беспроводной), любой трафик преобразуется в IP, и затем платформа управляет потоками пакетов.
Отличие IMS ver 6 от NGN
— Предоставление сервисов организовано на контроле сессий
— Для взаимодействия используется только IP
— SOFTSWITCH – все построено на одной аппаратной платформе, на которой работают несколько софтовых приложений, определяющих различные функции архитетуры IMS
Архитектура IMS
Архитектура IMS определена в стандартах 3GPP (3rd Generation Partnership Project), Европейского института стандартов связи ETSI и Форума Parlay.
схема проектируемой сети включает в себя следующее оборудование:
1) ядро IMS (Core IMS), состоящее из оборудования, реализующего функции:
а) управления сеансом (CSCF);
б) управления медиашлюзом (MGCF);
в) управления ресурсами мультимедиа (MRFC);
г) управления выбором сети (BGCF);
д) управления пограничным взаимодействием (IBCF);
е) управления шлюзом доступа (AGCF);
2) окружение IMS, состоящее из оборудования, реализующего функции:
а) процессора ресурсов мультимедиа (MRFP);
б) медиашлюза (MGF);
в) шлюза сигнализации (SGF);
г) пограничного шлюза (BGF);
д) подсистемы управления доступом и ресурсами (RACS);
е) сервера профиля пользователя (UPSF/HSS);
ж) определения местонахождения подписки (SLF);
з) учета данных для начисления платы (CCF);
и) взаимодействия (IWF);
к) подсистемы присоединения сети (NASS);
л) подсистемы эмуляции телефонной сети (PES);
м) подсистемы симуляции телефонной сети (PSS).
Уровень доступа
На этом уровне инициируется и терминируется сигнализация SIP, необходимая для установления сеансов и предоставления базовых услуг, таких как преобразование речи из аналоговой или цифровой формы в IP-пакеты с использованием протокола RTP (Realtime Transport Protocol). На этом уровне функционируют медиашлюзы, преобразующие базовые потоки VoIP в телефонный формат TDM.
Медиасервер предоставляет различные медиасервисы, в том числе конференц-связь, воспроизведение оповещений, сбор тоновых сигналов, распознавание речи, синтез речи и т.п.
На этом уровне функционируют медиашлюзы, преобразующие базовые потоки VoIP в телефонный формат TDM. Основным элементами является оборудование Уровня доступа СПД, через которое осуществляется подключение абонентов в ядру IMS (IAD, MSAN, DSLAM, OLT и др)
Уровень контроля сессиями
Один из двух основных логических блоков IMS — “сердце” всей системы — это блок управления сеансами связи (Call Session Control Function — CSCF), или, попросту говоря, SIP-серверы. Их основная задача реализация функциии управления сеансом (CSCF), — устанавливает, отслеживает, поддерживает и разъединяет мультимедийные сессии и обслуживает пользовательские взаимодействия, связанные с услугами. Оборудование CSCF выполняет три типа функций: прокси CSCF (P-CSCF), обслуживающая CSCF (S-CSCF) и запрашивающая CSCF (I CSCF). Прокси CSCF (P-CSCF) Proxy (обеспечивает доступ к сервисам из других сетей), обслуживающая CSCF (S-CSCF) Serving (осуществляет регстрацию и аутентификацию) запрашивающая CSCF (I CSCF) Interrogation (поределяет местонахождение абонента и роутинг).
MRFC (Media Resource Function Controller) На данном уровне реализуются функции контроллера ресурсов мультимедиа (MRFC), в соединении с оборудованием, реализующим функции процессора ресурсов мультимедиа (MRFP), располагающимся на транспортном уровне, обеспечивают набор ресурсов в основной сети для поддержки услуг. MRFC интерпретирует информацию, приходящую от сервера приложений (AS) через S-CSCF и соответствующим образом управляет MRFP. MRFC, в соединении с MRFP, обеспечивают мосты для многосторонних конференций, выдачу уведомлений абоненту, транскодирование информации.
Уровень приложений IMS
элементы уровня приложений и услуг в архитектуре коммутационной платформы IMS
1. Уровень приложений и услуг относится к верхнему уровню сетевой архитектуры IMS и предназначен для предоставления, обеспечения доступа и получения услуг как традиционной VoIP телефонии, так и мультимедийных услуг на базе IP и услуг интеллектуальных сетей.
2. Общая архитектура IMS соответствовует стандартам ETSI, 3GPP, TISPAN (не ниже 8 релиза) и включать на уровне услуг следующие функциональные компоненты:
a. Базу данных профилей абонентов:
блок определения местоположения абонента (Subscriber Location Function, SLF) — в случае использования нескольких HSS позволяет нахождение HSS с данными конкретного пользователя.
Серверы приложений AS (Application Server):
• сервер приложений SIP(SIP AS), который обеспечивает реализацию услуг платформы IMS;
• сервер коммутации мультимедийных услуг IP (IP Multimedia Service Switching Function, IM -SSF), который обеспечивает выполнение приложений расширенной логики сетей мобильной связи (Customized Application for Mobile Network Enhanced Logic, CAMEL), разработанных для сетей стандарта GSM;
• сервер приложений телефонии (Telephony AS TAS), который выполняет роль SIP User-agent, обеспечивает базовые возможности по обработке вызовов, включая маршрутизацию, установление, ожидание и перенаправление вызовов, конференц-связь и другие традиционные услуги.
• сервер обеспечения открытого доступа к услугам (Open Servise Access-Service Capability Server, OSA — SCS), который выполняет роль интерфейса для серверов приложений, построенных на основе OSA;
Сервер SCIM (Serviсe Capability Integration Manager), который обеспечивают взаимодействие серверов приложений с серверами управления вызовами и сеансами (CSCF).
Читайте также: