2010-01-08 2 views
15

Вопрос о MAC-протоколе 802.11 Wi-Fi.Зачем ждать SIFS перед отправкой ACK?

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

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

ответ

11

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

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

+0

Это, по-видимому, подтверждается ссылкой, которую я нашел: http://protocols.netlab.uky.edu/~calvert/classes/571/lectureslides/WiFi.pdf В заявлении, что «SIFS = время, необходимое для восприятия станции конец кадра и начало передачи ». – Omega

+0

SIFS должен предоставить разработчикам аппаратного обеспечения ограничение времени, затрачиваемого на декодирование и проверку кадра. Это необходимо, потому что 802.11 первоначально был строго в порядке доставки, поэтому отправитель не может перейти к следующему пакету, пока он не будет иметь ACK для текущего или отказался. Чтобы получить разумную производительность, приемник должен иметь максимальное время оборота в ACK. –

0

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

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

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

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

+0

У меня создалось впечатление, что шум является серьезной проблемой, и эти кадры чаще всего разделяются на более мелкие фрагменты, которые отправляются в режиме всплеска. Для каждого фрагмента приемник будет отправлять ACK для подтверждения, чтобы только плохие фрагменты были повторно переданы. –

+0

Вот как работает ACK 802.11, но исходная спецификация имеет SIFS и не имеет блока ACK. Кроме того, до добавления MPDU, 802.11 был строго в порядке доставки. –

3

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

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

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

Update:

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

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

Источники: This PDF (page 8) и Computer Networks by Andrew S. Tanenbaum

+0

В обоих режимах (DCF и PCF) во время SIFS ничего не отправляется. Каждый протокол всегда ожидает времени SIFS перед отправкой фрагмента. Так что это не объясняет, почему он (читай: DCF и PCF) не отправил ACK сразу после получения данных. – Omega

+0

@ Omega: Thing, базовая станция должна поддерживать DCF, но может опционально поддерживать PCF. Другие станции должны поддерживать DCF и поддерживать PCF. Если они не поддерживают PCF, им все равно придется ждать, так как другие могут ее поддержать. –

0

Быстрый краш-курс на 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, вызывается экспоненциальное отключение. Экспоненциальное back-off, 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 - это jumbo-frame, который имеет одну контрольную сумму для всего отправленного агрегированного пакета, внутри него много подкадров, которые содержат каждый из кадров данных, которые необходимо отправить. Если в кадре A-MSDU есть какая-либо ошибка, и ее необходимо повторно передать, то каждый подкадр должен быть повторно отправлен. Однако при использовании A-MPDU каждый подкадр имеет небольшой заголовок и контрольную сумму, которые позволяют любому подкадре, который имеет ошибку в нем, быть повторно переданным самим/в другом агрегированном фрейме, в следующий раз, когда отправляющие узлы получат канал , С помощью этих агрегированных схем отправки пакетов существует понятие block-ack. Блок-файл содержит растровое изображение кадров из начального порядкового номера, которые были просто отправлены в агрегированном пакете и получены правильно или неправильно. Использование агрегатной отправки кадров значительно повышает пропускную способность, так как большее количество данных может быть отправлено на каждый канал с помощью отправляющего узла, что также позволяет отправлять пакеты не по порядку. Однако отправка пакетов по заказу значительно усложняет уровень MAC-адресов 802.11.

0

SIFS = D + М + Rx/Tx

Где,

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

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

Rx/Tx = (приемо межремонтный)

Выше всех задержек не может быть предотвращено, так Он должен ждать КМКИ время перед отправкой подтверждения

1

SIFS = RTT (основано на скорости передачи PHY) + КАДР задержки обработки в приемнике (PHY задержки обработки + MAC-ОБРАБОТКА ЗАДЕРЖКИ) + Оправа задержки обработки (для составления RESPONSE CTS/ACK) + RF тюнер задержки (изменение от RX к TX)

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

Смежные вопросы