• Перш за все слід перевірити працездатність ланок. Як правило це робиться за допомогою Агента. Для цього слід стати на вкладку Плати і натиснути на код посадки потрібної ланки сигналізації. Виглядає це приблизно так:

Основні елементи:

1. Поле, де можна побачити показник помилок (від 0 до 100%, при 100% відбувається переініціалізація ланки сигналізації) і час останньої відмови ланки сигналізації. Час у форматі доба-год-хв-сек
2. Ідентифікатор ланки сигналізації і тип драйвера, який її обслуговує
3. Відсоток завантаженості ланки сигналізації в момент зчитування даних агентом (підрахунок ведеться кожну повну секунду). 100% означає, що між приймаються лише MSU (жодної FISU на прийомі)
4. Узагальнені помилки, серед яких є:
   1. Ланка неактивна - (статус не InService)
   2. Включено резервування - Станція намагається перенести весь трафік цієї ланки на резервну.
   3. Показник помилок > 10% - Індикатор рівня помилок сигнальних одиниць більший за 10%
   4. Не підтверджено SLTM - Не підтверджено один або кілька посланих станцією тестових повідомлень SLTM
   5. Віддалене блокування - Зустрічна станція застосувала блокування трафіку ланки (Link Inhibit Message)

1. Статус ланки має такі індикатори:
   1. Резервування ланки (ПЕРЕХІД) - Перехідний статус ChangeOver = try to on/ try to off
   2. Резервування ланки - поточний статус ChangeOver = on/off.
   3. Локальне блокування ланки (ПЕРЕХІД) - Перехідний статус по Inhibit = try to on/ try to off
   4. Локальне блокування ланки - Поточний статус по Inhibit = on/off
   5. SLTM не підтверджено ДВІЧІ - Двічі підряд не підтверджено SLTM, якщо за 30 сек не прийде підтвердження, ланку буде перезапущено.
   6. SLTM не підтверджено - Не підтверджено SLTM мінімум один раз
   7. Віддалене блокування - Зустрічна станція застосувала блокування трафіку ланки (Link Inhibit Message)
2. Режим роботи ланки встановлюється оператором функцією Керування ланками сигналізації, має такі індикатори:
   1. Робота з двооктетними LSSU - Передавати лише двооктетні LSSU (по замовчуванню однооктетні)
   2. Заборонено блокування ланки - На всі повідомлення LIN відповідати LID (Link Inhibit Deny)
   3. Congestion discard - не використовується
   4. Трасування взаємодії ланки сигналізації - Ця ланка сигналізації зберігає всі приняті і передані сигнальні одиниці в бортжурнал для наступної обробки програмою Tracer
   5. Режим Local Processor Outage - Вивести з обслуговування ланку, передаючи LSSU SIPO
   6. Аварійний період перевірки - При фазуванні використовувати аварійний час фазування.
   7. Зупинено оператором - Ланку сигналізації зупинено командою оператора
   8. Зупинятися після відмови - Одиночний запуск ланки сигналізації. При будь-якій відмові ланка НЕ буде введена в обслуговування автоматично. (Цей режим дозволяє діагностувати причини відмов).
3. Етап встановлення з'єднання, може приймати такі значення:
   1. Початковий стан (Idle) - може бути, після зупинки ланки в режимі AutoStop. При цьому зберігається причина останньої відмови ланки і причина сигнальної одиниці. Якщо не виставлено режим AutoStop, система не зупиняється на цій фазі і автоматично переходить в OutOfService. В стані Idle ланка передає LSSU (SIOS) і не обробляє прийнятих сигнальних одиниць.
   2. Не обслуговується (OutOfService) - Проміжний стан тривалістю T17, коли передається LSSU (SIOS) все, що на прийомі - відкидається. Через час T17 ланка переходить в стан Not Aligned
   3. Відмова процесора (ProcessorOutage) - Бойова робота, але оператор виставив режим Local Processor Outage. Ланка виведена з обслуговування.
   4. Відмова обох процесорів (BothProcessorOutage) - Локально і віддалено виставлено режим Processor Outage
   5. Не зфазований стан (NotAligned) - Передається LSSU (SIO) і чекається на прийомі LSSU (SIO/SIN/SIE) протягом часу T3. Якщо немає потрібних сигнальних одиниць, переходимо в Idle. Якщо є - в Aligned
   6. Зфазований стан (Aligned) - Починається передача LSSU (SIE або SIN), на прийомі чекаємо LSSU (SIE/SIN). Якщо отримуємо LSSU (SIOS) - в Idle. Якщо LSSU (SIN/SIE) - в Proving
   7. Перевірка каналу (Proving) - Підрахунок правильно прийнятих сигнальних одиниць. При великій кількості зіпсутих сигнальних одиниць - AERM Error Notified. Якщо все гаразд - переходимо в стан AlignedReady. Якщо приймаємо SIOS - в Idle, якщо SIO - в Aligned.
   8. Готовий до роботи (AlignedReady) - Починаємо передавати FISU. Чекаємо FISU, MSU, SIO, SIPO. При отриманні FISU, MSU переходимо в InService
   9. Зфазований НЕ ГОТОВИЙ - Під час фазування виставлено режим Local Processor Outage. Передаємо LSSU (SIPO). Це можливо лише в режимі LocalProcessorOutage, встановлений по команді оператора.
   10. Відмова віддаленого процесора - Передаємо FISU, приймаємо SIPO. Remote Processor Outage
   11. Нормальна робота (InService) - Передаємо FISU,MSU, приймаємо FISU,MSU. Ланка введена в обслуговування.
