де
– кількість транзакцій, що забезпечують реалізацію послуги .Значення
визначаються виходячи зі сценаріїв послуг або задаються у вихідних даних згідно з існуючою статистикою.Частина послуг вимагає для свого виконання передачі деяких статистичних даних. Позначимо через
відсоток кожної з послуг , що вимагає передачі додаткової статистичної інформації. Середня кількість транзакцій на одну послугу, з урахуванням передачі необхідної статистики: (5)Середня кількість транзакцій, що здійснюються в одну секунду, з урахуванням передачі статистичних даних:
(6)Зазначена інтенсивність здійснення транзакцій є основою для розрахунку необхідної кількості ланок системи СКС №7 між SSP і SCP.
Припустимо, що кожна транзакція містить
ЗНСО, що передаються в одному напрямку ланкою СКС.Середня тривалість передачі групи ЗНСО, що передаються в одному напрямку протягом однієї транзакції
(7)де
– середня тривалість ЗНСО.Позначимо середню довжину пакета, що передаються протягом однієї транзакції в одному напрямку каналом СКС №7 як
, а середню довжину ЗНСО, виражену в байтах, як .Кількість
значущих сигнальних одиниць, що передається в одному напрямку протягом однієї транзакції: (8)Значення
і зазвичай задаються в межах 140 і 53 байта відповідно, виходячи з наявних статистичних даних.Крім ЗНСО в каналі існує потік СЛСО з інтенсивністю
, що практично не залежить від запитів, які надходять на послугу IN. Зазначені СЛСО використовують для управління мережею, вони мають більш високий пріоритет, ніж пріоритет ЗНСО. Нарешті, весь вільний час, що залишився, у каналі заповнюється потоком ЗПСО, з інтенсивністю .Тривалість передачі СО залежить від їхньої довжини та швидкості передачі інформації в каналі
. Якщо позначити як , і відповідні середні довжини сигнальних одиниць ЗНСО, СЛСО і ЗПСО, виражені в байтах, то тривалість передачі цих СО становитиме відповідноШвидкість передачі інформації
у каналі СКС №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, з іншого.
Рисунок 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.