Реферат Аналіз варіантів побудови платформи інтелектуальних мереж IN
Работа добавлена на сайт bukvasha.net: 2015-10-28Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
ТЕМА
Аналіз варіантів побудови платформи інтелектуальних мереж (IN)
Вступ
Очевидно, що чим краща мережа зв'язку оператора, тим більш ефективну платформу для надання послуг інтелектуальної мережі можна створити на її базі. На якість надання послуг IN впливають такі характеристики базової мережі: по-перше, технічні пристрої, такі як прикінцеві та транзитні комутаційні системи, системи передачі, абонентські мережі доступу, вузли SCP і SSP, і по-друге, засоби адміністративного управління та технічної експлуатації послуг.
Створення платформи IN полегшується наявністю на мережі таких основних атрибутів:
- системи сигналізації СКС №7;
- цифрових систем комутації на всіх рівнях до прикінцевого;
- цифрових систем передачі;
- можливості використання телефонних апаратів із тональним набором;
- можливості ідентифікації лінії викликаючого абонента;
- обладнання одного виробника;
- систем докладного обліку вартості;
- організації, що здійснює маркетинг і обслуговування послуг зв'язку.
Оператор може почати створення платформи IN, не маючи жодного з наведених атрибутів, проте, чим більше з цього переліку він має, тим швидше та дешевше обійдеться створення платформи.
Система сигналізації СКС №7 у більшості застосувань обов'язково потрібна для взаємодії між вузлами SCP і SSP. Специфікація інтерфейсу між SCP і SSP є найбільш важливою частиною стандартизації IN. Рекомендований ITU-T спосіб перенесення сигналізації на цьому інтерфейсі – використання протоколів TCAP/INAP, що cпираються на системи сигналізації СКС №7 SCCP/MTP.
Переваги цифрових комутаційних систем і цифрових систем передачі стали настільки очевидними, що іноді ми забуваємо згадати про них. Проте значна кількість аналогових систем комутації, загалом на рівні прикінцевих АТС, найчастіше робить неможливим використання багатьох послуг IN абонентами, що обслуговуються цими АТС, через застарілі протоколи сигналізації.
Використання обладнання одного постачальника полегшує стик обладнання (наприклад, SCP і SSP), проте, може бути достатньо дорогим для оператора, оскільки тільки конкуренція знижує ціну.
Система докладного обліку вартості дає можливість винести дії щодо нарахування оплати в білінг-центр для забезпечення гнучкості у призначенні тарифів і нарахуванні оплати на різні рахунки залежно від типу послуги та її постачальника. Подібне практично неможливо зробити за допомогою використання індивідуальних абонентських лічильників.
Рішення про спосіб побудови IN для кожного оператора має бути індивідуальним і враховувати місцеві фактори, такі як ємність мережі, тип уже встановленого обладнання, прогнозований трафік, плановані послуги, економічний стан регіону тощо. Оскільки платформи IN провідних фірм-постачальників мають більш великий діапазон продуктивності (обробка від 360 спроб викликів у ЧНН до декількох мільйонів), на перший план для операторів виходить завдання забезпечення плавного зростання потужності впроваджуваного обладнання без кардинальних змін на мережі. Бажано, щоб при такому розвитку апаратне забезпечення (обсяг пам'яті, кількість серверів тощо) розширювалося за модульним принципом без зміни ПЗ, що дозволить повторно використати вже закуплені елементи в новій конфігурації. Успіх при такому еволюційному шляху розвитку засобів IN може принести тільки добре продуманий процес переходу від однієї конфігурації до іншої.
З урахуванням наведених вище особливостей способів побудови платформи IN сформулюємо загальні рекомендації з вибору способу реалізації IN для різних операторів.
1 Розподілена архітектура побудови IN
Розподілена архітектура побудови IN – це повномасштабне класичне рішення у вигляді окремих архітектурних елементів (рис. 1):
- вузол SSP – комутатор ТМЗК, оснащений зворотним зв'язком з підключеним до нього комп'ютером;
- інтелектуальна периферія IP, що забезпечує більшу зручність у процесі надання послуг, зокрема при обміні інформацією з користувачем, шляхом використання спеціалізованих ресурсів (оголошення, мовні підказки, розпізнавання мови тощо);
- вузол SCP, що управляє логікою надання послуг;
- вузол SMP, призначений для введення нових послуг і коректування старих, зберігання інформації про всі послуги, що надаються, а також оригіналів усіх програм обслуговування;
- вузол середовища створення послуг SCEP;
- вузол підтримки даних послуг SDP, що зберігає дані, які використовуються програмами логіки послуг.
Рисунок 1 – Класична архітектура IN
«Повна» або так звана «класична» архітектура IN для першого набору послуг CS-1 призначена для використання у великих або середніх мережах із високим трафіком. Вона здатна забезпечити на нинішньому етапі розвитку практично всі вимоги як операторів, так і майбутніх користувачів. Але ця система достатньо дорога. Тому компанії, яких цікавить насамперед невисока вартість обладнання, та компанії, які хочуть спочатку оцінити ефективність від впровадження нових послуг, часто вибирають інші варіанти.
Ще одним недоліком класичної архітектури є необхідність взаємодії SSР і SСР по мережі сигналізації СКС №7, а отже й обов’язкова її наявність у базовій мережі загального користування. При впровадженні послуг IN необхідно врахувати додаткове навантаження на мережу сигналізації та розрахувати необхідну кількість сигнальних каналів між вузлами SSP і SCP.
Процес взаємодії цих вузлів починається після надходження на станцію, що містить SSР, останньої цифри набору коду та номера послуги. SSР здійснює аналіз отриманої інформації, ініціює запит послуги у вигляді повідомлення IDР і передає його за допомогою протоколу INАР у вигляді команди BEGIN каналом СКС №7.
Повідомлення, отримане SСР, аналізується, обробляється комп'ютерами, внаслідок чого SSР одержує відповідь із SСР, в якій міститься інформація про те, як надати послугу. У загальному випадку подібний діалог може складатися з декількох транзакцій, тобто з декількох циклів «запит-відповідь», що забезпечують виконання необхідної послуги. На рис. 2 наведено діалог, що містить дві транзакції. Короткими стрілками показані інші повідомлення, що циркулюють у дуплексному каналі СКС №7 і не мають відношення до даної транзакції. Це можуть бути або повідомлення інших транзакцій, або службові сигнальні одиниці (СО), або «порожні» СО, що забезпечують синхронізацію роботи каналу СКС №7.
Рисунок 2 – Діалог між SSР і SСР у мережі СКС №7
Після отримання повідомлення ВЕGIN, що ініціює запит на інтелектуальну послугу, SСР обробляє зазначений запит і через деякий проміжок часу видає убік SSР повідомлення CONTINUE та іншу інформацію, необхідну для здійснення комутації та обслуговування необхідної послуги. Після одержання зазначеної інформації SSР повідомленням END інформує SСР про закінчення обміну, а SСР повідомленням DEND підтверджує відсутність помилок і згоду на завершення обміну.
У ланці СКС №7 повідомлення передаються за допомогою пакетів, що мають назву сигнальних одиниць (СО). Ці СО мають різне призначення та змінну довжину. Одне повідомлення може передаватися за допомогою декількох СО.
Використовується три типи СО:
- значущі СО (ЗНСО) – їхня довжина може бути до 273 байт;
- сигнальні одиниці стану ланки (СЛСО), використовуються для індикації стану прикінцевих пристроїв і управління ланкою сигналізації, їхня довжина може бути 7 або 8 байт;
- заповнювальні СО (ЗПСО), які мають нульову корисну довжину, але їхня наявність необхідна для оперативного контролю працездатності ланки сигналізації за відсутності сигнального трафіка користувача. ЗПСО передаються лише в тому випадку, коли немає для передачі ЗНСО або СЛСО, їхня довжина зазвичай приймається 6 байт.
При передачі СО в СКС №7 використовується дисципліна обслуговування з відносним пріоритетом, оскільки не можна перервати передачу СО, що вже почалась. СЛСО мають найвищий пріоритет. Наступний пріоритет належить ЗНСО.
Для досягнення необхідної продуктивності та підвищення надійності передачі сигнальних повідомлень між SSP і SCP зазвичай використовують одночасно кілька ланок СКС.
Припустимо, що мережа надає
Кількість користувачів послуги
Тоді інтенсивності надходження запитів на послугу
Сумарна інтенсивність надходження запитів на всі види послуг, задіяних у мережі
Імовірності появи запиту на послугу
Середня кількість транзакцій на одну послугу:
де
Значення
Частина послуг вимагає для свого виконання передачі деяких статистичних даних. Позначимо через
Середня кількість транзакцій, що здійснюються в одну секунду, з урахуванням передачі статистичних даних:
Зазначена інтенсивність здійснення транзакцій є основою для розрахунку необхідної кількості ланок системи СКС №7 між SSP і SCP.
Припустимо, що кожна транзакція містить
Середня тривалість передачі групи ЗНСО, що передаються в одному напрямку протягом однієї транзакції
де
Позначимо середню довжину пакета, що передаються протягом однієї транзакції в одному напрямку каналом СКС №7 як
Кількість
Значення
Крім ЗНСО в каналі існує потік СЛСО з інтенсивністю
Тривалість передачі СО залежить від їхньої довжини та швидкості передачі інформації в каналі
Швидкість передачі інформації
Отримане значення
Інтенсивність надходження транзакцій у розрахунку на одну ланку СКС№7
є однією з основних характеристик працездатності ланки.
2 Централізована архітектура побудови IN
Протягом історії розвитку послуг IN склалося кілька способів взаємодії з централізованими програмно-апаратними засобами реалізації логіки послуг, що пізніше одержали загальну назву вузла SCP. Перший спосіб був заснований на застосуванні протоколу Х.25, другий – на використанні модифікованої версії підсистеми TUP (або ISUP) системи сигналізації СКС №7. Третій і четвертий – на використанні інтегрованого вузла комутації та управління SSCP і вузла послуг SN, які є варіантами реалізації IN централізованої архітектури.
Вузли SSCP і SN містять у собі всі необхідні функції (SSF, SCF, SDF і SRF), інтегровані на єдиній платформі і є незалежними та повністю автономними мережними елементами, що реалізують послуги IN (рис. 3).
Загальною вимогою до базової мережі при побудові «класичної» IN є те, що провайдер повинен забезпечити підтримку системи сигналізації СКС №7, що пов'язує всі вузли IN з усіма АТС телефонної мережі. Вузли типу SN і SSCP зазвичай можуть працювати з ТМЗК по цифрових потоках, прийнятих у даній країні, що дуже важливо для країн, у телефонних мережах яких СКС №7 не завжди підтримується.
Крім того, для передачі абонентами IN додаткової інформації (наприклад, номера телефонної карти) як абонентські термінали, як правило, використовують телефонні апарати з тональним режимом набору номера. Однак у країнах, де прийнятий переважно декадний спосіб набору номера, розвиток послуг гальмується через необхідність заміни парку телефонних апаратів. Якщо навіть замінити всі аналогові АТС на цифрові, то навряд чи вдасться змусити всіх абонентів замінити свої телефонні апарати, тому втрачається зміст впровадження IN. Побудова IN з вузлом типу SN дозволяє вирішити проблему за рахунок більш гнучкої реалізації функції вузла SSP.
Рисунок 3 – Конфігурація IN із централізованою архітектурою
До переваг використання централізованої архітектури можна також віднести:
- відсутність необхідності в адаптації навколишньої мережі до впровадження послуг IN, тобто введення функції SSP у станції та організації їхнього зв'язку із платформою протоколом INAP;
- можливості легкої модернізації логіки послуг і створення нових послуг без внесення змін в інтерфейси взаємодіючих об'єктів за рахунок зосередження функцій SSP і SCP в одному вузлі;
- швидке впровадження послуг;
- створення послуг у режимі on-line;
- наявність потужних інструментів адміністративного управління;
- захист стартових інвестицій в IN на всіх рівнях.
Серед недоліків централізованої архітектури слід зазначити:
- досить низьку продуктивність;
- обмежений набір реалізованих послуг;
- неефективне використання ємності комутаційного поля (при з'єднанні користувача з абонентом послуги в SN задіяно вдвічі більше точок комутації, ніж при «класичній» архітектурі);
- зростання ймовірності внутрішніх блокувань при збільшенні трафіка.
Хоча на першому етапі різниця між централізованою та "класичною" архітектурою є невеликою, з погляду перспектив розвитку мережі існують суттєві відмінності (рис. 4–6). Так, SSCP дозволяє нестандартний інтерфейс між функціями SSF і SCF, але зі збереженням усіх стандартних інтерфейсів SSP. Наслідком є можливість надання послуг IN в умовах повної відсутності мережі СКС №7 з одного боку, і неоптимальність розвитку мережі при збільшенні кількості SSP і трафіка IN, з іншого.
РРисунок 4 – Перспективи розвитку платформи IN у випадку SSCP
Рисунок 5 – Перспективи розвитку платформи IN у випадку SN
Рисунок 6 – Перспективи розвитку платформи IN у випадку автономних SSP і SCP
Рисунок 5 – Перспективи розвитку платформи IN у випадку SN
Рисунок 6 – Перспективи розвитку платформи IN у випадку автономних SSP і SCP
Після введення нового SSP раніше розгорнутий SSCP може функціонувати вже тільки як SSP, отже на мережі необхідно буде встановити інший SCP, а разом з ним і SMP, у той час як інфраструктура управління та створення послуг, що залишилися в SSCP, стануть непотрібні.
Відмінність між SSCP і SN полягає в тому, що останній не має своїх абонентів і повинен підключатися мовними та сигнальними каналами до комутаційного вузла, пропускаючи через себе всі мовні з'єднання. Крім того, SN не може управлятися від зовнішнього SCP (тобто працювати як автономний SSP), але може підтримувати взаємодію з декількома SSP. При введенні на мережі нових SSP його можна було б залишити як SCP, проте він навряд чи зможе забезпечити необхідну продуктивність для обслуговування більшого рівня трафіка IN. Тому весь SN, найімовірніше, зможе працювати тільки як інтелектуальна периферія, а всю мережу IN необхідно будувати заново. У табл. 1 наведено порівняльний аналіз варіантів побудови платформи IN.
3 Частково розподілена архітектура побудови IN
Проміжною між централізованою та класичною архітектурою IN є частково розподілена платформа. Однією з таких конфігурацій IN є архітектура з винесеними з вузла послуг функціями SSP (рис. 7). Така побудова IN дозволить забезпечити обробку більшого трафіка і є вірним рішенням із впровадження послуг IN для тих операторів, які мають на своїй мережі станції з функціями SSP, що підтримують протокол INAP.
Рисунок 7 – Платформа IN із винесеними функціями SSP
Тут функції комутації та управління викликами виконуються станціями, а їхня взаємодія із платформою IN здійснюється протоколом INAP. Така архітектура вигідно відрізняється від централізованої економією ємності комутаційного поля та кількості мовних каналів при наданні послуг IN. Вона здатна підтримувати великий пакет послуг без будь-яких помітних обмежень.
Таблиця 1 – Порівняльний аналіз способів побудови платформи IN
| Переваги при початковому впровадженні | Недоліки у т.ч. при розвитку мережі |
| SSCP (CCAF, CCF, SSF, SRF, SCF, SDF) | |
| § Швидкість розгортання платформи, завдяки функціональній аналогічності з автономними SSP і SCP | § Неможливість взаємодії з іншими SSP як SCP (тобто SSCP трансформується в SSP) |
| § Відсутність необхідності в мережі СKC №7 | § Необхідність нового обладнання з функціями SCF, SMF і SCEF |
| § Мінімум початкових інвестицій | § Функції SCF, SMF і SCEF, наявні в SSCP, залишаються незатребуваними |
| | § Недостатня надійність |
| SN (CCF, SSF, SRF, SCF, SDF) | |
| § Швидкість розгортання платформи завдяки функціональній аналогічності з автономними SSP і SCP | § Можливість підключення тільки сполучними лініями (немає своїх абонентів), тому всі мовні з'єднання проходять через нього |
| § Можливість взаємодії з декількома зовнішніми SSP | § При взаємодії з іншим SSP як SCP мовні канали мають бути доведені до SN, тому що функції SRF інтегровані |
| § Мінімум початкових інвестицій | § Під час роботи як SCP на мережі з декількома SSP продуктивність недостатня |
| | § Недостатня надійність |
| SSP (СCAF, CCF, SSF, SRF) і SCP (SCF, SDF) | |
| § Гнучкість при нарощуванні продуктивності та функціональності | § Значні початкові капіталовкладення |
| § Простота розвитку | |
| § Надійність, необхідна для мереж загального користування з високим трафіком | |
Досить простим рішенням для впровадження таких послуг IN, де немає необхідності надання мовних повідомлень або існують інші можливості їхньої реалізації, а очікуваний трафік оцінюється як середній, є конфігурація з винесенням функцій IP з платформи (рис. 8).
Функції контролю та адміністративного управління IN розташовуються на єдиній платформі, а функції комутації та управління викликами виконуються на станціях.
Рисунок 8 – Платформа IN із винесеними функціями SSP і IP
Спеціальні ресурси забезпечуються зовнішньою інтелектуальною периферією IP або в обмеженому обсязі можуть надаватися системами комутації. У цьому випадку при зростанні трафіка, числа абонентів або розвитку послуг і необхідності переходу до більш продуктивної системи не потрібно модифікацій у специфікаціях послуг IN або в даних абонентів послуг.
