Сокращения

MP узел может буферизировать кадры, прослеживать энергетические режимы каждого узла, с которым есть линк (peer MP), и использовать peer сервисные периоды для передачи данных.

Узел, работающий в режиме энергосбережения или переходящий в него, называется энергосберегающим узлом. Работа в режиме энергосбережения опциональна.

Узел находится в одном из двух состояний:

• бодрствующий: узел может получать/передавать кадры и использует всю мощность;
• дремлющий: узел не может получать/передавать кадры и потребляет очень маленькую мощность.

Узлы обладают собственным энергорежимом для каждого своего линка к другому узлу. Узел поддерживает тот же режим, что и его peer MP. Энергорежимы линков одного узла независимы, поэтому узел может работать в других режимах на других линках. Узел поддерживает энергорежим и для non-peer MP узлов (см. 11В.13.2 ).

Определены 3 энергорежима: активный, легкий сон, глубокий сон.

• Активный режим (Active mode): узел все время в бодрствующем состоянии.
• Режим легкого сна (Light sleep mode): узел переключается между бодрствованием и сном по правилам приема и передачи кадров. Узел слушает все маяки своих peer MP.
• Режим глубокого сна (Deep sleep mode): узел переключается между бодрствованием и сном по правилам приема и передачи кадров. Узел может решить не слушать маяки от своего peer MP.

Используемый энергорежим указан двумя полями: Power Save Level и Power Management в поле Frame Control.

Таблица 1. Определение энергорежима.

Для взаимодействия с peer MP узлами в режимах Light Sleep Mode и Deep Sleep Mode соответственно узел может установить Active Mode для обоих. Два энергосберегающих узла устанавливают между собой режим Deep Sleep Mode.

Узел указывает свой non-peer энергорежим в поле Power Management в маяках и Probe Response кадрах, а также в groupcast кадрах. Non-peer энергорежим требуется, когда non-peer MP узел шлет Probe Request и Peer Link Open Request кадры. В результате будет установлен энергорежим, равный или меньший наименее активному режиму, в котором работает данный узел со своими peer узлами.

Все индикаторы энергорежима указаны в таблице 1. В соответствии с ней выставляются указанные биты в unicast кадрах, посылаемых по соответствующему линку.

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

Если узел действует в режиме глубокого сна или собирается изменить режим хотя бы одного своего линка на режим глубокого сна, узел выставляет соответствующие биты (см. таблицу 1) во всех своих multicast и broadcast кадрах.

Если узел ни с каким своим линком не работает в режиме глубокого сна, то если он находится в состоянии легкого сна или собирается поменять режим хотя бы одного своего линка на режим легкого сна, то во всех своих multicast и broadcast кадрах узел выставляет соответствующие таблице 1 биты.

Элемент Mesh TIM:

• идентифицирует узлы MP в энергосберегающем режиме (для которых предназначенный им ждущий обработки трафик буферизируется в отсылающих узлах). Информация эта закодирована в полу-виртуальной (partial virtual – частичной виртуальной. имеется в виду, что вся карта не передается, передается только ее часть от первого ненулевого бита и смещение этого бита) битовой карте с использованием AID;
• содержит индикатор, показывающий, ожидает ли обработки groupcast траффик.

Каждая MP присваивает уникальный AID каждой своей peer MP во время процедуры установления линка. AID 0 (ноль) зарезервирован для указания наличия в буфере groupcast MSDUs.

MP укажет, каким MP узел готов отправить буферизированные MSDUs, выставив соответствующие номерам AIDs биты в битовой карте элемента Mesh TIM.

1. Mesh TIM
2. Mesh DTIM

MP передает Mesh TIM в каждом маяке. Mesh DTIM элемент передается в маяке с периодом DTIMPeriod.

После посылки Mesh DTIM узел отправляет буферизированные groupcast MSDUs прежде, чем послать любой unicast кадр. В каждом таком groupcast кадре в поле More Data Field указано, есть ли еще в буфере ждущие отправки groupcast MSDUs. В последнем переданном groupcast кадре в этом поле 0.

Энергосберегающий узел находится в состоянии бодрствования в течение своего собственного Awake Window. Этот период задан в Awake Window элементе. Данный элемент обязательно должен быть в маяке DTIM Beacon, может также быть в маяке TIM Beacon и кадре Probe Response.

Начало отсчета периода Awake Window - с конца отправки маяков или Probe Response кадров с Awake Window элементом.

Связанные по линку узлы могут послать инициирующий взаимодействие кадр своему энергосберегающему соседу в течение Awake Window этого узла. Успешно переданный инициирующий кадр начинает таким образом период сервисного взаимодействия данных узлов как описано в 11В.13.10 ().

Не связанные линком узлы при необходимости связаться с энергосберегающим узлом могут послать Probe Request или Peer Link Open кадры в течение его Awake Window. В ответ узел пробудет в состоянии бодрствования как минимум до конца процедуры установления линка (успешного или нет) или до конца отправки кадра Probe Response.

