Устройство передачи и способ передачи

Изобретение относится к средствам передачи. Технический результат - повышение эффективности многопользовательского обмена кадрами управления. Принимают кадр запуска для распределения ресурсов для многопользовательской передачи восходящей линии связи (UL MU), причем кадр запуска содержит поле общей информации, которое включает в себя подполе типа, указывающее один из множества типов запуска, причем множество типов запуска включает в себя первый тип запуска, указывающий базовый запуск, используемый для запрашивания множества типов кадра ответа, и второй тип запуска, указывающий конкретный запуск, используемый для запрашивания конкретного типа кадра ответа UL MU. Передают конкретный тип кадра ответа UL MU в ответ на кадр запуска, когда подполе типа указывает второй тип запуска. Причем, когда подполе типа указывает второй тип запуска, кадр запуска содержит подполе типа обратной связи, включающее в себя тип обратной связи, который запрашивается для устройства связи. 2 н. и 6 з.п. ф-лы, 35 ил.

 

ОБЛАСТЬ ТЕХНИКИ

[0001] Настоящее изобретение в общем относится к устройству передачи и способу передачи для обмена кадрами многопользовательского управления.

Предшествующий уровень техники

[0002] Рабочая группа IEEE (Институт инженеров по электротехнике и электронике) 802.11 в настоящее время находится в процессе стандартизации технологии следующего поколения WLAN (беспроводной локальной сети) в рамках целевой группы 802.11ax. Основной задачей этой целевой группы является повышение эффективности использования спектра для повышения пропускной способности системы/области в сценариях с высокой плотностью точек доступа (AP) и/или терминальных станций (ʺне-AP STAʺ или просто STA в остальной части документа). Устройство, основанное на спецификации IEEE 802.11ax, обычно называется устройством высокой эффективности (HE). Среди предложенных различных технологий, множественный доступ с ортогональным частотным разделением (OFDMA) и многопользовательская передача восходящей линии связи являются двумя ключевыми технологиями, которые приняла целевая группа IEEE 802.11ax для достижения целей повышения пропускной способности. Фиг. 1 иллюстрирует пример 802.11ax WLAN сети 100 с АР 190 и несколькими STA, ассоциированными с AP 190.

[0003] Спецификация IEEE 802.11 определяет различные типы кадров, обмен которыми может производиться в беспроводной сети, основанной на стандарте IEEE 802.11. Кадры управления используются для обеспечения возможности и поддержания беспроводной связи в беспроводной сети. Эти кадры генерируются на уровне управления доступом к среде передачи (MAC) устройства IEEE 802.11 и обычно передаются с более надежной схемой модуляции и кодирования (MCS) для того, чтобы обеспечить их корректный прием. Некоторые из кадров управления широковещательно передаются точкой доступа (AP) в беспроводном базовом наборе услуг (BSS). Кадры управления широковещательной передачи включает в себя, например, кадр маяка, чтобы объявлять о наличии BSS, а также различных его свойствах, таких как беспроводной канал, на котором он действует, его идентификатор набора услуг (SSID) и т.д. STA, которая находится в пределах диапазона связи АР, может использовать информацию, полученную из кадра маяка, чтобы первоначально присоединиться к BSS, если она еще не присоединилась к BSS, или обновить свои записи BSS, если она уже присоединилась к BSS. Большинство кадров управления, однако, используются в одноадресном режиме (т.е., адресованы конкретной STA или АР).

[0004] В некоторых случаях AP может передавать кадры управления к конкретной STA, чтобы запрашивать ее выполнять определенное действие (например, кадр разъединения, чтобы запрашивать STA покинуть BSS). В большинстве случаев, правда, будет происходить обмен соответствующими кадрами управления между AP и STA. В качестве примера, кадр запроса ассоциации передается от АР к STA, и STA передает кадр ответа ассоциации обратно к АР, чтобы присоединиться к BSS. В качестве другого примера, передается запрос квитирования добавления блока (ADDBA) от АР к STA, и STA передает кадр ответа ADDBA обратно к АР, чтобы настроить использование механизма квитирования блока (Block Ack) между двумя устройствами.

Список цитированных документов

Непатентные документы

[0005] [NPL 1] IEEE 802.11-15/0132r17, Specification Framework for TGax, May 2015

[NPL 2] IEEE 802.11-16/0024r1, Proposed TGax draft specification

[NPL 3] Standard IEEE 802.11-2012

КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

[0006] Хотя многопользовательская передача возможна в нисходящей линии связи с использованием многопользовательской связи со множеством входов/множеством выходов (MU-MIMO), и множественный доступ с ортогональным частотным разделением (OFDMA) может быть использован как в нисходящей линии связи (DL), так и в восходящей линии связи (UL), трудно выполнять обмен кадрами управления в многопользовательской передаче эффективным образом.

[0007] Таким образом, не ограничивающий примерный вариант осуществления настоящего изобретения обеспечивает устройство передачи, содержащее: передатчик, который, при работе, передает кадр запуска (триггера) для распределения ресурсов для многопользовательской передачи восходящей линии связи (UL MU), причем кадр запуска содержит поле общей информации, которое включает в себя подполе типа, указывающее один из множества типов запуска, причем множество типов запуска включает в себя первый тип запуска, указывающий базовый запуск, используемый для запрашивания любого типа кадра ответа от терминальной станции-получателя, второй тип запуска, указывающий конкретный запуск, используемый для запрашивания конкретного типа кадра ответа UL MU от множества терминальных станций; и приемник, который, при работе, принимает конкретный тип кадра ответа UL MU от множества терминальных станций, когда подполе типа указывает второй тип запуска.

[0008] Эти общие и конкретные аспекты могут быть реализованы с использованием устройства, системы, способа и компьютерной программы и любой комбинации устройств, систем, способов и компьютерных программ.

[0009] Способы, описанные в настоящем изобретении, обеспечивают возможность многопользовательского обмена кадрами управления эффективным образом.

[0010] Дополнительные выгоды и преимущества раскрытых вариантов осуществления будут понятны из описания и чертежей. Выгоды и/или преимущества могут быть получены отдельно различными вариантами осуществления и признаками, представленными в спецификации и на чертежах, которые не требуется все предусматривать для того, чтобы получить одно или более из таких выгод и/или преимуществ.

Краткое описание чертежей

[0011] [Фиг. 1] Фиг. 1 является схематичным представлением конкретного варианта осуществления системы, которая использует многопользовательский обмен кадрами управления.

[Фиг. 2] Фиг. 2 является диаграммой примерной последовательности обмена кадрами, использующей установку и отмену механизма Block Ack.

[Фиг. 3] Фиг. 3 является диаграммой примерных последовательностей обмена кадрами для установки Block Ack между АР и несколькими STA.

[Фиг. 4A] Фиг. 4А иллюстрирует структуру элементов, используемую для переноса поля ʺТF Timeoutʺ (ТF Таймаут), используемого в первом варианте осуществления.

[Фиг. 4B] Фиг. 4В иллюстрирует таблицу, показывающую значение поля ʺТF Timeoutʺ в первом варианте осуществления.

[Фиг. 5] Фиг. 5 является диаграммой примерного многопользовательского обмена кадрами управления в соответствии с настоящим раскрытием, инициированного посредством AP.

[Фиг. 6] Фиг. 6 является диаграммой другого примерного многопользовательского обмена кадрами управления в соответствии с настоящим раскрытием, инициированного посредством AP.

[Фиг. 7] Фиг. 7 является диаграммой другого примерного многопользовательского обмена кадрами управления в соответствии с настоящим раскрытием, инициированного посредством STA.

[Фиг. 8] Фиг. 8 является диаграммой еще одного примерного многопользовательского обмена кадрами управления в соответствии с настоящим раскрытием, инициированного посредством STA.

[Фиг. 9A] Фиг. 9А иллюстрирует структуру кадра запуска в соответствии с первым вариантом осуществления.

[Фиг. 9В] Фиг. 9В иллюстрируют структуру поля Общая Информация (Common Info) в соответствии с первым вариантом осуществления.

[Фиг. 9C] Фиг. 9C иллюстрирует структуру поля Зависимая от типа Общая Информация в соответствии с первым вариантом осуществления.

[Фиг. 9D] Фиг. 9D иллюстрирует таблицу, показывающую описания нескольких типов кадров в соответствии с первым вариантом осуществления.

[Фиг. 9E] Фиг. 9E иллюстрирует структуру подполя Специфика Подтипа в соответствии с первым вариантом осуществления.

[Фиг. 9F] Фиг. 9F иллюстрирует таблицу, показывающую описание подполя Категория Действия в соответствии с первым вариантом осуществления.

[Фиг. 9G] Фиг. 9G иллюстрирует таблицу, показывающую описание подполя Поле Действия в соответствии с первым вариантом осуществления.

[Фиг. 10A] Фиг. 10A иллюстрирует структуру подполя Агрегированное Управление НЕ-Варианта (A-управление), используемого для переноса поля ʺТF Timeoutʺ, используемого во втором варианте осуществления.

[Фиг. 10B] Фиг. 10B иллюстрирует формат подполя управления в соответствии со вторым вариантом осуществления.

[Фиг. 10C] Фиг. 10C иллюстрирует таблицу, показывающую описание значений подполя ID Управления в соответствии со вторым вариантом осуществления.

[Фиг. 11A] Фиг. 11А иллюстрирует таблицу, показывающую описание различных типов запуска в соответствии со вторым вариантом осуществления.

[Фиг. 11B] Фиг. 11B иллюстрирует формат подполя Тип Предпочтительного Ответа в соответствии со вторым вариантом осуществления.

