диссертация. Талғатұлы Т Диссертация. Республики казахстан
 Скачать 2.81 Mb.
|
|
В PLU-периоде AP не использует любой пакет (например, ACK, RTS/CTS), чтобы сообщить о статусе отправки и приема пакетов у STA, потому что эти пакеты создают много расходов опроса, что приводит к снижению производительности канала. В этой ситуации может возникнуть проблема скрытого узла. Кроме того, кадры обновления информации из STA могут быть повреждены. Таким образом, для решения проблемы скрытого узла в результате повреждения или запаздывания пакетов обновления информации о статусе STA будем использовать подполе Count в формате PLU кадра. Значения Count [0;𝑁−𝑘−1] будут назначены станциям в строго обозначенном порядке: STA1 ∈ Count1 = 0, STA2 ∈ Count2 = 1, ... STAN-k ∈ CountN-k = 𝑁−𝑘−1. При получении станцией PLU-кадра происходит запоминание значения Count и реализуется следующий алгоритм: если Counti = 0, то STAi отправляет PLUR-кадр к AP; если Counti ≠ 0, то STAi продолжает прослушивать среду. Если STAi слышит пакеты из STAi-1, то STAi уменьшит свое значение Count до 0 и начнет передавать PLURi-кадр. Тем не менее, возможна ситуация, когда STAi не может слышать пакеты из STAi -1, так как они являются скрытыми узлами относительно друг от друга, или передача PLURi не удалась. Чтобы устранить эту проблему, точка доступа использует механизм rePLU. 3.2.2 Решение проблемы скрытого узла в PLU-периоде После получения PLURi-кадра от станции STAi AP будет продолжать ждать PLURi+1-кадр. Но может возникнуть ситуация, когда AP не получит PLURi+1. Например, если STAi и STAi+1 являются скрытыми узлами друг для друга, то STAi+1 не сможет выполнить обновление, поскольку она не может слышать STAi и не может уменьшить Count до 0. Или, хотя STAi+1 может отправить кадр PLURi+1 нормально, но кадр PLURi+1 поврежден. Для решения проблемы скрытого узла предложим механизм rePLU (Repeat PLU). После получения сообщения PLURi от станции STAi точка доступа будет продолжать ждать в течение интервала MIFS > SIFS. При этом MIFS (Multipolling Interframe Space) может быть реализован как PIFS, DIFS и т. п. После MIFS, если AP еще не получила сообщение PLURi+1 от станции STAi+1, то будет послан rePLU-кадр. Этот кадр похож на PLU-кадр, но содержит список неуспешных обновлений станций. Следует отметить, что значения Count будут снова назначаться от 0, т. е. STAi+1 присваивается Counti+1 = 0. С помощью этого механизма точка доступа может обновить информацию, а также приблизительно определить пару STA, столкнувшихся с проблемой скрытого узла. При повреждении PLU или PLUR1-кадра PLU-период будет отсутствовать. Чтобы этого избежать, AP отслеживает кадры от STA1, и если после MIFS нет сообщений от станции, то точка доступа должна отправить PLU-кадр заново. Повторная передача PLU-кадра возможна r раз, после чего AP удалит STA1 из списка и будет начинать с STA2 и т. д. При этом rePLU-кадры также следуют этому принципу. На рисунке 3.5 представлены временные диаграммы без использования и с использованием механизма rePLU. В случае а) показан ожидаемый PLU-период. В случае б) приведен пример работы rePLU-механизма после того, как STA3 не услышала PLUR2. После получения PLUR2 и ожидания в течение интервала MIFS точка доступа пошлет rePLU-кадр, который содержит информацию для остальных станций с измененными значениями Count (Count3 = 0, Count4 = 1 и т. д.).  Рисунок 3.5 – Использование rePLU-механизма 3.2.3 Реализация механизма мультиопроса MPP (Multi-Polling-Prioritized) является процессом передачи по восходящей (uplink) линии, в которой вводится механизм мультиопроса с помощью MPP-кадра для опроса всех STA в текущей группе m. На рисунке 3.6 представлен формат MPP-кадра. Поле Multipoll соответствует каждой из опрошенных STA и состоит из трех подполей: уже упоминаемые ранее при обсуждении формата PLU-кадра AID и Count, а также новое поле ТХОР, которое указывает станции назначенное значение TXOP для передачи данных. Значение ТХОР рассчитывается на основе значений поля Uplink parameters, которые собраны за PLU-период, что поможет преодолеть некоторые ограничения в поддержке VBR- трафика.  Рисунок 3.6 – Формат MPP-кадра. В этой главе исследуется только эффективность механизма мультиопроса. Так как количество опрошенных станций – это число станций в текущей приоритетной группе m, то оно задается в соответствии с алгоритмом работы DCF_out равным 𝑘. Таким образом, поле Count может принимать значения от 0 до (𝑘−1). На рисунке 3.6 показан формат MPP-кадра. MPP-период реализуется следующим образом. После окончания PLU- периода точка доступа по истечении SIFS посылает MPP-кадр для опроса всех STA в группе m. Каждая STA будет иметь определенное значение TXOP и Count. Для STAk верно Countk = k – 1. Станции, которые получили MPP-кадр, будут использовать соответствующее значение Count, чтобы выполнить передачу в определенном порядке. Точки доступа подтверждают успешную передачу с помощью сообщения ACK, содержащего информацию Count от станции-источника (рисунок 3.7). Следует отметить, что значения NAV также могут быть установлены с помощью MPP кадра. На рисунке 3.7 представлен формат ACK-кадра.  Рисунок 3.7 – Формат ACK-кадра При получении станцией STAj сообщения ACKi от станции STAi реализуется следующий алгоритм: если Countj – Counti = 1, то Count (STAj) = 0 и происходит передача кадра по истечении периода SIFS; если Countj – Counti ≠ 1, то STAj остается в режиме ожидания. 3.2.4 Решение проблемы скрытого узла в MPP-периоде Заметим, что в MPP-периоде проблема скрытого узла и потери пакетов могут возникнуть, но если использовать сообщения ACK, то их можно решить довольно простым способом. Данное предложение основывается на том, что каждое ACK от AP может быть услышано всеми STA этой AP. Пусть STAj не слышит пакеты STAi из-за проблемы скрытого узла. Тогда STAj может слышать ACKi, которое AP отправляет STAi. Таким образом, STAj становится активной в отправке ее сообщения и может избежать столкновений. Здесь можно использовать тот же подход, что и в PLU-периоде, когда STA слушают пакеты других станций. Но это приводит к снижению производительности из-за увеличения вероятности того, что две STA не могут слышать друг друга из-за скрытого узла, по сравнению с вероятностью потери АСК. Так как сообщение АСК тоже может быть потеряно, что приводит к бесконечно долгому ожиданию остальных STA, используем reMPP-механизм, аналогичный rePLU-механизму во избежание этой проблемы. Предположим, что АР не получала кадры станции STAi (TXOPi) из-за ошибки TXOPi или из-за потери ACKi-1. Следовательно, STAi не может выполнить передачу, так как ее значение Count не может уменьшиться до 0. В этом случае после отправки ACKi-1 AP будет ждать временной интервал MIFS > SIFS. Если AP не получит кадры из STAi, то пошлет reMPP-кадр, который содержит список не- удачно опрошенных станций и значения Count будут изменены. В примере на рисунке 3.8 вариант а отражает ожидаемый алгоритм реализации МРР-периода без проблем. В случае б) AP не может получить TXOP2 из-за ошибки или потери ACK1. Сообщение reMPP может быть передано r раз, как и в rePLU-механизме. Кроме того, поскольку длительность MPP-периода ограничена, то после превышения допустимой длительности, обслуживание STA, которые не успели передать данные, будут перенесено на следующий период и они будут расположены в начале списка опроса. На рисунке 3.6 показано использование reMPP-механизма.  Рисунок 3.8 – Использование reMPP-механизма 3.3 Оценка эффективности механизма мультиопроса с точки зрения критериев QoS Механизм мультиопроса был предложен в связи с необходимостью сокращения расходов опроса по сравнению с механизмом простого опроса. Расходы опроса уменьшают утилизацию канала, увеличивают задержку доступа и влияют на отклонение задержки (джиттер). Поэтому для оценки эффективности предлагаемого механизма по сравнению с существующими используем в качестве показателя расход опроса (PO – Polling overhead), или время, затраченное на процедуру опроса и неудачные попытки опроса. Согласно IEEE 802.11 всякий раз, когда AP опрашивает станции, не имеющие ожидающих данных, она добавляет в расходы время опроса, время ответа с кадром Null и время, затраченное протоколом для передачи. Эти расходы увеличиваются с увеличением количества таких станций. Для PCF в IEEE 802.11:  (3.1) (3.2)где N – число STA в BSS; pN – количество STA, на которых нет ожидающих данных, они будут отвечать нулевыми пакетами (Null); Tpoll_Fail – время ответа STA Null-пакетами; Tpoll и TNull – время отправки кадра опроса и Null-кадра соответственно; (1−𝑝)𝑁 – количество STA, на которых есть данные для передачи. Для предложенного механизма (далее – ММО) необходимо рассмотреть два случая: 1) Есть PLU-период: теку щая группа m наибольшая, система должна обновить новый список опроса:  (3.3)2) Нет PLU-периода: текущая группа m не самая большая, система не должна обновить список опроса:  (3.4) (3.5) (3.6) (3.7) (3.8)где TMPP, TPLU, TPLUR – время отправки MPP, PLU, PLUR-кадров соответственно; k – число STA в текущей группе m или количество активных STA, которые не будут обновлены при создании нового списка опроса; phys.rate – физическая скорость. В формулах (3.3) и (3.4) рассмотрен наихудший случай, то есть все остальные (N – k) STA имеют пакеты для передачи. Аналогично рассчитаем расход опроса TS-MP-механизма:  (3.9)где TSRMP, TSR, TDTMP – время отправки SRMP, SR, DTMP-кадров соответственно. Был предложен механизм мультиопроса RAL для решения проблемы скрытого узла, для которого:  (3.10) (3.11)В работе предложен UPCF-механизм с приоритетами. Для унификации сравнения предположим, что существуют только 4 приоритета как в ММО, опустим расчет времени процедуры разбиения дерева (tree-splitting) и учтем время решения коллизии только для одной коллизии. Можно сказать, что реальный расход опроса этого механизма будет больше, чем расход опроса, рассчитанный по следующей формуле:  (3.12)где 𝑇𝑃𝐸𝐻, 𝑇𝑃𝑅, 𝑇𝑅𝐸, 𝑇𝑉_𝑃𝑂𝐿𝐿 – время отправки PEH, PR, RE, V-POLL-кадров соответственно; h = 0,5k – количество станций, которые подвергаются коллизии. Следует отметить, что авторы не указали значения 𝑇𝑃𝐸𝐻, а функционально этот кадр похож на кадр опроса в PCF, поэтому было принято 𝑇𝑃𝐸𝐻=𝑇𝑝𝑜𝑙𝑙. При этом полученная оценка расхода опроса данного механизма будет оптимистична из-за внесенных ограничений. В этом сравнении приняты некоторые параметры по умолчанию согласно таблице 3.3. Версия стандарта IEEE 802.11 не влияет на точность сравнения, поэтому используется IEEE 802.11g как пример. Таблица 3.3 – IEEE 802.11g: параметры по умолчанию
|