Кветный Р.Н. и др. Методология построения систем контроля и мониторинга цифровых телекоммуникационных сетей (укр. язык)

Подождите немного. Документ загружается.

140

5.3. Модель обробки даних первинного цифрового потоку

та визначення часу подій в системі моніторингу

Період передачі даних в ПЦП складає



T =125 мкс. Період за-

дає сигнал фреймової синхронізації, що передають в початковому

(нульовому) байті серії із 32-х байт. Блоки інтерфейсу з ПЦП стандар-

ту Е1/Т1 (рис. 5.1) виділяють фреймову синхронізацію і передають її

разом з послідовними цифровими даними блокам PST. При цьому

можливий зсув фаз





між фреймовими сигналами у зовнішній ана-

логовій лінії і внутрішній цифровій лінії, що може досягати половини

періоду -





T5.0

max





. Сигнали фреймової синхронізації через блоки

PST, Buffer RAM та CU ініціюють переривання програми DSP.

Програма, що обслуговує дане переривання, фіксує, по яких

ПЦП сталося оновлення даних, що потрібно обробити і передати на

нижній рівень бази даних. Момент надходження переривання фіксу-

ється за допомогою таймера і тому в подальшому момент часу, коли

був прийнятий пакет сигнального повідомлення, не залежить від мо-

менту завершальної обробки. Єдину затримку у фіксацію моменту

надходження переривання може внести інше переривання, що посту-

пило раніше. Тому програма DSP, що обробляє переривання, виконана

таким чином, що за допомогою системи прапорців вона фіксує події

за мінімальний час і передає їх на обробку основній програмі. Основ-

на програма сканує стан прапорців і виконує дії, що відповідають по-

діям, зазначеним піднятими прапорцями. В результаті максимальний

час обробки переривань DSP з тактовою частотою 160 МГц не пере-

вищує





int

t 2 мкс.

Визначення часу фреймового переривання виконується шля-

хом зчитування таймера, що працює в межах однієї секунди з розпо-

дільчою здатністю 1 мкс. - 999999.0...0



mks

T с. Даний час в сумі з ча-

сом, що надходить від приймача точного часу щосекунди

sec

T , визна-

чає астрономічний час прийому сигнального повідомлення як

mksrec

TTT





sec

Робота таймера синхронізується сигналом 1PPS (рис. 5.1). Дані

про порядковий номер секунди

sec

T надходять від приймача точного

часу по входу блока таймера Serial Time. Вхід-вихід таймера

Synchronization призначений для взаємної синхронізації КЛС в АСТС.

Синхронізація таймера виконується таким чином: якщо таймер досяг

граничного значення раніше приходу чергового імпульсу сигналу

1PPS, то таймер зупиняється і по приходу сигналу 1PPS переходить в

141

початковий стан. Якщо раніше прийшов сигнал 1PPS, то він перево-

дить таймер в початкове положення.

Дані про

sec

T поступають послідовно згідно з протоколом

RS232 у проміжках між сигналами 1PPS з випередженням на одну се-

кунду. Дані накопичуються в буфері таймера і по сигналу 1PPS ста-

ють черговим відліком астрономічного часу. Таймер синхронізується

кварцевим резонатором із параметром стабільності не більше 30 РРМ.

За одну секунду його максимальне відхилення від номінального зна-

чення може скласти до 30 мкс. Тому середня похибка визначення

mks

протягом секунди складає





mks

T 15 мкс. Таким чином, максимальна

похибка визначення часу прийому сигнального повідомлення може

бути визначена як

5,79

intmax

















mks

Ttt



мкс, (5.1)

що менше встановленого вище граничного значення 0,1 мс.

Для зменшення похибки (5.1) передбачена можливість синхро-

нізації всіх таймерів інтерфейсних модулів частотою



f 2048 МГц,

що виділена із одного з ПЦП і може бути підключена по входу-виходу

Synchronization. У даному режимі, що встановлюється опціонально,