[Фиг. 11C] Фиг. 11С иллюстрирует таблицу, показывающую описание Подтипа Кадра в соответствии со вторым вариантом осуществления.

[Фиг. 11D] Фиг. 11D иллюстрирует таблицу, показывающую описание различных значений Поля Действия в соответствии со вторым вариантом осуществления.

[Фиг. 11E] Фиг. 11E иллюстрирует формат поля Пользовательская Информация (User Info) в соответствии со вторым вариантом осуществления.

[Фиг. 12A] Фиг. 12A иллюстрирует формат поля элемента ADDBA Расширение (ADDBA Extension) в соответствии с третьим вариантом осуществления.

[Фиг. 12B] Фиг. 12В иллюстрирует формат поля ADDBA Возможности (ADDBA Capabilities) в соответствии с третьим вариантом осуществления.

[Фиг. 12C] Фиг. 12С иллюстрирует таблицу, показывающую описание различных значений ТF Timeout в соответствии с третьим вариантом осуществления.

[Фиг. 13A] Фиг. 13А иллюстрирует структуру подполя Тип Предпочтительного Ответа в соответствии с третьим вариантом осуществления.

[Фиг. 13B] Фиг. 13В иллюстрирует таблицу, показывающую описание различных значений Типа Кадра в соответствии с третьим вариантом осуществления.

[Фиг. 14] Фиг. 14 является диаграммой структуры подполя Управление Планированием ответа UL MU, используемого для переноса TF таймаута, как используется в четвертом варианте осуществления.

[Фиг. 15] Фиг. 15 является диаграммой примерного многопользовательского обмена кадрами управления, инициированного посредством AP, в соответствии с четвертым вариантом осуществления.

[Фиг. 16] Фиг. 16 является блок-схемой последовательности операций, выполняемых посредством AP для того, чтобы инициировать многопользовательский обмен кадрами управления в соответствии с настоящим изобретением.

[Фиг. 17] Фиг. 17 является блок-схемой последовательности операций, выполняемых посредством STA для того, чтобы участвовать в многопользовательском обмене кадрами управления, инициированном посредством AP, в соответствии с настоящим изобретением.

[Фиг. 18] Фиг. 18 является блок-схемой примерной AP.

[Фиг. 19] Фиг. 19 является блок-схемой примерной STA.

Описание вариантов осуществления

[0012] Настоящее изобретение может быть лучше понято с помощью следующих фигур и вариантов осуществления. Варианты осуществления, описанные здесь, являются только иллюстративными по своей сущности и могут быть использованы для описания некоторых из возможных приложений и использований настоящего изобретения и не должны рассматриваться как ограничивающие настоящее изобретение в отношении альтернативных вариантов осуществления, которые явно не описаны в данном документе.

[0013] На фиг. 2 показана примерная последовательность 200 обмена кадрами между двумя 802.11 устройствами, которая включает в себя обмен кадрами управления с целью согласования параметров Block Ack. В инфраструктурном BSS, одно из устройств стандарта 802.11 будет представлять собой AP, а другое будет представлять собой STA. Последовательность 200 состоит из трех отдельных фаз: (а) фаза 210 установки Block Ack, (b) одна или более фаз 220 обмена данными и (с) фаза 230 отмены Block Ack. Block Ack является функцией, которая была введена в поправке IEEE 802.11e и позволяет 802.11 устройствам передавать пакеты кадров к другому 802.11 устройству, не требуя от приемника немедленно отправлять кадры Ack для каждого принятого кадра.

[0014] 802.11 устройство, которое инициирует пакетную передачу, известно как инициатор, в то время как получающее 802.11 устройство известно как получатель. После окончания пакета, инициатор может запросить от получателя передать Block Ack, которое содержит битовую карту принятых кадров, посредством передачи кадра запроса Block Ack. Этот обмен показан в фазе 220 на фиг. 2. Поправка IEEE 802.11n дополнительно усовершенствовала эту функцию, позволяя агрегировать пакет данных в один протокольный блок данных управления (Management Protocol Data Unit, MPDU), называемый А-MPDU. Хотя Block Ack является полезной функцией, как инициатор, так и получатель должны подготовить дополнительные ресурсы, прежде чем эта функция может быть использована. Получателю не только необходимо выделить дополнительные буферы для приема пакетов кадров, но он также должен поддерживать таблицу оценок, чтобы записывать состояние приема кадров. Подобным образом, инициатору также необходимо поддерживать запись переданных кадров. Эта подготовка выполняется в фазе 210 установки Block Ack. В этой фазе, два 802.11 устройства могут согласовывать размер буфера, идентификатор трафика (TID) задействованных кадров и длительность, в течение которой согласование будет действовать и т.д. После завершения фазы обмена данными, любая сторона может отменить согласование Block Ack в фазе 230 отмены.

[0015] Как объяснялось ранее, большинство обменов кадрами управления происходят между двумя 802.11 устройствами, обычно между AP и STA. В качестве примера, обмен кадрами управления, применяемый в фазе 210 установки Block Ack, изображен более подробно на фиг. 3. В этом примере, АР является инициатором, и STA являются получателями. Прежде чем AP получит возможность использовать функцию Block Ack, она должна установить функцию Block Ack с каждой STA, с которой она намеревается использовать функцию Block Ack, по одной STA в каждый данный момент времени. Последовательности 300, 310 и 320 обменов кадрами инициируются посредством AP, чтобы установить функцию Block Ack с STA1, STA2 и STAn, соответственно. Каждая из них задействует обмен кадрами управления действием ADDBA Block Ack между АР и соответствующей STA. Например, в последовательности 300, АР инициирует обмен путем конкуренции за беспроводную среду; эта попытка конкуренции представлена ссылочной позицией 302 на чертежах в данном раскрытии.

[0016] После того, как AP выигрывает право в конкуренции, она передает кадр 304 запроса ADDBA, уникально адресованный к STA1. После приема кадра 304 запроса ADDBA, STA1 передает обратно кадр 306 Ack к АР спустя длительность короткого межкадрового промежутка (SIFS) после конца кадра запроса ADDBA. Передача кадров Ack не требует конкуренции за беспроводную среду. После того, как STA обработала кадр запроса ADDBA, и если она принимает запрос, STA отправляет обратно кадр 308 ответа ADDBA после конкуренции за беспроводную среду и выигрыша в ней. АР подтверждает прием кадра ADDBA посредством передачи кадра Ack. Подобный обмен кадрами требуется также и в обратном направлении, то есть по инициативе STA, если STA намеревается использовать функцию Block Ack. Очевидно, что если имеется много задействованных STA, этот процесс установки займет много времени.

[0017] Хотя многопользовательская передача возможна в нисходящей линии связи (DL) с использованием многопользовательской связи со множеством входов/множеством выходов (MU-MIMO) и как в DL, так и в восходящей линии связи (UL) с использованием множественного доступа с ортогональным частотным разделением (OFDMA), когда речь идет об обмене кадрами управления, имеется еще несколько проблем, которые препятствуют эффективной многопользовательской связи, особенно в направлении UL. Эти вопросы можно свести к следующим двум проблемам: 1) большинство кадров управления передаются с использованием наивысшей Категории Доступа (Access Category, АС) Расширенного Распределенного Доступа к Каналу (Enhanced Distributed Channel Access, EDCA) AC_VO. Если АР передает несколько кадров управления к нескольким STA в многопользовательском PHY Протокольном Блоке Данных (Protocol Data Unit, PPDU) DL, то STA, которые успешно приняли эти кадры, будут пытаться отправить обратно соответствующие кадры управления ответом к AP, как только STA готовы сделать это. В то же время, для того, чтобы запрашивать множество кадров управления ответом от этих STA в многопользовательском режиме, АР будет пытаться передать базовый вариант заново определенного кадра управления, называемого кадром запуска.

[0018] Базовый кадр запуска содержит такую информацию, как распределение единицы ресурса (RU), длина PPDU, MCS и т.д., которые должны использоваться для передачи UL. После приема кадра запуска, STA, которым распределены RU в кадре запуска, могут отправлять обратно соответствующие кадры UL в многопользовательском PPDU UL. Это приводит к тому, что кадры управления ответом станций STA конкурируют за беспроводную среду между собой, а также с кадром запуска АР. В случае, если кадр запуска не может выиграть доступ к среде или его передача задерживается, STA не сможет использовать многопользовательскую передачу для своих кадров UL. 2) Базовый вариант кадра запуска не определяет тип кадра, который STA может отправить обратно в многопользовательском PPDU UL. Это может привести к тому, что некоторые STA отправляют обратно кадры, иные чем кадр управления ответом, приводя к ситуации, когда АР необходимо отправить один или более кадров запуска к этим STA. Оба эти фактора не только обуславливают неэффективность, но и, вследствие задержки в получении обратно кадров ответа, некоторые из кадров запроса может также потребоваться повторно сформировать в связи с проблемами таймаута.

[0019] Хотя методы, описанные в настоящем раскрытии, могут применяться ко многим системам беспроводной связи, для примера, остальная часть описания в данном описании, приведена в терминах системы IEEE 802.11 WLAN и ассоциированной с ней терминологии. Это не следует рассматривать как ограничение настоящего изобретения в отношении альтернативных систем беспроводной связи.

[0020] Вновь со ссылкой на фиг. 1, примерная беспроводная сеть 100 может включать в себя AP 190 и многие ассоциированные STA. STA2 120 и STA6 160 представляют собой класс устройств с высокой производительностью обработки и, возможно, высокими требованиями к QoS и относительно низкими требованиями к энергосбережению. STA1 110 и STA4 140 представляют еще один класс устройств, которые также могут иметь высокую производительность обработки и, возможно, высокие требования к QoS, но относительно с более высокими требованиями к потребляемой мощности. С другой стороны, STA3 130 и STA5 150 представляют собой еще один класс устройств, которые могут иметь низкую производительность обработки и могут быть очень чувствительными к потреблению мощности. В терминах IEEE 802.11ax, STA1 110, STA2 120, STA4 140 и STA6 160 могут рассматриваться в качестве устройств класса А, которые являются устройствами с высокими функциональными возможностями, а STA3 130 и STA5 150 рассматриваются как устройства класса B, которые являются устройствами с низкими функциональными возможностями.

