Полезная информация

ГЛАВА 7 ПРОТОКОЛЫ ИСПРАВЛЕНИЯ ОШИБОК

7.1. Повышение достоверности передачи

При передаче данных по каналам связи всегда возникают ошибки. Причины их могут быть самые различные, но результат оказывается один - данные искажаются и не могут быть использованы на приемной стороне для дальнейшей обработки. Как правило, вероятность искажения бита в потоке передаваемых данных на уровне физического канала находится в пределах 10~ ...Ю" . В тоже время со стороны пользователей и многих прикладных процессов часто выдвигается требование к вероятности ошибок в принимаемых данных не хуже 10-6...10-1 . Борьба с возникающими ошибками ведется на разных уровнях семиуровневой модели OSI (в основном на первых четырех). Для борьбы с возникающими ошибками известно много различных способов. Все их можно подразделить на две группы: не использующие обратную связь и использующие ее.

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

В системах с обратной связью применяются процедуры обнаружения ошибок и переспроса также называемые решающей обратной связью или обнаружением ошибок с автоматическим запросом повторения (АЗП, ARQ - Automatic Repeat Request). В этом случае код применяется только в режиме обнаружения ошибок, что дозволяет достичь очень низкой вероятности необнаруженной ошибки (до 10~ ...10~1 ) при незначительном уровне вводимой избыточности.

При передаче данных модемами наиболее широкое применение нашел второй подход, основанный на использовании методов ARQ. Иногда также применяется комбинация двух рассмотренных подходов, заключающаяся в реализации на передающей стороне сначала кодирования с обнаружением ошибок, а затем кодирования кодом с исправлением ошибок. Такие методы гибридного ARQ особенно эффективны при передаче данных по каналам очень низкого качества. Одним из примеров использования методов гибридного ARQ может служить сотовый протокол ZyCELL фирмы ZyXEL.

Для реализации механизма ARQ передаваемые данные организуются в специальные блоки, которые называются кадрами.

7.1.1. Формат кадра протоколов с исправлением ошибок

Формат кадра зависит от своего функционального назначения, типа протокола и режима передачи. Тем не менее, можно выделить некую обобщенную структуру кадра. Такой кадр содержит два флага (FLAG), поле управления (CONTR), поле информации (INFORM) и контрольную последовательность кадра (FCS - Frame Check Sequense), часто называемую также полем циклического избыточного кода (CRC - Cyclical Redundancy Check):

│ FLAG CONTR INFORM │ FCS FLAG


Флаги состоят из уникальной последовательности <01111110> и предназначены для установления и поддержания синхронизации передачи. Флаговая последовательность позволяет приемнику распознать начало и конец принимаемого кадра.

Поле управления содержит команды, ответы, а также порядковые номера, используемые для контроля прохождения данных в канале между приемником и передатчиком. Формат и содержание поля управления могут варьировать в зависимости от конкретного типа кадра конкретного протокола.

Информационное поле содержит данные пользователя или прикладного процесса передаваемые получателю.

Контрольная последовательность кадра используется для обнаружения ошибок передачи между двумя DCE. Передающее DCE вычисляет FCS и включает его в состав кадра. В свою очередь принимающая DCE производит аналогичные вычисления над принятым кадром и сравнивает полученный результат с полем FCS. Если имеет место совпадение, то считается, что передача прошла без ошибок. Вероятность необнаруженной ошибки, как правило, достигает порядка 10~ и менее. В случае несовпадения контрольных последовательностей кадра, считается, что была ошибка. Принимающее DCE посылает отрицательное подтверждение NAK, означающее, что необходимо повторить передачу кадра.

7.1.2. Кодонезависимость протоколов с исправлением ошибок

Протоколы с исправлением ошибок, как правило, являются кодонезависимыми. В первую очередь, это касается HDLC-подобных протоколов. Кодонезависимость протокола означает, что протокол способен передавать данные, представленные в виде практически любой известной кодировки, например ASCII (IA5) или EBCDIC. Это ценное свойство протокола достигается в основном за счет использования уникальной флаговой последовательности <01111110>. Однако ничто не мешает прикладному процессу (или пользователю) помещать в поток передаваемых данных последовательность <01 111 110>, совпадающую с флагом. Для того, чтобы предотвратить вставку в поток данных пользователя флаговой комбинации, передающее DCE помещает "О" после пяти идущих подряд единиц, встретившихся в любом месте между начальным и конечным флагами кадра. Такая вставка дополнительного "О" может производится в управляющее и информационное поля, а также в поле FCS. Описанный метод называется битс-таффингом (bit stuffing). Процесс битстаффинга поясняется рис. 7.1.

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

71.jpg

Рис. ^ Л. Битстаффинг в HDLC-подобных протоколах

72.jpg

Рис. 7.2. Процедура анализа принимаемого потока данных

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

Фактическое время между передачами кадров по каналу сопровождается передачей непрерывной последовательности флагов. Это называется межкад-ровым временным заполнением. Флаги могут быть восьмибитовыми или может иметь место совмещение последнего "О" предыдущего флага с первым "О" еле-' дующего флага.

Приемное DCE непрерывно контролирует поток битов в соответствии с алгоритмом, приведенном на рис. 7.2. После того как DCE получит комбинацию <011111>, оно анализирует следующий, бит. Если это "О", он удаляется. Если седьмой бит является единицей, то анализируется восьмой бит. Если восьмой бит - "О", считается, что получена флаговая комбинация <01111110>. Если "1", то получен сигнал покоя или аварийного завершения, и DCE выполняет соответствующие действия.

Таким образом обеспечивается кодовая прозрачность. Протоколу безразлично, какие кодовые комбинации находятся в потоке данных. Единственное, что требуется, так это поддержание уникальности флагов.

7.1.3. Обнаружение ошибок

Для обнаружения ошибок в передаваемых данных в общем случае могут применяться различные методы. К ним, в частности, относятся:

> посимвольный контроль четности (используемый при передаче по порту RS-232);

> поблочный контроль четности;

^ расчет контрольной суммы;

^ контроль циклическим избыточным кодом (CRC).

Реализация первых трех методов относительно проста. К сожалению, неспособность этих методов выявлять группирующие ошибки ограничивает их практическую применимость.

