Устройство и способ передачи и приема сигналов с помощью информации канала нисходящей линии связи в дежурном режиме в системе bwa-связи

Иллюстрации

Показать все

Изобретение относится к технике связи. Технический результат состоит в представлении пользователям услуг, имеющих различное качество обслуживания на высокой скорости передачи. Для этого способ включает в себя этапы, на которых обнаруживают изменение информации канала нисходящей линии связи, принимают уведомление от базовой станции о том, что имеются данные для мобильной станции, и уведомляют базовую станцию об изменении информации канала нисходящей линии связи с тем, чтобы базовая станция и мобильная станция имели одинаковую информацию канала нисходящей линии связи. 3 н. и 9 з.п. ф-лы, 5 ил., 5 табл.

Реферат

Область техники, к которой относится изобретение

Настоящее изобретение, в общем, относится к системе связи с широкополосным беспроводным доступом (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 в ходе интервала дежурного режима или изменения окружающих