Зачем ждать время SIFS перед отправкой ACK?

Вопрос о MAC-протоколе 802.11 Wifi.

Мы узнали, что, когда станция получила данные, она ожидает время SIFS. Затем он отправляет пакет. При поиске в Интернете причина, о которой всегда упоминается, заключается в том, чтобы предоставить ACK-пакетам более высокий приоритет. Это понятно, поскольку станция сначала должна ждать DIFS-времени, когда она хочет отправить нормальные данные (а DIFS больше, чем SIFS).

Но зачем же ждать? Почему бы не сразу отправить ACK? Станция знает, что данные пришли, и CRC правильный, поэтому зачем ждать?

Ответы

Ответ 1

Теоретически возможно знать, что CRC корректен в точном конце полученных данных из провода, но на практике вам нужно аккумулировать все образцы в последнем блоке, чтобы запускать IFFT, деконволюцию, FEC, а затем, наконец, в самом конце, после того, как, наконец, получив входные данные из формы сигнала, вы знаете, что CRC правильный. Кроме того, вам иногда необходимо включить схему передачи для отправки ACK, что может затруднить производительность приема. Если каждый шаг в цепочке обработки был мгновенным, и если схема передачи определенно не мешала приемной схеме, и если не было времени, необходимого для построения формы сигнала для ACK, можно было бы отправить ACK сразу после получения последнего бита волновой формы. Но, хотя каждый элемент в этой цепочке занимает некоторое детерминированное время, это не мгновенно. SIFS дает время приемника для получения данных из PHY, проверки и отправки ответа.

Отказ от ответственности: я больше знаком с Homeplug, чем с 802.11.

Ответ 2

Это похоже на то, что режим распределенной координации (DCF) и функция координаты точки (PCF) может сосуществовать внутри одной ячейки. Это базовая станция может использовать опрос, в то время как ячейка может использовать разделенную координацию с использованием CSMA/CA.

Таким образом, во время SIFS могут быть отправлены управляющие кадры или следующий фрагмент. Во время PIFS могут быть отправлены кадры PCF, и во время DIFS могут быть отправлены кадры DCF. Во время SIFS и PIFS PCF может справиться со своей магией.

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

Update:

Теперь я понимаю, что во время SIFS станция может отправлять RTS, CTS или ACK и иметь достаточно времени для переключения обратно в режим приема до того, как отправитель начнет передавать. Если это правильно, он отправит ACK во время SIFS. Затем он изменится на режим приема и дождитесь окончания SIFS. По истечении SIFS передатчик начнет отправку.

Кроме того, PCF контролируется PIFS, который приходит после SIFS и перед DIFS и поэтому не имеет отношения к этому обсуждению (моя ошибка). То есть SIFS < PIFS < DIFS < УМКИ.

Источники: Этот PDF (стр. 8) и Компьютерные сети Эндрю С. Таненбаум

Ответ 3

SIFS = RTT (на основе скорости передачи PHY) + ЗАДЕРЖКА ОБРАБОТКИ РАМЫ НА ПРИЕМНИКЕ (ЗАДЕРЖКА ОБРАБОТКИ PHY + ЗАДЕРЖКА ОБРАБОТКИ МАСШТАБА) + ЗАДЕРЖКА ОБРАБОТКИ РАМЫ (ДЛЯ СОЗДАНИЯ РЕАГИРОВАНИЯ CTS/ACK) + ЗАДЕРЖКА ТЮНЕРА RF (ИЗМЕНЕНИЕ ОТ RX-TX )

A Сторона передатчика, после последнего символа PHY (например, RTS), время, необходимое для перехода в режим RX (на радиочастоте). Таким образом, я бы увидел SIFS как вычисление стороны RX, чем сторона TX.

Ответ 4

Я не могу сказать точно, но это похоже на стратегию оптимизации, подобную IP. Если для каждого пакета данных не требуется ACK, имеет смысл немного удержаться, чтобы, если поступает больше пакетов данных, вы можете подтвердить их все одним ACK.

Пример: клиент отправляет 400 пакетов по-настоящему быстро на сервер. Вместо того, чтобы сервер отправляет 400 ACK, он может просто подождать, пока клиент не передохнет, прежде чем отправить один ACK обратно. В сочетании с вероятностью, что клиент возьмет передышку даже при большой нагрузке (он должен быть заполнен буфером неподтвержденных пакетов), это будет работоспособным.

