Федеральное государственное автономное - CORE

Федеральное государственное автономное

образовательное учреждение

высшего образования

«СИБИРСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»

Институт космических и информационных технологий

Кафедра «Вычислительная техника»

УТВЕРЖДАЮ

Заведующий кафедрой

О.В. Непомнящий

подпись

« » 2019 г.

МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ

Метод сетевого взаимодействия комплекса средств радиодоступа абонентов

09.04.01 — Информатика и вычислительная техника

09.04.01.06 — Микропроцессорные системы

Научный руководитель зав.кафедрой,канд.техн.наук


подпись, дата

Выпускник А.Ю. Харитонов


Рецензент нач.отдела А.В. Косолапов


Нормоконтролер доцент,канд.техн.наук

А.И. Постников


Красноярск 2019







УТВЕРЖДАЮ



подпись

« » 2019 г.

МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ

Унифицированный метод управления антенными постами

контрольно-измерительного комплекса космических аппаратов

09.04.01 — Информатика и вычислительная техника

09.04.01.06 — Технологии разработки программного обеспечения

Научный руководитель доцент,канд.техн.наук

В.А. Хабаров


Выпускник Д.В. Сафиуллин


Рецензент

подпись, дата должность, степень инициалы, фамилия

Нормоконтролер доцент,канд.техн.наук

А.И. Постников


Красноярск 2019







УТВЕРЖДАЮ



подпись

« » 20 г.

ЗАДАНИЕ

НА ВЫПУСКНУЮ КВАЛИФИКАЦИОННУЮ РАБОТУ

в форме магистерской диссертации

Студенту Харитонову Андрею Юрьевичу.Группа: КИ17-01-6м Направление (специальность): 09.04.01 Информа-

тика и вычислительная техника.Тема выпускной квалификационной работы: "Метод сетевого взаимо-

действия комплекса средств сетевого радиодоступа абонентов".Утверждена приказом по университету №Руководитель ВКР: О.В. Непомнящий, профессор, заведующий кафед-

рой, кандидат технических наук, кафедра ВТ ИКИТ СФУ.Исходные данные для ВКР: реализовать систему автоматизированного

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

Перечень разделов ВКР: анализ функционального состава и архитек-туры системы сетевого радиодоступа абонентов, разработка программноймодели протокола, разработка архитектуры программной части системы ра-диодоступа.

Перечень графического материала: структурная модель архитектурысистемы, структурная схема системы управления сетью персональной связи.

Руководитель ВКР О.В. Непомнящий

подпись

Заданиепринялкисполнению А.Ю. Харитонов

подпись

« » 20 г.

РЕФЕРАТ

Выпускная квалификационная работа по теме «Метод сетевого взаи-

модействия комплекса средств сетевого радиодоступа абонентов» содержит

61 страницу текстового документа, 23 рисунка, 2 таблицы, 32 использованных

источника.

СИСТЕМА СВЯЗИ, РАДИОДОСТУП, ПЛИС, ПРОТОКОЛ, АЛГОРИТМ,

МЕТОД.

Объект работы: метод сетевого взаимодействия комплекса средств се-

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

Задачи:

- выполнить анализ требований, предъявляемых к системе автоматизи-

рованного управления;

- разработать метод сетевого взаимодействия комплекса средств радио-

доступа абонентов, в том числе:

∙ архитектуру системы автоматизированного управления;

∙ способы обмена информацией в модулях программного проекта и

между аппаратной частью системы;

∙ метод взаимодействия программно-аппаратного комплекса систе-

мы автоматизированного управления.

- разработать программное обеспечение системы автоматизированного

управления.

Во введении раскрыта актуальность работы, сформулирована цель и

определены задачи на ВКР.

В первой главе изложены результаты анализа задания на ВКР, опре-

делены требования к разрабатываемой САУ, выполнен анализ протокола

доступа персональной связи, а так же физического уровня реализуемой си-

стемы.

Во второй главе изложены результаты разработки модели протокола

доступа персональной связи, а так же обоснована необходимость разработки

метода сетевого взаимодействия радиодоступа абонентов.

В третьей главе отображены результаты разработки архитектуры и

программной части системы, предложен метод взаимодействия аппаратно-

программного комплекса.

СОДЕРЖАНИЕ

Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1 Анализ функционального состава и архитектуры системы сетевого

радиодоступа абонентов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1 Основное назначение системы сетевого радиодоступа . . . . . . . . . . . . 6

1.2 Функциональный состав сети персональной связи . . . . . . . . . . . . . . . . 6

1.3 Архитектура сети радиодоступа персональной связи . . . . . . . . . . . . . 7

1.4 Требования к разрабатываемому ПО САУ КССРА . . . . . . . . . . . . . . . . . 8

1.5 Протокол доступа персональной связи . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5.1 Структура кадров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5.2 Типы пакетов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.3 Типы физических каналов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.3.1 Физический канал управления . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.3.2 Физический канал трафика . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.5.4 Временные счётчики . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5.5 Сетевые процедуры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5.5.1 Процедура синхронизации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5.5.2 Процедура регулирования мощности передатчика . . . . . . . . . 16

1.5.5.3 Процедура предоставления доступа . . . . . . . . . . . . . . . . . . . . . . . 17

1.5.5.4 Процедура подтверждения работоспособности станций . . . . 17

1.5.5.5 Процедура установления персональной связи . . . . . . . . . . . . . 18

1.5.5.6 Процедура передачи данных . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6 Физический уровень . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.7 Вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 Разработка программной модели протокола . . . . . . . . . . . . . . . . . . . . . . . 26

2.1 Общая модель системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Моделирование сетевых процедур . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.1 Процедура синхронизации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.2 Процедура регулировки мощности передатчика . . . . . . . . . . . . . . 29

2.2.3 Процедура подтверждения работоспособности станции . . . . . . . 31

2.2.4 Процедура предоставления доступа . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3 Вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Разработка архитектуры программной части системы радиодоступа 34

2

3.1 Выбор инструментария разработки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.1 Bare metal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.3 QNX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.4 Результаты сравнения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Архитектура САУ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Формы межзадачного взаимодействия QNX . . . . . . . . . . . . . . . . . . . 37

3.3 Архитектура программной системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4 Разработка программного обеспечения . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4.1 Система автоматизированного управления . . . . . . . . . . . . . . . . . . . 38

3.4.2 Поддержка интерфейсов физического уровня . . . . . . . . . . . . . . . . . 39

3.4.2.1 Пакет «Интерфейсы» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4.2.2 Интерфейсы для взаимодействия с ООД . . . . . . . . . . . . . . . . . . . 39

3.4.2.3 Элементы обеспечения телефонной связи . . . . . . . . . . . . . . . . . 40

3.4.2.4 Модули взаимодействия с пользователем. . . . . . . . . . . . . . . . . . 41

3.4.2.5 Пакет «Память» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4.2.6 Пакет «Интерфейс абонента» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4.2.7 Пакет «Контроллеры» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4.3 Реализация протокола персональной связи . . . . . . . . . . . . . . . . . . . 44

3.4.3.1 Пакет «Система синхронизации» . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4.3.2 Пакет «Режим работы системы» . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4.3.3 Пакет «Система регулировки мощности» . . . . . . . . . . . . . . . . . . 48

3.4.3.4 Пакет «Система управления сетью персональной связи» . . . 49

3.5 Вывод . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Заключение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Список сокращений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Список использованных источников . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Приложение А — Архитектура САУ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Приложение Б — Выбор типа пакета в служебном канале . . . . . . . . . . . . . . . 61

3

ВВЕДЕНИЕ

Спутниковая связь ҫ один из видов космической радиосвязи, осно-

ванный на использовании искусственных спутников Земли в качестве ре-

трансляторов. Спутниковая связь осуществляется между земными станция-

ми спутниковой связи (ССС), которые могут быть как стационарными, так и

подвижными. Принцип работы спутниковых систем навигации основан на

измерении расстояния от антенны на объекте (координаты которого необхо-

димо получить) до спутников [1ҫ4].

В рамках ВКР создана система автоматизированного управления, кото-

рая предназначается для обеспечения дистанционного управления цифро-

выми каналами станций спутниковой связи, работающих в сетях радио-АТС,

радиально-узловой связи, низкоэнергетических и носимых станций единой

системы спутниковой связи второй версии (ЕССС-2). Также, система поз-

воляет работать в сетях персональной и магистральной спутниковой связи

ЕССС-3 в режимах обработки сигналов на борту, при предоставлении циф-

ровых каналов по принципам радио-АТС (автоматическая телефонная стан-

ция) и (или) предоставления каналов по требованию по алгоритмам ЕССС-2

и по принципам радио-АТС с коммутацией каналов в ретрансляторе, дина-

мической коммутации каналов (маршрутизацией пакетов) в ретрансляторе

с обработкой сигналов на борту по алгоритмам ЕССС-3.

Разрабатываемая система позволит вести помехозащищённую радио-

связь в тактическом звене управления, обеспечивая работу в одном из шести

возможных режимах, с максимально возможной скоростью дуплексной пе-

редачи данных до 9.6 Кб/с при наличии в сети одновременно одного канала

радиотрафика, с возможным расширением до четырёх каналов.

Цель работы: реализация методов сетевого взаимодействия для си-

стемы автоматизированного управления (САУ) комплексом средств сетевого

радиодоступа абонентов.

Для достижения указанной цели в работе решаются следующие зада-

чи:

- анализ требований, предъявляемых к системе, а так же исходных дан-

ных;

- адаптация протокола организации доступа абонентской станции ра-

диодоступа (АСР) к цифровому каналу радиодоступа сети персональной

4

связи базовой абонентской станции радиодоступа (БАСР) к используемой

аппаратуре;

- разработка системы автоматизированного управления для комплекса

средств сетевого радиодоступа абонентов (КССРА).

Основные положения, выносимые на защиту:

- архитектура САУ для КССРА;

- методы и алгоритмы взаимодействия АСР, БАСР и ССС;

- методы и алгоритмы взаимодействия программной и аппаратной ча-

сти системы.

Научная новизна: предложен метод сетевого взаимодействия в со-

ставе комплекса средств сетевого радиодоступа абонентов, базирующийся

на протоколах ETSI EN 300 392 и IEEE 802.11, позволяющий организовать

работу оборудования сетевого радиодоступа.

Практическая ценность результатов работы заключается в разработ-

ке системы автоматизированного управления для комплекса средств сетево-

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

5

1 Анализ функционального состава и архитектуры системы се-

тевого радиодоступа абонентов

Увеличение эффективности использования каналов связи и пропуск-

ной способности группы ретрансляторов можно добиться на основе исполь-

зования принципа свободного доступа абонентов к общему частотному ре-

сурсу, получившему название "транкинг (или транк)"(Trunking — объедине-

ние в пучок) [5ҫ7].

В настоящее время в корпоративных сетях подвижной связи широ-

ко применяются транкинговые системы радиосвязи различных стандартов.

Такие системы необходимы в транспортных и энергетических отраслях, а

также в различных службах общественной безопасности, таких, как МЧС,

органы охраны правопорядка [8].

1.1 Основное назначение системы сетевого радиодоступа

Комплекс средств сетевого радиодоступа абонентов предназначается

для сопряжения цифровых каналов радиодоступа с цифровыми каналами

сетей персональной и магистральной спутниковой связи ЕССС-3, сетей пер-

сональной спутниковой связи ECCC-2, в том числе узловой, Радио-АТС, ма-

гистральной связи, сетей низкоэнергетических носимых станций. При этом

работа мобильных абонентов сети радиодоступа организуется в двух неза-

висимых наземных сетях ДМВ диапазона:

- персональная сеть радиодоступа со скоростями 1,2; 2,4; 4,8; 9,6 кбит/с;

- магистральная сеть радиодоступа со скоростями 64; 128; 256; 512; 1024;

2048 кбит/с.

1.2 Функциональный состав сети персональной связи

В состав сети персональной связи входят:

- базово-абонентская станция радиодоступа. Используется как в составе

станции спутниковой связи в роли базовой станции, так и в составе мобиль-

ного объекта связи (командно-штабных машин (КШМ)) в роли мобильной

6

станции. Данная станция обеспечивает передачу и прием информационных

потоков наземной сети радиодоступа, трансляцию цифровых потоков от ап-

паратуры дистанционного управления и коммутации каналов персональной

связи, инкапсуляцию этих потоков в транспортные пакеты и обратно, а так

же выполняет динамическую коммутацию логических каналов наземной се-

ти радиодоступа, кодирование-декодирование и модуляцию-демодуляцию

сигналов;

- абонентская станция радиодоступа. Данная станция используется в ка-

честве одноканальной абонентский станции, обеспечивающей радиодоступ

к цифровым каналам станции спутниковой связи при работе в персональной

сети радиодоступа;

- аппаратура дистанционного управления и коммутации каналов пер-

сональной связи. Данная аппаратура используется для обеспечения дистан-

ционного управления процессом организации каналов связи, станции спут-

никовой связи в сетях радио-АТС, радиально-узловой связи, в сетях низко-

энергетических носимых станций ЕССС-2 и ЕССС-3;

- шифровальная аппаратура связи (ШАС);

- оборудование обработки данных (ООД).

1.3 Архитектура сети радиодоступа персональной связи

Радиодоступ мобильных абонентов в КССРА, работающих в наземных

сетях персональной связи, обеспечивается на основе метода TDMA (Time

Division Multiple Access - множественный доступ с временным разделением

каналов) [9ҫ11]. Организуя, таким образом, от двух (со скоростью информа-

ционного обмена от 1,2 до 9,6 кбит/с) до четырех (со скоростями информа-

ционного обмена от 1,2 до 4,8 кбит/с) дуплексных каналов связи. При этом

организуемый логический канал радиодоступа может быть как закреплен-

ным за одной мобильной станцией, так и используемым в режиме доступа

по требованию несколькими мобильными станциями.

Схема радиодоступа абонентов сетейперсональной связи (ПС) строится

по принципам:

- «точка-точка», при котором мобильная станция организует связь с

БАСР, размещенной в составе станции спутниковой связи, по одному по-

7

лудуплексному логическому каналу радиодоступа;

- «звезда», при котором станция БАСР, размещенная в составе станции

спутниковой связи, организует связь по двум, трем или четырем полудуп-

лексным логическим каналам радиодоступа.

БАСРпри установке в ССС, для выполненияфункций базовой станции,

обеспечивает сопряжение с цифровыми дуплексными каналами ССС по фи-

зической линии через интерфейс С1-ФЛ-БИ (ГОСТ 27232-87) [12], и организу-

ет работу персональной сети радиодоступа, обеспечивающей беспроводной

доступ абонентских станций к среднескоростным цифровым каналам ССС.

Для управления доступом и коммутацией цифровых каналов между

БАСР и внешним оборудованием обработки данных, в составе мобильного

объекта, используется аппаратура дистанционного управления и коммута-

ции каналов персональной связи, подключаемая по физической линии через

интерфейс С1-ФЛ-БИ (ГОСТ 27232-87) [12].

АСР, при подключении внешней шифровальной аппаратуры связи по

физической линии через интерфейс С1-ФЛ-БИ (ГОСТ 27232-87) [12], а так же

ООД по физической линии через интерфейс Ethernet 10/100-Base-T (стандарт

IEEE 802.3), организует беспроводной доступ к среднескоростным цифровым

каналам базовой станции.

На рисунке 1.1 показана архитектура наземной сети радиодоступа ПС.

1.4 Требования к разрабатываемому ПО САУ КССРА

Разработаны следующие требования к системе автоматизированного

управления:

- САУ станций должны обеспечивать дистанционное управление циф-

ровыми каналами станций спутниковой связи, работающих в сетях радио-

АТС, радиально-узловой связи, низкоэнергетических и носимых станций

ЕССС-2, а также сетях персональной спутниковой связи ЕССС-3 с радио-

АТС, при предоставлении цифровых каналов по принципам радио-АТС или

по требованию по алгоритмам ЕССС-2, а также по принципам радио-АТС с

коммутацией каналов в ретрансляторе по алгоритмам ЕССС-3 при сопряже-

нии со станцией спутниковой связи по радиоканалу, организуемому в сети

радиодоступа.

8

Рисунок 1.1 — Общая структурная схема модели

- Устройства должны участвовать в выполнении функций обеспечения

радиодоступа к цифровым каналам спутниковой связи и коммутации внеш-

него ООД к организованному цифровому каналу с целью предоставления

доверенному абоненту, пользователю АСР, услуг телефонной связи и обме-

на SMS сообщениями с корреспондентом.

- САУ станции должна обеспечивать решение следующих задач:

∙ взаимодействие с абонентом по управлению режимами функци-

онирования станций, по формированию и вводу (установки) радиодан-

ных, необходимых параметров настройки станций, данных SIM карты;

∙ управление режимами работы станций и информационным обме-

ном;

∙ управление установлением соединений в сетях ПСС иМСС, вклю-

чая соединения с заданным абонентом, с сетью шифрованной связи, с

абонентами общегосударственной сети связи;

9

∙ управление получением и обработкой служебных сообщений;

∙ управление соединением (автоматическим подключением) внеш-

него ООД.

- Должно обеспечиваться управление станциями включая:

∙ управление вводом/выводомиз внешнихООДили от собственных

речепреобразующих устройств, пакетов информации;

∙ отработка стекапротоколов канального, сеансного, сетевогои транс-

портного уровня при организации обмена по радиолинии;

∙ взаимодействие с операторомпоуправлениюрежимамифункцио-

нирования станции, установки необходимых параметров при настройке

модемного оборудования;

∙ отображение на графическом экране служебной и пользователь-

ской информации.

1.5 Протокол доступа персональной связи

Радиодоступ мобильных абонентов в КССРА, работающих в сетях пер-

сональной связи, обеспечивается на основе метода TDMA [10]. При этом

работа тракта персональной связи на передачу и на прием осуществляется

на одной частоте на основе метода полудуплексной передачи с временным

разделением (Time Division Duplex — TDD) [13].

1.5.1 Структура кадров

Информация передается гиперкадрами длительностью 60 секунд. Ги-

перкадр состоит из 60 мультикадров длительностью по 1 секунде. Мульти-

кадр содержит 25 кадров, из которых первый кадр является контрольным.

При этом кадр имеет длительность 40 мс и содержит 4 временных интервала

(временных слота). Временной слот имеют длину 1200 бит, из которых 960 яв-

ляются информационными. Структура передаваемых кадров представлена

на рисунке 1.2.

Основным элементом в структуре передаваемых кадров является вре-

менной слот (интервал). Два временных слота используются для дуплексной

10

Рисунок 1.2 — Структура кадров

11

передачи с временным разделением, образуя один канал трафика. Продол-

жительность одного временного слота 0,01 секунды.

Каждый временной слот состоит из пяти субслотов, содержащих по 240

бит, для передачи данных, команд управления, синхронизирующих после-

довательностей. 240 битный субслот имеет продолжительность 0,002 секун-

ды.

1.5.2 Типы пакетов

На рисунке 1.3 показаны три основных вида пакетов используемых для

обмена информационными и управляющими сигналами между базовой и

мобильной станциями в обоих направлениях.

Формат пакета состоит из информационного поля, содержащего блок

данных, поля служебной информации, поля защитного интервала и поля

синхронизирующей последовательности, предназначенных для адаптиро-

вания радиотракта.

В зависимости от назначения используется 7 типов пакетов.

От мобильной станции к базовой станции:

- пакет управления;

- пакет управления мощностью передатчика;

- стандартный пакет;