кожні 125 мкс. синхронно з фронтом частоти

f таймер збільшує своє

значення на 125, а на протязі періоду

f збільшує своє значення син-

хронно з частотою резонатора. В результаті максимальна похибка ви-

значення

mks

T складає 3,75 нс і тому у виразі (5.1)

mks



можна опус-

тити, тоді





мкс. Частота

f може бути підключена до відпові-

дного входу таймера всіх ІМ пристрою, даний вхід працює в режимі

виходу, коли він генерує

f , режим визначається автоматично. Даний

підхід дозволяє синхронізувати роботу таймерів інтерфейсних моду-

лів у системі.

В разі втрати або відсутності сигналу 1PPS один із ІМ стає ге-

нератором секундної синхронізації – той же модуль, що генерує

f . В

даному випадку час

sec

T може означати як астрономічну величину, так

і відносну – з моменту включення пристрою.

5.4. Керування навантаженням у мережі зі спільноканаль-

ною сигналізацією

Розглянемо задачу керування навантаженням у мережі зі спі-

льноканальною сигналізацією СКС7 при наданні послуг по протоко-

лам високого рівня (level 4-7 OSI: transport; session; presentation;

application) та спосіб, що реалізовано в режимі фільтра-ретранслятора.

Обробка одного повідомлення із врахуванням пошуку абонента

142

(routing) може бути в межах 300 мс – 1-2 с. Тому застосування фільт-

рів небажаних повідомлень, що визначають оператори та користувачі,

може значно підвищити ефективність роботи обладнання зв’язку. Для

виконання функції фільтра сигнальних повідомлень КЛС включають у

розриві ланки сигналізації. У такому режимі КЛС працює як ретранс-

лятор симетрично розташованих входів і виходів, всі прийняті і від-

правлені повідомлення фіксує в базі даних моніторингу.

Задача фільтрації та узгодження з протоколом вирішена тим,

що фільтр-ретранслятор передає дані з однієї сторони розриву ланки

до іншої і по заданих параметрах фільтрує повідомлення про запити

на послуги. Відфільтровані повідомлення протоколів високого рівня

(четвертого-сьомого) із запитами на послуги, що заборонені, фільтр

фіксує, присвоює ідентифікаційні індекси і для подальшої передачі

замінює їх повідомленнями низького рівня (для СКС7 - третього) тес-

тового або інформаційного характеру з номерами в послідовності пе-

редачі відфільтрованих повідомлень без порушення послідовності в

нумерації і з ідентифікаційними індексами в якості параметра. При

отриманні повідомлень відповідей низького рівня від протилежного

пункту сигналізації контрольованої ланки по повернених ідентифіка-

ційних індексах фільтр знаходить повідомлення, що були замінені, і

на протилежну сторону розриву передає за номерами в послідовності

передачі отриманих повідомлень відповідей низького рівня відповідні

забороненим запитам повідомлення відповіді, що містять відмову в

послузі із вказівкою причини, що не приведе до повторного запиту

послуги [75].

Рис. 5.5. Схема роботи фільтра-ретранслятора

143

На рис. 5.5 представлена схема фільтрації повідомлень при

здійсненні запиту на передачу SMS. Передачу повідомлень SMS ви-

конують двома сесіями транзакцій під керуванням підсистем SCCP

[107-110] і TCAP [111-115]. Першою транзакцією термінал запитує

сервіс-центр про абонента, котрому треба направити SMS – передає

пакет із запитом “Send routing info for SM”, що фільтр транслює в

центр. Якщо абонент присутній у мережі, то центр передає повідом-

лення з кодом IMSI (International Mobile Subscriber Identification code),

яке фільтр передає терміналу. Якщо абонент недоступний, то замість

IMSI центр передає повідомлення, що містить код помилки – причину

відмови. У наступній транзакції здійснюється передача повідомлення

SMS від термінала до центра і від центра до абонента. Задача фільтра-

