Почему ожидают время SIFS перед передающим ACK?
Вопрос о протоколе MAC 802.11 Wi-Fi.
Мы узнали, что, когда станция получила данные, это ожидает в течение времени SIFS. Тогда это отправляет пакет. Когда поиск онлайн причины, которая всегда упоминается, должен отдать пакетам ACK более высокий приоритет. Это понятно, так как станция сначала должна ожидать время DIFS, когда она хочет отправить нормальные данные (и DIFS больше, чем SIFS).
Но почему ожидают вообще? Почему не сразу отправляют ACK? Станция знает, что данные прибыли, и CRC корректен, итак, почему ожидают?
4 ответа
] Теоретически можно знать, что КСГ верна на точном конце полученных от провода данных, но на практике необходимо собрать все образцы в последнем блоке, чтобы запустить IFFT, деконволюцию, FEC, и затем, наконец, в самом конце, после того как окончательно получены входные данные из формы волны, знаете ли вы, что CRC правильная. Кроме того, иногда вам нужно включить схему передачи, чтобы послать ACK, что может помешать приему. Если бы каждый шаг в цепочке обработки был мгновенным, и если бы схема передачи определенно не мешала схеме приема, и если бы не было времени вывода, необходимого для построения формы волны для ACK, то можно было бы послать ACK сразу после получения последнего бита формы волны. Но, хотя каждый элемент в этой цепочке занимает некоторое детерминированное время, это не мгновенно. SIFS дает приемнику время для получения данных от PHY, проверки и отправки ответа.[
] []Отказ от ответственности: Я больше знаком с Homeplug, чем с 802.11.[
].Я не могу сказать наверняка, но это похоже на стратегию оптимизации, похожую на IP. Если вам не требуется ACK для каждого пакета данных , имеет смысл немного подождать, чтобы в случае поступления дополнительных пакетов данных вы могли подтвердить их все с помощью одного ACK.
Пример: клиент действительно быстро отправляет 400 пакетов серверу. Вместо того, чтобы сервер отправлял обратно 400 ACK, он может просто дождаться, пока клиент выполнит передышку, прежде чем отправлять обратно один ACK. В сочетании с вероятностью того, что клиент возьмет передышку даже при большой нагрузке (он должен это сделать, поскольку его буфер неподтвержденных пакетов заполнится), это было бы работоспособным.
Это возможно в системах, где ACK (n) означает «Я получил все до пакета № n включительно.
Вы получите лучшую производительность и меньше трафика за счет использования такой стратегии. Пока время ожидания перед отправкой подтверждения на получателе меньше, чем время повторной передачи, если нет подтверждения на отправителе (с учетом задержек передачи), существует не должно быть проблем.
Таким образом, поскольку функция распределенной координации (DCF) и точечная функция координации (PCF) может сосуществовать в пределах одной ячейки. Это базовая станция может использовать опрос, в то же время ячейка может использовать дизитрибированную координацию с помощью CSMA / CA.
Таким образом, во время SIFS могут быть отправлены контрольные рамки или следующий фрагмент. Во время PIFS-кадров PCF могут быть отправлены и во время рамок DIFS могут быть отправлены. Во время SIFS и PIFS PCF может работать его магию.
Несмотря на то, что не все базовые станции поддерживают PCF, все станции должны ждать, так как некоторые могут его поддерживать.
Обновление:
Как я понимаю, теперь, когда во время SIFS станция может отправлять RTS, CTS или ACK и иметь достаточно времени, чтобы вернуться к режиму получения, прежде чем отправитель начнет передавать. Если это правильно, он отправит ACK во время SIFS. Затем он изменится для приема режима и дождаться до истечения SIFS. Когда SIFS провел передатчик, начнет отправлять.
Кроме того, PCF управляется PIFS, которые наступают после SIFS и до DIFS, и это не имеет отношения к этой дискуссии (моя ошибка). То есть SIFS Источники: Это PDF (стр. 8) и Компьютерные сети Andrew S. Tanenbaum
Быстрый курс по 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, то вызывается экспоненциальный откат. Экспоненциальный откат, также известный как окно конкуренции (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-кадр, который имеет одну контрольную сумму для всего отправляемого агрегированного пакета, в нем есть множество подкадров, содержащих каждый из кадров данных, которые необходимо отправить. Если есть какая-либо ошибка в кадре A-MSDU и его необходимо повторно передать, то необходимо повторно отправить каждый подкадр. Однако при использовании A-MPDU каждый подкадр имеет небольшой заголовок и контрольную сумму, которые позволяют повторно передать любой подкадр, в котором есть ошибка, сам / в другом агрегированном кадре в следующий раз, когда отправляющие узлы получат канал. . В этих схемах отправки агрегированных пакетов есть понятие блочного подтверждения. Блок-подтверждение содержит битовую карту кадров с начальным порядковым номером, которые были только что отправлены в агрегированном пакете и приняты правильно или неправильно. Использование агрегированной отправки кадров значительно повышает производительность, поскольку отправляющий узел может отправлять больше данных за каждый канал, что также позволяет отправлять пакеты вне очереди.Однако отправка пакетов вне очереди значительно усложняет уровень MAC 802.11.