- половинный стандартный пакет.

От базовой станции к мобильной станции:

- пакет синхронизации;

- стандартный пакет;

- половинный стандартный пакет.

1.5.3 Типы физических каналов

1.5.3.1 Физический канал управления

Физический канал управления включает в себя:

12

Рисунок 1.3 — Типы пакетов

13

- канал предоставления доступа — двунаправленный канал, используе-

мыйвсемимобильными станциямидляпроцедурыпредоставления доступа,

идентификации в сети персональной связи;

- канал сигнализации — двунаправленный канал, используемый всеми

станциями для передачи команд управления и синхронизации;

- канал управления на базе части ресурса канала трафика — двунаправ-

ленный канал, связанный с каналом передачи данных и использующий

часть его емкости для быстрой передачи команд управления.

Станции обмениваются по каналу предоставления доступа пакетами

синхронизации (от базовой станции) и пакетами управления (от мобильной

станции), содержащими команды управления процедуры предоставления

доступа.

Базовая станция передает каналу сигнализации пакеты синхрониза-

ции, содержащие информацию о сети (распределение временных интерва-

лов для передачи данных), информацию необходимую для временной син-

хронизации, а также информациюнеобходимуюдля регулировкимощности

передатчика мобильной станции.

1.5.3.2 Физический канал трафика

В системе передача и прием речи или данных осуществляется по ка-

налам трафика в режиме с коммутацией каналов. Трафик канал состоит из

двух временных слотов, работающих в режиме TDD.

В зависимости от необходимой скорости передачи и от количества

мобильных станций возможны шесть режимов с одновременной работой:

- первый режим — два дуплексных канала при скорости информацион-

ного обмена 9,6 кбит/с;

- второй режим — один дуплексный канал со скоростью информацион-

ного обмена 9,6 кбит/с, работающий на станцию спутниковой связи, и два

дуплексный канала со скоростью информационного обмена 4,8 кбит/с;

- третий режим — три дуплексных канала со скоростью информацион-

ного обмена 4,8 кбит/с;

- четвертый режим — четыре дуплексных канала со скоростью инфор-

мационного обмена 4,8 кбит/с;

14

- пятый режим — четыре дуплексных канала со скоростью информаци-

онного обмена 2,4 кбит/с;

- шестой режим — четыре дуплексных канала со скоростью информаци-

онного обмена 1,2 кбит/с.

В каждом из указанных режимов каналы трафика объединяются в ло-

гические каналы.

Логические каналы назначаются мобильному устройству после проце-

дуры подтверждения работоспособности станции. Переназначение логиче-

ских каналов происходит в процедуре установления связи, в зависимости от

режима работы сети персональной связи.

1.5.4 Временные счётчики

Выбор состояния системы должен определяться следующими счетчи-

ками:

- номер символа (SN — Symbol Number): 1 - 1200;

- номер временного интервала (TN — Timeslot Number): 1 - 4;

- номер TDMA-кадра (FN — Frame Number): 1 - 25;

- номер мультикадра (MN — Multiframe Number): 1 - 60.

Зависимость счетчиков между собой:

- SN увеличивается на единицу каждые 1/120 мс;

- TN увеличивается на единицу при достижении SN значения 1200;

- FN увеличивается на единицу при достижении TN значения 4;

- MN увеличивается на единицу при достижении FN значения 25.

Одновременное изменение счетчиков TN, FN, MN на значение 1 опре-

делятся временной меткой. Временная метка не учитывает требуемое сме-

щение по времени.

1.5.5 Сетевые процедуры

Сетевые процедуры определяют основные программные решения по

организациицифровых каналов радиодоступамобильных станцийна скоро-

стях 1,2; 2,4; 4,8; 9,6; 64; 128; 256; 512; 1024; 2048 кбит/с кцифровымспутниковым

каналам связи по протоколам ЕССС-2 и ЕССС-3.

15

1.5.5.1 Процедура синхронизации

Синхронизация в сети персональной связи задается базовой станцией

по данным времени от спутникового приёмника ГЛОНАСС/GPS для всех мо-

бильных станций с учётом длительности временных кадров. Для подстрой-

ки синхронизации при пакетной передаче данных базовая станция передает

стандартные обучающие последовательности и синхронизирующие после-

довательности.

Все временные интервалы, TDMA-кадры, мультикадры связаны меж-

ду собой набором счетчиков, непрерывно работающих, вне зависимости от

наличия передачи информации. Таким образом, как только мобильная стан-

ция определяет коррективы и установки данных счетчиков, все ее процессы

синхронизируются с базовой станцией.

Выбор временной метки. Временная метка задается по данным вре-

мени от спутникового приёмника ГЛОНАСС/GPS с периодом повторения 1

Гц. При этом базовая станция в канале сигнализации дополнительно сообща-

ет выбор времени (значение счетчика MN) при значении счетчика базовой

станции MN = 1 + 12T. Где T — целые числа от 0 до 4. Для учета смещения по

времени, в мобильных станциях, значение временной метки изменяется на

величину сдвига, автокорреляционной функции обучающей последователь-

ности, умноженной на 1/120 мс. А в случае отсутствия данных от спутни-

кового приёмника выбор времени устанавливается в канале сигнализации

при значении счетчика базовой станции MN = 1 + 4T. Где T — целые числа

от 0 до 14. Стоит отметить, что в канале сигнализации пакет синхронизации

передается в каждом субслоте в первом TDMA-кадре (FN = 1) во временном

интервале №2 (TN = 2). А отклонение по времени вычисляется на основа-

нии синхронизирующей и обучающей последовательностей получаемой в

пакете синхронизации.

1.5.5.2 Процедура регулирования мощности передатчика

Регулирование мощности передатчика происходит с целью опреде-

ления максимально-необходимого уровня сигнала на входе приемника ба-

зовой станции. Инициатором запуска процедуры регулирования мощности

16

является базовая станция на основании расчетного значения вероятности би-

товой ошибки в радиолинии. Расчет значения вероятности битовой ошибки

происходит при значении счетчика MN = 3+4M. Где M — целое число от 0 до

14.

В процессе регулировки мобильная станция изменяет уровень мощно-

сти передатчика каждые 16 бит поля управления мощности передаваемого

пакета. Базовая станция при этом измеряет значения вероятности битовой

ошибки.Номер 16 битовойповторяющейся последовательности, вероятность

битовой ошибки в которой была меньше или равна, передается мобильной

станции.

1.5.5.3 Процедура предоставления доступа

Процедура предоставления доступа к сети персональной связи выпол-

няет функции регистрации мобильных станций и персонализации абонен-

тов в системе.Инициаторомзапускапроцедурыявляетсямобильная станция.

Обмен пакетами со служебной информацией данной процедуры произво-

диться в канале предоставления доступа.

После включения мобильной станции и синхронизации всех счетчи-

ков, по данным времени от спутникового приёмника ГЛОНАСС/GPS, в те-

чение двенадцати мультикадров производится анализ среды передачи. В

зависимости от полученных в результате анализа данных, производится по-

пытка захватить свободный субслот канала предоставления доступа.

Получив подтверждение от базовой станции о закреплении субслота,

производится обмен командами идентификации мобильной станции в сети

персональной связи. В случае успешной идентификации, мобильной стан-

ции назначается субслот в канале сигнализации.

1.5.5.4 Процедура подтверждения работоспособности станций

Подтверждение работоспособности станции необходимо для опреде-

ления состояния мобильных станций в сети персональной связи. Инициато-

ром запуска процедуры подтверждения работоспособности является базовая

17

станция. Обмен пакетами со служебной информацией данной процедуры

производиться в канале сигнализации.

Процедура подтверждения работоспособности мобильной станции за-

пускается базовой станцией после завершения процедуры предоставления

доступа для закрепления зарезервированного субслота за мобильной стан-

цией и повторяется при значении счетчика MN = 2R. Где R — целое число от

1 до 30.

Для подтверждения работоспособности базовая и мобильная станции

обмениваются пакетами синхронизации и управления в канале сигнализа-

ции.

1.5.5.5 Процедура установления персональной связи

Процедура установления персональной связи в сетях ЕССС-2 и ЕССС-3

определяет форматы и структуру передаваемых и принимаемых служебных

команд, а так же алгоритмы управления логическими каналами и режимами

установления соединениями.

Запуск процедуры установления связи начинается с предоставления

мобильной станции каналов трафика объединенных в логические каналы, в

зависимости от режима работы, процедуры обмена служебными командами

базовой станции и приоритета мобильного абонента. Инициатором назна-

чения логических каналов для мобильной станции является как базовая, так

и мобильная станции.

На основании закрепленных логических каналов мобильной станции

предоставляется возможность устанавливать соединения по средствам об-

мена командами управления (структура команд и порядок их обмена опре-

деляется в зависимости от сети ЕССС) в канале управления на базе части

ресурса канала трафика.

Установив соединение, станции запускают обмен пакетами с речевой

информацией по каналам трафика в логических каналах.

18

1.5.5.6 Процедура передачи данных

Процедура передачи данных определяет принцип пакетирования пе-

редаваемого и принимаемого потока данных, а так же алгоритм передачи

данных в логическом канале.

Запуск процедуры передачи данных осуществляется после процедуры

установления персональной связи. Установив соединение, станции запуска-

ют обменпакетами сречевойинформациейпоканаламтрафика в логических

каналах.

Потокданных, поступающийсречепреобразующего устройства, обору-

дования обработки данных или шифровальной аппаратуры связи со скоро-

стями 1,2; 2,4; 4,8; 9,6 кбит/с, преобразуется, путем накопления поступающих

байтов, во фреймы. Фрейм состоит из 96 бит данных. Каждому сформирован-

ному фрейм в течение секунды назначается порядковый номер соответству-

ющий значению счетчика F (Frame).

Преобразованный таким образом поток данных поступает на сверточ-