ретранслятора полягає в тому, щоб пропускати запити “Send routing

info for SM” тільки зареєстрованих користувачів мережі і переривати

запити випадкових користувачів і користувачів без прав доступу. Для

цього фільтр містить “білий” або “чорний” списки адрес сервіс-

центрів, що відповідно володіють і не володіють правами доступу.

Коли прийнято фільтром повідомлення запиту на транзакцію і фільтр

установив, що адреса з “чорного” списку або не присутня у “білому”

(роботу фільтра по списках настроює оператор по даних моніторингу),

то замість запиту фільтр передає центру повідомлення SLTM з номе-

ром у послідовності передачі, що відповідає відфільтрованому пові-

домленню - NT. Повідомлення SLTM належить до підсистеми SNTM

третього рівня підсистеми МТР СКС7. Дане повідомлення використо-

вують для тестування адресних етикеток двох пунктів ланки сигналі-

зації. Повідомлення містить код етикетки пункту сигналізації, що по-

силає повідомлення (OPC), код етикетки пункту, якому воно призна-

чено (DPC), ідентифікатори типу ланки і мережі, поле коду тесту (Test

Pattern), що пункт призначення повертає у повідомленні-відповіді

SLTA. Даний тест є обов'язковим при входженні ланки в зв'язок, тому

що він погодить роботу пунктів сигналізації по третьому рівню МТР.

Пункти сигналізації періодично виконують даний тест. Відповідь по-

відомленням SLTA на SLTM і повернення поля коду тесту є обов'яз-

ковим, інакше пункт, що не одержав підтвердження тесту, припиняє

нормальну роботу. Довжина SLTM і SLTA залежить від довжини поля

Test Pattern, що не має жорсткого обмеження. Усі повідомлення в ме-

режі проходять у пункті сигналізації перевірку адресних етикеток, то-

му тест SNTM (обмін SLTM і SLTA), можна розглядати як звичайний

запит послуги і відповідь на неї, але послуга носить тривіальний хара-

ктер, підсистеми надання послуг по ній не виконують будь-яких дій.

Тому повідомлення запиту транзакції, що заборонено, фільтр-

ретранслятор заміняє тривіальною транзакцією. Кожній забороненій

144

транзакції фільтр привласнює ідентифікатор, що у повідомленні

SLTM передає як Test Pattern, відмінний від Test Pattern, що викорис-

товують у контрольованій ланці сигналізації. При одержанні підтвер-

дження тесту фільтр по його Test Pattern ідентифікує запит і формує

повідомлення терміналу, що містить код помилки, наприклад

“Subscriber absent”, фільтр передає його замість SLTA, але з тим же

послідовним номером - NR. Після отримання такого повідомлення те-

рмінал не стане повторювати запит.

Якщо під час передачі повідомлення SLTM відбувся збій, то

центр виявить порушення послідовності номерів NT і запросить по-

вторну передачу, фільтр ретранслює запит терміналу, котрий повто-

рить передачу фільтрованого повідомлення високого рівня, по якому

фільтр відновить повторну передачу SLTM. Якщо при прийомі SLTA

відбувся збій, то порушення послідовності номерів NR викличе запит

повторної передачі з боку термінала, що фільтр ретранслює центру,

центр повторить передачу SLTA. Запити повторної передачі і підтвер-

дження прийому передають ненумеровані повідомлення (FISU), або

наступні в послідовності повідомлення. Аналогічно відбувається об-

робка збоїв з боку термінала. Робота фільтра по кожній транзакції

вважається завершеною, якщо отримано підтвердження на повідом-

лення-відповідь по запиту.

Таким чином, даний спосіб дозволив звільнити центр від однієї

або двох-трьох транзакцій, у яких задіяні 4-6 рівні ОSI. Звичайний час

взаємодії ланки по тесту SNTM складає 20...30 мс, тоді як час однієї

транзакції запиту “Send routing info for SM” і відповіді центра комута-