CRC-контроль является более мощным методом обнаружения ошибок и используется для обнаружения ошибок на уровне блоков данных. Он основан на делении и умножении многочленов. В определенном смысле CRC-контроль является алгоритмом хеширования, который отображает (хэширует) элементы большого набора на элементы меньшего набора. IIpoiiecc хэширования приводит к потере информации. Хотя каждый отдельный элемент набора данных отображается на один и только один элемент хэш-набора - обратное не верно. При CRC-контроле большой набор всех возможных двоичных чисел отображается на меньший набор всех возможных CRC.

Вычисление и использование кода CRC производится в соответствии со следующей последовательностью действий:

К содержимому кадра, описываемого полиномом F(x), добавляется набор единиц

73.jpg

количество которых равно длине поля CRC.

Образованное таким образом число х F(x)+x L(x), где k - степень F(x), делится на производящий полином д(х).

Остаток 0(х) от такого деления, определяемый из соотношения

Q(x)g(x)=x16 F(x)+xkL(x) + 0(х),

где Q(x) - частное от деления x16F(x)+xkL(x) на д(х), в инвертированном виде помещается в контрольное поле кадра.

На приемной стороне выполняется деление содержимого кадра с полем CRC xl6F'(x)+xkL(x) + 0(х), где F'(x)=xi6F(.x)+L(x)+0(x) - передаваемая кодовая комбинация, на полином д(х). Результат такого деления можно привести к виду:

xVF(x)+xkL(x)+0(x)]/g(y>xwL(xVg(x)=xi\Q(x)g(x)}/g(x)+xlбUx)/g(x).

Числитель первого слагаемого делится па д(х), поэтому в приемнике, если при передаче ве было ошибок, остаток получается равным остатку от деления постоянного числителя второго слагаемого (х1 L(x)/g(x)) и имеет вид

x^+x^+x^x^xV+x+i = 1110100001111.

Таким образом, если результат вычислений на приемной стороне равен некоторому определенному числу (в некоторых системах нулю, либо другому числу, несовпадающему с приведенным выше), то считается, что передача выполнена без ошибок.

Возможны и другие алгоритмы формирования и проверки контрольного поля кадра. Однако отличия их от рассмотренного носят частный характер.

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

Рекомендацией ITU-T V.41 стандартизуется полином д(х)= х^+х^+х5-^}. Часто этот полином обозначают просто как ССГГТ-16 или МККТТ-16. Он, в частности, используется в протоколе XModem-CRC и производных от него протоколах передачи файлов.

Другим популярным 16-разрядным порождающим полиномом является полином CRC-16. Он приобрел широкую известность как часть протокола двоичной синхронной передачи (BSC - Binary Synchronous Communications) фирмы IBM, Данный многочлен также определяется альтернативной процедурой Приложения А к стандарту V.42 ITU-T. Полином CRC-16 представляется в виде

g(x)=xlб+xi5+x2+i.

Увеличение числа разрядов CRC-поля позволяет значительно повысить надежность передаваемых данных. Порождающий полином CCITT^32 (MKKTT-32) дает 32-разрядный остаток и также стандартизирован в Рекомендации V.42. Многочлен CCITT-32, известный как CRC-32, представляется в виде

g(x)=xз2+xW+xlб+xl2+xll+xlo+xв+x7+ х^+х^х1^.

Находит применение и многочлен CRC-12 g(x)=xi2+xil+xз+\. Он может использоваться в тех случаях, когда для поля CRC выделяется меньшее число разрядов или когда не требуется более высокая точность более длинных CRC.

Техническая реализация вычислений CRC основана, как правило, на использовании сдвиговых регистров с логическими элементами "исключающее ИЛИ" (сумма по модулю 2). Схема деления входной последовательности на полином g(x)=xl6+xl2+x5<-'^ приведена на рис. 7.3.

После сдвига всего исходного кадра в ячейках памяти сдвигового регистра остается результат деления (остаток). В дальнейшем он используется в качестве контрольного поля кадра.

Таким образом обеспечивается кодовая прозрачность. Протоколу безразлично, какие кодовые комбинации находятся в потоке данных. Единственное, что требуется, так это поддержание уникальности флагов.

7.1.3. Обнаружение ошибок

Для обнаружения ошибок в передаваемых данных в общем случае могут применяться различные методы. К ним, в частности, относятся:

> посимвольный контроль четности (используемый при передаче по порту RS-232);

> поблочный контроль четности;

> расчет контрольной суммы;

> контроль циклическим избыточным кодом (CRC).

Реализация первых трех методов относительно проста. К сожалению, неспособность этих методов выявлять группирующие ошибки ограничивает их практическую применимость.

CRC-контроль является более мощным методом обнаружения ошибок и используется для обнаружения ошибок на уровне блоков данных. Он основан на делении и умножении многочленов. В определенном смысле CRC-контроль является алгоритмом хеширования, который отображает (хэширует) элементы большого набора на элементы меньшего набора. Процесс хэширования приводит к потере информации. Хотя каждый отдельный элемент набора данных отображается на один и только один элемент хэш-набора - обратное не верно. При CRC-контроле большой набор всех возможных двоичных чисел отображается на меньший набор всех возможных CRC.

Вычисление и использование кода CRC производится в соответствии со следующей последовательностью действий:

К содержимому кадра, описываемого полиномом F(x), добавляется набор единиц

74.jpg

количество которых равно длине поля CRC.

Образованное таким образом число x16F(x)+x L(x), где k - степень F(x), делится на производящий полином д(х).

Остаток 0(х) от такого деления, определяемый из соотношения

Q(x)g(x)=x16 F(x)+xkL(x) + 0(х),

где Q(x) - частное от деления x16F(x)+xkL(x) на д(х), в инвертированном виде помещается в контрольное поле кадра.

75.jpg

Рис. 7.3. Схема деления на полином g(x)=x +x +х +1

7.1.4. Методы повторной передачи (ARQ)

Возможен ряд вариантов механизма ARQ. Каждый правильно принятый кадр может быть подтвержден отдельным специальным кадром, либо подтверждение может быть вставлено в управляющее поле информационных кадров, переносящих данные в обратном направлении. В последнем случае также должны применяться специальные кадры подтверждения, поскольку информационного кадра в нужный момент может не оказаться.

Существует два вида подтверждения о приеме: положительное (АСК) и отрицательное (NACK или NAK). Но в любом случае во избежание перегрузок должны применяться перерывы. Передающая сторона, не получившая ответа (АСК или NACK) в течение заданного промежутка времени после передачи, повторяет соответствующий кадр. Чтобы организовать процедуру перерывов, кадры должны сохраняться в накопителе передающей стороны до получения подтверждения правильности передачи.