ный кодер со скоростью R=1/2, а затем располагается в информационном по-

ле пакета. Информация описывающая порядок сформированных фреймов

записывается в поле служебной информации стандартного (половинного

стандартного) пакета.

При этом порядковый номер фрейма (Fi), входящий в состав поло-

винного стандартного пакета первого, второго и четвертого режима работы,

определяется в зависимости от номера TDMA-кадра (FN ) в течение кото-

рого был сформирован первый стандартный пакет (для скорости передачи

4,8 кбит/с) или первые два стандартных пакета (для скорости передачи 9,6

кбит/с):

- для первого режима работы логический канал 1, второго режима рабо-

ты логический канал 1, формулы 1.1, 1.2, 1.3, 1.4:

F1 =

FN, при FN = 1

105− 4 · FN, при 2 ≤ FN ≤ 25, (1.1)

19

F2 =

FN + 1, при FN = 1

106− 4 · FN, при 2 ≤ FN ≤ 25, (1.2)

F3 =

15− 4 · FN, при 1 ≤ FN ≤ 3

115− 4 · FN, при 4 ≤ FN ≤ 25, (1.3)

F4 =

16− 4 · FN, при 1 ≤ FN ≤ 3

116− 4 · FN, при 4 ≤ FN ≤ 25; (1.4)

- для первого режима работы логический канал 2 при запуске процеду-

ры передачи данных при значении счетчика MNi, где 1 ≤ i ≤ 60, форму-

лы 1.5, 1.6:

F1 = 5 · FN,при FN = 1, (1.5)

F2 = 5 · FN + 1,при FN = 1; (1.6)

- для первого режима работы логический канал 2 при продолжении пе-

редачи данных в последующих мультикадрах и до момента завершения

процедуры передачи данных, формулы 1.7, 1.8, 1.9, 1.10:

F1 = 3 · FN,при FN = 1, (1.7)

F2 = 3 · FN + 1,при FN = 1, (1.8)

F3 =

17− 4 · FN, при 1 ≤ FN ≤ 3

117− 4 · FN, при 4 ≤ FN ≤ 25, (1.9)

F4 =

18− 4 · FN, при 1 ≤ FN ≤ 3

118− 4 · FN, при 4 ≤ FN ≤ 25; (1.10)

20

- для второго режима работы логический канал 2, четвертого режима

работы логический канал 2, формулы 1.11, 1.12:

F1 =

49− 2 · FN, при 1 ≤ FN ≤ 24

53− 2 · FN, при FN = 25, (1.11)

F2 =

50− 2 · FN, при 1 ≤ FN ≤ 24

54− 2 · FN, при FN = 25; (1.12)

- для четвертого режима работы логический канал 1, формулы 1.13, 1.14:

F1 =

FN, при FN = 1

53− 2 · FN, при 2 ≤ FN ≤ 25, (1.13)

F1 =

FN + 1, при FN = 1

54− 2 · FN, при 2 ≤ FN ≤ 25; (1.14)

- для второго режима работы логический канал 3, четвертого режима

работы логические каналы 3, 4, формулы 1.15, 1.16:

F1 =

5− 2 · FN, при 1 ≤ FN ≤ 2

55− 2 · FN, при 3 ≤ FN ≤ 25, (1.15)

F1 =

6− 2 · FN, при 1 ≤ FN ≤ 2

56− 2 · FN, при 3 ≤ FN ≤ 25. (1.16)

Порядковый номер фрейма (F) входящий в состав стандартного пакета

канала трафика определяется согласно следующим выражениям:

- для первого режима работы логические каналы 1 и 2, второго режима

работы логический канал 1, формула 1.17:

1 ≤ F ≤ 100,при F ̸= F1, F ̸= F2, F ̸= F3, F ̸= F4; (1.17)

21

- для второго режимаработылогические каналы2и3, четвертого режима

работы логический канал 1, 2, 3 и 4, формула 1.18;

1 ≤ F ≤ 50,при F ̸= F1, F ̸= F2; (1.18)

Стоит отметить, что формирование первого пакета, при запуске проце-

дуры передачи данных, начинается только в момент приращения значения

счетчика FN.

В зависимости от режима работы в сети персональной связи организу-

ется обмен стандартными (половинными стандартными) пакетами с речевой

информацией между мобильной и базовой станцией.

1.6 Физический уровень

В качестве целевой физической системы используется SoC Zynq-7000

(XC7Z020) с аппаратно встроенным процессором ARM Cortex-A9.

Реализацияфизического уровня включает в себя как блоки внутреннего

взаимодействия, так и блоки, отвечающие за связь с внешним оборудовани-

ем, таким как ШАС, приёмо-передатчик канала связи, и пр.

Интерфейсы взаимодействия с оборудованием делятся на два типа, в

зависимости от подключения:

- подключённые непосредственно к процессору;

- подключённые к ПЛИС.

Данные типы подключения накладывают свои особенности работы с

каждым из интерфейсов.

Схема подключения интерфейсов процессора и его взаимодействия с

ПЛИС изображена на рисунке 1.4.

Для осуществления большейчасти взаимодействияпроцессораиПЛИС

используется интерфейс AXI [14, 15].

Протокол AXI представляет собой разновидность семейства протоко-

лов AMBA и является высокоэффективным средством, позволяющим осу-

ществлять взаимодействие между функциональными блоками в системах

на кристалле.

AXI интерфейс полностью поддерживается целевой системой и позво-

ляет производить соединение нескольких ведущих устройств с несколькими

22

Рисунок 1.4 — Схема процессорной части системы

ведомыми (рисунок 1.5).

AXI4-Lite интерфейс, преимущественноиспользующийся вработе, пред-

ставляет собой 32 разряднуюшинуданных с управляющими сигналами. Схе-

ма взаимодействия ведомого (процессора) и ведущих устройств изображена

на рисунке 1.6.

AXI протокол:

- используется когда требуется обеспечить высокуюпропускную способ-

ность и малое время задержки;

- поддерживается широким кругом компонентов;

- гибок в реализации для соединения различных архитектур.

Ключевые особенности AXI протокола:

- раздельные фазы адреса/управления и данных;

- поддержка передач невыровненных данных, применяя стробы байта;

- передачи на основе пакетов, с выдачей лишь начального адреса;

- выдачумножества внешнихадресов снеупорядоченнымиответами [16].

23

Рисунок 1.5 — Схема подключения устройств к AXI шине

Рисунок 1.6 — Схема взаимодействия устройств на шине

1.7 Вывод

На основании результатов анализа архитектуры, функционального со-

става, а также принципов и стандартов организации взаимодействия эле-

ментов и узлов системы радиодоступа абонентов сформирован перечень

основных требований к ПО САУ КССРА.

В том числе ПО должно обеспечивать:

- дистанционное управление цифровыми каналами станций спутнико-

вой связи;

- устройства должны участвовать в выполнении функций обеспечения

радиодоступа к цифровым каналам спутниковой связи;

- управление режимами работы станций и информационным обменом;

24

- управление получением и обработкой служебных сообщений;

- управление вводом/выводом из внешних ООД или от собственных ре-

чепреобразующих устройств, пакетов информации;

- отображение на графическом экране служебной и пользовательской

информации.

Выполнен анализ протокола доступа персональной связи, это позво-

лило определить перечень реализуемых процедур:

- процедура синхронизации;

- процедура регулирования мощности передатчика;

- процедура предоставления доступа;

- процедура подтверждения работоспособности станций;

- процедура установления персональной связи;

- процедура передачи данных.

На основании результатов анализа физического уровня, в том числе

процессорной части были определены необходимые модули и интерфейсы,

которые нужно реализовать в подсистеме взаимодействия с периферийным

оборудованием:

- модуль обработки пакетов Ethernet;

- модуль взаимодействия с ПЛИС по AXI шине;

- модуль взаимодействия с периферийными устройствами, расположен-

ными в ПЛИС.

25

2 Разработка программной модели протокола

Для осуществления имитационного прототипирования был исполь-

зован пакет MATLAB/Simulink [17ҫ21] и отладочные платы, использующие

целевую платформу SoC Zynq-7000 Avnet ZedBoard.

Модель протокольного уровня применяется для:

- симуляции работы протокола организации доступа абонентской стан-

ции к цифровому каналу радиодоступа сети персональной связи базовой

станции;

- совместной симуляции всей системы в составе модели протокольного

уровня и модели физического уровня;

- автоматической генерацииС кода и развёртыванииисполняемогофай-

ла на целевой платформе для тестирования и подтверждения принципов

работы разрабатываемого протокола персональной связи.

2.1 Общая модель системы

Общая модель системы состоит из модели базовой станции, модели

канала связи и модели мобильной станции. Общая структурная схема пред-

ставлена на рисунке 1.1.

Модели АСР и БАСР идентичны, поэтому их структурная схема пред-

ставлена на примере БАСР (рисунок 2.1).

Модель БС состоит из следующих элементов:

- модель физического уровня БАСР;

- модель протокольного уровня БАСР;

- имитаторы AXI интерфейса;

- генератор ПСП для алгоритма формирования сигнала;

- генератор ПСП для согласованного фильтра для алгоритма приёма сиг-

нала.

На рисунке 2.1 обозначены вход и выход модели физической системы.

На вход модель принимает оцифрованный сигнал на «нулевой частоте»

(Baseband). На выходе модель также формирует сигнал на «нулевой частоте».

Модель протокольного уровня БАСР содержит:

26

Рисунок 2.1 — Схема модели

- модель уплотнения TDMA БАСР;

- модель разуплотнения TDMA БАСР;

- модель реализации протокола организации доступа абонентской стан-

ции к цифровому каналу радиодоступа сети персональной связи БАСР.

Так как модель может быть использована как для реализации алгорит-

мов на аппаратной платформе, так и для симуляции, она содержит модель

имитации AXI интерфейса, эта модель используется при симуляции, для

