63892 (695490), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Тривалість передачі СО залежить від їхньої довжини та швидкості передачі інформації в каналі . Якщо позначити як , і відповідні середні довжини сигнальних одиниць ЗНСО, СЛСО і ЗПСО, виражені в байтах, то тривалість передачі цих СО становитиме відповідно

, , (9)

Швидкість передачі інформації у каналі СКС №7 становить 64 кбіт/с. Кількість ланок СКС №7 між SSP і SCP визначається виходячи з максимально припустимого завантаження каналу СКС , значення якого вибирається в межах

(10)

Отримане значення необхідно округлити до найближчого більшого цілого числа.

Інтенсивність надходження транзакцій у розрахунку на одну ланку СКС№7

(11)

є однією з основних характеристик працездатності ланки.

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.

3 Частково розподілена архітектура побудови IN

Проміжною між централізованою та класичною архітектурою IN є частково розподілена платформа. Однією з таких конфігурацій IN є архітектура з винесеними з вузла послуг функціями SSP (рис. 7). Така побудова IN дозволить забезпечити обробку більшого трафіка і є вірним рішенням із впровадження послуг IN для тих операторів, які мають на своїй мережі станції з функціями SSP, що підтримують протокол INAP.

Рисунок 7 – Платформа IN із винесеними функціями SSP

Тут функції комутації та управління викликами виконуються станціями, а їхня взаємодія із платформою IN здійснюється протоколом INAP. Така архітектура вигідно відрізняється від централізованої економією ємності комутаційного поля та кількості мовних каналів при наданні послуг IN. Вона здатна підтримувати великий пакет послуг без будь-яких помітних обмежень.

Таблиця 1 – Порівняльний аналіз способів побудови платформи IN

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

Функції контролю та адміністративного управління IN розташовуються на єдиній платформі, а функції комутації та управління викликами виконуються на станціях.

Рисунок 8 – Платформа IN із винесеними функціями SSP і IP

Спеціальні ресурси забезпечуються зовнішньою інтелектуальною периферією IP або в обмеженому обсязі можуть надаватися системами комутації. У цьому випадку при зростанні трафіка, числа абонентів або розвитку послуг і необхідності переходу до більш продуктивної системи не потрібно модифікацій у специфікаціях послуг IN або в даних абонентів послуг.

Характеристики

Список файлов реферата