l_472_12078122

послуги IMS. Підтримка функції хендовер в цій архітектурі також є присутньою, що продемонструвала компанія Cisco Systems для приватних абонентів.

Важливою перевагою IMS є також різноманітність підтримуваних інтерфейсів, що дає змогу адаптувати операторські послуги для різних терміналів незалежно від типу мережі.

Зазначимо, що перші програми IMS у мобільному зв'язку буде сфокусовано на послугах, не пов'язаних з двостороннім (дуплексним) спілкуванням. Це обумовлено тим, що традиційна мережа радіодоступу поки що має значні обмеження у доставці VoIP. При переході на VoIP слід звернутися за допомогою до сервіс-провайдерів, адже вони, крім іншого, здатні запропонувати й керовані послуги – кероване передавання голосу по IP і керовану безпеку.

Очевидно, що сервіс-провайдери повинні вносити інвестиції в мережеву інфрастктуру IMS, так як від IMS вони отримують все необхідне для надання конвергентних мультимедійних послуг.

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

621

Контрольні питання

1.Опишіть план реалізації конвергентної платформи надання послуг.

2.У чому полягає суть концепції FMC, і які основні технології застосовують для її реалізації?

3.У чому полягає особливість концепції IMS?

4.Охарактеризуйте основні властивості архітектури

IMS.

5.Перерахуйте основне обладнання транспортної площини архітектури IMS.

6.Перерахуйте основні елементи рівня керування та його функції.

7.Охарактеризуйте набір серверів рівня застосовань у

IMS.

8.Чому стандартизація архітектури IMS є предметом уваги широкого кола міжнародних організацій? Які організації беруть участь у стандартизації IMS?

9.Охарактеризуйте перспективи переходу на конвергентні платформи надання послуг? У чому складність такого переходу?

622

Розділ 17. Відкритий доступ до послуг

Складність практичної реалізації конвергентних платформ надання послуг полягає в тому, що наявні мережі фіксованого зв'язку, мобільного зв'язку та Інтернет спочатку будували за різними стандартами, тому програмне забезпечення однієї мережі на іншу не можна перенести. Це означає, що для забезпечення однакового набору послуг неможливо створити універсальні для цих мереж застосовання, що, природно, гальмує розвиток ринку послуг.

Узв'язку з цим постає завдання досягти

універсальності, звертаючись до застосовань і нових послуг

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

заснованих на відкритих стандартах, і архітектури відкритого доступу до послуг.

17.1. Відкриті стандарти інтерфейсів прикладного програмування

Прикладний програмний інтерфейс (Applied Programming Interfacе, API), який ще називають інтерфейсом прикладного програмування, – це набір стандартних програмних переривань, викликів процедур і форматів даних, які використовує застосовання для запиту та отримання від телекомунікаційного протоколу певних сервісів.

API визначає рівень абстракції вихідного тексту прикладної програми, що дає змогу переносити його на функціональні елементи мережі з різними процесорами й

623

технологічними особливостями для безпосереднього виконання. Таким чином, API стають незалежними від протоколів і технологій, які застосовуються усередині мережі.

API стандартизуються для того, щоб будь-який сторонній програміст-розробник міг створювати застосовання, витрачаючи мінімум зусиль і часу. Таким чином, будь-які нові програми та послуги можна розробляти, застосовуючи звичні інструментарії для програмування без урахування специфіки роботи мережі, детального знання сигналізації СС-7, протоколу ініціювання сесій SIP та ін. Достатнім є лише чітко дотримуватися інтерфейсів API.

Нижче наводимо основні використовувані відкриті стандарти API.

API-Parlay – API платформи для розробки, інтеграції та розгортання застосовань на основі технології Java. Розробку стандартів API-Parlay здійснює Parlay Group – консорціум розробників програмного забезпечення інформаційнокомунікаційних послуг. Відмінною особливістю цієї платформи є поєднання її функціональних можливостей з масштабованістю сучасних мереж, що дає змогу забезпечити підтримку різноманітних типів переданих даних, застосовань і клієнтських середовищ та спростити та пришвидшити розробку послуг та програм, використовуючи розподілені та розширювані компоненти на основі технології Java.

API-JAIN – API розвиненої інтелектуальної мережі IN

