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

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

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

Физический уровень (L1) - предназначен для взаимодействия с физической средой. Так как видеопоток будет поступать в реальном масштабе времени, то его надобности в его обработки на канальном уровне не требуется, поэтому видеопоток будет поступать на физический уровень. Так же на физическом уровне будут происходить оценка качества связи (радиоизмерения), информация о которых сразу будет передаваться служебному уровню L3, минуя канальный уровень L2 (более подробно об этом будет сказано в пункте 2.5).

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

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

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

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

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

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

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

После включения УУ, будет осуществлен переход в режим сна (1). Из режима сна УУ сразу же выйдет в режим вещания BCCH (2). При обнаружении ПО, на УУ поступит запрос на регистрацию (3). При подтверждении запроса на регистрацию УУ вернется в режим сна (4), в случае отказа будет осуществлен переход назад, а именно в режим вещания BCCH (5). Периодически из режима сна УУ будет переходить в режим вещания BCCH (6), для того чтоб передать необходимую информацию о себе и сети на ПО. Из режима сна УУ переходи в режим отправки сообщения (7), откуда после завершения отправки сообщения вернется в режим сна (8). Также из режима сна УУ может перейти в режим приема сообщений (9), приняв все сообщения без ошибок, осуществится возвращение обратно в режим сна (10). Если же в процессе приема сообщений, были приняты сообщения с ошибкой, то будет происходить регистрация  номеров ошибочно принятых сообщений (11). Как было сказано ранее в пункте 2.1, при накоплении четырех ошибочных сообщений, будет сформировано сообщение о просьбе повторной передачи ошибочных сообщений (12). После отправки сообщения, содержащего просьбу о повторной передачи ошибочно принятых сообщений, произойдет переход в режим сна (8). Также УУ будет периодически выходить из режима сна, для того что бы провести оценку качества связи (радиоизмерения) (13), после оценки вновь вернется в режим сна (14). На основании вышесказанного диаграмма состояний УУ примет следующий вид (Рисунок 2).

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

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

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

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

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

Рисунок 4. Сценарии взаимодействия сети.

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

Рисунок 5. Оценка качества связи.

Библиографический список 

• Бакке А.В. – лекции по курсу "Системы и сети связи с подвижными объектами". 
• Антонов Д.В.-КП на тему «Радиосеть управления подвижными объектами» Часть 2. Исправленная  
• Баранова.А.В. - КП на тему «Радиосистема управления беспилотными объектами» Часть2. 
• Мичугин М. - КП на тему  "Радиосистема управления  подвижными объектами" 
• Макаркин И.И. - КР на тему  Радиосистема управления беспилотным аппаратом (часть 2)
• Рихард А.И. - КР на тему «Радиосистема управления подвижными объектами». Часть 1 (Исправленная 2)