Проект TIPHON
Технологія VoIP >> Розділ 2. Мережеві аспекти IP-телефонії
[ << 2.1. Три основні сценарії IP-телефонії ] [ 2.3. Встановлення телефонного з'єднання в IP-мережі >> ]
2.2 Проект TIPHON
Робота над проектом TIPHON (Telecommunication and Internet Protocol Harmonization over Networks) була розпочата інститутом ETSI в квітні 1997 р. Основне завдання проекту - вирішення проблем взаємодії між мережами з маршрутизацією пакетів IP та мережами з комутацією каналів в частині підтримки прозорої передачі мовної та факсимільного інформації. Під мережами з комутацією каналів маються на увазі ТфОП, ISDN і GSM.
У проекті беруть участь понад 40 найбільших телекомунікаційних компаній. Є вісім робочих груп, остання з яких - щодо захисту інформації - була організована під час 15-ої наради робочих груп 4-8 жовтня 1999 р. в Лейпцігу. Результатом діяльності робочих груп TIPHON є технічні специфікації і звіти.
Сама ідея проекту TIPHON народилася під впливом динамічно розвивається ринку телекомунікаційних послуг, що надаються як операторами мереж зв'язку, що базуються на технології комутації каналів, так і операторами мереж, побудованих на основі технології маршрутизації пакетів IP. Завданням проекту є втілення в життя ідеології конвергенції та створення єдиної мережевої інфраструктури, привабливою для операторів різних видів зв'язку.
Була відзначена зростаюча потреба в організації зв'язку в реальному часі, в тому числі, телефонного зв'язку, у мережах, що реалізують технологію маршрутизації пакетів IP. Для задоволення цієї потреби інститут ETSI пропонує в проекті TIPHON концепцію «мережі мереж», такий, що мережі, що входять до її складу, можуть базуватися на технологіях комутації каналів і маршрутизації пакетів IP (рис. 2.7).
Рис. 1.1. Узагальнена структура мережі TIPHON
У рамках проекту TIPHON мережі, які використовують різні технології комутації, мають статус доменів «глобальної мережі». В основу взаємодії цих доменів покладено забезпечення гарантованої якості обслуговування (QoS) і захисту міжмережевих з'єднань. Крім того, забезпечується можливість управляти з'єднаннями, використовуючи стандартні протоколи сигналізації. Таким чином, мережа TIPHON можна визначити як мережа вищого рівня, що підтримує надання послуг телефонного зв'язку і базується на сукупності мереж нижчого рівня.
В основу проекту TIPHON покладені наступні правила:
- терміналами TIPHON можуть бути персональні комп'ютери і звичайні телефони;
- інтерфейс «людина-машина» (ММI) будується за аналогією з телефонним інтерфейсом;
- користувачі можуть змінювати точки доступу до послуг глобальної мережі; при цьому має зберігатися набір послуг, що надаються і якість обслуговування (QoS).
Головною метою проекту TIPHON є розробка механізмів взаємодії і пов'язаних з ними параметрів для забезпечення мультимедійного зв'язку з гарантованою якістю обслуговування між користувачами мереж з комутацією каналів і мереж з маршрутизацією пакетів. При цьому акцент робиться на взаємодію мереж, а не на окремі мережі, для чого і створюються відповідні специфікації і стандарти, орієнтовані на промислові підприємства, операторські компанії, адміністрації зв'язку, органи сертифікації та стандартизації та ін
Проект TIPHON передбачає вирішення низки технічних завдань, пов'язаних із забезпеченням прийнятної якості послуг телефонного зв'язку. У число цих завдань входить розробка еталонних конфігурацій і функціональних моделей, вимог до взаємодії різних функціональних об'єктів, процедур управління з'єднанням і протоколів; перетворення адрес в форматі Е.164 в IP-адреси; розгляд технічних аспектів захисту; вивчення питань мобільності і забезпечення якості обслуговування. Раніше вказувалося, що в роботі над проектом TIPHON беруть участь кілька груп, кожна з яких відповідає за вирішення певного завдання. Нижче представлені основні напрямки діяльності робочих груп TIPHON.
Розробка вимог до єдиної міжмережевий політиці, що визначають виявлення несправностей, вибір рівня якості обслуговування, підтримку необхідної сигналізації та передачі акустичних сигналів, трасування з'єднання, ідентифікацію абонента.
Розробка еталонних конфігурацій і функціональних моделей, включаючи функціональну модель шлюзу між IP-мережами та мережами з комутацією каналів, а також специфікацію інтерфейсів шлюзу. Моделі повинні відображати всі аспекти функціональності шлюзів, у тому числі взаємодія з воротарями і з Інтелектуальними мережами.
Розробка процедур обробки викликів і протоколів, алгоритмів встановлення і руйнування з'єднання, процедур виявлення воротаря, реєстрації кінцевого обладнання, аутентифікації користувача. Тут же розглядаються питання використання DTMF-сигналізації і специфицируются функції транспортного рівня.
Перетворення адреси у форматі Е.164 в IP-адресу. Користувачам IP-мереж, як правило, адреси виділяються динамічно, тому ідентифікувати користувачів по їх IP-адресами неможливо. Необхідно розробити новий механізм адресації, що забезпечує технологічну прозорість при перетворенні номери Е.164 в IP-адресу.
Технічні аспекти нарахування плати та виставлення рахунків. Повинні бути передбачені такі форми оплати: кредит, дебет, оплата за допомогою кредитної картки, оплата викликається стороною. При цьому повинні враховуватися наступні параметри: тип послуги, тривалість зв'язку, час доби.
Технічні аспекти захисту. До них відноситься первинний захист мережі від випадкових або навмисних пошкоджень. Тут же розглядається захист інформації та доступу, а також пов'язані з цим питання сигналізації, навантаження, аутентифікації, авторизації, шифрування і таємності виклику.
Питання якості обслуговування. Кінцевий користувач очікує, що послуга передачі мовної інформації буде надаватися з гарною якістю і високою надійністю. Але такі приклади, як надання послуг стільникового зв'язку стандарту GSM і мікростільникового зв'язку стандарту DECT, показали, що кінцевого користувача задовольняє якість обслуговування, найгірше в порівнянні з ТфОП або ISDN, до тих пір, поки він отримує вигоду від використання нової послуги. У разі надання послуг стільникового зв'язку - це мобільність терміналу, а в разі IP-телефонії це можуть бути низька вартість, можливості інтеграції послуг в рамках єдиної мережі.
Питання мобільності користувача. Користувач повинен мати доступ до послуги передачі мовної інформації по IP-мереж в будь-якому місці мережі.
Нижче трохи докладніше розглядаються найбільш цікаві, як здалося авторам, напрямки діяльності груп, що працюють над проектом TIPHON. Одним з таких напрямів є розробка принципу декомпозиції шлюзу.
Взяту за основу рекомендацію ITU-T Н.323, специфікації TIPHON доповнюють деякими обов'язковими процедурами, а також механізмами взаємодії IP-мереж з ТфОП. функціональна модель мережі IP-телефонії, розроблена TIPHON, складається з тих же компонентів, що і модель мережі Н.323 (сторож, шлюз, термінал), однак у ній передбачено поділ шлюзу на три функціонально-незалежних об'єкта. Це шлюз сигналізації (SG), транспортний шлюз (MG) і контролер транспортного шлюзу (MGC).
Шлюз сигналізації служить проміжною ланкою сигналізації між IP-мережами і ТфОП. У завдання транспортного шлюзу входить перетворення і / або перекодування переданої інформації. До транспортного шлюзу підключені ІКМ-тракти мережі з комутацією каналів, він також пригнічує відлуння, відтворює різні повідомлення для абонентів, приймає і передає сигнали DTMF і т.д. Контролер транспортного шлюзу MGC виконує процедури сигналізації Н.323, які визначені в рекомендаціях ITU-T Н.323, Н.225 (RAS і Q.931) і Н.245, а також перетворює сигналізацію ТфОП в сигналізацію Н.323. Основне його завдання - керувати роботою транспортного шлюзу, тобто здійснювати управління з'єднаннями, використанням ресурсів, перетворенням протоколів і т.п.
Сторож відповідає за управління об'єктами мережі, зокрема, виконує перетворення адрес (наприклад, телефонних номерів у відповідні IP-адреси) і маршрутизацію сигнальної інформації. Сторож в моделі мережі TIPHON підтримує всі ті функції, які визначені для нього в рекомендації Н.323. Але, крім цього, він відповідає за нарахування плати, взаєморозрахунки, складання звітів про використання ресурсів та виконує деякі інші функції.
Слід особливо підкреслити, що MGC - це об'єкт, який контролює роботу транспортного шлюзу. Управління сполуками в його функції не входить. Це - завдання воротаря, який виконує її відповідно з рекомендацією ITU-T Н.323.
Розроблена в рамках проекту TIPHON модель мережі, що складається з функціональних елементів та інтерфейсів (точок доступу) між ними, показана на рис. 2.8. Щоб відповідати рекомендаціям TIPHON, обладнання повинне підтримувати ці інтерфейси. Так, інтерфейс D призначений для організації взаємодії між воротарями, а інтерфейс С - між контролером шлюзу MGC і воротарем. Інтерфейс N підтримує взаємодію між об'єктами MGC і MG. Вони можуть спілкуватися на предмет створення, модифікації і завершення з'єднань; визначення необхідного формату інформації; генерації акустичних сигналів і різних мовних повідомлень; запиту звітів про події, пов'язані з проходженням інформаційного потоку. Показані на рис. 2.8 функції підтримки (back-end) можуть бути використані для аутентифікації, білінгу, перетворення адрес і інших завдань.
Змодельований на основі трьох описаних елементів розподілений шлюз сприймається іншими елементами мережі як єдина система.
Рис. 1.1. Модель мережі TIPHON
Три згаданих елемента (SG, MG, MGC) можуть не бути фізично розділені, однак такий поділ дає певні переваги. Справа в тому, що використання трьох окремих об'єктів дозволить обробляти більше викликів, оскільки в цьому випадку різні функції розподіляються по окремих процесорам. В ідеалі такі об'єкти повинні мати стандартні інтерфейси, що дасть оператору можливість використовувати продукцію різних фірм-виробників. У наведеній вище моделі один шлюз сигналізації з метою
більш економічного розгортання мережі може бути використаний для обслуговування великої кількості транспортних шлюзів.
Тепер слід розглянути питання про адресації в рамках проекту TIPHON. Від вирішення завдань адресації багато в чому залежать зручність користування послугою, робота алгоритмів маршрутизації, забезпечення мобільності абонентів і т.д. Концепцією телефонного зв'язку передбачено, що абонент мережі ТфОП повинен мати можливість зв'язатися з іншим абонентом зі свого телефону шляхом набору номера незалежно від того, до мережі якого типу підключений адресат. Формат номера зазвичай відповідає рекомендації Є. 164. В даний час органами стандартизації розробляються механізми перетворення телефонних номерів або в IP-адреси, або в уніфіковані покажчики ресурсів (URL).
Відображення телефонних номерів на IP-адреси створює проблему управління даними, так як користувачі мають тенденцію переміщатися по всій мережі Інтернет і входити в систему з різних місць, тому їх IP-адресу регулярно змінюється. Якщо передбачається, що мережі IP-телефонії будуть обслуговувати сотні мільйонів користувачів, то гнучке і надійне вирішення питання про те, яким чином має виконуватися регулярне оновлення даних і як повинні оброблятися запити, з усією очевидністю стане складною проблемою.
Відображення телефонних номерів на URL трохи спрощує проблему перетворення адрес шляхом використання інтернетівського ярлика для ідентифікації користувача. Однак, як тільки телефонний номер перетворений в ярлик, останній повинен бути перетворений на адресу постачальника послуг Інтернет, що, у свою чергу, формує остаточний IP-адресу одержувача. Наявність такої великої кількості стадій, потрібних, щоб знайти абонента, що викликається, буде, очевидно, суттєво збільшувати час між набором номера викликає абонентом і одержанням ним сигналу КПВ або зумера «Зайнято».
В даний час органами стандартизації розробляються й інші механізми, що забезпечують належну адресацію і маршрутизацію номерів Е.164, проте простих і універсальних шляхів вирішення цієї проблеми поки що не видно. Питання перетворення номери телефонної мережі загального користування в IP-адреса представляється поки ще досить складною, та шляхи її розв'язання розробляються не тільки робочою групою 4 у рамках проекту TIPHON, а й іншими організаціями, наприклад IETF.
Ще одним важливим напрямком роботи TIPHON є питання про класи обслуговування. Для операторів дуже приваблива можливість надання послуг з різним рівнем якості (і, відповідно, з різними тарифами), причому підтримуваним не тільки в межах мережі одного оператора, а й при зв'язку між мережами різних операторів. Для цього в рамках проекту TIPHON визначені чотири класи обслуговування, кожен з яких гарантує певну якість, як при встановленні з'єднання, так і під час сеансу зв'язку (таблиця 2.2).
Таблиця 2.2 Характеристики класів обслуговування TIPHON
| | |
|||
| Найвищий (4) | Високий (3) | Середній (2) | Низький (1) | |
| Якість передачі голосу в одному напрямку | Краще, чим G.711 | Не гірше. чим G.726 (32 Кбит/с) | Не гірше ніж GSM-FR | Не визначено |
| Наскрізна затримка, мс | <150 | <250 | <350 | <450 |
| Час встановлення з'єднання при прямій ІР-адресації, с (від IP до ТфОП) | <1,5 | 4 | 7 | 7 |
| Час встановлення з'єднання при перетворенні номера Е.164 в ІР-адрес, с | <2 | <5 | <10 | <10 |
| Час встановлення з'єднання при перетворенні номера Е.164 в ІР-адрес через клігинговий центр або при роумінгу, с | <3 | <8 | <15 | <15 |
| Час встановлення з'єднання при прямій ІР-адресації, с (від ТфОП до IP) | <4 | <10 | <20 | <20 |
| Час встановлення з'єднання при перетворенні номера Е.164 в ІР-адрес через клігинговий центр або при роумінгу, с (від ТфОП до IP) | <6 | <15 | <30 | <30 |
| Час встановлення з'єднання при перетворенні адреси електронної пошти в ІР-адрес, с | <4 | <13 | <25 | <25 |
* - Користувач IP-мережі викликає абонента ТМЗК.
** - Абонент ТфОП викликає користувача IP-мережі.
Якість обслуговування при встановленні з'єднання характеризується, перш за все, часом його встановлення, тобто часом між набором абонентом останньої цифри номера (або, наприклад, команди введення при наборі адреси на комп'ютері) і одержанням ним відповідного акустичного сигналу. Якість обслуговування під час сеансу зв'язку визначається багатьма факторами, основними з яких є наскрізна тимчасова затримка і якість наскрізної передачі мови (оцінюється методами експертної оцінки).
[ << 2.1. Три основні сценарії IP-телефонії ] [ 2.3. Встановлення телефонного з'єднання в IP-мережі >> ]
--Козінцев Олексій 36 гр. 11:42, 16 листопада 2010 (EET)
