Способы и wtru для сканирования wur

Изобретение относится к области связи с применением в модуле беспроводной передачи/приема (WTRU). Технический результат заключается в достижении возможности для WTRU определения, когда начать сканирование пробуждающих радиоустройств (WUR). Для этого предусмотрено: генерирование объектом управления станцией (SME) примитива запроса, обеспечивающего процесс сканирования пробуждающих радиоустройств (WUR) для кадров обнаружения WUR, передаваемых одной или более точками доступа (AP), причем примитив запроса содержит множество первых параметров; выполнение процесса сканирования WUR с использованием WUR на основе множества первых параметров; генерирование на уровне MAC по меньшей мере одного примитива подтверждения на основе результата процесса сканирования WUR и по меньшей мере части множества первых параметров; и передачу от уровня MAC на SME по меньшей мере одного примитива подтверждения. 2 н. и 18 з.п. ф-лы, 23 ил., 1 табл.

 

Перекрестная ссылка на родственные заявки

Настоящая заявка испрашивает преимущество по предварительной заявке на патент США № 62/811,967, поданной 28 февраля 2019 г., содержание которой полностью включено в настоящий документ путем ссылки.

Предпосылки создания изобретения

В фиксированной или маломобильной беспроводной связи для локальных сетей (LAN) используются такие технологии, как IEEE (Институт инженеров по электротехнике и радиоэлектронике) 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ax, 802.11be или в целом 802.11x, также обычно называемые WiFi. Эти технологии относятся к спецификациям управления доступом к среде передачи данных (MAC) и физического уровня (PHY) для создания беспроводных локальных сетей (WLAN) между по меньшей мере двумя точками. С ростом WLAN может оказаться желательным передавать сигналы в одной передаче для нескольких типов интерфейсов WLAN для достижения требуемых характеристик и спектральной эффективности.

Изложение сущности изобретения

Описан способ для применения в модуле беспроводной передачи/приема (WTRU). Способ включает: генерирование объектом управления станцией (SME) примитива запроса, обеспечивающего процесс сканирования пробуждающих радиоустройств (WUR) для кадров обнаружения WUR, передаваемых одной или более точками доступа (AP), причем примитив запроса содержит множество первых параметров; выполнение процесса сканирования WUR на основе множества первых параметров; и генерирование на уровне MAC по меньшей мере одного примитива подтверждения на основе результата процесса сканирования WUR и по меньшей мере части множества первых параметров; и передачу от уровня MAC на SME по меньшей мере одного примитива подтверждения.

Описан модуль беспроводной передачи/приема (WTRU). WTRU содержит: процессор, выполненный с возможностью генерирование примитива запроса, обеспечивающего процесс сканирования WRU для кадров обнаружения WUR, передаваемых одной или более точками доступа (AP), причем примитив запроса содержит множество первых параметров; выполнения процесса сканирования WUR на основе множества первых параметров; генерирования на уровне MAC по меньшей мере одного примитива подтверждения на основе результата процесса сканирования WUR и по меньшей мере части множества первых параметров; и передачи от уровня MAC на объект управления станцией (SME) по меньшей мере одного примитива подтверждения.

Краткое описание графических материалов

Более подробное объяснение содержится в представленном ниже описании, приведенном в качестве примера, в сочетании с прилагаемыми графическими материалами, на которых аналогичные номера позиций на фигурах обозначают аналогичные элементы:

на фиг. 1A представлена схема системы, иллюстрирующая пример системы связи, в которой могут быть реализованы один или более описанных вариантов осуществления;

на фиг. 1B представлена схема системы, иллюстрирующая пример модуля беспроводной передачи/приема (WTRU), который может быть использован в системе связи, проиллюстрированной на фиг. 1A, в соответствии с вариантом осуществления;

на фиг. 1C представлена схема системы, иллюстрирующая пример сети радиодоступа (RAN) и пример опорной сети (CN), которые могут быть использованы в системе связи, проиллюстрированной на фиг. 1A, в соответствии с вариантом осуществления;

на фиг. 1D представлена схема системы, иллюстрирующая дополнительный пример RAN и дополнительный пример CN, которые могут быть использованы в системе связи, проиллюстрированной на фиг. 1A, в соответствии с вариантом осуществления;

на фиг. 2A представлена блок-схема, иллюстрирующая способ в соответствии с вариантом осуществления настоящей заявки;

на фиг. 2B представлена блок-схема, иллюстрирующая способ в соответствии с другим вариантом осуществления настоящей заявки;

на фиг. 3 показан пример конструкции элемента широковещательной передачи нисходящей линии связи (DL);

на фиг. 4 показан пример конструкции элемента широковещательной передачи восходящей линии связи (UL);

на фиг. 5 показан пример межкадрового кодирования проверки четности с низкой плотностью (LDPC) с последовательно увеличивающимися инкрементами;

на фиг. 6 показан пример межкадрового кодирования LDPC с непоследовательно увеличивающимися приращениями;

на фиг. 7 показан пример межкадрового кодирования двоичного сверточного кода (BCC);

на фиг. 8 показан пример межкадрового кодирования/частичного гибридного автоматического запроса на повторение передачи (HARQ) с фиксированными индексами;

на фиг. 9 показан пример межкадрового кодирования/частичного HARQ со скользящим окном;

на фиг. 10 показан пример межкадрового кодирования/частичного HARQ с обратной связью и динамическим выбором инкрементного подкадра;

на фиг. 11 показан пример процедуры энергосбережения с межкадровым интервалом (xIFS) между повторениями широковещательного сервиса (BCS);

на фиг. 12 показан пример процедуры энергосбережения с конкретными временными различиями между повторениями;

на фиг. 13 показан пример повторения передачи с обратной связью;

на фиг. 14 показан пример широковещательной передачи с множеством AP с разнесением с циклическим сдвигом CSD;

на фиг. 15 показан пример широковещательной передачи с множеством AP с разделением по времени;

на фиг. 16 показан пример широковещательной передачи с множеством AP со схемой пространственного разнесения передачи;

на фиг. 17 показан пример сетевой архитектуры, в которой UL WTRU (например, станция (STA)) не имеет информации о статусе приемника;

на фиг. 18 показан пример процедуры для AP для обеспечения обратной связи по нисходящей линии связи (DL); и

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

Подробное описание

На фиг. 1A представлена схема, иллюстрирующая пример системы 100 связи, в которой могут быть реализованы один или более описанных вариантов осуществления. Система 100 связи может представлять собой систему множественного доступа, от которой множество пользователей беспроводной связи получают содержимое, такое как голосовая информация, данные, видео, обмен сообщениями, широковещание и т.п. Система 100 связи может быть выполнена с возможностью предоставления множеству пользователей беспроводной связи доступа к такому содержимому посредством совместного использования системных ресурсов, включая ширину полосы пропускания беспроводного соединения. Например, в системах 100 связи можно использовать один или более способов доступа к каналу, таких как множественный доступ с кодовым разделением (CDMA), многостанционный доступ с временным разделением каналов (TDMA), многостанционный доступ с частотным разделением каналов (FDMA), многостанционный доступ с ортогональным частотным разделением каналов (OFDMA), FDMA с одной несущей (SC-FDMA), расширенное OFDM с безызбыточным расширением дискретного преобразования Фурье с синхропакетом (ZT-UW-DFT-S-OFDM), OFDM с синхропакетом (UW-OFDM), OFDM с фильтрацией блока ресурса, блок фильтров с несколькими несущими (FBMC) и т.п.

Как показано на фиг. 1A, система 100 связи может включать в себя модули 102a, 102b, 102c, 102d беспроводной передачи/приема (WTRU), сеть 104 радиодоступа (RAN), опорную сеть (CN) 106, коммутируемую телефонную сеть 108 общего пользования (PSTN), сеть 110 Интернет и другие сети 112, хотя следует понимать, что описанные варианты осуществления предполагают любое количество WTRU, базовых станций, сетей и/или сетевых элементов. Каждый из WTRU 102a, 102b, 102c, 102d может представлять собой устройство любого типа, выполненное с возможностью функционирования и/или взаимодействия в среде беспроводной связи. Например, WTRU 102a, 102b, 102c, 102d, любой из которых может называться станцией (STA), могут быть выполнены с возможностью передачи и/или приема радиосигналов и могут включать в себя оборудование пользователя (UE), мобильную станцию, стационарный или мобильный абонентский модуль, абонентский модуль, пейджер, сотовый телефон, карманный персональный компьютер (PDA), смартфон, ноутбук, нетбук, персональный компьютер, беспроводной датчик, точку доступа или устройство Mi-Fi, устройство Интернета физических объектов (IoT), часы или другие носимые устройства, устанавливаемый на голове дисплей (HMD), транспортное средство, беспилотный радиоуправляемый летательный аппарат, медицинское устройство и приложения (например, применяемые в дистанционной хирургии), промышленное устройство и приложения (например, роботизированные и/или другие беспроводные устройства, работающие в условиях промышленной и/или автоматизированной технологической цепочки), устройство, относящееся к бытовой электронике, устройство, работающее в коммерческой и/или промышленной беспроводной сети, и т.п. Любой из WTRU 102a, 102b, 102c и 102d можно взаимозаменяемо называть UE. Следует отметить, что в настоящей заявке термины «WTRU» и «STA» могут использоваться взаимозаменяемо, если не указано иное.

Системы 100 связи могут также включать в себя базовую станцию 114a и/или базовую станцию 114b. Каждая из базовых станций 114a, 114b может представлять собой устройство любого типа, выполненное с возможностью беспроводного взаимодействия с по меньшей мере одним из WTRU 102a, 102b, 102c, 102d для облегчения доступа к одной или более сетям связи, таким как CN 106, сеть Интернет 110 и/или другие сети 112. В качестве примера базовые станции 114a, 114b могут представлять собой базовую приемопередающую станцию (BTS), NodeB, eNode B (eNB), Home Node B, Home eNode B, станцию следующего поколения NodeB, такую как gNode B (gNB), станцию NodeB новой радиосети (NR), контроллер пункта связи, точку доступа (AP), беспроводной маршрутизатор и т.п. Хотя каждая из базовых станций 114a, 114b показана как отдельный элемент, следует понимать, что базовые станции 114a, 114b могут включать в себя любое количество взаимно соединенных базовых станций и/или сетевых элементов.

Базовая станция 114a может быть частью RAN 104, которая может также включать в себя другие базовые станции и/или сетевые элементы (не показаны), такие как контроллер базовой станции (BSC), контроллер радиосети (RNC), узлы ретранслятора и т.п. Базовая станция 114a и/или базовая станция 114b могут быть выполнены с возможностью передачи и/или приема радиосигналов на одной или более несущих частотах, которые могут называться сотами (не показаны). Эти частоты могут относиться к лицензированному спектру, нелицензированному спектру или к сочетанию лицензированного и нелицензированного спектров. Сота может обеспечивать покрытие для беспроводного сервиса в конкретной географической зоне, которая может быть относительно фиксированной или которая может изменяться со временем. Сота может быть дополнительно разделена на сектора соты. Например, сота, связанная с базовой станцией 114a, может быть разделена на три сектора. Таким образом, в одном варианте осуществления базовая станция 114a может включать в себя три приемопередатчика, т.е. по одному для каждого сектора соты. В варианте осуществления в базовой станции 114a может быть использована технология «множественный вход — множественный выход» (MIMO) и может быть задействовано множество приемопередатчиков для каждого сектора соты. Например, для передачи и/или приема сигналов в требуемых пространственных направлениях можно использовать формирование лучей.

Базовые станции 114a, 114b могут обмениваться данными с одним или более из WTRU 102a, 102b, 102c, 102d посредством радиоинтерфейса 116, который может представлять собой любую подходящую систему беспроводной связи (например, для передачи сигналов в радиочастотном (РЧ), микроволновом спектре, спектре сантиметровых волн, спектре микрометровых волн, инфракрасном (ИК), ультрафиолетовом (УФ) спектре, спектре видимого света и т.д.). Радиоинтерфейс 116 может быть установлен с использованием любой подходящей технологии радиодоступа (RAT).

Более конкретно, как указано выше, система 100 связи может представлять собой систему множественного доступа, и в ней можно использовать одну или более схем доступа к каналу, например CDMA, TDMA, FDMA, OFDMA, SC-FDMA и т.п. Например, в базовой станции 114a в RAN 104 и WTRU 102a, 102b, 102c может быть реализована технология радиосвязи, такая как сеть наземного радиодоступа (UTRA) для универсальной системы мобильной связи (UMTS), в которой может быть установлен радиоинтерфейс 116 с использованием широкополосного CDMA (WCDMA). WCDMA может включать в себя протоколы связи, такие как высокоскоростной пакетный доступ (HSPA) и/или усовершенствованный HSPA (HSPA+). Протокол HSPA может включать в себя высокоскоростной пакетный доступ по нисходящей (DL) линии связи (HSDPA) и/или высокоскоростной пакетный доступ по восходящей (UL) линии связи (HSUPA).

В варианте осуществления в базовой станции 114a и WTRU 102a, 102b, 102c может быть реализована такая технология радиосвязи, как усовершенствованная сеть наземного радиодоступа UMTS (E-UTRA), которая может устанавливать радиоинтерфейс 116 с использованием стандарта долгосрочного развития сетей связи (LTE), и/или LTE-Advanced (LTE-A), и/или LTE-Advanced Pro (LTE-A Pro).

В варианте осуществления в базовой станции 114a и WTRU 102a, 102b, 102c может быть реализована такая технология радиосвязи, как новая технология радиодоступа (NR), которая может устанавливать радиоинтерфейс 116 с использованием NR.

В варианте осуществления в базовой станции 114a и WTRU 102a, 102b, 102c может быть реализовано множество технологий радиодоступа. Например, в совокупности в базовой станции 114a и WTRU 102a, 102b, 102c могут быть реализованы технологии радиодоступа LTE и NR, например, с использованием принципов двойного подключения (DC). Таким образом, радиоинтерфейс, используемый WTRU 102a, 102b, 102c, может характеризоваться использованием множества типов технологий радиодоступа и/или передачами, отправляемыми на базовые станции/с базовых станций, множества типов (например, eNB и gNB).

