2. Проработка плоскости управления сценариями взаимодействия (L3)

         2.1. Назначение плоскости управления (сигнализации) радиосети, пояснение идеи двустороннего управления решениями на L3 уровне в виде "событие->воздействие->исполнение->уведомление об исполнении". Выделение основных служб плоскости управления и пояснение их задач.

        На служебном (L3) уровне реализуются разнообразные правила проведения сеанса связи, а с помощью формируемых на  этом уровне сигнальных (служебных) сообщений осуществляется согласованное выполнение этих правил. На служебном уровне формируются широковещательные сообщения на ведущем терминале, в нашем случае таким терминалом является УУ, а на служебном уровне ПО будет осуществляться прием широковещательного сообщения. То есть на L3 уровне будет необходима служба установления соединения, которая будет организовывать широковещательные сообщения. Рассмотрим идею двустороннего управления решениями на L3 уровне в виде "событие->воздействие->исполнение->уведомление об исполнении".

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

Таким образом можно выделить следующие службы L3 уровня:

• Служба установления соединения.
• Служба контроля качества активного соединения

2.2. Разработка иерархических моделей сетевых объектов - как транспортной платформы доставки информационных (п.1.1-1.4) и служебных сообщений (п.2.1). Выделение ключевых слоев модели (физические ресурсы - канал передачи данных - службы управления сеансом соединения/сценариями взаимодействия), пояснение задач служб уровней транспортной платформы.

Описание иерархической модели сетевых объектов будем проводить в соответствии с рекомендациями модели Open System Interconnection (OSI). Модель определяет различные уровни взаимодействия систем, каждый уровень выполняет определенные функции при таком взаимодействии.

Рассмотрим уровни модели OSI, необходимые в разрабатываемой системе (Рисунок 1).

Рисунок 1. Иерархическая модель сетевых объектов

Физический уровень (L1) - предназначен для взаимодействия с физической средой.

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

Служебный уровень (L3) - реализуются разнообразные правила проведения сеанса связи, а с помощью формируемых на  этом уровне сигнальных (служебных) сообщений осуществляется согласованное выполнение этих правил. 

2.3. Разработка правил идентификации сессий, сообщений, процедур/служб обработки сигнальных сообщений (задачи в п.2.1), а также сетевых объектов (организация адресного пространства радиосети).

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

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

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

2.4. Формирование диаграмм состояний сетевых объектов (выделенных узлов, терминалов) с учетом мер по обеспечению энергосбережения. Выделение активного и пассивного состояний сетевых объектов и анализ задач (режимов), выполняемых в этих состояниях.

После включения УУ, начнется осуществляться вещание широковещательного сообщения (BCCH), с определенной кодовой последовательностью (1). При обнаружении «необходимого» ПО, будет получен запрос на подключение (2). Если подключение будет подтверждено, то начнется обмен данными (3), если же в подключении будет отказано, то УУ вновь будет вещать BCCH (4). Во время проведения сеанса связи (обмен данными) периодически будет проводиться оценка качества связи (5). В случае прерывания сеанса связи или его завершения, УУ опять перейдет в состояние вещания BCCH (6). Если же команды управления не поступают на протяжении одной минуты, то УУ перейдет в энергосберегающий режим (режим сна) (7). При этом хотелось бы заметить, что если были получены команды управления, и была осуществлена их передача, то, так называемый, «отсчет» минуты будет начинаться после передачи команды стоп, то есть когда ПО не будет выполнять какие-либо команды управления. В режиме сна УУ будет отображать только данные GPS и телеметрии, которые ПО, находясь, соответственно, тоже в режиме сна, будет передавать раз в пять минут. Причиной же выхода из режима сна (8) является получение команд управления от пользователя. На основании вышесказанного диаграмма состояний УУ примет следующий вид:

Рисунок 2. Диаграмма состояний УУ

        После включения ПО, начнется осуществляться поиск широковещательного сообщения (BCCH), с определенной кодовой последовательностью (1). При обнаружении «необходимого» BCCH, будет отправлен запрос на подключение(2). Если подключение будет подтверждено, то начнется обмен данными (3), если же в подключении будет отказано, то ПО вновь будет искать BCCH (4). Во время проведения сеанса связи (обмен данными) периодически будет проводиться оценка качества связи (5). В случае прерывания сеанса связи или его завершения, ПО опять перейдет в состояние поиска BCCH (6).  Если же команды управления не поступают на протяжении одной минуты, то ПО перейдет в энергосберегающий режим (режим сна) (7). При этом хотелось бы заметить, что если были получены команды управления, и была осуществлена их реализация, то, так называемый, «отсчет» минуты будет начинаться после получения команды стоп, то есть когда ПО не будет выполнять какие-либо команды управления. В режиме сна ПО не будет транслировать видеопоток, с целью экономии заряда аккумулятора, а также передача данных GPS и телеметрии будет осуществляться раз в пять минут. Причиной же выхода из режима сна (8) является получение команд управления от УУ. На основании вышесказанного диаграмма состояний ПО примет следующий вид:

Рисунок 3. Диаграмма состояний ПО

2.5. Проработка ключевых сценариев взаимодействия объектов сети: обнаружение/идентификация сети, регистрация/привязка к сети, реализация сеанса предоставления услуги и т.п.. Разработка сценария, выполняющего оперативное реагирование на изменение качества соединения (как будет оцениваться качество соединения, как управлять свойствами активного соединения сетевых объектов).