ції з кодом помилки складає 150...300 мс, а час надання послуги може

скласти секунду і більше. Отже, на одній перерваній транзакції або

послузі можна одержати економію часу від 100 мс. до секунди.

5.5. Загальна архітектура системи

Система моніторингу має ієрархічну структуру і складається з

рівня збору даних та центру моніторингу. В залежності від масштабу

та адміністративної структури служби контролю мережі СКС7. Сис-

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

гіональні центри моніторингу.

На рис. 5.6 представлена трьохрівнева архітектура системи

Рівень збору даних утворюють територіально рознесені лока-

льні пункти моніторингу (ЛПМ). Кожен ЛПМ складається з територі-

ально рознесених пристроїв АСТС, які встановлені безпосередньо на

ланках сигналізації. Кількість контрольованих сигнальних ланок – в

межах від одиниць до сотень. ЛПМ об‘єднані мережею передачі да-

145

них, незалежною від контрольованої мережі СКС7, в якості якої ви-

ступає корпоративна МПД. Крім АСТС в склад ЛПМ також входять:

 додаткові сервери баз даних;

 сервери програмного забезпечення;

 модуль, що приймає архів даних з локального рівня;

 програмно-апаратні модулі МТР, ISUP, сервісу та загально-

го керування.

Незалежна мережа

передачі даних

Рис.5.6. Загальна архітектура системи

Програмне забезпечення ЛПМ на основі інформації із мережі

СКС7 формує статистичні дані про якість, трафік, виклики та ін.

Керування системою моніторингу здійснюється через центр

моніторингу. ПЗ центру моніторингу дозволяє здійснювати контроль

всієї мережі СКС7 в режимі реального часу, адмініструвати систему

моніторингу, проводити аналіз статистики, керувати правами корис-

тувачів, створювати звіти. Діапазон функцій центру обмежується

встановленим програмним забезпеченням.

5.6. Структурна схема системи

На рис.5.7 наведено структурну схему ІВС контролю телеко-

мунікаційних систем на базі аналізу даних СКС7.

На рівні зчитування даних системи розташовані пристрої для

моніторингу (АСТС), що підключені безпосередньо до потоків

2048 мБ/с.

146

онтролер

Контролер

Адаптер інтерфейсу

Сигнальний процесор ПЗ

считування

Трансивер Е1

Одноплатний комп‘ютер

ПЗ декодування

сигнальної інформації

Джерело синхронізації

Ethernet

2048 мБ/с

PCI 104

Рис. 5.7. Структурна схема ІВС

Вони в режимі реального часу збирають інформацію про функ-

ціонування мережі СКС7 та передають її по локальній мережі на рі-

вень обробки даних та запитів.

Інформація про функціонування мережі зберігається на рівні

даних та запитів на сервері СУБД. На сервері ПЗ встановлено програ-

мне забезпечення, за допомогою якого виконується первинна обробка

147

даних, взаємозв'язок із сервером СУБД. Функцію з'єднання локальних

пристроїв моніторингу з VPN (корпоративною мережею) виконує ма-

ршрутизатор. Перемикач дозволяє забезпечити одночасну роботу де-

кількох комп'ютерів з одним набором пристроїв введення-виведення

(миша, клавіатура, монітор). Додатково на цьому рівні присутнє дже-

рело синхронізації, пов‘язане з еталоном часу, за рахунок якого дося-

гається встановлення єдиного часу для всієї системи.

Для захищеної передачі даних використовується віртуальна

приватна мережа.

На рівні відображення та запиту даних розташовані об‘єднані

локальної мережею спеціалізовані робочі місця з розподіленим досту-

пом користувачів та адміністраторів ІВС. На робочих місцях встанов-

лене ПЗ, що відповідає задачам, необхідним для виконання.

Також на цьому рівні знаходиться:

 маршрутизатор;

 комутатор 1Gb;

 комутатор 10\100 Мб;

 сервери ПЗ;

 сервери СУБД.

