Интегрированные сети ISDN (стр. 3 из 5)
Таким образом, можно идентифицировать факт потери информационного кадра (нужна ретрансмиссия) или отклика на него. После трех ретрансмиссий считается, что канал разорван, и предпринимается попытка его восстановить. FCS получается путем деления последовательности бит, начиная с адреса и кончая (но не включая) началом fcs, на образующий полином x16+x12+x5+1. Практически это делается с использованием сдвигового регистра, который в исходном состоянии устанавливается в единичное состояние. В конечном результате в регистре оказывается код остатка от деления. Дополнение по модулю 1 этого остатка и есть FCS.
Рис. 4.3.3.14 Схема вычисления контрольной суммы (FCS/CRC)
Другой возможной ошибкой является получение I-кадра с неверным номером N(S). Это возможно, когда LAP работает при ширине окна более 1. Если потерян кадр с номером N(s)=k, принимающая сторона не должна посылать подтверждение приема кадра k+1. Отклик при этом имеет тип REJ (см. таблица 4.3.3.1) с N(R)=k+1. Это укажет передающей стороне, что все кадры до k получены, но необходимо возобновить передачу, начиная с кадра k. При выявлении ошибки в N(R) связь прерывается, реинициализируются переменные состояния передающей и принимающей сторон, после чего канал восстанавливается, и обмен возобновляется с самого начала.
Таблица 4.3.3.1. (См. также раздел о протоколе X.25)
| Кодировка байтов | |||||||||
| Команда | Отклик | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
| Информационные кадры | |||||||||
| iframe | - | N(S) | 0 | ||||||
| Iframe | - | N(R | P/td> | ||||||
| Кадры управления (supervisory) | |||||||||
| RR | RR | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
| RR | RR | N(R) | P/F | ||||||
| RNR | RNR | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
| RNR | RNR | N(R) | P/F | ||||||
| REJ | REJ | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
| REJ | REJ | N(R) | P/F | ||||||
| Ненумерованные кадры | |||||||||
| SABME | - | 0 | 1 | 1 | p | 1 | 1 | 1 | 1 |
| - | DM | 0 | 0 | 0 | f | 1 | 1 | 1 | 1 |
| UI | - | 0 | 0 | 0 | p | 0 | 0 | 1 | 1 |
| DISC | - | 0 | 1 | 0 | p | 0 | 0 | 1 | 1 |
| - | UA | 0 | 1 | 1 | f | 0 | 0 | 1 | 1 |
| - | FRMR | 1 | 0 | 0 | f | 0 | 1 | 1 | 1 |
| P/F | poll=1 для команды, в противном случае конечный бит для отклика. |
| Iframe | (information frame) Информационный кадр |
| DISC | (disconnect) Отсоединить |
| RR | (receiver ready) Приемник готов |
| UA | (unnumbered acknowledge) Ненумерованное подтверждение |
| RNR | (receiver not ready) Приемник не готов |
| FRMR | (frame reject) Кадр отвергнут |
| REJ | (reject) Отказ |
| DM | (disconnect mode) Режим отключения |
| SABME | (set asynchronous balanced mode extended) Установка расширенного асинхронного сбалансированного режима |
| UI | (unnumbered information) Ненумерованная информация. |
Ниже на рис. 4.3.3.15 показана схема алгоритма восстановления после потери кадра RR.
Рис. 4.3.3.15 Восстановление системы после потери кадра RR
Сигнал RNR(получатель не готов) используется для запрета пересылки пакетов партнеру на уровне 2 и может использоваться при реализации приоритетных услуг. Другим пакетом, который специфицирован на уровне 2, является кадр frame reject (FRMR). Этот кадр может быть получен объектом второго уровня, но не может быть послан. При получении этого кадра система сбрасывается в исходное состояние. После завершения процедуры обмена разрыв канала производится путем посылки кадров DISC (disconnect) и отклика UA (unnumbered acknowledgment), с этого момента обмен кадрами I-типа не возможен. Кадр DM(disconnect mode) может выполнять те же функции, что и UA. Он используется в качестве отклика на SABME, если слой 2 не может установить связь, или отклика на disc, если связь уже разорвана.
Для управления и контроля за выделяемыми идентификаторами TEI предназначен специальный драйвер, который имеет возможность выделять и удалять используемые TEI. Все сообщения, связанные с TEI, передаются с помощью пакетов SAPI (service access point identifier). Так как работа с TEI должна выполняться вне зависимости от состояния уровня 2, все TEI-сообщения являются ненумерованными (UI) и не требуют отклика. Надежность достигается путем многократной пересылки пакетов. Пока терминалу не присвоен TEI (terminal endpoint identifier), используется широковещательный метод обмена. Все терминалы пользователя должны воспринимать любые управляющие кадры. Кадры управления в процессе присвоения TEI терминалу рассылаются широковещательно. Схема присвоения TEI и установления связи показана ниже на рис. 4.3.3.16:
Рис. 4.3.3.16 Алгоритм выделения TEI и формирования связи
Третий уровень X.25 служит для доставки управляющих сообщений даже в случае отказа сети, именно здесь выполняется реконфигурация маршрута, если это необходимо. Сигнальный пакет 3-го уровня имеет формат (рис. 4.3.3.17):
Рис. 4.3.3.17 Формат сигнального пакета уровня 3
Эти пакеты следуют от терминала к коммутатору и наоборот. Первый октет (поле протокольный дискриминатор) дает D-каналу в будущем возможность поддержки нескольких протоколов. Приведенный код соответствует стандартному управляющему запросу пользователя. Третий октет (поле код запроса - call reference value) используется для идентификации запроса вне зависимости от типа коммуникационного канала, где этот запрос может быть реализован. Четвертый байт характеризует назначение пакета (например, Setup - запрос установления канала). Возможные типы сообщений перечислены в таблице 4.3.3.2. Длина сообщения зависит от его типа. Стандарт не регламентирует содержания полей, следующих за полем тип сообщения, и они могут использоваться по усмотрению пользователя для расширения функциональных возможностей системы.
Таблица 4.3.3.2 Коды типов сообщений
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | Значение сообщение |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Переход к определенным типам сообщений: |
| 0 | 0 | 0 | - | - | - | - | - | Сообщения о состоянии: |
| 0 | 0 | 0 | 0 | 1 | Alerting (оповещение) | |||
| 0 | 0 | 0 | 1 | 0 | Call proceeding (состояние запроса) | |||
| 0 | 0 | 0 | 1 | 1 | Progress (прогресс) | |||
| 0 | 0 | 1 | 0 | 1 | Setup (начальная установка) | |||
| 0 | 0 | 1 | 1 | 1 | Connect (соединение) | |||
| 0 | 1 | 1 | 0 | 1 | Setup acknowledge (подтверждение начальной установки) | |||
| 0 | 1 | 1 | 1 | 1 | Connect acknowledge (подтверждение соединения) | |||
| 0 | 0 | 1 | - | - | - | - | - | Сообщения фазы запроса информации: |
| 0 | 0 | 0 | 0 | 0 | User information (пользовательские данные) | |||
| 0 | 0 | 0 | 0 | 1 | Suspend reject (отложенный отказ) | |||
| 0 | 0 | 0 | 1 | 0 | Resume reject (отказ возобновления) | |||
| 0 | 0 | 1 | 0 | 1 | Suspend (откладывание выполнения) | |||
| 0 | 0 | 1 | 1 | 0 | Resume (возобновление) | |||
| 0 | 1 | 1 | 0 | 1 | Suspend acknowledge (подтверждение откладывания) | |||
| 0 | 1 | 1 | 1 | 0 | Resume acknowledge (подтверждение возобновления) | |||
| 0 | 1 | 0 | - | - | - | - | - | Сообщения об устранении дефекта: |
| 0 | 0 | 1 | 0 | 1 | Disconnect (отсоединение) | |||
| 0 | 0 | 1 | 1 | 0 | Restart (повторный старт) | |||
| 0 | 1 | 1 | 0 | 1 | Release (освобождение) | |||
| 0 | 1 | 1 | 1 | 0 | Restart acknowledge (подтверждение повторного старта) | |||
| 1 | 1 | 0 | 1 | 0 | Release complete (освобождения завершено) | |||
| 0 | 1 | 1 | - | - | - | - | - | Прочие сообщения: |
| 0 | 0 | 0 | 0 | 0 | Segment (сегмент) | |||
| 0 | 0 | 0 | 1 | 0 | Facility (возможность) | |||
| 0 | 1 | 1 | 1 | 0 | Notify (обращение внимания) | |||
| 1 | 0 | 1 | 0 | 1 | Status inquiry (запрос состояния) | |||
| 1 | 1 | 0 | 0 | 1 | Congestion control (управление перегрузкой) | |||
| 1 | 1 | 0 | 1 | 1 | Information (информация) | |||
| 1 | 1 | 1 | 0 | 1 | Status (состояние) |
* Цифрами в верхней части таблицы пронумерованы биты кодов
В приведенной ниже таблице 4.3.3.3представлены информационные элементы, которые могут содержаться в сообщениях Setup (это самый сложный тип сообщений).
Таблица 4.3.3.3. Поля setup-сообщений
| Поле в пакете | Длина (октеты) | Комментарии |
| Дискриминатор протокола | 1 | |
| Код запроса | 2-3 | |
| Тип сообщения | 1 | |
| Передача завершена | 1 | Опционно, включается, если пользователь или сеть указывает, что вся информация включена в это сообщение Setup |
| Возможности канала | 6-8 | Описывает CCITT телекоммуникационные услуги (BC) |
| Идентификация канала | 2-? | Служит для идентификации канала в пределах isdn-интерфейса, управляемого данными процедурами |
| Специфические возможности сети | 2-? | Опционно |
| Дисплей | 2-82 | Опционно: IA5 (ASCII) символы для отображения на терминале |
| keypad | 2-34 | Альтернатива для пересылки кода вызываемого объекта. keypad может использоваться и для другой информации |
| Номер отправителя | 1-? | Опционно |
| Субадрес отправителя | 2-23 | Опционно |
| Номер адресата | 2-? | В случае направления пользователь-сеть является альтернативой keypad |
| Субадрес адресата | 2-23 | Опционно |
| Выбор транзитной сети | 2-? | Опционно |
| Совместимость с нижним уровнем (llc) | 2-16 | Опционно |
| Совместимость с верхним уровнем (hlc) | 2-4 | Опционно |
| Пользователь-пользователь | 2-131 | Опционно, когда вызывающий пользователь хочет передать информацию вызываемому |
Сигнальная система ISDN позволяет пользователю уже на фазе формирования канала с помощью запроса setup сформулировать требования к каналу, задав значение BC (bearer capability, см. таблицу 4.3.3.3), а также HLC (high layer compatibility) и LLC (low layer compatibility), характеризуя необходимый вид услуг. При этом проверяется совместимость запрашиваемых скоростей и имеющихся в распоряжении возможностей. HLC определяет тип сервиса или оборудования (телефон, факс группы 3 или 4, видеотекст), а LLC - быстродействие терминала пользователя, механизм адаптации к скорости передачи данных, контроль четности, синхронный/асинхронный интерфейс и т.д.). BC может принимать значения (например, “BC=speech”):