имитации взаимодействия ARM процессора и ПЛИС. Это необходимо, по-

скольку модель протокольного уровня реализуется на ARM процессоре, а

модель физического уровня на ПЛИС.

2.2 Моделирование сетевых процедур

Разработана модель системы и выполнена генерация кода под целе-

вую платформу и отладки системы на инструментальных платах. Модель

организована на базе механизма State-Flow Diagram [22ҫ24].

27

2.2.1 Процедура синхронизации

Все временные интервалы (TN), TDMA-кадры (FN), мультикадры (MN)

вязаны между собой набором счетчиков (SN), непрерывно работающих, вне

зависимости от наличия передачи информации. Таким образом, как толь-

ко мобильная станция определяет коррективы и установки данных счетчи-

ков, все ее процессы синхронизируются с базовой станцией. Для подстройки

синхронизации при пакетной передаче данных базовая станция передает

стандартные обучающие последовательности и синхронизирующие после-

довательности.

Рисунок 2.2 — Модель процедуры синхронизации

Процедура синхронизации (рисунок 2.2) производится на мобильной

станции. В ходе этой процедуры проверяется содержимое пакетов синхро-

низации, которые отправляются базовой станцией. Счётчик packN считает

сколько безошибочныхприёмов пакетов было совершено (состояние SynYes).

Только в том случае если пять подряд безошибочных пакетов принято, про-

цедура переходит в состояние Counter, в котором запускаются системные

28

счётчики, синхронизированные с базовой станцией.

2.2.2 Процедура регулировки мощности передатчика

Регулирование мощности передатчика происходит с целью определе-

ния максимально-необходимого уровня сигнала на входе приемника базо-

вой станции. Инициатором запуска процедуры регулирования мощности

является базовая станция на основании расчетного значения вероятности

битовой ошибки в радиолинии.

Рисунок 2.3 — Модель процедуры регулировки мощности (мобильная стан-ция)

29

В процессе регулировки мобильная станция (рисунок 2.3) передает

пакет «регулировки мощности» состоящий из повторяющихся 16 битовых

комбинаций поля управления мощности. При этом базовая станция (рису-

нок 2.4), принимая данный пакет, измеряет значения вероятности битовой

ошибки.Номер 16 битовойповторяющейся последовательности, вероятность

битовой ошибки в которой была меньше или равна 0.062, передается мобиль-

ной станции.

Рисунок 2.4 — Модель процедуры регулировки мощности (базовая станция)

В состоянии PowerControlSending отправляется пакет с проверочными

битам. В состоянии PowerControlDetecting производится сравнение получен-

ных бит и определяется количество ошибочных бит. Команда по результатам

сравнения бит отправляется в состоянии PowerSetupSending.

30

2.2.3 Процедура подтверждения работоспособности станции

Подтверждение работоспособности станции (рисунок 2.5) необходимо

для определения состояния мобильной станций в сети персональной связи.

Инициатором запуска процедуры подтверждения работоспособности явля-

ется базовая станция.

Рисунок 2.5 — Модель процедуры подтверждения работоспособности (мо-бильная станция)

Состояние StateReq отправляет запрос, а состояние WorkModeDetecting

проверяет ответ. Если обмен сообщениями прошёл с ошибками, данная про-

цедура запускает процедуру предоставления доступа заново путём переклю-

чения переменной accessDone из состояния «1» в состояние «0».

31

2.2.4 Процедура предоставления доступа

Процедура предоставления доступа к сети персональной связи выпол-

няет функции регистрации мобильных станций и персонализации абонен-

тов в системе (приложение Б). Инициатором запуска процедуры является

мобильная станция.

После включения мобильной станции и синхронизации всех счетчи-

ков, в течение двенадцати мультикадров производится анализ среды переда-

чи. В зависимости от полученных в результате анализа данных, производит-

ся попытка захватить свободный субслот канала предоставления доступа.

Получив подтверждение от базовой станции о закреплении субслота,

производится обмен командами идентификации мобильной станции в сети

персональной связи. В случае успешной идентификации, мобильной стан-

ции назначается субслот в канале сигнализации.

Примоделировании случайным образом генерируется номер слота для

попытки доступа, далее осуществляется обмен сообщения между базовой и

мобильной станциями в соответствии с протоколом. Если все сообщения

принимаются корректно, но номер слота закрепляется за мобильной стан-

цией.

2.3 Вывод

В результате выполнения моделирования в среде MATLAB/Simulink

разработаны:

- модель процедуры синхронизации;

- модель процедуры регулировки мощности передатчика;

- модель процедуры подтверждения работоспособности станции;

- модель процедуры предоставления доступа.

Выполнена симуляционная отработка, котораяпоказала, что хотямоде-

лирование в среде Simulink и является необходимым условием качественной

разработки программного обеспечения, оно, само по себе, не может обеспе-

чить должныймеханизм взаимодействиямодулей, т.к. представляет систему

в неизменном виде, не адаптирующейся под реальные условия использова-

ния.

32

Не представляется возможным использовать такие возможности, как

разделение потоков, применение специальных методов, присущих, напри-

мер, операционным системам. Так же не представляется возможным опти-

мизировать работу системы с точки зрения скорости обработки пакетов и

приоритетности выполнения алгоритмов.

Исходя из поставленных задач и выводов, полученных в ходе модели-

рования системы, становится ясно, что необходимо разработать метод вза-

имодействия в составе комплекса средств сетевого радиодоступа абонентов,

позволяющий организовать работу оборудования сетевого радиодоступа.

33

3 Разработка архитектуры программной части системы радио-

доступа

3.1 Выбор инструментария разработки

Разработка будущей системы завязана на использовании SoC Zynq

фирмы Xilinx предоставляет определённый выбор целевой системы.

3.1.1 Bare metal

Разработка, без использования операционной системы имеет свои пре-

имущества. Она позволяет выполнять операции и производить расчёты на

максимально возможной скорости, так как отсутствует какое-либо внешнее

распределение ресурсов и времени (оно целиком ложится на плечи разра-

ботчика). Xilinx предоставляет определённые средства разработки, такие как

Xilinx SDK, однако их возможности не позволяют в полной мере обеспе-

чить разработчика удобным функционалом, таким, который предоставляют

операционные системы.

3.1.2 Linux

В сравнении с bare metal разработкой ОС Linux [25] предоставляет более

удобные механизмы взаимодействия с аппаратурой, что позволило бы уско-

рить разработку САУ. Однако, Linux не предоставляет настолько удобных

механизмов межпроцессного взаимодействия, как QNX.

Однако с другой стороны, генерация кода модели в Simulink для Linux

является самым простым решением создания кода системы.

3.1.3 QNX

QNX представляет собой UNIX-подобную операционную систему ре-

ального времени (ОСРВ) [26ҫ29], в основе которой лежит микроядерная ар-

хитектура (рисунок 3.1). Это позволяет взаимодействовать с аппаратными

34

ресурсами максимально эффективно, по сравнению с операционными си-

стемами, использующих архитектуру монолитного ядра (такими как Linux),

приближаясь по скорости к разработке без операционной системы (baremetal

development).

Рисунок 3.1 — Архитектура микроядра QNX

Кроме того, микроядро QNX, являясь связующим звеном для операци-

онной системы в целом, предоставляет эффективные способы межпроцесс-

ного взаимодействия (interprocess communication (IPC) services), что в свою

очередь позволяет изменять и наращивать базовую функциональность опе-

рационной системы без ущерба её стабильности и надёжности.

Основой межпроцессного взаимодействия в QNX является подсистема

обмена сообщениями. Полная интеграция данного механизма в архитектуру

операционной системы определяет её высокую производительность, эффек-

тивность и простоту.

3.1.4 Результаты сравнения

Определено то, что ввиду ограничений по ресурсам памяти использо-

вание сторонних библиотек не представляется возможным. Следовательно,

выбирать необходимо из возможностей предоставляемых непосредствен-

но операционными системами исходя из требований задания на ВКР и со-

путствующих документов. Результаты выбора инструментальной системы

представлены в таблице 3.1.

35

3.2 Архитектура САУ

Исходя из требований задания на ВКР и результата выбора целевого

инструментария была разработана архитектура САУ, изображённая в прило-

жении А.

Таблица 3.1 — Сравнительные характеристики инструментальных систем

Параметр Bare metal Linux QNX

Возможность ге-нерации кода изMatlab

- + -

Наличие механиз-мов межпроцессно-го взаимодействия

- + +

Наличие подсисте-мы обмена сообще-ниями

- - +

Использованиемикроядернойархитектуры ОС

- - +

Приемлемая ско-рость выполненияопераций

+ + +

Наличие механиз-мов отказоустойчи-вости

- - +

Работа в режиме ре-ального времени

- - +

Таким образом можно сделать вывод о целесообразности использова-

ния операционной системы реального времени QNX.

Так как в качестве целевой операционной системы была выбрана ОСРВ

QNX, в процессе разработки будут учитываться особенности микроядерной

архитектуры ОС. Она предполагает наличие множества программ и драй-

веров, работающих на одном уровне абстракции. Для обеспечения взаимо-

действия между модулями используется подсистема передачи сообщений

(Message Passing) [30].

36

3.2.1 Формы межзадачного взаимодействия QNX

Для разработки предложены формы межзадачного взаимодействия

QNX, которые описаны в таблице 3.2 [30].

Таблица 3.2 — Формы межзадачного взаимодействия

Служба Область реализации

Обмен сообщениями Ядро

Сигналы Ядро

Очереди сообщений POSIX Внешний процесс

Разделяемая память Администратор процессов

Неименованные программные каналы (pipes) Внешний процесс

Именованные программные каналы (FIFOs) Внешний процесс

В качестве основного средства был выбран обмен сообщениями, так

как он является основополагающим примитивом межзадачного взаимодей-

ствия, реализуется на уровне ядра (это означает высокую скорость передачи),

