Форматы BSC и управляющие коды

ПРОТОКОЛ BSC.

Множественный доступ с временным разделением (TDMA)

(Или множественный доступ с квантованием времени - Прим. перев.)

Более уточненным подходом к реализации систем первичный/вторичный без опроса является множественный доступ с вре­менным разделением (TDMA). Этот метод является дальней­шим развитием метода мультиплексной передачи с времен­ным разделением (TDM).

BSC является полудуплексным протоколом. Передача осу­ществляется поочередно в обоих направлениях. Этот протокол поддерживает двухточечные и многоточечные соединения, а также как коммутируемые, так и некоммутируемые каналы. BSC является кодозависимым протоколом, и каждый знак, переданным по BSC-каналу, должен быть декодирован у получа­теля, чтобы определить, является ли он управляющим знаком или относится к данным пользователя. Как указывалось ранее, кодозависимые протоколы называются бит-зависимыми или знак- (байт-) зависимыми протоколами, а они далее различа­ются по признаку фиксированности расположения управляю­щих полей в кадре. Форматы кадра BSC и управляющие коды показаны на рис. 4

Рис. 4 Форматы BSC и управляющие коды.

Знак

Функция

SYN PAD DLE ENQ SOH STX ITB ETB ETX EOT BCC

Синхронизация канала в состоянии покоя (поддерживает активность канала) Наполнение кадра (временное заполнение между кадрами) Авторегистр 1 (используется для достижения кодовой прозрачности) Запрос (используется с опросом/выбором при захвате) Начало заголовка Начало текста (переводит линию в режим текста) Конец промежуточного блока Конец блока передачи Конец тектса Конец передачи (переводит линию в режим управления) Контрольный счетчик блока

Управляющие коды могут иметь несколько функций, которые определяются конкретным режимом работы канала в данный момент времени. (Режимы работы канала рассматриваются в следующем разделе.) На рисунке не показаны все возможные модификации формата кадра BSC, а приведены в качестве примеров некоторые основные реализации формата.

Так как BSC является знак-ориентированным протоколом, существуют проблемы отделения полей данных пользователя от управляющих полей. Существует возможность того, что данные, которые были распознаны как управляющие данные BSC, бы­ли созданы прикладным процессом пользователя. Например, можно предположить, что программа пользователя создает по­следовательность битов, которая совпадает с управляющим ко­дом ЕТХ (конец текста). Принимающая станция, встретив ЕТХ в данных пользователя, заключит, что это конец передачи, ко­торым обозначен кодом ЕТХ, созданным пользователем. Прото­кол BSC воспримет ЕТХ как протокольный управляющий знак и попытается выполнить контроль ошибок над неполным кад­ром BSC, что приведет к ошибке.

Очевидно, управляющие кодовые комбинации должны быть исключены из полей текста и заголовка. Эта проблема решает­ся в протоколе BSC с помощью управляющего кода DLE. Этот код помещается перед управляющими кодами STX, ЕТХ, ЕТВ, ITB и SOH для идентификации этих символов как действительно управляющих символов канала. Наиболее простой способ достижения кодовой прозрачности состоит в том, чтобы ис­пользовать DLE.STX или DLE.SOH для обозначения начала неуправляющих (т. е. пользовательских) данных, a DLE.ETX, DLE.ЕТВ или DLE.ITB для обозначения конца данных пользо­вателя. DLE не помещается перед данными, сформированными пользователем. Следовательно, если комбинации битов, совпа­дающие с какими-либо из этих управляющих знаков, будут соз­даны в тексте пользователя и поступят в принимающую стан­цию, эта станция будет считать их обычными данными пользо­вателя, поскольку перед ними не будет стоять DLE.

DLE переводит канал в режим, прозрачного текста, кото­рый позволяет производить передачу любой комбинации бит. Эта возможность является весьма важной, когда BSC исполь­зуется в различных видах приложений. Например, проектный или статистический отделы фирмы часто используют числа с плавающей запятой для представления больших чисел или дробных чисел с очень высокой точностью.

Возникает особая проблема с использованием DLE, если этот символ создается прикладным процессом конечного поль­зователя, так как он в этом случае может быть принят за управляющий код. BSC решает эту проблему, помещая DLE за символом DLE, относящимся к пользовательским данным. При­емник отбрасывает первый DLE из двух последовательно рас­положенных символов DLE и принимает второй DLE как допу­стимые данные пользователя.

Наличие заголовков, показанных на рис. 4, не является обязательным. Если заголовок включен в сообщение, перед ним помещается код SOH.

Дата добавления: 2014-01-06