[0021] Фундаментальной проблемой в любой беспроводной связи является тот факт, что беспроводной приемопередатчик может находиться либо в состоянии передачи, либо в состоянии приема в любой данный момент времени. Даже если беспроводное устройство содержит множество приемопередатчиков, так как передаваемый сигнал несколько мощнее, чем принимаемый сигнал, пока приемопередатчик передает на определенной частоте, он не может принимать какой-либо сигнал на той же частоте. В связи с этим, практически все беспроводные устройства работают в полудуплексном режиме связи. Этот факт также приводит к следующей проблеме: передатчик, сам по себе, не в состоянии обнаружить какой-либо конфликт, который может произойти в отношении его передаваемого сигнала.

[0022] В IEEE 802.11, это преодолено за счет использования положительных квитирований приема от устройств-получателей. Если это запрашивается передатчиком, получатель посылает обратно кадр квитирования некоторого рода (Ack/Block Ack и т.д.) для подтверждения успешного приема кадра передатчика. Если передатчик не получает никаких подтверждений для его передачи, он будет считать, что передача безуспешна, и он может перейти к выполнению действий по восстановлению, например, к повторной передаче кадра и т.д. В качестве превентивной меры, IEEE 802.11 использует Множественный Доступ с Зондированием Канала с Предотвращением Конфликтов (CSMA/CA) в качестве первичного механизма доступа к каналу. Предотвращение столкновений достигается за счет использования случайных отсрочек передачи, тогда как CSMA предполагает использование физических и виртуальных механизмов Зондирования Канала (CS). Физический механизм CS обеспечивается PHY-уровнем и включает в себя фактическое зондирование беспроводной среды (либо обнаружение преамбулы, либо обнаружение энергии, либо оба). Виртуальный механизм CS обеспечивается МАС-уровнем и использует Вектор Сетевого Распределения (NAV). NAV поддерживает предсказание будущего трафика в среде на основе информации о длительности, которая объявляется в большинстве IEEE 802.11 кадров. Эта длительность может содержаться в заголовке MAC и/или может быть получена также из длительности Возможности Передачи (TXOP) в заголовке PHY, если он присутствует. Когда физическое CS или виртуальное CS указывает на то, что среда занята, устройству не разрешается передавать любой сигнал за исключением некоторых конкретных кадров, таких как кадр Ack или кадр Block Ack. Хотя NAV является полезным, чтобы защитить передачу устройства от устройств третьих лиц, которые находятся на его дальности связи, NAV не предназначен для предотвращения конкуренции от STA, которые являются получателями кадров, которые устанавливают NAV.

[0023] Многопользовательская передача была введена в поправке IEEE 802.11ac посредством технологии MU-MIMO, но только в нисходящей линии связи. AP смогла передавать различные кадры одноадресной передачи, которые адресованы к различным STA, с использованием различных пространственных потоков. Однако из-за потребности в дополнительных антеннах и других сложностей, эта функция не была введена в направлении восходящей линии связи. Как указывалось выше, многопользовательская передача с использованием OFDMA как в нисходящей линии связи, так и в восходящей линии связи является ключевой технологией, которую приняла исследовательская группа IEEE 802.11ax для достижения целей улучшения пропускной способности. В направлении нисходящей линии связи, так как именно АР будет передавать все многопользовательские кадры, многопользовательская передача является сравнительно простой. Многопользовательский PPDU DL состоит из заголовка PHY широкополосного канала, который переносит информацию относительно узкополосных каналов (известных как единицы ресурсов или RU), на которых переносится каждый отдельный PHY-блок служебных данных (PSDU). Теоретически, в пределах одного канала 20 МГц, до 37 независимых передач может переноситься к 37 различных STA, в многопользовательском PPDU.

[0024] Передача в направлении восходящей линии связи является более сложной, так как существует необходимость в синхронизации времени между передачами от нескольких STA, а также должно быть обеспечено, чтобы передачи от различных STA не мешали друг другу, т.е. каждой STA должен быть присвоен уникальный RU. Это достигается в IEEE 802.11ax с помощью специального кадра управления, называемого кадром запуска, который передается посредством AP. Кадр запуска содержит информацию, такую как Распределение Единицы Ресурса (RU), длина PPDU, MCS и т.д., которые должны использоваться для передачи UL. После приема кадра запуска, STA, которым распределены RU в кадре запуска, могут передавать соответствующие кадры UL в качестве многопользовательского PPDU UL после SIFS от конца кадра запуска без необходимости конкурировать за беспроводную среду. Помимо базового кадра запуска, который может быть использован для запрашивания любого типа кадров, различные варианты кадров запуска были определены, чтобы запрашивать конкретный тип кадров. Например, вариант MU-RTS используется для запрашивания кадров CTS от множества STA, в то время как MU-BAR используется для запрашивания кадров Block Ack от множества STA, и т.д.

[0025] Исходя из вышеизложенных знаний, авторы настоящей заявки создали настоящее изобретение. Раскрыты способы, которые позволяют осуществлять эффективно и своевременно многопользовательский обмен кадрами управления. В соответствии с одним аспектом настоящего раскрытия, АР, в PPDU DL, несущем один или более кадров, указывает на длительность времени, в течение которой STA-получателю, который является адресованным в кадре, содержащемся в PPDU DL, не разрешено передавать любой кадр, иной чем немедленное квитирование предыдущего PPDU DL, пока STA не примет другой кадр, который явно дает разрешение STA передавать снова. Это может рассматриваться как передатчик, защищающий свою будущую передачу от одной или более STA, которые являются получателями его более ранней передачи. Защита от STA третьей стороны может быть обеспечена с помощью традиционного механизма защиты NAV. Это позволит AP передавать кадр запуска, запрашивающий многопользовательский PPDU UL, своевременным образом.

[0026] Второй аспект настоящего раскрытия включает в себя настройку кадра запуска, чтобы ограничивать типы кадра, запрашиваемого в PPDU UL, типом, который является предпочтительным для AP. В случае многопользовательского обмена кадрами управления, это задействует указание в кадре запуска, с использованием конкретного типа кадра запуска или с использованием нового варианта базового кадра запуска, точного типа и подтипа кадра управления и других деталей, которые позволят адресованным STA однозначно идентифицировать точный тип кадра управления, предпочитаемый АР, подлежащий включению в PPDU UL.

[0027] Различные примерные варианты осуществления для многопользовательского обмена кадрами управления, предложенного в настоящем изобретении, подробно описаны в следующих разделах.

[0028] <Первый вариант осуществления>

Как упоминалось ранее, одной из проблем многопользовательского обмена кадрами управления, когда обмен инициируется AP посредством отправки многопользовательского PPDU DL, содержащего кадры запроса управления, адресованные к множеству STA, является тот факт, что соответствующие однопользовательские кадры ответа/отчета управления от соответствующей STA будут конкурировать за среду с кадром запуска АР и могут вызвать задержки в передаче кадра запуска. Поскольку многопользовательский PPDU UL, несущий несколько кадров ответа управления, не разрешается передавать без приема кадра запуска от АР, это может вызвать прерывания многопользовательского обмена кадрами управления.

[0029] Возможно, что АР будет пытаться защитить последующие кадры ответа от STA путем включения более длинной длительности TXOP в PPDU DL, который инициирует обмен кадрами, устанавливая при этом NAV STA третьей стороны. В качестве альтернативы, АР может также использовать механизмы защиты, такие как обмен многопользовательскими кадрами RTS (MU-RTS) и CTS перед обменом кадрами управления. Однако это не решает проблему, состоящую в том, что кадр запуска задерживается из-за конкуренции STA, которые являются получателем PPDU DL, поскольку правила установки NAV не применяются к STA. Возможно, что АР могла бы попытаться избежать вышеупомянутую конкуренцию STA, которые являются получателем PPDU DL, путем передачи кадра запуска после короткого межкадрового промежутка (SIF) от конца PPDU UL, несущего кадры Ack STA, до PPDU DL, тем самым предотвращая конкуренцию однопользовательских кадров ответа/отчета управления STA за среду передачи. Однако этот способ не всегда может работать, так как STA могут быть не в состоянии подготовить кадры ответа/отчета управления в течение этой длительности. Это может быть связано с несколькими факторами, например, возможностями обработки STA либо характером кадра управления, обмен которым осуществляется, либо STA может быть занята другими процессами во время приема кадра запроса управления и так далее. Это приведет к неиспользованию RU в PPDU UL, что является не только неэффективным использованием среды, но и в крайних случаях может привести к тому, что STA третьей стороны воспринимают среду как незанятую и передают, вызывая в результате конфликт на AP.

[0030] Для того чтобы решить эту проблему, в настоящем изобретении вводится новый механизм защиты. Он предусматривает то, что АР включает длительность времени, представляющую таймаут кадра запуска, упоминаемый далее как TF-Таймаут, в кадры одноадресной передачи нисходящей линии связи. Включение TF-Таймаута в кадр указывает намерение AP передать, в качестве следующего кадра нисходящей линии связи, кадр запуска в течение длительности таймаута, который распределяет RU STA-получателю для передачи кадра восходящей линии связи. TF-Таймаут может быть выполнен в виде отдельного поля в новом элементе, определенном для конкретной цели переноса TF-Таймаута, или он также может выполняться в существующем элементе.