4. Причина останньої відмови ланки, може приймати такі значення:
   1. Немає даних - не потребує пояснення
   2. Спрацював таймер T1 - Не закінчився вчасно стан AlignedReady
   3. Спрацював таймер T2 - Не закінчився вчасно стан NotAligned
   4. Спрацював таймер T3 - Не закінчився вчасно стан Aligned
   5. Спрацював таймер T6 - Отримуємо SIB надто довго
   6. Спрацював таймер T7 - Надто довго немає підтвердження переданих сигнальних одиниць
   7. AERM Error Notified - Під час фазування виявлено неприпустимо великий рівень зіпсутих сигнальних одиниць
   8. SUERM Error Notified - Під час роботи виявлено неприпустимо великий рівень зіпсутих сигнальних одиниць
   9. Отримано команду вiд вiддаленої системи - Прийнято LSSU (SIO або SIOS)
   10. Отримано команду вiд оператора - Оператор виконав команду Stop
   11. Два помилкових FIB пiдряд - Прийнято дві сигнальні одиниці підряд, в яких невірне значення поля FIB
   12. Два помилкових BSN пiдряд - Прийнято дві сигнальні одиниці підряд, в яких невірне значення поля BSN
   13. Два не пiдтверджених SLTM - Двічі підряд не отримано підтвердження SLTM. (Повинно прийти SLTA)
   14. Перервана передача Broken Tx Path - Надто довго не прийнято жодної сигнальної одиниці.
5. Причина ігнорування сигнальної одиниці
   1. Немає даних - не потребує пояснення
   2. Не спiвпадає Network Indicator - Network Indicator SLTM або SLTA не відповідає індикатору цієї ланки сигналізації
   3. Не спiвпадає DPC з нашим - У принятому повідомленні SLTM або SLTA не відповідає DPC з присвоєним цій станції
   4. Не спiвпадає OPC з сусiднiм - У принятому повідомленні SLTM або SLTA не відповідає OPC з присвоєним сусідній станції
   5. Не Знайдено вiдповiдний ChannelSet - Не знайдено обробника повідомлення верхнього рівня, або не оголошено маршруту для транзитного повідомлення.
   6. Не спiвпадає SLC в SLTM/SLTA - В принятому повідомленні SLTM або SLTA поле SLC не відповідає кодові ланки сигналізації
   7. Не спiвпадає Test Pattern в SLTA - В принятому повідомленні SLTA Test Pattern не відповідає переданому в SLTM
   8. Не реалiзована пiдсистема користувача - Принято повідомлення для нереалізованої підсистеми користувача
   9. Помилка в iндикаторi довжини MSU - Довжина сигнальної одиниці не відповідає полю Length Indicator
   10. Невiдоме повiдомлення MTN - Повідомлення підсистеми SNMP неможливо обробити
   11. CIC не включений в TonalSet - Принято повідомлення для каналу, якого не існує
   12. Не Ss7-сумiсний канальний драйвер - Помилка в таблиці ліній. Драйвер не пакетного типу.
   13. Неправильний формат сигнальної одиниці - Помилки в сигнальній одиниці
   14. Не знайдено ланки для повiдомлення 3 рiвня - При спробі передати сигнальну одиницю не виявлено жодної придатної для цього ланки сигналізації
   15. Локальна відмова блокування ланки сигналізації - Оператор зробив спробу заблокувати останню доступну ланку сигналізації
   16. Віддалена відмова блокування ланки сигналізації - Сусідня станція зробила спробу заблокувати останню доступну ланку сигналізації
