В рамках данной статьи рассмотрены
следующие пункты задания к курсовой работе:
2. Расчетная часть: проектирование
радиосети.
2.1. Проработка функционального состава сетевого терминала (выделенного узла сети),
отражающего
выполнение возлагаемых на объект задач.
2.2. Пояснение концепции решения следующей задачи:
- организация радиосети, идентификация
сетевых объектов
с
использованием ключевых звеньев доставки сообщений,
пояснение функций
каждого звена.
2.3. Характеристика информационного трафика в прямом и обратном
направлениях передачи: вид трафика, производительность и предполагаемый
объем сообщений, иные предполагаемые свойства трафика.
2.4. Обоснование иерархической модели сети -
как транспортной сети
доставки информационных и служебных сообщений. Выделение ключевых слоев модели (не менее трех),
пояснение назначения
протоколов обмена всех уровнях модели. Выделение радиоинтерфейса и
формулирование задач по передаче/приему сообщений службами различных уровней.
2.5. Стратегии поведения терминалов и выделенных узлов в радиосети. Анализ сценария взаимодействия сетевых объектов (выделенных узлов, терминалов) в рамках оказания услуг на прикладном (верхнем) уровне модели; задачи служб и характеристика сообщений прикладного уровня. Пояснение сеанса соединения, характеристика этапов "жизненного цикла" сеанса. Выделение активного и пассивного состояний сетевых объектов и анализ задач, выполняемых в этих состояниях.
2.6.
Анализ возможных решений по обеспечению энергосбережения. Построение диаграмм
состояний сетевых объектов, отражающих основные элементы разрабатываемого
сценария.
2.7.
Разработка протокола передачи сообщений канального уровня (L2).
2.7.1. Задачи служб канального уровня, характеристика видов сообщений: адресные/широковещательные, уведомительные или требующие обязательного ответа, служебное/информационное и т.п. Обоснование гарантированной/негарантированной доставки указанных видов служебных и информационных сообщений. Способы оценки целостности принимаемых сообщений.
2.7.2.
Обоснование способа реализации физических каналов связи. Формулирование
требований к алгоритму множественного доступа к физическим каналам связи,
обоснование предполагаемой структуры канального ресурса (на основании
п.2.2-2.6), реализующего двустороннего обмена сообщениями. Анализ предлагаемого
алгоритма множественного доступа на предмет возникновения коллизий и пояснение
решения по их устранению.
2.7.3.
Выделение типов и характеристика логических каналов (ЛКС) L2 уровня. Построение временной диаграммы, отражающей
двустороннюю доставку всех видов сообщений L2 уровня: пояснение очередности и
интенсивности передачи сообщений различных ЛКС (с учетом п.2.3). Проработка
шкалы времени диаграммы обмена сообщениями.
2.7.4.
Пояснение назначения и размерности полей сообщений канального уровня.
2.7.5. Расчет пропускной способности ЛКС в обоих направлениях. Сведение основных свойств ЛКС в таблицу.
Часть
2: расчетная часть. Проектирование радиосети.
2.1. Проработка функционального состава
сетевого терминала (выделенного узла сети), отражающего выполнение возлагаемых
на объект задач.
Проектируемая мной радиосеть состоит из
двух терминалов. Рассмотрим состав нашего сетевого терминала и задачи,
возлагаемые на терминал:
1)Наиболее важную задачу, которую
должен выполнять терминал - это передача, соответственно, прием радиосигналов второму терминалу (от второго
терминала). Передача данных должна осуществляться с требуемой скоростью.
Пользователям сети будет предоставлена возможность производить обмен информации
представленной в виде:
-аудио, видео, текстовых данных и
многое другое, в режиме реального времени.
Скорость, необходимая для передачи всех
видов данных, конкретно описана в пункте 1.1.
2)После того, как задача
передачи/приема решена, перейдём к следующей задаче, стоящей перед терминалами.
Т.к. при передаче на радиосигнал будет
действовать различные факторы, приводящие к искажению сигнала на приеме,
необходимо обеспечить помехозащищенность нашего сигнала, иными словами,
уменьшить степень искажения сигнала при распространении через среду передачи.
Также стоит отметить, для каждого вида
данных, которые мы будем передавать, будет определяться строго индивидуально
вероятность ошибки на бит. Принцип определения данного параметра для различных
видов данных, также описан в пункте 1.1.
3)Синхронизация сеанса связи является
важным этапом в процессе передачи/приема данных. В моём техническом задании
сказано о том, что инициатором сеанса
связи может быть любой узел, значит ни за одним из терминалов, не будет
стационарно закреплен статус мастер. Мастером сети будет являться тот терминал,
который первый отправил широковещательное сообщение другому терминалу в целях
установки синхронизации.
Терминал, который получил статус
мастера сети, в процессе всего сеанса связи будет неким *управляющим* для
ведомого терминала, это будет проявляться в следующем:
-во-первых, все начинается с того, что
мастер осуществляет первый передачу необходимых данных, ведомый просто
отвечает на эту передачу, никаких
признаков управления от него не следует.
-во-вторых, передача информационного
трафика со стороны ведомого терминала возможна, но только в случае согласия
мастера(если у мастера нет информации которую нужно передавать на данный
момент).
-в-третьих, команда, направленная на
завершение сеанса связи, поступает только от мастера сети.
-мастер сети будет определять переход
на другой профиль передачи (если это необходимо). Принимать данное решение
мастер сети будет на основе служебных сообщений приходящих от ведомого
терминала в процессе передачи (далее данный процесс принятия решения будет подробно
рассказан). Постоянное поддержание синхронизации терминалов, не соответствует
важному критерию, как энергосбережение, потому что аппаратура, как на приемной,
так и на передающей стороне, будет постоянно отправлять и соответственно
принимать сигнал синхронизации. Сигнал синхронизации будет отправляться
терминалом только тогда, когда требуется установление связи, поэтому
предложенный мной вариант синхронизации, будет более уместен. В период, когда
ни одним из терминалов не отправляется сигнал синхронизации, они будут
находиться в пассивном режиме. Данный режим подразумевает что наши терминалы
будут периодически просыпаться (т.е. заранее определен период пробуждения), для
прослушивания канала, т.е. для того, чтобы понять, отправлял ли сигнал терминал
на другой стороне, если такой сигнал обнаружился, то терминал переходит в
активный режим, т.е. запускается процесс, направленный на организацию связи с
последующей передачей данных, если сигнал не был обнаружен, то терминал остается
в пассивном режиме. В описанной ситуации не предусмотрено условие, при котором
может произойти экстренное прекращение электроснабжения, и один из терминалов,
не будет иметь понятия, есть ли терминал на противоположной стороне в сети или
нет. Т.е. второй терминал будет впустую осуществлять процесс своего
периодического нахождения в сети. О данной ситуации очень подробно расписано в
пункте 2.5, в подпунктах 16 и 17.
После осуществления процесса
синхронизации, ведомый терминал отправляет подтверждение, о том что он в сети,
и готов к началу сеанса связи, т.е. готов к приему данных от мастера.(об этом
идет речь в следующем подпункте), таким образом осуществляется данный этап
организации сеанса связи.
4)Формирование запросов - это следующая
задача, которую должен выполнять терминал. Виды формирующихся запросов можно
разделить на две группы:
4.1)Первый терминал отправляет запрос *
разреши осуществить передачу* , на что, второй терминал отвечает *разрешаю передачу
или не разрешаю передачу*. (Более подробно об этом будет рассказано в пункте 2.5)
4.2) Необходимо иметь возможность
приемной стороне, формировать и отправлять запрос с просьбой осуществить повторную
передачу непринятых пакетов, или уведомление о принятом сообщении.( Более
подробно об этом будет рассказано в пункте 2.5)
5)Снижение энергопотребления.
Как было
сказано в пункте 3, основной режим в котором будут находиться терминалы - это
пассивный режим, в этом режиме будет наименьшее потребление энергии в сравнении
с активным режимом.
6)Задача
обеспечения корректного взаимодействия с устройством пользователя, в нашем
случае это ППК.
7)Проведение
радиоизмерений.
Проведение радиоизмерения
осуществляется каждым терминалом, для анализа качества канала связи.
Выполнение данной задачи занимает
важное место в процессе выбора пути развития сценария, текущего соединения. В
результате выполнения данной задачи, полученные сведения подвергаются анализу
информационной подсистемой терминала. В конечном итоге, после анализа, в
зависимости от полученных результатов, выбирается такой профиль передачи, который
способен обеспечить передачу данных с наименьшими ошибками, т.е. обеспечить
передачу данных с наименьшими потерями.
Изобразим
функциональную схему данного устройства (рисунок 1):
Рисунок 1 Функциональный состав
терминала.
Функциональная схема терминала будет состоять, условно говоря из :
1)Модулей, в которых будут происходить преобразования сигнала относящихся к
уровню L1(2-й модуль) или L2(1-й модуль).
2)Модуля управления сеансами.
3)Модуль информационной системы.
4)Модуль USB.
Анализ деталей функционирования
различных уровней будет описан в последующих пунктах данной курсовой
работы.
2.2.Пояснение концепции решения следующей задачи:
-организация радиосети, идентификация сетевых объектов с использованием ключевых звеньев доставки сообщений, пояснение функций каждого звена. Обоснование требуемой архитектуры радиосети.
Пояснение концепции решения указанной
выше задачи и обоснование требуемой архитектуры радиосети были подробно мной
рассмотрены в пункте1.1. и пункте1.2., а
также, частично, об этом было сказано в пункте 2.1. Соответствующая ссылка
будет размещена в списке литературы.
2.3. Характеристика информационного
трафика в прямом и обратном направлениях передачи: вид трафика, производительность
и предполагаемый объем сообщений, иные предполагаемые свойства трафика.
Согласно работе моей системы связи,
необходимо будет организовать один аудиоканал, потому что, обмен будет
происходить строго между двумя пользователями. При передаче речи, достаточно
будет использовать скорость передачи 64 кбит/с, а с учетом сжатия речи без
потерь, отведем полосу пропускания для аудиоканала ≈ 16кбит/с, для решения
данной задачи, нам потребуется соответствующий речевой кодек. Для обеспечения
заданной скорости кодирования, будем использовать кодек G.728,
относящийся к категории LD-CELP (Low Delay - Code Excited Linear
Prediction - кодек с управляемым кодом линейным предсказанием и малой
задержкой)
При передаче видеопотока, также
необходимо организовать один видеоканал. Проведем расчет, направленный на поиск
необходимой пропускной способности канала при передаче видео с различным
разрешением и кодеком:
Рисунок 2. Анализ влияния
разрешения на требуемую пропускную
способность.
Т.о.
отведем на передачу видеопотока канал связи с полосой пропускания
порядка
3Мбит/с. (MPEG 4 с разрешением 640х480).
При
передаче текстовых файлов будем использовать канал связи с полосой пропускания
(0-16Мбит/с), т.е. если два вышеописанных канала связи используются, то под эту услугу выделяется оставшаяся часть пропускной
способности, а если два этих канала не используются, то под данную услугу
выделяется вся пропускная способность.
Для
разных протоколов передачи данных, т.е. для передачи протоколов передачи данных
будут требоваться свои каналы передачи данных на втором уровне с очень высоким
качеством защиты, для аудиоканала или видеоканала такой защищенности не
потребуется.
Потому
что если возникает ошибка, то мы все равно можем передать этот пакет, пусть
отображаться он будет с артефактами, смысл передаваемой информации не
изменится.
Но
если возникла ошибка при передаче данных, то потеря одного бита чревата потерей
всего, например если в процессе передачи
архива rar
или zip произошла потеря, то
они могут быть уже не читаемы.
При
передаче аудио трафика, потеря определенного количества пакетов содержащих в
себе передаваемую информацию, иными словами возникновение на приемной стороне
некоторого количества ошибок не является столь критичным, как при передаче
данных, т.к. не потеряется общий смысл передачи аудио трафика.
При
передаче данных будет функционировать служба АRQ (т.е. автоматический
повтор ранее переданного сообщения), в то время как, при передаче аудио и видео
трафика, функционирование данной службы
является неуместным. По всем каналам передачи данных, в рамках сеанса
передачи данных, а именно видео, аудио, данных, будет применяться различная
стратегия защиты передаваемой информации.
2.4. Обоснование иерархической модели сети - как транспортной сети доставки информационных и служебных сообщений. Выделение ключевых слоев модели (не менее трех), пояснение назначения протоколов обмена на всех уровнях модели. Выделение радиоинтерфейса и формулирование задач по передаче/приему сообщений службами различных уровней.
Рисунок 3 Иерархическая модель сети.
Имеется оконечное оборудование
пользователя, в рамках моей курсовой работы, оно представляет собой ППК. Внутри
которого, существует приложение, в рамках операционной системы. Непосредственно
с приложением взаимодействует пользователь. Приложение связано с терминалом
через определенный интерфейс.
-Уровень L4, т.е. транспортное
соединение, данный уровень будет формировать трафик. Транспортный уровень формирует запросы к L3 уровню: подготовить
соединение с определенной скоростью. Если требуется передача нескольких видов
данных одновременно, то в таком случае, транспортный уровень формирует и
отправляет команду L3
уровню, о том, что необходимо организовать одновременно 2-3 сеанса связи, т.е.
для речи, для данных, для видео, и каждому соединению будет присвоен свой сеанс
связи. Соответственно, под каждым сеансом будет подразумеваться отдельный вид
трафика. Подводя итог, можно сказать, транспортный уровень диктует условия
работы и L3
и L2 уровню. На транспортном уровне будет
осуществляться функционирование следующих служб:
-служба управления соединениями
-служба управления передачи аудиоданных
-служба управления передачи видеоданных
-служба управления передачи текстовых
данных
Транспортный уровень в данной модели
выполняет следующие функции:
1)Задает характеристики сессии, а именно,
какие данные будут передаваться, видео, аудио, текст.
2)Именно на этом уровне происходит
фрагментация пакетов, которые в последующем перемещаются на канальный уровень.
-Соответствующие сценарии
взаимодействия запускаются на L3 уровне, под воздействием команд
приходящих с L4.
Иными словами, на данном уровне характеризуется сценарий взаимодействия, т.е.
определяется фаза, а именно:
1)фаза 1 (видеоданные)
2)фаза 2 (аудиоданные)
3)фаза 3 (текстовые данные)
-Канальный уровень L2,другими
словами, уровень канала передачи данных (КПД), данный уровень предназначен для
безошибочной доставки пакетов канального уровня. Управлением данного уровня,
занимается L3
уровень, т.е. уровень сценария взаимодействия, и приложение предоставляет
трафик на L2
уровень. На этом уровне будет некий диспетчер, который будет делегировать
физические каналы под ту или иную потребность, а сам состав физических каналов,
будет рассмотрен позднее.
На данном этапе, согласно моей
концепции, будет присутствовать служба ARQ. Если актуален для
текущей сессии текстовый формат, т.е.
профиль №3, то будет задействована служба ARQ.
В случае осуществления передачи
видеоданных или аудиоданных, служба ARQ временно выключается, потому что, как
говорилось раньше, применение данной службы в случае передачи данных данного
формата не представляется уместным.
Также на данном уровне осуществляется
проверка целостности.
Также здесь же будет работать служба,
направленная на автоматическое регулирование мощности передатчика. Помимо этого
здесь происходит осуществление смены профиля передачи, который способен
обеспечить передачу данных с наименьшими ошибками, т.е. обеспечить передачу
данных с наименьшими потерями.
-Физический уровень L1, на данном уровне оперирует служба, в соответствии с которой, осуществляется помехоустойчивое кодирование/декодирование, перемежение/деперемежение, а также, синхронизация.
2.5. Стратегии поведения терминалов и выделенных узлов в радиосети. Анализ сценария взаимодействия сетевых объектов (выделенных узлов, терминалов) в рамках оказания услуг на прикладном (верхнем) уровне модели; задачи служб и характеристика сообщений прикладного уровня. Пояснение сеанса соединения, характеристика этапов "жизненного цикла" сеанса. Выделение активного и пассивного состояний сетевых объектов и анализ задач, выполняемых в этих состояниях.
Приведем предполагаемую стратегию
поведения терминалов в проектируемой радиосети.
Представим, что в нашей радиосети у
одного из терминалов имеются данные, которые необходимо передать другому
терминалу. Мастером сети будет являться тот терминал, который является
инициатором соединения.
Первый терминал прослушивает канал, в
случае отсутствия сигнала от второго терминала, отправляет запрос * разреши
осуществить передачу* , на что, второй терминал отвечает *разрешаю передачу или
не разрешаю передачу*, либо ответа вообще не последовало. В случае
отрицательного ответа или вообще отсутствия ответа, первый терминал
осуществляет повторный запрос, если не удается получить положительного ответа
спустя 2 попытки, то пользователю выводится информация о невозможности
организовать передачу, и соответственно причина проблемы(например слабый
уровень соединения и т.д.) В случае положительного ответа, пользователь осуществляет
передачу данных посредством своего ППК. Передача данных будет осуществляться
путём передачи пакетов, каждому из них будет присвоено свой номер(в случае
передачи текстовых данных).
При передаче, некоторое количество
пакетов, содержащих в себе часть передаваемой информации, могут быть искажены,
соответственно будет невозможно распознать информацию, передаваемую в этом
пакете. В данном случае необходимо иметь возможность приемной стороне,
формировать и отправлять запрос с просьбой осуществить повторную передачу этих
пакетов. Терминал на приемной стороне, будет отправлять отчет о принятых/непринятых
пакетах. Номера пакетам присваиваются для того, чтобы:
-решить проблему, рассмотренную выше
-расставить правильную последовательность передающихся пакетов
на принимающей стороне, т.к. пакеты могут прийти не в прямой
последовательности, согласно их отправке.
После успешного приёма, формируется
сообщение, сигнализирующее о том, что информация принята успешно, и данная информация выводится на экран пользователя.
Затем передающий терминал формирует запрос второму терминалу * последует ли
встречная передача данных?*, если ответ на этот запрос положительный, второй
терминал начинает процесс передачи
данных, если ответ отрицательный, то в данном случае процесс передачи будет
считаться оконченным.
Реализация охарактеризованного
алгоритма будет производиться с помощью временного разделения канала.
Рассмотрим подробнее на примере сеанса
передачи данных.
На сеансовом уровне актуализируется
сеанс, например, в данный момент будет сеанс передачи данных. Этот сеанс
означает передачу определенного файла в определенное сетевое расширение. Для этой
задачи требуется канал связи. Происходит обращение со стороны сеансового уровня
на L3-уровень
с просьбой предоставить канал связи. L3-уровень
удовлетворяет потребность сеансового уровня, предоставив определенный канал
связи. На сеансовом уровне имеется информация о том, что будет передаваться, а
также адрес, куда это будет передаваться. Поэтому, в момент, когда L3-уровень
ответил положительно на просьбу сеансового уровня, сеансовый уровень посылает
уведомление сеансовому уровню второго терминала типа *прими*. Таким образом,
начинается процесс приема, используя соединение, установленное на L2- уровне.
Есть некоторое приложение, в котором работает пользователь, допустим, в левом окне список файлов, которые он может передать, т.е. он обладает этими файлами, а в правом окне расшаренная сетевая структура, список файлов на втором объекте. Пользователь перемещает свой файл в расшаренное хранилище. Организуется сеанс, запрашивается канал у L3-уровня, предоставляется канал, устанавливается соединение с другим терминалом, тем самым устанавливается именно процесс передачи. Сеанс будет существовать до тех пор, пока он свою задачу не выполнит.
Пользователь перемещает свой файл в расшаренное хранилище
Осуществлен процесс передачи данных
Построим диаграмму сценария
взаимодействия сетевых объектов при передаче текстовых данных (рисунок 4)
Рисунок 4 Диаграмма сценария взаимодействия сетевых
терминалов при передаче текстовых данных
1) Прослушивание
канала, в случае незанятости отправить широковещательное сообщение второму
терминалу, сформировать запрос о разрешении передачи данных, с меткой о том, что
первый терминал будет являться мастером сети.
2) Ответ от второго терминала *Готов к
обмену*.
3) Процесс передачи данных.
4) Уведомление со стороны второго
терминала, о правильно принятых всех пакетах, переданных в данный момент
времени.
5) Продолжение процесса передачи
пакетов.
6) При окончании передачи этих пакетов,
второй терминал формирует запрос * Повтори передачу некоторых пакетов*.
7) Повторная передача запрашиваемых
пакетов.
8) Уведомление со стороны второго
терминала, о правильно принятых всех пакетах
9) Уведомление о завершении процесса
передачи, и запрос *Есть ли что передать в ответ?*
10) Ответ на запрос *Да,есть*.
11) Следует ответ первого терминала
*Готов к приему*
12) Начинается цикл передачи данных
Т2-Т1. После окончания передачи, от Т2 следует сообщение типа *Передачу
завершил, есть ли информация для обратной передачи*.
13) Мастер отвечает *Информации для
передачи нет, переходи в пассивный режим*
14) Т2 переходит в пассивный режим,
передав перед этим уведомление о принятой команде
15) Т1 переходит в пассивный режим.
16)
и 17) В описанной ситуации не предусмотрено условие, при котором может
произойти экстренное прекращение электроснабжения, и один из терминалов, не
имеет понятия, есть ли терминал на противоположной стороне в сети или нет.
В
данном случае стоит внести следующее:
-если
есть момент продолжительного простоя 20 минут, то оба терминала передают друг
другу служебное сообщение типа * я терминал(ID), нахожусь в сети*.
Таким образом, будет решена проблема аварийного выключения и прочие моменты.
(Для простоты, дадим краткое наименование подобному поведению терминалов в
сложившейся ситуации, например, (Found), на диаграмме Found
будет обозначено соответствующе.
Таким образом,
будет осуществляться сценарий взаимодействия сетевых терминалов при передаче
текстовых данных.
Построим диаграмму сценария взаимодействия сетевых объектов при передаче видеоданных (рисунок 5).
Рисунок 5 Диаграмма сценария взаимодействия сетевых
терминалов при передаче видеоданных
1)Прослушивание канала, в случае
незанятости отправить широковещательное сообщение второму терминалу,
сформировать запрос о разрешении передачи данных, с меткой о том, что первый
терминал будет являться мастером сети.
2)Ответ от второго терминала *Готов к
обмену*.
3)Терминал 1 начинает отправку видео пакетов.
4)После того как первый терминал передал несколько пакетов, второй терминал
отправляет информацию первому терминалу, следующего вида:
-уменьшить/увеличить мощность
передатчика, смени профиль передачи
(если есть на то причина) и т.д.
5)Первый терминал продолжает передачу
остальных пакетов, и данный цикл повторяется, до момента, когда будет передан
последний пакет.
6)Повторение пункта 4
7)Первый терминал уведомляет второго, о
конце передачи, попутно спрашивая, о том, есть ли информация, предназначенная
для передачи в его сторону.
8)Второй терминал отвечает *да, для
тебя есть информация, разреши начать передачу?*
9)Первый
терминал отвечает положительно на запрос
второго терминала.
10)Организуется
цикл передачи данных, как и в пунктах 3-7.
11)Повторение
пункта 4.
12)Повторение пункта 10. После
окончания передачи, от Т2 следует сообщение типа *Передачу завершил, есть ли
информация для обратной передачи*.
13) Мастер
отвечает *Информации для передачи нет, переходи в пассивный режим*
14) Т2
переходит в пассивный режим, передав перед этим уведомление о принятой команде.
15) Т1
переходит в пассивный режим.
16) и 17) (Found)
Таким образом,
будет осуществляться сценарий взаимодействия сетевых терминалов при передаче
видеоданных.
Выделение активного и пассивного состояния сетевых объектов охарактеризовано в пункте 2.1.
2.6.Анализ возможных решений по
обеспечению энергосбережения. Построение диаграмм состояний сетевых объектов,
отражающих основные элементы разрабатываемого
сценария.
Решения по обеспечению минимизации
энергопотребления:
1)Снижение энергопотребления будет
реализовываться путем применения определенного алгоритма установления
синхронизации между терминалами
(более подробно об этом рассказано в пункте
2.1, подпункт №3).
2) Основной режим, в котором будут находиться терминалы - это пассивный
режим, в этом режиме будет наименьшее потребление энергии в сравнении с
активным режимом.
3) Отталкиваясь от уровня принимаемого сигнала будет автоматически регулироваться мощность излучения передатчика.(см.п 1.2.)
При построении диаграмм состояний
сетевых объектов, смоделируем несколько возможных ситуаций возможного
взаимодействия терминалов:
- представим следующее, имеется
терминал, у которого нет информации,
которую необходимо передать второму терминалу в данный момент.
Данную ситуацию назовем, например,
модель А.
Иными словами, рассматриваемый
терминал в пассивном режиме, и с определенной периодичностью, будет
пробуждаться с целью прослушивания канала на наличие широковещательного
сообщения отправленного от второго терминала(см.п 1.2.).
Далее приведу диаграмму состояния нашего терминала, а далее будут приведены комментарии, наиболее подробно поясняющие данную диаграмму.(Рисунок 6)
Рисунок
6 Диаграмма состояния терминала ( модель А).
Для
обеспечения выполнения функций
возложенных на терминал, необходимо чтобы он был включен.
Основное
состояние, в котором будут находиться наши терминалы – это пассивный режим,
данный режим подразумевает следующее:
-при
отсутствии информации, которую нужно терминалам передавать, они будут
*просыпаться* с определенной периодичностью, для поиска широковещательного
сообщения от второго терминала,
в случае, когда данное сообщение не будет найдено, они будут продолжать находиться
в пассивном режиме.
В
данной рассмотренной диаграмме, у терминала нет информации для передачи, и он
проверят канал на наличие
широковещательного сообщения.
При
проверке было обнаружено данное сообщение .
Соответственно, терминал находится
в активном режиме. Стоит отметить процесс установления синхронизации.
Синхронизация будет осуществляться в момент, когда наш терминал принял
широковещательное сообщение от второго терминала, т.е. от мастера сети.
Как
было сказано ранее, (а если точнее в пункте 1.2. моей КР), мастером сети будет
являться тот, кто первый отправил широковещательное сообщение, направленное на
осуществление дальнейшей передачи. Т.е. подводя итог данного этапа диаграммы,
можно выделить несколько моментов:
1)На
данном этапе осуществляется синхронизация терминалов
2)На
данном этапе определяется статус терминалов: *мастер-ведомый*.
После
того, как был осуществлен приём широковещательного сообщения, ведомый терминал
отправляет мастеру сети сообщение типа *Готов к приёму, начинай процесс
передачи*.
Допустим,
мастер передает текстовую информацию, в этом случае, как было сказано немного
ранее, информация передается по пакетам,
все эти пакеты пронумерованы, в соответствии с их передачей. Затем следует
передача сообщения от ведомого терминала, в которой находится информация:
1)*повтори
передачу некоторых пакетов и соответственно, номер пакетов*, т.е. в данном
случае будет себя четко проявлять служба ARQ. Данная информация
будет передаваться только в случае реальной надобности.
2)*успешно
приняты все пакеты, продолжай процесс передачи*.
Таким
образом, будет осуществляться процесс передачи информации. После того, как
мастер передал последнюю группу пакетов, мастер отправляет запрос ведомому
терминалу, типа *Передача окончена, есть ли у тебя информация, требующая
обратной передачи?*.
Тем
самым, ведомый терминал может оправить сообщениеp,
содержащую в себе информацию двух типов:
1)*Для
обратной передачи, информации нет*
2)*Есть
информация, необходимая для обратной передачи, разреши начать передачу?*
В
первом случае, мастер отправляет уведомление ведомому терминалу типа *Завершение сеанса связи, переходи в
пассивный режим*. Ведомый терминал
аналогично отправляет уведомление типа *Понял, перехожу в пассивный режим*.
Таким образом завершается процесс приема/передачи информации, требующей
передачи на данный момент.
Во
втором случае, организуется аналогичный процесс передачи данных, рассмотренный
выше. После того как
ведомый завершил передачу, и у мастера нет данных для передачи, мастер
отправляет уведомление ведомому терминалу типа
*Завершение сеанса связи, переходи в пассивный режим*. Ведомый терминал
аналогично отправляет уведомление типа *Понял, перехожу в пассивный режим*.
Таким образом мы рассмотрели диаграмму состояний терминалов в ситуации под
названием *модель А*.
Следующая
ситуация возможного взаимодействия терминалов:
- представим следующее, имеется
терминал, у которого есть информация, которую необходимо передать второму
терминалу в данный момент.
Данную ситуацию назовем, например,
модель Б.
Иными словами, рассматриваемый
терминал изначально находится в пассивном режиме, и ему поступает задача,
передать определенную информацию.
Далее приведу диаграмму состояния нашего терминала, а далее будут приведены комментарии, наиболее подробно поясняющие данную диаграмму.(Рисунок 7).
Рисунок
7. Диаграмма состояния терминала (модель Б).
Для
обеспечения выполнения функций
возложенных на терминал, необходимо чтобы он был включен.
Основное
состояние, в котором будут находиться наши терминалы – это пассивный режим,
данный режим подразумевает следующее:
-при
отсутствии информации, которую нужно терминалам передавать, они будут
*просыпаться* с определенной периодичностью (начало каждого кадра), для поиска
широковещательного сообщения от второго терминала .
Для данного случая: терминалу необходимо передать информацию, он начинает прослушивать канал на наличие широковещательного сообщения, если данное сообщение найдено, то (см. схему последовательности выполнения операций терминалов( рисунок 6)). Если наш терминал не обнаружил широковещательного сообщения , то он осуществляет процесс передачи этого сообщения лично.
Послав
данное сообщение, от второго терминала приходит уведомление о готовности к
приему . Не следует
забывать, что именно на этапе приема
широковещательного сообщения устанавливается синхронизация между терминалами. С
этого момента наш терминал стал мастером сети, а второй терминал ведомым.
После
получения разрешения на передачу от ведомого терминала, мастер начинает процесс
непосредственной передачи информации, как было рассмотрено выше, т.е. по пакетам .
Также здесь будет выполнять свои функции служба ARQ (о данном этапе, подробно написано в модели А). После окончания передачи, мастер формирует сообщение ведомому терминалу * Передача окончена*, есть ли у тебя информация, требующая обратной передачи?*.
В случае отказа, оба терминала переходят в пассивный режим , а в случае положительного ответа, организуется процесс обратной передачиr, и в конце, когда у терминалов не будет никакой информации ориентированной на передачу, они оба переключатся с активного режима в пассивныйs.(Более подробно о данных этапах рассмотрено в описании к модели А).
2.7. Разработка протокола передачи сообщений канального
уровня (L2).
2.7.1. Задачи служб канального уровня, характеристика видов сообщений: адресные/широковещательные, уведомительные или требующие обязательного ответа, служебное, информационное и т.п. Обоснование гарантированной/негарантированной доставки указанных видов служебных и информационных сообщений. Способы оценки целостности принимаемых сообщений.
В
соответствии с моей курсовой работой, канальный уровень предназначен для диспетчеризации, т.е.
выбора определенного количества физических каналов под конкретную услугу.
Также, данный уровень предназначен для проверки обеспечения заданного качества
услуги, т.е. служба ARQ. Данная служба актуальна для сессии,
в процессе которой передается текстовый формат, т.е. профиль №3. В случае осуществления передачи
видеоданных или аудиоданных, служба ARQ временно
выключается, потому что, применение
данной службы в случае передачи данных данного формата не представляется
уместным. Необходимо отметить следующее:
-на канальном уровне вводится понятие CRC-код, с помощью
данной функции, будет определяться целостность передаваемых пакетов, также в
пакетах выделяются поля адреса, типа пакета, номер пакета (в случае передачи
текстовых данных).
В состав канального уровня
будет входить служба, направленная на фрагментирование пакетов, поступающих с
транспортного уровня, т.е. с приложения. Т.е. будет осуществляться фрагментация
как на транспортном уровне, так и на канальном, разница будет заключаться в
размерности фрагментирования, а именно, на канальном уровне будет осуществляться
более мелкое фрагментирование, чем на транспортном. Фрагментация на канальном
уровне будет осуществляться с целью структурирования потока битов в L2-пакеты, которые будут иметь ограниченные
размеры. В свою очередь, данные пакеты L2 уровня, будут в соответствии с определенными
правилами фрагментироваться на L1 уровне. Все это несет единую цель, обеспечение
структуризации при передаче данных. Данные должны передаваться в соответствии с
выстроенной моделью передачи данных.
Характеристика видов
сообщения
1)Сообщение трафика.
Данный вид L2-сообщений
будет использоваться (по надобности):
-службой передачи
аудио трафика
-службой передачи
видео трафика
-службой передачи
данных
Данный вид сообщений
относится к информационным сообщениям, адресным,
и в зависимости от вида передаваемого трафика подразделяются на 2 группы:
-требующие ответа
целостности доставки
-не требующие ответа о
целостности доставки
К первой группе
относятся сообщения, в которых передается текстовый трафик.
Ко второй группе
относятся сообщения, которых передается видеотрафик и аудиотрафик.
2)Широковещательные
сообщения.
Данный вид L2-сообщений
будет использоваться службой установления соединения.
В данной курсовой
работе, данные сообщения служат для организации
соединения между терминалами, и соответственно, для их синхронизации и
т.д. В случае, когда один из терминалов принял данное сообщение, немедленно
следует ответ, о готовности к ведению обмена информацией.
3)Служебные сообщения.
Данный вид L2-сообщений
будет использоваться, например, службой контроля передачи данных
К данному роду сообщений можно отнести, следующий вид сообщений:
-сообщения-уведомления, которые посылают друг другу терминалы:
1)Целостность принятых
пакетов;
2)Уровень принимаемого
сигнала;
3)Запрос на обратную
передачу;
4)Решение о переходе в
пассивный режим;
Для всех рассмотренных сообщений, будь то
информационные, или служебные,
необходимо высокое качество доставки передаваемой информации, вследствие
чего, наибольшую вероятность ошибки на бит примем равную: Pb = 1*10-7 (в
соответствии с ТЗ).
2.7.2.Обоснование
способа реализации физических каналов связи. Формулирование требований к
алгоритму множественного доступа к физическим каналам связи, обоснование
предполагаемой структуры канального ресурса (на основании п.2.2-2.6),
реализующего двустороннего обмена сообщениями. Анализ предлагаемого алгоритма
множественного доступа на предмет возникновения коллизий и пояснение решения по
их устранению.
В
соответствии с моей курсовой работой, организуемая радиосеть состоит всего из
двух терминалов, доступ к физической среде будет осуществляться по требованию.
Как было сказано выше, передача данных будет осуществляться только тогда, когда есть информация, требующая передачи,
т.е. в момент отсутствия данной информации, ни информационные, ни служебные
сообщения передаваться не будут. Будет использоваться временное разделение
каналов, это означает, что в отдельно взятый момент времени, только один из
терминалов будет обладать полным доступом к физической среде. Так как,
участниками сети являются два терминала, то о проблемах коллизий, не может идти
речь.
2.7.3. Выделение типов и характеристика логических каналов (ЛКС) L2 уровня. Построение временной диаграммы, отражающей двустороннюю доставку всех видов сообщений L2 уровня: пояснение очередности и интенсивности передачи сообщений различных ЛКС (с учетом п.2.3). Проработка шкалы времени диаграммы обмена сообщениями. Расчет пропускной способности ЛКС в обоих направлениях.
В соответствии с моей концепцией радиосети, на логическом
уровне можно выделить следующие каналы передачи сообщений:
1)Канал аудио трафика(TCHaudio)
2)Канал видео трафика(TCHvideo)
3)Канал передачи
данных(TCHdata)
4)Широковещательный
канал(BCCH).
5)Канал передачи ответа на запрос (SDCCH)
6)Подтверждение передачи (SАCCH)
-Канал аудио трафика(TCH) – данный логический канал предназначен для адресной передачи
пакетов аудио трафика. Скорость передачи будет 64кбит/с, но с учетом сжатия
речи, передача будет осуществляться со скоростью 16 кбит/с.
Так как есть риск не
правильно принять данные пакеты, то в случае ошибки принятия одного пакета,
пользователь, на приемной стороне, не заметит возникшую ошибку.
Таким образом, пропускная способность, для данного канала должна составлять 16 кбит/с.
-Канал видео трафика(TCH) - данный логический канал предназначен для адресной передачи пакетов видео трафика. Скорость передачи будет 3 Мбит/с. Руководствуясь тем, что выбранное разрешение передаваемого изображения( видео) 640х480, в пакете будет передаваться фрагмент картинки равный 28х21. Таким образом, пропускная способность, для данного канала должна составлять 3Мбит/с или 3072 кбит/с
-Канал передачи данных - данный логический канал предназначен для адресной передачи пакетов данных. Скорость передачи будет 4900 кбит/с или 4,79 Мбит/с, при условии, когда одновременно осуществляется передача аудио, видео, данных.( с учетом BCCH и SDCCH, SACCH), (см.ниже).
-Канал BCCH и SDCCH, SACCH – осуществление передачи по данным
канал, также будет задействовать некоторую часть доступного трафика.
На канал SDCCH и SACCH отведем 3% от общего трафика (153 кбит/с), а
на канал BCCH 1% (51
кбит/с).
Рассмотрим диаграмму двустороннего обмена сообщениями L2
уровня.
Рисунок 8. Диаграмма двустороннего
обмена сообщениями L2
уровня.
На данной диаграмме изображен
двусторонний обмен L2-сообщениями при передаче видео
трафика.
Терминал дает команду службе установления соединения отправить
широковещательное сообщение BCCH. Данная отправка осуществилась. Данный терминал
стал мастером сети а второй терминал, соответственно ведомым. Ведомый дает
команду службе установления связи на отправку сообщения о том что он в сети и
готов обмену данными. Данный процесс осуществился. Мастер приняв данное
сообщение, дает команду службе передачи видео трафика направленную на передачу
данных. Таким образом осуществляется таким образом осуществляется процесс
передачи данных.
После того как мастер завершил передачу видео трафика, он формирует команду
службе установления обратного соединения, отправить сообщение с соответствующим
содержанием. Процесс отправки осуществлен. Спустя несколько этапов передачи
служебных сообщений, организуется цикл обратной передачи. В результате, ведомый
терминал дает команду своей службе установления обратного соединения отправить
сообщение соответствующего содержания. В конце, когда ни у одного из терминалов
нет информации необходимой для передачи,
мастер формирует команду своей службе завершения сеанса связи, отправить
сообщение соответствующего типа ведомому терминалу. Данное сообщение
отправлено. Ведомый терминал принял данное сообщение, и дав команду своей
службе завершения сеанса связи отправить мастеру сообщение определенного
содержания.
Таким образом, мы рассмотрели двусторонний обмен сообщениями L2 уровня при передаче видео трафика.
2.7.4.
Пояснение назначения и размерности полей сообщений канального уровня.
Рисунок 9. Структура TCHvideo сообщения канального уровня
Type
– тип передаваемого сообщения – 4 бита
Информационное
сообщение – 588 бит
Длина
всего сообщения – 592 бита
Длина
информационного сообщения будет составлять 588
бит, т.к. изображение (видео) будет
передаваться фрагментарно, в моём случае, была выбрана фрагментация
размерностью 28х21, что и будет составлять
588 бит.
Как было сказано ранее, в соответствии с моей концепцией радиосети, на логическом уровне можно выделить следующие каналы передачи сообщений:
1)Канал аудио трафика(TCHaudio)
2)Канал видео трафика(TCHvideo)
3)Канал передачи данных(TCHdata)
4)Широковещательный канал(BCCH).
5)Канал передачи ответа на запрос (SDCCH)
6)Подтверждение передачи (SАCCH)
Поле пакета Type необходимо для того, что бы при передаче трафика, т.е. пакетов данных, приемник мог бы различить к какому типу трафика принадлежит принятый пакет, в соответствии с чем, произведем присвоение номера для каждого типа пакета:
- TCHaudio - [ 0 0 0 1 ]
- TCHvideo - [ 0 0 1 0 ]
- TCHdata - [ 0 0 1 1 ]
- BCCH - [ 0 1 0 0 ]
- SDCCH - [ 0 1 0 1 ]
- SАCCH - [ 0 1 1 0 ]
Рисунок 10. Структура TCHaudio сообщения канального уровня
Type
– тип передаваемого сообщения – 4 бита
Информационное
сообщение – 380 бит
Длина всего сообщения – 384 бита
Размерность информационного сообщения
выбрана согласно условию:
-речь будет
передаваться фрагментарно, по 23.75 мс т.к. это соответствует 380 битам.
Рисунок 11. Структура TCHdata сообщения канального уровня
Type
– тип передаваемого сообщения – 4 бита
Numb
– номер передаваемого пакета –3 бита
Информационное
сообщение – 345 бит
CRC –
(контрольная сумма на основе избыточного циклического кода) -
инструмент, служащий для осуществления проверки достоверности принятого
сообщения – 32 бита
Длина
всего сообщения – 384 бит
Длина
всего сообщения выбрана именно такой, из-за того, что скорость кодирования
будет применена для данного типа пакетов равная ½. Об этом все подробно
изложено в 3-ей части курсовой работы.(Ссылка будет в списке литературы)
Рисунок 12. Структура BCCH сообщения канального уровня
Type
– тип передаваемого сообщения – 4 бита
ID
- у наших терминалов есть свой ID, и в базе данных
будет записан как свой ID, так и ID второго
терминала. В составе BCCH сообщения будет находиться ID передающего
терминала, который будет известен только двум терминалам, соответственно,
принимая данное сообщение, терминал проверяет данный ID с ID находящимся
в базе данных, если они совпадают, то устанавливается синхронизация и
выполняются все дальнейшие действия, направленные на организацию передачи
данных – 8 бит
Информационное
сообщение – важно отметить, информационное сообщение будет включать в свой
состав информацию, необходимую для синхронизации терминалов – 120 бит
CRC –
(контрольная сумма на основе избыточного циклического кода) -
инструмент, служащий для осуществления проверки достоверности принятого
сообщения – 16 бит
Длина всего сообщения – 148 бит
Длина
полного сообщения для BCCH,
SDCCH,
SACCH выбрана
исходя соображений следующего рода:
- длина
пакета после помехоустойчивого кодирования, на физическом уровне будет
составлять 192 бита. (Для чего заложена именно
такая длина физического пакета, подробно изложено в третьей части
курсовой работы).
Рисунок 13. Структура SDCCH и SACCH сообщения канального уровня
Type
– тип передаваемого сообщения – 4 бита
Информационное
сообщение – 128 бит
CRC –
(контрольная сумма на основе избыточного циклического кода) -
инструмент, служащий для осуществления проверки достоверности принятого
сообщения – 16 бит
Длина
всего сообщения –148 бит
- длина
пакета после помехоустойчивого кодирования, на физическом уровне будет
составлять 192 бита. (Для чего заложена именно
такая длина физического пакета, подробно изложено в третьей части
курсовой работы).
2.7.5. Сведение основных
свойств ЛКС в таблицу.
Рисунок 14. Сведения
основных свойств ЛКС
Список используемой литературы:
1)Бакке
А.В. - лекции по курсу «Системы и сети связи с подвижными объектами».
2)https://lektsii.org/10-21442.html
3)https://markevich.by/raschet-videoarxiva-propusknoj-sposobnosti-seti
Ссылки
на предыдущие публикации и соответствующий раздел форума:
1)http://omoled.ru/publications/view/1160
2)http://omoled.ru/publications/view/1174
3)http://omoled.ru/publications/view/1189
4)http://omoled.ru/publications/view/1196
5)http://radiolay.ru/viewtopic.php?f=83&t=452