УСТРОЙСТВО И СПОСОБ ПЕРЕДАЧИ И ПРИЕМА СИГНАЛОВ С ПОМОЩЬЮ ИНФОРМАЦИИ КАНАЛА НИСХОДЯЩЕЙ ЛИНИИ СВЯЗИ В ДЕЖУРНОМ РЕЖИМЕ В СИСТЕМЕ BWA-СВЯЗИ
DEVICE AND METHOD FOR SYGNALS TRANSMISSION AND RECEPTION BY MEANS OF INFORMATION OF DOWNLINK LINE IN STANDBY MODE IN BWA-COMMUNICATION SYSTEM

Область техники, к которой относится изобретение
Настоящее изобретение, в общем, относится к системе связи с широкополосным беспроводным доступом (BWA), а более конкретно к устройству и способу передачи и приема сигналов между мобильной станцией (MS) и базовой станцией (BS), когда происходит изменение в информации канала нисходящей линии связи, когда MS находится в дежурном (спящем) режиме.
Уровень техники
В системе связи четвертого поколения (4G), которая является системой связи следующего поколения, активно проводились исследования на предмет того, чтобы предоставлять пользователям услуги, имеющие различное качество обслуживания (QoS), на высокой скорости передачи. В последнее время в системе связи 4G активно проводились исследования с тем, чтобы поддерживать высокоскоростные услуги, при этом обеспечивая мобильность и QoS в системе связи с широкополосным беспроводным доступом (BWA), такой как система беспроводной локальной вычислительной сети (LAN, ЛВС) и система беспроводной городской вычислительной сети (MAN, ГВС). Типичная система связи, разработанная таким образом, чтобы достигать целей, упомянутых выше, включает в себя систему связи IEEE (Институт инженеров по электротехнике и электронике) 802.16e.
Система связи IEEE 802.16e использует схему мультиплексирования с ортогональным частотным разделением каналов (OFDM) и схему множественного доступа с ортогональным частотным разделением каналов (OFDMA), чтобы поддерживать сеть широковещательной передачи для физического канала системы беспроводной ГВС.
Фиг.1 - блок-схема, схематично иллюстрирующая традиционную систему мобильной связи IEEE 802.16e. Ссылаясь на фиг.1, система связи IEEE 802.16e имеет структуру с несколькими сотами, включающую в себя соту 100 и соту 150. Кроме того, система связи IEEE 802.16e включает в себя BS 110, управляющую сотой 100, BS 140, управляющую сотой 150, и множество MS 111, 113, 130, 151 и 153. Передача и прием сигналов между BS 110 и 140 и MS 111, 113, 130, 151 и 153 осуществляется с помощью схемы OFDM/OFDMA. В данном документе MS 130 размещается в граничной области, т.е. в области передачи обслуживания между сотой 100 и сотой 150. Следовательно, когда MS 130 перемещается в соту 150, управляемую посредством BS 140, во время выполнения передачи и приема для BS 110, обслуживающая BS для MS 130 изменяется с BS 110 на BS 140.
В системе связи IEEE 802.16e энергопотребление MS играет важную роль в производительности всей системы. Следовательно, работа в дежурном режиме и работа в активном режиме, соответствующая работе в дежурном режиме, предложена для BS и MS, чтобы минимизировать энергопотребление MS. Дополнительно, чтобы справляться с изменением состояния канала между MS и BS, MS периодически выполняет ранжирование (процесс согласования) для корректировки ошибки синхронизации, сдвига частоты и мощности передачи между BS и MS.
Далее описываются операции при распределении профиля пакетов нисходящей линии связи в типичной системе связи IEEE 802.16a.
Сначала, когда питание MS включается, MS отслеживает все частотные диапазоны, заданные заранее в MS, и обнаруживает пилот-сигнал, имеющий наибольшую интенсивность, т.е. наибольшее отношение мощности сигнала на несущей к помехе и шуму (CINR). Дополнительно MS определяет BS, передающую пилот-сигнал, имеющий наибольшее CINR, в качестве обслуживающей BS, которая является BS, которой MS в данный момент принадлежит. После этого MS принимает преамбулу (заголовок) кадра нисходящей линии связи, переданного от обслуживающей BS, и достигает синхронизации системы между MS и обслуживающей BS.
Когда MS синхронизируется с обслуживающей BS, обслуживающая BS передает сообщение DL(нисходящая линия связи)_MAP и сообщение UL(восходящая линия связи)_MAP в MS. Сообщение DL_MAP имеет формат сообщения, показанный в таблице 1 ниже.
Таблица 1
Синтаксис
Размер
Примечания
DL_MAP_Message_Format () {
Management Message Type = 2
8 битов
PHY Synchronization Field
Переменный
См. соответствующую спецификацию протокола PHY
DCD Count
8 битов
Base Station ID
48 битов
Number of DL MAP Element n
16 битов
Begin PHY Specification section{
См. применимый раздел спецификации PHY
for (i=1 i<=n; i++)
Для каждого элемента DL_MAP от 1 до n
DL_MAP Information Element ( )
Переменный
См. соответствующую спецификацию протокола PHY
If! byte boundary) { Padding Nibble
4 бита
Заполнение свободного места пробелами для достижения предела по байтам
}
}
}
}
Как показано в табл. 1, сообщение DL_MAP содержит множество информационных элементов (IE), таких как Management Message Type, представляющий тип сообщения, которое должно быть передано, PHY Synchronization, задаваемый в соответствии со схемой модуляции и схемой демодуляции, применяемым к физическому (PHY) каналу для достижения синхронизации, DCD Count, представляющий счетчик, соответствующий изменениям в конфигурации сообщения дескриптора канала нисходящей линии связи (DCD), включающего в себя профиль пакетов нисходящей линии связи, Base Station ID, представляющий идентификатор BS, и Number of DL_MAP Elements n, представляющий число элементов после Base Station ID. Сообщение DL_MAP в таблице 1 содержит число n элементов IE DL_MAP, каждый из которых включает в себя код использования интервала передачи по нисходящей линии связи (DIUC), который имеет значение, соответствующее профилю пакетов нисходящей линии связи, включенному в сообщение DCD. Т.е. MS может обнаружить информацию о схеме кодирования (типе кода прямого исправления ошибок (FEC)) и схеме модуляции, применяемой к пакетам нисходящей линии связи, включенным в кадр нисходящей линии связи, посредством извлечения значения DIUC из сообщения DL_MAP. Следовательно, MS может принимать данные (кадр данных) в пакете нисходящей линии связи, идентифицирующие пакеты нисходящей линии связи в кадре нисходящей линии связи.
Когда происходит перемещение MS или изменение окружающих условий канала MS вызывает изменение значения CINR пилот-сигнала, принимаемого MS от обслуживающей BS, необходимо также изменять значение DIUC, применяемое к данным, которые должны передаваться посредством MS, в соответствии с изменением значения CINR пилот-сигнала.
Дополнительно, когда BS необходимо изменить профиль пакетов нисходящей линии связи, BS изменяет профиль пакетов и затем передает сообщение DCD, включающее в себя информацию об изменении, в MS. Затем посредством приема сообщения DCD MS может обнаружить изменение в профиле пакетов нисходящей линии связи из сообщения DCD.
Тем не менее, когда профиль пакетов нисходящей линии связи изменяется, т.е. сообщение DCD изменяется в то время, когда MS находится в дежурном режиме, MS не может обнаруживать изменение сообщения DCD в реальном времени, поскольку MS находится в дежурном режиме.
Фиг. 2 схематично иллюстрирует работу MS, когда сообщение DCD изменяется в то время, когда MS находится в дежурном режиме, в традиционной системе связи IEEE 802.16e. На фиг. 2 и MS и BS настраивают протоколы для схем модуляции и схем кодирования при приеме и передаче до передачи и приема сигналов между собой. Настройка протоколов для схем модуляции и схем кодирования осуществляется посредством передачи и приема профиля пакетов нисходящей линии связи, т.е. передачи и приема сообщения DCD.
Дополнительно необходимо подготовить протоколы для схем модуляции и схем кодирования между BS и MS, чтобы дать возможность MS штатным образом возобновлять передачу/прием данных после "пробуждения" из дежурного режима.
Тем не менее, поскольку MS вообще не принимает никаких сигналов от BS в ходе интервала дежурного режима, когда MS остается в дежурном режиме, MS не может обнаруживать никаких изменений в профиле пакетов нисходящей линии связи, т.е. в наборе DIUC, сделанных BS в интервале дежурного режима. Когда DIUC, используемые посредством MS и BS, не совпадают вследствие работы MS в дежурном режиме, невозможно передавать и принимать данные между MS и BS.
Далее описываются различные сценарии, в которых DIUC, используемые посредством MS и BS, перестают совпадать вследствие работы MS в дежурном режиме.
Первый случай соответствует тому, когда сообщение DCD изменяется в то время, когда MS осуществляет работу в дежурном режиме, т.е. в то время, когда MS остается в интервале дежурного режима.
В системе связи IEEE 802.16e MS обнаруживает счетчик DCD, включенный в текущее принятое сообщение DL_MAP, и сравнивает обнаруженное значение со значением счетчика DCD, в данный момент сохраненным в самой MS. Если значение счетчика DCD, включенное в сообщение DL_MAP, в данный момент принятое посредством MS, и значение счетчика DCD, в данный момент сохраненное в MS, отличаются, MS обнаруживает изменение в сообщении DCD. Т.е. поскольку значения счетчика DCD отличаются, номера версий профилей пакетов нисходящей линии связи отличаются. Следовательно, MS может обнаруживать номер версии профиля пакетов нисходящей линии связи с помощью значения счетчика DCD.
Тем не менее, в текущей системе связи IEEE 802.16e невозможно сообщать об изменении профиля пакетов нисходящей линии связи в MS, которая "пробудилась" из дежурного режима. Следовательно, если BS передает данные нисходящей линии связи в MS с помощью профиля пакетов нисходящей линии связи самой BS без обнаружения того, что профиль пакетов нисходящей линии связи BS отличается от профиля пакетов нисходящей линии связи, сохраненного в MS, MS не может штатным образом принимать данные нисходящей линии связи.
Вышеуказанный сценарий подробнее описывается далее со ссылкой на фиг. 2.
Тем не менее, сначала следует отметить, что фиг. 2 основана на том допущении, что параметр, обозначающий значение счетчика DCD, управляемое посредством BS 200, - это N, параметр, обозначающий значение счетчика DCD, управляемое посредством MS 250, - это M, и два параметра N и M имеют начальное значение 0. Когда BS 200 обнаруживает, что необходимо изменить профиль пакетов нисходящей линии связи, в то время когда MS 250 находится в дежурном режиме, т.е. в интервале дежурного режима, BS задает значение счетчика DCD N, которое управляется посредством BS 200, равным 1 (N=1) на этапе 211, и передает измененное сообщение DCD на этапе 213. Хотя BS 200 передала измененное сообщение DCD, MS 250 в интервале дежурного режима не может обнаруживать изменение сообщения DCD. Следовательно, MS 250 сохраняет значение 0 (M=0) параметра, обозначающего значение счетчика DCD, которое управляется посредством самой MS 250, на этапе 215.
Когда интервал дежурного режима завершается, MS 250 принимает сообщение DL_MAP от BS 200 в интервале прослушивания на этапе 217. В сообщении DL_MAP значение счетчика DCD, более конкретно значение параметра N, представляющее значение счетчика DCD, управляемое посредством BS 200, задается равным 1. Следовательно, MS 250 обнаруживает из значения счетчика DCD, что необходимо принять новое сообщение DCD от базовой станции BS 200.
После того, как интервал прослушивания завершается, MS 200 переходит в дежурный режим и ожидает сообщения DCD на этапе 219. Когда BS 200 обнаруживает появление данных, предназначенных для MS 250, в то время когда MS 250 находится в дежурном режиме, BS 200 передает в MS 250 сообщение TRF_IND, указывающее то, что имеются данные, которые должны быть переданы, предназначенные для MS 250, т.е. сообщение TRF_IND, в котором бит, представляющий MS 250 в битовой карте идентификатора дежурного режима, помечается посредством положительного значения, т.е. 1, на этапе 221.
После передачи сообщения TRF_IND BS 200 передает данные в MS 250 на этапе 223. Тем не менее, как описано выше, хотя BS 200 передает данные с помощью нового измененного профиля пакетов нисходящей линии связи, MS 250 по-прежнему использует профиль пакетов нисходящей линии связи до изменения. Как результат, значение DIUC, применяемое к данным, передаваемым от BS 200 в MS 250, отличается от значения DIUC, сохраненного в MS 250, и MS 250 не может штатным образом демодулировать данные, передаваемые от BS 200, на этапе 225.
Как описано выше, в первом сценарии коды DIUC, используемые посредством MS и BS, становятся различными, т.е. перестают совпадать вследствие изменения сообщения DCD в то время, когда MS осуществляет работу в дежурном режиме, т.е. в то время, когда MS остается в интервале дежурного режима.
Тем не менее, как описано ниже, во втором сценарии коды DIUC, используемые посредством MS и BS, становятся различными вследствие работы MS в дежурном режиме, поскольку сама MS изменяет значение DIUC, чтобы быть надлежащим для MS, в то время когда MS осуществляет работу в дежурном режиме, т.е. в то время, когда MS остается в интервале дежурного режима.
Более конкретно, когда MS перемещается в то время, когда она находится в интервале дежурного режима или когда окружающие условия канала MS изменяются, чтобы значение CINR сигнала канала пилот-сигнала от обслуживающей BS стало отличным от этого значения до того, как MS перейдет в дежурный режим, MS изменяет значение DIUC, чтобы оно было надлежащим для самой MS. Например, когда значение CINR сигнала канала пилот-сигнала, измеренное в то время, когда MS находится в интервале дежурного режима, становится меньше значения CINR сигнала канала пилот-сигнала, измеренного до того, как MS переходит в интервал дежурного режима, если MS передает данные в BS с помощью имеющегося значения DIUC без обновления, существует большая вероятность того, что данные, передаваемые посредством MS, имеют ошибку.
Как описано выше, в текущей системе связи IEEE 802.16e, если сообщение DCD изменяется в то время, когда MS находится в дежурном режиме, невозможно штатным образом выполнять передачу и прием данных, тем самым вызывая потерю данных. Потеря данных может ухудшить общую производительность системы связи IEEE 802.16e, предназначенной для высокоскоростной передачи данных. Следовательно, существует потребность в решении для передачи и приема данных, отражающем изменение сообщения DCD в реальном времени.
Сущность изобретения
Следовательно, настоящее изобретение предназначено для разрешения вышеуказанных и других проблем, возникающих в предшествующем уровне техники. Задача настоящего изобретения заключается в том, чтобы создать систему и способ передачи и приема сигналов, когда информация канала нисходящей линии связи изменяется в дежурном (спящем) режиме системы связи с широкополосным беспроводным доступом.
Другая задача настоящего изобретения заключается в том, чтобы создать систему и способ для уведомления об изменении информации канала нисходящей линии связи от MS к BS, когда информация канала нисходящей линии изменяется в дежурном режиме системы связи с широкополосным беспроводным доступом.
Другая задача настоящего изобретения заключается в том, чтобы создать систему и способ для запроса об изменении в информации канала нисходящей линии связи от MS к BS, когда информация канала нисходящей линии изменяется в дежурном режиме системы связи с широкополосным беспроводным доступом.
Чтобы решить вышеуказанные и другие задачи, предложено устройство для передачи и приема сигнала согласно изменению информации канала нисходящей линии связи в системе связи с широкополосным беспроводным доступом. Устройство содержит мобильную станцию для обнаружения изменения информации канала нисходящей линии связи, приема уведомления о том, что имеются данные, которые мобильная станция должна принять, и уведомления об изменении информации канала нисходящей линии связи; и базовую станцию для изменения информации канала нисходящей линии связи и передачи в мобильную станцию измененной информации канала нисходящей линии связи, включающей в себя информацию, уведомляющую об изменении информации канала нисходящей линии связи, уведомления о наличии данных, которые должны быть переданы в мобильную станцию, установления соответствия информации канала нисходящей линии связи базовой станции и мобильной станции друг с другом посредством заданной схемы и передачи данных в мобильную станцию с помощью согласованной информации канала нисходящей линии станции, когда базовая станция примет уведомление об изменении информации канала нисходящей линии станции от мобильной станции.
В соответствии с другим аспектом настоящего изобретения предложен способ передачи и приема сигнала согласно изменению информации канала нисходящей линии связи посредством мобильной станции в системе связи с широкополосным беспроводным доступом. Способ заключается в том, что обнаруживают изменение информации канала нисходящей линии связи, принимают уведомление от базовой станции о том, что имеются данные для приема мобильной станцией, и уведомляют базовую станцию об изменении информации канала нисходящей линии связи, тем самым указывая то, что базовая станция и мобильная станция имеют одинаковую информацию канала нисходящей линии связи.
В соответствии с другим аспектом настоящего изобретения предложен способ передачи и приема сигнала согласно изменению информации канала нисходящей линии связи посредством базовой станции в системе связи с широкополосным беспроводным доступом. Способ заключается в том, что изменяют информацию канала нисходящей линии связи; передают в мобильную станцию измененную информацию канала нисходящей линии связи, включающую в себя информацию, уведомляющую об изменении информации канала нисходящей линии связи, уведомляют о наличии данных, которые должны быть переданы в мобильную станцию, устанавливают соответствие информации канала нисходящей линии связи базовой станции и мобильной станции друг с другом посредством одной схемы из первой заданной схемы и второй заданной схемы и передают данные в мобильную станцию с помощью согласованной информации канала нисходящей линии связи, когда базовая станция примет уведомление об изменении информации канала нисходящей линии станции от мобильной станции.
Краткое описание чертежей
Вышеуказанные и другие задачи, признаки и преимущества настоящего изобретения станут более понятными из последующего подробного описания, рассматриваемого вместе с прилагаемыми чертежами, из которых:
Фиг. 1 - блок-схема, схематично иллюстрирующая традиционную систему мобильной связи IEEE 802.16e;
Фиг. 2 схематично иллюстрирует работу MS, когда сообщение DCD изменяется в то время, когда MS находится в дежурном режиме, в традиционной системе связи IEEE 802.16e;
Фиг. 3 схематично иллюстрирует работу MS, когда сообщение DCD изменяется в то время, когда MS находится в дежурном режиме, в системе связи IEEE 802.16e согласно варианту осуществления настоящего изобретения;
Фиг. 4 - блок-схема последовательности операций способа работы MS в системе связи IEEE 802.16e согласно варианту осуществления настоящего изобретения; и
Фиг. 5 - блок-схема последовательности операций способа работы BS в системе связи IEEE 802.16e согласно варианту осуществления настоящего изобретения.
Подробное описание предпочтительного
варианта осуществления
Далее описаны предпочтительные варианты осуществления настоящего изобретения со ссылками на прилагаемые чертежи. В последующем подробное описание известных функций и конфигураций, содержащихся в данном документе, опущено в случаях, когда это может отвлечь от предмета настоящего изобретения.
Настоящее изобретение предлагает схему передачу и приема сигналов посредством мобильной станции (MS) согласно изменению информации канала нисходящей линии связи в системе связи согласно стандарту Института инженеров по электротехнике и электронике (IEEE) 802.16e, которая является системой связи с широкополосным беспроводным доступом (BWA). Т.е. настоящее изобретение предлагает схему передачи и приема сигналов с помощью одного кода использования интервала передачи по нисходящей линии связи (DIUC) между BS и MS посредством уведомления об изменении сообщения дескриптора канала нисходящей линии связи (DCD), т.е. изменении значения счетчика DCD, от MS к BS, когда сообщение DCD изменяется в то время, когда MS находится в дежурном режиме в системе связи IEEE 802.16e.
Кроме того, настоящее изобретение предлагает схему надежной передачи и приема сигналов между BS и MS посредством запроса в реальном времени об изменении DIUC от MS к BS, когда значение отношения мощности сигнала на несущей к помехе и шуму (CINR) опорного сигнала, к примеру сигнала канала пилот-сигнала, измеренное в то время, когда MS находится в интервале дежурного режима, становится меньше значения CINR опорного сигнала, измеренного до того, как MS перешла в дежурный режим, в системе связи IEEE 802.16e.
Система связи IEEE 802.16e - это BWA-система связи, использующая схему мультиплексирования с ортогональным частотным разделением каналов (OFDM) и множественного доступа с ортогональным частотным разделением каналов (OFDMA), в которой сигналы физического канала передаются посредством множества поднесущих, чтобы обеспечить высокоскоростную передачу данных, и структура с множеством сот используется для того, чтобы поддерживать мобильность MS. Хотя система связи IEEE 802.16e используется в данном документе как вариант осуществления настоящего изобретения, следует отметить, что настоящее изобретение может быть применено к любым системам связи, поддерживающим работу в дежурном режиме.
Фиг.3 схематично иллюстрирует работу MS, когда сообщение DCD изменяется в то время, когда MS находится в дежурном режиме, в системе связи IEEE 802.16e, согласно варианту осуществления настоящего изобретения.
Как показано на фиг. 1 и 2, и MS и BS настраивают протоколы для схем модуляции и схем кодирования при приеме и передаче до передачи/приема сигналов между собой. Настройка протоколов для схем модуляции и схем кодирования осуществляется посредством передачи и приема профиля пакетов нисходящей линии связи, т.е. передачи и приема сообщения DCD. Дополнительно необходимо подготовить протоколы для схем модуляции и схем кодирования между BS и MS, чтобы дать возможность MS штатным образом возобновлять передачу и прием данных после "пробуждения" из дежурного режима. Тем не менее, поскольку MS вообще не принимает никаких сигналов от BS в ходе интервала дежурного режима, когда MS остается в дежурном режиме, MS не может обнаруживать никаких изменений в профиле пакетов нисходящей линии связи, т.е. в наборе DIUC, сделанных BS в интервале дежурного режима. Когда DIUC, используемые посредством MS и BS, перестают совпадать вследствие работы MS в дежурном режиме, невозможно передавать и принимать данные между MS и BS.
Т.е. когда сообщение DCD изменяется в то время, когда MS осуществляет работу в дежурном режиме, т.е. MS находится в интервале дежурного режима, MS обнаруживает счетчик DCD, включенный в текущее принятое сообщение DL_MAP, и сравнивает обнаруженное значение со значением счетчика DCD, в данный момент сохраненным в самой MS, в системе связи IEEE 802.16e. Если значение счетчика DCD, включенное в сообщение DL_MAP, в данный момент принятое посредством MS, и значение счетчика DCD, в данный момент сохраненное в MS, отличаются, MS обнаруживает изменение в сообщении DCD. Т.е. поскольку значения счетчика DCD отличаются, номера версий профилей пакетов нисходящей линии связи отличаются. Следовательно, MS обнаруживает номер версии профиля пакетов нисходящей линии связи с помощью значения счетчика DCD.
Как описано выше, в текущей системе связи IEEE 802.16e невозможно сообщать об изменении профиля пакетов нисходящей линии связи в MS, которая "пробудилась" из дежурного режима. Следовательно, если BS передает данные нисходящей линии связи в MS с помощью профиля пакетов нисходящей линии связи самой BS без обнаружения того, что профиль пакетов нисходящей линии связи BS отличается от профиля пакетов нисходящей линии связи, сохраненного в MS, MS не может штатным образом принимать данные нисходящей линии связи от BS.
Следовательно, предлагает схему передачи и приема данных между MS и BS с помощью DIUC, который обновляется таким образом, чтобы быть одинаковым, когда изменяется сообщение DCD, что описывается далее со ссылкой на фиг. 3.
Тем не менее, сначала следует отметить, что фиг. 3 основана на том допущении, что параметр, обозначающий значение счетчика DCD, управляемое посредством BS 300, - это N, параметр, обозначающий значение счетчика DCD, управляемое посредством MS 350, - это M, и два параметра N и M имеют начальное значение 0. Когда BS 300 обнаруживает, что необходимо изменить профиль пакетов нисходящей линии связи, в то время когда MS 350 находится в дежурном режиме, т.е. в интервале дежурного режима, BS обновляет значение счетчика DCD N, которое управляется посредством BS 300, до 1 (N=1) на этапе 311 и передает измененное сообщение DCD на этапе 313. Хотя BS 300 передала измененное сообщение DCD, MS 250 в интервале дежурного режима не может обнаруживать изменение сообщения DCD. Следовательно, MS 350 сохраняет значение 0 (M=0) параметра, обозначающего значение счетчика DCD, которое управляется посредством MS 350, на этапе 315.
Когда интервал дежурного режима завершается, MS 350 принимает сообщение DL_MAP от BS 300 в интервале прослушивания на этапе 317. В сообщении DL_MAP значение счетчика DCD, более конкретно значение параметра N, представляющее значение счетчика DCD, которое управляется посредством BS 200, задается равным 1. Следовательно, MS 350 обнаруживает из значения счетчика DCD, что необходимо принять новое сообщение DCD от базовой станции BS 300.
После того, как интервал прослушивания завершается, MS 300 переходит в дежурный режим и ожидает сообщения DCD на этапе 319. Когда BS 300 обнаруживает данные, предназначенные для MS 350, в то время когда MS 350 находится в дежурном режиме, BS 300 передает в MS 350 сообщение TRF_IND, указывающее то, что имеются данные, которые должны быть переданы, предназначенные для MS 350, т.е. сообщение TRF_IND, в котором бит, представляющий MS 350 в битовой карте идентификатора дежурного режима, помечается посредством положительного значения, т.е. 1, на этапе 321.
После приема сообщения TRF_IND MS 350 уведомляет в BS 300 о том, что она обнаружила изменение сообщения DCD, т.е. изменение значения счетчика DCD, на этапе 323. На этом этапе MS 350 использует сообщение заголовка контроля доступа к среде (MAC) при уведомлении об изменении значения счетчика DCD в BS 300. Операция уведомления об изменении значения счетчика DCD посредством MS 350 подробнее описывается далее.
После приема уведомления об изменении значения счетчика DCD от MS 350 BS обнаруживает, что MS 350 по-прежнему применяет сообщение DCD до изменения, т.е. сообщение DCD, имеющее значение счетчика DCD равное 0, и затем BS выбирает одну из двух следующих схем для того, чтобы разрешить проблему, обусловленную различием между значениями счетчика DCD в BS 300 и MS 350. Т.е. для того, чтобы не допустить некорректной передачи и приема данных вследствие различия между значениями DIUC, в таком случае BS выбирает одну из двух следующих схем на этапе 325. После этого BS 300 передает данные в MS 350 посредством использования выбранной схемы на этапе 327.
В первой схеме BS 300 приостанавливает передачу данных в MS 350 до тех пор, пока MS 350 не примет новое сообщение DCD, т.е. до тех пор, пока BS 300 не передаст в широковещательном режиме новое сообщение DCD, после приема отчета об изменении значения счетчика DCD. Т.е. согласно первой схеме BS 300, принявшая новое сообщение DCD, выполняет передачу и прием данных после обновления DIUC MS 350, чтобы быть такими же, как передача и прием данных BS 300.
Согласно второй схеме BS 300 выполняет передачу и прием данных посредством применения значения счетчика DCD, в данный момент сохраненного в MS 350, т.е. посредством использования DIUC, соответствующего значению счетчика DCD, в данный момент сохраненному в MS 350. Фиг. 3 иллюстрирует случай, в котором BS 300 передает данные в MS 350 согласно второй схеме.
Второй случай, в котором MS и BS используют различные DIUC вследствие работы MS в дежурном режиме, соответствует тому, когда MS изменяет значение DIUC, чтобы быть надлежащим для нее при работе в дежурном режиме, т.е. в то время, когда MS находится в интервале дежурного режима.
Когда MS перемещается в то время, когда она находится в интервале дежурного режима или когда окружающие условия канала MS изменяются, чтобы значение CINR сигнала канала пилот-сигнала от обслуживающей BS стало отличным от этого значения до того, как MS перейдет в дежурный режим, MS изменяет значение DIUC, чтобы оно было надлежащим для самой MS. Например, когда значение CINR сигнала канала пилот-сигнала, измеренное в то время, когда MS находится в интервале дежурного режима, становится меньше значения CINR сигнала канала пилот-сигнала, измеренного до того, как MS переходит в интервал дежурного режима, если MS передает данные в BS с помощью имеющегося значения DIUC без обновления, существует большая вероятность того, что данные, передаваемые посредством MS, имеют ошибку. Следовательно, настоящее изобретение позволяет MS запрашивать обновление DIUC MS даже тогда, когда MS находится в дежурном режиме, чтобы установить соответствие DIUC для MS и BS, тем самым обеспечивая штатную передачу и прием данных.
Более конкретно, согласно настоящему изобретению сообщение MAC-заголовка, уведомляющее об изменении значения счетчика DCD, используется для того, чтобы запрашивать обновление DIUC MS. Сообщение MAC-заголовка для уведомления об изменении значения счетчика DCD и запроса на изменение значения DIUC MS подробнее описано в данном документе ниже.
Сначала сообщение MAC-заголовка, предлагаемое в настоящем изобретении для уведомления об изменении значения счетчика DCD и запроса на обновление DIUC MS, определяется как один из трех следующих типов.
Первый тип сообщения MAC-заголовка - это сообщение, генерируемое на основе сообщения MAC-заголовка, используемого в текущей системе связи IEEE 802.16e. Первый тип сообщения MAC-заголовка уведомляет об изменении значения счетчика DCD с помощью двух неиспользованных и зарезервированных битов в сообщении MAC-заголовка, т.е. заголовка сообщения физического (PHY) канала текущей системы связи IEEE 802.16e. Первый тип сообщения MAC-заголовка имеет формат, показанный в табл. 2 ниже.
Таблица 2
HT=1 (1)
EC=0 (1)
TYPE=010 (3)
PREFERENCE_DIUC (4)
UP_TX_POWER (7)
UL-HEADROOM (6)
DCD CHANGE COUNT LSB (2)
CID MSB (8)
CID LSB (8)
HCS (8)
Как видно из таблицы 2, все поля, за исключением поля DCD CHANGE COUNT LSB (самый младший бит) в первом типе сообщения MAC-заголовка, являются такими же, как поля сообщения заголовка уведомления PHY-канала текущей системы связи IEEE 802.16e. В таблице 2 HT - это поле, указывающее тип заголовка, EC - это поле, указывающее управление шифрованием, и оно всегда имеет значение 0 в сообщении заголовка уведомления PHY-канала, а TYPE - это поле, указывающее тип в данный момент переданного сообщения MAC-заголовка. Когда TYPE помечено как 010, это подразумевает, что сообщение MAC-заголовка - это сообщение заголовка уведомления PHY-канала.
В таблице 2 PREFERENCE_DIUC - это поле, указывающее значение DIUC, запрошенное посредством MS, UP_TX_POWER - это поле, указывающее дополнительную мощность передачи, доступную для MS, DCD CHANGE COUNT LSB - это поле, указывающее LSB значения числа измененного сообщения DCD, CID указывает базовый идентификатор соединения MS, а HCS - это поле, указывающее контрольную последовательность заголовков.
Первый тип сообщения MAC-заголовка - это сообщение MAC-заголовка, сгенерированное посредством изменения зарезервированных битов сообщения заголовка уведомления PHY-канала текущей системы связи IEEE 802.16e в поле DCD CHANGE LSB, которое уведомляет об изменении значения счетчика DCD. Два зарезервированных бита, в настоящее время не используемые в сообщении заголовка уведомления PHY-канала текущей системы связи IEEE 802.16e, используются в качестве двух LSB-битов счетчика DCD, задающих DIUC (PREFERENCE_DIUC), запрашиваемый посредством MS в сообщении MAC-заголовка первого типа. Сообщение MAC-заголовка первого типа включает в себя PREFERENCE_DIUC и DCD CHANGE COUNT LSB, посредством которых MS может уведомлять об изменении счетчика DCD и изменении DIUC в BS.
Сообщение MAC-заголовка второго типа - это сообщение заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот, которое является новым сформированным сообщением, чтобы уведомлять об изменении значения счетчика DCD и запрашивать изменение DIUC MS.
Второй тип сообщения MAC-заголовка имеет формат, показанный в таблице 3 ниже.
Таблица 3
HT=1 (1)
EC=0 (1)
TYPE=100 (3)
BR (11)
REQUESTED DOWNLINK BURST PROFILE (8)
CID MSB (8)
CID LSB (8)
HCS (8)
В таблице 3 поля HP, EC, HCS и CID сообщения MAC-заголовка второго типа являются такими же, как поля HT, EC, HCS и CID сообщения MAC-заголовка первого типа, показанного в таблице 2, поэтому повтор их описания опущен.
В таблице 3 TYPE - это поле, указывающее тип в данный момент переданного сообщения MAC-заголовка. Когда TYPE помечено как 100, это подразумевает, что сообщение MAC-заголовка - это сообщение заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот. Дополнительно поле BR указывает полосу частот, запрошенную посредством MS, которая имеет значение 0, когда отсутствуют данные, которые MS должна передавать посредством восходящей линии связи. Поле REQUESTED DOWNLINK BURST PROFILE имеет длину 8 битов, из которых четыре бита с нулевого бита по третий бит представляют значение DIUC, запрошенное посредством MS, а четыре бита с четвертого бита по седьмой бит представляют четыре LSB-бита задающего DIUC счетчика DCD, запрошенного посредством MS. REQUESTED DOWNLINK BURST PROFILE имеет формат, показанный в таблице 4 ниже.
Таблица 4
Название
Тип(1 байт)
Длина
Значение
REQUESTED DOWNLINK BURST PROFILE
1
1
Биты 0-3: DIUC профиля пакетов нисходящей линии связи, запрошенного посредством MS для трафика нисходящей линии связиБиты 4-7: LDB значения Configuration Change Count для DCD, задающего профиль пакетов, ассоциативно связанный с DIUC
Сообщение MAC-заголовка второго типа включает в себя поле REQUESTED DOWNLINK BURST PROFILE, посредством которого MS может уведомлять об изменении счетчика DCD и изменении DIUC в BS.
Сообщение MAC-заголовка третьего типа - это сообщение заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот, которое является новым сформированным сообщением, чтобы уведомлять об изменении значения счетчика DCD и запрашивать изменение DIUC MS.
Третий тип сообщения MAC-заголовка имеет формат, показанный в таблице 5 ниже.
Таблица 5
HT=1 (1)
EC=0 (1)
TYPE=100(3)
BR (11)
CINR (7)
DCD Change Indication (1)
CID MSB (8)
CID LSB (8)
HCS (8)
В таблице 5 поля HP, EC, HCS и CID сообщения MAC-заголовка третьего типа, показанного в таблице 5, являются такими же, как поля HT, EC, HCS и CID сообщения MAC-заголовка первого типа, показанного в табл. 2, поэтому повтор их описания опущен.
В таблице 5 TYPE - это поле, указывающее тип в данный момент переданного сообщения MAC-заголовка. Когда TYPE помечено как 100, это подразумевает, что сообщение MAC-заголовка - это сообщение заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот. Хотя типы сообщений MAC-заголовка второго типа и MAC-заголовка третьего типа могут отличаться друг от друга, они заданы как одинаковые в настоящем варианте осуществления для обеспечения понятности и удобства описания.
В таблице 5 поле BR указывает полосу частот, запрошенную посредством MS, которое имеет значение 0, когда отсутствуют данные, которые MS должна передавать посредством восходящей линии связи. Дополнительно поле CINR указывает CINR сигнала нисходящей линии связи, к примеру сигнала канала пилот-сигнала, принимаемого посредством MS, а поле DCD Change Indication указывает то, был ли изменен счетчик DCD.
Как показано в таблице 5, сообщение MAC-заголовка третьего типа имеет формат, аналогичный формату сообщения MAC-заголовка второго типа. Т.е. так же, как и сообщение MAC-заголовка второго типа, сообщение MAC-заголовка третьего типа - это сообщение, указывающее запрос на изменение профиля пакетов нисходящей линии связи и запрос полосы частот. Тем не менее, сообщение MAC-заголовка второго типа и сообщение MAC-заголовка третьего типа отличаются по процессу запроса об изменении профиля пакетов нисходящей линии связи.
Далее описываются способы, которыми сообщение MAC-заголовка второго типа и сообщение MAC-заголовка третьего типа запрашивают изменение профиля пакетов нисходящей линии связи.
Во-первых, сообщение MAC-заголовка второго типа используется посредством MS, которая непосредственно запрашивает назначение значения DIUC, которое является надлежащим для MS, от BS, чтобы изменить значение DIUC, когда перемещение MS в ходе интервала дежурного режима или изменения окружающих условий канала заставляет CINR сигнала канала пилот-сигнала от BS стать отличным от CINR до перехода MS в дежурный режим. Следовательно, в сообщении MAC-заголовка второго типа четыре бита с нулевого бита по третий бит из восьми битов поля REQUESTED DOWNLINK BURST PROFILE используются для того, чтобы выражать значение DIUC, запрошенное посредством MS.
В отличие от этого сообщение MAC-заголовка третьего типа используется станцией MS, чтобы запрашивать назначение значения DIUC, надлежащего для MS, посредством уведомления CINR принимаемого сигнала канала пилот-сигнала вместо использования посредством MS, которая непосредственно запрашивает назначение значения DIUC, которое является надлежащим для MS, от BS, чтобы изменить значение DIUC, когда перемещение MS в ходе интервала дежурного режима или изменения окружающих условий канала заставляет CINR сигнала канала пилот-сигнала от BS стать отличным от CINR до перехода MS в дежурный режим. Следовательно, сообщение MAC-заголовка третьего типа включает в себя поле CINR для уведомления CINR сигнала канала пилот-сигнала, принимаемого посредством MS. Чтобы уведомить о качестве канала MS, сообщение MAC-заголовка третьего типа может включать в себя CINR, а также другую информацию, допускающую выражение качества канала MS.
Дополнительно, чтобы уведомить об изменении значения счетчика DCD, сообщение MAC-заголовка второго типа непосредственно передает значение счетчика DCD, сохраненное в MS, в BS с помощью четырех битов от четвертого бита до седьмого бита из восьми битов поля REQUESTED DOWNLINK BURST PROFILE.
В отличие от этого сообщение MAC-заголовка третьего типа использует поле указания изменения DCD, чтобы выразить изменение значения счетчика DCD. Т.е. когда значение счетчика DCD, в данный момент сохраненное в MS, отличается от значения счетчика DCD, принятого посредством MS в интервале прослушивания, значение поля указания изменения DCD задается равным 1. Когда значение счетчика DCD, в данный момент сохраненное в MS, равно значению счетчика DCD, принятому посредством MS в интервале прослушивания, значение поля указания изменения DCD задается равным 0. Следовательно, BS может обнаруживать, изменилось ли значение счетчика DCD из значения поля указания изменения DCD сообщения MAC-заголовка третьего типа.
Временная точка, в которой передается сообщение MAC-заголовка третьего типа, должна быть такой же, как временная точка, в которой передается сообщение MAC-заголовка первого типа и сообщение MAC-заголовка второго типа. Т.е. когда значение счетчика DCD, в данный момент сохраненное в MS, отличается от значения счетчика DCD сообщения DCD, принятого посредством MS в интервале прослушивания, или когда необходимо изменить значение DIUC вследствие изменения CINR сигнала нисходящей линии связи, принятого посредством MS, MS передает сообщение MAC-заголовка третьего типа.
Дополнительно, даже когда значение счетчика DCD, в данный момент сохраненное в MS, равно значению счетчика DCD сообщения DCD, принятого посредством MS в интервале прослушивания, и необязательно изменять значение DIUC с учетом CINR сигнала нисходящей линии связи, принятого посредством MS, MS может использовать сообщение MAC-заголовка третьего типа для подтверждения сообщения TRF_IND.
Когда MS уведомляет о своем значении CINR посредством сообщения MAC-заголовка третьего типа в BS, BS определяет значение DIUC, надлежащее для MS, в соответствии со значением CINR MS. Процесс, в котором BS определяет значение DIUC, надлежащее для MS, в соответствии со значением CINR MS, не описывается в данном документе, поскольку он не имеет прямого отношения к настоящему изобретению.
Дополнительно, когда MS уведомляет об изменении значения счетчика DCD посредством сообщения MAC-заголовка третьего типа в BS, т.е. когда MS передает сообщение MAC-заголовка третьего типа, содержащее поле указания изменения DCD, имеющее значение, равное 1, BS приостанавливает передачу данных трафика, предназначенных для MS, до тех пор, пока MS не примет сообщение DCD, соответствующее измененному значению счетчика DCD, т.е. до тех пор, пока BS не выполнит повторную передачу сообщения DCD, соответствующего измененному значению счетчика DCD.
Кроме того, даже до того, как BS выполнит повторную передачу сообщения DCD, соответствующего измененному значению счетчика DCD, если BS непрерывно управляла и обнаруживает значение счетчика DCD сообщения DCD, сохраненного в MS, BS может передать данные трафика, предназначенные для MS, с помощью DIUC, заданного в сообщении DCD, соответствующем значению счетчика DCD, сохраненному в MS.
Следовательно, в отличие от сообщения MAC-заголовка первого типа и сообщения MAC-заголовка второго типа сообщение MAC-заголовка третьего типа позволяет MS непосредственно уведомлять о принимаемом CINR сигнала нисходящей линии связи в BS. Следовательно, BS может точно определять DIUC для MS, а также величину мощности, которая должна быть передана в MS, число повторов кодирования данных и т.д.
Далее новые сообщения MAC-заголовков, предлагаемые посредством настоящего изобретения, в том числе сообщение MAC-заголовка первого типа, показанное в таблице 2, т.е. сообщение, созданное посредством изменения сообщения заголовка уведомления PHY-канала, используемого в текущей системе связи IEEE 802.16e, сообщение MAC-заголовка второго типа и сообщение MAC-заголовка третьего типа сравниваются друг с другом.
Сообщение MAC-заголовка первого типа является преимущественным в том, что оно является повторно используемым сообщением, которое создано посредством внесения изменений в сообщение заголовка уведомления PHY-канала, используемое в текущей системе связи IEEE 802.16e. Тем не менее, в то время как сообщение MAC-заголовка первого типа позволяет передавать 2 LSB-бита счетчика DCD, сообщение MAC-заголовка второго типа позволяет передавать 4 LSB-бита счетчика DCD. Следовательно, сообщение MAC-заголовка второго типа является более подходящим, чем сообщение MAC-заголовка первого типа, когда MS остается в дежурном режиме в течение относительно долгого времени, и сообщение DCD изменяется относительно часто.
Дополнительно сообщение MAC-заголовка второго типа и сообщение MAC-заголовка третьего типа могут быть использованы для того, чтобы одновременно выполнять подтверждение изменения профиля пакетов нисходящей линии связи и запрос на выделение полосы частот. Т.е. даже когда MS находится в дежурном режиме, MS может запрашивать полосу частот посредством восходящей линии связи к BS, если появляются данные, которые должны быть переданы в BS. В таком случае MS может одновременно выполнять подтверждение изменения профиля пакетов нисходящей линии связи и запрос на выделение полосы частот с помощью сообщения MAC-заголовка второго типа и сообщения MAC-заголовка третьего типа. Посредством одновременного выполнения подтверждения изменения профиля пакетов нисходящей линии связи и запроса на выделение полосы частот можно минимизировать нагрузку по передаче сигналов в восходящей линии связи.
Фиг. 4 - это блок-схема последовательности операций способа работы MS в системе связи IEEE 802.16e согласно варианту осуществления настоящего изобретения.
Как описано выше, сообщение MAC-заголовка второго типа и сообщение MAC-заголовка третьего типа аналогичны по своим функциям, т.е. они оба являются сообщениями заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот. Поэтому следует отметить, что одно из сообщения MAC-заголовка второго типа и сообщения MAC-заголовка третьего типа может быть выборочно использовано в качестве сообщения заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот в последующем описании фиг. 4.
Ссылаясь на фиг. 4, в то время когда MS находится в дежурном режиме на этапе 411, MS проверяет, завершен ли интервал дежурного режима на этапе 413. Когда интервал дежурного режима еще не завершен, MS остается в интервале дежурного режима на этапе 411.
Когда интервал дежурного режима завершен, MS переходит в интервал прослушивания. На этапе 415 MS принимает сигнал канала пилот-сигнала от обслуживающей BS, измеряет CINR сигнала канала пилот-сигнала и определяет из измеренного CINR, необходимо ли изменять DIUC самой MS.
На этапе 417 MS сравнивает значение счетчика DCD сообщения DL_MAP от BS со значением счетчика DCD, сохраненным в MS, и определяет, изменилось ли значение счетчика DCD. На этапе 419 MS принимает сообщение TRF_IND от BS и проверяет, помечен ли бит для MS в битовой карте идентификатора дежурного режима принятого сообщения TRF_IND посредством значения, представляющего положительный идентификатор, т.е. 1. Когда бит не помечен посредством 1, MS возвращается к этапу 411.
В результате проверки на этапе 419, когда бит помечен посредством 1, MS проверяет, выделена ли для MS полоса частот восходящей линии связи, на этапе 421. MS переходит к этапу 423, когда MS выделена полоса частот восходящей линии связи, и переходит к этапу 429, когда MS не выделена полоса частот восходящей линии связи.
На этапе 423 MS проверяет, необходимо ли уведомлять об изменении значения счетчика DCD или запрашивать изменение DIUC. Когда необходимо уведомить об изменении значения счетчика DCD или запрашивать изменение DIUC, MS выбирает одно сообщение MAC-заголовка из сообщения MAC-заголовка первого типа, т.е. сообщения заголовка уведомления PHY-канала, и сообщений MAC-заголовка второго и третьего типа, т.е. сообщений заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот, уведомляет об изменении значения счетчика DCD или запрашивает изменение DIUC посредством использования выбранного сообщения на этапе 425. На этапе 425 MS подчиняется определению системы связи IEEE 802.16e в выборе одного сообщения MAC-заголовка из сообщений MAC-заголовка первого, второго и третьего типов.
Когда необязательно уведомлять об изменении значения счетчика DCD и запрашивать изменение DIUC, MS может передавать сообщение заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот вместо сообщения заголовка запроса полосы частот после присваивания полю BR сообщения заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот значения 0 на этапе 427.
На этапе 429 MS переходит из дежурного режима в режим "пробуждения" и затем осуществляет обычный режим работы.
Как описано выше, сообщение MAC-заголовка второго типа и сообщение MAC-заголовка третьего типа аналогичны по своим функциям, т.е. являются сообщениями заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот. Поэтому следует отметить, что одно из сообщения MAC-заголовка второго типа и сообщения MAC-заголовка третьего типа может быть выборочно использовано в качестве сообщения заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот в последующем описании фиг. 5.
Фиг.5 - это блок-схема последовательности операций способа работы BS в системе связи IEEE 802.16e согласно варианту осуществления настоящего изобретения. Ссылаясь на фиг. 5, в то время когда соответствующая MS, управляемая посредством BS, находится в дежурном режиме на этапе 511, BS проверяет, завершен ли интервал дежурного режима соответствующей MS на этапе 513. Когда интервал дежурного режима еще не завершен, BS возвращается к этапу 511.
Когда интервал дежурного режима MS завершен, BS переходит в интервал прослушивания. На этапе 515 BS проверяет, сохранены ли в буфере данные, предназначенные для соответствующей MS, т.е. данные, которые должны быть переданы в MS. Когда нет данных, которые должны быть переданы в MS, BS переходит к этапу 517.
На этапе 517 BS передает сообщение TRF_IND после пометки бита для соответствующей MS в битовой карте идентификатора дежурного режима сообщения TRF_IND посредством значения, представляющего отрицательную индикацию, т.е. 0, и затем переходит к этапу 519. На этапе 519 BS обновляет интервал дежурного режима соответствующей MS, а на этапе 521 BS управляет MS в дежурном режиме на основе обновленного интервала дежурного режима.
Как результат проверки на этапе 515, когда нет данных, которые должны быть переданы в MS, BS передает сообщение TRF_IND после пометки бита для соответствующей MS в битовой карте идентификатора дежурного режима сообщения TRF_IND посредством значения, представляющего положительную индикацию, т.е. 1, на этапе 523.
На этапе 525 BS выделяет полосу частот восходящей линии связи соответствующей MS и принимает посредством выделенной полосы частот восходящей линии связи одно сообщение MAC-заголовка из сообщения MAC-заголовка первого типа, т.е. сообщения заголовка уведомления PHY-канала, и сообщений MAC-заголовка второго и третьего типа, т.е. сообщений заголовка запроса на изменение профиля пакетов нисходящей линии связи и запроса полосы частот. На этапе 525 BS подчиняется определению системы связи IEEE 802.16e в приеме сообщений MAC-заголовка первого, второго и третьего типа.
На этапе 527 BS определяет на основе анализа сообщения MAC-заголовка первого, второго или третьего типа, принятого от MS, есть ли уведомление об изменении значения счетчика DCD или запрос на изменение DIUC. Когда есть запрос на изменение DIUC, BS изменяет DIUC согласно запросу MS на этапе 529.
Как результат определения на этапе 527, когда есть уведомление об изменении значения счетчика DCD, BS передает данные в MS на основе DIUC профиля пакетов нисходящей линии связи сообщения DCD, соответствующего значению счетчика DCD, сохраненному в MS, или приостанавливает передачу данных до тех пор, пока BS не передаст сообщение DCD в MS, на этапе 531.
Когда нет ни уведомления об изменении значения счетчика DCD, ни запроса на изменение DIUC в результате определения на этапе 527, BS переходит непосредственно к этапу 533.
На этапе 533 BS управляет MS, чтобы перейти в режим "пробуждения", и затем завершает процесс.
Согласно настоящему изобретению, когда сообщение DCD изменяется, т.е. когда изменяется профиль пакетов нисходящей линии связи, в дежурном режиме системы связи с широкополосным беспроводным доступом, использующей схему OFDM/OFDMA, к примеру, системы связи IEEE 802.16e, или когда необходимо изменить DIUC MS вследствие изменения CINR MS, MS уведомляет об изменении сообщения DCD и запрашивает изменение DIUC от BS, чтобы BS и MS передавали и принимали данные с одинаковым DIUC, тем самым максимизируя эффективность передачи.
Несмотря на то, что настоящее изобретение показано и описано со ссылкой на его конкретные варианты осуществления, специалистам в данной области техники следует понимать, что различные изменения по форме и содержанию могут быть сделаны без отступления от сущности и объема изобретения, определенных прилагаемой формулой изобретения.