6. Інформація рівня MTP-2 - значення полів останніх прийнятих і переданих сигнальних одиниць
7. Ланка сигналізації, яку відображає детальна інформація.

Використовуючи цю інформацію можна визначити основні проблеми при помилках в роботі ланок сигналізації. Аналізувати роботу протоколу ISUP немає змісту, поки не працює ланка сигналізації.

• Якщо ланка працює, слід перевірити можливість проведення вхідних та вихідних зі станції викликів. На цьому етапі можна скористуватися звичайним трасуванням. По ньому можна визначити передані і прийняті каналом пакети на рівні MessageType. Типовий приклад такого трасування наведено нижче.

Agent Версія 4.3 (Tue Mar 27 22:07:14 2007)
  Файл трасування лінії
 
Станція : Apr20Qpa
Лінія ySs7 A011 #0001 ІКМ-30 / Ss7 двонаправлена цифрова лінія
 
Початок трасування : 30 Январь 2008 г. 16:17:45 (Користувач: amc)
 
#0001 Виклик   50062>............. ySs7 A01E  3248400613 C0 [----/----]
 
                    T B B B  B B B B  R B B B B B B B 
                    r i i i  i i i i  c i i i i i i i 
                    n t t t  t t t t  L t t t t t t t                Трива-
  Час    Стан       M 6 5 4  3 2 1 0  3 6 5 4 3 2 1 0  Підключено    лість
  0.000  Чекає      - - - -  - - - -  - - - - - - - -  0000Hz        14.032
 14.032  Чекає      - - - -  - - - -  1 - - - - - - 1  0000Hz         0.008
 14.040  Чекає      - - - -  - - - -  - - - - - - - -  0000Hz         0.056
 14.096  Номер->    1 - - -  - - - 1  - - - - - - - -  0000Hz         0.008
 14.104  Номер->    - - - -  - - - -  - - - - - - - -  0000Hz         0.208
 14.312  Номер->    - - - -  - 1 1 -  - - - - - - - -  0000Hz         0.008
 14.320  Номер->    - - - -  - - - -  - - - - - - - -  0000Hz         0.032
 14.352  Виклик     - - - -  - - - -  - - - - - - 1 1  0000Hz         0.008
 14.360  Виклик     - - - -  - - - -  - - - - - - - -  0000Hz         4.096
 
Кінець трасування : 30 Январь 2008 г. 16:18:04 (Користувач: amc)
 
#0001 Виклик   50062>...........10 ySs7 A01F  3248400613 C0 [----/----]

З цього трасування можна визначити, що зроблене воно на лінії A011 типу ySs7. Взаємодія ISUP показана в колонці після Стану (для сигналізацій по CAS в ній відображаються приняті і передані СУВи). Для сигналізації ySs7 ці два поля об'єднані і в нах відображаються приняті і передані повідомлення (MessageTypes). Старший біт поля визначає, чи повідомлення передане в напрямку зустрічної станції, чи це приняте від неї повідомлення (0(риска) - приняте, 1 - передане). Решта бітів представляють собою двійковий код повідомлення, перелік можливих варіантів якого можна знайти в довіднику. Приклади розкодованих рядків:

14.096  Номер->    1 - - -  - - - 1  - - - - - - - -  0000Hz         0.008
                   ^^^^^^^^^^^^^^^^
                   ||||||||||||||||
                   Тип повідомлення = 1(передане) + 0000001(IAM)

14.312  Номер->    - - - -  - 1 1 -  - - - - - - - -  0000Hz         0.008
                   ^^^^^^^^^^^^^^^^
                   ||||||||||||||||
                   Тип повідомлення = 0(приняте) + 0000110(ACM)

Таким чином можна відслідкувати взаємодію одного окремого каналу за допомогою трасування Агента. Наявність в трасуванні повідомлення не гарантує, що воно передалося саме тією ланкою сигналізації, яку Ви для цього визначили (наприклад в результаті помилки в таблиці маршрутизації).

• Якщо ж необхідно провести більш детальне трасування взаємодії ланки сигналізації, необхідно використовувати програму Tracer. Вона дозволяє трасувати всі сигнальні одиниці, приняті і передані ланкаю сигналізації, в тому числі FISU, LSSU, і сигнальні одиниці з неправильною контрольною сумою на прийомі. Крім того ця програма декодує всі сигнальні одиниці. Тому за допомогою неї можна отримати набагато більше інформації, ніж з трасування Агента.