Рано или поздно в жизни вам предстоит построить point-to-point wireless link на оборудовании под управлением RouterOS, и вы с очень большой вероятностью будет ожидать канал шириной 300Mbps от N стандарта. Но спешу вас огорчить, 300 Mbps вы получите только на канальном уровне, можете смело вычесть отсюда примерно 25% и вы получите реальную пропускную способность канала. И это всё при условии чистых частот и отсутствия помех.

Если вам нужны эти 25%, хотя сказать по правде если и сможете их достать то не более 20% для этого начинается тонкий тюнинг wireless такая как агрегация фреймов, отказ от 802.11 CSMA/CA и переход на nsteream или NV2, а также настройка мощности передатчика на определенных индексах модуляции и некоторые другие нюансы…

Но сегодня кратко об одном единственном параметре, это параметр CCQ, данная аббревиатура расшифровывается как Client Connection Quality, т.е она нам говорит от том на сколько качественно используется канал конкретным клиентом.

Представим себе что у нас есть точка доступа RouterOS b/g/n, к ней подключен единственный клиент Вася на стандарте 802.11b.

Клиент подключился и согласовал с точкой доступа канал 11 Mbps.

Точка доступа должна отправить 1375 KB клиенту ethernet трафик, такое значение равно 11Mbit, для удобства в дальнейшем расчёта.

Исходя из представленных данных точка доступа, должна отправить данные в течении 1 секунды, так как канальная скорость определяется в Mbit в секунду, а данных нам надо передать 11Mbit. Если точка доступа уложилась в 1 секунду мы можем считать, что канал утилизирован на 100%.

Не всё так просто

Если капнуть чуть глубже, то wireless клиент при получении фрейма должен отправителю отправить ACK сообщение о том что фрейм получен.

Заголовок 802.11 равен 34 байта, и 1372KB тоже не одним фреймом будут отправлены , заголовок ethernet без учёта преамбулы и fcs равен 14 байтам. Возьмём для расчёта MTU 1500 байт

1372*1000 = 1372000 байт необходимо отправить.

1372000/1500 = примерно 915 пакетов, такое количество пакетов необходимо отправить до клиента.

915*(14+34) - размер заголовков ethernet и wireless = 43920, дополнительная нагрузка которая ляжет на плечи wireless интерфейса.

И того точки доступа необходимо будет передать 915 фреймов каждый размером в 1548 байт. А это уже 1415920 байт а это уже рост примерно на 3%.

Каждый раз когда точка доступа будет вещать в эфир данный фрейм клиенту, она будет знать, что при текущем подключении 11Mbps фрейм размером в 1546 байт должен быть доставлен клиенту за определённое время.

11Mbps = 11000000 bit в секунду.

1548 байт = 12384 bit

И тут есть ещё один нюанс, мы должны получить от клиента подтверждение, управляющий фрейм ACK который равен 34 байтам.

Для удобства расчётов переведём секунды в миллисекунды, 1 секунда = 1000ms

11000 bit per ms - скорость подключения клиента к точке доступа.

Для отправки 12384 bit точка доступа потратит 1,125 ms + 0,024 ms на прием управляющего кадра.

И того если пакет равен 1500 байт, точка доступа должны получить управляющий фрейм через 1,149ms и это без учёта времени которое потребуется клиенту на обработку и формирование фрема и без учёта скорости распространения сигнала.

Другими словами если через 1,149 ms не получен подтверждающий фрейм, начинается процедура повторной отправки фрейма (данную процедуру можно настраивать в RouterOS)

Отсюда и рассчитывается значение CCQ и естественно выводится усреднённое значение.

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

Можем сделать вывод, что на CCQ, также влияет сам клиент, если клиент «тормозит», то точка доступа будет пересылать кадр заново основываясь на настройках.

Если на рабочей частоте есть помехи, то либо до клиента не дойдет фрейм либо от клиента не дойдёт ACK.

И еще раз, основная мысль в том, что CCQ рассчитывается исходя из согласованного индекса модуляции, а не из лучшей скорости на данном стандарте, если клиент и точка доступа согласуют 1Mbps то из такого канала и будет рассчитано значение CCQ.

А теперь представим себе, что CCQ у вас равен 50%, а это значит что примерно каждый фрейм отправляется повторно, что конечно сказывается на занятости частоты и уменьшения пропускной способности и для других клиентов, на той же частоте.

Не берите значения которые я приводил как единственно истинные, например у тех же стандартов 802.11b и 802.11n размер заголовка разный.

Здесь были приведен сам принцип работы и расчёта, но не более того.

Рассказать друзьям