Аналіз варіантів побудови платформи інтелектуальних мереж (IN) (стр. 1 из 3)

ТЕМА

Аналіз варіантів побудови платформи інтелектуальних мереж (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 зазвичай використовують одночасно кілька ланок СКС.

Припустимо, що мережа надає

різних послуг.

Кількість користувачів послуги

становить . Кількість запитів на послугу , що надходить від одного користувача в ЧНН (інтенсивність надходження запитів), становить .

Тоді інтенсивності надходження запитів на послугу

у ЧНН від усіх користувачів дорівнює

(1)

Сумарна інтенсивність надходження запитів на всі види послуг, задіяних у мережі

(2)

Імовірності появи запиту на послугу

(3)

Середня кількість транзакцій на одну послугу:

(4)