Существует три основные способа обработки ответов на положительные и отрицательные подтверждения:

> Стартстопный, или передача с остановкой и ожиданием (SAW - Stop And Wait), часто называемый блочным методом передачи.

> С возвращением на N кадров (GBN - Go Back N), также называемый потоковым методом передачи.

> Метод выборочного (селективного) повтора (SR - Selective Repeat). Кратко рассмотрим принцип работы перечисленных процедур.

SAW

Согласно этой процедуре без подтверждения может быть передан только один кадр. После передачи очередного кадра передающая сторона ждет подтверждения. Если поступает отрицательное подтверждение или произойдет превышение времени тайм-аута, кадр передается повторно. Кадр сбрасывается (стирается) из накопителя передатчика лишь после получения положительного подтверждения. Временная диаграмма работы процедуры ARQ типа SAW изображена на рис. 7.4.

Данную процедуру удобно использовать при полудуплексной связи, когда передача сторон чередуется. Однако она неэффективна в случае организации по.чнодуплексной связи, особенно, если время распространения сигнала по каналу значительно больгае времени передачи кадра, что типично для спутниковых и ряда других каналов.

76.jpg

Рис.. 7.4. Передача кадров согласно процедуре SAW

 

Из теории телекоммуникации известно простое выражение для оценки производительности СПД со схемой ARQ типа SAW:

77.jpg

где Q - вероятность безошибочной передачи кадра из п бит; V - скорость передачи, выраженная в бит/с; D - средняя задержка между двумя успешными передачами, с.

Если время распространения пренебрежимо мало (при небольшой протяженности канала либо по причине низкой скорости передачи), процедура SAW не приведет к серьезному снижению производительности всей системы.

GBN

В данном случае кадры передаются непрерывно без ожидания подтверждения приема определенного количества кадров. При получении отрицательного подтверждения или по истечении установленного времени ожидания неподтвержденный и все последующие кадры передаются повторно. Пример такой передачи по процедуре GBN представлен на рис. 7.5.

Производительность схемы GBN может быть вычислена с помощью следующего выражения:

78.jpg

79.jpg

Рис. 7.5. Передача кадров согласно процедуре GBN

где N - задержка кругового распространения, т.е. промежуток времени от момента начала передачи кадра до момента получения подтверждения на него.

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

Процедуру GBN часто называют ARQ типа REJ (REJect), также как служебные кадры, переносящие подтверждения NACK от приемника к передатчику.

SR

Согласно процедуре SR повторная передача данных осуществляется только для кадра, на который поступило отрицательное подтверждение либо истекло время тайм-аута подтверждения. Данная процедура, по сравнению с процедурами SAW и GBN, существенно увеличивает пропускную способность СПД. Но для передачи и приема кадров не по порядку их номеров на приемной стороне должен находится буферный накопитель с произвольным доступом. С увеличением задержки распространения сигнала в канале связи необходимо увеличивать буферную память. Очевидно, реализация процедуры SR является более сложной и дорогостоящей. По этой причине она долго не могла найти широкого коммерческого применения. Даже в наиболее совершенном на сегодняшний день протоколе V.42 процедура селективного повтора не является обязательной. Временная диаграмма передачи кадров согласно процедуры SR показана на рис. 7.6.

Способ SR часто называют ARQ типа SREJ (Selective REJect), также как одноименные служебные кадры, переносящие подтверждения о селективном неприеме от приемника к передатчику.

710.jpg

Рис.. 7 6 Передача кадров согласно процедуре SR

Эффективность СПД со схемой ARQ типа SR в идеальном случае зависит только от вероятности безошибочного приема кадров, то есть от качества канала связи.

^s^Q-

Сравнивая приведенные выше выражения для производительности трех ос новных схем ARQ, нетрудно заметить, что при условии короткого расстояния и низкой скорости передачи (D, V->0, N->\) эффективность систем передачи становится равной между собой и зависит исключительно от качества канала связи (вероятности Q) С другой стороны, при увеличении расстояния и возрастании скорости передачи (D, V, Л/->оо), стратегия селективной повторной передачи оказывается вне конкуренции. На рис 7 7 приведены ориентировоч ные зависимости эффективности рассмотренных методов от вероятности ошибок в канале

711.jpg

Рис 7.7 Производительность различных вариантов ARQ

7.2. Протоколы MNP

7.2.1. Общие сведения

Одним из первых протоколов исправления ошибок стал протокол MNP (Microcom Networking Protocol), разработанный фирмой Microcom. Он оказался настолько удачным, что претерпел девять модификаций и расширений, которые получили название Классов протоколов MNP. Классы 1 -4 обеспечивают исправление ошибок, классы 6, 9,10 - кроме исправления ошибок, выполняют и другие функции.

MNP1 используется для асинхронного побайтного полудуплексного обмена данными. Он был разработан для того, чтобы устройства с минимальными аппаратными ресурсами могли осуществлять контроль ошибок. Из-за своей чрезвычайно низкой эффективности протокол в современных модемах больше не используется.

MNP2 позволяет исправлять канальные ошибки при асинхронной полнодуплексной передаче данных и требует реализуется в модемах с микропроцессорным управлением. Протокол также характеризуется повышенной избыточностью, поскольку в нем при асинхронном режиме передачи в каждый передаваемый символ включаются стартовые и стоповые биты.

MNP3 обеспечивает обмен данными между модемами по протоколу SDLC (Synchronouse Data Link Control) в синхронном режиме, в то время как обмен данными с компьютером остается асинхронным. Из байт данных, принимаемых от DTE, формируются блоки данных (кадры), называемые в терминах MNP пакетами. Каждый пакет передается как один синхронный кадр второго канального уровня модели OSI. Скорость передачи информации при использовании MNP3 повышается за счет того, что уже не требуется передавать дополнительные стартовые и стоповые биты для каждого байта.

MNP4 предусматривает возможность изменения размера пакета в процессе процедуры согласования параметров передачи, называемой также процедурой адаптивной сборки пакетов (Adaptive Packet Assembly). Пакет может содержать 32, 64, 128, 192 или 256 байт. При большом уровне шумов передаются пакеты меньших размеров. В результате этого увеличивается вероятность безошибочной передачи пакета данных. По высококачественным каналам пересылаются пакеты больших размеров; при этом уменьшается количество избыточной служебной информации. Управление размером пакета со стороны пользователя часто возможно при помощи АТ-команды \Ап.

