Разновидности и форматы передаваемых сообщений. – ЧАСТЬ 1

Разновид­ности передаваемых в ZigBee сетях сообщений определяются потребностями обеспечения ее функционирования, включая следующие аспекты:

–                самоорганизацию сети;

–                поддержание се работоспособности в изменяющихся условиях;

–                информационный обмен сенсорными данными между абонентами. Удовлетворение перечисленных потребностей обеспечивается передачей

фреймов сообщений четырех типов:

–                маячковых фреймов;

–                фреймов данных;

фреймов команд управления; – фреймов подтверждения приема сообщения.

Передача фреймов данных обеспечивает логическую связь, соответствую­щую верхним (прикладным) уровням взаимодействия приборов сети. Передача фреймов трех остальных типов: маячковых, команд управления, подтверждения приема – обеспечивает логическую связь, соответствующую MAC и PHY уров­ням взаимодействия приборов. В целом фреймы четырех перечисленных типов (с учетом разновидностей фреймов управления, что является предметом дальней­шего рассмотрения) обеспечивают все аспекты функционирования ZigBee сетей.

Фреймы PHY уровня (PPDU) всех типов отличаются с учетом их полезной нагрузки (PSDU) наличием двух структурных элементов (рис. 4.43):

1)           заголовка синхронизации (Synchronization Header – SHR);

2)           заголовка фрейма физического уровня (PHY Header – PHR).

Рис. 4.43. Структура фреймов физического уровня (PPDU) и MAC подуровня (MPDU) ZigBee сетей

Заголовок фрейма физического уровня (PHR) содержит сведения о размерах его полезной нагрузки, т.е. о длине MPDU. Максимально допустимая длина по­следней, выраженная в безразмерных единицах, составляет 127 октетов. Заголовок синхронизации (SHR) включает два поля:

–                поле преамбулы (Preamble), назначение которой состоит в обеспечении чипо­вой и символьной синхронизации приемника с частотами следования соот­ветствующих элементов принимаемого сигнала;

–                поле разделения (Start-of-Frame Delimiter – SFD), служащее для отделения конца преамбулы от начала заголовка фрейма (PHR).

Длина заголовков PHR, SHR фреймов PPDU, применяемых в частотных ка­налах 0-й канальной страницы (обязательные для реализации каналы, предусмо­тренные стандартом IEEE 802.15.4-2003), кратна длине октета данных (см. табл. 4.22). В зависимости от длины полезной нагрузки суммарный размер заголовков составляет от 4.5% до 33% общей длины PPDU. Скорость передачи битов в за­головках не отличается от их скорости при передаче нагрузки (PSDU),

Характеристики фреймов физического уровня каналов «нулевой»

канальной страницы

Элементы фреймов

Длина элементов, октет

Длительность элементов в различных каналах, мс

0

1…10

И...26

SHR

5

2

1

0.160

PHR

1

0.4

0.2

0.022

PSDU

9…127

3.6…50.8

11.8…25.4

0.288…4.064

PPDU (в целом)

15…133

6…53.2

3…26.6

0.48…4.256

Фреймы MAC уровня (MPDU), являющиеся сервисными блоками данных (PSDU) PHY уровня, содержат 3 типовые структурные составляющие (рис. 4.43): за­головок (MAC Header – MHR), полезную нагрузку (MAC Payload) и концевик (MAC Footer – MFR). Заголовок фрейма содержит сведения о его характеристиках и адре­сации. Полезная нагрузка составляет содержательную часть передаваемого сообще­ния. Она включается во фреймы данных, команд управления и маячковые фреймы, но отсутствует во фреймах подтверждения приема, содержание которых однозначно определяется самим фактом их передачи. Концевик фрейма содержит контрольную последовательность фрейма (Frame Check Sequence – FCS), позволяющую обнару­жить ошибки в передаче заголовка и полезной нагрузки фрейма. При применении циклического кода с обнаружением ошибок посредством контроля четности CRC-16 [3] длина FCS составляет 2 октета независимо от длины MHR и MSDU.

