Навигация
Централізована архітектура побудови IN
18279
знаков
1
таблица
8
изображений
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
Після введення нового SSP раніше розгорнутий SSCP може функціонувати вже тільки як SSP, отже на мережі необхідно буде встановити інший SCP, а разом з ним і SMP, у той час як інфраструктура управління та створення послуг, що залишилися в SSCP, стануть непотрібні.
Відмінність між SSCP і SN полягає в тому, що останній не має своїх абонентів і повинен підключатися мовними та сигнальними каналами до комутаційного вузла, пропускаючи через себе всі мовні з'єднання. Крім того, SN не може управлятися від зовнішнього SCP (тобто працювати як автономний SSP), але може підтримувати взаємодію з декількома SSP. При введенні на мережі нових SSP його можна було б залишити як SCP, проте він навряд чи зможе забезпечити необхідну продуктивність для обслуговування більшого рівня трафіка IN. Тому весь SN, найімовірніше, зможе працювати тільки як інтелектуальна периферія, а всю мережу IN необхідно будувати заново. У табл. 1 наведено порівняльний аналіз варіантів побудови платформи IN.
Похожие работы
... СРСР, а також у Німеччині, Іспанії, Гонконгу, Південній Кореї, Бразилії, Єгипті та ін. Широке поширення одержало комплексне рішення компанії Huawei з побудови інтелектуальних мереж TELLIN. Ця платформа є повним комплектом обладнання та сучасних технічних засобів для побудови IN у повній відповідності до міжнародних стандартів і рекомендацій організацій ITU-T і ETSI. Вперше IN TELLIN з'явилася на ...
... розвитку телефонної мережі та потреб її абонентів у послугах IN адміністрація цієї мережі може прийняти один з описуваних вище варіантів початкового розгортання інтелектуальної мережі та організації доступу до неї. З урахуванням перерахованих вище існуючих критеріїв вибору, принципів побудови та плану нумерації ТМЗК України, а також можливостей АТС електромеханічних систем, можливі два основних ...
... ідеальних напруг приймальних каналів U, які вільні від ефекту взаємного впливу, вирішується система: , (27) де - вектор реальних напруг приймальних каналів, отриманих після аналого-цифрового перетворювача (АЦП) без проведення корекції. З метою компенсації взаємного впливу, розв’язання системи (12) здійснюється за методом найменших квадратів з мінімізацією функц ...
... та модернізації переліку послуг, в основу проекту були покладені принципи, аналогічні принципам конструювання послуг інтелектуальної мережі. 2. Системи комп'ютерної телефонії фірми «Беркут» Науково-виробнича фірма «Беркут» (Санкт-Петербург) є виробником широкого спектра систем телекомунікаційного обладнання, розроблюваних на базі власної платформи комп'ютерної телефонії та прикладного ПЗ. ...
0 комментариев