Протокол MNP4 позволяет повысить скорость передачи за счет оптимизации фазы (режима) передачи данных (Data Phase Optimization), поскольку не требует передавать не изменяющийся заголовок для каждого нового пакета.

Благодаря этому большая часть информационной пропускной способности канала используется для передачи данных.

MNP6 рассчитан на работу со скоростями от 300 до 9600 бит/с. Модем начинает работу на скорости 2400 бит/с и затем изменяет ее в зависимости от типа удаленного модема. Этот протокол предусматривает возможность автоматического переключения из полудуплексного режима в дуплексный и обратно.

MNP9 обеспечивает совместимость с протоколом модуляции V.32 и предусматривает процедуру сжатия, а также повышает эффективность передачи за счет реализации режима селективного повтора искаженных пакетов (ARQ типа SR).

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

7.2.2. Форматы передаваемых данных

Способность MNP к непрерывному совершенствованию и расширению своих функциональных возможностей определяется базисным элементом сообщения MNP, называемым протокольным блоком данных (PDU - Protocol Data Unit). PDU включается в синхронный или асинхронный пакет, передаваемый от модема к модему. Ниже приведена диаграмма асинхронного байт-ориентированного пакета MNP2:

712.jpg

где каждый знак представлен символом в виде:

713.jpg

Пакет MNP2 включает в себя поле начального флага, содержащее три байта: SYN, DLE и STX (16h, 10h, 2h); прозрачные пользовательские данные переменной длины в виде PDU; управляющее поле конечного флага, включающее два байта: DLE и ЕТХ (10h, 3h); двухбайтовую контрольную последовательность кадра, полученную с помощью образующего полинома CRC-16 g^^W+A

Формат синхронного пакета MNP (MNP3 и выше) следующий:

714.jpg

где FLAG - флаг, представляющий собой комбинацию <01111110> (7Eh). В данном случае каждый передаваемый знак представляется байтом без стартового и стопового битов. Исключение стартовых и стоповых бит существенно повышает эффективность передачи информации при помощи синхронных протоколов.

Блок данных PDU содержит всю информацию, требуемую для описания и реализации услуг управления соединением и пересылки данных между модемами. Существует всего восемь типов PDU. Общий формат блоков PDU приведен ниже:

LEN ^ TYPE Parameters User data


где LEN - это длина PDU в байтах, TYPE - код от 1 до 9, указывающий тип PDU и Parameters - это строка служебных знаков. Значение Parameters определяется его позицией в PDU и значением кода TYPE. Например, Parameters порядковый номер передачи N(S) указывает последовательный номер данного PDU в потоке передаваемых пакетов и позволяет приемному модему определить правильность приема очередного пакета.

MNP позволяет сформировать до 256 различных параметров и, соответственно, до 256 различных типов PDU. Это предоставляет большие возможности по развитию и расширению протоколов MNP, каждый из которых будет совместим с предыдущими.

В настоящее время определены следующие восемь типов PDU.

Link Request (LR) - запрос соединения:

715.jpg

LR: TYPE=1

Инициализирует или подтверждает соединение. Параметры включают класс услуг MNP, число сообщений, которые могут быть приняты без подтверждения, и максимальную длину данных пользователя в PDU.

Link Disconnect (LD) - разъединение канала:

 716.jpg

LD:TYPE=2

Запрашивает разрыв соединения по каналу. Длина блока LD может быть равна 4 или 7 байт. При этом соответственно передается один или два параметра (второй параметр необязательный). Информация в блоке Parameters содержит причину разъединения. В настоящее время оговорены следующие четыре причины разъединения:

> ошибка в фазе установления протокола (не получен блок LR), - код причины 1;

> в третьем байте блока LR содержится запрос режима работы, неподдерживаемого локальным модемом (код причины 2);

> принятый блок LR имеет несовместимое или неизвестное значение параметра, - код причины 3;

> завершение связи по инициативе пользователя, - код причины 255.

Link Transfer (LT) - передача по каналу:

717.jpg

LT: TYPE=4

Переносит данные пользователя по каналу. Данные пользователя добавляются к блоку LT как поле переменной длины до 256 байт. Единственный параметр (р) - это последовательный номер передачи SSN, идентифицирующий положение PDU в потоке передаваемых блоков.

Link Acknowledgement (LA) - подтверждение приема:

718.jpg

LA: TYPE=5

Подтверждает прием сообщения. Parameters указывают количество PDU LT, которое приемник может принять до переполнения (до окончания размера окна). Link atteNtion (LN) - линейное предупреждение (разрыв связи):

719.jpg

LN: TYPE=6

Прерывает связь между передатчиком и приемником. Parameters указывают на то, что делать с переданными, но не подтвержденными данными передатчика: доставить их до прерывания, после прерывания или не доставлять вообще (разрушить). Обычно используется для передачи сигнала разъединения. Передача данных в блоке LN запрещена, длина фиксирована и равна 7 байт. Блок содержит два параметра - номер извещения и тип извещения.

Параметр "Тип извещения" определяет порядок обработки состояния разрыва связи. При получении сигнала "Линейное предупреждение", устройство управления должно определить параметр разрыва. От этого параметра зависит, во-первых, как обрабатывать накопленные, но еще не переданные пользователю данные. Если данные доставляются пользователю, то разрыв называется не разрушающим; если же вся накопленная информация уничтожается, разрыв считается разрушающим. Во-вторых, требуется установить последовательность доставки пользователю информации о разрыве и накопленных данных. Если сообщение о разрыве может быть передано в общем потоке данных, то разрыв является несрочным (обычным); если такое сообщение передается с высшим приоритетом, то разрыв считается срочным.

В соответствии с данными понятиями кодируется поле типа извещения, которое может принимать следующие значения:

1 - срочный разрушающий разрыв;

2 - срочный неразрушающий разрыв;

3 - несрочный (обычный) неразрушающий разрыв.

Link atteNtion Acknowledgement (LNA) - подтверждение приема блока линейного предупреждения LN:

720.jpg

LNA:TYPE=7

Подтверждает прием PDU LN и позволяет корректно выполнить процедуру разрыва. Parameters включает номер SSN подтверждаемого блока LN. Длина блока равна 4 байт, в нем содержится всего один параметр, а данные отсутствуют. Этот блок подтверждает правильный прием всех блоков предупреждения LN, имеющих номер, меньший или равный указанному.

Link Management (LM) - управление каналом:

721.jpg

LM:TYPE=8

