Главная  Классификация протоколов сигнализации 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [ 11 ] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169]


Рис.2.17. Описание попытки установления соединения при занятости соединительных путей

В данном MSC-описании определены процесс OTLOC обработки сигналов; сообщения NEWCALL (новый вызов), SEIZURE (занятие), АСК (подтверждение занятия), BNUMBER (номер абонента Б), CONGESTION (занятость промпугей), REJECT (отказ), DISCONNECT (разъединение), RELEASEGUARD (контроль исходного состояния), IDLE (исходное); вентили 1, 6, 9 к программному обеспечению обработки вызовов и все остальные к физическому уровню интерфейса с соединительной линией; тайм-ауты Т1 (ожидание поступления подтверждения занятия) и Т2 (время непроизводительного занятия соединительной линии).

Текстовое представление данного описания выглядит следующим образом:

instance OTLOC; L inNEWCALL

2. out SEIZURE setTI

setT2

3. in ACK reset Tl

4. out BJMUMBER

5. in CONGESTION reset T2

6. out REJECT

7. out DISCONNECT

8. in RELEASEGUARD

9. out IDLE end instance end MSC

Недостаток такого описания заключается в его линейном характере и в невозможности представить на одной диаграмме ветвление алгоритма.

Для того, чтобы представить процесс при различных возможных сценариях, используется так называемая обзорная диаграмма MSC, иногда называемая «дорожной картой». На ней представляются все MSC-сценарии и так называемые условия. Упрощенная «дорожная карта» процесса OTLOC обработки сигналов для протокола сигнализации 2ВСК по соединительной линии ГТС из предыдущего примера представлена на рис. 2.18. MSC-сценарии показаны прямоугольниками, а условия - шестиугольниками.



Разъединение

Линия свободна

~~Г~

Отказ

Занятие

УТ1редответноеЧ N. состояние

Разъединение

Тайм-а/т

Отбой А

Ответ

Разъединение

/ Ожидание \ Чраэъед мнения/

♦- Разговор \*

Отбой Б

Рис. 2.18. Упрощенная обзорная диаграмма MSC обмена сигналами по соединительной линии ГТС Подобная карта близка к более широко применяемому методу описаний-граф-схеме алгоритма и позволяет легко перейти от набора МЗСсценариев к SDL-диаграмме, поскольку условия можно представить в виде SDL-состояний, а MSC-сценарии представляют собой последовательности сигналов, переводящих процесс из состояния в состояние, и задач, выполняемых при этих переходах.

При этом отдельные MSC-сценарии, представленные на «дорожной карте» в виде прямоугольников, могут входить в конкретные сценарии типа изображенной на рис. 2.17 MSC-процедуры.

К достоинствам описания процессов при помощи MS С относятся исключительная наглядность и легкость, с которой могут быть проверены протоколы, специфицированные таким методом. Достаточно сказать, что тестовые сценарии получаются путем слияния MSC-спецификаций разрабатываемого процесса и имитатора протокола.

Именно подобным образом разработаны протокол-тестеры российских систем сигнализации, используемые для отладки программного обеспечения цифровых АТС, предназначенных к установке на телефонных сетях СНГ. и рассмотренные в заключительной главе книги.

Это может быть проиллюстрировано на приведенном выше примере сценария MS С Cong на рис. 2.17. Тестирование выполнения данной спецификации должно осуществляться имитатором протокола по сценарию MSC Sim, изображенному на рисунке 2.19.

MSG Cong SIM

SIG SIM

Ч SEIZURE -

SZIND ,

Ч ACK

B NUMBER

CONGESTION

DIGITS f

CONG IN

DISCONNECTION

J

RELEASE GUARD

л DIS IND f

RLG IN \

PASSED .

Рис. 2.19. Сценарий работы имитатора протокола обмена сигналами по СЛ при занятости промпутей

В приведенном описании определен момент SIGS1M. Сообщения SEIZURE, ACK, BNUMBER, CONGESTION, DISCONNECTION, RELEASEGUARD были введены для сценария MSC Cong. Сообщения SZIND (индикация занятия), DIGITS (цифры номера), DISJND (индикация разъединения) и PASSED (тест прошел) дают информацию оператору о прохождении соответствующих этапов испытаний.

Сообщения CONG IN (команда на передачу сигнала о занятости соединительных путей) и RLGIN (команда на передачу сигнала «Контроль исходного состояния») поступают от оператора. Вентили 1, 3, 4, 7, 8, 11 - к физическому уровню интерфейса с соединительной линией, а 2, 5, (5,9, 10, 12 - к интерфейсу с пользователем (оператором). Таймеры ТГ и Т2



3. 4. 5. 6.

обеспечивают тайм-ауты для ожидания соответствующих сигналов.

Текстовое описание процесса тестирования выглядит следующим образом: MSC

instance SIGS1M

1. in SEIZURE

2. out SZJND out ACK set ТГ in BNUMBER reset ТГ out DIGITS in CONGIN

7. out CONGESTION set T2

8. in DISCONNECTION reset T2

9. in RLGJN

10. out RELEASEGUARD

11. out PASSED end instance end MSC

Проведя процедуру слияния (Merge) сценариев рис. 2.17 и 2.19, получаем результирующий сценарий MSC Cong Test. MSC Cong Test = MSC Cong II MSC Sim

При этом целесообразно ввести момент USER (оператор), описывающий интерфейс с пользователем. Сценарий MSC Cong Test приведен на рис. 2.20.

MSC CongTest OTLOC NEW CALL L

SIGSIM

USER

REJECT

T1>

SEIZURE

В NUMBER

CONGESTION

DISCONNECT

RELEASE GUARD

82 IND

DIGITS

CONG IN

RLG IN

Рис.2.20. Сценарий проверки обмена сигналами при занятости соединительных путей

Итак, SDL-диаграммы, описанные в предыдущем параграфе, являются источником тестовых последовательностей, представляющих собой набор MSC-сценариев. Именно по набору такого рода сценариев проводится проверка правильности отработки протоколов сигнализации, описанных в книге. Эти же сценарии положены в основу работы протокол-тестеров из главы 11. С помощью этих протокол-тестеров сообщения о сбое в сценарии (получен не тот сигнал, который ожидался, или сигнал не пришел до срабатывания тайм-аута), поступающие оператору, позволяют провести не только проверку, но и отладку указанного программного обеспечения.

2.3. СТАНДАРТИЗАЦИЯ МЕТОДОВ СПЕЦИФИКАЦИИ И ОПИСАНИЯ СОВРЕМЕННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ АРХИТЕКТУР

Современные телекоммуникационные архитектуры и создаваемые для них новые протоколы сигнализации вызвали необходимость в дополнительных языках их спецификаций и описаний: ASN.1 (Abstract Syntax Notation One) для протоколов модели Взаимодействия открытых систем (ВОС или OSI в английской аббревиатуре), TTCN (Tree and Tabular Combined Notation) для создания тестовых сценариев при тестировании конформности в рамках телекоммуникационных архитектур, GDMO для информационных



[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [ 11 ] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169]

0.0014