на базі Java (Java Advanced Intelligent Network, JAIN). JAIN дає змогу здійснювати інтеграцію протоколів IP-мереж і IN, забезпечуючи новий рівень абстракції, оскільки має відповідні Java-інтерфейси для створення послуг у мережах ТфЗК, IP або

624

АТМ. Окрім того, JAIN забезпечує перенесення послуг, конвергенцію мереж і захищений доступ як до телефонних послуг, так і до послуг мереж передавання даних.

API-CORBA – API архітектури брокера запитів до об'єктів (Common Object Reguest Broker Architecture, CORBA). CORBA є відкритою, незалежною від постачальників архітектурою, яку використовують прикладні обчислювальні системи для забезпечення спільної роботи в комп'ютерних мережах.

API побудовано з використанням розширюваної мови розмітки XML – мови HXML. HXML застосовується як стандартний спосіб обміну інформацією в середовищах, де не використовують загальні платформи. Побудова API для механізмів дистанційного виклику процедури на базі XML дає простий та розширюваний спосіб обміну даними з пристроєм. Цю технологію найчастіше використовують для створення web-сервісів та для забезпечення їх взаємодії з клієнтським процесом.

17.2. Концепція відкритого доступу до послуг (OSA)

Наявність відкритих стандартів прикладних програмних інтерфейсів API хоча й сприяє швидкому створенню та впровадженню нових застосовань, але не зовсім вирішує завдання оперативного введення в експлуатацію нових комунікаційних послуг, тому що звернення різних мережевих платформ до застосовань не є універсальним.

Виникає необхідність долучити проміжну ланку – міст між розробниками застосовань і мережевими операторами.

625

Ідея створення такого «мосту» породила концепцію, що отримала відповідно до рекомендацій ETSI назву відкритого доступу до послуг (Open System Access, OSA).

Ідея концепції OSA полягає в тому, щоб забезпечити мережеві елементи, які працюють за різними протоколами, можливістю взаємодіяти з застосованнями та послугами через стандартні інтерфейси API за допомогою сервера доступу до послуг. Даний сервер призначено для втілення ідеї «мосту», тобто шлюзу.

Концепція OSA передбачає також реалізацію єдиних засобів і способів керування як уже наявними мережами, так розроблюваними конвергентними платформами у процесі надання комунікаційних послуг. Відповідно до концепції OSA елементи керування мережею є незалежними від протоколів і технологій, які застосовують усередині самої мережі, настільки, наскільки це є можливим і необхідним. Зважаючи на те, цей рівень є прикладним, дані елементи керування, закономірно, повинні дотримуватися інтерфейсів API.

Сервери застосовань можуть перебувати поза зоною мережевого оператора, як, наприклад, це передбачено в технології побудови розподілених інформаційних систем CORBA. Дозволяючи серверам застосовань керувати мережею ззовні, можна, проте, гарантувати безпеку мережі, що можна досягти автентифікацією застосовань, використовуючи міжмережеві екрани. При переході до мереж NGN програмний комутатор Softswitch також буде взмозі керувати серверами застосовань саме через API-Parlay.

Створюючи конвергентні платформи на основі OSA, передбачають такі принципово важливі аспекти:

626

•відкрите середовище для створення послуг;

•відкрита платформа керування послугами.

Слід зазначити, що концепція OSA використовує багато положень концепції інтелектуальної мережі IN, зокрема, принцип програмного формування компонентів основної послуги та додаткових видів обслуговування, програмну модель виклику та поняття "тригера" як точки виявлення запиту на додаткову послугу (див. п. 8.3).

Відкрите середовище для створення послуг, в рамках концепції OSA, в усьому базується на стандартних API та передбачає розробку нових програмних блоків послуг і компонування послуги, використовуючи спеціальні інструментальні засоби програмування. Закладені в ці засоби принципи модульності дають змоги сервіс-провайдеру самостійно комбінувати й налаштовувати програмні компоненти в своїй мережі.

OSA дає можливість операторам і сервіс-провайдерам інтегрувати в мережі застосовання від різних сторонніх виробників, а також розробляти свої власні програми.