[0031] Фиг. 4А иллюстрирует конструкцию элемента 400, который несет длительность TF-Таймаута в соответствии с первым вариантом осуществления. Элемент 400 включает в себя ID Элемента 410, поле 420 Длина и поле 430 TF-таймаута. ID Элемента 410 уникально идентифицирует элемент, имеет один октет в длину и определяется спецификацией IEEE 802.11. Поле 420 Длина также имеет один октет в длину и определяет число октетов, следующих за полем Длина. В этом примере, поле Длина указывает один октет.

[0032] Поле 430 TF-Таймаута также имеет один октет в длину, и его кодирование показано в таблице 450 на фиг. 4В. Если TF-Таймаут установлен в 0, это указывает на то, что таймаут не установлен, или он будет сбрасывать TF-Таймаут, если он был ранее установлен в ненулевое значение. Если установлен в ненулевое значение, TF-Таймаут указывает длительность таймаута в единицах Единицы Времени (TU, 1 TU=1024 мкс).

[0033] На фиг. 5 показан примерный многопользовательский обмен 500 кадрами управления, который стал возможным благодаря настоящему изобретению. Последовательность обмена кадрами в этом примере является многопользовательской версией процесса установки Block Ack, упомянутого на фиг. 3 и включает в себя обмен кадрами запроса ADDBA от AP (инициатора) и кадрами ответа ADDBA от STA (получателей). Обмен кадрами инициируются посредством АР путем конкуренции за среду и после выигрыша в конкуренции, передачи многопользовательского PPDU 502 OFDMA-DL, несущего один или более одноадресных кадров 504, 506,…, 508 запроса ADDBA, адресованных к STA1, STA2, …, STAn. Фраза ʺX, …, Yʺ здесь и в последующих текстах представляют объекты, пронумерованные от X до Y в порядке возрастания. Буква ʺnʺ в STAn представляет число больше, чем 2, и меньше, чем максимальное число STA, которые могут быть адресованы в многопользовательском PPDU.

[0034] В соответствии с первым вариантом осуществления, каждый из кадров 504, 506,…, 508 запроса ADDBA также несет элемент 400, который включает в себя поле 430 TF-Таймаут. Поле 430 TF-Таймаут указывает длительность времени, как визуализируется посредством 518, в течение которого STA1, STA2, …, STAn с адресами, совпадающими с полем Адрес Приемника соответствующих кадров 504, 506,…, 508 ответа ADDBA, не разрешено передавать какой-либо кадр, кроме немедленного квитирования предыдущего PPDU DL, пока STA не примет кадр 510 запуска, который распределяет RU для STA, чтобы передать свои соответствующие кадры UL. Для того чтобы определить подходящее значение, которое должно использоваться для длительности TF-Таймаута, АР может учитывать несколько факторов, таких как тип обмениваемых кадров управления или возможности обработки STA и т.д. Например, AP может установить более длинную длительность TF-Таймаута для обмена кадрами управления ADDTS, поскольку кадры ADDTS вовлекают множество параметров, и STA может потребоваться больше времени для подготовки кадров ADDTS. Аналогичным образом, АР может установить более короткую длительность TF-Таймаута, если все STA, вовлеченные в обмен, являются устройствами класса А с более высокими функциональными возможностями, и более короткую длительность TF-Таймаута, если STA являются устройствами класса B с более низкими функциональными возможностями.

[0035] Выбор АР длительности TF-Таймаута также может быть основан на знании АР предыдущих попыток установки Block Ack с STA. Например, если предыдущая попытка установки Block Ack с STA была безуспешной из-за того, что STA была не в состоянии передать кадр ответа ADDBA во время, АР может выбрать более длинную длительность TF-Таймаута для STA в следующей попытке установки Block Ack. Длительность TF-Таймаута для группы STA, принимающих участие в том же самом обмене кадрами, должна быть установлена на то же самое значение. Вычисление длительности TF-Таймаута может быть выполнено с помощью специализированного модуля 1854 на MAC-уровне СР, или она может быть реализована как функция программного обеспечения в пределах МАС. STA, которая принимает длительность TF-Таймаута, может реализовать отдельный таймер (таймер 1954 TF-Таймаута) в пределах MAC-уровня, чтобы отсчитывать эту длительность, и может установить флаг 1958 TX Ограничение, который ограничивает любую передачу в то время, как значение таймера не равно нулю. После приема действительного кадра запуска от АР, распределяющей RU для STA, чтобы передавать ее кадры UL, таймер 1954 TF-Таймаута будет сброшен в нуль, и флаг 1958 ограничения ТХ будет очищен.

[0036] После того, как АР приняла кадры Ack для кадров запроса ADDBA, она будет передавать кадр запуска 510 на STA, чтобы запрашивать кадры ответа ADDBA от STA, которые отправили обратно кадры Ack. Помимо другой информации, упомянутой ранее, кадр запуска 510 будет включать в себя информацию, чтобы ограничить тип кадра, который STA может передавать в непосредственно следующем PPDU UL, кадром ответа ADDBA. В примерной последовательности 500, кадр запуска 510 распределяет RU 512, 514, …, 516 для STA1, STA2, …, STAn, соответственно. Кадр запуска может быть передан как широковещательный кадр запуска в однопользовательском формате PPDU или он также может быть передан как множество одноадресных кадров запуска в многопользовательском формате PPDU.

[0037] АР может конкурировать за среду передачи и пытаться передать кадр 510 запуска сразу же после приема кадров Ack от STA, если АР уверена, что STA будут способны подготовить кадры ответа ADDBA во время. В качестве альтернативы, она может выбрать, попытаться осуществить передачу немного позже, чтобы обеспечить больше времени для STA, чтобы подготовить кадры ответа ADDBA, но это влечет за собой риск, что другие STA третьей стороны могут упредить передачу кадра запуска. Этот риск может быть сведен к минимуму с помощью механизмов защиты, таких как обмен многопользовательскими RTS (MU-RTS) и CTS кадрами перед обменом кадрами управления. То, как АР выбирает длительность TXOP, которая будет использоваться в обмене MU-RTS/CTS или начальным MU PPDU нисходящей линии связи для защиты многопользовательского обмена кадрами управления, может также зависеть от длительности TF-Таймаута. В идеале, длительность TXOP, которая охватывает весь обмен кадрами управления, будет предпочтительнее, чтобы защитить обмен кадрами управления от STA третьей стороны, но это может быть нежелательным, когда длительность TF-Таймаута сравнительно велика, поскольку такая защита может рассматриваться неравноправной для станций третьей стороны.

[0038] Более разумный подход для AP может состоять в том, чтобы установить длительность TXOP только достаточно длинной, чтобы защитить кадр 510 запуска, запрашивающий кадры управления ответом, и кадр 510 запуска инициирует следующий ТХОР с длительностью TXOP достаточно длинной, чтобы защитить последующий обмен кадрами. Еще более консервативным подходом может быть, установка длительности TXOP только до Ack кадров, квитирующих MU PPDU 502 нисходящей линии связи, в этом случае не будет никакой защиты от STA третьей стороны. То, как AP или STA, участвующие в обмене кадрами управления, конкурируют за среду передачи, чтобы передавать кадр запуска или однопользовательские кадры управления ответом, может также зависеть от длины длительности TXOP. В пределах длительности TXOP, конкуренция может только использовать зондирование среды в течение фиксированной длительности, например, PIFS без выполнения случайной отсрочки передачи, тогда как за пределами длительности TXOP, конкуренция за среду также включает в себя случайную отсрочку передачи.

[0039] После приема кадра 510 запуска, каждая из STA STA1, STA2, …, STAn будет передавать UL многопользовательский PPDU 520, PHY заголовок, занимающий всю полную полосу, и соответствующие кадры 522, 524, …, 526 ответа ADDBA, занимающие узкие полосы на соответствующих распределенных RU 512, 514, …, 516. После приема UL многопользовательского PPDU 520, АР завершает обмен кадрами посредством передачи кадра 530 квитирования в качестве DL многопользовательского PPDU, несущего отдельные кадры 532, 543, …, 536 Ack на отдельных RU.

[0040] На фиг. 6 показана последовательность 600 обмена кадрами, которая очень похожа на последовательность 500 обмена кадрами, но это дает пример случая, когда одна или более STA не в состоянии подготовить запрашиваемый кадр управления во время, а именно кадр ответа ADDBA в этом примере. Здесь STA1 не может отправить обратно кадр ответа ADDBA, и RU, распределенный STA1, является пустым, как показано на 612. В таком случае, АР будет использовать знание того, что STA1 ранее квитировала кадр запроса ADDBA, чтобы сделать обоснованное предположение, что STA1 будет пытаться передать кадр ответа ADDBA в более поздний момент времени.

[0041] Для того, чтобы избежать неэффективности доступа к каналу EDCA, АР может отправить передачу другого кадра 622 запуска к STA1 в том же DL многопользовательском PPDU, несущем кадры 624, …, 626 Ack к STA2, …, STAn, причем каждый кадр Ack занимает один RU. Так как кадр запуска 622 длиннее, чем кадр Ack, АР может распределить больший RU для кадра запуска по сравнению с RU, несущим кадры Ack для того, чтобы свести к минимуму заполнение. Кроме того, так как кадр запуска 622 только выделяет RU для одной STA, т.е. STA1, АР, скорее всего, выделит наибольший RU в этой полосе частот, например, для 242-тоновый RU в рабочей полосе в 20 МГц. Это можно было бы рассматривать как особое использование кадра запуска, поскольку запрашиваемый PPDU восходящей линии связи несет PSDU от одного пользователя вместо более обычного случая множества PSDU от нескольких пользователей.