Это возможно в системах, где ACK(n) означает "Я получил все до и включая пакет # n.

При использовании такой стратегии вы получите лучшую производительность и меньше трафика. До тех пор, пока время ожидания ожидания перед отправкой на ресивере меньше, чем время повторной передачи-если-no-ack-before в отправителе (принимая во внимание задержки передачи), не должно быть никаких проблем.

Ответ 5

Быстрый краш-курс по 802.11:

802.11 - это, по сути, гигантская система таймеров. В наиболее распространенных реализациях 802.11 используется распределенная координационная функция DCF. DCF позволяет узлам входить и выходить из диапазона радиоканала, используемого для 802.11, и координировать распределенным образом, кто должен отправлять и получать данные (игнорируя скрытые и подверженные риску проблемы node для этого обсуждения). Прежде чем какой-либо node сможет начать отправку данных по каналу, все они должны ждать период DIFS, в котором определено, что канал неактивен, если он неактивен в течение периода DIFS, первый node для захвата канала начинает передачу, В стандарте 802.11, то есть не-802.11e-реализации и не 802.11n, каждый отдельный пакет данных, который передается, должен быть подтвержден физическим уровнем, PHY, пакетом подтверждения, независимо от используемого протокола верхнего уровня. После отправки пакета данных время SIFS истекает, после истечения SIFS управляющие кадры, предназначенные для node, которые имеют "взятый" контроль канала, могут быть отправлены, в этом случае и кадр подтверждения передается. SIFS позволяет node отправить пакет данных для переключения из режима передачи в приемный. Если пакет потерян и ACK не получен после истечения времени ожидания SIFS/ACK, вызывается экспоненциальное отключение. Экспоненциальное back-off, a.k.a конкурирующее окно (CW) начинается со значения CWmin, в некоторых реализациях linux это 15 временных интервалов времени, когда время слота изменяется в зависимости от используемого протокола 802.11. Значение CW затем выбирается из 1 в любой верхний предел, который был рассчитан для CW. Если текущий пакет был потерян, тогда CW увеличивается с 15 до 30, а затем случайное значение выбирается между 1 и 30. Каждый раз подряд происходит потеря CW удваивается до 1023, после чего он попадает в предел. Как только пакет будет принят успешно, CW будет reset обратно в CWmin.

Что касается 802.11n/802.11e: Каждый пакет данных по-прежнему должен быть подтвержден, но при использовании 802.11e (реализовано в 802.11n) несколько пакетов данных могут быть объединены двумя разными способами: A-MSDU или A-MPDU. A-MSDU - это jumbo-frame, который имеет одну контрольную сумму для всего отправленного агрегированного пакета, внутри него много подкадров, которые содержат каждый из кадров данных, которые необходимо отправить. Если в кадре A-MSDU есть какая-либо ошибка, и ее необходимо повторно передать, то каждый подкадр должен быть повторно отправлен. Однако при использовании A-MPDU каждый подкадр имеет небольшой заголовок и контрольную сумму, которые позволяют любому подкадре, который имеет ошибку в нем, быть повторно переданным самим/в другом агрегированном фрейме, в следующий раз, когда отправляющие узлы получат канал, С помощью этих агрегированных схем отправки пакетов существует понятие block-ack. Блок файл содержит растровое изображение кадров из начального порядкового номера, которые были просто отправлены в агрегированном пакете и получены правильно или неправильно. Использование агрегированной отправки фреймов значительно улучшает производительность пропускной способности, так как больше данных может быть отправлено на получение канала с помощью отправки node, что также позволяет отправлять пакеты не по порядку. Однако отправка пакетов по заказу значительно усложняет уровень MAC-адресов 802.11.

Ответ 6

SIFS = D + М + Rx/Tx

Где

D = (Задержка приема (RF delay) и декодирование преамбулы/заголовка процедуры конвергенции физического уровня (PLCP))

M = (Задержка обработки MAC)

Rx/Tx = (время обработки приемопередатчика)

Прежде всего, задержек нельзя избежать, поэтому ему нужно подождать время SIFS перед отправкой подтверждения