Реализует функции классов 6 и 10 MNP, включая возможность управления изменением скорости передачи модема в течение сеанса связи. Параметры содержат требуемую скорость передачи.

Link Management Acknowledgement (LMA) - подтверждение приема LM:

722.jpg

LR: TYPE=1

Подтверждает правильный прием блока LM. Parameters - это SSN подтверждаемого PDU LM.

7.2.3. Процедура соединения MNP

При использовании протоколов MNP модемы взаимодействуют друг с другом, передавая и принимая PDU, включенные в пакеты синхронных или асинхронных битовых потоков.

Соединение инициализируется, когда один из модемов (передатчик) передает по каналу блок данных "Запрос соединения" (LR). Приемник отвечает, передавая собственный PDU LR обратно передатчику. После этого передатчик передает PDU "Подтверждение приема" (LA), и на этом соединение считается установленным. Этот трехэтапный процесс подтверждения связи называется фазой установления соединения. После фазы установления передатчик пересылает данные со своего компьютера приемнику в форме PDU "Передача по каналу" (LT). Приемник подтверждает корректное получение этих сообщений, посылая обратно передатчику PDU "Подтверждение приема" (LA). Таким образом реализуется метод решающей обратной связи для повышения достоверности передачи информации. Число сообщений, передача которых разрешена до того момента, как будет принят PDU LA, устанавливается при обмене "запросами соединения" (LR). Этот обмен данными и подтверждениями их приема называется фазой передачи данных.

В случае приема сообщения с ошибками программное обеспечение, реализующее механизм автоматического запроса повторения в модеме MNP также посылает передатчику PDU "Подтверждение приема" с номером последнего правильно принятого протокольного блока LT. В этом случае блок "Подтверждение приема" (LA) указывает передатчику, что надо передавать PDU LT, следующий за тем, чей номер помещен в параметр данного блока. То есть следующий номер и будет номером полученного с искажениями информационного блока LT. Приемник выносит решение об искажении информационного блока, если обнаружена некорректная контрольная последовательность пакета, неправильная последовательность приема PDU LT или получение большего числа сообщений, чем может обработать приемник.

Один из модемов может завершить сеанс связи, послав PDU "Разъединение канала" (LD). Отправитель PDU LT подразумевает, что сеанс завершен после передачи им запроса на разъединение канала. Модемы MNP откликаются на сигнал DTE BREAK, посылая сигналы удаленному модему на основе сигнализации, предусмотренной PDU "Прерывание канала" и "Отклик на прерывание канала" (LN и LNA). "Прерывание канала" LN вырабатывается в ответ на . прерывание и указывает, должны ли данные, переданные до сигнала BREAK, быть доставлены пользователю или отменены. Приемник возвращает "Отклик на прерывание канала" (LNA), указывающий SSN подтверждаемого PDU LN.

В ходе фазы установления соединения передатчик и приемник достигают соглашених об услугах, которые они будут использовать при передаче данных. Кроме того, они "договариваются" о следующем:

> будет связь синхронной или асинхронной;

> будет ли применяться сжатие данных и если будет, то в соответствии с каким протоколом;

> какой класс (классы) MNP активизировать.

Соглашение по этим вопросам достигается в ходе трехэтапного обмена блоками данных LR и LA. Обмен начинается с асинхронной передачи отправителем своего LR. Это происходит в соответствии с протоколом MNP2, поскольку его поддерживают все MNP-модемы.

LR передатчика содержит информацию о наборе функций, которые передатчик хотел бы использовать. В ответ приемник посылает передатчику LR, указывающий, какие из запрошенных функций он поддерживает.

Передатчик подтверждает получение LR приемника, посылая кадр LA, который содержит набор функций, согласованных с приемником. С этого момента передатчик и приемник начинают взаимодействие, используя перечень выбранных функций. Например, они могут теперь переключиться с асинхронного режима на синхронный, если "договорились" о его использовании.

Если используется класс 6 или класс 10 MNP, изменение скорости передачи совершается в ходе фазы передачи данных с помощью PDU "Управление каналом" (LM). Модем подсчитывает число повторных передач и изменяет скорость передачи по каналу таким образом, чтобы достичь оптимального соотношения между числом искаженных блоков данных (согласно содержимому счетчика повторных передач) и скоростью передачи. Для этого удаленному модему передается блок данных PDU "Управление каналом" (LM) с указанием скорости, и затем изменяя скорость работы местного модема.

7.2.4. Расширения MNP

Расширение MNP возможно посредством добавления новых параметров к PDU или путем использования новых PDU. Совместимость с существующими реализациями MNP поддерживается за счет того, что применение новых расширений должно быть взаимно согласованно. Новые PDU могут быть добавлены без изменения функций других PDU (как в случае с блоками "Управление каналом"). Оптимизация фазы передачи данных (класс 4), селективный повтор (класс 9) являются примерами расширений MNP, достигнутыми при полной поддержке существующих образцов модемов MNP. При оптимизации фазы передачи данных повторяющиеся начальные служебные символы извлекаются из PDU, что увеличивает долю передаваемых данных пользователя по отношению к количеству служебных данных. Например, не оптимизированный PDU LT выглядит следующим образом:

723.jpg

где первая "1" в параметре "Последовательный номер передачи" (send sequence по) является номером параметра, а вторая "1" указывает длину параметра. Метод идентификации типа и длины параметров дает протоколу возможность иметь новую информацию, добавленную к имеющимся параметрам, как метод видоизменения протокола, помимо наращивания числа параметров в PDU. Однако опыт показывает, что параметры "Тип" (type) и "Длина" (length) не всегда требуются. Например, SSN в PDU LT всегда является первым и единственным параметром, а его длина всегда составляет один байт.

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

724.jpg

где параметр "Длина" теперь занимает 2 байта вместо четырех. Блок данных "Отклик по каналу" (LA) может быть также оптимизирован. Не оптимизированный PDU LA имеет формат:

725.jpg

где параметр RSN указывает на SSN последнего PDU LT, без ошибок принятого, a CDT указывает число PDU LT, которые приемник может дополнительно принять от передатчика. Обратите внимание, что "2" определяет параметр CDT и, таким образом, всегда является вторым параметром в блоке. Параметр CDT также имеет длину 1 байт. Оптимизированный PDU LA выглядит следующим образом:

3 LA RSN CDT