и позволяет работать как синхронно, так и асинхронно.

3.3 Архитектура программной системы

Использование ОСРВ QNX открывает широкие возможности для раз-

работки архитектуры приложения, позволяя распределить пакеты и модули

в соответствии с их предназначением, требуется лишь определить формат

взаимодействия между ними. При использовании механизма обмена сооб-

щениями QNX со стороны операционной системы неважно что передаётся в

межзадачных сообщениях, структура которых определяется разработчиком

в зависимости от существующих потребностей.

Таким образом, предложено разбиение намодули результирующей си-

стемы, что позволит проводить разработку каждого из модулей независимо

от остальных, архитектура которой представлена в приложении А, а её часть

изображена на рисунке 3.2.

37

Рисунок 3.2—Часть архитектуры системыавтоматизированного управления:служебные пакеты

3.4 Разработка программного обеспечения

3.4.1 Система автоматизированного управления

Разработка ПО проводилась в условиях ограничения памяти (∼10 Мб),

поэтому использование дополнительных библиотек, например Qt, не пред-

ставляется возможным. Однако, как уже было сказано выше, QNX предостав-

ляет множество механизмов, которые могут упростить работу разработчика.

В каждом пакете системы используется абстракция «Фасад». Данная

абстракция необходима для обеспечения связимежду различнымипакетами

системы.

38

3.4.2 Поддержка интерфейсов физического уровня

Исходя из требований задания на ВКР разработаны драйвера, которые

предназначены для поддержки интерфейсов взаимодействия физического

уровня, позволяющие пользователю взаимодействовать с системой, за ис-

ключением модуля тестирования:

- С1-ФЛ-БИ

- Ethernet

- AMBE

- Клавиатура

- Дисплей

- SIM-карта

3.4.2.1 Пакет «Интерфейсы»

Разнотипное оборудование, часть из которого подключено непосред-

ственно к процессорной части, а часть к части логики накладывает особен-

ности при разработке драйверов устройств. Например, интерфейсы, подклю-

ченные к ПЛИС предобрабатываются непосредственно в логике, в то время

как процессор выполняет лишь часть обработки, однако, интерфейсы, под-

ключенные к процессору требуют его непосредственного участия в первич-

ной обработке, в то время какПЛИСв этом случае занимается постобработкой

входных сигналов.

3.4.2.2 Интерфейсы для взаимодействия с ООД

Разработаныдрайверыинтерфейсов (С1-ФЛ-БИ, Ethernet), которыеобес-

печивают взаимодействие с внешним оборудованием обработки данных и

предназначены для охвата как можно большего количества типов внешних

устройств.

С1-ФЛ-БИ. Интерфейс С1-ФЛ-БИ [12] предназначен для сопряжения

БАСР с цифровым каналом связи при обслуживании сети персональной свя-

зи, а так же для возможности сопряжения АСР с ООД. В работе выполнен

39

в виде драйвера, который взаимодействует с логикой ПЛИС для обработки

команд. На вход драйвер получает данные из интерфейса С1-ФЛ-БИ, обраба-

тывает их в операционной системе, а затем так же, отдаёт сырые данные в

ПЛИС, которая занимается упаковкой и дальнейшей их отправкой.

Ethernet. В отличие от С1-ФЛ-БИ для БАСР интерфейс Ethernet необ-

ходим для сопряжения с цифровым каналом в сети магистральной связи. В

случае с АСР интерфейс Ethernet так же необходим для сопряжения с внеш-

ним ООД.

Обработка пакетов осуществляется при помощи программного пакета

pcap, данные обрабатываются на процессоре, затем вычленяются необходи-

мые составляющие пакетов и передаются в ПЛИС для добавления необходи-

мых заголовков и отправки во внутренний тракт связи.

3.4.2.3 Элементы обеспечения телефонной связи

AMBE-2000. Разработан драйвер интерфейса AMBE-2000, который ис-

пользуется для обеспечения телефонной связи в сети радиодоступа в составе

абонентских устройств в качестве речепреобразующего устройства (РПУ) ис-

пользуется вокодер АМВЕ-2000 фирмы Digital Voice System [31].

Данный вокодер является допустимым вариантом решения, так как

необходимо поддержать речевой канал связи с уже существующими станци-

ями спутниковой связи, так же использующие данный вокодер, кроме того,

он является гибким и дешёвым решением для обеспечения полудуплексной

связи.

Взаимодействие с вокодером осуществляется путём передачи сообще-

ний в управляющее IP ядро ПЛИС. Данное ядро имеет свою адресацию, кото-

рая отображается в адресном пространстве операционной системы и взаимо-

действие можно осуществлять с помощью записи/чтения соответствующих

адресов.

Для обеспечения мобильности связи дополнительно могут использо-

ваться гарнитура и тангента.

Телефонно-микрофонная гарнитура предназначена для обеспечения

двухсторонней радиотелефонной связи в полевых условиях.

На случай, если длина кабеля гарнитурыокажетсямала для соединения

40

со станцией АСР, предусмотрена тангента, которая обеспечивает подключе-

ние между гарнитурой и АСР.

3.4.2.4 Модули взаимодействия с пользователем

Разработано приложение для обеспечения взаимодействия с пользова-

телем, которое использует матричную клавиатуру и дисплей.

Дисплей. В работе используется дисплей, имеющий размер матрицы

128x80 с контроллером SSD1325. Дисплей реализует возможность отображе-

ния с использованием 16 оттенков основного цвета.

В целях сокращения используемых пинов процессора, обеспечения бу-

фера на запись и автоматизации процесса работы с дисплеем на ПЛИС было

реализовано IP ядро, обеспечивающее переход между AXI интерфейсом про-

цессора и SPI интерфейсом дисплея, рисунок 3.3. Данная схема отображает

пример реализации ПЛИС для работы с дисплеем и клавиатурой.

Рисунок 3.3 — Прошивка управляющей логики для проверки работы дисплеяи клавиатуры

41

Модуль дисплея реализуется в пакете «Интерфейс абонента». Он содер-

жит в себе описание используемого алфавита, набор заранее приготовлен-

ных элементов экрана, и подсистему приёма сообщений от других пакетов

с целью отображения специфичной информации. Например, получая ин-

формацию из пакета «Контроллеры», выводится статус сети, уровень заряда

батареи и сигнал навигационного приёмника.

Данный модуль содержит в себе библиотеку для работы с дисплеем,

а именно процедуры взаимодействия с логикой ПЛИС, процедуры отрисов-

ки, а так же управления дисплеем. Используя данную библиотеку можно

выводить на экран любые изображения, предварительно описав их в заголо-

вочном файле элементов интерфейса.

Модуль интерфейсов использует систему многопоточности QNX и ре-

ализует возможности межзадачного взаимодействия посредством реализа-

ции интерфейса взаимодействия с данным модулем. Кроме того, данный

модуль предоставляет точку входа в процедуры тестирования, являясь сер-

вером для клиентского компьютера с соответствующим программным обес-

печением.

3.4.2.5 Пакет «Память»

Разработанпакет памяти, представляющийсобой адаптер к хранилищу

персональных данныхАСР, либо, в случае с БАСР, кроме того, хранящий ещё

и настройки сети. Память реализована как отдельный пакет с интерфейсом

получения данных, рисунок 3.4.

Реализация памяти сводится к набору файлов, в которых хранится ин-

формация о состоянии системы (телефонная книга, настройки станцииипр.),

которые выгружаются в память, позволяя получать к ним быстрый доступ

с помощью реализованного интерфейса обмена, посредством подсистемы

передачи сообщений QNX.

3.4.2.6 Пакет «Интерфейс абонента»

Разработан пакет интерфейса абонента(рисунок 3.5), который необхо-

дим для предоставления возможности оператору взаимодействовать со стан-

42

Рисунок 3.4 — Пакет «Память»

циями АСР и БАСР. Данный пакет реализует интерфейс, по которому любой

другой пакет может вывести на отображение любую необходимую инфор-

мацию.

Данный пакет содержит в себе программы управления дисплеем и

клавиатурой и обеспечивает оперативный ввод-вывод данных. На основном

экране отображается следующая информация(рисунок 3.6):

- уровень заряда батареи аккумуляторной;

- уровень принимаемого сигнала;

- уровень громкости;

- уровень яркости подсветки дисплея;

- индикатор блокировки клавиатуры станции;

- индикатор подключения внешнего устройства шифрованной связи;

3.4.2.7 Пакет «Контроллеры»

Разработан пакет контроллеров, который служит для измерения дина-

мически меняющихся параметров системы, таких как уровень сигнала и за-

ряд аккумулятора, рисунок 3.8. Отображение данных параметров осуществ-

ляется с помощью пакета «Интерфейс абонента» по предоставляемому им

интерфейсу взаимодействия.

43

Рисунок 3.5 — Пакет «Интерфейс абонента»

Рисунок 3.6 — Основной экран станции

Взятие данных осуществляется по протоколу AXI4-Lite, а реализация

адаптеров к периферии расположена непосредственно в логике ПЛИС.

3.4.3 Реализация протокола персональной связи

3.4.3.1 Пакет «Система синхронизации»

Разработан пакет системы синхронизации (рисунок 3.9), который обес-

печивает синхронизацию внутренних счётчиков во всех требуемых пакетах,

что позволяет обеспечить работоспособность всей системы.

Разработана система подписок, с использованием механизмов QNX. В

44

а)б)

в)г)

Рисунок 3.7 — Пример меню дисплея:а,б) варианты исполнения основного экрана; в) дисплей при ошибке вводакода карты абонента; г) меню включения речевого информатора.

пакете системы синхронизации не должны храниться адреса для отправки

временной метки. Вместо этого данный пакет должен предоставлять интер-

фейс, с помощью которого другие приложения (пакеты) смогут добавлять

себя в список получателей временной метки и соответственно иметь воз-

можность быть синхронизированными.