Інтерфейси API розміщують на серверах застосовань, забезпечуючи доступ до інфокомунікаційних послуг. Використання API та протоколу ініціації сесії SIP дає змогу легко долучати нові послуги. На сервері застосовань можна розміщувати також моделі традиційної інтелектуальної мережі IN та необхідні для неї протоколи сигналізації СС-7. І, нарешті, сервер застосовань і абонент, якому надають послугу, можуть знаходитися в мережах, що належать різним операторам.

627

Відкрита платформа керування послугами містить такі елементи, як медіасервер і транспортні шлюзи.

Медіасервери призначено для реалізації послуг, забезпечуючи спеціалізовані ресурси, такі, наприклад, як засоби конференц-зв'язку, інтерактивну мовленнєву систему, факсимільне передавання та ін. Медіасервер і сервери застосовань є незалежними пристроями, але можуть розгортатися як на окремих фізичних платформах, так і на одній платформі. Сервер застосовань може використовувати ресурси, розташовані на медіасервері, наприклад, для забезпечення послуг, які вимагають доступу до мультимедійної інформації користувача. Якщо сервер застосовань використовується в поєднанні з медіасервером, то логіка послуг у сервері застосовань має доступ до всіх подій у процесі обслуговування виклику засобами протоколу SIP.

Транспортні шлюзи – це сервери, налаштовані в режимі шлюзу, тобто комунікаційного устатковання (на відміну від серверів застосовань і медіасерверів, які налаштовані в режимі хосту). Транспортні шлюзи завжди розташовуються на межі мережі, а медіасервери можуть розташовуватися як на межі, так і в ядрі мережі. Крім своїх основних функцій – сполучування сегментів мереж різних операторів– транспортні шлюзи можуть виконувати обробку інформації користувачів спільно з медіасервером.

Таким чином, операторам зв'язку надано всі механізми, що дають змогу швидко та гнучко розгортати, а також змінювати послуги залежно від індивідуальних потреб користувачів.

628

17.3. Архітектура OSA/Parlay

Упродовж декількох років різні організації пропонували кілька варіантів реалізації концепції OSA, допоки 1998 року не було засновано консорціум Parlay Group, до якого ввійшли провідні світові розробники програмних продуктів, телекомунікаційних рішень, а також оператори зв'язку.

Окрім створення відкритих специфікацій API, група Parlay розробила архітектуру, яка стала однією з визнаних практичних реалізацій концепції відкритого доступу до послуг. Вона отримала назву «архітектура OSA/Parlay».

Основу архітектури складають три типи компонентів:

застосовання, шлюз доступу до послуг та функціональні мережеві елементи (див. рис. 17.1).

		Область
	застосовання	сторонніх
		програмістів
	Єдиний інтерфейс
	OSA/Parlay API
	OSA/Parlay-шлюз	Область
		телефонних
	Різні протоколи
		компаній
	взаємодії зі застосованнями

GSN

MSN

SSP

S-CSCF

YATS

ТфЗК

Мережі СРЗ, GSM/GPRS

Мережі

СРЗ 3G

Відомчи

мережі

(комутація

каналів)

(комутація пакетів,

(мультимедійні

комутація каналів)

послуги)

Рисунок 17.1. Архітектура OSA/Parlay CРЗ – система рухомого зв’язку

629

Архітектура OSA визначає набір функціональних мережевих елементів, взаємодію яких із застосованнями можна реалізувати через API за допомогою OSA/Parlay-

шлюзу.

Як показано на рисунку 17.1, різні мережі зв'язку мають різні функціональні мережеві елементи, зокрема:

•у мережах мобільного зв'язку виокремлюють SGSN

(Serving GPRS Support Node) – сервісний опорний вузол GPRS і MSC (Mobile Switching Center) – центр комутації мобільного зв'язку;

•у телефонній мережі загального користуванн – SSP

(Service Switching Point), який є вузлом комутації послуг (IN);

•у мобільних мережах 3G – S-CSCF (Serving Call Session Control Function), тобто функціональний елемент керування сесією виклику послуг;

•у відомчих мережах зв'язку – установчі АТС (Private Branch Exchange, РВХ).

Кожен із перерахованих функціональних елементів виходить на OSA/Parlay-шлюз за своїм власним протоколу, а завдання шлюзу за концепцією OSA полягає в тому, щоб звести всі протоколи до єдиних інтерфейсів API.

630