Заголовки MAC фреймов при их полноформатной реализации содержат сле­дующие поля служебной информации, необходимой для передачи фрейма в сети (рис. 4.44):

–                поле спецификации (характеристик) фрейма (Frame Control Field);

–                поле нумерации фрейма (Frame Number Field);

–                поля адресации фрейма (Addressing Fields);

–                поле заголовка конфиденциальности фрейма (Auxiliary Security Header Field).

Рис. 4.44. Структура заголовка MAC фреймов ZigBee сетей

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

1)           длина заголовка в зависимости от типа фрейма, его адресации и конфиден­циальности передачи может изменяться в пределах от 3 до 127 октет (наи­меньшую длину имеют фреймы АСК);

2)           спецификация фрейма (поле длиной в 2 октета) содержит субполя, в которых отражаются сведения о типе передаваемого фрейма (Frame Туре), конфи­денциальности передачи (Security Enabled), наличии у отправителя после­дующих фреймов для передачи адресату (Frame Pending), необходимости подтверждения приема получателем отправляемого фрейма (Ack Request), используемом способе адресации фрейма (Destination Address Mode, Source Address Mode, PANID Compression), версии стандарта IEEE 802.15.4, со­гласно которой оформлен фрейм;

3)           нумерация фреймов (поле длиной в 1 октет) осуществляется для контроля их доставки адресату; в зависимости от типа фрейма различают нумерацию маячковых фреймов (Beacon Sequence Number – BSN), нумерацию фреймов данных и подтверждения приема, а также нумерацию команд управления (Data Sequence Numbef- DSN);

4)           конфиденциальность передачи фреймов сопровождается наличием в поле заголовка конфиденциальности (поле длиной до 14 октет) сведений об уровне конфиденциальности (Security Level) и о ключах (Keying Material), которые используются для ее реализации;

5)           адресация фреймов обеспечивается сведениями, которые приводятся в четы­рех полях адресации и заполняются сведениями упоминавшихся выше адрес­ных субполей спецификации суперфрейма. Адресные поля включают: иден­тификаторы PAN, к которым принадлежит источник и получатель сообщения (Destination PAN ID, Source PAN ID) и адреса источника и получателя (Source Address, Destination Address). Предусматриваются две разновидности приме­няемых адресов: короткие адреса (Short Address), длина которых составля­ет 2 октета и которые присваиваются приборам координатором сети (или ее ветви) при ассоциации прибора, и расширяемые адреса (Extended Address), длина которых составляет 8 октетов и которые являются индивидуальными адресами приборов (IEEE Address). Вид применяемого адреса указывается в субполях режима адресации (Destination Address Mode, Source Address Mode) спецификации фрейма. Расширяемые адреса применяются приборами при их ассоциации в сеть (до присвоения им коротких адресов), а также в ситуациях, когда короткий адрес прибора для применения не предусматривается. Отсут­ствие адресных полей может наблюдаться во фреймах подтверждения (АСК). Источник и адресат этого фрейма однозначно определяется источником и адресатом предшествующего фрейма.

Полезная нагрузка фреймов MAC уровня, именуемая блоком сервисных дан­ных этого уровня (MSDU), регламентируется [62] для фреймов двух типов: ма­ячковых фреймов и фреймов команд управления (далее – команд). Последние совместно обеспечивают все аспекты функционирования сети: самоорганиза­цию, поддержку работоспособности и передачи данных. Перечень фреймов ко­манд включает 9 их разновидностей; их взаимосвязь с различными аспектами функционирования сети иллюстрируется табл. 4.23.

Таблица 4.23

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

Сетевая функция

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

RFD

ACK

Tx

Rx

 

Самоорганизация сети

Запрос маячкового фрейма (Beacon Request)

 

 

 

Запрос ассоциации (Association Request)

X

 

X

Ответ ассоциации (Association Response)

 

X

X

Уведомление о деассоциации (Deassociation Notification)

X

X

X

Поддержание работоспособности

Запрос гарантированных слотов (GTS Request)

 

 

X