[0042] Для обменов кадрами управления иных, чем обмены кадрами ADDBA, если AP и STA, уже выполнили установку Block Ack, АР может также использовать один вариант кадра мульти-STA Block Ack, чтобы квитировать кадры запроса ADDBA от STA2, …, STAn вместо индивидуальных кадров 624, …, 626 Ack. Это также поможет сбалансировать размеры RU между кадром 622 запуска и кадром Ack. Спустя длительность SIFS после окончания кадра 620 запуска, STA1 передает обратно кадр 630 ответа ADDBA к точке доступа на RU, выделенном ей кадром 622 запуска. Наконец, АР завершает обмен кадрами путем передачи кадра 640 Ack. Хотя в этом примере только STA1 терпит неуспех в передаче кадра ответа ADDBA в первом временном цикле, многие другие сценарии возможны с другими STA, которые также не способны передать соответствующие кадры ответа ADDBA, или STA, которые не способны передать ответ ADDBA даже спустя некоторое время после второго или последующих кадров запуска. Специалисту в данной области должно быть очевидно, что объясненное здесь действие восстановления, т.е. передача другого кадра запуска в том же PPDU, такого как кадры Ack, также будет работать, чтобы восстановить последовательность обмена кадрами в таких случаях. AP может повторять процесс до тех пор, пока число STA, которым не удалось передать кадр ответа ADDBA, не станет ниже предварительно заданного значения, или число попыток восстановления превысит заранее установленный срок ожидания, принятый АР для последовательности многопользовательского обмена кадрами.

[0043] На фиг.7 показан другой пример последовательности 700 многопользовательского обмена кадров, которая используется для установки механизма Block Ack между STA1, STA2, …, STAn (инициаторы) и АР, с которой ассоциированы STA (получатель). В однопользовательском случае, STA будет инициировать обмен кадрами ADDBA путем передачи запроса ADDBA к АР. Всегда возможно для AP ожидать большого количества таких запросов от множества STA и консолидировать кадры ответа ADDBA в DL многопользовательском PPDU. Однако более эффективным способом было бы синхронизировать запросы ADDBA от STA.

[0044] Предполагается, что AP будет иметь достаточно информации относительно STA, которые, скорее всего осуществят запрос установки Block Ack. AP может собрать такую информацию заранее пассивно собирая незапрашиваемые отчеты о состоянии буфера от STA, или AP также может активно опрашивать STA об их отчетах о состоянии буфера с использованием кадра запуска варианта опроса отчета о состоянии буфера (BSRP). STA, которые указывают нагрузку буфера выше определенного порога, могут рассматриваться в качестве кандидатов для многопользовательской установки Block Ack. AP может также использовать информацию о существующем потоке трафика (TS), который STA могут устанавливать с AP, для определения STA-кандидатов для многопользовательской установки Block Ack. AP инициирует последовательность обмена кадрами путем передачи кадра 710 запуска, запрашивающего кадры запроса ADDBA от кандидатов STA STA1, STA2, …, STAn.

[0045] После приема кадра 710 запуска, каждая из адресуемых STA готовит соответствующие кадры 722, 724, …, 726 запроса ADDBA и передает их в соответствующем выделенном RU в UL многопользовательском PPDU 720. АР квитирует прием UL многопользовательского PPDU 720 путем передачи DL многопользовательского PPDU 730, несущего соответствующие кадры Ack. После того, как АР завершила подготовку всех кадров ответа ADDBA, она конкурирует за среду передачи и после победы в конкуренции передает DL многопользовательский PPDU 740, несущий кадры ответа ADDBA к STA. Наконец, последовательность обмена кадрами завершается в STA, посредством передачи UL многопользовательского PPDU, несущего соответствующие кадры Ack.

[0046] Фиг. 8 иллюстрирует другую последовательность 800 обмена кадрами управления, очень похожую на последовательность 700 обмена кадрами. АР инициирует последовательность обмена кадрами посредством передачи кадра 810 запуска, запрашивающего кадр запроса ADDBA от кандидатов STA, STA1, STA2, …, STAn. После приема кадра запуска, каждая из адресуемых STA готовит соответствующие кадры запроса ADDBA и передает их в соответствующем распределенном RU в UL многопользовательском PPDU 820. В этом примере АР является достаточно быстродействующей, чтобы подготовить кадр ответа ADDBA в пределах длительности SIFS приема кадров запроса ADDBA. Для того чтобы избежать неэффективности конкуренции EDCA, для каждой STA, АР агрегирует кадр Ack с кадром запроса ADDBA и соответствующим кадром ответа ADDBA и передает их в DL многопользовательском PPDU 830 спустя SIFS после окончания PPDU UL 820. Наконец, последовательность обмена кадрами завершается в STA, посредством передачи UL многопользовательского PPDU, несущего соответствующие кадры Ack. В этом примере предполагается, что АР устанавливает длительность TXOP в кадре 810 запуска достаточно длинной, чтобы завершить всю последовательность 800 обмена кадрами.

[0047] Фиг. 9А иллюстрирует структуру кадра запуска, которая может быть настроена, чтобы запрашивать конкретный тип кадра в соответствии с настоящим раскрытием. Структура 900 кадра была предложена в IEEE 802.11ax как специальный кадр управления, называемый кадром запуска, используемым для запрашивания и распределения ресурсов для многопользовательских передач UL. Помимо общих полей MAC-кадра, таких как Управление Кадром 902, Длительность 904, Адрес Приемника (RA) 906, Адрес Передатчика (ТА) 908 и Последовательность Проверки Кадра (FCS) 918, кадр запуска также содержит следующие поля:

- поле 910 Общая Информация (Common Info), используемое для указания информации, которая является общей для всех STA, которым распределены RU посредством кадра запуска,

- одно или более полей 912, …, 914 Пользовательская Информация (User Info), используемых для обозначения информации, специфичной для конкретного пользователя. Широковещательно передаваемый кадр запуска несет несколько полей Пользовательская Информация, в то время как одноадресно передаваемый кадр запуска несет только одно поле Пользовательская Информация,

- Опционально, кадр запуска может также включать в себя поле 916 Заполнение, чтобы расширить кадр запуска и предоставить больше времени для STA, чтобы подготовить UL многопользовательский PPDU.

[0048] Фиг. 9В иллюстрирует структуру поля 910 Общая Информация и содержит следующие подполя:

- подполе 922 Тип Запуска указывает тип кадра запуска. В первом варианте осуществления подполе Тип Запуска устанавливается на значение 0 (ноль) и указывает базовый кадр запуска,

- подполе 924 Длина указывает длину запрашиваемого PPDU UL.

- подполе 926 Каскадная Информация, которое, если равно 1, указывает на то, что последующий кадр запуска будет следовать за текущим кадром запуска,

- поле 928 Требуется CS указывает, требуется ли от STA выполнить физическое и виртуальное зондирование несущей перед передачей кадра ответа,

- поле 930 BW указывает ширину полосы канала,

- подполя CP и Тип LTF 932, режим MU MIMO LTF 934, # LTF 936, STBC 938, LDPC Дополнительный Символ 940, AP TX Мощность 942 и Расширение Пакета 944 указывают информацию, необходимую для уровня PHY для подготовки и передачи PPDU UL,

- подполе 946 Пространственное Повторное Использование указывает информацию для пространственного повторного использования среды,

- подполе 948 НЕ-SIGA Зарезервировано указывает, как должны быть установлены зарезервированные биты в SIGA PPDU UL,

- подполе 950 Зависимая от Типа Общая Информация указывает информацию, специфическую для этого конкретного типа кадра запуска. Текущий базовый кадр запуска, предложенный в IEEE 802.11ax, не содержит подполе Зависимая от типа Общая Информация.

[0049] Фиг. 9C иллюстрирует структуру поля 950 Зависимая от типа Общая Информация, предложенного в первом варианте осуществления, чтобы ограничить типы кадров, которые STA, указанные в полях Пользовательская Информации, могут включать в PPDU UL, который следует за кадром запуска. Базовый кадр запуска в настоящее время не накладывает никаких ограничений на типы кадров ответа, которые могут быть включены в PPDU UL. В соответствии с первым вариантом осуществления, двух-октетное подполе 952 Предпочтительный Тип Ответа включено в поле Зависимая от типа Общая Информации и содержит следующие подполя:

- однобитовое подполе 954 Тип Кадра, указывающее тип кадра, запрашиваемого в PPDU UL. Значение 0 указывает кадр данных, в то время как значение 1 указывает кадр управления.

- четырехбитовое подполе 956 TID/Подтип Кадра указывает TID кадра данных, если подполе 954 Тип Кадра указывает кадр данных, или подтип кадра управления, если подполе 954 Тип Кадра указывает кадр управления. То же самое кодирование подтипа кадра, что и для подполя Подтип, определенного для поля Управление Кадром в спецификации IEEE 802.11, может быть использовано, например, 0 для кадра Запрос Ассоциации, 13 для кадра действия и т.д.

- одно-октетное подполе 958 Специфика Подтипа, которое является зарезервированным, если подполе 954 Тип Кадра указывает кадр данных, и указывает дополнительные детали относительно типа кадра, если подполе 954 Тип Кадра указывает кадр управления. Кодирование подполя 958 Специфика Подтипа может отличаться для различных кадров управления. Например, если подполе 956 Подтип Кадра указывает 13, т.е. кадр действия управления, подполе 958 Специфика Подтипа дополнительно разделено на пятибитовое подполе 972 Категория Действия и трехбитовое подполе 974 поля Действие. Кодирование подполя 972 Категория Действия таково, как подробно описано в таблице 980 на фиг. 9F, и значения от 0 до 21 используются для указания кадра категории действия, как определенно в спецификации IEEE 802.11; например, 0 для кадров действия управления спектром, 3 для кадров действия Block Ack и т.д. Подполе 974 Поле Действия определяет формат кадра в пределах категории кадра действия, и пример, когда Категория Действия указывает кадры действия Block Ack, подробно описан в таблице 990 на фиг. 9G. Смысл значений от 0 до 7 такой же, как определено в соответствующем разделе спецификации IEEE 802.11; например, 0 указывает запрос ADDBA, 1 обозначает ответ ADDBA и т.д.

