канала, отслеживая вектор распределения сети (Network Allocation Vector, NAV). Каждый фрейм содержит поле NAV, которое сообщает, как долго будет передаваться последовательность, в которую он входит. Станции, услышавшие этот фрейм, понимают, что канал будет занят в течение указанного в NAV периода, даже если физический сигнал в канале отсутствует. Например, NAV для фреймов данных включает также время, необходимое для отправки подтверждения. Все станции, фиксирующие этот фрейм, воздерживаются от передачи в течение периода отправки подтверждения, слышали они его или нет. По сути, поле NAV служит для отсчета времени ожидания, когда отправитель предполагает, что канал занят. В стандарте 802.11 интервал поля NAV отсчитывается в микросекундах. В ситуациях, когда в эфире множество беспроводных устройств, поле NAV, установленное одним отправителем, может сбрасываться другими передающими в том же диапазоне станциями. Это порождает коллизии и снижает производительность. Для устранения такого эффекта в версии 802.11ax используется не одно, а два поля NAV. Первое модифицируется фреймами, которые соответствуют фреймам, привязанным к станции, второе — фреймами, которые могут улавливаться станцией, но исходят из перекрывающихся сетей.

Дополнительный механизм RTS/CTS использует NAV, чтобы запрещать станциям отправлять фреймы одновременно со скрытыми станциями (илл. 4.27). В этом примере станция A хочет передать данные станции B. Станция C находится в зоне действия А (а также, возможно, в зоне действия В, но это не имеет значения). Станция D входит в зону действия B, но не входит в зону действия А.

Илл. 4.27. Использование прослушивания виртуального канала в протоколе CSMA/CA

Протокол начинает работать тогда, когда станция А решает, что ей необходимо послать данные станции В. А посылает станции В фрейм RTS, запрашивая разрешение на передачу. Если станция В может принять данные, она отсылает обратно подтверждение о том, что канал чист, — фрейм CTS. После приема CTS станция А отправляет фрейм и запускает таймер подтверждения. В случае корректного приема В генерирует фрейм подтверждения, завершающий передачу. Если интервал таймера на станции A истекает до получения подтверждения, то считается, что произошла коллизия, и весь алгоритм работы протокола повторяется с самого начала после периода молчания.

Теперь рассмотрим этот же процесс с точки зрения станций C и D. Станция C находится в зоне действия А, поэтому она также принимает фрейм RTS и понимает, что скоро по каналу будут передаваться какие-то данные. Исходя из информации, содержащейся в RTS, С может предположить, сколько времени займет передача последовательности, включая завершающее подтверждение. Поэтому, чтобы не мешать другим, она воздерживается от передачи данных, пока обмен не будет завершен. Для этого она обновляет свою запись NAV, указывая, что канал занят, как показано на илл. 4.27. Станция D не слышит RTS, зато фиксирует CTS и также выставляет NAV. Обратите внимание: сигналы NAV не передаются, а являются лишь внутренними напоминаниями станций о том, что нужно хранить молчание в течение определенного промежутка времени.

Однако, несмотря на теоретическую привлекательность модели RTS/CTS, это один из тех методов, практическая реализация которых провалилась. Есть несколько причин, почему она используется так редко. Она не рассчитана на короткие фреймы (которые отправляются вместо RTS) и на присутствие точек доступа (которые по определению должны быть слышны всем). В других ситуациях она также замедляет работу. RTS/CTS в стандарте 802.11 немного отличается от протокола MACA, с которым мы познакомились в разделе 4.2, поскольку каждый, кто получает RTS или CTS, сохраняет молчание в течение какого-то промежутка, чтобы подтверждение (ACK) сумело пройти по каналу без коллизий. По этой причине проблема засвеченной станции не решается (как в случае MACA), устраняется только проблема скрытых станций. Чаще всего скрытых станций совсем немного, к тому же технология CSMA/CA и так помогает им. Она замедляет станции, которым по какой-либо причине не удается успешно отправить данные, чтобы повысить вероятность удачной передачи.

CSMA/CA с физическим и виртуальным прослушиванием составляет суть протокола 802.11. Однако есть несколько других механизмов, разработанных для того же стандарта. Создание каждого из них обусловлено определенными потребностями при реальной эксплуатации, так что мы кратко их рассмотрим.

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

Основная стратегия увеличения числа успешных передач заключается в снижении скорости передачи. На низких скоростях используются более надежные методы модуляции сигнала, который с большей вероятностью будет правильно получен при заданном отношении «сигнал/шум». При ощутимой потере фреймов станция понижает скорость. Если фреймы приходят с небольшой потерей, станция периодически повышает скорость, проверяя, можно ли ее использовать.

Еще один способ повысить шанс передачи неповрежденного фрейма состоит в том, чтобы посылать более короткие фреймы. Если вероятность ошибки в одном бите равна p, то вероятность того, что n-битовый фрейм будет принят корректно, равна (1 – p)n. Например, при p = 10–4 шанс корректной передачи полного фрейма Ethernet длиной 12 144 бита составляет менее 30 %. Большая часть фреймов будет потеряна. Но если их длина составит только одну треть (4048 бит), то две трети фреймов (то есть большинство) будут получены правильно, а число повторных передач снизится.

Уменьшения длины фреймов можно добиться, сократив максимальный размер сообщения, которое принимается от сетевого уровня. Кроме того, 802.11 позволяет разделять фреймы на фрагменты (fragments), каждый из которых снабжается отдельной контрольной суммой. Размер фрагмента не фиксирован, а является параметром, который может быть скорректирован точкой доступа. Фрагменты нумеруются и подтверждаются индивидуально с использованием протокола с ожиданием (то есть отправитель не может передать фрагмент с номером k + 1, пока не получит подтверждение о доставке фрагмента с номером k). Они идут один за другим с подтверждением (и возможно, с повторной отправкой) между ними, до тех пор пока весь фрейм не будет успешно передан или пока время передачи не достигнет заданного максимума. Представленный выше механизм NAV удерживает станции от передачи только до прихода первого подтверждения о доставке. Но есть и другой механизм (описанный далее), который позволяет получателю принять всю пачку фрагментов, без фреймов от других станций между ними.

Вторая потребность, которую мы обсудим, — экономия энергии. Время работы от аккумулятора для мобильных беспроводных устройств всегда представляет проблему. Стандарт 802.11 решает вопрос управления электропитанием, чтобы клиенты не тратили энергию впустую в отсутствие передачи или приема информации.

Экономия энергии обеспечивается главным образом за счет использования фреймов-маяков (beacon frames). Это периодические широковещательные сообщения, отправляемые