Для реализации механизма подписок создан именованный канал для

возможностипередачиназванияфайлаименованного каналапакета-подписчика.

Это означает, что каждый пакет, которому потребуются временные метки,

сможет создать именованный канал и отправить свой идентификатор в за-

ранее известный канал системы синхронизации. После этого пакет системы

синхронизации добавляет имя канала подписчика в свой список и в уста-

новленное отправлет время временную метку всем подписчикам списка.

45

Рисунок 3.8 — Пакет «Контроллеры»

Данный механизм реализован в абстракции «Фасад».

Так как система синхронизации - одна из основных частей всей про-

граммной системы, т.к. все части этой системы работают по определённо-

му временному закону, она должна обеспечивать своевременную отправку

данных своим подписчикам. В результате отработки выявлено, что стан-

дартное сообщение для межпроцессного взаимодействия MsgSend отправ-

ляет данные используя скорость, которая не соответствует требуемым вре-

менным интервалам. Опытным путём было установлено, что процедура

MsgSendPulse предоставляет необходимую скорость при отправке данных,

однако эта функция может отправлять лишь ограниченное количество ин-

формации, а именно 32 бита данных и 8 бит заголовка.

Таким образом, разработан механизм сжатия данных временнойметки

для оперативной отправки.

Структура, используемая в пакете «Система синхронизации», для ор-

ганизации подписки сторонних модулей, для получения временных меток:

typedef s t ruc t _ s u b s c r i b e r _ d a t a {

msg_header_t hdr ;

char da t a [ 3 2 ] ;

} s u b s c r i b e r _ d a t a _ t ;

46

Рисунок 3.9 — Пакет «Система синхронизации»

Точка доступа для подписки на пакеты, содержащие временные метки:

# define ATTACH_POINT " sphere / syncModule "

Выбор состояния системы должен определяться следующими счетчи-

ками:

- номер символа (SN ҫҫ Symbol Number): 1 ҫ 1200;

- номер временного интервала (TN —- Timeslot Number): 1 ҫ 4;

- номер TDMA-кадра (FN ҫҫ Frame Number): 1 ҫ 25;

- номер мультикадра (MN ҫҫ Multiframe Number): 1 ҫ 60.

Значения счётчиковпередаютсяподписчикамввидепульса (MsgSendPulse).

Это обеспечивает асинхронность работы и высокую скорость при их массо-

вой рассылке подписанным пакетам.

Так как при помощи MsgSendPulse можно передать лишь 4 байта дан-

ныхи 1 байт заголовкаимеет смысл либоиспользовать заголовок как данные,

либо, что сделано в приложении упаковать имеющиеся значения счётчиков.

Примаксимальном значениипервого счётчика 1200 его двоичное пред-

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

0000 0100 1011 0000.

47

Из этого следует, что старшая тетрада второго байта счётчика SN всегда

будет свободной. А так как существует счётчик TN, который не использует

значения выше 15, целесообразно заполнять им свободное пространство.

Таким образом осуществляется передача в пульсе четырёх байт, вместо из-

начально требуемых пяти.

В этом случае двоичное представление максимальных значений счёт-

чиков при передаче будет выглядеть следующим образом:

0100 0100 1011 0000 0001 1001 0011 1100.

3.4.3.2 Пакет «Режим работы системы»

Реализован пакет «Режим работы системы» (рисунок 3.10), который

необходим для обеспечения работы станций в заданном режиме. Режим

работы системы определяется оператором в меню настроек базовой станции

и может быть изменён в процессе работы. От него зависит в какой момент

времени что именно должна делать система в целом, в частности, данная

система определяет как необходимо обрабатывать текущий принятый пакет

- как служебный, либо как пакет данных.

Данный пакет также реализует механизм подписок, однако его работа

зависит от системы синхронизации. Поэтому для неё он сам является под-

писчиком.

Тип текущего пакета определяется в соответствии с протоколом досту-

па персональной связи.

Пример выбора типа пакета при значении счётчикаMN = 1 (служебный

канал) изображён в приложении Б.

3.4.3.3 Пакет «Система регулировки мощности»

Разработана система регулировки мощности (рисунок 3.11), которая

служит для максимального сокращения мощности излучения абонентских

станций в целях их максимального сокрытия от средств обнаружения.

Алгоритм регулировки мощности позволяет определить её минималь-

но необходимый уровень для ведения бесперебойной передачи. Выполня-

48

Рисунок 3.10 — Пакет «Режим работы системы»

ется это следующим образом: сначала ищется максимальная мощность, при

которой пакеты перестают иметь приемлемый уровень битовой ошибки и

начинается её плавное увеличение (с шагом 0.25 Вт) до тех пор, пока связь

не станет стабильной при текущем значении мощности + 2.5 Вт.

3.4.3.4 Пакет «Система управления сетью персональной связи»

Разработана «Система управления сетьюперсональной связи», которая

позволяет устанавливать связь в сетях ЕССС и определяет взаимодействие

между базовой, мобильными и станциями спутниковой связи.

Взаимодействие модулей системы управления сетью персональной

связи выстроено на основе конечных автоматов. Это означает, что у каж-

дого модуля этой системы есть свой набор состояний, который определяет

поведение всей системы.

Ниже приведён автомат состояний процедуры установления логиче-

ского канала.

В мобильной станции присутствуют следующие состояния:

- INIT_STATE;

49

Рисунок 3.11 — Пакет «Система регулировки мощности»

- SEND_TRAFFIC_ACCEPT;

- HAS_CHANNEL;

- SEND_DETACHING_ACCEPT;

- SEND_CHANNEL_REQUEST.

В базовой станции:

- INIT_STATE;

- SEND_TRAFFIC_MODE_SET;

- RECEIVE_TRAFFIC_EXPECT;

- HAS_CHANNEL;

- SEND_DETACH_CHANNEL;

- RECEIVE_DETACH_EXPECT.

Изначально мобильная станция находится в состоянии INIT_STATE. В

установленное время при наличии закреплённого за мобильной станцией

субслота в канале сигнализации базовая станция отправляет пакет синхро-

низации с командой «Установка режима», в ответ на это мобильная станция

50

переходит в состояние SEND_TRAFFIC_ACCEPT, в котором она отправляет

базовой станции, находящейся в состоянии INIT_STATE, ответную команду

«Подтверждение режима», что заставляет базовуюстанциюперейти в состоя-

ние SEND_TRAFFIC_MODE_SET и зарезервировать под мобильную станцию

логический канал, повторно отправив команду «Установка режима» и пе-

рейдя в состояние RECEIVE_TRAFFIC_EXPECT, тем самым заставив перейти

мобильную станцию в состояние HAS_CHANNEL, в котором она вновь от-

правляет команду «Подтверждение режима», что окончательно закрепляет

логический канал за мобильной станцией и переводит базовую станцию в

состояние HAS_CHANNEL (рисунок 3.12).

Кроме того в данной системе присутствуют такие состояния АСР и

БАСР, в которые они могут переходить при необходимости смены логиче-

ского канала, а так же его открепления. Данный алгоритм реализовывает

адаптер между ССС и БАСР.

Данный модуль реализован в виде класса, который обеспечивает пере-

дачу команд из одного интерфейса в другой в зависимости от состояния и

отправленных команд.

3.5 Вывод

В результате разработки было выполнено следующее:

- разработана архитектура САУ;

- реализованы отдельные пакеты, отвечающие за работу системы;

- налажено взаимодействие между пакетами;

- настроено взаимодействие части аппаратных ресурсов с программной

САУ.

На основании результатов разработки архитектуры системы автомати-

зированного управления реализованы следующие компоненты:

- драйвер интерфейса С1-ФЛ-БИ;


- модуль работы с клавиатурой;

- модуль работы с дисплеем;

- пакеты системы автоматизированного управления:

∙ пакет «Память»;

51

Рисунок 3.12 — Сценарий предоставления доступа

52

∙ пакет «Интерфейс абонента»;

∙ пакет «Контроллеры»;

∙ пакет «Система синхронизации»;

∙ пакет «Режим работы системы»;

∙ пакет «Система регулировки мощности»;

∙ пакет «Система управления сетью персональной связи»;

При реализации предложен метод и способы взаимодействия про-

граммных компонент системы, а также выполнено тестирование работы

ARM, ПЛИС и протокола.

Результаты показали работоспособность системы в целом, однако на

данныймомент некоторые из компонент остаются неразработанными и тре-

буют дальнейшего изучения.

53

ЗАКЛЮЧЕНИЕ

На основании результатов анализа архитектуры, функционального со-

става, а также принципов и стандартов организации взаимодействия эле-

ментов и узлов системы радиодоступа абонентов сформирован перечень

требований, предъявляемых к ПО, таких как требования к:

- обеспечению дистанционного управления цифровыми каналами стан-

ций спутниковой связи;

- управлению режимами работы станций и информационным обменом;

- управлению получением и обработкой служебных сообщений;

- управлению вводом/выводом из внешних ООД или от собственных

речепреобразующих устройств;

- отображению на графическом экране служебной и пользовательской

информации.

Выполнен анализ протокола доступа персональной связи, это позво-

лило определить перечень реализуемых процедур:

- процедура синхронизации;

- процедура регулирования мощности передатчика;

- процедура предоставления доступа;

- процедура подтверждения работоспособности станций;

- процедура установления персональной связи;

- процедура передачи данных.

На основании результатов анализа, в том числе физического уровня и

процессорной части были определены необходимые модули и интерфейсы,

которые нужно реализовать в подсистеме взаимодействия с периферийным

оборудованием:


- модуль взаимодействия с ПЛИС по AXI шине;

- модуль взаимодействия с периферийными устройствами, расположен-

ными в ПЛИС.

Выполнено моделирование в среде MATLAB/Simulink моделей следу-

ющих процедур:

- процедуры синхронизации;

- процедуры регулировки мощности передатчика;

