Главная Классификация протоколов сигнализации [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
Рис. 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.0016 |