В тексте слова “маяк”, “сигнал” и его синонимы и “beacon” обозначают одно и то же.

Сокращения

1. Использование механизмов для BSS/IBSS с некоторыми изменениями
   • ATIM окно, ATIM кадры - новые правила
   • TIM IE в сигнальном кадре, PS-poll кадр (упорядочивающий передачу по каналам)
   • APSD механизм
2. Уменьшена частота передачи сигналов
   • сигналы передаются только с периодом DTIM
   • эффективное разделение ответственности за Mesh сигнализацию
3. Эффективное рекламирование режима энергосбережения
   • указано в сигнальных кадрах
   • указано через PS бит в поле Frame Control
4. Задает механизмы, позволяющие узлам MP бодрствовать только необходимый для действительного приема сигнала период времени
   • эффективное использование “more data bit” и “EOSP”
5. Синхронизация (2 вида ) (также обеспечивает высокую производительность MAC-схемы)
   • интервалы отправки сигналов узлами MP могут быть разные
   • TSF-функция для всей Mesh-сети: обновление времени одновременно с интервалом DTIM, все узлы MP испускают сигналы со своим локальным временем, обновление времени по самому быстрому из полученных времен

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

ATIM - интервал времени сразу после передачи узлом сигнала, т.е. в начале интервала DTIM. В течение ATIM гарантируется бодрствование узла. За это время узел получает управляющий трафик, в котором могут быть:

• указание, что передается трафик, ждущий обработки, т.е. “повисший” (pending);
• изменения в PS-статусе,
• возобновление приостановленных ранее потоков.

В зависимости от полученных за время ATIM данных, узел остается бодрствующим соответствующее время и после завершения интервала ATIM.

Узел MP инициализирует свой TSF таймер в зависимости от действующего синхронизирующего протокола узла MP. MP периодически передает специальный кадр.

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

Узлы используют элемент Протокол Синхронизации в маяках и в кадрах Probe Response для анонсирования действующего протокола.

• Поддержка синхронизации опциональна. Если узел не поддерживает ее, то данный элемент в указанные кадры не включается.
• Узел может синхронизироваться с 1 или несколькими соседними узлами в зависимости от собственных требований или требований соседних узлов.
• Даже при способности к синхронизации, узел может ее не выполнять.

Сдвиг [мкс] в дополнительном коде (2's complement). Узел MP хранит временной сдвиг между собственным TSF таймером и TSF таймером каждого соседа, с которым он намерен синхронизироваться. MP также может игнорировать получаемые в маяках и кадрах Probe Response временные метки. Однако узел, применяющий тот же протокол синхронизации, что и сосед, будет использовать временные метки своего соседа и обновлять сдвиг:

(1) сдвиг соседнего узла MP = полученная от соседа временная метка - значение собственного TSF таймера (1)

Узел может получить значение таймера соседа:

(2) значение таймера соседа = значение собственного таймера + сдвиг для этого соседа (2)

Маяки для mesh и BSS - разные, даже если генерятся одним и тем же узлом. Интервалы для генерации mesh и BSS маяков могут быть независимы.

TBTT - момент времени, на который записывается передача маяка в расписание.

Узел определяет серии TBTT с периодом dot11MeshBeaconPeriod * TU. Нулевое время - это TBTT всей Mesh, когда был передан кадр маяка, а именно mesh DTIM. На каждый момент TBTT сети узел вносит в расписание маяк - следующий кадр, предназначенный для передачи (см. правила пункта 9 ). Период отправки маяка включается в сами маяки и кадры Probe Response.

Этот механизм разработан, чтобы предотвратить коллизии маячков, переданных станциями STA, которые друг друга не видят (так называемые скрытые узлы). Механизм состоит из 2 процедур.

MP сообщает расписание приема маяков в элементе beacon timing element соседним MP в кадрах маяков, кадрах Probe Response или в кадрах beacon timing response. В beacon timing элемент может быть включен любой маяк, переданный на той же частоте, даже если он пришел извне Mesh сети. Узел MP, поддерживающий процедуры сообщения о расписании своих маяков, установит 1 в бит “Beacon timing report enabled” поля Mesh Capability в элементе Mesh Configuration.

Получив beacon timing element, MP может выбрать свой TBTT так, чтобы он не накладывался на существующие TBTT других STA на расстоянии 2 хопов. Также узел MP может проверить, получили ли другие узлы его маяк, проверив в элементах beacon timing elements других MP поле beacon timing: AID значение этого поля должно содержать ID данного узла. Узлы, поддерживающие эту процедуру выбора TBTT, установят 1 в бит “TBTT Adjustment enabled” поля Mesh Capability в элементе Mesh Configuration.

Опционально узлы могут подогнать свои TSF таймеры.

Отдельные от сети MP могут подогнать TBTT или временной сдвиг, чтобы они не конфликтовали с другими узлами, до или во время установки связи (peer link) с узлами. Также узел может подогнать TSF таймер, если заметит, что его TBTT будет постоянно конфликтовать с другими TBTT. Свой TSF узел может ускорить или ввести в состояние ожидания на некоторое время.

Сбор и сообщение информации о TBTT соседних MP может быть сделано одной из двух процедур.

В дополнение, отчеты по маякам узлы могут использовать для обмена информацией о расписании маяков, как это описано в 11.10.9.1 ( видимо, первая редакция стандарта или вообще не 11s).

Опционально, узлы могут иногда откладывать передачу своих маяков после моментов TBTT на псевдослучайный интервал. Псевдослучайный интервал времени может быть выбран так, чтобы вероятность коллизии с другими маяками была меньше. Это позволяет обнаруживать соседей через кадры маяков в случае, если они выберут конфликтующий временной сдвиг. В этом случае MBCA-механизм может быть использован для выбора не конфликтующих временных сдвигов.