Уведомление «осиротевшего» прибора (Orphan Notice)

X

 

 

Перенастройка координатора (Coordinator Realignment)

 

X

Приме­чание

Уведомление о PAN ID конфликте (PAN ID Conflict Notification)

X

 

X

Поддержка передачи данных

Запрос данных (Data Request)

X

 

X

Примечание. Подтверждение приема команды производится при ее адресной передаче «осиротевшему» прибору и не производится при ее широковещательной передаче.

Каждой команде управления ставится в соответствие идентификатор коман­ды (Command Frame Identifier – CFID), который отражается в отдельном поле полезной нагрузки (MAC Payioad) фрейма (рис. 4.45). Содержание команды от­ражается в другом поле – поле полезной нагрузки команды (Command Payioad). Возможности полнофункциональных (FFD) и ограниченно функциональных (RFD) приборов в отношении передачи и приема фреймов команд отличаются: FFD обеспечивает прием и передачу фреймов всех разновидностей, FRD – не­которые команды не передают и/или не принимают (требования [62] в отноше­нии этих свойств отражены в табл. 4.23).

Рис. 4.45. Структура MAC фреймов команд управления

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

–                запрос маячкового фрейма широковещательно передается полнофункцио­нальным прибором (FFD) при активном сканировании им области персональ­ного радиовлияния (POS) для оценки наличия в этой области существующих ZigBee сетей; запрос передается FFD, который планирует организовать но­вую ZigBee сеть и стать ее координатором (PANC) или ассоциироваться в су­ществующую сеть с возможностью стать координатором ее ветви;

–                запрос ассоциации передается координатору существующей сети FFD или RFD приборами при их намерении ассоциироваться в упомянутую сеть; RFD предварительно осуществляет пассивное сканирование POS с целью опре­деления идентификатора сети и адреса координатора, которые широковеща­тельно передаются последним в его маячковых фреймах;

–                ответ ассоциации передается прибору координатором сети, в которую этот прибор ассоциируется; ответ содержит решение координатора об ассоциации прибора или отказе в ней и, в случае положительного решения, присваивае­мый прибору короткий сетевой адрес;

–                уведомление о деассоциации передается прибором координатору сети с ука­занием побуждений, вызывающих деассоциацию (собственные потребности прибора, потребности координатора);

–                запрос о предоставлении гарантированных слотов времени (GTS) передает­ся прибором координатору сети; необходимоеусловие обращения с запросом состоит в том, что передаваемые в GTS сообщения предназначаются получа­телю, который является абонентом той же сети; оба прибора – отправитель и получатель – должны иметь короткий сетевой адрес; слоты выделяются раз­дельно для передачи и приема; число слотов, выделяемых одному прибору для передачи и/или приема, не может превосходить 1; суммарное число GTS (при наличии соответствующего ресурса времени) не может превосходить 7;

–                уведомление «осиротевшего» прибора передается координатору ассоции­рованным прибором, который утратил связь с сетью; уведомление в каче­стве полезной нагрузки содержит только идентификатор команды (см. рис. 4.45), поскольку ответ на него является типовым – прибору сообщаются сведения, содержащиеся во фрейме перенастройки координатора; в адрес­ных полях заголовка фрейма (MHR) «осиротевший» прибор в качестве адреса источника указывает свой расширенный 8-октетный адрес, опуска­ет поле идентификатора сети источника и приводит широковещательный короткий адрес и широковещательный идентификатор сети получателя (координатора);

–                фрейм перенастройки координатора передается «осиротевшему» прибору в ответ на его уведомление или широковещательно передается всем прибо­рам при необходимости изменения характеристик сети вследствие причин, выявленных координатором; сведения, содержащиеся в полезной нагрузке команды в обоих случаях одинаковы, и, кроме идентификатора команды, включают идентификатор сети (PAN ID), короткий адрес координатора, ко­роткий адрес прибора, которым ему надлежит пользоваться, номер каналь­ной страницы (Channel Page) и номер частотного канала (Logical Channel) в этой странице (см. п. 4.4.1.2);

