ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 20.10.2024

Просмотров: 191

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Глава 1 аналоговые абонентские линии

1.1. Немного истории

1.2. Типы источников абонентской нагрузки

1.3. Сигнализация по аналоговым абонентским линиям: электрические параметры линий

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

1.5. Включение малых атс по абонентским линиям: исходящий вызов

1.6. Включение малых атс по абонентским линиям: входящий вызов

Глава 2 цифровые абонентские линии

2.1. Абонентские линии isdn

2.2. Интерфейсы в опорных точках

2.3. Пользовательский доступ isdn

2.4. Абонентские линии xDsl

Глава 3 протокол dss-1: физический уровень и уровень звена данных

3.1. Введение в dss-1

3.2. Физический уровень протокола dss-1

3.4. Уровень lapd: процедуры

Глава 4 протокол dss-1:сетевой уровень

4.1. Функции протокола q.931

4.2. Форматы сообщений

4.3. Процедуры обработки базового вызова

4.4. Процедуры пакетной передачи данных

4.5. Процедуры сигнализации «пользовательпользователь»

4.6. Дополнительные услуги

4.7. Вместо заключения

Глава 5 протокол qsig

5.1. Модель протокола qsig

5.2. Функциональное описание подсистем

5.3. Услуги и дополнительные сетевые услуги qsig

5.4. Протокол dpnss

Глава 6 открытый интерфейс v5

6.1. Три источника и три составные части сети доступа

6.2. Модель v5: услуги и порты пользователя

6.3. Протоколы и пропускная способность

6.4. Физический уровень протокола v5

6.5. Уровень lapv5

6.6. Форматы сообщений уровня 3

6.7. Мультиплексирование портов isdn

Глава 7 протокол ТфОп

7.1. Проблема ТфОп

7.2. Информационные элементы сообщений протокола ТфОп

7.3. Сообщения протокола ТфОп

7.4. Протокол ТфОп на стороне сети доступа

7.5. Протокол ТфОп на стороне атс

7.6. Процедуры протокола ТфОп

7.7. Национальные спецификации протокола ТфОп

Глава 8 служебные протоколы v5.2

8.1. Протокол назначения несущих каналов

8.2. Протокол управления трактами интерфейса v5.2

8.3. Протокол защиты v5.2

8.4. Протокол управления

Глава 9 протокол х.25

9.1. Модель взаимодействия открытых систем

9.2. Сети с коммутацией пакетов х.25

9.3. Архитектура протоколах.25

9.4. Применения протокола х.25

Глава 10 протоколы интернет

10.1. Протоколы tcp/ip и модель osi

10.2. Протокол управления передачей tcp

10.3. Протоколы udp и icmp

10.4. Межсетевой протокол ip

10.5. Протоколы нижнего уровня

10.6. Сетевые услуги в tcp/ip

10.7. Прогнозы по мотивам tcp/ip

Глава 11 реализация, тестирование и преобразование протоколов

11.1. Тестирование протоколов сети доступа

11.2. Оборудование сети абонентского доступа

11.3. Конвертеры протоколов сети доступа

Литература

В направлении от AN к LE используется информационный элемент «Уведомление-о-передаче», который информирует станцию об исполнении запроса передать импульсный сигнал (Pulsed-signal) или цифру (Digit-signal). Этот элемент уведомляет либо о начале передачи импульса, либо об окончании передачи единственного импульса или одного из импульсов в последовательности импульсов.

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

Необходимость передавать на станцию сведения о состоянии линии уже упоминалась. Такого рода сведения могут передаваться в информационном элементе «Данные-о-линии» (Line-information), который связан, в частности, с активизацией и деактивизацией в некоторых УАТС услуги переадресации вызовов путем особой маркировки импенданса линии. Кодировки параметров этого информационного элемента приведены в таблице 7.6. Все не указанные в таблице коды зарезервированы для будущих применений. Ограниченное использование информационного элемента «Данные-о-линии» обусловлено тем, что существуют альтернативные методы управления переадресацией вызовов.

Может потребоваться изменить период времени, в течение которого должен существовать сигнал. Это выполняется с помощью информационного элемента «Время-распознавания» (Recognition-time), используемого, например, когда нужно увеличить время распознавания, чтобы уменьшить вероятность ошибочной интерпретации состояния линии. Длина этого информационного элемента всегда составляет 4 байта, его передача осуществляется только в сообщении от АТС к сети доступа, а структура элемента представлена на рис. 7.4. В поле «сигнал» может помещаться код любого типа сигнала из приведенных выше в таблицах 7.2 и 7.3. Поле «тип длительности» содержит индекс той строки предварительно определенной в сети доступа таблицы, где указано время, в течение которого сигнал должен оставаться активным. Бит 7 четвертого байта всегда имеет значение 0.


Сообщения протокола ТфОП передаются в совместно используемых всеми портами ТфОП для этой цели С-каналах (или С-канале). Принимаемые сообщения проверяются, расшифровываются и обрабатываются. Все это вносит случайные задержки и сдвиги между моментами передачи в сеть доступа линейных сигналов, моментами передачи сетью доступа соответствующих сообщений к АТС, моментами передачи от АТС ответных сообщений и моментами реакции сети доступа на эти сообщения. Во избежание неразберихи АТС может потребовать от сети доступа автономно реагировать на некоторые линейные сигналы от абонентского оборудования. Такое требование, передаваемое только от АТС к сети доступа, содержится в информационном элементе «Активизировать-автономную-реакцию-на-сигнал» (Enable-autonomousacknowledge). Длина элемента составляет 4 байта для непрерывных сигналов и от 4 до 6 байтов для импульсных сигналов (рис. 7.5 и 7.6). Для полей «сигнал» и «реакция» используются кодировки, приведенные в таблицах 7.2 и 7.3. В том случае, если реакция является импульсным сигналом, к полям «тип длительности импульса», «индикатор подавления», «индикатор запроса подтверждения» и «число импульсов» применяются правила, которые были определены выше для информационного элемента «Импульсный-сигнал».

