ТЕМА
Аналіз варіантів побудови платформи інтелектуальнихмереж (IN)
Вступ
Очевидно, що чимкраща мережа зв'язку оператора, тим більш ефективну платформу для наданняпослуг інтелектуальної мережі можна створити на її базі. На якість наданняпослуг IN впливають такі характеристики базової мережі: по-перше, технічніпристрої, такі як прикінцеві та транзитні комутаційні системи, системипередачі, абонентські мережі доступу, вузли SCP і SSP, і по-друге, засобиадміністративного управління та технічної експлуатації послуг.
Створенняплатформи IN полегшується наявністю на мережі таких основних атрибутів:
- системисигналізації СКС №7;
- цифровихсистем комутації на всіх рівнях до прикінцевого;
- цифровихсистем передачі;
- можливостівикористання телефонних апаратів із тональним набором;
- можливостіідентифікації лінії викликаючого абонента;
- обладнанняодного виробника;
- системдокладного обліку вартості;
- організації,що здійснює маркетинг і обслуговування послуг зв'язку.
Оператор може початистворення платформи IN, не маючи жодного з наведених атрибутів, проте, чимбільше з цього переліку він має, тим швидше та дешевше обійдеться створенняплатформи.
Система сигналізаціїСКС №7 у більшості застосувань обов'язково потрібна для взаємодії між вузламиSCP і SSP. Специфікація інтерфейсу між SCP і SSP є найбільш важливою частиноюстандартизації IN. Рекомендований ITU-T спосіб перенесення сигналізації на цьому інтерфейсі – використанняпротоколів TCAP/INAP, що cпираються на системи сигналізації СКС №7SCCP/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 зазвичай використовують одночасно кількаланок СКС.
Припустимо, що мережа надає /> різних послуг.
Кількість користувачів послуги /> становить />. Кількість запитів напослугу />,що надходить від одного користувача в ЧНН (інтенсивність надходження запитів),становить />.
Тоді інтенсивності надходження запитів на послугу /> у ЧНН від усіх /> користувачівдорівнює
/> (1)
Сумарнаінтенсивність надходження запитів на всі види послуг, задіяних у мережі
/> (2)
Імовірності появи запиту на послугу />
/> (3)
Середня кількість транзакцій на одну послугу:
/> (4)
де /> –кількість транзакцій, що забезпечують реалізацію послуги />.
Значення /> визначаються виходячи зісценаріїв послуг або задаються у вихідних даних згідно з існуючою статистикою.
Частина послуг вимагає для свого виконання передачі деяких статистичнихданих. Позначимо через /> відсоток кожної з послуг />, що вимагаєпередачі додаткової статистичної інформації. Середня кількість транзакцій наодну послугу, з урахуванням передачі необхідної статистики:
/> (5)
Середня кількість транзакцій, що здійснюються в одну секунду, з урахуванням передачістатистичних даних:
/> (6)
Зазначенаінтенсивність здійснення транзакцій є основою для розрахунку необхідноїкількості ланок системи СКС №7 між SSP і SCP.
Припустимо, що кожна транзакція містить /> ЗНСО, що передаються в одномунапрямку ланкою СКС.
Середнятривалість передачі групи ЗНСО, щопередаються в одному напрямку протягом однієї транзакції
/> (7)
де /> –середня тривалість ЗНСО.
Позначимо середню довжину пакета, що передаються протягом однієїтранзакції в одному напрямку каналом СКС №7 як />, а середню довжину ЗНСО, вираженув байтах, як />.
Кількість /> значущих сигнальних одиниць, щопередається в одному напрямку протягом однієї транзакції:
/> (8)
Значення /> і /> зазвичай задаються в межах 140 і53 байта відповідно, виходячи з наявних статистичних даних.
Крім ЗНСО в каналі існує потік СЛСО з інтенсивністю />, що практично незалежить від запитів, які надходять на послугу IN. Зазначені СЛСОвикористовують для управління мережею, вони мають більш високий пріоритет, ніжпріоритет ЗНСО. Нарешті, весь вільний час, що залишився, у каналі заповнюєтьсяпотоком ЗПСО, з інтенсивністю />.
Тривалість передачі СО залежить від їхньої довжини та швидкості передачіінформації в каналі />. Якщо позначити як />, /> і /> відповідні середнідовжини сигнальних одиниць ЗНСО, СЛСО і ЗПСО, виражені в байтах, то тривалістьпередачі цих СО становитиме відповідно
/> , /> , /> (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, з іншого.