–                уведомление о конфликте в идентификации сети (PAN ID) передается коорди­натору сети ассоциированным в нее прибором, который в пределах POS выявил существование другой сети с идентификатором, совпадающим с ее собствен­ным (принял маячковый фрейм сети с соответствующим PAN ID); координа­тор, получив уведомление, производит активное сканирование POS и, удосто­верившись в правильности PAN, изменяет ранее применявшиеся PAN ГО;

–                запрос данных передается ассоциированным прибором своему коорди­натору, который посредством широковещательной передачи маячкового фрейма сообщает прибору о наличии предназначенного ему фрейма дан­ных (см. рис. 4.40).

Передача команд управления производится в течение состязательного пе­риода (САР) суперфрейма. Факт приема команд подтверждается фреймами АСК типа (за исключением некоторых команд, подтверждение приема которых не требуется, см. табл. 4.23).

Учитывая ключевую роль маячковых фреймов в обеспечении функциони­рования сети, остановимся в заключение на составе и содержании их полезной нагрузки (состав ее полей и субполей иллюстрируется рис. 4.46). Маячковый фрейм содержит следующие поля:

–                поле спецификации суперфрейма (Superframe Specification), содержащее све­дения об обозначении сети и распределении временного ресурса суперфрей­ма, «возглавляемого» передаваемым маячковым фреймом;

–                поля гарантированных слотов времени (GTS Fields), содержащие сведения о GTS, предоставляемых абонентам в пределах суперфрейма;

–                адресные поля (Pending Address Fields), содержащие сведения о наличии и по­лучателях содержащихся у координатора предназначенных абонентам фрей­мах данных;

–                полезную нагрузку маячка (Beacon Payioad), которая содержит сведения, пере­даваемые верхними (по отношению к MAC) уровнями (не является обяза­тельным элементом).

Рис. 4.46. Структура полезной нагрузки маячкового фрейма MAC уровня


Распределение временного ресурса суперфрейма отражается в трех субпо- лях его спецификации, а именно: субполе порядка маячкового интервала (Beacon Order – ВО), субполе порядка суперфрейма (Superframe Order – SO) и субполе финального слота состязательного периода (Final CAP Slot). Взаимосвязь ВО и SO с длительностями соответствующих интервалов рассматривалась в п. 4.4.1.3. Номер последнего слота САР определяет длительность остаточного интервала безсостязательного доступа (CFP). Субполе BLE (Battery Life Extension) отра­жает требования к безотлагательному участию абонентов в состязаниях за до­ступ к передаче сообщений координатору после окончания маячкового фрейма (см. далее п. 4.4.2.2). Субполе координатора PAN (PAN Coordinator) отражает статус последнего как источника передаваемого маячкового фрейма. Наконец, поле ассоциации (Association Permit) содержит информацию о том, допустима ли ассоциация абонентов в сеть.

Три поля гарантированных слотов времени содержат:

–                спецификацию рассматриваемых слотов (GTS Specification), которая включа­ет сведения об их числе в CFP начинающегося суперфрейма и о возможности приема дальнейших заявок на выделение GTS;

—         сведения о способе использования предоставляемых GTS – для целей приема или передачи сообщений (GTS Direction);

–                список предоставляемых GTS (GTS List), в который включаются сведения о длине каждого GTS, номере его начального слота и коротком адресе прибора, которому GTS предоставляется.

Адресные поля сообщений, содержащихся у координатора и предназна­ченных абонентам, содержат сведения о числе адресатов с короткими и рас­ширенными адресами (указываются в поле спецификации – Pending Address Specification) и об их адресах (указываются в поле списка адресов – Address List). Общее число адресатов обоих разновидностей равно 7.

Маячковый фрейм обеспечивает выполнение координатором диспетчер­ских функций «непрямой» передачи сообщений в сетях с маячковым режимом работы (см. рис. 4.40). В безмаячковых сетях реализация «непрямой» передачи предполагает выполнение пользователями диспетчерских функций в «сотруд­ничестве» с координатором (рис. 4.42).

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100