Також рівень відображення та запитів обладнаний широким ек-

раном, на який виводиться інформація про конфігурацію і стан мережі

СКС7.

5.7. Структура програмного забезпечення

На комп‘ютерах «Аналізатор АСТС» встановлені прилади

АСТС, які є логічним та територіальним об‘єднанням програмно-

апаратних комплексів «АСТС». Таке об‘єднання може включати в се-

бе від одного до десяти АСТС. АСТС виконують контроль стану ме-

режі сигналізації та передачі інформації про стани в центр контролю в

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

трафіка та якості роботи мережі з передачею цієї інформації в базу да-

них.

Аналізатор АСТС є найбільш критичним елементом ІВС, оскі-

льки його простій, непрацеспроможність або нестача ресурсів

комп‘ютера однозначно призводять до втрати даних. Крім того, цей

елемент є елементом ІВС, що масштабується.

АСТС виконує такі функції:

 автоматичний запуск при старті ОС або запуск по команді

«Інспектора програм»;

 автоматичну настройку у відповідності з конфігурацією ІВС

та реконфігурацію по команді «Адміністратора програм»;

148

 автоматичне створювання/відкриття документа/сесії;

 автозбереження документа/сесії;

 динамічне підключення/відключення джерел даних в сесії;

 динамічне реконфігурування документа/сесії у відповіднос-

ті з конфігурацією ІВС;

 довготривалу буферизацію даних, що приймаються та під-

раховуються;

 підготовку даних для ІВС;

 обмін даними з іншими зондами;

 автоматичну очистку дисків від застарілих даних;

 автоматичне підключення до «Адміністратора програм» та

підтримка з‘єднання;

 автоматичне підключення до «Концентратора» та підтримка

з‘єднання;

 автоматичне підключення до «Заповнювача БД» та підтри-

мка з‘єднання;

 підготовка та «змістовна» буферизація даних для відправ-

лення (канал передачі даних у реальному часі);

 підготовка та повна буферизація даних для відправлення до

«Заповнювача БД»;

 отримання точного астрономічного часу.

На серверах програмного забезпечення ЛМП встановлене ПЗ,

що виконує прийом інформації від сервера зондів та її передачу в

центр контролю в режимі реального часу та запис статистичної інфо-

рмації на сервер баз даних ЛПМ.

149

СУБД

Компонент системи

"Сервер зондів"

WAN

ЛПМ 1

. . .

Компонент системи

"Сервер ПЗ"

Socket

АСТС – АСТС

Socket

АСТС – Концентратор RealTime даних

Socket

АСТС – Заповнювач БД

Files

АСТС –Сховище первинних необроблених даних

SQL

Доступ до даних для вторинної обробки (звіти та ін.)

Files

Сервер прямих підключень –Сховище первинних необроблених даних

Socket

Дисплей стану (клієнт) – Сервер прямих підключень

CORBA

Адміністратор програм – Адміністратор програм

CORBA

Менеджер звітів – Менеджер звітів

Socket

Концентратор RealTime даних– Концентратор RealTime даних

SQL

Менеджер

звітів

–

СУБД (статистич

ні

дан

)

Концентратор

RealTime дан

их

Менеджер

звітів

Адміністратор

програм

Компонент системи

"Сервер даних"

Сховище первинних

необроблених

даних

Статистика

ЛПМ N

. ..

Bridge

Се

рвер прям

підключень

Bridge

LAN WAN

Конф

гурац

АСТС

Аналізатор АСТС

АСТС

Аналізатор АСТС

АСТС

Аналізатор АСТС

Запо

внювач

БД

Реплікатор

Архіватор

Рис. 5.8. Архітектура системи. Схема модулів та потоків даних ЛПМ

До складу сервера ЛПМ також входить ПЗ доступу до статис-

тичної інформації на сервері баз даних для виконання звітів. Крім то-