Как описано в 11В.13.1, MP указывает свой энергорежим отдельно для каждого линка и узнает энергорежимы своих peer MPs.

Как описано в 11В.13.4, MP указывает всем своим peer MPs в энергосберегающем режиме наличие в своем буфере трафика для них через TIM элементы. Как описано в 11В.13.5, MP передает groupcast кадры после DTIM маяка.

Как описано в 11В.13.10, периоды сервисного взаимодействия между peer MPs предназначены для передачи кадров энергосберегающим узлам. Эти периоды не используются для взаимодействия бодрствующими узлами.

Инициация периода сервисного взаимодействия с энергосберегающим узлом (в легком или глубоком сне - одинаково) происходит через передачу инициирующего кадра (trigger frame) в течение Awake Window дремлющего узла.

Узел в активном состоянии, т.е. всегда бодрствует. Периоды сервисного взаимодействия между такими узлами не применяются для обмена кадрами.

Узел должен входить в бодрствующее состояние до того, как настанет очередной момент TBTT, соответствующий его расписанию передачи DTIM маяков.

Узел также должен оставаться бодрствующим после передачи DTIM маяка в течение Awake Window и на протяжении всего времени, необходимого для передачи ему groupcast кадров, если передача началась в период Awake Window.

Узел в течение Awake Window может получать инициирующие кадры, как описано в пункте 6.

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

Узел, действующий по схеме легкого сна, должен войти в бодрствующее состояние до очередного момента TBTT, указывающего отправку своих маяков и маяков peer узлов (видимо, мысль в том, что их расписания должны пересекаться). Узел бодрствует в течение Awake Window и необходимое для получения groupcast кадров время. Узел может вернуться в дремлющее состояние, если в полученном маяке от peer узла, с которым он указал свой режим как “легкий сон”, нет указания на любые (unicast или groupcast) предназначающиеся ему кадры. Если же указание на наличие кадров есть, то данный узел (получатель этих кадров) должен послать инициирующий сервисное взаимодействие кадр своему peer узлу, чтобы инициировать начало сервисного периода и готовность получать маяки.

Если узел в легком сне переходит в бодрствующее состояние, чтобы получить DTIM маяки и групповые кадры от своих peer узлов, этот узел останется бодрствующим, пока не получит кадр с полем More Data Field, указывающим, что это последний groupcast MSDU.

Узел может войти в дремлющее состояние только при наличии следующих условий:

• узел функционирует в энергосберегающем режиме на всех своих линках,
• узел не находится в периоде сервисного взаимодействия ни с одним своим peer узлом,
• указанный узлом период Awake Window уже закончился,
• узел закончил передачу своих groupcast кадров после своего DTIM маяка,
• узел получил инициирующий взаимодействие кадр от всех своих peer узлов, также действующих в режиме легкого сна, к которым он указал в своем маяке наличие ожидающего трафика в буфере.

Узел, установивший режим глубокого сна со всеми своими peer узлами, должен передавать DTIM маяки. Если узел указал активный режим или режим легкого сна по отношению к любому своему peer узлу, он должен передавать TIM и DTIM маяки.

Период используется для взаимодействия по линку, где хоть один узел работает в энергосберегающем режиме. В этот период по линку передаются unicast кадры. Период этот направленного действия и может состоять из нескольких TXOP. Один узел передает кадры и инициирует окончание периода сервисного взаимодействия. Узел может одновременно работать в нескольких таких периодах с разными peer узлами. Максимально, один сервисный период может быть установлен по каждому направлению с каждым peer узлом.

Кадр с данными или QoS-Null кадр, требующие подтверждения, могут быть использованы в качестве инициирующего сервисное взаимодействие кадра. Если бит EOSP в peer trigger (инициирующем) кадре выставлен в 0, то этот кадр инициирует 2 независимых периода сервисного взаимодействия, одним из которых владеет передатчик этого кадра, а другим - его получатель. Если бит EOSP выставлен в 1, то инициируется 1 сервисный период, которым владеет получатель кадра.

В течение сервисного периода передатчик и его peer узел взаимодействуют в активном режиме. Передатчик может отправлять кадры от разных AC, но каждый TXOP должен содержать кадры только от одной AC.

Сервисный период заканчивается после успешно подтвержденного QoS-Null кадра или кадра с данными с EOSP битом, выставленнным в 1; кадр этот должен отправить узел, передавший сервисный период ( его инициировавший или пославший его длительность?).

Если на такой кадр, сигнализирующий о завершении сервисного периода, не приходит подтверждение его получения, узел передаст кадр еще как минимум 1 раз в течение данного сервисного периода. Максимальное число повторных отправлений в течение одного периода взаимодействия - меньшее из Max Retry Limit и атрибута MIB attribute dot11MPMissingAckRetryLimit. Если и на последний повторно отправленный кадр не придет подтверждение его получения, узел может использовать следующий период сервисного взаимодействия для дальнейших посылок кадра и ожидания подтверждения.