[0050] Кодирование типа предпочтительного ответа приведено в таблице 960 на фиг. 9D.

[0051] <Второй вариант осуществления>

В соответствии со вторым вариантом осуществления АР указывает TF-Таймаут с помощью одного из подполей управления в подполе Агрегированное Управление (A-Управление) поля НТ- Управление HE-варианта.

[0052] Фиг. 10A иллюстрирует формат подполя А-Управление поля 1000 НТ-Управление HE-варианта, как определено в стандарте IEEE 802.11ax. Подполе А-Управление содержит последовательность из одного или более подполей 1010, …, 1020 с последующим опциональным подполем 1030 Заполнение, которое установлено в последовательность нулей таким образом, чтобы сделать длину подполя А-Управление равной 30 битам. Каждое подполе Управление состоит из четырех-битового подполя ID Управления и подполя Информация Управления переменной длины. Подполе ID Управления указывает тип информации, содержащейся в подполе Информация Управления, в то время как длина подполя Информация Управления является фиксированной для каждого значения подполя ID Управления, которое не зарезервировано. ID Управления от 0 до 3 были определены в 802.11ax, и их детали показаны в таблице 1060 на фиг. 10С. Фиг. 10B иллюстрирует формат подполя 1050 Управление, используемого для переноса TF-Таймаута согласно второму варианту осуществления. Помимо подполя 1052 ID Управления, оно переносит восьмибитовое подполе 1054 TF-Таймаут. Потенциальное кодирование подполей является таким, как подробно описано в строке 1062 в таблице 1060. Перенос TF-Таймаута в подполе А-Управление в MAC-заголовке кадра нисходящей линии связи могло бы быть эффективным способом сигнализации TF-Таймаута.

[0053] В соответствии со вторым вариантом осуществления, новый тип запуска определяется для кадра запуска, который используется для запрашивания кадров управления. Таблица 1100 на фиг. 11А подробно описывает различные типы запусков, которые были определены в 802.11ax, со строкой 1102, показывающей примерное кодирование для типа запуска используемого, чтобы запрашивать кадры управления, как это предлагается во втором варианте осуществления. При использовании запрашивания кадров управления, подполе 922 Тип Запуска должно быть установлено на значение, которое указывает запуск кадра управления.

[0054] Фиг. 11B иллюстрирует структуру двух-октетного подполя 1100 Предпочтительный Тип Ответа, предложенную для включения в поле 950 Зависимая от Типа Общая Информация, которая используется для того, чтобы дополнительно сузить конкретный кадр управления, предпочтительный для АР, и содержит четырех-битовое подполе 1112 Подтип Кадра и восьмибитовое подполе 1114 Специфика Подтипа, в то время как остальные 4 бита зарезервированы. Подполе 1112 Подтип Кадра указывает запрашиваемый подтип кадра управления, и может быть использовано то же кодирование подтипа кадра, что и для подполя Подтип, определенного для поля Управление Кадра в спецификации IEEE 802.11. Кодирование подполя 1114 Специфика Подтипа может отличаться для различных кадров управления, и пример кодирования, когда подполе 1112 Подтип Кадра указывает кадры действия управления, показан на фиг. 9E.

[0055] Таблица 1140 на фиг. 11D показывает примерное кодирование для подполя 974 Поле Действия, когда Категория Действия указывает 1 для QoS кадра действия. Смысл значений от 0 до 6 такой же, как определено в соответствующем разделе спецификации IEEE 802.11; например, 1 указывает ответ ADDTS ответ, 4 указывает конфигурацию карты QoS и т.д.

[0056] Фиг. 11E иллюстрирует структуру 1150 одного из полей 912, …, 914 Пользовательская Информация и содержит следующие подполя:

- Подполе 1152 AID 12, которое переносит AID STA, для которой предназначено поле Пользовательская Информация,

- Подполе 1154 Распределение RU, которое указывает RU, распределенное STA, идентифицированной подполем 1152 Идентификатор Пользователя,

- Подполе 1156 Тип Кодирования, которое указывает тип кода PPDU восходящей линии связи, отправленного как ответ STA, идентифицированной подполем 1152 Идентификатор Пользователя,

- подполе 1158 МCS, которое указывает MCS PPDU восходящей линии связи, отправленного как ответ STA, идентифицированной подполем 1152 Идентификатор Пользователя,

- Подполе 1160 DCM, которое указывает, должна ли Модуляция Двойной Несущей (DCM) использоваться в PPDU восходящей линии связи, отправленного как ответ STA, идентифицированной подполем 1152 Идентификатор Пользователя,

- подполе 1162 Распределение SS, которое указывает пространственные потоки PPDU восходящей линии связи, отправленного как ответ STA, идентифицированной подполем 1152 Идентификатор Пользователя,

- подполе 1164 Целевой RSSI, которое указывает ожидаемый AP RSSI для PPDU восходящей линии, отправленный как ответ STA, идентифицированной подполем 1152 Идентификатор Пользователя,

- однобитовое поле 1165 Зарезервировано,

- подполе 1166 Зависимая от Типа Пользовательская Информация, которое указывает на информацию специфичную для STA, идентифицированной подполем 1152 Идентификатор Пользователя. В соответствии со вторым вариантом осуществления, когда подполе 922 Тип Запуска устанавливается на значение, которое указывает запуск кадра управления, подполе 1166 Зависимая от Типа Пользовательская Информация переносит специфичную для пользователя дополнительную информацию, относящуюся к обмену кадрами управления. В качестве примера, при использовании во время обмена кадрами действия ADDTS QoS, это может включать в себя значение ID потока трафика (TSID), или при использовании во время обмена кадрами действия Block Ack, это может включать в себя значение TID; различные поля Пользовательская Информация могут иметь различные значения.

[0057]<Третий вариант осуществления>

В соответствии с третьим вариантом осуществления, предлагается другой способ перенесения TF-Таймаута. Вместо того чтобы определить новый элемент, существующий элемент, уже переносимый кадром управления, может использоваться посредством АР, чтобы переносить TF-Таймаут.

[0058] Пример в случае кадров действия Block Ack показан на фиг. 12А. TF-Таймаут переносится в элементе 1200 ADDBA Расширения. ID элемента 1202 устанавливается, как указано в спецификации 802.11; поле 1204 Длина указывает один октет, в то время как поле 1206 Возможности ADDBA настроено, как показано на фиг. 12В. Помимо существующего подполя 1212 Без-Фрагментации, остальные 7 битов в настоящее время зарезервированы. В соответствии с третьим вариантом осуществления, некоторые из зарезервированных битов, например, 6 битов используются для указания TF-Таймаута 1224, в то время как оставшийся 1 бит зарезервирован. Кодирование TF-Таймаута подробно описано в таблице 1230 на фиг. 12С: значение, равное нулю указывает, что TF-Таймаут не установлен или он используется для сброса ранее установленного TF-Таймаута, в то время как значения от 1 до 63 указывают значения таймаута от 1 до 63 TU соответственно. По сравнению с первым вариантом осуществления, диапазон TF-Таймаута, который может быть установлен в способе, предложенном во втором варианте осуществления, может быть короче, в зависимости от того, сколько битов доступны в существующих элементах для указания TF-Таймаута, но даже с более коротким диапазоном, цель защиты передачи АР может быть выполнена, так как в фактической реализации длительность TF-Таймаута не ожидается очень большой.

[0059] Согласно третьему варианту осуществления изобретения, предложен другой вариант кадра запуска, который представляет собой вариант кадра запуска, предлагаемого в первом варианте осуществления. На фиг. 13А показана структура двух-октетного подполя 1300 Предпочтительный Тип Ответа, предложенного для включения в поле 950 Зависимая от Типа Общая Информация согласно третьему варианту осуществления изобретения. Подполе 1300 Предпочтительный Тип Ответа содержит двух-битовое подполе 1310 Тип Кадра, четырех-битовое подполе 1320 TID/Подтип Кадра и восьмибитовые подполя 1330 Специфика Подтипа, а остальные 2 бита зарезервированы.

[0060] В то время как остальная часть подполей является такой же, как определенно в первом варианте осуществления, кодирование подполя 1310 Тип Кадра таково, как подробно описано в таблице 1340 на фиг. 1 и соответствует подполю Тип, определенному для поля Управление Кадра в спецификации 802,11. Подполе 1320 TID/Тип Подкадра указывает TID кадра данных, если подполе 1310 Тип Кадра указывает кадр данных, подтип кадра управления, если подполе 1310 Тип Кадра указывает кадр управления, и подтип кадра управления, если подполе 1310 Тип Кадра указывает кадр управления. Подполе 1330 Специфика Подтипа указывает дополнительные детали относительно типа кадра, если подполе 1310 Тип Кадра указывает кадр управления, иначе оно зарезервировано для кадров данных и управления. Кодирование подполя 1330 Специфика Подтипа может отличаться для различных кадров управления, и примерное кодирование, когда подполе 1320 Подтип Кадра указывает кадры действия управления, показано на фиг. 9E.

[0061]<Четвертый вариант осуществления>