В других вариантах осуществления в базовой станции 114a и WTRU 102a, 102b, 102c могут быть реализованы технологии радиосвязи, такие как IEEE 802.11 (т.е. WiFi), IEEE 802.16 (т.е. технология широкополосного доступа в микроволновом диапазоне (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, временный стандарт 2000 (IS-2000), временный стандарт 95 (IS-95), временный стандарт 856 (IS-856), глобальная система мобильной связи (GSM), развитие стандарта GSM с увеличенной скоростью передачи данных (EDGE), GSM EDGE (GERAN) и т.п.

Базовая станция 114b, показанная на фиг. 1A, может представлять собой, например, беспроводной маршрутизатор, станцию Home Node B, станцию Home eNode B или точку доступа, и в ней может быть использована любая подходящая RAT для облегчения обеспечения беспроводной связи в локализованной зоне, такой как коммерческое предприятие, жилое помещение, транспортное средство, учебное заведение, промышленный объект, воздушный коридор (например, для использования беспилотными радиоуправляемыми летательными аппаратами), проезжая часть и т.п. В одном варианте осуществления в базовой станции 114b и WTRU 102c, 102d может быть реализована технология радиосвязи, такая как IEEE 802.11, для создания беспроводной локальной сети (WLAN). В варианте осуществления в базовой станции 114b и WTRU 102c, 102d может быть реализована технология радиосвязи, такая как IEEE 802.15, для создания беспроводной персональной сети (WPAN). В еще одном варианте осуществления в базовой станции 114b и WTRU 102c, 102d можно использовать RAT на основе сот (например, WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR и т.п.) для создания пикосоты или фемтосоты. Как показано на фиг. 1A, базовая станция 114b может иметь прямое соединение с сетью Интернет 110. Таким образом, для базовой станции 114b может не требоваться доступа к сети Интернет 110 посредством CN 106.

RAN 104 может обмениваться данными с CN 106, которая может представлять собой сеть любого типа, выполненную с возможностью предоставления услуг передачи голосовой информации, данных, приложений и/или голосовой связи по протоколу IP (VoIP) на один или более из WTRU 102a, 102b, 102c, 102d. К данным могут предъявляться различные требования по качеству обслуживания (QoS), например различные требования по производительности, требования к задержке, требования к отказоустойчивости, требования к надежности, требования к скорости передачи данных, требования к мобильности и т.п. В сети CN 106 может быть обеспечено управление вызовами, услуги биллинга, услуги мобильной связи на основе местоположения, предварительно оплаченные вызовы, возможность связи с сетью Интернет, распределение видеосигналов и т.п. и/или реализованы функции высокоуровневой защиты, такие как аутентификация пользователей. Хотя на фиг. 1A это не показано, следует понимать, что RAN 104 и/или CN 106 могут прямо или косвенно обмениваться данными с другими RAN, которые используют такую же RAT, что и RAN 104, или другую RAT. Например, в дополнение к связи с RAN 104, в которой может быть использована технология радиосвязи NR, CN 106 может также осуществлять связь с другой RAN (не показана), использующей технологию радиосвязи GSM, UMTS, CDMA 2000, WiMAX, E-UTRA или WiFi.

CN 106 может также выступать в качестве шлюза для WTRU 102a, 102b, 102c, 102d для обеспечения доступа к сети PSTN 108, сети Интернет 110 и/или другим сетям 112. PSTN 108 может включать в себя телефонные сети с коммутацией каналов, которые предоставляют традиционные услуги телефонной связи (POTS). Интернет 110 может включать в себя глобальную систему взаимно соединенных компьютерных сетей и устройств, которые используют распространенные протоколы связи, такие как протокол управления передачей (TCP), протокол пользовательских дейтаграмм (UDP) и/или протокол Интернета (IP) в наборе протоколов Интернета TCP/IP. Сети 112 могут включать в себя проводные и/или беспроводные сети связи, которые принадлежат другим поставщикам услуг и/или управляются ими. Например, сети 112 могут включать в себя другую CN, соединенную с одной или более RAN, в которых можно использовать такую же RAT, как RAN 104, или другую RAT.

Некоторые или все из WTRU 102a, 102b, 102c, 102d в системе 100 связи могут включать в себя многорежимные возможности (например, WTRU 102a, 102b, 102c, 102d могут включать в себя множество приемопередатчиков для связи с разными беспроводными сетями по разным беспроводным линиям связи). Например, WTRU 102c, показанный на фиг. 1A, может быть выполнен с возможностью обмена данными с базовой станцией 114a, которая может использовать технологию радиосвязи на основе сот, а также с базовой станцией 114b, которая может использовать технологию радиосвязи IEEE 802.

На фиг. 1B представлена схема системы, иллюстрирующая пример WTRU 102. Как показано на фиг. 1B, WTRU 102 может включать в себя, помимо прочего, процессор 118, приемопередатчик 120, передающий/приемный элемент 122, динамик/микрофон 124, клавиатуру 126, дисплей/сенсорную панель 128, несъемное запоминающее устройство 130, съемное запоминающее устройство 132, источник 134 питания, набор 136 микросхем глобальной системы определения местоположения (GPS) и/или другие периферийные устройства 138. Следует понимать, что WTRU 102 может включать в себя любую подкомбинацию вышеперечисленных элементов и при этом соответствовать варианту осуществления.

Процессор 118 может представлять собой процессор общего назначения, процессор специального назначения, традиционный процессор, цифровой сигнальный процессор (DSP), множество микропроцессоров, один или более микропроцессоров, связанных с ядром DSP, контроллер, микроконтроллер, специализированные интегральные схемы (ASIC), программируемые пользователем вентильные матрицы (FPGA), интегральную схему (IC) любого другого типа, конечный автомат и т.п. Процессор 118 может выполнять кодирование сигналов, обработку данных, управление мощностью, обработку ввода/вывода и/или иметь любые другие функциональные возможности, необходимые WTRU 102 для функционирования в среде беспроводной связи. Процессор 118 может быть соединен с приемопередатчиком 120, который может быть соединен с передающим/приемным элементом 122. Хотя на фиг. 1B процессор 118 и приемопередатчик 120 показаны в виде отдельных компонентов, следует понимать, что процессор 118 и приемопередатчик 120 могут быть выполнены как единое целое и встроены в электронный блок или микросхему.

Передающий/приемный элемент 122 может быть выполнен с возможностью передачи сигналов на базовую станцию (например, базовую станцию 114a) или приема от нее сигналов по радиоинтерфейсу 116. Например, в одном варианте осуществления передающий/приемный элемент 122 может представлять собой антенну, выполненную с возможностью передачи и/или приема РЧ-сигналов. В варианте осуществления передающий/приемный элемент 122 может представлять собой излучатель/детектор, выполненный с возможностью передачи и/или приема, например, сигналов в ИК-, УФ-спектре или спектре видимого света. В еще одном варианте осуществления передающий/приемный элемент 122 может быть выполнен с возможностью передачи и/или приема сигналов как в РЧ-спектре, так и в спектре видимого света. Следует понимать, что передающий/приемный элемент 122 может быть выполнен с возможностью передачи и/или приема любой комбинации радиосигналов.

Хотя на фиг. 1B передающий/приемный элемент 122 показан в виде единственного элемента, WTRU 102 может включать в себя любое количество передающих/приемных элементов 122. Более конкретно, в WTRU 102 может быть использована технология MIMO. Таким образом, в одном варианте осуществления WTRU 102 может включать в себя два или более передающих/приемных элементов 122 (например, множество антенн) для передачи и приема радиосигналов по радиоинтерфейсу 116.

Приемопередатчик 120 может быть выполнен с возможностью модуляции сигналов, передаваемых посредством передающего/приемного элемента 122, а также демодуляции сигналов, принятых посредством передающего/приемного элемента 122. Как указано выше, WTRU 102 может иметь многорежимные возможности. Таким образом, приемопередатчик 120 может включать в себя множество приемопередатчиков, с помощью которых WTRU 102 получает возможность взаимодействия посредством множества RAT, таких как, например, NR и IEEE 802.11.

Процессор 118 WTRU 102 может быть соединен с динамиком/микрофоном 124, клавиатурой 126 и/или дисплеем/сенсорной панелью 128 (например, жидкокристаллическим дисплеем (LCD) или дисплеем на органических светодиодах (OLED)) и может принимать от них данные, вводимые пользователем. Процессор 118 может также выводить пользовательские данные на динамик/микрофон 124, клавиатуру 126 и/или дисплей/сенсорную панель 128. Кроме того, процессор 118 может иметь доступ к информации с подходящего запоминающего устройства любого типа, такого как несъемное запоминающее устройство 130 и/или съемное запоминающее устройство 132, и хранить на нем данные. Несъемное запоминающее устройство 130 может включать в себя оперативное запоминающее устройство (ОЗУ), постоянное запоминающее устройство (ПЗУ), жесткий диск или запоминающее устройство любого другого типа. Съемное запоминающее устройство 132 может включать в себя карту модуля идентификации абонента (SIM), карту памяти, защищенную цифровую карту памяти (SD) и т.п. В других вариантах осуществления процессор 118 может осуществлять доступ к информации с запоминающего устройства, которое физически размещено не в WTRU 102, а, например, на сервере или домашнем компьютере (не показан), и хранить на нем данные.

Процессор 118 может принимать питание от источника 134 питания и может быть выполнен с возможностью управления питанием и/или распределения питания на другие компоненты в WTRU 102. Источник 134 питания может представлять собой любое подходящее устройство для подачи питания на WTRU 102. Например, источник 134 питания может включать в себя одну или более сухих батарей (например, никель-кадмиевых (NiCd), никель-цинковых (NiZn), никель-металл-гидридных (NiMH), литий-ионных (Li-ion) и т.п.), солнечных элементов, топливных элементов и т.п.

Процессор 118 может также быть соединен с набором 136 микросхем GPS, который может быть выполнен с возможностью предоставления информации о местоположении (например, долготы и широты) относительно текущего местоположения WTRU 102. Дополнительно или вместо информации от набора 136 микросхем GPS модуль WTRU 102 может принимать информацию о местоположении по радиоинтерфейсу 116 от базовой станции (например, от базовых станций 114a, 114b) и/или определять свое местоположение на основании синхронизации сигналов, принимаемых от двух или более соседних базовых станций. Следует понимать, что WTRU 102 может получать информацию о местоположении посредством любого подходящего способа определения местоположения и при этом соответствовать варианту осуществления.

Процессор 118 может быть дополнительно соединен с другими периферийными устройствами 138, которые могут включать в себя один или более программных и/или аппаратных модулей, которые обеспечивают дополнительные признаки, функциональные возможности и/или возможности по установлению проводной или беспроводной связи. Например, периферийные устройства 138 могут включать в себя акселерометр, электронный компас, спутниковый приемопередатчик, цифровую камеру (для фото- и/или видеосъемки), порт универсальной последовательной шины (USB), вибрационное устройство, телевизионный приемопередатчик, беспроводную гарнитуру, модуль Bluetooth®, радиомодуль с частотной модуляцией (FM), цифровой музыкальный проигрыватель, мультимедийный проигрыватель, модуль для воспроизведения видеоигр, Интернет-браузер, устройство виртуальной реальности и/или дополненной реальности (VR/AR), трекер активности и т.п. Периферийные устройства 138 могут включать в себя один или более датчиков. Датчики могут представлять собой один или более из гироскопа, акселерометра, датчика Холла, магнитометра, датчика ориентации, бесконтактного датчика, датчика температуры, датчика времени; датчика географического положения, высотомера, датчика освещенности, датчика касания, магнитометра, барометра, датчика жестов, биометрического датчика, датчика влажности и т.п.

WTRU 102 может включать в себя полнодуплексное радиоустройство, в котором передача и прием некоторых или всех сигналов (например, связанных с конкретными подкадрами как для UL (например, для передачи), так и для DL (например, для приема)) могут осуществляться совместно и/или одновременно. Полнодуплексное радиоустройство может включать в себя блок управления помехами для снижения уровня и/или по существу устранения собственных помех с помощью либо аппаратного обеспечения (например, дросселя), либо обработки сигнала с помощью процессора (например, отдельного процессора (не показан) или процессора 118). В варианте осуществления WTRU 102 может включать в себя полудуплексное радиоустройство для передачи и приема некоторых или всех сигналов (например, связанных с конкретными подкадрами как для UL (например, для передачи), так и для DL (например, для приема)).

На фиг. 1C представлена схема системы, иллюстрирующая RAN 104 и CN 106 в соответствии с вариантом осуществления. Как отмечено выше, RAN 104 может использовать технологию радиосвязи E-UTRA для обмена данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 116. RAN 104 может также обмениваться данными с CN 106.

RAN 104 может включать в себя eNode-B 160a, 160b, 160c, хотя следует понимать, что сеть RAN 104 может включать в себя любое количество eNode-B и при этом соответствовать варианту осуществления. Каждая eNode-B 160a, 160b, 160c может включать в себя один или более приемопередатчиков для обмена данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 116. В одном варианте осуществления в eNode B 160a, 160b, 160c может быть реализована технология MIMO. Таким образом, в eNode-B 160a может, например, быть использовано множество антенн для передачи радиосигналов на WTRU 102a и/или приема радиосигналов от него.

Каждая eNode-B 160a, 160b, 160c может быть связана с конкретной сотой (не показана) и может быть выполнена с возможностью принятия решений по управлению радиоресурсами, решений по передаче обслуживания, диспетчеризации пользователей в UL и/или DL и т.п. Как показано на фиг. 1C, eNode-B 160a, 160b, 160c могут обмениваться данными друг с другом по интерфейсу X2.

CN 106, показанная на фиг. 1C, может включать в себя объект 162 управления мобильностью (MME), обслуживающий шлюз (SGW) 164 и шлюз 166 (PGW) сети с пакетной передачей данных (PDN). Хотя вышеперечисленные элементы показаны как часть CN 106, следует понимать, что любой из этих элементов может принадлежать субъекту, отличному от оператора CN, и/или может управляться таким субъектом.

MME 162 может быть подключен к каждой из eNode-B 162a, 162b, 162c в RAN 104 по интерфейсу S1 и может выступать в качестве узла управления. Например, MME 162 может отвечать за аутентификацию пользователей WTRU 102a, 102b, 102c, активацию/деактивацию канала, выбор конкретного обслуживающего шлюза во время начального соединения WTRU 102a, 102b, 102c и т.п. MME 162 может обеспечивать функцию плоскости управления для переключения между RAN 104 и другими RAN (не показаны), которые используют другие технологии радиосвязи, такие как GSM и/или WCDMA.

SGW 164 может быть подключен к каждой eNode B 160a, 160b, 160c в RAN 104 по интерфейсу S1. SGW 164 может по существу направлять и пересылать пакеты пользовательских данных на WTRU 102a, 102b, 102c и от них. SGW 164 может выполнять другие функции, например привязку плоскостей пользователя во время передачи обслуживания между базовыми станциями eNode B, запуск пейджинга, когда данные DL доступны для WTRU 102a, 102b, 102c, управление и хранение контекста WTRU 102a, 102b, 102c и т.п.

SGW 164 может быть подключен к PGW 166, который может предоставлять WTRU 102a, 102b, 102c доступ к сетям с коммутацией пакетов, таким как сеть Интернет 110, для облегчения обмена данными между WTRU 102a, 102b, 102c и устройствами с поддержкой IP.

CN 106 может облегчать обмен данными с другими сетями. Например, CN 106 может предоставлять WTRU 102a, 102b, 102c доступ к сетям с коммутацией каналов, таким как PSTN 108, для облегчения обмена данными между WTRU 102a, 102b, 102c и традиционными устройствами связи наземной линии связи. Например, CN 106 может включать в себя IP-шлюз (например, сервер мультимедийной IP-подсистемы (IMS)), который выступает в качестве интерфейса между CN 106 и PSTN 108, либо может обмениваться данными с ним. Кроме того, CN 106 может предоставлять WTRU 102a, 102b, 102c доступ к другим сетям 112, которые могут включать в себя другие проводные и/или беспроводные сети, которые принадлежат другим поставщикам услуг и/или управляются ими.

Хотя WTRU описан на фиг. 1A–1D как беспроводной терминал, предполагается, что в определенных типовых вариантах осуществления с таким терминалом может быть использован (например, временно или постоянно) проводной интерфейс связи с сетью связи.

В типовых вариантах осуществления другая сеть 112 может представлять собой WLAN.

WLAN в режиме базового набора служб (BSS) инфраструктуры может иметь точку доступа (АР) для BSS и одну или более станций (STA), связанных с АР. АР может иметь доступ к системе распределения (DS) или интерфейс с ней или же осуществлять связь по проводной/беспроводной сети другого типа, которая переносит трафик в BSS и/или из BSS. Трафик на станции STA, исходящий извне BSS, может поступать через AP и может быть доставлен на станции STA. Трафик, исходящий из станций STA к получателям вне BSS, может быть отправлен на АР для доставки соответствующим получателям. Трафик между станциями STA в пределах BSS может быть отправлен через АР, например, если STA-источник может отправлять трафик на АР, а АР может доставлять трафик STA-получателю. Трафик между STA в пределах BSS может считаться и/или называться одноранговым трафиком. Одноранговый трафик может быть передан между (например, непосредственно между) STA-источником и STA-получателем при установлении прямой линии связи (DLS). В определенных типовых вариантах осуществления DLS может использовать DLS 802.11e или туннелированное DLS 802.11z (TDLS). WLAN с использованием независимого BSS (IBSS) режима может не иметь АР, а STA (например, каждая STA) в пределах или с использованием IBSS могут осуществлять связь непосредственно друг с другом. В настоящем документе режим IBSS может иногда называться режимом «динамической» связи.

При использовании режима работы инфраструктуры 802.11ac или аналогичного режима работы AP может передавать маяк по фиксированному каналу, такому как первичный канал. Первичный канал может иметь фиксированную ширину (например, ширину полосы пропускания 20 МГц) или динамически установленную ширину. Первичный канал может представлять собой рабочий канал BSS и может быть использован множеством STA для установления соединения с АР. В определенных типовых вариантах осуществления может быть реализован множественный доступ с контролем несущей и предотвращением коллизий (CSMA/CA), например, в системах 802.11. STA (например, каждая STA), включая АР, могут обнаруживать первичный канал для CSMA/CA. При распознавании/обнаружении и/или определении занятости первичного канала конкретной STA эта конкретная STA может отключаться. Одна STA (например, только одна станция) может осуществлять передачу в любой конкретный момент времени в данном BSS.

Для осуществления связи STA с высокой пропускной способностью (HT) может быть использован канал шириной 40 МГц, например путем объединения первичного канала 20 МГц со смежным или несмежным каналом 20 МГц с образованием канала шириной 40 МГц.

STA со сверхвысокой пропускной способностью (VHT) могут поддерживать каналы шириной 20 МГц, 40 МГц, 80 МГц и/или 160 МГц. Каналы 40 МГц и/или 80 МГц могут быть образованы путем объединения сплошных каналов 20 МГц. Канал 160 МГц может быть образован путем объединения 8 сплошных каналов 20 МГц или путем объединения двух несплошных каналов 80 МГц, которые могут называться конфигурацией 80 + 80. Для конфигурации 80 + 80 данные после кодирования канала могут проходить через анализатор сегментов, который может разделять данные на два потока. Обработку по методу обратного быстрого преобразования Фурье (IFFT) и обработку во временной области можно выполнять отдельно для каждого потока. Потоки могут быть сопоставлены с двумя каналами 80 МГц, а данные могут быть переданы посредством передающей STA. В приемнике принимающей STA вышеописанная операция для конфигурации 80 + 80 может быть инвертирована, а объединенные данные могут быть отправлены на устройство управления доступом к среде передачи данных (MAC).

Протоколы 802.11af и 802.11ah поддерживают режимы работы на частотах до 1 ГГц. В 802.11af и 802.11ah значения ширины полосы пропускания канала и несущие уменьшены по отношению к используемым в 802.11n и 802.11ac. Протокол 802.11af поддерживает значения ширины полосы пропускания 5 МГц, 10 МГц и 20 МГц в неиспользуемой части частотного спектра телевидения (TVWS), а протокол 802.11ah поддерживает значения ширины полосы пропускания 1 МГц, 2 МГц, 4 МГц, 8 МГц и 16 МГц с использованием спектра, отличного от TVWS. Согласно типовому варианту осуществления 802.11ah может поддерживать управление с измерением/межмашинные связи (MTC), например устройства межмашинной связи (MTC) в макрозоне покрытия. Устройства MTC могут обладать определенными возможностями, например ограниченными возможностями, включая поддержку (например, поддержку только) определенных и/или ограниченных значений ширины полосы пропускания. Устройства МТС могут включать в себя батарею, имеющую срок службы батареи, превышающий пороговое значение (например, для обеспечения очень длительного срока службы батареи).

Системы WLAN, которые могут поддерживать множество каналов и значений ширины полосы пропускания канала, такие как 802.11n, 802.11ac, 802.11af и 802.11ah, включают в себя канал, который может быть назначен в качестве первичного канала. Первичный канал может иметь ширину полосы пропускания, равную наибольшей общей рабочей ширине полосы пропускания, поддерживаемой всеми STA в BSS. Ширина полосы пропускания первичного канала может быть установлена и/или ограничена STA из числа всех STA, работающих в BSS, которая поддерживает режим работы с наименьшей шириной полосы пропускания. В примере 802.11ah первичный канал может иметь ширину 1 МГц для STA (например, устройств типа MTC), которые поддерживают (например, поддерживают только) режим 1 МГц, даже если AP и другие STA в BSS поддерживают 2 МГц, 4 МГц, 8 МГц, 16 МГц и/или режимы работы с другими значениями ширины полосы пропускания канала. Параметры обнаружения несущей и/или вектора выделения сети (NAV) могут зависеть от состояния первичного канала. Если первичный канал занят, например, из-за STA (которая поддерживает только режим работы 1 МГц), осуществляющей передачу на AP, все доступные полосы частот могут считаться занятыми, даже если большинство доступных полос частот остаются незанятыми.

В Соединенных Штатах Америки доступные полосы частот, которые могут быть использованы 802.11ah, находятся в диапазоне от 902 МГц до 928 МГц. Доступные полосы частот в Корее — от 917,5 МГц до 923,5 МГц. Доступные полосы частот в Японии — от 916,5 МГц до 927,5 МГц. Общая ширина полосы пропускания, доступная для 802.11ah, составляет от 6 МГц до 26 МГц в зависимости от кода страны.

На фиг. 1D представлена схема системы, иллюстрирующая RAN 104 и CN 106 в соответствии с вариантом осуществления. Как отмечено выше, RAN 104 может использовать технологию радиосвязи NR для обмена данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 116. RAN 104 может также обмениваться данными с CN 106.

RAN 104 может включать в себя gNB 180a, 180b, 180c, хотя следует понимать, что RAN 104 может включать в себя любое количество gNB и при этом соответствовать варианту осуществления. Каждая gNB 180a, 180b, 180c может включать в себя один или более приемопередатчиков для обмена данными с WTRU 102a, 102b, 102c по радиоинтерфейсу 116. В одном варианте осуществления в gNB 180a, 180b, 180c может быть реализована технология MIMO. Например, gNB 180a, 108b могут использовать формирование лучей для передачи сигналов на gNB 180a, 180b, 180c и/или приема сигналов от них. Таким образом, gNB 180a, например, может использовать множество антенн для передачи радиосигналов на WTRU 102a и/или приема радиосигналов от него. В варианте осуществления на gNB 180a, 180b, 180c может быть реализована технология агрегирования несущих. Например, gNB 180a может передавать на WTRU 102a множество несущих составляющих (не показаны). Подмножество этих несущих составляющих может относиться к нелицензированному спектру, тогда как остальные несущие составляющие могут относиться к лицензированному спектру. В варианте осуществления на gNB 180a, 180b, 180c может быть реализована технология координированной многоточечной передачи (CoMP). Например, WTRU 102a может принимать координированные передачи от gNB 180a и gNB 180b (и/или gNB 180c).

WTRU 102a, 102b, 102c могут обмениваться данными с gNB 180a, 180b, 180c с использованием передач, связанных с масштабируемой численной величиной. Например, разнос символов OFDM и/или разнос поднесущих OFDM может различаться для разных передач, разных сот и/или разных участков спектра беспроводной передачи. WTRU 102a, 102b, 102c могут обмениваться данными с gNB 180a, 180b, 180c с использованием подкадра или временных интервалов передачи (TTI) с различной или масштабируемой длительностью (например, содержащих различное количество символов OFDM и/или имеющих постоянные различные длительности абсолютного времени).

gNB 180a, 180b, 180c могут быть выполнены с возможностью обмена данными с WTRU 102a, 102b, 102c в автономной конфигурации и/или в неавтономной конфигурации. В автономной конфигурации WTRU 102a, 102b, 102c могут обмениваться данными с gNB 180a, 180b, 180c без одновременного доступа к другим RAN (например, таким как eNode-B 160a, 160b, 160c). В автономной конфигурации WTRU 102a, 102b, 102c могут использовать одну или более gNB 180a, 180b, 180c в качестве якорной точки мобильности. В автономной конфигурации WTRU 102a, 102b, 102c могут обмениваться данными с gNB 180a, 180b, 180c с использованием сигналов в нелицензированной полосе. В неавтономной конфигурации WTRU 102a, 102b, 102c могут обмениваться данными/устанавливать соединение с gNB 180a, 180b, 180c и одновременно обмениваться данными/устанавливать соединение с другой RAN, такой как eNode-B 160a, 160b, 160c. Например, в WTRU 102a, 102b, 102c могут быть реализованы принципы двойного соединения (DC) для по существу одновременного обмена данными с одной или более gNB 180a, 180b, 180c и одной или более eNode-B 160a, 160b, 160c. В неавтономной конфигурации eNode-B 160a, 160b, 160c могут выступать в качестве якорной точки мобильности для WTRU 102a, 102b, 102c, а gNB 180a, 180b, 180c могут обеспечивать дополнительное покрытие и/или пропускную способность для обслуживания WTRU 102a, 102b, 102с.

Каждая из gNB 180a, 180b, 180c может быть связана с конкретной сотой (не показана) и может быть выполнена с возможностью принятия решений об управлении радиоресурсом, решений о передаче обслуживания, диспетчеризации пользователей в UL и/или DL, поддержке сегментирования сети, DC, взаимодействии между NR и E-UTRA, маршрутизации данных плоскости пользователя в функциональный блок 184a, 184b плоскости пользователя (UPF), маршрутизации информации плоскости управления в функциональный блок 182a, 182b управления доступом и мобильностью (AMF) и т.п. Как показано на фиг. 1D, gNB 180a, 180b, 180c могут обмениваться данными друг с другом по интерфейсу Xn.

CN 106, показанная на фиг. 1D, может включать в себя по меньшей мере один AMF 182a, 182b, по меньшей мере один UPF 184a, 184b, по меньшей мере один функциональный блок 183a, 183b управления сеансом (SMF) и, возможно, сеть 185a, 185b передачи данных (DN). Хотя вышеперечисленные элементы показаны как часть CN 106, следует понимать, что любой из этих элементов может принадлежать субъекту, отличному от оператора CN, и/или может управляться таким субъектом.

AMF 182a, 182b могут быть подключены к одной или более из gNB 180a, 180b, 180c в RAN 104 по интерфейсу N2 и могут выступать в качестве узла управления. Например, AMF 182a, 182b могут отвечать за аутентификацию пользователей WTRU 102a, 102b, 102c, поддержку сегментирования сети (например, обработку разных сеансов блока данных протокола (PDU) с разными требованиями), выбор конкретного SMF 183a, 183b, управление зоной регистрации, прекращение сигнализации слоя без доступа (NAS), управление мобильностью и т.п. Сегментирование сети может быть использовано в AMF 182a, 182b для настройки поддержки CN для WTRU 102a, 102b, 102c на основании типов сервисов, используемых WTRU 102a, 102b, 102c. Например, для разных вариантов использования могут быть установлены разные сетевые сегменты, например сервисы, основанные на доступе к связи повышенной надежности с малым временем задержки (URLLC), сервисы, основанные на доступе к усовершенствованной широкополосной сети мобильной связи (eMBB), сервисы для доступа к MTC и т.п. AMF 182a, 182b может обеспечивать функцию плоскости управления для переключения между RAN 104 и другими RAN (не показаны), которые используют другие технологии радиосвязи, такие как LTE, LTE-A, LTE-A Pro, и/или технологии доступа, отличные от 3GPP, такие как WiFi.

SMF 183a, 183b может быть подключен к AMF 182a, 182b в CN 106 по интерфейсу N11. SMF 183a, 183b может также быть подключен к UPF 184a, 184b в CN 106 по интерфейсу N4. SMF 183a, 183b могут выбирать UPF 184a, 184b и управлять ими, а также конфигурировать маршрутизацию трафика с помощью UPF 184a, 184b. SMF 183a, 183b могут выполнять другие функции, такие как управление IP-адресом UE и его выделение, управление сеансами PDU, управление реализацией политики и QoS, предоставление уведомлений о данных DL и т.п. Тип сеанса PDU может быть основан на IP, не основан на IP, основан на Ethernet и т.п.

UPF 184a, 184b могут быть подключены к одной или более gNB 180a, 180b, 180c в RAN 104 по интерфейсу N3, который может предоставлять WTRU 102a, 102b, 102c доступ к сетям с коммутацией пакетов, таким как сеть Интернет 110, для облегчения обмена данными между WTRU 102a, 102b, 102c и устройствами с поддержкой протокола IP. UPF 184, 184b могут выполнять другие функции, такие как маршрутизация и передача пакетов, применение политик в плоскости пользователя, поддержка многоканальных сеансов PDU, обработка QoS в плоскости пользователя, буферизация пакетов DL, привязка для обеспечения мобильности и т.п.

CN 106 может облегчать обмен данными с другими сетями. Например, CN 106 может включать в себя IP-шлюз (например, сервер мультимедийной IP-подсистемы (IMS)), который выступает в качестве интерфейса между CN 106 и PSTN 108, либо может обмениваться данными с ним. Кроме того, CN 106 может предоставлять WTRU 102a, 102b, 102c доступ к другим сетям 112, которые могут включать в себя другие проводные и/или беспроводные сети, которые принадлежат другим поставщикам услуг и/или управляются ими. В одном варианте осуществления WTRU 102a, 102b, 102c могут быть подключены к локальной DN 185a, 185b с помощью UPF 184a, 184b по интерфейсу N3 к UPF 184a, 184b и интерфейсу N6 между UPF 184a, 184b и DN 185a, 185b.

С учетом фиг. 1A–1D и соответствующих описаний фиг. 1A–1D одна или более или все из функций, описанных в настоящем документе в связи с одним или более из: WTRU 102a–d, базовых станций 114а–b, eNode-B 160a–c, MME 162, SGW 164, PGW 166, gNB 180a–c, AMF 182a–b, UPF 184a–b, SMF 183a–b, DN 185a–b и/или любого (-ых) другого (-их) устройства (устройств), описанного (-ых) в настоящем документе, могут быть реализованы одним или более устройствами эмуляции (не показаны). Устройства эмуляции могут представлять собой одно или более устройств, выполненных с возможностью эмуляции одной или более или всех функций, описанных в настоящем документе. Например, устройства эмуляции можно применять для испытания других устройств и/или для моделирования функций сети и/или WTRU.

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

Одно или более устройств эмуляции могут выполнять одну или более функций, включая все функции, и при этом не быть реализованными/развернутыми в качестве части проводной и/или беспроводной сети связи. Например, устройства эмуляции можно использовать в сценарии испытания в испытательной лаборатории и/или в неразвернутой (например, испытательной) проводной и/или беспроводной сети связи для проведения испытания одного или более компонентов. Одно или более устройств эмуляции могут представлять собой испытательное оборудование. Для передачи и/или приема данных в устройствах эмуляции можно использовать прямое РЧ-соединение и/или беспроводные связи посредством РЧ-схемы (которая может, например, включать в себя одну или более антенн).

Была создана Исследовательская группа (SG) по высокопроизводительным сетям WLAN (HEW) IEEE 802.11 для изучения объема и цели возможного будущего изменения, направленного на повышение качества обслуживания всех пользователей для широкого спектра пользователей беспроводных сетей во многих сценариях использования, включая сценарии повышенной плотности в полосе 2,4 ГГц, 5 ГГц и 6 ГГц. В настоящее время HEW SG рассматривает новые варианты использования, которые поддерживают режимы плотного развертывания AP и STA, а также связанные технологии управления радиоресурсами (RRM). К числу возможных применений HEW относятся новые сценарии использования, такие как доставка данных для мероприятий на стадионах, сценарии с высокой плотностью пользователей, например на железнодорожных станциях, в корпоративных/розничных средах, а также свидетельства в пользу усиления зависимости от доставки видеоматериалов и беспроводной связи в медицинских учреждениях. Совет по стандартам IEEE утвердил рабочую группу (TG) по IEEE 802.11ax на основе результатов, полученных HEW SG.

В некоторых докладах на совещаниях по стандарту TGax было сообщено, что измеряемый трафик для различных приложений больше возможен в коротких пакетах и что есть сетевые приложения, которые также могут генерировать короткие пакеты. К этим приложениям относятся: виртуальный офис; подтверждение TPC; подтверждение передачи видеопотока; устройства/контроллеры (например, мыши, клавиатуры, игровые манипуляторы и т.д.); доступ (например, пробный запрос/ответ); выбор сети (например, пробные запросы, протокол запроса доступа к сети (ANQP)); и/или кадры сетевого управления/контроля. Во многих докладах по 802.11ax было предложено внедрять многопользовательские функции (MU), включающие в себя OFDMA восходящей (UL) и нисходящей (DL) линии связи, а также UL и DL MU-MIMO. В 802.11ax и других протоколах может быть использовано проектирование и определение механизма мультиплексирования произвольного доступа UL для различных целей.

Предложения TGax относительно проблем доступа к среде передачи данных в диапазоне 6 ГГц включают использование инициируемого или запланированного доступа к среде передачи данных только в диапазоне 6 ГГц и/или ограничение активного сканирования и планирования усовершенствованного распределенного доступа к каналу (EDCA) в качестве доступа к среде передачи данных в диапазоне 6 ГГц.

TG IEEE 802.11ba была создана для определения изменений физического уровня (PHY) и управления доступом к среде передачи данных (MAC), направленных на улучшение работы с низким энергопотреблением устройств 802.11. Изменения MAC и PHY могут способствовать использованию пробуждающих радиоустройств (WUR). Ожидаемые рабочие диапазоны WUR включают в себя 2,4 ГГц, 5 ГГц и могут быть расширены до поддиапазона 1 ГГц. WUR может функционировать как дополнительный радиомодуль основного радиоустройства (PCR), используемый для передачи обычных пакетов 802.11. PCR также может называться основным радиоустройством. WUR может передавать пакеты, содержащие (только) информацию управления, и потребляемая активным приемником мощность может составлять менее одного милливатта. Прием пробуждающего пакета WUR может привести к выводу основного радиоустройства (PCR) из спящего режима. В одном примере WUR может иметь диапазон, по меньшей мере равный диапазону основного радиоустройства, работающего в диапазоне полезной нагрузки, равном по меньшей мере 20 МГц.

STA с AP и без AP могут содержать WUR в качестве дополнительного радиомодуля. Примеры вариантов использования WUR включают: устройства интернета физических объектов (IoT); низкое энергопотребление для смартфонов; сценарий уведомления о быстром сообщении/входящем вызове; быстрый запрос состояния/отчет, сценарий изменения конфигурации; и/или сценарий быстрого отчета об аварии/критическом событии.

TG IEEE 802.11bc была создана для определения изменений MAC применительно к усовершенствованной услуге широковещательной передачи (eBCS) для устройств 802.11. Изменение IEEE 802.11bc не должно влиять на спецификации IEEE 802.11 PHY. Сервис eBCS может существовать в направлении DL от AP к STA без AP или может существовать в направлении UL от STA датчика без АР. eBCS может предоставляться станциям STA, которые связаны или не связаны с конкретной AP. Можно ожидать, что AP будет поддерживать до 3000 STA без AP с сервисом eBCS. Кроме того, может существовать класс недорогих STA без AP, которые получают сервис eBCS и могут не иметь возможности передавать данные напрямую на AP. Примеры использования eBCS могут включать: видеотрансляцию со стадиона; автомобильное вещание; широковещательная передача данных с датчиков восходящей линии связи; музейная информация и многоязычное вещание; и/или широковещательная передача информации и контента из источников событий.

При внутрикадровом кодировании для широковещательных или других каналов содержимое передаваемого кадра может быть получено из единственного набора кодированных битов. При межкадровом кодировании содержимое переданного кадра может быть получено из множества наборов закодированных битов, которые обычно передаются в отдельных кадрах, но генерируются (например, с использованием линейного кодирования с дополнительными приращениями) для формирования новых подкадров, которые могут передаваться для содействия декодированию. Это позволяет передавать широковещательный сигнал всем принятым WTRU (STA) с повышенной надежностью с прогрессивной формой согласования скорости передачи, чтобы обеспечивать плавное изменение скорости кода. Используемый кодер обычно представляет собой код, совместимый со скоростью, так что для любых двух скоростей кода R > R', причем скорость кадров R' представляет собой конкатенацию скорости кадров R и дополнительные биты избыточности.

Для устройств 802.11ba согласовано сканирование WUR. При сканировании WUR AP может отправлять кадры обнаружения WUR, содержащие информацию о себе и своем BSS. WTRU, которые поддерживают WUR, могут сканировать кадры обнаружения WUR, чтобы обнаруживать подходящие AP и BSS для связи. Тем не менее примитивы объекта управления уровня MAC (MLME) могут нуждаться в определении для WTRU, чтобы начать сканирование WUR и/или передать собранную информацию о принятых кадрах обнаружения WUR на более высокие уровни. Соответствующие примитивы MLME могут быть определены так, чтобы WTRU могли управлять процессом сканирования WUR, а также передавать информацию о принятых кадрах обнаружения WUR, собранную во время процесса сканирования WUR, на более высокий уровень. Следует отметить, что термины сканирование WUR и процесс сканирования WUR могут использоваться взаимозаменяемо, если не указано иное.

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

Способ 200 в соответствии с вариантом осуществления настоящей заявки будет описан со ссылкой на фиг. 2А ниже. На фиг. 2A показана блок-схема способа 200. Как показано на фиг. 2A, способ 200 может включать: на этапе 201 генерирование объектом управления станцией (SME) примитива запроса, обеспечивающего процесс сканирования пробуждающих радиоустройств (WUR) для кадров обнаружения WUR, передаваемых одной или более точками доступа (AP), причем примитив запроса содержит множество первых параметров; на этапе 202 выполнение процесса сканирования WUR на основе множества первых параметров; на этапе 203 генерирование на уровне управления доступом к среде передачи данных (MAC) по меньшей мере одного примитива подтверждения на основе результата процесса сканирования WUR и по меньшей мере части множества первых параметров; и на этапе 204 передачу от уровня MAC на SME по меньшей мере одного примитива подтверждения.

Соответственно, WTRU в соответствии с вариантом осуществления настоящей заявки может содержать: процессор, выполненный с возможностью генерирования примитива запроса, обеспечивающего процесс сканирования пробуждающих радиоустройств (WRU) для кадров обнаружения WUR, передаваемых одной или более точками доступа (AP), причем примитив запроса содержит множество первых параметров; выполнения процесса сканирования WUR на основе множества первых параметров; генерирования на уровне MAC по меньшей мере одного примитива подтверждения на основе результата процесса сканирования WUR и по меньшей мере части множества первых параметров; и передачи от уровня MAC на SME по меньшей мере одного примитива подтверждения.

В приведенном ниже описании будет подробно описан способ на этапе 201.

Примитив запроса может быть примитивом MLME, который может быть определен и использован для сканирования WUR. В одном варианте осуществления примитив запроса может быть примитивом MLME-WURSCAN.Request. Например, сканирование WUR может быть инициировано примитивом MLME, таким как примитив MLME-WURSCAN.Request. Этот примитив MLME может запрашивать опрос потенциальных BSS посредством кадров обнаружения WUR, которые WTRU может позже выбрать для попытки соединения. Следует отметить, что в настоящей заявке термины «примитив MLME-WURSCAN.Request», «MLME-WURSCAN.Request» и «примитив запроса» могут использоваться взаимозаменяемо, если не указано иное. Эти параметры в примитиве запроса (например, примитиве MLME-WURSCAN.Request) будут описаны ниже со ссылкой на подробные описания вариантов осуществления.

В другом варианте осуществления примитив запроса может быть примитивом MLME-SCAN.Request или частью примитива MLME-SCAN.Request. Параметры в примитиве MLME-SCAN.Request могут быть аналогичны параметрам в примитиве MLME-WURSCAN.Request, а параметры в примитиве MLME-SCAN.Request будут дополнительно описаны ниже. В настоящей заявке термины «примитив MLME-SCAN.Request», «MLME-SCAN.Request» и «примитив запроса» могут использоваться взаимозаменяемо, если не указано иное. Эти параметры в примитиве запроса (например, примитиве MLME-WURSCAN.Request) будут описаны ниже со ссылкой на подробные описания вариантов осуществления.

В одном варианте осуществления примитив запроса может быть сгенерирован объектом управления станцией (SME). Например, примитив MLME-WURSCAN.request может быть сгенерирован SME для WTRU, чтобы определить, используя свое WUR или режим WUR с низким энергопотреблением, сканировать кадры обнаружения WUR, чтобы определить, есть ли другие BSS, к которым можно присоединиться. В одном варианте осуществления примитив запроса может быть сгенерирован процессором.

Процесс сканирования пробуждающих радиоустройств (WUR) для кадров обнаружения WUR, передаваемых одной или более AP, представляет собой процесс сканирования WTRU, направленный на сканирование и, таким образом, обнаружение подходящих AP и BSS для связи. WTRU будут сканировать и обнаруживать кадры обнаружения WUR, передаваемые от AP. Кадр обнаружения WUR может содержать различные поля, такие как SSID, сжатый SSID, сжатый BSSID, информацию о канале и т.д.

Примитив запроса может содержать множество первых параметров. Множество первых параметров может содержать по меньшей мере один из идентификатора базового набора служб (BSSID), BSSIDList, идентификатора набора служб (SSID), SSIDList, CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MinDiscoveryChannelTime, MaxDiscoveryChannelTime, ReceivedPowerThreshod, MaxScanningTime, WURScanningReportingPeriod (или WURScanningReportingTime), WURScanningMode, WURScanningReportingOption или RequestWURresult. В следующей части будут поочередно описаны вышеупомянутые параметры.

BSSID может указывать BSSID требуемой AP или требуемого BSS. В одном варианте осуществления BSSID может идентифицировать базовые наборы служб, которые представляют собой 48-битные метки и соответствуют соглашениям MAC-48. BSSID может быть подстановочным BSSID (например, ff:ff:ff:ff:ff:ff). В одном варианте осуществления в примитиве запроса может быть только один BSSID. В другом варианте осуществления в примитиве запроса может быть множество BSSID. Один или множество BSSID могут быть включены в список BSSIDList. Другими словами, BSSIDList может содержать информацию об одном или более BSSID. Например, BSSIDList может быть списком, содержащим множество BSSID, каждый из которых может указывать требуемый BSS или AP. Хотя некоторые примеры BSSID и BSSIDList были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любой вариант вышеупомянутых вариантов осуществления BSSID и BSSIDList также может быть применен в этом способе и WTRU в соответствии с настоящей заявкой, если они могут помочь реализовать принцип настоящей заявки.

SSID может быть идентификатором набора служб требуемой AP, BSS или SS. То есть SSID может указывать набор служб, к которому WTRU может требоваться подключение. SSID может быть подстановочным SSID. В одном варианте осуществления в примитиве запроса может быть только один SSID. В другом варианте осуществления в примитиве запроса может быть множество SSID. Один или множество SSID могут быть включены в список SSIDList. Другими словами, список SSIDList может содержать информацию об одном или более SSID требуемой АР или BSS. Например, SSIDList может быть списком, содержащим множество SSID, каждый из которых может указывать требуемый набор служб AP или BSS. Хотя некоторые примеры SSID и SSIDList были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любой вариант вышеупомянутых вариантов осуществления SSID и SSIDList также может быть применен в этом способе и WTRU в соответствии с настоящей заявкой, если они могут помочь реализовать принцип настоящей заявки.

CompressedBSSID может указывать сжатый BSSID требуемой AP или требуемого BSS, с которым WTRU может потребоваться установить связь. В одном варианте осуществления CompressedBSSID может быть частичным BSSID. CompressedBSSID может быть связан с подстановочным BSSID. Ассоциированный CompressedBSSID может быть вычислен на основе предоставленных BSSID. В одном варианте осуществления в примитиве запроса может быть только один CompressedBSSID. В другом варианте осуществления в примитиве запроса может быть множество CompressedBSSID. Один или множество CompressedBSSID могут быть включены в CompressedBSSIDList. Другими словами, CompressedBSSIDList может содержать один или более сжатых BSSID требуемых AP или BSS. Например, CompressedBSSIDList может быть списком, содержащим множество сжатых BSSID, каждый из которых может указывать требуемый BSS или AP. Хотя некоторые примеры CompressedBSSID и CompressedBSSIDList были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любой вариант вышеупомянутых вариантов осуществления CompressedBSSID и CompressedBSSIDList также может быть применен в этом способе и WTRU в соответствии с настоящей заявкой, если они могут помочь реализовать принцип настоящей заявки.

DiscoveryChannel может указывать канал или канал WUR, на котором кадры обнаружения (например, кадры обнаружения WUR) могут быть просканированы в процессе сканирования WRU. В одном варианте осуществления в примитиве запроса может быть только один DiscoveryChannel. То есть кадры обнаружения могут быть просканированы на конкретном канале, указанном этим DiscoveryChannel. В другом варианте осуществления в примитиве запроса может быть множество DiscoveryChannel. То есть кадры обнаружения могут быть просканированы на множестве каналов, указанных этими DiscoveryChannel. Один или множество DiscoveryChannel могут быть включены в DiscoveryChannelList. Другими словами, DiscoveryChannelList может содержать информацию об одном или более DiscoveryChannel. Например, DiscoveryChannelList может быть списком, содержащим множество каналов DiscoveryChannel, каждый из которых может указывать канал или канал WUR, на котором кадры обнаружения (например, кадры обнаружения WUR) могут быть просканированы для обнаружения требуемых AP или BSS. Если примитив MLME-WURSCAN.request включает в себя один или более WURDiscoveryChannel или WURDiscoveryChannelList, то WTRU может настраиваться только на эти каналы обнаружения WUR для сканирования кадров обнаружения WUR. Хотя некоторые примеры DiscoveryChannel и DiscoveryChannelList были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любой вариант вышеупомянутых вариантов осуществления DiscoveryChannel и DiscoveryChannelList также может быть применен в этом способе и WTRU в соответствии с настоящей заявкой, если они могут помочь реализовать принцип настоящей заявки. Следует отметить, что термины «канал», «канал WUR» и «канал обнаружения» могут использоваться взаимозаменяемо, если не указано иное.

MinDiscoveryChannelTime может указывать минимальное время в единицах времени (TU) или других единицах для выполнения WTRU сканирования WUR на каждом из каналов, указанных одним или более DiscoveryChannel в DiscoveryChannelList. MinDiscoveryChannelTime может быть определено на основе периодов обнаружения WUR требуемых AP, BSS или SS. Периоды обнаружения WUR могут быть заранее определены или получены по радиоканалу от одной или более АР. Хотя MinDiscoveryChannelTime и его предпочтительный вариант осуществления были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любое доступное значение MinDiscoveryChannelTime также может быть применено в этом способе и WTRU в соответствии с настоящей заявкой, если оно может помочь реализовать принцип настоящей заявки.

MaxDiscoveryChannelTime может указывать максимальное время в TU или других единицах для WTRU для выполнения WTRU сканирования WUR на каждом из каналов, указанных одним или более DiscoveryChannel в DiscoveryChannelList. MaxDiscoveryChannelTime может быть определено на основе периодов обнаружения WUR требуемых AP, BSS или SS. Периоды обнаружения WUR могут быть заранее определены или получены по радиоканалу от одной или более АР. Хотя MaxDiscoveryChannelTime и его предпочтительные варианты осуществления были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любое доступное значение MaxDiscoveryChannelTime также может быть применено в этом способе и WTRU в соответствии с настоящей заявкой, если оно может помочь реализовать принцип настоящей заявки.

ReceivedPowerThreshold может указывать порог принятой мощности, выше которого обрабатывается (-ются) кадр (-ы) обнаружения (например, кадры обнаружения WUR). Таким образом, в процессе сканирования WUR может (могут) обрабатываться только кадр (-ы) обнаружения, принимаемая мощность которого (-ых) превышает значение ReceivedPowerThreshold. Кадр (-ы) обнаружения, принимаемая мощность которого (-ых) ниже, чем ReceivedPowerThreshold, может (могут) быть проигнорирован (-ы) в процессе сканирования WUR. В одном варианте осуществления ReceivedPowerThreshold может быть определен с помощью индикатора мощности канала приема (RCPI), индикатора мощности принятого сигнала (RSSI), отношения сигнал/шум (SNR) и/или отношения сигнал/помеха + шум (SINR). Хотя ReceivedPowerThreshold и его предпочтительные варианты осуществления были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любое доступное значение ReceivedPowerThreshold также может быть применено в этом способе и WTRU в соответствии с настоящей заявкой, если оно может помочь реализовать принцип настоящей заявки.

MaxWURScanningTime может указывать максимальное время в TU или других единицах для выполнения WTRU процесса сканирования WUR. Хотя MaxWURScanningTime и его предпочтительные варианты осуществления были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любое доступное значение MaxWURScanningTime также может быть применено в этом способе и WTRU в соответствии с настоящей заявкой, если оно может помочь реализовать принцип настоящей заявки.

WURScanningReportingPeriod (или WURScanningReportingTime) может указывать время или период, в который могут быть предоставлены результаты процесса сканирования WUR (например, с помощью примитива MLME-WURScanning.confirm). Хотя WURScanningReportingPeriod и его предпочтительные варианты осуществления были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любое доступное значение WURScanningReportingPeriod также может быть применено в этом способе и WTRU в соответствии с настоящей заявкой, если оно может помочь реализовать принцип настоящей заявки.

WURScanningMode может указывать режим сканирования WUR. Например, значениями WURScanningMode могут быть: «фоновый», «одновременно с обычным сканированием», «только сканирование WUR» и т.д. Другими словами, режим сканирования WUR, обозначенный WURScanningMode, может быть «фоновым», «одновременным с обычным сканированием», «только сканированием WUR» и т.д. Вышеупомянутый режим сканирования WUR будет дополнительно описан ниже со ссылкой на подробные варианты осуществления. Хотя WURScanningMode и примеры его значений были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любое доступное значение WURScanningMode также может быть применено в этом способе и WTRU в соответствии с настоящей заявкой, если оно может помочь реализовать принцип настоящей заявки.

WURScanningReportingOption может указывать, как могут быть предоставлены результаты процесса сканирования WUR. То есть возможность предоставления результатов процесса сканирования WUR может быть указана параметром WURScanningReportingOption. Значениями WURScanningReportingOption могут быть: Immediate (немедленно), Periodic (периодически), At Pre-determined Time (в предварительно заданное время), Channel Specific (в зависимости от канала), At_Request (по запросу), At_End (в конце) и т.д. Например, если параметр WURScanningReportingOption имеет значение Periodic или «в At_Specified_Time, WURScanningReportingPeriod или WURScanningReportingTime, как описано выше, могут быть включены в тот же примитив (т.е. примитив запроса), чтобы указать время или периодичность, с которой могут передаваться или предоставляться результаты процесса сканирования WUR. Вышеупомянутые варианты предоставления результатов процесса сканирования WUR будут дополнительно описаны ниже со ссылкой на подробные варианты осуществления. Хотя WURScanningReportingOption и примеры его значений были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любое доступное значение WURScanningReportingOption также может быть применено в этом способе и WTRU в соответствии с настоящей заявкой, если оно может помочь реализовать принцип настоящей заявки.

RequestResults может указывать, что текущие результаты процесса сканирования WUR запрошены и должны быть предоставлены путем выдачи примитива подтверждения (например, примитива MLME-WURSCAN.confirm).

До сих пор были описаны различные первые параметры, которые могут быть включены в примитив запроса. Следует отметить, что вышеупомянутые первые параметры приведены только в качестве примера, и они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любые доступные параметры могут быть включены в примитив запроса, если они могут помочь реализовать принцип настоящей заявки.

В следующей части будет подробно описан способ на этапе 202. Как описано выше, способ 200 может включать: на этапе 202 выполнение процесса сканирования WUR с использованием WUR на основе множества первых параметров.

В одном варианте осуществления, как описано выше, после генерирования SME или процессором примитива запроса (например, примитива MLME-WURSCAN.request), процессор может управлять WTRU, чтобы инициировать процесс сканирования WUR либо сразу, либо после завершения последовательности текущего обмена кадрами. Затем WTRU может выполнять процесс сканирования WUR на основе множества первых параметров в примитиве запроса.

В зависимости от параметра WURScanningMode, например, если его значение равно «фоновый», процесс сканирования WUR в соответствии с настоящей заявкой может быть запущен как фоновое сканирование. В этом случае WTRU может выполнять операции другого типа.

Если значение параметра WURScanningMode — «только сканирование WUR», то процесс сканирования WUR может быть инициирован только как сканирование WUR. В этом случае, например, WTRU может выключить свое основное радиоустройство и/или выполнять сканирование WUR только в режиме WUR с низким энергопотреблением, и в это время WTRU может не выполнять никаких других операций.

Если значение параметра WURScanningMode — «одновременно с обычным сканированием», «одновременно с пассивным сканированием/активным сканированием», то процесс сканирования WUR может выполняться как параллельный процесс обнаружения вместе с обычным сканированием, активным сканированием/пассивным сканированием, которое может быть указано параметром WURScanningMode. Например, WTRU может использовать свой WUR для сканирования кадров обнаружения WUR в режиме WUR с низким энергопотреблением и при этом выполнять пассивное или активное сканирование, например, с использованием PCR или основного радиоустройства.

Как описано выше, на основе параметра WURScanningMode могут быть выбраны различные режимы сканирования WUR. Следует отметить, что процесс сканирования WUR может быть не единственным процессом сканирования, выполняемым WTRU в заданный период времени. То есть как процесс сканирования без WUR (например, процесс активного сканирования, процесс пассивного сканирования и т.д.), так и процесс сканирования WUR могут выполняться WTRU одновременно.

В другом варианте осуществления примитив запроса может быть примитивом MLME-SCAN.Request или частью примитива MLME-SCAN.Request. В одном примере процесс сканирования WUR может инициироваться примитивом MLME-SCAN.request, который может содержать один или более параметров сканирования WUR. Например, в примитив MLME-SCAN.request может быть добавлен любой из следующих параметров: BSSIDList, SSIDList, CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MinDiscoveryChannelTime, MaxDiscoveryChannelTime, MaxScanningTime, ReceivedPowerThreshold, WURScanningMode, WURScanningReportingOption, RequestWURResult. Эти параметры могут быть такими, как описано в настоящем документе, и процедуры для инициирования сканирования WUR могут быть аналогичными описанным в настоящем документе. Подробное описание этих параметров может быть аналогично описанию, приведенному выше со ссылкой на примитив MLME-WURSCAN.request. Поэтому подробное описание этих параметров будет опущено. Термины MLME-WURSCAN и MLME-SCAN могут использоваться взаимозаменяемо (например, в названиях примитивов, таких как MLME-SCAN.request, MLME-SCAN.confirm, MLME-WURSCANSTOP.request и/или MLME-WURSCANSTOP.confirm).

В приведенной ниже части описания будет описан способ на этапе 203. Как описано выше, способ 200 может включать: на этапе 203 генерирование по меньшей мере одного примитива подтверждения на основе результата процесса сканирования WUR и по меньшей мере части множества первых параметров.

По меньшей мере один примитив подтверждения может содержать один или более примитивов MLME-WURSCAN.confirm, один или более примитивов MLME-SCAN.confirm или комбинацию примитива (-ов) MLME-WURSCAN.confirm и примитива (-ов) MLME-SCAN.confirm. Например, по меньшей мере один примитив подтверждения может содержать один примитив MLME-WURSCAN.confirm и один примитив MLME-SCAN.confirm. В другом примере по меньшей мере один примитив подтверждения может содержать множество примитивов MLME-WURSCAN.confirm и не содержать примитивов MLME-SCAN.confirm. Хотя некоторые примеры по меньшей мере одного примитива подтверждения были описаны выше, они не подразумевают исключающего или ограничивающего характера для настоящей заявки. В некоторых вариантах осуществления термины «примитив MLME-SCAN.confirm», «примитив MLME-WURSCAN.confirm», «примитив подтверждения» могут использоваться взаимозаменяемо.

По меньшей мере, один примитив подтверждения может быть сгенерирован на основе как (1) результата процесса на этапе 202, так и (2) части множества первых параметров. То есть, с одной стороны, по меньшей мере один примитив подтверждения может быть сгенерирован на основе результата процесса на этапе 202, то есть результата процесса сканирования WUR. С другой стороны, по меньшей мере один примитив подтверждения может быть сгенерирован на основе части множества первых параметров. Часть множества первых параметров может содержать по меньшей мере одно из содержащего: WURScanningReportingOption, ReceivedPowerThreshold, CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList или их комбинацию. В следующей части описания будет подробно описана часть множества первых параметров, используемых для определения примитива подтверждения. В приведенном ниже описании примитив подтверждения и примитив MLME-WURSCAN.confirm могут использоваться взаимозаменяемо, если не указано иное.

В одном варианте осуществления часть множества первых параметров может содержать параметр WURScanningReportingOption. То есть примитив MLME-WURSCAN.confirm может быть сгенерирован на основе значений WURScanningReportingOption. WURScanningReportingOption может быть использован для определения времени для генерирования примитива MLME-WURSCAN.confirm. Следующее описание будет посвящено взаимосвязи между примитивом MLME-WURSCAN.confirm и WURScanningReportingOption, то есть порядок генерирования примитива MLME-WURSCAN.confirm на основе значения параметра WURScanningReportingOption.

Например, если значение WURScanningReportingOption равно «немедленно», то примитив MLME-WURSCAN.confirm может генерироваться каждый раз, когда кадр обнаружения WUR принят или обнаружен правильно.

Если значение WURScanningReportionOption равно Channel_Specific, то примитив MLME-WURSCAN.confirm может быть сгенерирован после того, как конкретный канал обнаружения WUR был просканирован на наличие кадров обнаружения WUR, и может иметь или не иметь совпадающие идентификаторы Compressed SSID или Compressed BSSID, как указано в MLME_WURSCAN.request. В этом случае канал обнаружения WUR может быть одним или более каналов обнаружения WUR, указанных в MLME_WURSCAN.request.

Если значение WURScanningReportingOption равно «по запросу», то примитив MLME-WURSCAN.confirm может быть сгенерирован, если MLME-WURSCAN.request был сгенерирован с параметром RequestResults или с параметром RequestResults, значение которого было установлено равным 1, чтобы обеспечивать предоставление результатов текущей процедуры сканирования WUR.

Если значение WURScanningReportingOption равно «в конце», то примитив MLME-WURSCAN.confirm может быть выдан в конце текущей процедуры сканирования WUR после того, как сканирование WUR было завершено на одном или более каналов обнаружения WUR, что может быть указано в примитиве MLME-WURSCAN.request.

Если значение WURScanningReportionOption равно «периодически» или «в указанное время», то примитив MLME-WURSCAN.confirm может генерироваться в каждом периоде или в определенное время, что может быть указано в примитиве MLME-WURSCAN.request.

В одном варианте осуществления часть множества первых параметров может содержать по меньшей мере один параметр из SSID, SSIDList, BSSID, BSSIDList, CompressedSSID, CompressedSSDList, CompressedBSSID или CompressedBSSIDList. То есть примитив MLME-WURSCAN.confirm может быть сгенерирован на основе значений по меньшей мере одного параметра SSID, SSIDList, BSSID, BSSIDList, CompressedSSID, CompressedSSDList, CompressedBSSID или CompressedBSSIDList. Следующее описание будет посвящено взаимосвязи между примитивом MLME-WURSCAN.confirm и вышеупомянутым (-и) параметром (-ами), то есть порядок генерирования примитива MLME-WURSCAN.confirm на основе значения (значений) вышеупомянутого по меньшей мере одного параметра.

Например, примитив MLME-WURSCAN.confirm может быть сгенерирован, если был получен кадр обнаружения WUR с соответствующим SSID, BSSID, сжатым SSID или сжатым BSSID. В другом примере, если один или более CompressedBSSID или CompressedSSID были предоставлены в примитиве запроса (например, примитиве MLME-WURSCAN.request), то примитив MLME-WURSCAN.confirm может быть сгенерирован, если кадр обнаружения WUR был принят с совпадающим сжатым SSID или совпадающим сжатым BSSID. Например, если в полученном кадре обнаружения WUR идентификатор передатчика, содержащийся в поле идентификатора, совпадает с 12 наименее значащими битами (LSB) требуемого сжатого BSSID, а поле, зависящее от типа, содержит 12 битов MSB требуемого сжатого BSSID, тогда может существовать совпадающий сжатый BSSID и может быть сгенерирован примитив MLME-WURSCAN.confirm. Если MLME-WURSCAN.request содержит один или более из CompressedBSSID, CompressedSSID, CompressedBSSIDList, CompressedSSIDList, то могут быть переданы только BSS с совпадающими CompressedBSSID или CompressedSSID (или их частью).

В одном варианте осуществления часть множества первых параметров может содержать параметр ReceivedPowerThreshold. То есть примитив MLME-WURSCAN.confirm может быть сгенерирован на основе значения ReceivedPowerThreshold. Например, если примитив MLME-WURSCAN.request содержит ReceivedPowerThreshold, тогда примитив MLME-WURSCAN.confirm может быть сгенерирован только для одного или нескольких BSS, чьи кадры обнаружения WUR были приняты WTRU с принимаемой мощностью, превышающей заданную ReceivedPowerThreshold. То есть, если принимаемая мощность кадров обнаружения WUR больше, чем заданное значение ReceivedPowerThreshold, то примитив MLME-WURSCAN.confirm может передать один или множество BSS, передающих кадры обнаружения WUR.

Следующее описание будет посвящено содержимому примитива подтверждения в соответствии с настоящей заявкой. Примитив подтверждения (например, примитив MLME-WURSCAN.confirm) может быть использован для возврата описаний набора BSS, обнаруженных процессом сканирования WUR (например, путем приема одного или более кадров обнаружения WUR). В одном варианте осуществления множество примитивов MLME-WURSCAN.confirm может быть сгенерировано, если значение WURReportingOption равно Channel_Specific, At_Request, Periodic или At_Specified_Time. В другом варианте осуществления может быть сгенерирован единственный примитив MLME-WURSCAN.confirm.

В одном варианте осуществления может быть сгенерирован по меньшей мере один примитив подтверждения, и каждый из по меньшей мере одного примитива подтверждения может содержать множество вторых параметров. Множество вторых параметров может содержать по меньшей мере один параметр из BSSDescriptionFromWURDFSet, ResultCode, ScannedWURDiscoveryChannelList и VendorSpecificInfo. Параметр BSSDescriptionFromWURDFSet может присутствовать, если значение dot11WUROptionImplemented или dot11WURActivated — истинно. В следующем описании будут подробно описаны вышеупомянутые вторые параметры в примитиве подтверждения.

В одном варианте осуществления в примитиве подтверждения может быть один или более BSSDescriptionFromWURDFSet. Каждый BSSDescriptionFromWURDFSet может состоять из одного или более параметров, таких как приведенные в качестве примера параметры, показанные в таблице 1.

Таблица 1. Параметры BSSDescriptionFromWURDFSet

Имя	Тип	Описание
Идентификатор (ID) передатчика	12-битный идентификатор	Идентификатор передатчика включен в поле идентификатора кадра обнаружения WUR и может быть 12 битами LSB сжатого BSSID.
Частичный сжатый BSSID	24-битный частичный сжатый BSSID	Частичный сжатый BSSID может состоять из 12 битов LSB сжатого BSSID (может быть включен в поле ID принятого кадра обнаружения WUR) и 12 битов MSB сжатого BSSID (может быть включен в зависящее от типа поле полученного кадра обнаружения WUR).
12 битов LSB сжатого BSSID	12 битов LSB сжатого BSSID	12 битов LSB сжатого BSSID могут состоять из 12 битов LSB сжатого BSSID (может быть включен в поле ID принятого кадра обнаружения WUR)
12 битов MSB сжатого BSSID	12 битов LSB сжатого BSSID	12 битов MSB сжатого BSSID (могут быть включены в зависящее от типа поле принятого кадра обнаружения WUR).
Сжатый SSID	Полный или частичный сжатый SSID	Полный или частичный сжатый SSID. Например, 16 битов LSB или MSB сжатого SSID, которые могут быть получены из поля сжатого SSID принятого кадра обнаружения WUR.
Операционный класс	Поле операционного класса	Операционный класс первичного канала AP, передающей кадр обнаружения WUR.
Канал	Поле канала	Рабочий канал AP, передающей кадр обнаружения WUR и работающий в обычном (не WUR) режиме.
Принимаемая мощность	Принимаемая мощность кадра обнаружения WUR.	Принимаемая мощность кадра обнаружения WUR, например RCPI или RSSI.

ResultCode может иметь по меньшей мере одно из следующих приведенных в качестве примера значений: SUCCESS (успех), INTERMEDIATE_SCAN_RESULT (промежуточный результат сканирования), NOT_SUPPORTED (не поддерживается), PARTIAL_WURSCAN (частичное сканирование WUR), PERIODIC_SCAN_RESULT (результат периодического сканирования), REQUESTED_SCAN_RESULTS (результаты запрошенного сканирования). Во всех этих приведенных в качестве примера значениях SCAN можно заменить на WURSCAN, чтобы уточнить, что результаты являются результатами сканирования WUR. Значение ResultCode может зависеть от причин, по которым был выдан примитив MLME-WURSCAN.confirm. В следующем описании будут подробно описаны приведенные выше значения ResultCode, приведенные в качестве примера.

SUCCESS может быть использовано, если процесс сканирования WUR был успешно выполнен. INTERMEDIATE_SCAN_RESULT может быть использовано, если параметр WURReportingOption в примитиве MLME-WURSCAN.request имеет значение Channel_Specific или Immediate. Значение ResultCode может быть установлено в PARTIAL_SCAN, если выполняется сканирование не всех каналов обнаружения WUR. Для ResultCode может быть установлено значение PERIODIC_SCAN_RESULT, если параметр WURReportingOption в примитиве MLME-WURSCAN.request имеет значение Periodic или At_Requested_Time. Для ResultCode может быть установлено значение REQUESTED_SCAN_RESULTS, если параметр WURReportingOption в примитиве MLME-WURSCAN.request имеет значение At_Request, а примитив MLME-WURSCAN.request был получен с RequestWURResult.

Следует отметить, что вышеупомянутые приведенные в качестве примера значения ResultCode приведены только в качестве примера, и они не подразумевают исключающего или ограничивающего характера для настоящей заявки. Любые доступные значения ResultCode могут быть применены к способу и WTRU в соответствии с настоящей заявкой, если они могут помочь реализовать принципы настоящей заявки.

ScannedWURDiscoveryChannelList может содержать список просканированных каналов обнаружения WUR.

В одном варианте осуществления результаты WUR SCAN могут быть переданы с помощью примитива MLME-SCAN.confirm или как часть примитива MLME-SCAN.confirm. То есть примитив MLME-SCAN.confirm может быть использован для возврата описаний набора BSS или AP, обнаруженных процессом сканирования WUR (например, путем приема одного или более кадров обнаружения WUR). Множество примитивов MLME-SCAN.confirm может быть выдано, если значение WURReportingOption равно Channel_Specific, At_Request, Periodic или At_Specified_Time. В противном случае может быть выдан единственный примитив MLME-SCAN.confirm. Примитив MLME-SCAN.confirm может включать в себя любой из следующих приведенных в качестве примера параметров: BSSDescriptionFromWURDFSet, ResultCode, ScannedWURDiscoveryChannelList или VendorSpecificInfo. Приведенные в качестве примера параметры могут быть такими же или подобными параметрам, описанным со ссылкой на примитив MLME-WURSCAN.confirm. Поэтому подробное описание приведенных в качестве примера параметров в примитиве MLME-SCAN.confirm будет опущено. В настоящей заявке термины MLME-WURSCAN и MLME-SCAN могут использоваться взаимозаменяемо, если не указано иное. Соответственно, если не указано иное, термины MLME-SCAN.request и MLME-WURSCAN.request могут использоваться взаимозаменяемо; термины MLME-SCAN.confirm и MLME-WURSCAN.confirm могут использоваться взаимозаменяемо; термины «MLME-WURSCAN-STOP.Request», «примитив MLME-WURSCAN-STOP.Request», «MLME-SCAN-STOP.Request», «примитив MLME-SCAN-STOP.Request» и «примитив запроса остановки» могут использоваться взаимозаменяемо; и термины «MLME-WURSCAN-STOP.confirm», «примитив MLME-WURSCAN-STOP.confirm», «MLME-SCAN-STOP.confirm», «примитив MLME-SCAN-STOP.confirm» и «примитив подтверждения остановки» могут использоваться взаимозаменяемо.

После процесса на этапе 203 способ 200 перейдет к процессу на этапе 204, т.е. передаче от уровня MAC на SME по меньшей мере одного примитива подтверждения.

Способы и WTRU в соответствии со вторым вариантом осуществления настоящей заявки будут описаны ниже со ссылкой на фиг. 2B. Как показано на фиг. 2B, процессы этапов с 201 по 204 аналогичны процессам, описанным выше со ссылкой на фиг. 2B. Разница между первым вариантом осуществления и вторым вариантом осуществления заключается в том, что способ 200, показанный на фиг. 2B, включает процессы этапов с 205 по 207. Конкретнее, способ 200 дополнительно включает: на этапе 205 обнаружение, был ли сгенерирован примитив запроса остановки для остановки процесса сканирования WUR, причем при условии, что примитив запроса остановки был сгенерирован, способ 200 дополнительно включает: на этапе 206 остановку процесса сканирования WUR; и на этапе 207 генерирование примитива подтверждения остановки. Примитив остановки может быть сгенерирован до того, как будет сгенерирован первый примитив подтверждения.

Приведенное ниже описание будет посвящено процессам на этапах 205 и 207. В одном варианте осуществления примитив запроса остановки может быть примитивом MLME-WURSCAN-STOP.request, который может завершать любой текущий процесс сканирования WUR. Например, независимо от того, в каком режиме сканирования WTRU выполняет процесс сканирования WUR на основе параметра WURScanningMode, примитив MLME-WURSCAN-STOP.request может завершить такой процесс сканирования WUR. SME может сгенерировать примитив MLME-WURSCAN-STOP.request, чтобы остановить все текущие процессы сканирования WUR, выполняемые WTRU.

В другом варианте осуществления примитив запроса остановки может быть примитивом WUR-SCAN-STOP.request или частью примитива WUR-SCAN-STOP.request. Примитив WUR-SCAN-STOP.request может быть использован для завершения любого текущего процесса сканирования WUR. Примитив WUR-SCAN-STOP.request может включать в себя один или более параметров, например ScanType. Как описано выше, множество процессов сканирования (например, как процесс сканирования WUR, так и процесс сканирования без WUR) могут выполняться WTRU одновременно. Параметр ScanType может указывать тип (-ы) сканирования, которое (-ые) примитив может завершать. Параметр ScanType может иметь любое из следующих значений: WUR_Scan (сканирование WUR), Non-WUR_Scan (сканирование, не относящееся к WUR) и All_Scan (все сканирования). Если ScanType имеет значение WUR_Scan, все текущие процессы сканирования WUR могут быть завершены. Если ScanType имеет значение Non_WUR_Scan, то процессы сканирования, не относящиеся к WUR, могут быть завершены, включая процесс пассивного сканирования и процесс активного сканирования. Если ScanType имеет значение All_Scan, все текущие процессы сканирования, включая сканирование WUR и сканирование, не относящееся к WUR (например, активное сканирование и пассивное сканирование), могут быть завершены.

Если был сгенерирован примитив запроса остановки, то на этапе 206 соответствующий (-ие) процесс (-ы) сканирования может (могут) быть завершен (-ы) на основе примитива запроса остановки. То есть, если WTRU или его процессор принимает примитив запроса остановки, то соответствующий (-ие) процесс (-ы) сканирования, идентифицированный (-ые) примитивом запроса остановки, может (могут) быть завершен (-ы).

В приведенном ниже описании будет подробно описан способ на этапе 207. Как описано выше, способ 200 может включать: на этапе 207 генерирование примитива подтверждения остановки.

В первом варианте осуществления примитив подтверждения остановки может быть примитивом MLME-WURSCAN-STOP.confirm, который может быть использован для указания успешного завершения процесса (-ов) сканирования, такого (-их) как процесс (-ы) сканирования WUR и/или процесс (-ы) сканирования, не относящиеся к WUR. Во втором варианте осуществления примитив подтверждения остановки может быть примитивом MLME-Scan-Stop.confirm или частью примитива MLME-Scan-Stop.confirm. Примитив MLME-Scan-Stop.confirm может быть использован аналогично MLME-WURSCAN-STOP.Confirm. В третьем варианте осуществления примитив подтверждения остановки может быть примитивом MLME-WURSCAN.confirm или примитивом MLME-SCAN.confirm, описанным выше. То есть примитив MLME-WURSCAN.confirm или примитив MLME-SCAN.confirm могут быть использованы для той же цели, что и MLME-WURSCAN-STOP.confirm.

Следующее описание будет посвящено поддержке сервиса eBCS в соответствии с настоящей заявкой.

Существует потребность в поддержке услуги широковещательной передачи для неассоциированных WTRU. Кроме того, в текущих стандартах WLAN существует потребность в услуге широковещательной передачи для восходящей линии связи. Для неассоциированных WTRU или для WTRU, которые предназначены только для приема и не могут осуществлять передачу, необходимы конструкции для поддержки услуги широковещательной передачи по нисходящей линии связи. Кроме того, необходимы схемы для широковещательной передачи по восходящей линии связи посредством WTRU для одной или более AP. Для поддержки WTRU независимо от статуса ассоциирования WTRU и для поддержки услуги широковещательной передачи по восходящей линии связи посредством WTRU без AP для одной или более AP могут быть разработаны протоколы услуги широковещательной передачи и сигнализации.

В настоящем документе описаны механизмы поддержки услуги широковещательной передачи в соответствии с настоящей заявкой. WTRU (например, AP или STA без AP), у которого имеется dot11eBCSImplemented и/или dot11eBCSActivized, может включать элемент eBCS в свой маяк или в кадры пробного запроса/ответа и кадры (повторного) запроса ассоциирования/ответа, которые WTRU передает. В одном примере элемент eBCS может быть включен в широковещательную информацию восходящей линии связи (UL) и/или нисходящей линии связи (DL). В другом примере элемент eBCS по UL может быть включен в широковещательную информацию UL, и/или элемент eBCS по DL может быть включен в широковещательную информацию DL. Следует отметить, что в настоящей заявке, если не указано иное, термины «элемент широковещательной передачи по DL», «элемент eBCS по DL» и «элемент возможностей широковещательной передачи по DL» могут использоваться взаимозаменяемо.

Приведенная в качестве примера конструкция элемента широковещательной передачи по DL или элемента eBCS по DL показана на фиг. 3. Элемент широковещательной передачи по DL может содержать одно или более из следующих приведенных в качестве примера полей: идентификатор элемента; длина; расширение идентификатора элемента; и/или возможности широковещательной передачи по DL, включая поля N eBCS. Комбинация идентификатора элемента и расширения идентификатора элемента может идентифицировать текущий элемент как элемент широковещательной передачи по DL или элемент eBCS по DL. Поле длины может указывать длину элемента широковещательной передачи по DL.

Возможности широковещательной передачи по DL могут включать в себя N полей (то есть от eBCS 1 до eBCS N), так что каждое поле может быть использовано для указания конкретной услуги широковещательной передачи, которая предоставляется передающим WTRU (например, передающей AP). Каждое поле eBCS может содержать одно или более из следующих приведенных в качестве примера подполей: идентификатор услуги широковещательной передачи, тип eBCS, требуемая ассоциация, требуемая передача UL, скорость широковещательной передачи, частота широковещательной передачи, кодирование широковещательной передачи, управление широковещательной передачей, параметры широковещательной передачи и/или состояние широковещательной передачи. Вышеупомянутые подполя будут дополнительно описаны ниже.

Подполе «идентификатор услуги широковещательной передачи» может указывать идентификатор услуги широковещательной передачи. Подполе «тип eBCS» может включать в себя тип услуги широковещательной передачи (например, является ли eBCS UL или DL, или относится ли услуга широковещательной передачи к категории автомобильных, указывающих направление, экстренных, вспомогательных, информационных и/или предназначенных для поддержки события). В одном примере битовое отображение может быть включено в элемент широковещательной передачи по DL, чтобы указать, какие типы услуг широковещательной передачи предоставляются передающим (-и) WTRU. Типом также может быть широковещательная передача с множеством AP. В другом примере тип широковещательной передачи может быть идентифицирован организационно уникальным идентификатором (OUI). Подполе «требуемая ассоциация» может указывать, требуется ли ассоциация для использования одной или более услуг широковещательной передачи (например, услуги широковещательной передачи, идентифицированной идентификатором услуги широковещательной передачи).

Подполе «требуемая передача UL» может указывать, требуется ли передача по UL для использования одной или более услуг широковещательной передачи (например, услуги широковещательной передачи, идентифицированной идентификатором услуги широковещательной передачи). Подполе «скорость широковещательной передачи» может указывать скорость передачи данных, связанную с услугой широковещательной передачи. Подполе «частота широковещательной передачи» может указывать частоту, на которой передаются данные широковещательной передачи. Подполе «кодирование широковещательной передачи» может указывать кодирование пакетов данных широковещательной передачи (например, межкадровый двоичный сверточный код BCC (BCC), межкадровая проверка четности с низкой плотностью (LDPC), гибридный автоматический запрос на повторение передачи (HARQ), код свертки (CC), инкрементная избыточность (IR) HARQ).

Подполе «управление широковещательной передачей» может указывать, как управлять услугой широковещательной передачи. Например, подполе «управление широковещательной передачей» может указывать, что, если WTRU требуется определенная услуга широковещательной передачи, WTRU необходимо напрямую согласовать это с передающим WTRU (например, передающей AP), используя, например, кадр запроса широковещательной передачи. В другом примере подполе «управление широковещательной передачей» может указывать адрес сервера (например, IP-адрес сервера) или адрес AP контроллера (например, MAC-адрес или BSSID другой AP). Такая AP контроллера может быть главной AP набора с множеством AP. WTRU может также связываться с AP контроллера или сервером для обеспечения обратной связи об услуге широковещательной передачи, согласованных скоростях или кодировании. Примерами способов управления могут быть способы управления посредством WLAN, протокол управления передачей/Интернет-протокол (TCP/IP), согласование запроса широковещательной передачи, ANQP и/или обмены кадрами общего рекламного сервиса (GAS).

Подполе «параметры широковещательной передачи» может включать в себя один или более параметров широковещательной передачи, включая смещение, канал и т.д. Например, смещение может указывать смещение начала следующего пакета широковещательной передачи или последовательностей широковещательной передачи, которые могут отсчитываться от конца текущей передачи, от целевого времени передачи маяка (TBTT) или от других контрольных точек. Канал может указывать канал, подканалы OFDMA или блоки ресурсов (RU), на которых могут быть доступны пакеты услуги широковещательной передачи.

Подполе «состояние широковещательной передачи» может указывать текущее состояние широковещательной передачи, например Broadcasting (идет вещание), Paused (приостановлено) или To be Initiated (ожидается инициирование).

Иллюстративная конструкция элемента широковещательной передачи по UL или элемента eBCS по UL показана на фиг. 4. Элемент широковещательной передачи по UL может включать в себя одно или более из следующих приведенных в качестве примера полей: идентификатор элемента; длина; расширение идентификатора элемента; и/или широковещательная информация UL, включая поля N eBCS. Следует отметить, что в настоящей заявке, если не указано иное, термины «элемент широковещательной передачи по UL», «элемент eBCS по UL» и «элемент возможностей широковещательной передачи по UL» могут использоваться взаимозаменяемо.

Комбинация идентификатора элемента и расширения идентификатора элемента может идентифицировать текущий элемент как элемент широковещательной передачи по UL или элемент eBCS по UL. Поле длины может указывать длину элемента широковещательной передачи по UL. Широковещательная информация UL может включать в себя N полей (то есть от eBCS 1 до eBCS N), так что каждое поле может быть использовано для указания конкретной услуги широковещательной передачи по UL, поддерживаемой передающим WTRU. Каждое поле eBCS может содержать одно или более из следующих приведенных в качестве примера подполей: Allowed Broadcast Service ID (идентификатор разрешенной услуги широковещательной передачи); Allowed eBCS Type (разрешенный тип eBCS); Association Required (требуемая ассоциация); DL Reception Required (требуемый прием DL); Allowed Broadcast Rate (разрешенная скорость широковещательной передачи); Broadcast Frequency Allowed (разрешенная частота широковещательной передачи); Broadcast Encoding (кодирование широковещательной передачи); Broadcast Control (управление широковещательной передачей); Broadcast Parameters (параметры широковещательной передачи); и/или Broadcast Status (состояние широковещательной передачи). Вышеупомянутые подполя будут дополнительно описаны ниже.

Подполе «идентификатор разрешенной услуги широковещательной передачи» может указывать идентификатор услуги широковещательной передачи по UL, которая поддерживается и разрешена передающим WTRU. Подполе «разрешенный тип eBCS» может включать в себя тип разрешенной услуги широковещательной передачи (например, является ли разрешенный eBCS UL или DL, или относится ли услуга широковещательной передачи к категории автомобильных, сенсорных, указывающих направление, экстренных, вспомогательных, информационных и/или предназначенных для поддержки события). В одном примере битовое отображение может быть включено в элемент широковещательной передачи по UL, чтобы указать, какие типы услуг широковещательной передачи разрешены и поддерживаются передающим (-и) WTRU. В другом примере тип широковещательной передачи может быть идентифицирован OUI или адресом сервера. Подполе «разрешенный тип eBCS» может включать в себя подробное описание предоставляемой услуги широковещательной передачи.

Подполе «требуемая ассоциация» (не показано на фиг. 4) может указывать, требуется ли ассоциация для использования одной или более разрешенных услуг широковещательной передачи по UL (например, услуги широковещательной передачи, идентифицированной идентификатором разрешенной услуги широковещательной передачи). Подполе «требуемый прием DL» (не показано на фиг. 4) может указывать, необходим ли прием DL для использования одной или более разрешенных услуг широковещательной передачи по UL (например, услуги широковещательной передачи, идентифицированной идентификатором разрешенной услуги широковещательной передачи).

Подполе «разрешенную скорость широковещательной передачи» может указывать разрешенную скорость передачи данных для одного или более WTRU для передачи по UL, ассоциированной с услугой широковещательной передачи. Подполе «разрешенная частота широковещательной передачи» может указывать разрешенную частоту, на которой WTRU разрешено широковещательно передавать данные по UL, ассоциированной с этой разрешенной услугой широковещательной передачи. Подполе «кодирование широковещательной передачи» может указывать кодирование, которое должно быть использовано для пакетов данных широковещательной передачи по UL, например, межкадровый BCC, межкадровый LDPC, HARQ CC, HARQ IR.

Подполе «управление широковещательной передачей» может указывать способы управления широковещательной передачей по UL. Например, подполе «управление широковещательной передачей» может указывать, как управлять услугой широковещательной передачи (например, указывать место назначения разрешенной услуги широковещательной передачи по UL). Например, оно может указывать, что если WTRU требуется использовать определенную услугу широковещательной передачи по UL, WTRU необходимо напрямую согласовать это с передающим WTRU (например, передающей AP), используя, например, кадр запроса широковещательной передачи. В другом примере подполе «управление широковещательной передачей» может указывать адрес сервера (например, IP-адрес сервера) или адрес AP контроллера (например, MAC-адрес или BSSID другой AP). Такая AP контроллера может быть главной AP набора с множеством AP. WTRU, которому требуется использовать услугу широковещательной передачи по восходящей линии связи, чтобы получить обратную связь или согласовать MCS, которые будут использованы, может связываться с сервером или контроллером. Например, способ управления может осуществляться посредством WLAN, TCP/IP, согласования запроса на широковещательную передачу, обменов кадрами ANQP или GAS.

Подполе «параметры широковещательной передачи» может включать в себя один или более параметров широковещательной передачи, включая доступ к UL, например EDCA, инициированный широковещательный доступ, произвольный доступ OFDMA восходящей линии связи. Например, если параметром широковещательной передачи является инициируемый широковещательный доступ, WTRU, использующий услугу широковещательной передачи восходящей линии связи, может передавать широковещательные пакеты восходящей линии связи только в том случае, если это инициировано AP. Например, AP может быть инициирована на одном или более подканалах или RU. В триггерном кадре или кадре запуска может быть указано, что запускаются данные широковещательной передачи восходящей линии связи и/или передачи от неассоциированных WTRU. Если параметром широковещательной передачи является произвольный доступ OFDMA восходящей линии связи, WTRU, использующий услугу широковещательной передачи восходящей линии связи, может передавать широковещательные пакеты восходящей линии связи только в том случае, если это инициировано триггерным кадром или кадром запуска, запускающим произвольный доступ к восходящей линии связи на одном или более RU. Подполе «состояние широковещательной передачи» может указывать текущее состояние широковещательной передачи, например Broadcasting (идет вещание), Paused (приостановлено) или To be Initiated (ожидается инициирование).

В одном варианте осуществления элементы широковещательной передачи по UL и DL, как описано выше, могут быть объединены в один элемент широковещательной передачи или элемент eBCS. В другом варианте осуществления информация, включенная в элементы широковещательной передачи по UL и DL, может быть включена как часть элемента ANQP. Кроме того, любое подмножество элементов широковещательной передачи по UL и DL может передаваться в кадрах любого другого типа или в элементах любого другого типа, заголовках MAC и PHY и т.д.

Процедура широковещательной передачи по DL в соответствии с настоящей заявкой будет описана ниже.

Во-первых, WTRU (то есть WTRU без AP), которому требуется услуга широковещательной передачи по DL, может включать в себя элемент широковещательной передачи по DL в кадрах, которые он передает, например, кадрах пробного запроса, кадрах ANQP или кадрах запроса GAS. При передаче WTRU элемент широковещательной передачи по DL может указывать информацию или параметры требуемой услуги широковещательной передачи DL. В другом примере WTRU без АР может включать в себя элемент запроса широковещательной передачи по DL, который может включать в себя одно или более подполей, описанных для элемента широковещательной передачи по DL, описывающих требуемые услуги широковещательной передачи по DL.

Во-вторых, AP может включать элемент широковещательной передачи по DL или элемент eBCS в свой маяк, ответы на пробу, ответы об ассоциации, кадры ответа ANQP или кадры ответа GAS либо любой другой тип кадров. В одном примере AP может включать в себя элемент широковещательной передачи по DL, только если она получила от WTRU кадр, который запрашивает элемент широковещательной передачи по DL (например, когда она получила кадр, такой как кадр ANQP, кадр запроса GAS или кадры пробных запросов, которые включают в себя элемент широковещательной передачи по DL или элемент eBCS, указывающий на потребность в услуге широковещательной передачи по DL). При передаче AP элемент широковещательной передачи по DL может указывать услуги широковещательной передачи по DL, предоставляемые AP.

В-третьих, WTRU (то есть WTRU без AP), принимающий элемент широковещательной передачи по DL, может идентифицировать одну или более требуемых услуг широковещательной передачи, предоставляемых AP. WTRU без АР может следовать инструкциям, указанным в элементе широковещательной передачи по DL, таким как ассоциация, если ассоциация необходима. Если состояние широковещательной передачи указывает, что услуга широковещательной передачи в настоящее время осуществляет широковещательную передачу, WTRU без АР может следовать информации об управлении широковещательной передачей и ее параметрах (например, настраиваться на верные RU, подканалы или каналы с правильным смещением для приема одного или более пакетов услуги широковещательной передачи с использованием указанного режима или кодировки широковещательной передачи).

Если состояние широковещательной передачи указывает, что услуга широковещательной передачи приостановлена или должна быть инициирована, WTRU без АР может следовать инструкциям, включенным в элемент широковещательной передачи по DL, чтобы возобновить или инициировать услугу широковещательной передачи. Например, если управление широковещательной передачей должно быть «согласовано с AP», WTRU может связываться с AP, а затем направлять запрос услуги широковещательной передачи AP. В другом примере WTRU может не связываться с AP, но использовать запрос ANQP или протоколы GAS для возобновления или инициирования услуги широковещательной передачи по DL. Если управление широковещательной передачей указано как «согласованное с AP контроллера или сервером» посредством «WLAN» или «TCP/IP», WTRU может устанавливать связь с AP контроллера, а затем направлять запрос услуги широковещательной передачи AP, указывая при этом лучшую АР для услуги широковещательной передачи; или WTRU может использовать соединения TCP/IP для связи с сервером для возобновления или инициирования требуемой услуги широковещательной передачи, указывая при этом лучшую AP, в которой должна быть предоставлена услуга широковещательной передачи.

Затем WTRU может использовать способы управления широковещательной передачей для дальнейшего согласования услуг широковещательной передачи, такие как обратная связь, кодирование, схема модуляции и кодирования (MCS) и/или повторение.

Процедура широковещательной передачи по UL в соответствии с настоящей заявкой будет описана ниже.

Во-первых, WTRU (то есть WTRU без AP), которому требуется использовать одну или более услуг широковещательной передачи по UL, может включать элемент широковещательной передачи по UL в кадры, которые он передает, такие как кадры пробного запроса, кадры ANQP или кадры запроса GAS. При передаче WTRU без АР элемент широковещательной передачи по UL может указывать информацию или параметры требуемых услуг широковещательной передачи по UL. В другом примере WTRU без АР может включать в себя элемент запроса широковещательной передачи по UL, который может включать в себя одно или более подполей, описанных для элемента широковещательной передачи по UL, описывающих требуемые услуги широковещательной передачи по UL.

Во-вторых, AP может включать в элемент широковещательной передачи по UL или элемент eBCS в свой маяк, ответы на пробу, ответы об ассоциации, кадры ответа ANQP или кадры ответа GAS либо любые другие типы кадров. AP может включать в себя элемент широковещательной передачи по DL, если она получила от WTRU кадр, который запрашивает элемент широковещательной передачи по DL (например, когда она получила кадр, такой как кадр ANQP, кадр запроса GAS или кадры пробных запросов, которые включают в себя элемент широковещательной передачи по UL или элемент eBCS, указывающий на потребность в услугах широковещательной передачи по UL). При передаче AP элемент широковещательной передачи по UL может указывать услуги широковещательной передачи по UL, которые поддерживаются и разрешены AP. AP может предоставлять политики в отношении поддерживаемой и разрешенной услуги широковещательной передачи по UL, например разрешенной скорости широковещательной передачи, разрешенной частоты широковещательной передачи или разрешенного способа широковещательной передачи по UL, такого как инициированная широковещательная передача, произвольный доступ OFDMA восходящей линии связи или EDCA.

Если состояние широковещательной передачи — Accepting Broadcast (прием широковещательной передачи), то WTRU без АР может начинать широковещательную передачу своих данных UL, если он получил от AP кадр (например, маяк, ответы на пробный запрос или ответы об ассоциации либо кадры обнаружения FILS), который может включать в себя элемент широковещательной передачи по UL или элемент eBCS, в котором AP может указывать, что она поддерживает и разрешает эту конкретную услугу широковещательной передачи по UL. WTRU может следовать инструкциям, включенным в элемент широковещательной передачи по UL, для осуществления широковещательной передачи по UL, например, с использованием разрешенной скорости широковещательной передачи, частоты широковещательной передачи и/или способов широковещательной передачи по восходящей линии связи. Если состояние широковещательной передачи — Pause или To Be Initiated, WTRU без АР может использовать указанные способы управления широковещательной передачей для согласования непосредственно с AP или связаться с AP контроллера или сервером, используя способы управления широковещательной передачей (например, WLAN, TCP/IP), для возобновления или инициирования услуги широковещательной передачи по UL, предоставляемой AP.

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

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

Широковещательные пакеты могут передаваться множеству WTRU, например, в случае нисходящей линии связи. Условия канала, а также возможности и чувствительности устройств могут варьироваться у различных WTRU. Следовательно, надежность приема широковещательного пакета может не быть одинаковой для всех принимающих WTRU. Надежность широковещательной передачи особенно важна для WTRU, которые не ассоциированы или не могут передавать данные. Таким образом, широковещательные протоколы и широковещательные пакеты могут быть спроектированы так, чтобы услуги широковещательной передачи гарантированно предоставлялись всем WTRU.

В настоящем документе описаны механизмы повышения надежности широковещательной передачи в соответствии с настоящей заявкой. Примером механизма надежности широковещательной передачи является межкадровое кодирование, такое как BCC и LDPC. Узел широковещательной передачи (например, AP) может передавать кадры, содержащие систематические биты или биты четности из ранее переданных кадров, закодированные и чередуемые между собой. Данные в исходном кадре могут быть закодированы BCC или LDPC. В первом примере данные в новых подкадрах могут содержать кодированные данные из ранее переданных кадров, которые линейно закодированы вместе, что называется межкадровым кодированием BCC или LDPC. В этом случае надежность дополнительных битов после декодирования становится выше. Во втором примере данные в новых подкадрах могут содержать кодированные данные из ранее переданных кадров, которые объединены и чередуются между собой. Это можно описать как HARQ частичного кадра. В этом случае вместо того, чтобы повторная передача HARQ осуществлялась сама по себе, она передается вместе с повторными передачами HARQ из других кадров. Это может помочь уменьшить задержку широковещательной передачи. В приведенном ниже описании будут подробно описаны два вышеупомянутых примера.

На фиг. 5 и фиг. 6 показаны примеры межкадрового кодирования LDPC с последовательно увеличивающимися инкрементами. Как показано на фиг. 5, процедура межкадрового кодирования LDPC может начинаться после создания битов данных и битов четности путем отбрасывания сокращенных битов в процедуре кодирования LDPC, в результате чего получается пакет с длиной Nmax. Кадр RH скорости, показанный на фиг. 5, может содержать N битов, а D (не)равных инкрементов могут содержать D инкрементных подкадров от ∆1 до ∆D.

Nmax может быть определено на основе длины пакета, который должен быть отправлен (N), количества инкрементных подкадров (D) и их соответствующих длин (Δ_i). Каждый инкрементный подкадр может иметь разную длину, так что Nmax = N + . Если длина каждого инкрементного подкадра одинакова, то Nmax = N + DΔ_i. Исходная передача для каждого кадра будет содержать N битов (как показано на фиг. 5), тогда как инкрементные подкадры (например, ∆1–∆D) могут быть составлены из дополнительных (невыкалываемых) битов четности. В примере, показанном на фиг. 6, индексы инкрементов могут быть случайными и могут не увеличиваться последовательно.

На фиг. 7 показан пример межкадрового кодирования BCC. В случае межкадрового кодирования BCC для передачи BCC исходная передача для каждого кадра имеет N невыкалываемых битов (например, N битов, показанных на фиг. 7), а инкрементные подкадры (например, ∆1 и ∆2, показанные на фиг. 7) могут быть составлены из других выкалываемых битов. Как показано на фиг. 7, данные источника могут содержать x0, x1, x2, x3 и x4; кодированные данные могут содержать A0–A4 и B0–B4; один кадр RL скорости с неравными инкрементами для BCC может содержать N битов (включая A0, B0, A1, B2, A3, B4), ∆1 (содержащий B1, A2 и B3) и ∆2 (A4 и A0).

Могут быть определены процедуры для межкадровой передачи BCC/LDPC и частичного пакета HARQ для кодов BCC/LDPC. На фиг. 8 показан пример межкадрового кодирования и частичного HARQ с фиксированными индексами. AP может определять передачу кадров NT + D (т.е. кадров NT и кадров D). Первые передачи NT (т.е. 1-NT) представляют собой кадры с внутрикадровым кодированием, состоящие из N битов каждого кадра. Как показано на фиг. 8, внутрикадровое кодирование содержит NT-кадры от 1 до NT-кадра. Последние передачи D представляют собой подкадры с межкадровым кодированием, состоящие из комбинации инкрементов D из каждого кадра.

В одном варианте осуществления инкременты D подкадра каждого кадра могут быть объединены, а затем переданы. Это обеспечивает возможность частичной передачи HARQ. В другом варианте осуществления инкременты D каждого кадра могут быть линейно закодированы с использованием конкретной схемы кодирования.

Для каждого переданного кадра может быть сигнализировано одно или более из следующей информации (например, в заголовке процедуры конвергенции физического уровня (PLCP)): внутрикадровое или межкадровое кодирование, индекс кадра внутрикадрового кодирования, индекс кадра межкадрового кодирования (в примере ниже это может быть индекс a в дельта (a, b) и/или может быть сигнализировано явно либо идентифицировано неявно на основе индекса кадра после начала всей передачи) или индексы кадров, закодированных в инкрементном подкадре (в приведенном ниже примере это может быть индекс b в дельта (a, b) и/или может сигнализировано явно либо идентифицировано неявно на основе количества кадров в передаче). В случае, когда индексы могут иметь разные размеры, может быть сигнализирован размер инкрементов из каждого кадра в инкрементном подкадре.

На фиг. 9 показан пример межкадрового кодирования и частичного HARQ со скользящим окном. Как показано на фиг. 9, инкрементные подкадры могут быть агрегированы (например, как агрегированный PPDU) в передаваемые кадры. Например, каждый кадр может агрегировать инкрементные подкадры из предшествующих ему кадров до максимального количества инкрементных подкадров. Как показано на фиг. 9, кадр 2 агрегирует первый инкрементный подкадр (т.е. ∆1, 1) из кадра 1. Кадр 3 агрегирует второй инкремент (т.е. ∆2, 1) из кадра 1 с первым инкрементом (∆1, 2) из кадра 2. Кадр 4 агрегирует инкременты из кадров 1, 2 и 3. Кадр 5 агрегирует инкременты из кадров 2, 3 и 4, поскольку значение D (количество инкрементов) равно 3.

Передаваемые инкременты могут быть выбраны динамически, как показано на фиг. 10. Например, этот подход может быть использован в случае, если возможна обратная связь от WTRU о кадрах, которые были приняты неудачно. Вещающая AP может динамически выбирать определенные кадры для передачи инкрементной информации. Вещающая АР может динамически выбирать размер инкремента для отправки на основе необходимого качества сигнала широковещательной передачи (для некоторых кадров может потребоваться больше защиты, чем для других). В примере обратная связь одного или более WTRU указывает, что конкретный кадр принят очень неудачно. Например, если большинство (выбранных) WTRU указывают, что кадр был принят неудачно, может потребоваться дополнительная информация. В другом примере WTRU может отправлять больше информации о кадрах, которые могли быть отправлены ранее, чтобы гарантировать, что они будут декодированы быстрее, чтобы уменьшить общую задержку.

Процедура WTRU может быть определена как часть межкадрового кодирования. Как часть иллюстративной процедуры WTRU, AP и WTRU могут обмениваться информацией о возможностях касательно возможности принимать межкадровое кодирование. Информация о возможностях может содержать максимальное количество кадров, которые могут быть декодированы одновременно. AP может использовать информацию о возможностях для принятия решения о параметрах межкадрового кодирования для широковещательного канала. Например, AP может устанавливать количество одновременных кадров на минимум, указанный всеми принимающими WTRU (например, набор дискретных, предварительно определенных значений и/или специфичных для WTRU). WTRU может принимать кадр и декодировать принятый заголовок PLCP. WTRU может идентифицировать, что принятый кадр имеет межкадровую кодировку. WTRU может идентифицировать, является ли пакет внутрикадровым, межкадровым или и тем и другим. Если пакет имеет внутрикадровую кодировку, WTRU может декодировать кадр. Если декодирование прошло успешно, WTRU может отправлять ACK на AP по запросу и/или завершать процедуру декодирования для этого кадра. Если декодирование прошло неуспешно, WTRU может сохранять кадр в буфере.

Если пакет имеет межкадровое кодирование, WTRU может декодировать/устранять перемежение/деагрегировать инкрементные подкадры в кадре. WTRU может идентифицировать инкрементный подкадр на основе явной или неявной сигнализации. WTRU может отбрасывать инкрементные подкадры всех кадров, которые были успешно декодированы. WTRU может обрабатывать инкрементные подкадры всех кадров, которые не были декодированы, путем добавления информации об инкрементных подкадрах, принятой в существующий буфер кадров, с последующим декодированием результатов. Если декодирование прошло успешно, WTRU может отправлять ACK на AP по запросу и/или завершать процедуру декодирования для этого кадра. Если декодирование прошло неуспешно, WTRU может сохранять кадр в буфере. WTRU может отправлять NAK на AP или дождаться, пока не будет принято общее количество инкрементных подкадров, прежде чем отправлять NAK. Поскольку канал является широковещательным каналом, передача ACK/NAK может быть основана на запросе AP к конкретному (-ым) WTRU, а не ко всем WTRU, которым осуществляется передача. В одном из примеров WTRU могут отправлять ACK/NAK по определенному (под)каналу, и наличие сигнала на подканале может уведомлять AP об успешном/неудачном завершении.

Если пакет имеет как внутри-, так и межкадровую кодировку, WTRU может отделять пакет внутри кадра от пакета между кадрами, а затем обрабатывать каждый отдельно, используя подходы, описанные выше.

При широковещательной передаче HARQ широковещательный кадр может быть передан несколько раз или с повторением. В приведенной в качестве примера процедуре передача с повторениями может быть такой же, как и первоначальная передача, так что приемники могут легко комбинировать принятые данные. Сигнализация может быть использована, чтобы дать возможность принимающему WTRU комбинировать принятые кадры. Одно или более из следующей информации (полей) могут быть включены, например, в заголовок PLCP, заголовок MAC, корпус MAC и/или сигнальный кадр: идентификатор, широковещательная передача, повторение передачи, индекс повторения, следующий кадр повторения или следующий маяк повторения. Вышеупомянутые поля будут дополнительно описаны ниже.

Поле «идентификатор» (ID) может указывать любой из ID назначения, ID источника, ID передатчика, ID приемника, ID широковещательной передачи, ID широковещательного канала и/или ID контента. Поле широковещательной передачи может быть использовано для указания того, является ли этот кадр широковещательным, многоадресным и/или одноадресным. Поле повторения передачи может быть использовано, чтобы указать, передается ли этот кадр повторно. Поле повторения передачи также может указывать тип используемого повторения (например, простое повторение или межкадровое кодирование).

Поле индекса повторений может указывать количество повторений для текущей передачи. Например, поле индекса повторений может быть передано в возрастающем порядке. В другом примере поле индекса повторений может быть передано в убывающем порядке, так что принимающие WTRU могут знать количество повторений передачи, которые могут последовать. Поле следующего кадра повторения может указывать ожидаемое время для следующего кадра повторения. Поле следующего кадра повторения также может указывать тип кадра повторения, который должен быть отправлен в это время. Поле следующего маяка повторения может указывать ожидаемое время для следующего маяка повторения. В примере ожидаемое время может представлять собой продолжительность.

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

Согласно первому подходу для разных повторений могут быть использованы разные перемежители битов. Между кодером BCC и сопоставитель комбинаций может использоваться битовый перемежитель. В одном примере могут быть определены несколько перемежителей битов. Например, количество перемежителей битов может быть таким же, как максимальное разрешенное количество повторений. В этом случае один перемежитель может быть использован для одного повторения. В другом примере может быть определено фиксированное количество перемежителей. Сопоставление индекса перемежителя с повторением может быть определено с помощью функции. Например, может быть использована модульная функция. Индекс перемежителя, используемый для k-го повторения, может быть определен как Interleaver_ID = mod (k, N), где N — определенное максимальное количество перемежителей. Битовый перемежитель может использоваться или не использоваться для кодов LDPC. В приведенном в качестве примера подходе битовые перемежители могут быть определены для повторений передачи.

Согласно второму подходу для разных повторений могут быть использованы разные перемежители символов. Например, перемежитель уровня символа может быть использован сразу после сопоставителя комбинаций. Использование перемежителя уровня символа может заключаться в распределении модулированного символа среди символа OFDM. В одном примере может быть определено фиксированное количество перемежителей символов. Сопоставление индекса перемежителя с повторением может быть определено с помощью функции. Например, может быть использована модульная функция. Индекс перемежителя символов, используемый для k-го повторения, может быть определен как Interleaver_ID = mod (k, N), где N — определенное максимальное количество перемежителей уровня символа.

Согласно третьему подходу для разных передач может использоваться другая версия избыточности (RV). Разные RV могут соответствовать разным подмножествам кодированных битов. Сопоставление индекса RV с повторением может быть определено с помощью функции. Например, может быть использована модульная функция. Индекс RV, используемый для k-го повторения, может быть определен как RV_ID = mod (k, N), где N — определенное максимальное количество RV.

О разнесенной широковещательной передаче может быть сигнализировано в заголовке PLCP, заголовке MAC или корпусе MAC, и данные могут включать в себя одно или более из следующих приведенных в качестве примера полей: идентификатор, широковещательная передача, повторение передачи, максимальное количество повторений, индекс повторения, индекс передачи или следующий маяк/синхронизация повторения. Вышеупомянутые приведенные в качестве примера поля будут дополнительно описаны ниже.

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

Поле индекса передачи может быть использовано для сигнализации индекса перемежителя уровня битов, индекса перемежителя уровня символа и/или индекса RV, используемых в следующей передаче. Поле следующего маяка/синхронизации повторения может указывать ожидаемое время для следующего маяка/синхронизации повторения. В примере ожидаемое время может представлять собой продолжительность. Эта продолжительность может быть функцией возможностей WTRU, позволяющей каждому WTRU декодировать каждую передачу независимо. В другом примере ожидаемое время может быть «немедленно», что указывает на то, что следующее повторение происходит в течение продолжительности межкадрового интервала (xIFS) после завершения текущей передачи.

Могут быть использованы процедуры для энергосбережения при приеме услуги широковещательной передачи (BCS). WTRU может принимать заголовок PLCP с идентификатором повторения. В одном примере заголовок PLCP может содержать общее количество повторений, а также индекс повторения. WTRU может сохранять все повторения и декодировать после последнего приема. WTRU может декодировать после каждого повторения. Одна или более AP и один или более WTRU могут согласовывать минимальную длительность между повторениями, чтобы разрешить декодирование пакета после каждого повторения.

Если WTRU декодировал пакет, он может перейти в спящий режим на время передачи. На фиг. 11 показан пример процедуры энергосбережения с межкадровым интервалом xIFS между повторениями BCS, который может быть использован для BCS. Например, как показано на фиг. 11, WTRU1 декодировал пакет во время Tx1, а затем он может находиться в спящем режиме до Tx4.

Если WTRU декодировал пакет, и продолжительность между повторениями представляет собой «немедленно», WTRU может перейти в спящий режим на время определенных повторений. На фиг. 12 показан пример процедуры энергосбережения с конкретными временными различиями между повторениями, которые могут быть использованы для BCS. Например, как показано на фиг. 12, WTRU1 декодировал пакет в течение Tx1, а затем он может находиться в спящем режиме в течение Tx2, Tx3 и Tx4.

В одном варианте осуществления может быть использовано повторение передачи на основе обратной связи. Максимальное количество повторений передачи может быть предварительно определено или (пере)определено. Максимальное количество повторений передачи может быть перенесено и сигнализировано в сигнальных кадрах, кадрах (повторной) ассоциации, кадрах пробного запроса/ответа или любых других типах кадров управления/контроля. WTRU (например, WTRU с АР или WTRU без АР) не всегда может достигать максимального количества повторений передачи. WTRU может завершать повторение передачи на основе обратной связи. Например, если WTRU принимает положительное подтверждение (ACK) от другого WTRU, который может находиться далеко от WTRU, WTRU может останавливать повторение.

В одном варианте осуществления повторения передачи могут быть разделены по меньшей мере предварительно определенным межкадровым интервалом xIFS. В одном способе xIFS может быть больше, чем короткий межкадровый интервал (SIFS) или распределенный межкадровый интервал (DIFS). В одном варианте осуществления межкадровый интервал между каждой повторной передачей может быть динамическим и настраиваемым. Принимающий WTRU при некоторых условиях может отвечать положительным подтверждением, если WTRU успешно принял повторную (-ые) широковещательную (-ые) передачу (-и). Подтверждение может быть передано до следующего повторения, так что вещающий WTRU может принимать его до передачи следующего повторения. Вещающий WTRU может определять, может ли он завершать повторение передачи. В одном варианте осуществления группе WTRU может быть разрешено передавать подтверждение. Например, вещающий WTRU может определять группу WTRU, которая может находиться далеко от него. Вещающий WTRU может указывать в кадре управления или кадре контроля, что группе WTRU может быть разрешено передавать подтверждение между повторными широковещательными передачами. Группа WTRU может передавать назад то же самое подтверждение одновременно, так что они могут быть выровнены на стороне приемника, и приемник может их декодировать.

В одном варианте осуществления кадр опроса или кадр многопользовательского блочного запроса ACK (MU-BAR) могут быть переданы до или после повторения передачи. В альтернативном варианте осуществления триггерный кадр пакета нулевых данных (NDP) может быть агрегирован с широковещательным кадром. Кадр опроса, кадр MU-BAR или триггерный кадр NDP могут запускать передачи подтверждения от одного или множества WTRU. Принимающий WTRU, который может быть опрошен или запущен, может отвечать положительным подтверждением, если он успешно принял повторную (-ые) широковещательную (-ые) передачу (-и). Вещающий WTRU может принимать положительное подтверждение и определять, может ли он завершать повторение передачи.

Вещающий WTRU может определять, может ли он завершать повторение. Или вещающий WTRU или AP могут конфигурировать, может ли вещающий WTRU завершать повторение. В одном варианте осуществления конфигурация может быть основана на том, может ли широковещательный кадр нацеливаться на ассоциированные WTRU или неассоциированные WTRU. Если кадр может быть передан неассоциированным WTRU или частично этим неассоциированным WTRU, вещающий WTRU не может преждевременно завершать повторение передач.

Максимальное количество повторений может быть определено АР или иным образом. AP может вещать количество максимальных повторений в своем маяке, запросе/ответе на ассоциацию, кадре пробного запроса/ответа или других типах кадров контроля/управления. В одном варианте осуществления AP может решить использовать большее максимальное количество повторений, если диапазон покрытия BSS может быть большим или AP может фиксировать много WTRU на границе соты. В противном случае AP может использовать меньшее максимальное количество повторений. На фиг. 13 показан пример повторения передачи с обратной связью. Как показано на фиг. 13, во время Tx1 WTRU1 принял передачу от AP, но WTRU2 и WTRU3 не приняли передачу. Следовательно, WTRU2 и WTRU3 могут отправлять NAK на AP. Затем во время Tx2 может быть выполнено повторение передачи. Затем WTRU2 успешно принял передачу. Но WTRU3 не принял. Затем во время Tx3 может быть выполнено повторение передачи. Затем WTRU3 принял передачу.

В одном варианте осуществления для надежности может быть использована широковещательная передача с множеством AP. WTRU могут ассоциироваться с одной или множеством AP (ассоциированными WTRU). AP могут осуществлять рассылку набору AP для широковещательной передачи (ассоциированные и неассоциированные WTRU). AP могут идентифицировать широковещательный ресурс (например, вся полоса, определенный RU). AP могут осуществлять рассылку схемы передачи широковещательного канала (BC). Например, AP могут отправлять разнесение с циклическим сдвигом (CSD) с указанием ID AP, соответствующего сдвига и/или циклического префикса (CP). AP могут отправлять CSD с тем же сдвигом и CP. AP могут отправлять передачу на основе временного интервала (например, временной сдвиг с индексом синхронизации). AP могут использовать метод JT (например, метод и индекс кластеризации дерева суффиксов (STC)). На фиг. 14 показан пример широковещательной передачи с множеством AP с CSD. На фиг. 15 показан пример широковещательной передачи с множеством AP с разделением по времени. На фиг. 16 показан пример широковещательной передачи с множеством AP со схемой пространственного разнесения передачи (например, пространственно-временным блочным кодом (STBC)).

В одном варианте осуществления повторение передачи может быть использовано для широковещательных/многоадресных кадров. Например, повторение передачи для широковещательных/многоадресных кадров может быть использовано с: различными самодекодируемыми RV, перемежителем с различным уровнем битов, перемежителем с различным уровнем символов (эквивалентным изменению сопоставления поднесущих) и/или с SIG, указывающим широковещательную передачу, PAID (например, ID ассоциации), RV, HARQ, ID перемежителя и/или следующей синхронизации.

В одном варианте осуществления может быть использовано повторение передачи на основе обратной связи. Например, повторение передачи может быть разделено по меньшей мере фиксированной продолжительностью (например, xIFS). xIFS может быть больше, чем SIFS или DIFS. Повторение на основе обратной связи может включать в себя использование опроса/многопользовательского блочного запроса ACK (MU-BAR). Некоторым WTRU может быть разрешено передавать назад подтверждение до следующего повторения, если передача успешно декодирована. В одном варианте осуществления предварительно выбранные удаленные WTRU могут передавать подтверждение (например, используя процедуру «ближний-дальний» в 802.11ay). АР, успешно получившая подтверждение, в некоторых случаях может завершать передачу. AP может периодически выполнять полное повторение для неассоциированных WTRU. Параметры передачи BCS (для ассоциированных WTRU) могут быть обобщены, и/или TCP/IP может быть сконфигурирован для неассоциированного/непередающего WTRU посредством пробного (-ых) запроса (-ов). ACK может указывать модули WTRU, группу WTRU, отчет обратной связи о пакете нулевых данных (NDP) и/или MU произвольного доступа.

Если подсеть AP выполнена с возможностью отправки одной и той же широковещательной информации от множества AP с автоматическим повтором (AR), настроенным для отправляемых кадров, или без него, WTRU, принимающий эти переданные кадры, должен иметь возможность идентифицировать кадры, содержащие те же данные широковещательной передачи или инкрементную версию избыточности данных широковещательной передачи. В этом случае WTRU может улучшать прием данных широковещательной передачи путем объединения кадров, если это необходимо, или игнорирования избыточных кадров, содержащих уже принятые данные. В случае, если AR представляет собой простое повторение (отправка версии избыточности одного и того же кадра от множества AP), WTRU должен иметь средство для определения, что он уже получил данные, чтобы игнорировать избыточные кадры, или что он не получил данные. WTRU должен знать, как объединять кадры для повышения вероятности того, что данные могут быть приняты. В случае, если AR имеет кадры инкрементной избыточности (IR), WTRU должен иметь средства получения информации о том, как он должен комбинировать инкрементные избыточные кадры, комбинировать кадры с идентичными данными и игнорировать кадры, содержащие данные, которые уже были приняты. В настоящее время не существует способа информирования WTRU о том, что кадры, отправляемые разными AP, содержат одни и те же данные широковещательной передачи или IR-версию данных, которые WTRU пытается принять.

Следующее описание будет посвящено планированию подсети для решения обсуждаемых выше проблем.

Подсеть AP может быть выполнена с возможностью широковещательной передачи одной и той же информации от множества АР. Такая подсеть может использовать способы для информирования WTRU о том, что широковещательная передача от множества AP содержит данные широковещательной передачи. Поскольку каждая AP является уникальным источником передачи, может быть использовано множество способов. В иллюстративном способе информирования WTRU о широковещательных данных подсеть AP может координировать использование одной и той же информации идентификатора широковещательной передачи. AP могут использовать одно или более из следующих информационных полей (например, в заголовке PLCP, заголовке MAC, корпусе MAC и/или сигнальном кадре) для предоставления информации идентификатора широковещательной передачи: индикатор множества AP, идентификатор субъекта, идентификатор, широковещательная передача, повторение передачи, индекс повторения, следующий кадр повторения или следующий маяк повторения. Вышеупомянутые поля будут дополнительно описаны ниже.

Поле индикатора множества AP может указывать на то, что кадр, а также связанный (-ые) с ним ID транслируется (-ются) множеством AP. Поле ID подсети может предоставлять уникальный идентификатор для подсети, и все AP в подсети могут использовать один и тот же идентификатор. Подсети могут координироваться, чтобы гарантировать, что разные подсети с перекрывающимися областями обслуживания имеют уникальные идентификаторы подсети. В одном примере идентификатор подсети может быть основан на MAC-адресе одной из АР в подсети. В другом примере может использоваться хэш SSID, хэш на основе местоположения AP, уникальный идентификатор подсети, назначенный администратором сети/подсети, или любой другой уникальный идентификатор.

Поле «идентификатор» (ID) может указывать ID назначения, ID источника, ID передатчика, ID приемника, ID широковещательной передачи, ID широковещательного канала и/или ID контента. Поле широковещательной передачи может быть использовано для указания того, является ли этот кадр широковещательным, многоадресным и/или одноадресным. Поле повторения передачи может быть использовано, чтобы указать, передается ли этот кадр повторно. Поле повторения передачи также может указывать тип используемого повторения (например, простое повторение или межкадровое кодирование).

Поле индекса повторений может указывать количество повторений передачи для текущей передачи. В одном из вариантов осуществления поле индекса повторений может быть передано с прямым отсчетом. В другом варианте осуществления поле индекса повторений может быть передано с обратным отсчетом, так что принимающие WTRU могут знать количество последующих повторений передачи. Поле следующего кадра повторения может указывать ожидаемое время для следующего кадра повторения. Поле следующего кадра повторения также может указывать тип кадра повторения, который должен быть отправлен в это время. Поле следующего маяка повторения может указывать ожидаемое время для следующего маяка повторения. В примере ожидаемое время может представлять собой продолжительность.

AP могут координировать и выбирать виртуальный SSID и/или MAC-адрес, который все AP в подсети будут использовать для широковещательной передачи (например, конкретного широковещательной передачи или определенного набора широковещательных передач). Все AP в подсети могут передавать одну и ту же информацию SSID (например, виртуальный SSID и/или MAC-адрес). Посредством передачи одной и той же информации SSID эти AP будут отображаться как одна вещающая AP для любого WTRU, принимающего широковещательные кадры, отправленные AP в подсети. AP, использующие виртуальный SSID и/или MAC-адрес, могут использовать одно или более из следующих информационных полей (например, в заголовке PLCP, заголовке MAC, корпусе MAC и/или сигнальном кадре) для предоставления информации идентификатора широковещательной передачи: индикатор виртуального SSID, виртуальный MAC-адрес, идентификатор, широковещательная передача, повторение передачи, индекс повторения, следующий кадр повторения и/или следующий маяк повторения. Вышеупомянутые поля будут дополнительно описаны ниже.

Поле индикатора виртуального SSID может быть одним битом, указывающим, что SSID является виртуальным SSID, или это может быть несколько битов, предоставляющих информацию о типе указанного виртуального SSID. Поле виртуального MAC-адреса может быть одним битом, указывающим, что MAC-адрес AP является виртуальным MAC-адресом, или это может быть несколько битов, предоставляющих информацию о типе указанного виртуального MAC-адреса.

Поле «идентификатор» (ID) может указывать ID назначения, ID источника, ID передатчика, ID приемника, ID широковещательной передачи, ID широковещательного канала и/или ID контента. Поле широковещательной передачи может быть использовано для указания того, является ли этот кадр широковещательным, многоадресным и/или одноадресным. Поле повторения передачи может быть использовано, чтобы указать, передается ли этот кадр повторно. Поле повторения передачи также может указывать тип используемого повторения (например, простое повторение или межкадровое кодирование).

Поле индекса повторений может указывать количество повторений передачи для текущей передачи. В одном из вариантов осуществления поле индекса повторений может быть передано с прямым отсчетом. В другом варианте осуществления поле индекса повторений может быть передано с обратным отсчетом, так что принимающие WTRU могут знать количество последующих повторений передачи. Поле следующего кадра повторения может указывать ожидаемое время для следующего кадра повторения. Поле следующего кадра повторения также может указывать тип кадра повторения, который должен быть отправлен в это время. Поле следующего маяка повторения может указывать ожидаемое время для следующего маяка повторения. В одном варианте осуществления ожидаемое время может быть продолжительностью.

Процедуры могут быть использованы для обеспечения надежности широковещательной передачи по UL. В широковещательной передаче по DL может быть задействовано несколько передатчиков и приемников, и каждый приемник может представлять конечную точку услуги широковещательной передачи, расположенную внутри WTRU без АР. Это может усложнить протокол множественный доступ с контролем несущей (CSMA)/ARQ уровня MAC для данных широковещательной передачи, поскольку разные пары передатчик-приемник могут иметь разный статус успеха/неудачи. Например, множеству AP может потребоваться знать идентификаторы (неассоциированных) широковещательных приемников, чтобы назначить ресурсы обратной связи в направлении UL. Кроме того, множеству AP может потребоваться координировать действия между собой, чтобы знать, какой MAC PDU (MPDU)/блок данных отсутствует для по меньшей мере одного WTRU, перед попыткой повторной передачи.

Надежность широковещательной передачи по UL также может быть проблемой. Как показано на фиг. 17, UL WTRU 1701 не знает статуса приемника (или статистику принятых блоков данных протокола (PPDU) процедуры конвергенции физического уровня (PLCP) в течение некоторой продолжительности времени), что показано как «Имеет ли WTRU информацию о том, успешен ли PPDU, без входных данных более высокого уровня?» Примером требования к передаваемым данным может быть то, что потеря данных недопустима, и для потерянных данных необходимы повторные передачи. В этом случае без знания уровня протокола 802.11 UL WTRU 1701 может потребоваться ассоциация с BSS (или соединение с другим доступом), чтобы иметь одноадресное соединение для обмена данными для запуска повторной передачи. Другим примером требования к передаваемым данным может быть то, что потеря данных допустима, но нежелательна. В этом случае обратная связь от приемника может улучшать качество PPDU, передаваемых в будущем.

В широковещательной передаче по UL разные приемники вещательного пакета UL представляют одну конечную точку широковещательной передачи, и имеется только один передатчик (т.е. есть состояние одного (совместного) приемника, на основании которого может действовать один передатчик). Это делает протокол CSMA/ARQ уровня MAC более вероятным в UL. Это помогает устранить ошибку беспроводной связи или повысить надежность передаваемых позже данных (повторно переданных или новых), и WTRU без AP не нужно полагаться исключительно на одноадресное соединение с узлом-приемником широковещательной передачи через верхний уровень для обеспечения надежности.

Приведенные в качестве примера процедуры для широковещательной передачи по UL могут быть или могут не быть применены к PPDU на основе PPDU (например, могут быть применимы к обратной связи в течение периода времени после широковещательной передачи по UL, и в течение этого времени передатчик UL 802.11 MAC сохраняет информацию, в повторной передаче которой может возникнуть необходимость). UL WTRU может основывать широковещательную передачу по UL на обратной связи, чтобы регулировать устойчивость PPDU, которые должны быть отправлены после обратной связи, без выполнения повторных передач потерянных данных. Примеры процедур для широковещательной передачи по UL могут быть применимы к невещательным PPDU, отправленным в направлении UL в конфигурации с множеством AP, где одна AP является якорной или главной AP, а другие AP являются вспомогательными приемниками или подчиненными AP для якорной AP.

На фиг. 18 показан пример передатчика для получения совместной обратной связи в качестве средства обеспечения обратной связи для повышения устойчивости. В пакете широковещательной передачи по UL, запрашивающем обратную связь, передающий WTRU 1801 может указывать MCS, инициирование скремблера и/или более длинный защитный интервал (GI), который должен быть использован в запрашиваемой обратной связи DL. В одном варианте осуществления предварительно определенный MCS/GI может быть использован для PPDU обратной связи в DL, и/или инициирование скремблера PPDU обратной связи может быть установлено на то же значение, что и в запрашивающем PPDU широковещательной передачи по UL.

В одном варианте осуществления PPDU широковещательной передачи по UL может указывать одну или более AP, которым разрешено осуществлять обратную связь, чтобы ограничить разброс задержки сигнала обратной связи. Если передающий WTRU не принимает никакой обратной связи, тогда передающий WTRU может делать вывод, что все AP заняты/подвержены помехам, и может выполнять отложенную (повторную) передачу. Если WTRU не использует процедуру обратной связи для выполнения повторной передачи (т.е. без повторной передачи для широковещательных PPDU), WTRU может основывать свою передачу на обратной связи, чтобы отрегулировать устойчивость PPDU (например, мощность, MCS) для отправки в будущем. Если множество AP успешно приняли PPDU широковещательной передачи по UL, их кадры обратной связи могут быть объединены по беспроводной связи и декодированы как один PPDU в WTRU без AP.

На фиг. 19 показана другая приведенная в качестве примера процедура для обеспечения AP обратной связи DL, так что передатчик может получать совместную обратную связь (например, для каждого MPDU/блока данных в одном или более агрегированных MPDU (AMPDU), переданных по UL). Может быть использован механизм, который позволяет передавать AMPDU без необходимости предварительного обмена для установки соглашения об обратной связи. Такое соглашение о незапрошенной обратной связи может быть использовано в широковещательной передаче по UL. Параметры для соглашения (например, размер буфера, значение времени ожидания) могут быть установлены равными предварительно определенным значениям для всех WTRU, поддерживающих широковещательную передачу по UL.

Для приема единого совместного битового отображения обратной связи, соответствующего блокам данных/MPDU, может быть использован подход обратной связи NDP, например, с амплитудной манипуляцией на основе положительной обратной связи. Тональный набор, указывающий статус 0, может не передаваться, тогда как тональный набор, указывающий статус 1, может передаваться AP. Длинное обучающее поле (LTF) NDP может содержать более длинный GI, чтобы покрывать разницу задержек распространения от разных AP до исходного передатчика/передатчика, то есть WTRU 1901 без AP.

PPDU широковещательной передачи по UL может указывать начальный порядковый номер. Сигнал ACK в каждом тональном наборе может представлять бит обратной связи для MPDU/блока данных со смещением порядкового номера относительно начального порядкового номера. На основе энергии тонального набора исходный передатчик/передатчик (то есть WTRU без АР) может получать статус приема порядкового номера MPDU/блока данных на основе соответствующего индекса тонального набора.

Поскольку обратная связь NDP может быть амплитудной манипуляцией на основе положительной обратной связи, NDP обратной связи, инициированный PPDU широковещательной передачи по UL, может рассматриваться исходным передатчиком как единый NDP. Когда исходный передатчик обнаруживает NDP, соответствующие отсутствующие MPDU/блоки данных могут быть повторно переданы. Если NDP не обнаружен, исходный передатчик может делать вывод, что все приемники (например, AP) подвержены помехам/заняты, и может выполнять отложенную (повторную) передачу. Если WTRU не использует процедуру обратной связи для выполнения повторной передачи (т.е. без повторной передачи для широковещательных PPDU), WTRU может осуществлять свою передачу на основе обратной связи, чтобы отрегулировать устойчивость PPDU (например, мощность, MCS) для отправки в будущем.

Хотя признаки и элементы описаны выше в конкретных комбинациях, специалисту в данной области будет очевидно, что каждый признак или элемент можно использовать отдельно или в любой комбинации с другими признаками и элементами. Кроме того, описанные в настоящем документе способы могут быть реализованы в компьютерной программе, программном обеспечении или программно-аппаратном обеспечении, встроенном в машиночитаемый носитель и предназначенном для исполнения компьютером или процессором. Примеры машиночитаемого носителя включают в себя электронные сигналы (переданные по проводным или беспроводным соединениям) и машиночитаемые носители информации. Примеры машиночитаемого носителя информации включают в себя, без ограничений, постоянное запоминающее устройство (ПЗУ), оперативное запоминающее устройство (ОЗУ), регистр, кэш-память, полупроводниковые устройства хранения данных, магнитные носители, такие как внутренние жесткие диски и съемные диски, магнитооптические носители и оптические носители, такие как диски CD-ROM и цифровые универсальные диски (DVD). Процессор в сочетании с программным обеспечением можно использовать для реализации радиочастотного приемопередатчика, предназначенного для применения в составе WTRU, UE, терминала, базовой станции, RNC и/или любого главного компьютера.

1. Способ беспроводной связи для применения в станции (STA), включающий:

генерирование объектом управления станцией (SME) примитива запроса, обеспечивающего процесс сканирования пробуждающих радиоустройств (WUR) для кадров обнаружения WUR, передаваемых одной или более точками доступа (AP), причем примитив запроса содержит множество первых параметров, включающих в себя по меньшей мере часть CompressedBSSID и MinDiscoveryChannelTime;

выполнение процесса сканирования WUR на основе множества первых параметров;

генерирование по меньшей мере одного примитива подтверждения на основе результата процесса сканирования WUR и по меньшей мере подмножества из множества первых параметров, при этом каждый из по меньшей мере одного примитива подтверждения содержит множество вторых параметров, включающих в себя по меньшей мере часть CompressedBSSID; и

передачу на SME по меньшей мере одного примитива подтверждения.

2. Способ по п. 1, в котором множество первых параметров дополнительно содержит по меньшей мере один из идентификатора базового набора служб (BSSID), BSSIDList, идентификатора набора служб (SSID), SSIDList, compressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MaxDiscoveryChannelTime, MaxScanningTime, ReceivedPowerThreshod, WURScanningMode, WURScanningReportingOption или RequestWURresult.

3. Способ по п. 2, в котором WURScanningMode указывает режим сканирования WUR.

4. Способ по п. 1, в котором множество вторых параметров дополнительно содержит BSSDescriptionFromWURDFSet.

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

6. Способ по п. 1, в котором примитив запроса представляет собой примитив MLME-WURSCAN.Request.

7. Способ по п. 1, в котором примитив запроса генерируется объектом управления станцией (SME).

8. Способ по п. 1, в котором примитив запроса представляет собой примитив MLME-SCAN.Request.

9. Способ по п. 1, дополнительно включающий генерирование примитива запроса остановки для остановки процесса сканирования WUR.

10. Способ по п. 1, дополнительно включающий генерирование примитива подтверждения остановки.

11. Беспроводная станция (STA), содержащая:

процессор, выполненный с возможностью

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

выполнения процесса сканирования WUR на основе множества первых параметров,

генерирования по меньшей мере одного примитива подтверждения на основе результата процесса сканирования WUR и по меньшей мере подмножества из множества первых параметров, при этом каждый из по меньшей мере одного примитива подтверждения содержит множество вторых параметров, включающих в себя по меньшей мере часть битов CompressedBSSID, и

передачи на объект управления станцией (SME) по меньшей мере одного примитива подтверждения.

12. STA по п. 11, причем множество первых параметров содержит по меньшей мере один из BSSID, BSSIDList, SSID, SSIDList, CompressedBSSID, compressedSSID, CompressedBSSIDList, CompressedSSIDList, DiscoveryChannel, DiscoveryChannelList, MinDiscoveryChannelTime, MaxDiscoveryChannelTime, MasScanningTime, ReceivedPowerThreshod, WURScanningMode, WURScanningReportingOption или RequestWURresult.

13. STA по п. 12, причем WURScanningMode указывает режим сканирования WUR.

14. STA по п. 11, причем множество вторых параметров дополнительно содержит BSSDescriptionFromWURDFSet.

15. STA по п. 11, дополнительно содержащая приемопередатчик, причем процессор и приемопередатчик выполнены с возможностью ассоциации с базовым набором служб (BSS) на основе одного или более из второго множества параметров по меньшей мере одного примитива подтверждения.

16. STA по п. 11, в которой примитив запроса представляет собой примитив MLME-WURSCAN.Request.

17. STA по п. 11, в которой примитив запроса генерируется объектом управления станцией (SME).

18. STA по п. 11, в которой примитив запроса представляет собой примитив MLME-SCAN.Request.

19. STA по п. 11, в которой процессор дополнительно выполнен с возможностью генерирования примитива запроса остановки для остановки процесса сканирования WUR.

20. STA по п. 11, в которой процессор дополнительно выполнен с возможностью генерирования примитива подтверждения остановки.