Такой формат позволяет сэкономить 4 байта (57%) на подтверждающее сообщение. Функция селективного повтора (класс 9) была реализована простым добавлением числа последовательных номеров, которые могут быть включены в один PDU LA. Вместо того, чтобы передавать все PDU LT, начиная с данного RSN, специфицируется только один.

Дополнительное подтверждение позволяет избегать посылки отдельного PDU LA, если исходящим PDU является протокольный блок LT, с которым и передается подтверждение. PDU LT, модифицированный для переноса подтверждающей информации выглядит следующим образом:

4 LT SSN RSN CDT User data


PDU также был оптимизирован посредством исключения избыточных байтов "type" и "length". Многие расширения MNP требуют еще меньших модификаций протокола, чем в данном примере. Так, сжатие данных выполняется с использованием одного из трех различных алгоритмов: класса 5, класса 7 или V.42bis, в зависимости от значения одного (девятого) параметра PDU "Запрос канала" (LR). С момента, когда программное обеспечение модема определит, какой алгоритм сжатия используется в PDU LT, это больше не влияет на дальнейшую работу протокола.

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

7.3. Протокол V.42

7.3.1. Основные характеристики

Стандарт V.42, принятый ITU-T в ноябре 1988 года, определяет процедуру LAPM (Link Access Procedure for Modems), схожую по возможностям с MNP4. Преимущества LAPM по сравнению с MNP4 заключаются в повышенной скорости передачи по плохим телефонным каналам и хорошей согласованности с другими стандартами, основанными на протоколе HDLC. Процедура LAPM

 726.jpg

Рмс. 7.8. Функции DCE без аппаратной коррекции ошибок

очень близка к процедурам LAPB и LAPD, применяемых в сетях Х.25 и в сетях интегрального обслуживания ISDN.

Согласно V.42 требуется реализация как процедуры LAPM, так и протокола MNP4, как альтернативного варианта повышения достоверности. Это означает, что модем V.42 может взаимодействовать с модемами типа MNP4. Однако при таком соединении не будут задействованы все возможности V.42. Во время установления связи модем V.42 проверяет, может ли удаленный модем работать согласно полного протокола V.42 или только по протоколу MNP4. При этом предпочтение отдается протоколу V.42. Таким образом, модем V.42 пытается использовать процедуры коррекции ошибок согласно V.42, и если это не получается, то производится попытка запустить MNP4. Если и эта попытка оказывается безуспешной, устанавливается связь без коррекции ошибок.

В отличие от аппаратуры канала данных без аппаратного исправления ошибок (рис. 7.8), рекомендация V.42 выделяет в функциональной схеме DCE дополнительный блок защиты от ошибок (рис. 7.9).

^Согласно V.42 блок управления модема должен определять, поддерживает ли удаленная аппаратура функции исправления ошибок, и координировать согласование соответствующих процедур.

Блок защиты от ошибок предназначен для управления процедурами исправления ошибок. Именно он и реализует протокол связи LAPM.

Рекомендация V.42 регламентирует также цепи интерфейса V.24, задействованные в процессе работы модемов по протоколу V.42 (рис. 7.10).

727.jpg

Рис. 7.9. Функции DCE согласно V.42

728.jpg

Рис. 7.10. Цепи, работающие при защите от ошибок, где TD - передаваемые данные; RD - принимаемые данные; TDC - синхронизация передаваемых данных; RDC - синхронизация принимаемых данных; RTS - запрос передачи; RFS - готовность к передаче; RSD - детектор принимаемого линейного сигнала из канала данных.

7.3.2. Формат кадров V.42

В стандарте V.42 используется понятие кадра данных. Согласно V.42 кадр должен передаваться только в синхронном режиме и соответствовать рекомендациям протокола Х.25 или HDLC. Это означает, что в нем обязательно должны присутствовать поля адреса и управления. Кадр LAPM выглядит следующим образом:

1 FLAG 1 ADRES I CONTR │ INFORM │ FCS FLAG


Здесь ADRES - поле адреса, которое позволяет по одному физическому каналу организовать несколько логических (виртуальных) каналов. Формат поля адреса следующий:

DLCI │ с/г 1 0


где DLCI (Data Link Connection Identifier) - идентификатор соединения по звену данных, или адрес. Разряд с/г определяет, содержит ли кадр команду или ответ на нее.

Для определения адреса допускается использовать один или два байта. В последнем случае последний разряд поля адреса должен быть равен единице. Протокол V.42 определяет следующие допустимые значения идентификатора соединения DLCI:

> 0 - данные пользователя;

^ 1-31 -зарезервировано;

> 32-62 - не используется и не зарезервировано;

> 63 - служебные данные блока управления.

Заметим, что в протоколах MNP поле адреса не используется.

INFORM - поле информации пользователя, которое является необязательным, однако может присутствовать и в служебных кадрах. Поле информации V.42 соответствует блоку PDU протоколов MNP.

CONTR - поле управления является обязательным для HDLC-подобных процедур, но в протоколах MNP не используется. Это поле может состоять из одного или двух байт. Определить его размер можно по типу кадра, который определяется одним или двумя последними битами первого байта. Последний нулевой бит означает двухбайтное поле управления формата I. Комбинация 01 в последних битах соответствует типу кадра формата S. Комбинация 11 соответствует одному байту управления кадра формата U. Остановимся подробнее на указанных типах кадров.

Кадры формата I (информационные) предназначены для передачи прикладных данных. В поле управления таких кадров содержится порядковый номер N(S) передаваемого и номер N(R) подтверждаемого кадров (в протоколах MNP для таких целей используется шесть байт), а также признак запроса ответа (бит Р). Параметры N(S) и N(R) LAPM аналогичны соответствующим параметрам SSN и RSN протоколов MNP. Таким образом, поле управления кадра формата I выглядит следующим образом:

N{S) 0
N(R) Р


Если передается команда или запрос, на который необходим ответ, бит Р должен быть равен единице. При Р равном нулю ответ не требуется. В ответах на запрос этот бит также устанавливается равным единице.

При передаче последнего кадра пакета разряд Р устанавливается в " 1 ". Это означает окончанием передачи пакета. При получении такого кадра приемная сторона должна передать подтверждение приема пакета данных.

Кадры формата S (супервизорные) используются для подтверждения получения информационных кадров, запроса их повторной передачи или запроса временной задержки передачи кадров. Процедура LAPM допускает подтверждение правильного приема данных любым кадром. При дуплексной передаче информации предпочтительно пересылать подтверждения принятых кадров вместе с передаваемыми данными. В симплексном режиме передачи используются специальные супервизорные кадры.