В соответствии с четвертым вариантом осуществления, АР включает один или более флагов, называемых TF-Флагом, в DL многопользовательский PPDU, который инициирует многопользовательский обмен кадрами управления, чтобы указать STA-получателям о намерении AP передать, в качестве следующего кадра после DL многопользовательского PPDU, кадр запуска, распределяющий RU для STA. TF-флаг может переноситься в одном из подполей Управление подполя А-Управление поля 1000 НТ-Управление HE-Варианта.

[0062] На фиг. 14 показана структура подполя 1450 Управление, когда подполе ID Управления равно 0, в этом случае подполе Информация Управления переносит информацию планирования для UL многопользовательского PPDU, несущего немедленное квитирование для кадров, содержащих подполе Управление. Подполе 1450 Управление содержит следующие подполя:

- подполе 1452 Длина PPDU UL, которое указывает длину PPDU ответа восходящей линии связи.

- подполе 1454 Распределение RU, которое указывает RU, назначенный для передачи ответа PPDU восходящей линии связи.

- подполе 1456 Мощность DL TX, которое указывает мощность передачи AP.

- подполе 1458 Целевой RSSI UL, которое указывает целевую мощность приема AP.

- подполе 1460 MCS UL, которое указывает MCS, подлежащую использованию для PPDU ответа восходящей линии связи.

- TF-флаг 1462, предложенный в четвертом варианте осуществления, который указывает намерение AP передать, в качестве следующего кадра, следующего за кадром, который содержит подполе 1450 Управление, кадр запуска, распределяющий RU для STA, чтобы передать последующий ответ PPDU восходящей линии связи.

[0063] Когда TF-флаг 1462 установлен на 1, это означает ограничение передачи, и STA, которая является получателем кадра, несущего TF-флаг 1462, ограничена от передачи чего-либо в среде, за исключением кадра немедленного квитирования, до тех пор, пока она не примет кадр запуска от AP, распределяющей RU для нее, или пока не истечет длительность TXOP, указанная кадром, несущим TF- флаг 1462. Другими словами, в соответствии с четвертым вариантом осуществления, длительность TXOP, указанная кадром, несущим TF-флаг 1462, действует как неявный TF-Таймаут, который был предложен в других вариантах осуществления. Если STA не удается принять кадр запуска, STA может возобновить нормальную передачу после того, как TXOP истекает.

[0064] Последовательность 1500 обмена кадрами на фиг. 15 иллюстрирует пример многопользовательского обмена кадрами управления в соответствии с четвертым вариантом осуществления. Обмен кадрами управления для установки Block Ack приведен в качестве примера. Многопользовательский PPDU 1510 нисходящей линии связи переносит несколько одноадресных кадров 1512, …, 1516 запроса ADDBA, адресованных к STA STA1, … STAn. Каждый кадр запроса ADDBA также переносит подполе 1450 Управление, которое распределяет RU для кадра Ack в ответ на кадр запроса ADDBA, с 922 TF-флагом 1462, установленным в 1. PPDU 1510 также устанавливает длительность 1520 TXOP достаточно длинной, чтобы покрыть время, в которое АР рассчитывает передать кадр 1530 запуска, который запрашивает кадры ответа ADDBA от STA. Длительность 1520 TXOP действует как защита для кадра запуска 1520 против STA третьей стороны. Поскольку TF-флаги 1462 установлены в 1, STA ограничены от передачи соответствующих однопользовательских кадров ответа ADDBA до тех пор, пока гн будет принят кадр 1530 запуска.

[0065] Другой альтернативный способ, чтобы переносить TF-флаг состоит в использовании одного бита в PHY-заголовке DL многопользовательского PPDU, который инициирует многопользовательский обмен кадрами управления, например, один бит в поле общего блока HE SIG-B. Если бит установлен, ограничение передачи применяется ко всем STA, которые имеют нешироковещательные RU, распределенные в полях пользователя SIG-B.

[0066]<Система связи радио>

Фиг. 16 иллюстрирует примерный способ 1600, подлежащий реализации посредством AP, чтобы облегчить многопользовательский обмен кадрами управления, инициированный AP. Пример для случая обмена кадрами, инициированного STA, подобен этому и поэтому не поясняется. В 1610, на основе информации из приложений верхнего уровня или на основе существующих кадров данных в буферах AP и т.д., АР выбирает группу STA, с которыми АР намерена инициировать обмен кадрами управления. АР может также учитывать другие факторы, такие как возможности STA, при выборе группы, например, группируя STA высокой производительности Класса А в одну группу и группируя STA низкой производительности Класса В в другую группу и т. д.

[0067] В 1620, на основе аналогичной информации, АР также определяет значение, которое будет использоваться для TF-Таймаута, или подходящую длительность TXOP, которая будет использоваться, если используется способ TF-флага. В 1630, АР формирует многопользовательский PPDU для переноса одноадресных кадров управления и включает TF-таймаут или TF-флаг. В 1640, после конкуренции за среду, АР передает многопользовательский PPDU. В 1650, АР формирует кадр запуска, который распределяет RU для STA, чтобы отправить обратно соответствующие кадры управления ответа, и после ожидания в течение соответствующего периода времени, АР передает кадр запуска. В 1660, после приема кадров управления ответа от STA, АР передает многопользовательский PPDU, несущий соответствующие кадры Ack. Если какой-либо из STA не удалось отправить обратно кадр управления ответа, АР также включает в многопользовательский PPDU широковещательные или один/несколько одноадресных кадров запуска, распределяющих RU для каждой из таких STA. Этот этап можно повторять по мере необходимости, пока длительность TXOP не истечет, или когда AP принимает кадры управления ответа от всех вовлеченных STA.

[0068] Фиг. 17 иллюстрирует примерный способ 1700, подлежащий реализации посредством STA, чтобы участвовать в многопользовательском обмене кадрами управления, инициированном посредством AP. Пример для случая обмена кадрами, инициированного посредством STA, также является сходным и поэтому не поясняется. В 1710, STA принимает многопользовательский PPDU, переданный посредством AP, и на основе соответствующей информации из PHY-заголовка, извлекает кадр управления, адресованный STA. В 1720, помимо обработки принятого кадра управления, STA также извлекает либо поле TF-Таймаут, либо TF-флаг и запускает таймер, который инициализируется либо на длительность TF-Таймаута, либо, если используется способ TF-флага, на оставшуюся длительность TXOP. Когда упомянутый таймер не равен нулю, STA воздерживается от передачи любого кадра, отличного от немедленного квитирования для принятого кадра управления.

[0069] В 1730, STA подготавливает кадр управления ответа, если она принимает запрос от АР и ожидает кадр запуска. В 1740, после приема кадра запуска от AP, упомянутый таймер сбрасывается, и STA передает подготовленный кадр управления ответа на RU, распределенном для STA кадром запуска. Если, с другой стороны, упомянутый таймер истекает, прежде чем STA принимает кадр запуска от AP, ограничение передачи удаляется, и STA имеет возможность свободно конкурировать и передавать кадр управления ответа в однопользовательском формате PPDU.

[0070] <Конфигурация точки доступа>

Фиг. 18 представляет собой блок-схему примера AP 1800, которая может представлять собой AP 190 на фиг. 1. АР 1800 содержит центральный процессор (CPU) 1830, соединенный с памятью 1820, вторичным хранилищем 1840, с одним или более интерфейсами 1850 беспроводной связи, а также с другими интерфейсами 1880 проводной связи. Вторичное хранилище 1840 может быть энергонезависимым считываемым компьютером носителем хранения, который используется для постоянного хранения соответствующих инструкций кодов, данных и т.д. Во время запуска, процессор 1830 может скопировать коды инструкций, а также связанные с ними данные в энергонезависимую память 1820 для исполнения. Код инструкции может быть операционной системой, пользовательским приложением, драйверами устройств, исполнительными кодами и т.д., которые необходимы для работы AP 1800. Размер кода инструкции и, следовательно, емкости хранения как вторичного хранилища 1840, так и памяти 1820 могут быть по существу больше, чем таковые в STA 1700.

[0071] STA 1800 может также включать в себя источник питания 1810, который в большинстве случаев может быть питанием от сети, но в некоторых случаях также может быть каким-либо аккумулятором большой емкости, например, автомобильным аккумулятором. Проводной интерфейс связи 1880 может быть интерфейсом Ethernet или интерфейсом электролинии или интерфейсом телефонной линии и т.д. Интерфейс беспроводной связи 1850 может включать в себя интерфейс для сотовой связи, или интерфейс для протоколов связи малого радиуса действия, таких как Zigbee, или может быть интерфейсом WLAN.

[0072] Беспроводной интерфейс 1850 может дополнительно включать в себя модуль 1852 MAC и PHY-модуль 1860. Модуль 1852 MAC в АР может быть существенно более сложным, чем в STA 1900 и может содержать множество подмодулей. Среди других подмодулей, модуль 1852 МАС может содержать вычислитель 1854 TF-Таймаута, который отвечает за выполнение этапа 1620 способа 1600. Модуль 1852 МАС может также хранить таблицу 1856 кодирования, используемую для представления предпочтительного типа ответа в кадре запуска. PHY-модуль несет ответственность за преобразование данных модуля МАС в/из сигналов передачи/приема. Беспроводной интерфейс также может быть соединен, с помощью PHY-модуля, с одной или более антеннами 1870, которые ответственны за фактическую передачу/прием беспроводных сигналов связи по/из беспроводной среды.

