Такой режим называется распределенной координацией (Distributed Coordination Function, DCF). Все станции действуют независимо, нет централизованного контроля. Стандарт также включает необязательный режим сосредоточенной координации (Point Coordination Function, PCF), при котором все процессы в ячейке контролирует точка доступа — как базовая станция сотовой сети. Однако на практике PCF не применяется, так как невозможно запретить станциям из соседней сети передавать конкурирующий трафик.
Вторая проблема заключается в том, что области передачи разных станций могут не совпадать. В проводной сети система спроектирована таким образом, чтобы все станции могли слышать друг друга. Особенности передачи радиосигналов не позволяют обеспечить такое постоянство для беспроводных станций. Следовательно, может возникнуть упомянутая ранее проблема скрытой станции (илл. 4.26 (а). Поскольку не все станции слышат друг друга, передача в одной части ячейки может быть не воспринята станцией, находящейся в другой ее части. В приведенном на рисунке примере станция С передает данные станции В. Если станция А прослушает канал, она не обнаружит ничего подозрительного и сделает ложный вывод о том, что она имеет право начать передачу станции В. Это решение приведет к коллизии.
Илл. 4.26. Проблема (а) cкрытой станции; (б) засвеченной станции
Кроме того, есть и обратная проблема, показанная на илл. 4.26 (б). Станция В хочет отправить данные для станции С и прослушивает канал. Услышав, что в нем уже осуществляется какая-то передача, В делает ложный вывод, что отправка для С сейчас невозможна. Между тем станция А — источник сигнала, который смутил станцию В, — на самом деле отправляет данные станции D (на рисунке ее нет). Таким образом, теряется возможность передать информацию.
Чтобы решить проблему очередности передачи данных станциями, в стандарте 802.11 прослушивание канала происходит и на физическом, и на виртуальном уровне. При физическом прослушивании среда просто проверяется на наличие сигнала. Виртуальное прослушивание заключается в том, что станции ведут логический журнал использования канала, отслеживая вектор распределения сети (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). Это периодические широковещательные сообщения, отправляемые точкой доступа (AP), например, каждые 100 мс. Фреймы сообщают клиентам о присутствии AP и содержат системные параметры: идентификатор AP, время, интервал до следующего маяка и настройки безопасности.
Клиенты могут вставить бит управления электропитанием во фреймы, с помощью которых они сообщают точке доступа о переходе в энергосберегающий режим (power-save mode). В этом режиме клиент может «дремать», а AP будет буферизовать предназначенный для него трафик. Чтобы проверить наличие входящего трафика, клиент «просыпается» при каждом приходе маяка и проверяет содержащуюся в нем карту трафика. Эта карта говорит клиенту о наличии буферизованного трафика. Если он есть, клиент посылает сообщение опроса в точку доступа и она передает буферизованный трафик. Затем клиент может вернуться в спящий режим до следующего маяка.