Информация пользователя в этих кадрах не передается. Формат поля управления супервизорного кадра выглядит следующим образом:

х х │ х │ х │ S │ S I 0 1
N(R) Р


где значение разрядов (S,S) определяет конкретное назначение супервизорного кадра; разряды "хххх" не используются.

Последний тип кадров формата U (Unnumbered) - ненумерованный:

I М │ M M p M M 1 I 1


где М - изменяемые функциональные биты, определяющие код и параметры кадра; последние два бита со значением (1,1) являются признаком ненумерованного кадра. Кадры этого типа используются для обмена служебной информацией. В них не допускается передача информации о подтверждении блоков.

С помощью поля управления CONTR однозначно определяется тип кадра и его формат. Как и для протоколов MNP, каждый кадр можно рассматривать как определенную команду процедуры передачи данных. Приведем перечень кодов команд и сообщений процедуры LAPM:

RR - готовность к приему (тип S):

о о о о о о о 1
N(R) р


RNR - неготовность к приему (тип S):

0 │ 0 │ 0 │ 0 │ 0 │ 1 │ 0 1
N(R) Р


REJ - неприем кадра (тип S):

0 │ 0 0 о 1 о │ о 1
N(R) р


SREJ - селективный неприем отдельного кадра (тип S):

о │ о │ о 0111110 1
N(R) Р


SABME - установить асинхронный сбалансированный режим (тип U):

0 1 1 Р 1 1 1 1


DM - режим "Завершение связи" (тип U):

I о о о р I 1 1 1 1 1


UI - ненумерованная информация (тип U):

0 о о I р о о 1 I 1 I


DISC - завершение связи (тип U):

I о 1 о р о о 1 1 I


UA - ненумерованное подтверждение (тип U):

I 0 1   Р 1 1 1 1 I


FRMR - неприем кадра (тип U):

│ 1 0 I 0 р о 1 1 1 I


XID - идентификация обмена (тип U):

1 1 I 0 │ 1 I 0 │ I 1 I 1 I 1 I 1 I


TEST - испытание (тип U):

I 1 1 1 0 о о 1 I 1 I


Стандарт V.42 описывает функционирование модема с коррекцией ошибок как совокупность алгоритмов работы блока управления и процедур блока защиты от ошибок. Алгоритмы блока управления регламентирует последовательность выполнения различных процедур и команд.

7.3.3. Процедура соединения на основе V.42

Процедура соединения полностью определяется алгоритмом работы блока управления и может быть разделена на фазу обнаружения, фазу установления соединения с исправлением ошибок, фазу испытания канала связи, фазу передачи данных, фазу завершения связи и фазу разрыва соединения.

Фаза обнаружения

Работа протокола начинается с фазы обнаружения. На этом этапе каждый из соединяющихся модемов определяет к какому классу аппаратуры относится его корреспондент. При этом производится распределение ролей: один из модемов становится инициатором соединения, а другой - ответчиком.

Затем происходит взаимное опознавание. Каждый модем должен определить возможности своего партнера. Для этого модем-инициатор начинает передавать последовательность единиц со специальными символами опознавания:

О 1000 1000 1 11...11 0 1000 1 11...11 и так далее.

Между символами может быть от 8 до 16 единиц. Такая последовательность передается до получения ответа от модема-ответчика, но не более 750 мс.

Подобный сигнал передает и удаленный модем. Он может передавать одну из двух возможных последовательностей:

О 1010 0010 1 11...11 0 1100 0010 1 11...11

или

0 1010 0010 1 11...11 0 0000 0000 1 11. ..11.

Первая последовательность означает, что протокол V.42 поддерживается, вторая - что протокол не поддерживается. Если оба модема поддерживают протокол V.42, то начинается фаза установления соединения с исправлением ошибок.

Фаза установления соединения

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

XID (eXchange IDentification), аналогичными кадрам протоколов MNP, содержащим информацию о конкретных возможностях модема.

Такое согласование параметров допускается не только в фазе установления соединения, но и в фазе передачи данных. В последнем случае в любой момент времени может быть передана команда приостановки передачи данных RNR.

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

В целом процедура аналогична используемой в протоколах MNP, но существуют и свои особенности. На начальном этапе установления соединения однозначно невозможно определить разрядность контрольной суммы. Поэтому приемнику очередной принятый кадр необходимо проверять как по 16-разрядной, так и по 32-разрядной контрольной последовательности. Если одна из проверок дает положительный результат, то кадр считается принятым без ошибок. Так продолжается до завершения фазы установления соединения.

Отличительная особенность процедуры установления соединения согласно V.42 заключается в значительном количестве параметров сеанса связи, требующих согласования в течение данной фазы. Такие параметры, в частности, определяют использование режима селективной повторной передачи (SR, SREJ), возможность шлейфных испытаний (TEST), размер контрольной последовательности кадра (16 или 32 бита) и др.

Фаза испытания канала

В течение этой фазы модемы могут обмениваться тестовыми кадрами TEST и по результатам передачи делать выводы о качестве канала связи. Эта фаза является необязательной.

Рекомендация V.42 не предусматривает конкретное кодирование поля информации кадров TEST. Однако в ней отмечается, что поле данных должно иметь определенное содержание для проведения испытаний канала.

Фаза передачи данных

В случае успешного согласования параметров связи модемы переходят в фазу передачи данных. Сигналом к переходу в эту фазу является передача кадра SABME. Отвечающий модем при первой же возможности выдает ответ на такую команду. Это может быть кадр UA. Если вызываемый модем не в состоянии начать обмен данными, он может ответить кадром DM (режим разъединения). В случае готовности к информационному обмену обоих модемов наступает фаза передачи данных. Данные передаются в кадрах формата I, каждый из которых имеет свой номер и может быть легко идентифицирован.

После приема информационного кадра приемник проверяет его контрольную последовательность и делает заключение о достоверности полученных дан-. ных. Правильно принятый кадр сопровождается подтверждением, которое передается в составе любого кадра.

При наличии данных передается информационный кадр, в поле управления которого заносится номер, на единицу больший номера последнего правильно принятого кадра. Если модем занят и временно не может принимать данные, он отвечает ненумерованным кадром RNR (неготовность к приему);

если свободен, то отвечает командой RR (готовность к приему), также с номером очередного ожидаемого кадра. После этого все кадры с номерами меньше указанного считаются успешно принятыми, а кадр с указанным номером еще не подтвержденным.