[0073] В конкретном варианте осуществления, операционная система содержит операционную систему реального времени (RTOS), пользовательское приложение содержит веб-браузер или приложение смартфона, драйвера устройств включают в себя драйвер WLAN, и код исполнения может содержать код, который при исполнении CPU 1830, побуждает способ 1600 выполняться. В зависимости от реализации, таблица 1856 кодирования предпочтительного типа ответа может представлять собой кодирование 960 предпочтительного типа ответа или может представлять собой кодирование 1130 предпочтительного типа ответа, или может представлять собой кодирование 1340 предпочтительного типа ответа. Таблица 1856 кодирования предпочтительного типа ответа может быть сохранена со значениями по умолчанию в процессе производства, но AP 1800 также может настроить их, если это необходимо в соответствии с превалирующими условиями сети, и передавать новое содержимое таблицы к участвующим STA, например, в процессе ассоциирования, или AP 1800 может также выбрать для оповещения новое содержимое таблицы в информационном элементе в некоторых периодических кадрах, таких как кадры маяка.

[0074] AP 1800 может включать в себя множество других компонентов, которые не показаны, для наглядности, на фиг. 18. Проиллюстрированы только те компоненты, которые наиболее существенны для настоящего изобретения.

[0075] <Конфигурация STA>

На фиг. 19 показана блок-схема примерной STA 1900, которая может быть любой одной из STA на фиг. 1. STA 1900 содержит центральный процессор (CPU) 1930, соединенный с памятью 1920, вторичное хранилище 1940 и один или более интерфейсов 1950 беспроводной связи.

[0076] Вторичное хранилище 1940 может быть энергонезависимым считываемым компьютером носителем хранения, который используется для постоянного хранения соответствующих кодов инструкций, данных и т.д. В момент запуска, процессор 1930 может копировать коды инструкций, а также связанные с ними данные в энергозависимую память 1920 для исполнения. Код инструкций может быть операционной системой, пользовательскими приложениями, драйверами устройств, исполнительными кодами и т.д., которые требуются для работы STA 1900. STA 1900 может также включать в себя источник питания 1910, например, ионно-литиевую батарею или элемент питания и т.д. Интерфейс 1950 беспроводной связи может включать в себя интерфейс для сотовой связи, или интерфейс для протоколов связи малого радиуса действия, таких как Zigbee, или может быть интерфейсом WLAN.

[0077] Беспроводной интерфейс 1950 может дополнительно включать в себя модуль 1952 MAC и TF-модуль 1960. Среди других подмодулей, модуль 1952 МАС может включать в себя счетчик 1954 TF-Таймаута, чтобы отслеживать период ограничения передачи на основе либо поля TF-Таймаута, либо длительности TXOP, если используется способ TF-флага. Модуль 1952 MAC может поддерживать флаг 1958 ограничения TX для записи состояния ограничения передачи; если флаг установлен, STA воздерживается от передачи кадров иных, чем немедленные квитирования. Модуль 1952 MAC может также хранить таблицу 1956 битового кодирования, используемую для представления кодирования предпочтительного типа ответа. PHY-модуль несет ответственность за преобразование данных модуля МАС в/из сигналов передачи/приема. Беспроводной интерфейс также может быть соединен, с помощью PHY-модуля, с одной или более антеннами 1970, которые отвечают за фактическую передачу/прием беспроводных сигналов связи по/из беспроводной среды.

[0078] В конкретном варианте осуществления, операционная система содержит операционную систему реального времени (RTOS), пользовательское приложение содержит веб-браузер или приложение смартфона, драйвера устройств содержат драйвер WLAN, и код исполнения может содержать код, который при исполнении посредством CPU 1930, побуждает способ 1700 выполняться. Таймер 1954 TF-Таймаута используется в 1720, чтобы отслеживать TF-Таймаут. В зависимости от реализации, таблица 1956 кодирования предпочтительного типа ответа может представлять собой кодирование 960 предпочтительного типа ответа или может представлять собой кодирование 1130 предпочтительного типа ответа или может представлять собой кодирование 1340 предпочтительного типа ответа. Таблица 1956 кодирования предпочтительного типа ответа может быть сохранена со значениями по умолчанию в процессе производства. Также возможно, чтобы таблица 1956 кодирования предпочтительного типа ответа обновлялась в соответствии со значениями, передаваемыми посредством AP в процессе ассоциирования, или на основе значений, оповещаемых регулярно посредством AP в периодических кадрах, таких как кадры маяка.

[0079] STA 1900 может содержать множество других компонентов, которые не показаны, для наглядности, на фиг. 19. Проиллюстрированы только те компоненты, которые наиболее существенны для настоящего изобретения.

[0080] В вышеприведенных вариантах осуществления, настоящее изобретение сконфигурировано с аппаратными средствами в качестве примера, но также может быть обеспечено программным обеспечением совместно с аппаратными средствами.

[0081] Кроме того, функциональные блоки, используемые в описании вариантов осуществления, как правило, реализованы в виде LSI устройств, которые являются интегральными схемами. Функциональные блоки могут быть выполнены в виде отдельных чипов, или часть или все из функциональных блоков могут быть интегрированы в единый чип. Термин ʺLISʺ используется в настоящем описании, но термины ʺICʺ, ʺсистемная LSIʺ, ʺсупер-LSIʺ или ʺультра-LSIʺ также могут быть использованы в зависимости от степени интеграции.

[0082] Кроме того, схемная интеграция не ограничивается LSI, и может быть достигнута специализированными схемами или процессором общего назначения, иного чем LSI. После изготовления LIS, может быть использована программируемая вентильная матрица (FPGA), которая является программируемым или перестраиваемым процессором, который позволяет осуществлять реконфигурацию соединений и настроек ячеек схем в LSI.

[0083] В случае если появится технология интеграции, замещающая LSI, в результате достижений в области полупроводниковой технологии или других технологий, производных от этой технологии, функциональные блоки могли бы быть интегрированы с использованием такой технологии. Другой возможностью является применение биотехнологии и/или тому подобного.

Промышленная применимость

[0084] Настоящее изобретение может быть использовано для того, чтобы осуществлять обмен кадрами управления между многими беспроводными устройствами эффективным образом.

Список ссылочных позиций

[0085] 100 Беспроводная сеть

110, 120, 130, 140, 150, 160, 1900 STA

190, 1800 AP

1810, 1910 Источник питания

1820, 1920 Память

1830, 1930 CPU

1840, 1940 Вторичная память

1850, 1950 Беспроводной интерфейс

1852, 1952 Модуль MAC

1854 Вычислитель TF-Таймаута

1856, 1956 Таблица предпочтительного типа ответа

1860, 1960 PHY-модуль

1870, 1970 Антенна

1880 Интерфейс проводной связи

1954 Таймер TF-Таймаута

1958 Флаг ограничения TX

1. Устройство связи, содержащее:

приемник, который, во время работы, принимает кадр запуска для распределения ресурсов для многопользовательской передачи восходящей линии связи (UL MU), причем кадр запуска содержит поле общей информации, которое включает в себя подполе типа, указывающее один из множества типов запуска, причем множество типов запуска включает в себя первый тип запуска, указывающий базовый запуск, используемый для запрашивания множества типов кадра ответа, и второй тип запуска, указывающий конкретный запуск, используемый для запрашивания конкретного типа кадра ответа UL MU; и

передатчик, который, во время работы, передает конкретный тип кадра ответа UL MU в ответ на кадр запуска, когда подполе типа указывает второй тип запуска,

причем, когда подполе типа указывает второй тип запуска, кадр запуска содержит подполе типа обратной связи, включающее в себя тип обратной связи, который запрашивается для устройства связи.

2. Устройство связи по п. 1, в котором тип обратной связи указывает, что отчет запрашивается посредством кадра запуска.

3. Устройство связи по п. 1, в котором конкретный тип кадра ответа UL MU является одним из множества типов кадров управления для многопользовательского обмена кадрами управления.

4. Устройство связи по п. 1, в котором кадр запуска содержит поле пользовательской информации для каждого из множества устройств связи, включающего в себя данное устройство связи, причем поле пользовательской информации включает в себя подполе распределения блока ресурсов (RU), указывающее один или более RU, используемых соответствующим одним из множества устройств связи.

5. Устройство связи по п. 1, в котором кадр запуска содержит подполе идентификатора ассоциации (AID), несущее множество битов для ассоциирования одного из множества устройств связи, включающего в себя данное устройство связи, и поле пользовательской информации для каждого из множества устройств связи, причем поле пользовательской информации включает в себя подполе распределения блока ресурсов (RU), указывающее один или более RU, используемых соответствующим одним из множества устройств связи, и причем упомянутый один или более RU, указанных подполем распределения RU, ассоциирован с устройствами связи, которые указаны подполем AID.

6. Устройство связи по п. 1, в котором кадр запуска содержит подполе таймаута, указывающее длительность ограничения передачи, в течение которой множество устройств связи, включающее в себя данное устройство связи, ограничены от передачи любых кадров, иных чем кадр квитирования (ACK).

7. Способ связи, содержащий:

прием кадра запуска для распределения ресурсов для многопользовательской передачи восходящей линии связи (UL MU), причем кадр запуска содержит поле общей информации, которое включает в себя подполе типа, указывающее один из множества типов запуска, причем множество типов запуска включает в себя первый тип запуска, указывающий базовый запуск, используемый для запрашивания множества типов кадра ответа, и второй тип запуска, указывающий конкретный запуск, используемый для запрашивания конкретного типа кадра ответа UL MU; и

передачу конкретного типа кадра ответа UL MU в ответ на кадр запуска, когда подполе типа указывает второй тип запуска,

причем, когда подполе типа указывает второй тип запуска, кадр запуска содержит подполе типа обратной связи, включающее в себя тип обратной связи, который запрашивается для устройства связи.

8. Способ связи по п. 7, в котором тип обратной связи указывает, что отчет запрашивается посредством кадра запуска.