Differences

This shows you the differences between two versions of the page.

--- etc:common_activities:materials:beaconing80211s:powersavein2d [2009/05/05 20:47] – режим энергосбережения - создано raa
+++ etc:common_activities:materials:beaconing80211s:powersavein2d [2009/05/15 12:02] (current) – комментарий к partial virtual jcmvbkbc
@@ Line 1: / Line 1: @@
 ====== Режим энергосбережения ======
+**Сокращения**
+| AID |  |
 //MP// узел может буферизировать кадры, прослеживать энергетические режимы каждого узла, с которым есть линк (//peer MP//), и использовать //peer// сервисные периоды для передачи данных.
@@ Line 5: / Line 9: @@
 Узел, работающий в режиме энергосбережения или переходящий в него, называется //энергосберегающим узлом//. Работа в режиме энергосбережения опциональна.
-===== Зависящие от линка энергорежимы =====
+===== 1. Энергорежимы линков узла =====
 Узел находится в одном из двух состояний:
@@ Line 12: / Line 16: @@
   * дремлющий: узел не может получать/передавать кадры и потребляет очень маленькую мощность.
-Узлы обладают собственным энергорежимом для каждого линка, который у них есть к другому узлу. Узел поддерживает тот же режим, что и его //peer MP//. Энергорежимы линков одного узла независимы, поэтому узел может работать в других режимах на других линках. Узел поддерживает энергорежим и для //non-peer MP// узлов (см. 11В.13.2 :?:).
+Узлы обладают собственным энергорежимом для каждого своего линка к другому узлу. Узел поддерживает тот же режим, что и его //peer MP//. Энергорежимы линков одного узла независимы, поэтому узел может работать в других режимах на других линках. Узел поддерживает энергорежим и для //non-peer MP// узлов (см. 11В.13.2 :?:).
 Определены 3 энергорежима: **активный**, **легкий сон**, **глубокий сон**.
@@ Line 31: / Line 35: @@
 Для взаимодействия с //peer MP// узлами в режимах //Light Sleep Mode// и //Deep Sleep Mode// соответственно узел может установить //Active Mode// для обоих. Два энергосберегающих узла устанавливают между собой режим //Deep Sleep Mode//.
-===== Энергорежимы для non-peer линков =====
+===== 2. Энергорежимы для non-peer линков =====
 Узел указывает свой //non-peer// энергорежим в поле //Power Management// в маяках и //Probe Response// кадрах, а также в //groupcast// кадрах. //Non-peer// энергорежим требуется, когда //non-peer MP// узел шлет //Probe Request// и //Peer Link Open Request// кадры. В результате будет установлен энергорежим, равный или меньший наименее активному режиму, в котором работает данный узел со своими //peer// узлами.
-===== Индикаторы энергорежима и переходы между энергорежимами =====
+===== 3. Индикаторы энергорежима и переходы между энергорежимами =====
 Все индикаторы энергорежима указаны в таблице 1. В соответствии с ней выставляются указанные биты в //unicast// кадрах, посылаемых по соответствующему линку.
-Алгоритм запуска смены энергорежима - вне данного стандарта.
+==== Переход в менее активный режим ====
+Для перехода в менее активный режим узел использует //unicast// кадры с подтверждением их получения. Переход может быть из активного режима в режимы легкого или глубокого сна или из режима легкого сна в глубокий сон.
+Если узел действует в режиме глубокого сна или собирается изменить режим хотя бы одного своего линка на режим глубокого сна, узел выставляет соответствующие биты (см. таблицу 1) во всех своих //multicast// и //broadcast// кадрах.
+Если узел ни с каким своим линком не работает в режиме глубокого сна, то если он находится в состоянии легкого сна или собирается поменять режим хотя бы одного своего линка на режим легкого сна, то во всех своих //multicast// и //broadcast// кадрах узел выставляет соответствующие таблице 1 биты.
+===== 4. Mesh TIM переходы =====
+Элемент //Mesh TIM//:
+  * идентифицирует узлы //MP// в энергосберегающем режиме (для которых предназначенный им ждущий обработки трафик буферизируется в отсылающих узлах). Информация эта закодирована в полу-виртуальной (partial virtual :?: -- частичной виртуальной. имеется в виду, что вся карта не передается, передается только ее часть от первого ненулевого бита и смещение этого бита) **битовой карте с использованием //AID//**;
+  * содержит индикатор, показывающий, ожидает ли обработки //groupcast// траффик.
+Каждая //MP// присваивает уникальный //AID// каждой своей //peer MP// во время процедуры установления линка. //AID// 0 (ноль) зарезервирован для указания наличия в буфере //groupcast MSDUs//.
+//MP// укажет, каким //MP// узел готов отправить буферизированные //MSDUs//, выставив соответствующие номерам //AIDs// биты в битовой карте элемента //Mesh TIM//.
+===== 5. Типы Mesh TIM элементов =====
+  - Mesh TIM
+  - Mesh DTIM
+//MP// передает //Mesh TIM// в каждом маяке. //Mesh DTIM// элемент передается в маяке с периодом //DTIMPeriod//.
+После посылки //Mesh DTIM// узел отправляет буферизированные //groupcast MSDUs// прежде, чем послать любой //unicast// кадр. В каждом таком //groupcast// кадре в поле //More Data Field// указано, есть ли еще в буфере ждущие отправки //groupcast MSDUs//. В последнем переданном //groupcast// кадре в этом поле 0.
+===== 6. Окно бодрствования (Awake Window) =====
+Энергосберегающий узел находится в состоянии бодрствования в течение своего собственного //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//.
+===== 7. Поддержка энергосбережения =====
+Как описано в 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// дремлющего узла.
+===== 8. Функционирование в различных энергорежимах различных линков =====
+==== Функционирование в активном состоянии ====
+Узел в активном состоянии, т.е. всегда бодрствует. Периоды сервисного взаимодействия между такими узлами не применяются для обмена кадрами.
+==== Функциоирование в состоянии глубокого сна ====
+Узел должен входить в бодрствующее состояние до того, как настанет очередной момент //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// узлов, также действующих в режиме легкого сна, к которым он указал в своем маяке наличие ожидающего трафика в буфере.
-==== Переход на менее активный уровень ====
+===== 9. Сигнализация в различных энергорежимах =====
-===== Mesh TIM переходы =====
+Узел, установивший режим глубокого сна со всеми своими //peer// узлами, должен передавать //DTIM// маяки. Если узел указал активный режим или режим легкого сна по отношению к любому своему //peer// узлу, он должен передавать //TIM// и //DTIM// маяки.
-===== Mesh TIM типы =====
+===== 10. Период сервисного взаимодействия //peer// узлов =====
-===== Окно бодрствования (Awake Window) =====
+Период используется для взаимодействия по линку, где хоть один узел работает в энергосберегающем режиме. В этот период по линку передаются //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//. Если и на последний повторно отправленный кадр не придет подтверждение его получения, узел может использовать следующий период сервисного взаимодействия для дальнейших посылок кадра и ожидания подтверждения.