АТС может отменить автоматическую реакцию сети доступа с помощью сообщения, содержащего информационный элемент «Деактивизироватъ-автономную-реакцию-на-сигнал» (Disableautonomous-acknowledge). Данный информационный элемент также передается только в сообщении от АТС к сети доступа, а длина его всегда составляет 3 байта.

Некоторые сообщения сети доступа являются реакцией этой сети на последовательность сигналов, требующую, как правило, нескольких сообщений ТфОП. Такие предварительно определенные последовательности могут активизироваться информационным элементом «Автономное-управление-последовательностъю-сигналое» (Autonomous-signalling-sequence). Данный элемент передается только в сообщениях от АТС к сети доступа. Последовательность сигналов определяется с помощью поля «тип последовательности» (sequence type) в битах 1 - 4 (таблица 7.1).

Если сеть доступа должна послать соответствующий предварительно определенной последовательности ответ к АТС, этот ответ дается с помощью информационного элемента «Результатавтономного-управления-последовательностью-сигналов» (Sequence-response).


Имеется ряд информационных элементов, связанных с задачами обнаружения ошибок передачи и технического обслуживания. Для обнаружения ошибок передачи сообщения целесообразно нумеровать. С этой целью в сообщения вводится информационный элемент «Порядковый-номер» (sequence-number), представленный на рис. 7.7. Длина данного элемента всегда равна 3 байтам, и он может передаваться в обоих направлениях.

Информационный элемент «Порядковый-номер» должен обязательно присутствовать в сообщениях SIGNAL, PROTOCOL_PARAMETER и SIGNAL_ACK, но не разрешен в других сообщениях. В сообщениях SIGNAL и PROTOCOL_PARAMETER информационный элемент «Порядковый-номер» содержит порядковый номер передачи M(S), а в сообщениях SIGNAL_ACK - порядковый номер приема M(R).

В случае приема достоверного сообщения, которое не имеет смысла в контексте других ранее принятых сообщений, возникает необходимость выяснить состояние процесса в логическом объекте протокола ТфОП по другую сторону интерфейса. Для передачи этой информации служит информационный элемент «Состояние» (State), а причина его передачи указывается в информационном элементе «Причина» (Cause).

Длина информационного элемента «Причина» может составлять 3, 4 или 5 байтов, как это видно из рис. 7.8. Если длина составляет 3 байта, поле диагностики в информационный элемент не включается. Если длина составляет 4 байта, то четвертый байт является диагностическим и указывает идентификатор типа сообщения, вызвавшего передачу информации о причине. Если длина составляет 5 байтов, то диагностическими являются байты 4 и 4а, указывая идентификатор типа сообщения и идентификатор информационного элемента в сообщении, вызвавшего передачу информации о причине. Кодировка информационного элемента «Причина» приведена в таблице 7.7. Все остальные коды зарезервированы.

Может случиться так, что сообщение имеет правильный номер, имеет смысл в контексте обмена другими сообщениями, но содержащийся в нем запрос не может быть выполнен из-за отсутствия нужных для этого ресурсов. В такой ситуации в ответное сообщение вводится информационный элемент «Ресурс-недоступен» (Resource-unavailable). Цель данного информационного элемента сообщить АТС о недоступности ресурса, затребованного тем информационным элементом, который скопирован в поле копии возвращаемого к АТС элемента «Ресурс-недоступен». Элемент «Ресурс-недоступен» передается только в сообщениях SIGNAL от сети доступа к АТС. Длина этого элемента зависит от длины возвращаемой копии информационного элемента и может варьировать от 3 до 8 байтов.



7.3. Сообщения протокола ТфОп

Формат сообщения V5 представлен на рис. 6.7 предыдущей главы. Как и для других протоколов V5, сообщения протокола ТфОП состоят из:

а) уникального для протоколов V5 дискриминатора протокола,

б) адреса уровня 3, идентифицирующего порт, к которому относится данное сообщение,

в) типа сообщения,

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

В протоколе ТфОП предусмотрены девять типов сообщений, приведенных в таблице 7.8. Остальные коды типов сообщений протокола ТфОП (согласно таблице 6.4 предыдущей главы) зарезервированы для будущих применений.

Первыми двумя сообщениями ESTABLISH и ESTABLISH_ACK сторона сети доступа и сторона АТС обмениваются при создании сигнального пути в интерфейсе V5. Аналогичным образом, при освобождении сигнального пути производится обмен сообщениями DISCONNECT и DISCONNECT_COMPLETE.

В активной фазе по сигнальному пути идет обмен сообщениями SIGNAL и SIGNAL_ACK. В этой фазе АТС может также регулировать поведение сети доступа путем передачи сообщения PROTOCOL_PARAMETER.

В любой фазе процесса в интерфейсе V5 АТС может передать через интерфейс сообщение STATUS_ENQUIRY, например, если она получает не соответствующее контексту сообщение или по какой-либо другой причине. Сеть доступа передает через интерфейс сообщение STATUS в ответ на сообщение STATUS_ENQUIRY или при получении сообщения, не соответствующего контексту

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

Необходимо отметить, что в сообщениях ESTABLISH, ESTABLISH_ACK, SIGNAL и PROTOCOL_PARAMETER допускается присутствие только одного из указанных необязательных информационных элементов.

Сообщение ESTABLISH, содержание которого представлено в таблице 7.9, соответствует запросу создания сигнального пути для управления исходящим или входящим соединением ТфОП.