- процедуры подтверждения работоспособности станции;

54

- процедуры предоставления доступа.

Проведена отработка протокола по полученным моделям, которая по-

казала, что моделирование в среде Simulink не может обеспечить должный

механизм взаимодействия модулей, т.к. полученная система не предназна-

чена для реальных условий использования и требует разработки отдельного

программного обеспечения.

Исходя из полученных результатов выбран инструментарий для даль-

нейшей разработки, и на основании предложенного выбора была разработа-

на архитектура САУ, а так же части программной системы:

- драйвер интерфейса С1-ФЛ-БИ;


- модуль работы с клавиатурой;

- модуль работы с дисплеем;

- пакеты системы автоматизированного управления:

∙ пакет «Память»;

∙ пакет «Интерфейс абонента»;

∙ пакет «Контроллеры»;

∙ пакет «Система синхронизации»;

∙ пакет «Режим работы системы»;

∙ пакет «Система регулировки мощности»;

∙ пакет «Система управления сетью персональной связи»;

Таким образом предложен метод сетевого взаимодействия в составе

комплекса средств сетевого радиодоступа абонентов, базирующийся на про-

токолах ETSI EN 300 392 и IEEE 802.11, позволяющий организовывать работу

оборудования сетевого радиодоступа.

s[32]s

55

СПИСОК СОКРАЩЕНИЙ

АСР — Абонентская станция радиодоступа

БАСР — Базовая абонентская станция радиодоступа

ЕССС — Единая система спутниковой связи

КССРА — Комплекс средств сетевого радиодоступа абонентов

ООД — Оборудование обработки данных

ОСРВ — Операционная система реального времени

ПС — Персональная связь

ПСП — Псевдо-случайная последовательность

РПУ — Речепреобразующее устройство

ССС — Станция спутниковой связи

ШАС — Шифровальная аппаратура связи

AMBA — Advanced microcontroller bus architecture

ARM — Advanced RISC machine

AXI — Advanced extensible interface

DSP — Digital signal processor

ETSI — The European telecommunications standards institute

FN — Frame number

IPC — Interprocess communication

MCBSP — Multichannel buffered serial port

MN — Multiframe number

SN — Symbol number

SPI — Serial peripheral interface

SIM — Subscriber identity module

TDD — Time division duplex

TDMA — Time division multiple access

TETRA — Terrestrial trunked radio

TN — Timeslot number

56

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Спутниковая связь [Электронный ресурс] // ООО «Трилайн Си-

стемс». — Режим доступа: http://3lsystems.ru/equipment/satellite/ (дата обра-

щения: 2019-05-23).

2. Волков, Л.Н. Системы цифровой радиосвязи: базовые методы и ха-

рактеристики : учеб. пособие / Л.Н. Волков, М.С. Немировский, Ю.С. Шина-

ков. — Москва : Эко-Трендз, 2005. — 392 с.

3. The changingworld of satellite communication [Электронный ресурс] //

World Technology Evaluation Center. — Режим доступа: http://www.wtec.org/

loyola/satcom2/0102.htm.

4. Сомов, А.М. Спутниковые системы связи : учеб. пособие / А.М. Со-

мов. — Москва : Горячая линия. — 2012. — 244 с.

5. Что такое транкинг (или транк)? [Электронный ресурс] // SAGA ҫ си-

стемырадиосвязи. — Режимдоступа: http://www.sagatelecom.ru/encyclopedia/

systems/detail.php?ID=75 (дата обращения: 2018-10-29).

6. Транковая (транкинговая) связь [Электронный ресурс] // Системы

связи. — Режим доступа: https://www.2491040.ru/Trunk.html.

7. Транкинговая связь [Электронный ресурс] // Радиал. — Режим до-

ступа: https://www.radial.ru/faq/tranking/.

8. Булдаков, Г. А. Обзор аналоговых стандартов транкинговой связи /

Г.А. Булдаков // Omega Science. — 2016. — С. 13ҫ21.

9. Скляр, Б. Цифровая связь. Теоретические основы и практическое

применение / Б. Скляр. — Москва : Вильямс. — 2003. — 1104 с.

10. Технология TDMA: гарантия построения надежной беспроводной

сети [Электронный ресурс] // РУБА. — Режим доступа: http://wifi.kz/articles/

tekhnologiya-tdma-garantiya-postroeniya-nadezhnoy-besprovodnoy-seti/.

11. TDMA — Time Division Multiply Access [Электронный ресурс] // Про-

фессиональные средства связи. — Режим доступа: http://www.mobilradio.ru/

information/vocabulary/tdma.htm.

57

12. ГОСТ 27232-87 Стык аппаратуры передачи данных с физическими

линиями. Основные параметры. — Введ. 01.01.1988. —Москва : Издательство

стандартов, 1987. — 7 с.

13. Cowley, J Communications and Networking: An Introduction / J. Cowley.

— London : Springer. — 2013. — 235 p.

14. Продвинутая шинная архитектура микродиспетчера [Электронный

ресурс] //Новые знания! — Режимдоступа: http://ru.knowledgr.com/01044758/

ПродвинутаяШиннаяАрхитектураМикродиспетчера.

15. AMBA4 AXI4-Stream Protocol [Электронный ресурс] // University of

Idaho. — Режим доступа: http://www.mrc.uidaho.edu/mrc/people/jff/EO-440/

Handouts/AMBA-Protocols/AXI-Stream/IHI0051A-amba4-axi4-stream-v1-0-

protocol-spec.pdf.

16. ARM IHI 0022F.b AMBA AXI and ACE Protocol Specification. — 2017. —

England, Cambridge : ARM Limited. — 440 p.

17. Иглин, С.П. Математические расчеты на базе Matlab / С.П. Иглин. —

Санкт-Петербург : BHV. — 2005. — 640 с.

18. Курбатова, Е.А. MATLAB 7. Самоучитель / Е.А. Курбатова. — Москва :

Вильямс. — 2005. — 256 с.

19. Алексеев, Е.Р. MATLAB 7. Самоучитель / Е.Р. Алексеев, О.В. Чесноко-

ва. — Москва : НТ Пресс. — 2006. — 464 с.

20. Черных, И.В. Simulink: Инструмент моделирования динамических

систем / И.В. Черных. — MATLAB.Exponenta. — 2003. — 252 с.

21. Дьяконов, В.П. Simulink. Самоучитель / В.П. Дьяконов. — Москва :

ДМК-Пресс. — 2013. — 782 с.

22. Stateflow — Model and simulate decision logic using state machines and

flow charts [Электронный ресурс] // MathWorks. — Режим доступа: https://

www.mathworks.com/products/stateflow.html.

23. Что такое Stateflow? [Электронный ресурс] // Bourabai Research. —

Режим доступа: http://bourabai.kz/cm/stateflow11.htm.

24. Stateflow 5. Руководство [Электронный ресурс] // MATLAB. — Режим

доступа: http://matlab.exponenta.ru/stateflow/book1/index.php.

58

25. Linux Kernel [Электронный ресурс] // The Linux Kernel Archives. —

Режим доступа: https://www.kernel.org/linux.html (дата обращения: 2019-05-

09).

26. QNX Software Development Platform 6.5.0 SP1 [Электронный ресурс] //

Blackberry QNX. — Режим доступа: http://www.qnx.com/developers/docs/6.5.0

SP1.update/com.qnx.doc.adas.nav/topic/bookset.html.

27. Операционная системаQNX[Электронныйресурс] // SWDSoftware. —

Режим доступа: http://www.swd.ru/index.php3?pid=572.

28. Операционная система реального времени QNX [Электронный ре-

сурс] // Habrahabr. — Режим доступа: https://habr.com/ru/post/124656/.

29. QNX: секретное оружие в стадии конверсии [Электронный ресурс] //

CIT Forum. — Режимдоступа: http://citforum.ru/operating-systems/articles/qnx/.

30. QNX Neutrino RTOS — System Architecture. — Canada : QNX Software

Systems, 2005. — 404 p.

31. AMBE-2000 and 2020VocoderChipDescription [Электронныйресурс] //

Digital Voice Systems, Inc. — Режим доступа: https://www.dvsinc.com/products/

a20x0.shtml (дата обращения: 2019-03-17).

32. СТО 4.2ҫ07ҫ2014 Системаменеджмента качества. Общие требования

к построению изложению и оформлению документов учебной деятельно-

сти. — Введ. 2014. ҫ Красноярск : СФУ, 2014. ҫ 60 с.

59

ПРИЛОЖЕНИЕ А — АРХИТЕКТУРА САУ

Схема части физического уровня

60

ПРИЛОЖЕНИЕ Б — ВЫБОР ТИПА ПАКЕТА В СЛУЖЕБНОМ КАНАЛЕ

Выбор типа пакета в служебном канале

switch ( m_t imeCounters . t imes lo tNumber ) {

case 1 :

s e r v i c e P a c k e t | = CONTROL_PACKET ;

My_MsgSendPulse ( co id , −1 , m_stationCommands .

oddTimeslotCommand , s e r v i c e P a c k e t ) ;

break ;

case 2 :

i f ( IS_BASE_STATION ) {

s e r v i c e P a c k e t | = SYNCHRONIZATION_PACKET ;

} e l se {

s e r v i c e P a c k e t | = POWER_CONTROL_PACKET ;

}


evenTimeslotCommand , s e r v i c e P a c k e t ) ;

break ;

case 3 :

s e r v i c e P a c k e t | = CONTROL_PACKET ;


oddTimeslotCommand , s e r v i c e P a c k e t ) ;

break ;

case 4 :

s e r v i c e P a c k e t | = SYNCHRONIZATION_PACKET ;


evenTimeslotCommand , s e r v i c e P a c k e t ) ;

break ;

defaul t :

break ;

}

61

Федеральное государственное автономное - CORE

Documents

Transcript of Федеральное государственное автономное - CORE