Зачем ждать время SIFS перед отправкой ACK? - PullRequest
16 голосов
/ 08 января 2010

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

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

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

Ответы [ 6 ]

11 голосов
/ 09 января 2010

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

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

3 голосов
/ 09 января 2010

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

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

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

Обновление:

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

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

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

1 голос
/ 02 июля 2014

SIFS = RTT (в зависимости от скорости передачи PHY) + ЗАДЕРЖКА ОБРАБОТКИ КАДРОВ ПРИ ПРИЕМНИКЕ (ЗАДЕРЖКА ОБРАБОТКИ ФИЗИКА + ЗАДЕРЖКА ОБРАБОТКИ МАС) + ЗАДЕРЖКА ОБРАБОТКИ КАДРОВ (ДЛЯ НАСТРОЙКИ ОТВЕТА CTS / ACK) + ЗАДЕРЖКА ТЮНЕРА ВЧ )

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

0 голосов
/ 27 февраля 2013

SIFS = D + М + Rx / Tx

Где,

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

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

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

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

0 голосов
/ 26 июня 2010

Быстрый ускоренный курс по 802.11:

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

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

0 голосов
/ 09 января 2010

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

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

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

».

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

...