CC BY
9МЕХАНИЗМ МУЛЬТИОПРОСА НА ОСНОВЕ ПРИОРИТИЗАЦИИ ДЛЯ WLAN С ВЫСОКОЙ ПЛОТНОСТЬЮ УСТРОЙСТВ
Ч.Д. Ле1, О.А. Симонина1
1 Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича, Санкт-Петербург, 193232, Российская Федерация Адрес для переписки: [email protected]
Информация о статье
УДК 621.396
Язык статьи - русский
Ссылка для цитирования: Симонина О. А., Ле Ч.Д. Механизм мультиопроса на основе при-оритизации для WLAN с высокой плотностью устройств // Труды учебных заведений связи. 2017. Т. 3. № 1. С. 80-92.
Аннотация: Статья посвящена вопросу повышения качества обслуживания в высокозагру-женных мультисервисных сетях Wi-Fi. Предлагается модифицировать метод мультиопроса с учетом требований к трафику по критерию минимизации задержки. Для этого предлагается модифицировать механизм опроса и переложить вопросы конкуренции со станций на точки доступа. Также предлагается модифицировать стандартизированные форматы PLU и PLUR-кадров, переопределяя резервные поля для поддержки работы предлагаемого механизма.
Ключевые слова: Wi-Fi, мультиопрос, качество обслуживания, PCF, DCF.
THE MULTIPOLLING MECHANISM BASED ON THE PRIORITIZATION FOR WLAN IN A HIGH DENSE NETWORKS
Le Tran Duc1, O. Simonina1
1The Bonch-Bruevich Saint-Petersburg State University of Telecommunication, St. Petersburg, 193232, Russian Federation
Article info
Article in Russian
For citation: Le Tran Duc, Simonina O. The Multipolling mechanism based on the prioritization for WLAN in a high dense networks // Proceedings of educational institutes of communication. 2017. Vol. 3. Iss. 1. PP. 80-92.
Abstract: This article is devoted to improving the quality of service in multiservice high-density Wi-Fi networks. It is proposed to modify the multipolling mechanism given the traffic requirements and minimizing delays. For this purpose it is proposed to modify the polling mechanism and to shift the competition from the stations to the access point. It is also proposed to modify standardized formats PLU and PLURframes, overriding the backing field to support the work of the proposed mechanism.
Keywords: Wi-Fi, Multipolling Mechanism QoS, PCF, DCF.
Введение
Сети на основе семейства стандартов IEEE 802.11 не только доминируют на рынке сетей беспроводного доступа, но и, по прогнозам [1], эта тенденция сохранится в ближайшие несколько лет несмотря на активное развитие мобильной передачи данных (рис. 1). Это не удивительно, так как сети Wi-Fi обладают рядом неоспоримых достоинств: недороги, используют нелицензируемый диапазон, гибки в конфигурации, позволяют проводить процедуры авторизации пользователей и устройств, совместимы с Ethernet и стеком протоколов TCP/IP, обладают хорошей пропускной способностью. Все это обусловило широкое применение Wi-Fi в домашних, корпоративных и сетях доступа в общественных местах. При этом сети Wi-Fi не являются мультисервисными в полном смысле -скорее, это сеть передачи данных с пропускной способностью, позволяющей передавать большие объемы трафика, в том числе видео. Для малозагруженных сетей подход на основе best effort вполне объясним, но в сетях с высокой плотностью узлов он порождает ряд проблем.
Рисунок 1. Прогноз увеличения количества IP-трафика, создаваемого различными сетями доступа, согласно Cisco VNI [1]
Стандарт IEEE 802.11 [2] определяет два режима работы: DCF (Distributed Coordination Function) и PCF (Point Coordination Function). Режим PCF используется в период без конкуренции CFP (Contention-Free Period). За счет сокращения затрат времени на конкуренцию PCF может поддерживать приложения с требования по минимизации задержки. Однако механизм PCF не может в полной мере обеспечивать передачу мультимедийного трафика с заданным качеством [3, 4, 5].
Сейчас для поддержки мультисервисности предлагается несколько решений. Стандартизированные закреплены в рекомендации IEEE 802.11e [2] и реализованы за счет различения классов трафика и выстраивания системы приоритетов для каждого из них. Однако в IEEE 802.11e существует проблема с обеспечением передачи трафика с переменной скоростью VBR (Variable Bit
Rate), когда мгновенная скорость передачи и размер пакета, как правило, довольно сильно отличаются от соответствующих средних значений [3].
В направлении разработки механизмов обработки мультисервисного трафика в сетях Wi-Fi уже давно работают многие коллективы авторов. Большинство этих механизмов представляют собой модификации PCF или HCCA (HCF (Hybrid Coordination Function) Controlled Channel Access) и сосредоточены на следующих ключевых проблемах:
- создание списка опроса;
- управление списком опроса;
- определение последовательности опроса;
- уменьшение времени, затраченного на неудачные попытки опроса (PO -Polling overhead) - в дальнейшем будем это называть расходом опроса.
Например, в работе [4] авторы предложили использовать два кадра мульти-опроса с разными целями. Первый кадр передается с целью сбора информации co станции (STA). Второй кадр, сконструированный на основе собранной информации, содержит последовательность опроса для передачи данных. Тем не менее, этот механизм имеет довольно много недостатков. Например, авторы не рассматривали проблему коллизий, которые могут возникнуть из-за проблемы скрытого узла во время сбора информации и в процедуре передачи данных. Кроме того, не указаны порядок сбора информации и опроса станций (STAs), таким образом, если кадр опроса поврежден, то может появиться сбой в работе всех STAs.
В статье [6] авторы предложили модифицированный PCF, который улучшает использование среды. Основная цель этого механизма заключается в уменьшении влияния проблемы скрытого узла с помощью счетчика столкновений. Механизм UPCF (UnifiedPoint Coordination Function) в работе [3] является одним из механизмов мультиопроса, использующих приоритет для пропуска трафика различных типов в соответствии с требованиями QoS (Quality of Service). Он поддерживает возможность обслуживания VBR-трафика с использованием соответствующих значений ТХОР (Transmit Opportunity). UPCF использует технику подтверждения установления связи (handshaking) для реализации приоритетов трафика в период CFP. В работе [7] предложен другой механизм мультиопроса: каждая станция передает только тогда, когда она получает конкретное количество простых сообщений опроса, при необходимости с вложенным кадром подтверждения.
Большинство работ в области управления качеством в сетях Wi-Fi опубликованы в прошлом десятилетии. Однако с переходом на сети с высокой плотностью устройств возникла необходимость пересмотреть используемые механизмы. Появление новых исследований и проектов ( исследуемых, например, в [8, 9]) позволяет сделать вывод о необходимости пересмотра подходов к обеспечению качества в сетях Wi-Fi.
Механизм мультиопроса на основе групп
В [10, 11] предложено объединить режимы доступа PCF и DCF для назначения права доступа к среде точкам доступа (APs) и станциям. Основная идея заключалась в разделении механизма приоритизации APs на два:
- PCF_in, выполняемый для одной AP и предназначенный для выдачи права доступа к среде STA, а также обеспечивающий передачу данных;
- DCF_out, выполняемый на основе модифицированного списка опроса для обеспечения конкуренции точек доступа за право доступа к среде.
Для разграничения прав доступа к среде было предложено ввести группы приоритета m исходя из требуемых значений задержки (табл. 1). Пусть d - максимально допустимое значение задержки, тогда чем меньше d, тем выше в списке находится тип трафика. В случае, если значения d для разных потоков равны, то они помещаются в одну группу m, где m - приоритет группы, m = 1, 2, 3,..., N. Таким образом, чем выше требования к задержке, тем выше приоритет группы m. При этом количество групп определяется исключительно количеством граничных требований по задержке, а не только типом трафика.
Таблица 1. Пример приоритизации трафика в зависимости от требований к задержке
Тип трафика Категория доступа Приоритет группы m Допустимое значение межконцевой задержки d, мс
Voice AC_VO 1 <50
Video AC_VI 2 50-250
Best Effort AC_BE 3 250-400
Background AC_BK 4 Не нормировано
Обозначим как к количество станций в одной группе т. Значение к используется для конкуренции в ВСБ_ои и рассматривается как один из параметров для обеспечения QoS. Например, если две БТЛ обслуживают трафик, принадлежащий одной группе, то в списке доступа они располагаются с приоритетом по времени подключения. Таким образом, происходит перенос конкуренции с STA на АР. В случае незанятой среды АР продолжают ждать в течение времени:
ООНБ^т) = ттЫ
где ттт - наименьшее значение т в списке опроса, slot_times = 9 или 20 мс в зависимости от реализации, что позволит передавать высокочувствительный к задержкам трафик раньше.
В работе [10] рассмотрен случай, когда несколько точек доступа имеют одинаковое значение т, т. е. конкурируют за доступ к среде, что не исключает возможность возникновения коллизии. В этой статье предположено, что всегда имеется АР, которая выигрывает конкуренцию на право доступа к среде. Кроме
того, предлагается добавить передачу по нисходящей линии (downlink) к механизму, предложенному в [10]. Осуществление передачи «вниз» также должно следовать схеме приоритетов: кадр, полученный AP, вставляется в буфер в соответствии с назначенным приоритетом. Таким образом, кадры с более высоким приоритетом окажутся ближе к началу буфера, за счет чего появляется возможность уменьшить значение задержки для высокоприоритетного трафика. Если продолжительность периода недостаточна для передачи всех кадров, то оставшиеся кадры будут переданы в следующем периоде первоочередно. Под периодом подразумевается время от начала CP (Contention Period) предыдущего интервала обслуживания (SI - Service Interval) до конца CFP текущего интервала обслуживания. После передачи кадров AP будет сохранять управление средой и продолжать мультиопрос в режиме PCF_in (рис. 2).
Deacon lnkival
Г SI i Sl_i+1 si -2 -►
CFP CI3 CF-'P . . CP CFP CP
в е ii sirs Pf.tf Polling list 155 MIT Pulling Ii3<" DL PI.U MPI' Polling list DL В e ^
i <? 1} 4- tonkjafil Time 4—> 4r FintUrL Time BaikoiT, Time и и п
Period -> 4- Period -
Рисунок 2. Интервал между посылками маячка в механизме мультиопроса
Реализация механизма мультиопроса при передаче «вниз»
После DCF_out точка доступа контролирует среду и при необходимости продолжает передачу «вниз», после которой будет ждать в течение SIFS. По истечении SIFS запускается два процесса длительностью PLU (период обновления списка опроса - Polling List Update period) и MPP (период мультиопроса по приоритету - Multi-Polling-Prioritized period). В течение PLU точка доступа обновляет список опроса в заданном порядке для избегания коллизий. Во время MPP точка доступа опрашивает все STAs группы m в списке опроса (см. рис. 2).
Период PLU задает процесс обновления/удаления STAs в списке опроса, который будет использоваться в следующем периоде механизмом DCF_out для конкуренции за право доступа к среде. Следует отметить, что в каждом MPP-периоде только станции, принадлежащие группе m с наивысшим приоритетом, могут выполнить передачу. Если в списке опроса появляются новые станции, которые принадлежат к высокоприоритетным группам m, то уже подключенные станции в низкоприоритетных группах m могут потерять доступ к среде. Во избежание этого PLU-период реализуется только если текущая группа m является
самой большой группой в списке опроса, что также позволит уменьшить время, затраченное на неудачные попытки опроса (PO - Polling overhead). Например, APi имеет 4 группы m = 1, 2, 3, 4 и AP2 - 2 группы m = 1, 3. Таким образом, APi будут обновлять список опроса в период, когда текущая группа m = 4 и AP^ -когда текущая группа m = 3.
PLU-процесс происходит следующим образом: за интервал SIFS после Beacon-кадра (или после СР-периода), AP будет посылать PLU-кадр всем STAs. Станции отвечают PLUR-кадрами (Polling List Update Response frames), которые содержат необходимую информацию для создания точкой доступа нового списка опроса и выполнения необходимых расчетов для нового MPP-периода. На рис. 3 и 4 представлены форматы PLU и PLUR-кадров, используемых в предлагаемом механизме мультиопроса.
Рисунок 3. Формат PLU-кадра
Otitis: 2 I
Рисунок 4. Формат PLUR-кадра
Длина PLU-кадра изменяется в зависимости от количества STAs, принадлежащих к этому BSS. На рис. 3 поле Indicator состоит из подполя AID (Association Identifier), которое идентифицирует станцию в BSS и подполя Count, которое имеет значения от 0 до (N-k-1). Здесь k - это число станций в самой большой группе m, N - число STAs в BSS. Подполе Count используется для
определения порядка обновления/опроса, уменьшения потерь кадров и решения проблемы скрытого узла. BSSID - идентификатор BSS, FCS - последовательность контрольных битов кадра.
На рис. 4 поле Uplink parameters содержит информацию, необходимую для расчета TXOP аналогично TSPEC IEEE 802.11e. Поле Priority состоит из трех подполей: m, User priority (приоритет пользователя) и Reserved (резервный). Подполе m указывает приоритет трафика, т. е. группу m станции в новом списке опроса. Подполе User priority может использоваться для поддержки QoS в других решениях, например, классификации и контроля трафика на OpenFlow-ком-мутаторах с использованием технологии SDN. Подполе Reserved зарезервировано для будущего пользования.
Переопределим поле Frame Control в IEEE 802.11-2012, так как согласно стандарту это поле не используется для поддержки мультиопроса. Для этого используем зарезервированные байты (определяющие тип и подтип) в поле Frame Control (b3 b2, b7-b4). Подобный подход уже встречался в научных работах, например, в [7]. Переопределённое поле Frame Control будет содержать новые параметры (табл. 2), при этом ACK-G в будущем можно использовать для снижения расходов кадров ACK.
Таблица 2. Описание переопределённых кадров поля Frame Control
Значение типа b3 Ь2 Описание типа Значение подтипа b7b6b5 Ь4 Описание подтипа
11 Мультиопрос 0000-1011 Reserved (резервный)
11 Мультиопрос 1100 ACK-G
11 Мультиопрос 1101 MPP
11 Мультиопрос 1110 PLUR
11 Мультиопрос 1111 PLU
Для решения проблемы скрытого узла в результате повреждения или запаздывания пакетов обновления информации о статусе STA будем использовать подполе Count в PLU-кадре. Значения Count (от 0 до N-k-X) будут назначены станциям в строго обозначенном порядке:
STAx е Counti = 0, STA2 е Count2 = 1,
STAN-k е CountN-k = N-k-1).
При получении станцией PLU-кадра происходит запоминание значения Count и реализуется следующий алгоритм:
если Counti = 0, то STAi отправляет PLUR-кадр к AP; если Counti Ф 0, то STAi продолжает наблюдать среду.
Если STAi слышит пакеты из STAi-i, то STAi уменьшит свое значение Count до 0 и начинет передавать PLUR-кадр. Тем не менее, возможна ситуация, когда STAi не может слышать пакеты из STAi-i, так как они являются скрытыми узлами относительно друг от друга, или передача PLURi не удалась. Чтобы устранить эту проблему, точка доступа использует механизм rePLU.
Решение проблемы скрытых узлов в механизме мультиопроса при передаче «вниз»
Для решения проблемы скрытых узлов используем механизм rePLU. После получения сообщения PLURi точка доступа будет продолжать ждать в течение MIFS > SIFS. При этом MIFS может быть реализован как PIFS, DIFS и т. п. Если AP еще не получила сообщение PLURi+i от станции STAi+i, то будет послан rePLU-кадр. Этот кадр похож на PLU-кадр, но содержит список неуспешных обновлений станций. Следует отметить, что значения Count будут снова назначаться от 0, т. е. STAi+i присваивается Counti+i = 0.
При повреждении PLU или PLURi-кадра PLU-период будет отсутствовать. Чтобы этого избежать, AP отслеживает кадры от STAi, и если после MIFS нет сообщений от станции, то точка доступа должна отправить PLU-кадр заново. Повторная передача PLU-кадра возможна r раз, после чего AP удалит STAi из списка и будет начинать с STAi и т. д.
На рис. 5 представлены временные диаграммы без и с использованием rePLU-механизма. В случае b) приведен пример работы rePLU-механизма после того, как STA3 не услышала PLUR2. После получения PLUR2 и ожидания в течение интервала MIFS точка доступа пошлет rePLU-кадр, который содержит информацию для остальных станций с измененными значениями Count (Count3 = 0, Count4 = i и т. д.).
PLU
SIFS ч-►
PLUR L «-У PLUR 2
> PLL'R j
PLUR 4 4-> PLUR S <
PLUR б
i)
b}
Рисунок 5. Использование rePLU-механизма
Реализация механизма мультиопроса при передаче «вверх»
Введем механизм мультиопроса в процесс передачи «вверх» (uplink), используя MPP-кадр для опроса станций в текущей группе m. На рис. 6 представлен формат MPP-кадра. Поле Multipoll соответствует каждой из опрошенных STA и состоит из трех подполей: уже упоминаемые ранее при обсуждении формата PLU-кадра AID и Count, а также новое ТХОР, которое указывает назначенное
значение TXOP станции для передачи данных. Значение ТХОР рассчитывается на основе значений поля Uplink parameters, которые собраны за PLU-период, что поможет преодолеть некоторые ограничения в поддержке VBR-трафика [3, 12]. Так как количество опрошенных станций - это число станций в текущей приоритетной группе m, которое в соответствии с алгоритмом работы DCF_out, то оно будет равно k. Таким образом, поле Count может принимать значения от 0 до (k-1).
Octets:
MultipolM Multipoll_k
Control BSSID FCS
Octets: 2
AID I
1 1 TXOP1 CoLinl_l
Рисунок 6. Формат MPP-кадра
После окончания PLU-периода точка доступа по истечении SIFS посылает MPP-кадр для опроса всех STAs в группе m, тогда для STAk верно Countk = k-1. Станции, получившие MPP-кадр, будут использовать соответствующее значение Count для определения порядка передачи. Точки доступа подтверждают успешную передачу с помощью сообщения ACK, содержащего информацию Count от станции-источника.
При получении станцией STAy сообщения ACKi от станции STAi реализуется следующий алгоритм:
если County - Counti = 1, то Count (STAy) = 0 и происходит передача кадра по истечению периода SIFS;
если County - Counti Ф 1, то STAy остается в режиме ожидания.
Решение проблемы скрытых узлов в механизме мультиопроса при передаче «вверх»
В данном случае проблема скрытого узла может быть решена с использованием сообщений АСК. Каждое АСК от АР может быть услышано всеми БТАб этой АР. Пусть БТАу не слышит пакеты БТА/ из-за проблемы скрытого узла. Тогда БТАу может слышать АСК/, которое АР отправляет БТА/. При этом вероятность, что две БТАб не могут слышать друг друга из-за скрытого узла будет выше, чем вероятность потери АСК. Так как сообщение АСК тоже может быть потеряно, используем геМРР-механизм, аналогичный геРЬЦ-механизму.
Предположим, что АР не получала кадры станции БТА/ (ТХОР/) из-за ошибки ТХОР/ или из-за потери АСК/-1. В этом случае после отправки АСК/-1 АР будет ждать временной интервал МГРБ > БГРБ. Если АР не получит кадры из БТА/, то пошлет геМРР-кадр, который содержит список неудачно опрошенных станций (рис. 7).
sirs
МРР ч—► ТХОР I
аск_ I "
ТХОР Î
АС к
ТХОР J
а)
SIFS IACK I MIFS ! ¡SIPS I ACIC AC к
МРР <—► ТХОР L <—* , ч-—► ТХОР 2 м ► " - * >, ТХОР 3 м_►
[ 1 - 3
Ъ)
Рисунок 7. Использование reMPP-механизма
В примере (рис. 7) вариант а) отражает ожидаемый алгоритм реализации МРР-периода без проблем. В случае b) AP не может получить TXOP2 из-за ошибки или потери ACKi. Сообщение reMPP может быть передано r раз, как и в rePLU-механизме. Кроме того, поскольку длительность MPP-периода ограничена, то после превышения допустимой длительности, STAs, которые не успели передать данные, будут перенесены на следующий период и расположены в начале списка опроса.
Сравнение расходов опроса различных механизмов
Для оценки эффективности предлагаемого механизма с существующими используем такой показатель как время, затраченное на неудачные попытки опроса (PO - Polling overhead), или расход опроса.
Для PCF в IEEE 802.11:
POPCF =pNTpollpail + (1 ~p)NTpoll, Tpoll_Fail = Tpoll +SIFS + TNull +SIFS,
где N - число STAs в BSS;
pN - количество STAs, на которых нет ожидающих данных, они будут отвечать нулевыми пакетами (Null); Tpoii_Faii - время ответа STA Null-пакетами;
Трои и TNuu - время отправки кадра опроса и Null-кадра соответственно; (l-p)N - количество STAs, на которых есть данные для передачи.
Для предложенного механизма (далее - ММО) необходимо рассмотреть два случая:
1) Есть PLU-период - текущая группа m наибольшая, система должна обновить новый список опроса:
РОммо = TPLU + (N- k)TPLUR + 2(N- k)SIFS + TMPP + 3SIFS.
2) Нет PLU-периода - текущая группа m не самая большая, система не должна обновить список опроса:
_ _ 12 + 4 к
РОММО ~2SIFS + TMpp, ТМРР —
phys. rate '
8[12 + 3 (N-k)] 32,8
Трш =-т-:-, Tplur = ^-—, к = (1-p)N,
pays. rate pays. rate
где TMpp,TpLU,TpLUR - время отправки MPP, PLU, PLUR-кадров соответственно; k - число STAs в текущей группе m или количество активных STAs, которые
не будут обновлены при создании нового списка опроса; phys.rate - физическая скорость.
Аналогично рассчитаем расход опроса TS-MP-механизма [3]:
POTS-MP ~TSRMP +kTSR + 2(k+1)SIFS + TDTMP,
где Tsrmp,Tsr,Tdtmp - время отправки SRMP, SR, DTMP-кадров соответственно.
В [9] авторы предложили механизм мульти-опроса RAL для решения проблемы скрытого узла, для которого:
PORAL = TRAL +pNTpollFail,
Tpoll_Fail = 2SIFS + TNull.
В работе [2] предложен UPCF-механизм с приоритетами. Предположим, что существуют только 4 приоритета как в ММО, и опустим расчет времени процедуры разбиения дерева (tree-splitting), учтем время решения коллизии только для одной коллизии. Тогда:
POupcf = 4ТРЕн + 3 PIFS + (k+1)TPR + 2 kSIFS + TRE + hTRR + (h+ 1)SIFS + TVpoLL,
где ТРЕн, ТРН, ТНЕ, Ту_РОц - время отправки РЕн, PR, RE, V-POLL-кадров соответственно;
к = 0,5к - количество станций, которые подвергаются коллизии.
Следует отметить, так как авторы не указали значения ТРЕн, а функционально этот кадр похож на кадр опроса в PCF, то принято ТРЕн = Тро11. При этом полученная оценка расхода опроса данного механизма будет оптимистична из-за внесенных ограничений.
Некоторые параметры для стандарта IEEE 802.11g приняты по умолчанию (табл. 3).
Таблица 3. IEEE 802.11g: параметры по умолчанию
Параметр Символ Значение
Интервал SIFS SIFS 10 |is
Интервал PIFS PIFS 25 |s
Физическая скорость phys.rate 54 Mbps
Размер CF-Poll Sizepoll 20 bytes
Размер ACK SizeACK 14 bytes
Размер Null-кадра Sizernu 34 bytes
Время отправки кадра опроса Tpoll 8xSizepoii/phys.rate
Время отправки Null-кадра Trnii 8xSizeNuii/phys.rate
Время отправки Data Tuata 8xPsize/phys. rate
Время отправки ACK Tack 8xSizeACK/phys.rate
На рис. 8 приведены результаты сравнительного анализа эффективности предлагаемого механизма с существующими. Здесь p - доля станций, отвечающих Null-пакетами; Ti(w) - PCF в IEEE 802.11; T2(n) - ММО с PLU-периодом; Тз(п) -ММО без PLU-периода; T4(n) - TS-MP [3]; Ts(n) - RAL [9]; Тб(п) - UPCF [2].
Рисунок 8. Результаты сравнительного анализа эффективности различных механизмов опроса
Легко видеть, что без использования PLU-периода расход опроса предлагаемого механизма - обозначен как Тз(п) - всегда наименьший. Однако в периоде обновления списка опроса эффективность предлагаемого механизма снижается (обозначен как Т2(п)). При этом с ростом количества активных станций эффективность предлагаемого механизма наилучшая из всех рассмотренных. Также явно видны преимущества предлагаемого механизма в случае увеличения количества STAs в BSS, что важно при использовании во WLAN с высокой плотностью устройств.
Выводы
Предложенный механизм использует пиритизацию на двух этапах для повышения способности поддержки QoS в сетях с высокой плотностью точек доступа. На первом этапе пиритизация позволяет различить точки доступа по различным группам m в соответствии с приоритетом трафика. На втором
этапе точка доступа использует механизм мультиопроса для опроса станций в группе т. Основным нововведением является использование PLU-кадров для сбора информации от станций и обновления списка опроса, а также MPP-кадров для координации передачи данных без коллизий. Предложенный механизм позволяет точкам доступа планировать последовательность опроса, основываясь на информации, полученной от всех станций, что позволит в будущем разработать более эффективные схемы планирования.
В дальнейшем необходимо определить оптимальное значение TXOP, производительность системы и задержки для предлагаемого механизма.
Список используемых источников
1. Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 20162021 White Paper. [Электронный ресурс] http://www.cisco.eom/c/en/us/solutions/collateral/ ser-vice-provider/visual-networking-index-vni/mobile-white-paper-c11-520862.html
2. Standards Committee et al. Wireless LAN medium access control (MAC) and physical layer (PHY) specifications: Amendment 8: Medium Access Control (MAC) Quality of Service enhancements // IEEE Computer Society. 2005.
3. Chou Z.T., Hsu C.C., Hsu S.N. UPCF: a new point coordination function with QoS and power management for multimedia over wireless LANs // IEEE/ACM Transactions on Networking (TON). 2006. Vol. 14. Iss. 4. PP. 807-820.
4. Kim B.S. et al. Two-step multipolling MAC protocol for wireless LANs // IEEE Journal on Selected Areas in Communications. 2005. Vol. 23. Iss. 6. PP. 1276-1286.
5. Zhong Z. et al. Issues and challenges in dense WiFi networks // Wireless Communications and Mobile Computing Conference (IWCMC), 2015 International. IEEE. 2015. PP. 947-951.
6. Kanjanavapastit A., Landfeldt B. Enhancements of the modified PCF in IEEE 802.11 WLANs // Journal of Communications and Networks. 2005. Vol. 7. Iss. 3. PP. 313-324.
7. Fang Y. et al. On the performance enhancement of wireless lan-a multi-polling mechanism with hidden terminal solution // Global Telecommunications Conference, 2005. GL0BEC0M'05. IEEE. 2005. Vol. 1. P. 5.
8. Красавина Т., Банков Д.В., Хоров Е.М. Исследование протокола распределенного управления процессом присоединения устройств при отсутствии помех в канале / Институт проблем передачи информации им. А. А. Харкевича РАН (Москва). Конференция: Информационные технологии и системы. Сочи. 07-11 сентября 2015 г.
9. Perez S.C. et al. Tuning mechanism for IEEE 802.11 e EDCA optimization // IEEE Latin America Transactions. 2013. Vol. 11. Iss 4. PP. 1134-1142.
10. Ле Ч.Д., Симонина О.А. Механизм приоритезации для обеспечения минимизации задержки в условиях конкурентной среды в сетях Wi-Fi с плотным распределением устройств // Информационные технологии и системы. 2016. № 3(95). С. 99-106.
11. Ле Ч. Д., Симонина О. А. Организация приоритетного доступа в сетях IoT с высокой плотностью устройств и чувствительными к задержкам сервисами // Электросвязь. 2016. № 9. С. 63-67.
12. Al-Maqri M.A. et al. Adaptive multi-polling scheduler for QoS support of video transmission in IEEE 802.11 e WLANs // Telecommunication systems. 2016. Vol. 61. Iss. 4. PP. 773791.