При-обнаружении ошибки в принятом кадре запрашивается его повторная передача. Это осуществляется в зависимости от принятой реакции на автоматический запрос повторения ARQ с помощью одного из двух типов кадров неподтверждения. В случае ARQ с возвратом на N шагов (GBN) передаются кадры REJ (неприем). При получении кадра REJ передатчик должен повторить все кадры, начиная с номера, заданного в этой команде. Остальные кадры подтверждаются этой командой. При ARQ с селективным повтором (SR) принимаемый модем передает кадр типа SREJ (селективный неприем). В случае получения такого кадра, передающий модем должен повторить только кадр с указанным номером, после чего передача очередного кадра может быть продолжена. Режим ARQ с селективным повтором не является обязательным. Соответственно, не являются обязательными и кадры селективного неприема, которые не поддерживаются некоторыми устройствами.

Возможна ситуация, когда принят кадр с неустранимыми искажениями, например, с недопустимым полем управления (CONTR), с ненормальной длиной или недействительным номером. Если повторная передача кадра не исправляет положение, модем может уведомить об этом своего корреспондента командой FRNR (неприем кадра). Прием такого кадра вызывает переход в фазу повторного установления соединения с исправлением ошибок. В этом случае снова выполняется согласование параметров протокола. Возврат в эту фазу может происходить и по другим причинам, например, по инициативе пользователя, при получении кадра SABME в фазе передачи данных, по истечении тайм-аута ожидания кадра и др.

Фаза завершения связи

Фаза начинается с передачи кадра DISC. Ответом на него может служить кадр UA, подтверждающий завершение кадра, или кадр DM, информирующий о том, что корреспондент уже находится в фазе завершения связи.

Фаза разрыва соединения

Модемы переходят в фазу разрыва соединения в случае необходимости срочного прекращения связи до того, как данные будут переданы полностью. При этом должен использоваться кадр UI, содержащий в поле информации параметр BRK (разрыв) или BRKACK (подтверждение разрыва). Как и в протоколах MNP, здесь можно говорить об обычном, срочном или разрушающем разрывах. Эти кадры имеют следующий формат.

Кадр BRK:

0 0 о Р 0 0 1 1 ,
X 1 6 0 0 0 0 о
D S Резерв
Длина разрыва


где D - бит, определяющий является ли разрыв разрушающим или нет; S - бит, определяющий является ли разрыв срочным или нет: х - порядковый номер кадра по модулю 2.

Кадр BRKASK:

0 0 о Р о о 1 1
х 1 1 о о о о о


В фазе разрыва соединение не разрушается, обмен кадрами при этом продолжается. Однако модем игнорирует все кадры, кроме DISC и SABME. Прием кадра DISC подтверждается обычным образом, а прием кадра SABME вызывает переход в фазу установления соединения с исправлением ошибок. '

7.3.4. Управление потоком в V.42

Для управления потоком в протоколе V.42 используется метод скользящего (переменного) окна. Размер окна (М- 1) обычно равен 7 кадрам, в расширенной версии протокола - М- 1=127. Порядковые номера кадров лежат в пределах 0 ^ N(S) ^ М-1, где М - модуль порядковой нумерации. В неподтвержденном состоянии может находится не более М-1 кадров. Расширенная версия применяется при передаче по каналам с большими значениями задержки распространения сигналов, такими как спутниковые. 729.jpg

Рис. 7.11. Скользящее окно: до (а) и после {б) получения подтверждения Н(Р)='3

 

В качестве примера рассмотрим случай, когда все М кадров с номерами от О до М-1 не подтверждены. Кадр с номером N(R) подтверждает все предыдущие кадры, включая кадр с номером N(S)-1, и сообщает об ожидании кадра N(S). После того, как кадры с меньшими номерами получат подтверждения, номера этих кадров могут использоваться вновь. Таким образом, механизм порядковой нумерации по модулю М с подтверждениями устанавливает скользящее окно последовательных номеров, которые можно использовать в данный момент для нумерации передаваемых кадров. Пример организации скользящего окна при М=8 показан на рис. 7.11.

Вначале (рис. 7.11, а) предполагается, что кадры 1-5 являются неподтвержденными. Остается окно из двух кадров 6 и 7, так как неподтвержденных кадров должно быть не более М-1. Далее считается, что получено подтверждение с номером N(R)=3 (рис. 7.11, б). Оно подтверждает получение кадров 1 и 2, тем самым позволяя расширить используемое окно включением в него кадров 0 и 1.

7.3.5. Вычисление контрольного поля кадра

Рекомендация V.42 предусматривает применение как 16-разрядного, так и 32-разрядного контрольного поля кадра (FCS). Поле FCS-32 применяется при передаче данных по каналам с очень большим уровнем помех.

Поле FCS-16 представляет собой дополнение до "1" по модулю 2 двух следующих чисел:

> остатка от деления числа

xV+x^xVW+x^xV+x^xV+xV+x^+x^)

на образующий полином CRC-)6xl6+xl -l-:>:5-!-!, где k - количество бит в кадре, находящихся между последним битом открывающего флага и первым битом FCS (не включая эти биты), за исключением стаффинг-битов.

> остатка от деления по модулю 2 на образующий полином х +х +х +1 произведения х16 на содержимое кадра, находящегося между последним битом открывающего флага и первым битом FCS, за исключением стаффи нг-битов.

При типовой реализации вычисления FCS в передатчике сначала содержимое сдвигового регистра устанавливается в единичное состояние, а затем изменяется путем деления полей адреса, управления и информационного поля на образующий полином. Дополнение результирующего остатка до "1" передается в виде 16-разрядного контрольного поля кадра.

При типовой реализации в приемнике первоначальное содержимое ячеек регистра устанавливается равным " 1 ". Окончательный остаток после умножения последовательно входящих защищенных битов и FCS принимаемого кадра на х16 и последующего деления на образующий полином ^r^+^^+^+l, должен равняться при отсутствии ошибок передачи константе <0001 1101 0000 1111> (от л:15 до х соответственно). Если это не так, то принятый кадр считается ошибочным и запрашивается его повторная передача.

Вычисление FCS-32 принципиально ничем не отличается от вычисления 16-разрядного контрольного кадра. В данном случае используется образующий полином CRC-32 х^+х^+х^+х^+х^+х^+х^+х^+х^х^ A^+^+^+l. На приемной стороне правильность приема кадров с FCS-32 контролируется по константе <1100 0111 00000100 1101 1101 0111 1011>.