Узел 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 может быть сделано одной из двух процедур.

Узлы MP могут так сообщить свое расписание маяков, что другие узлы смогут проактивно избежать коллизии маяков. Информационный элемент beacon timing element может быть передан только в маяке, передаваемом в момент TBTT для DTIM. Узлы могут выбрать любую частоту для передачи расписания маяков. В зависимости от числа соседей узел может включить в маяк не все полученные им данные о расписании получения маяков других узлов из-за ограниченности размера кадра. Узел включит данные только по тем маякам, которые были получены в близкие моменты времени и потенциально могут накладываться.

Расписание маяков узлы могут передать в кадрах “Probe Response” в ответ на кадр “Probe Request”. Узел, посчитавший, что его маяки не были правильно получены его соседями, может испустить Probe Request для проверки, правильно ли получает его маяк конкретный сосед.

Узлы, посчитавшие, что не получают маяк от конкретного соседа из-за коллизии маяков, могут передать кадр подгона TBTT (TBTT Adjustment request frame). Узлы со значением 1 в поле “TBTT Adjustment enabled” подгонят свои TBTT при получении этого запроса.

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

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