ПЕРЕКОНФИГУРИРОВАНИЕ РАДИОИНТЕРФЕЙСА Российский патент 2014 года по МПК H04W36/18 

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

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

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

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

Передача информации и данных базовой станцией на пользовательское устройство осуществляется по радиочастотным несущим, известным как несущие нисходящей линии связи. Передача информации и данных пользовательским устройством на базовую станцию осуществляется по радиочастотным несущим, известным как несущие восходящей линии связи. Следовательно, в дополнение к HS-DPA на нисходящей линии связи, доступ на основе высокоскоростной пакетной связи по восходящей линии связи (HS-UPA) также предусмотрен в восходящей линии связи. HS-UPA также известен как Улучшенная восходящая линия связи (Enhanced Uplink).

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

Было предложено разрешить каждому из базовых станций и пользовательских устройств передавать одновременно на более чем одной несущей. Кроме того, было предложено разрешить каждому из базовых станций и пользовательских устройств принимать одновременно на более чем одной несущей. В отношении каждой несущей, как восходящей, так и нисходящей линии связи, в типичном случае осуществляется независимое управление мощностью со стороны базовой станции. Обеспечение более чем одной несущей нисходящей линии связи, например, при четырех частотных несущих, дает увеличение в пропускной способности в направлении на пользовательское устройство. Сети, в которых имеется более двух несущих, могут упоминаться как сети доступа на основе высокоскоростной пакетной связи по нисходящей линии связи в множестве сот (MC-HSDPA). Используемый здесь термин ”сеть с множеством несущих” подразумевается охватывающим случай, где в сети предусмотрены две (например, HSDPA в двух сотах и HSUPA в двух сотах), три, четыре или более несущих нисходящей (или восходящей) линии связи.

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

Раскрытие изобретения

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

Согласно первому аспекту осознается, что проблема, характерная для существующей организации обмена сообщениями, заключается в том, что нет гибкого механизма, который обеспечивает пользовательскому устройству возможность инициировать переконфигурацию радиоинтерфейса. Хотя и имеются одиночные сообщения действия, которыми предоставляется лишь одиночное указание, они не могут обеспечить какую-либо дополнительную информацию, кроме той, которая просто указывает, что требуется изменение. Также, в типичном случае, эти одиночные сообщения действия будут декодироваться только обслуживающей сотой, а другие базовые станции, которые могут быть затронуты переконфигурацией, проигнорируют сообщение. Соответственно, переконфигурация или изменение, требующиеся для радиоинтерфейса, определяется пользовательским устройством. Эта переконфигурация кодируется в упомянутое сообщение, используя подходящую методику. Кроме того, в это сообщение также кодируется индикатор. Данный индикатор указывает принимающим базовым станциям, следует ли им реагировать на принятое сообщение. Таким образом, предоставляется гибкий механизм, которым обеспечивается возможность предоставления дополнительной информации касаемо требуемой переконфигурации. Данное сообщение может декодироваться всеми базовыми станциями в пределах дальности связи пользовательского устройства, но упомянутый индикатор указывает, какие базовые станции должны реагировать на это сообщение.

В одном варианте осуществления системой беспроводной связи является система беспроводной связи с множеством несущих.

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

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

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

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

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

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

В одном варианте осуществления восходящий канал управления содержит усовершенствованный выделенный физический канал управления (E-DPCCH) и восходящий канал данных содержит усовершенствованный выделенный физический канал данных (E-DPDCH).

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

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

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

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

Согласно одному варианту осуществления, указание переконфигурации кодируется с использованием по меньшей мере 6 битов.

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

В одном варианте осуществления системой беспроводной связи является система беспроводной связи с множеством несущих.

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

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

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

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

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

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

В одном варианте осуществления восходящий канал управления содержит усовершенствованный выделенный физический канал управления (E-DPCCH) и восходящий канал данных содержит усовершенствованный выделенный физический канал данных (E-DPDCH).

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

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

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

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

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

В одном варианте осуществления системой беспроводной связи является система беспроводной связи с множеством несущих.

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

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

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

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

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

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

В одном варианте осуществления восходящий канал управления содержит усовершенствованный выделенный физический канал управления (E-DPCCH) и восходящий канал данных содержит усовершенствованный выделенный физический канал данных (E-DPDCH).

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

В одном варианте осуществления этап приема содержит этап, на котором принимают сообщение запроса переконфигурации в сообщении уровня два, в котором сообщение запроса переконфигурации закодировано.

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

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

В одном варианте осуществления системой беспроводной связи является система беспроводной связи с множеством несущих.

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

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

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

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

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

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

В одном варианте осуществления восходящий канал управления содержит усовершенствованный выделенный физический канал управления (E-DPCCH) и восходящий канал данных содержит усовершенствованный выделенный физический канал данных (E-DPDCH).

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

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

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

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

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

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

Перечень фигур чертежей

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

Фиг. 1 - иллюстрация системы беспроводной связи согласно одному варианту осуществления;

Фиг. 2 - иллюстрация коммуникационных уровней между сетью и пользовательским устройством;

Фиг. 3 - иллюстрация примерного командного сообщения восходящей линии связи согласно одному варианту осуществления;

Фиг. 4 - иллюстрация структуры усовершенствованного выделенного канала;

Фиг. 5 - иллюстрация примерного командного сообщения восходящей линии связи согласно одному варианту осуществления;

Фиг. 6 - иллюстрация примерного командного сообщения восходящей линии связи согласно одному варианту осуществления;

Фиг. 7 - иллюстрация примерного командного сообщения восходящей линии связи согласно одному варианту осуществления;

Фиг. 8 - иллюстрация примерного командного сообщения восходящей линии связи согласно одному варианту осуществления;

Фиг. 9 и 10 - иллюстрация примерной работы сети при использовании команд восходящей линии связи; и

Фиг. 11 и 12 - иллюстрация примерной работы сети при использовании команд восходящей линии связи.

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

Фиг. 1 иллюстрирует систему 10 беспроводной связи согласно одному варианту осуществления. Пользовательское устройство 50 перемещается по системе беспроводной связи. Предусмотрены базовые станции 20, которые поддерживают области радиопокрытия 30. Предусмотрено некоторое количество таких базовых станций 20, которые географически распределены для обеспечения пользовательскому устройству 50 широкой области покрытия. Когда пользовательское устройство находится в пределах области, обслуживаемой базовой станцией 30, связь может устанавливаться между пользовательским устройством и базовой станцией по ассоциированным линиям радиосвязи. Каждая базовая станция в типичном случае поддерживает ряд секторов в пределах географической области обслуживания 30.

В типичном случае, отдельная антенна в базовой станции поддерживает каждый ассоциированный сектор. Соответственно, каждая базовая станция 20 имеет множество антенн, и сигналам, посылаемым через эти различные антенны, электронным образом назначаются веса для обеспечения секторизованного подхода. Естественно, следует понимать, что Фиг. 1 иллюстрирует небольшое подмножество общего количества пользовательских устройств и базовых станций, которые могут быть в наличии в типичной системе связи.

Сеть радиодоступа системы беспроводной связи управляется контроллером радиосети (RNC) 40. Контроллер радиосети 40 управляет работой системы беспроводной связи посредством осуществления связи с множеством базовых станций по магистральной линии 60 связи. Контроллер сети также осуществляет связь с пользовательским устройством 50 через каждую базовую станцию.

Контроллер 40 радиосети поддерживает список соседей, который включает в себя информацию о географических взаимосвязях между секторами, поддерживаемыми базовыми станциями 20. Кроме того, контроллер 40 радиосети поддерживает информацию местоположения, которая обеспечивает информацию о местоположении пользовательских устройств 50 в пределах системы 10 беспроводной связи. Контроллер радиосети выполнен с возможностью маршрутизировать трафик через сети с коммутацией каналов и сети с коммутацией пакетов. Следовательно, предусмотрен центр коммутации мобильной связи, с которым контроллер радиосети может осуществлять связь. Центр коммутации мобильной связи может осуществлять связь с сетью с коммутацией каналов, такой как коммутируемая телефонная сеть общего пользования (PSTN) 70. Аналогично, контроллер радиосети может осуществлять связь с обслуживающими узлами поддержки общей службы пакетной радиопередачи (SGSN) и шлюзовым узлом поддержки общей службы пакетной радиопередачи (GGSN). GGSN может осуществлять связь с базовой сетью с коммутацией пакетов, такой как, например, Интернет.

Пользовательское устройство 50 в типичном случае передает информацию и данные на базовую станцию 20, с тем чтобы они могли быть перенаправлены в сети беспроводной связи. Пользовательскому устройству может, например, потребоваться передать данные на базовую станцию для того, чтобы ретранслировать текстовые сообщения, голосовую информацию, когда пользователь использует данное устройство для выполнения телефонного вызова, или другие данные. Базовая станция 20, в сочетании с параметрами, установленными контроллером 40 радиосети, выделяет ресурсы пользовательскому устройству таким путем, который нацелен на оптимизацию работы сети 10 беспроводной связи.

В Универсальной системе мобильной связи (UMTS) предусмотрена организация доступа на основе высокоскоростной пакетной связи по нисходящей линии связи в множестве сот (MC-HSDPA). В случае MC-HSDPA, сектор определяется как географическая область радиопокрытия базовой станции или Узла В (Node B). Сектор может состоять из нескольких сот, при этом задачей каждой соты является покрытие той же самой области радиопокрытия, что и сектор, и ей используется отдельная частотная несущая для своей передачи. Частотная несущая может лежать в пределах одной полосы частот или может быть распределена по двум полосам частот. MC-HSDPA представляет собой расширение в отношении доступа на основе высокоскоростной пакетной связи по нисходящей линии связи в двух сотах (DC-HSDPA). В случае MC-HSDPA, пользовательское устройство может принимать вплоть до четырех одновременных передач нисходящей линии связи из четырех разных сот. Следовательно, MC-HSDPA потенциально может удваивать и учетверять пропускную способность нисходящей линии связи DC-HSDPA и HSDPA (в одной соте), соответственно. MC-HSDPA также иногда упоминается как 4C-HSDPA (HSDPA в четырех сотах) или 3C-HSDPA, когда пользовательское устройство принимает одновременные передачи из четырех или трех сот, соответственно.

В системе с множеством несущих каждая несущая имеет независимые нисходящие линии радиосвязи от базовой станции на пользовательское устройство. Управление этими нисходящими линиями радиосвязи осуществляется независимо, поскольку каждой несущей, по всей вероятности, будут соответствовать разные пути распространения радиосигнала к пользовательскому устройству. Для систем HSDPA, выполненных с возможностью работы в режиме с множеством несущих, может быть предусмотрено более двух несущих нисходящей линии связи. Следует понимать, что в сети с множеством несущих количество несущих нисходящей линии связи может не совпадать с количество несущих восходящей линии связи. Более того, количество обеспечиваемых несущих нисходящей линии связи может не быть в точности равно удвоенному количеству несущих обеспечиваемых восходящей линии связи. В HSDPA режима с множеством несущих, с каждым сектором, обслуживаемым базовой станцией, может быть ассоциировано несколько несущих частот или "несущих". Несущая или сота, поддерживаемая несущей, охватывает ту же самую географическую зону, что и сектор. Каждая сота обслуживается посредством отличной от других несущей частоты. Следовательно, должно быть понятно, что в системе с одной несущей сота эквивалентна сектору, поскольку в секторе имеется только одна сота или несущая частота. Тем не менее, в сети с множеством несущих каждый сектор может содержать несколько сот, причем каждая сота обслуживается одновременно посредством отличной от других несущей частоты.

В MC-HSDPA, основная несущая соответствует соте, в которой переносятся важнейшие каналы управления, и она не может быть деактивирована. Есть только одна основная несущая, и другие несущие называются неосновными несущими (Неосновная Несущая 1, Неосновная Несущая 2 и Неосновная Несущая 3).

Управление несущими может быть реализовано с использованием команд высокоскоростного совместно используемого канала управления (HS-SCCH). Команды HS-SCCH соответствуют сигнализации уровня 1 от поддерживающей базовой станции на пользовательское устройство, которыми обеспечивается возможность осуществления быстрых команд/инструкций. Помимо активации/деактивации неосновных несущих, команды HS-SCCH могут также использоваться для включения прерывистой передачи или приема.

В общем, связь между узлами осуществляется по нескольким уровням. В сети радиодоступа (RAN) HSPA имеется три уровня связи между сетью и пользовательским устройством, как показано на Фиг. 2. Уровень 3 соответствует уровню управления радиоресурсами (RRC), Уровень 2 состоит из подуровня управления линией радиосвязи и подуровня управления доступом к среде передачи, а Уровень 1 соответствует физическому уровню. Каждый уровень в сети или в пользовательском устройстве будет посылать сообщения, предназначенные только для того же уровня в пользовательском устройстве или в сети. Например, сообщение RRC (сообщение Уровня 3) из сети предназначено только для RRC в пользовательском устройстве. За исключением физического уровня (Уровня 1), сообщения всех остальных уровней не могут быть посланы непосредственно на соответствующий уровень на другом узле. Например, сообщение Уровня 3 из сети должно пройти через Уровень 2 и Уровень 1 перед тем, как оно может быть послано на пользовательское устройство. На пользовательском устройстве данное сообщение принимается на Уровне 1 и проходит через Уровень 2 до того, как оно достигнет своего пункта назначения на Уровне 3. Путь, который проходит это сообщение Уровня 3 в данном примере, показан стрелкой 100 на Фиг. 2.

Обычно уровень RRC в сети посылает конфигурационные сообщения для предписания пользовательскому устройству выполнить некоторую задачу (например, эстафетную передачу обслуживания в другую соту). Управление уровнем RRC осуществляется контроллером 40 радиосети, который физически отделен от Узла В (NB). Вследствие этого сообщения RRC обычно медленные. Команды могут быть ускорены посредством отправки этих команд из базовой станции по физическому уровню (т.е. Уровню 1), поскольку базовая станция может непосредственно осуществлять связь с пользовательским устройством на физическом уровне. В HSPA, высокоскоростной совместно используемый канал управления (HS-SCCH), сообщение Уровня 1, используется для переноса команд на пользовательское устройство. Команда HS-SCCH обеспечивает то, что решения, принятые на базовой станции и в сети, достигают пользовательского устройства быстро. Наличие команд HS-SCCH выгодно для таких функций, как Быстрая смена обслуживающей соты, позволяющей быстро осуществлять эстафетную передачу обслуживания пользовательского устройства в соту. Команда HS-SCCH также используется для включения/выключения функции прерывистой передачи (DTX) и прерывистого приема (DRX) в пользовательском устройстве. В HSDPA с четырьмя несущими (4C-HSDPA), команда HS-SCCH используется для активации или деактивации неосновных несущих в пользовательском устройстве.

Команда HS-SCCH посылается из базовой станции в пользовательское устройство. Для пользовательского устройства является выгодным, если оно также может послать сообщение Уровня 1 для переноса команды или запроса на базовую станцию. Например, пользовательское устройство 4C-HSDPA может пожелать запросить, чтобы базовая станция деактивировала неосновную несущую для сбережения ресурса аккумуляторной батареи. На текущий момент, сообщения Уровня 1 восходящей линии связи предназначены лишь для функциональных возможностей Уровня 1 (например, команды Управления мощностью передачи), но не для команды, которая может затрагивать конфигурацию на других уровнях.

В отличие от команд HS-SCCH, для любой команды восходящей линии связи, в дополнение к ее приему обслуживающей сотой, также требуется, чтобы она принималась необслуживающими сотами (т.е. сотами, участвующими в мягкой эстафетной передаче обслуживания, которые не являются основной обслуживающей сотой). Недостатком команд HS-SCCH является то, что базовая станция должна информировать необслуживающие соты через RNC 40 о любых изменениях в отношении пользовательского устройства, что вызывает задержку. Примером этого является активация/деактивация неосновной несущей восходящей линии связи при доступе на основе высокоскоростной пакетной связи по восходящей линии связи в двух сотах (DC-HSUPA), где базовая станция должна информировать RNC 40 об активации/деактивации, с тем чтобы RNC 40 мог распространить данную информацию на все необслуживающие соты, относящиеся к пользовательскому устройству. Следовательно, для команд/запросов, которые воздействуют на необслуживающую соту, важно, чтобы команда восходящей линии связи также достигала все необслуживающие соты.

Следовательно, предлагаемой методикой обеспечивается механизм, который обеспечивает пользовательскому устройству возможность посылать команду или запрос Уровня 1 или Уровня 2 в сеть. Это может быть достигнуто разнообразием различных способов, что будет подробно разъяснено ниже.

Для каждой команды восходящей линии связи требуется одно или более из следующих полей/информации:

• Идентификатор для идентификации пользовательского устройства, которое послало команду восходящей линии связи;

• Тип Команды: Тип Команды указывает, требуется ли квитанция со стороны обслуживающей и/или необслуживающей соты и требуется ли действие со стороны обслуживающей и/или необслуживающей соты;

• Представление команды: Битовые комбинации для представления конкретных команд;

• Контрольная сумма: путь для базовой станции удостовериться в том, что она корректно приняла команду.

Важно, что некоторые команды восходящей линии связи квитируются сетью. Существующий канал индикатора гибридного ARQ E-DCH (E-HICH) может быть использован для квитирования команды восходящей линии связи. Аналогично командам HS-SCCH, команды восходящей линии связи не следует посылать вместе с E-DCH, переносящим пользовательскую информацию, поскольку это вызовет путаницу в квитанциях из сети. Существующий E-HICH также посылается необслуживающей сотой, который может использоваться для квитирования команды восходящей линии связи. Для команд или запросов, которые не воздействуют на необслуживающие соты (например, запрос деактивации неосновной несущей в 4C-HSDPA), пользовательское устройство может игнорировать квитанции из необслуживающих сот (или от необслуживающих сот не требуется посылать квитанции для этих типов команд/запросов). Для команд или запросов, которые воздействуют на необслуживающие соты, от пользовательского устройства потребуется ожидать квитанций от всех из обслуживающей и необслуживающих сот до того, как оно сможет перейти к командам/запросам.

Команда восходящей линии связи может также включать в себя указание того, требуются ли какие-либо действия со стороны обслуживающей или необслуживающей соты. Никаких действий может не потребоваться со стороны либо обслуживающей, либо необслуживающей соты, если команда восходящей линии связи используется для передачи информации в группу необслуживающих сот. Также, она может указывать, требуется ли квитанция от обслуживающей или необслуживающей соты. Этим может быть снижен объем ненужных квитанций в сетях.

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

Реализация 1 - Новый физический канал

В этой реализации предусмотрен новый физический канал для переноса команд и/или запросов восходящей линии связи. Канал команд восходящей линии связи использует по-новому определенный формат или может повторно использовать существующий формат физического канала. Повторное использование существующего формата имеет преимущество, заключающееся в том, что в отношении рабочих характеристик его линии связи не требуется выполнять тест на согласованность, поскольку у него будут те же самые рабочие характеристики линии связи существующего формата, которые протестированы. Однако, в таком случае команда восходящей линии связи будет ограничена количеством информационных битов существующего физического канала. Текущая команда HS-SCCH имеет лишь 6 битов для представления команды, что дает максимум 64 различные команды. Эти разные команды быстро израсходуются, особенно при вводе в действие 4C-HSDPA + 4C-HSUPA, где 27 команд требуются для активации/деактивации 4 несущих нисходящей и восходящей линии связи. Следовательно, по-новому определяемый физический канал для команд восходящей линии связи должен содержать, по меньшей мере, 6 битов для представления команд/запросов. Новый код разнесения будет предусмотрен для кодирования сообщения. Могут использоваться существующие или новые схемы кодирования/декодирования. Аналогично команде HS-SCCH, команда восходящей линии связи должна содержать CRC (поле проверки циклическим избыточным кодом) для обнаружения ошибок, чтобы избежать некорректной интерпретации команды. Квитанция может также потребоваться от базовой станции, когда команда принимается.

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

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

Иллюстративный формат показан на Фиг. 3, где:

• ACK_REQ состоит из 2 битов и используется для указания того, требуется ли квитанция от обслуживающей или необслуживающей соты. Это описывается более подробно ниже.

• ACT_REQ состоит из 2 битов и используется для указания того, требуется ли действие со стороны обслуживающей или необслуживающей соты. Это описывается более подробно ниже.

• Дополнительные заголовки команды.

• Представление команды. Каждая уникальная битовая комбинация задает ассоциированную команду.

• Контрольная сумма CRC. Контрольная сумма CRC может составлять 16 или существующие 24 бита, используемые в E-DPDCH.

Поскольку это сообщение уровня 1, UE идентифицируется посредством используемого кода скремблирования.

Реализация 2 - Использование E-DPCCH и E-DPDCH с модификацией

E-DCH (усовершенствованный выделенный канал) - это транспортный канал, который переносит пользовательские данные для HS-UPA. Он состоит из E-DPCCH (выделенного физического канала управления E-DCH) и одного или более E-DPDCH (выделенных физических каналов данных E-DCH), как показано на Фиг. 4. Оба физических канала в E-DCH спроектированы для функционирования при мягкой эстафетной передаче обслуживания, и таким образом необслуживающие соты уже обладают функциональной возможностью декодировать их. E-DPDCH переносит пользовательскую информацию, тогда как E-DPCCH переносит управляющую информацию, включающую в себя инструкцию декодирования для вложенного E-DPDCH. Чтобы избежать необходимости в дополнительных тестах на согласованность, для команды восходящей линии связи можно повторно использовать существующий формат E-DPCCH. E-DPCCH состоит из 10 информационных битов, которые могут использоваться для представления команд/запросов восходящей линии связи. Однако E-DPCCH не содержит проверок на ошибки, поскольку он является частью E-DCH, который содержит 24-битовый CRC как часть своего кодирования. Этот CRC переносится посредством E-DPDCH. Для обеспечения обнаружения ошибок, команда восходящей линии связи с использованием E-DPCCH может быть послана совместно с необязательным E-DPDCH, который переносит CRC. E-DPDCH может быть необязательным, поскольку для некоторых команд или запросов восходящей линии связи CRC может не потребоваться (например, для запроса деактивации неосновной несущей в 4C-HSPA). Сокращенный набор E-TFCI может быть использован для E-DPDCH, и он может переносить дополнительную информацию для команды восходящей линии связи. В отношении E-DPCCH, переносящего команду восходящей линии связи, выполняется разнесение с помощью кода разнесения, отдельного от того, что используется существующим E-DPCCH, с тем чтобы базовая станция могла провести различие между ими двумя.

Следовательно, в данной реализации осуществляется повторное использование существующей пары E-DPCCH и E-DPDCH с модификацией. Для E-DPCCH будет использоваться другой код разнесения, чтобы можно было его отличить от существующего E-DPCCH. Соответствующий E-DPDCH может быть необязательным (указывается в E-DPCCH), и, если он посылается, в E-DPDCH могут использоваться несколько различных форматов.

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

Иллюстративный формат показан на Фиг. 5. Здесь:

○ по E-DPCCH: ACK_REQ, состоящие из 2 битов, используются для указания того, требуется ли квитанция со стороны обслуживающей или необслуживающей соты, что будет описано более подробно ниже.

○ по E-DPCCH: ACT_REQ, состоящие из 2 битов, используются для указания того, требуется ли действие со стороны обслуживающей или необслуживающей соты, что будет описано более подробно ниже.

○ по E-DPCCH: вложение E-DPDCH. 1 бит используется для указания того, есть ли E-DPDCH, вложенный в эту команду.

○ по E-DPCCH: команда или E-TFCI. 5 битов используются для представления того, отсутствует ли вложение E-DPDCH. В противном случае, это будет E-TFCI, используемый во вложенном E-DPDCH.

○ по E-DPDCH: заголовок команды.

○ по E-DPDCH: представление команды.

○ по E-DPDCH: 24-битный CRC.

ACK_REQ и ACT_REQ посылаются по E-DPCCH, поскольку базовая станция будет декодировать E-DPCCH первым. Это позволит обслуживающей и необслуживающей сотам принимать решение в отношении того, нужно ли им декодировать вложенный E-DPDCH (если он вообще есть). Например, если ACT_REQ указывает, что от необслуживающей соты не требуется никакого действия, необслуживающая сота не будет дополнительно декодировать E-DPDCH.

Поскольку это есть сообщение Уровня 1, пользовательское устройство идентифицируется посредством используемого кода скремблирования.

Реализация 3 - Использование обособленного E-DPDCH

Использование E-DPCCH с вложенным E-DPDCH, как упомянуто выше, приводит к тому, что базовая станция должна декодировать два физических канала (хотя базовая станция может уже делать это в текущий момент). Также дополнительная мощность требуется для переноса двух физических каналов для команды восходящей линии связи. Чтобы избежать этого, команда восходящей линии может использовать обособленный E-DPDCH. Здесь, для E-DPDCH используются фиксированные E-TFCI, коэффициент разнесения (SF) и код разнесения, с тем чтобы он мог быть декодирован без каких-либо инструкций из E-DPCCH. Для команды восходящей линии может использоваться наименьший размер транспортного блока для E-DPDCH, составляющий 18 битов (E-TFCI=0), что больше, чем для существующей команды HS-SCCH. Однако можно использовать другие заранее определенные E-TFCI. Существующий CRC (24 бита) в E-DPDCH может неоднократно использоваться для обнаружения ошибок. E-TFCI=0 изначально предусмотрен для переноса информации планирования MAC, что является надежным и, следовательно, подходящим для переноса команды восходящей линии.

Существующим тестом на согласованность в 3GPP тестируются только рабочие характеристики канала E-DCH (усовершенствованного выделенного канала), но не его компонентов, E-DPDCH или E-DPCCH. Дополнительное тестирование не требуется для обособленного E-DPDCH, поскольку ожидается, что он будет функционировать лучше, чем E-DCH (т.е. комбинированные E-DPDCH и E-DPCCH). Это обусловлено тем, что сбой в E-DPCCH приведет к сбою в E-DPDCH, поскольку базовой станцией теряется инструкция декодирования. Для команды восходящей линии связи, использующей обособленный E-DPDCH, будет иметься известная инструкция декодирования на базовой станции, что эквивалентно исправному E-DPCCH.

Для E-DPDCH будет использоваться другой код разнесения и фиксированный формат с тем, чтобы базовая станция знала, как его искать и декодировать его. Примерным форматом является формат, используемый в E-TFCI=0, в котором имеется 18 битов.

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

Иллюстративный формат показан на Фиг. 6. Здесь:

○ ACK_REQ, состоящие из 2 битов, используются для указания того, требуется ли квитанция со стороны обслуживающей или необслуживающей соты, что будет описано более подробно ниже.

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

○ представление команды. Каждая битовая комбинация задает команду (по меньшей мере, 6 битов).

○ 24-битная контрольная сумма CRC.

Заголовок команды и представление команды совместно состоят из 14 битов. Поскольку это является сообщением Уровня 1, UE идентифицируется по используемому коду скремблирования.

Реализация 4 - Использование E-DPDCH и DPDCH без модификации

Как упомянуто выше, для E-DPCCH или обособленного E-DPDCH с другим кодом разнесения будет требоваться дополнительное средство обнаружения/поиска на базовой станции для обнаружения этого канала. Чтобы избежать этого, можно повторно использовать существующий E-DCH. Здесь неиспользуемые биты E-TFCI в E-DPCCH используются для указания того, что соответствующий E-DPDCH является командой восходящей линии связи. Аналогично обособленному E-DPDCH, для E-DPDCH здесь будет использоваться фиксированный коэффициент разнесения и фиксированный размер транспортного блока. Хотя в разных таблицах есть разные неиспользуемые E-TFCI, базовая станция может быть запрограммирована распознавать конкретные (т.е. неиспользуемые) E-TFCI в каждой таблице в качестве указания на то, что соответствующий E-DPDCH является командой восходящей линии связи. В то же время данный способ в общем случае будет лишь применим в HSUPA с TTI 2 мс, поскольку на текущий момент неиспользуемые E-TFCI имеются только в HSUPA с TTI 2 мс.

Следовательно, данная реализация аналогична реализации 2, где повторно используется существующая пара E-DPCCH и E-DPDCH. Однако никакого нового кода разнесения не используется для отличения их от существующих E-DPCCH и E-DPDCH. Неиспользуемые битовые комбинации E-TFCI используются для указания того, что соответствующий E-DPDCH является командой восходящей линии связи. Для E-DPDCH в типичном случае используется фиксированный и, предпочтительно, существующий формат (например, E-TFCI=0).

Преимущества данной реализации заключаются в том, что не требуется никакого нового средства поиска; не требуется никакой новой цепи декодера или кодера; и не требуется никаких новых тестов на согласованность. Недостатки состоят в том, что данный подход может быть применим только во варианте с TTI длительностью 2 мс, поскольку на текущий момент только в TTI 2 мс имеются неиспользуемые битовые комбинации E-TFCI; команда восходящей линии связи будет фиксированного размера, поскольку может быть использована только одна неиспользуемая битовая комбинация; и базовая станция декодирует два канала для получения команды.

Иллюстративный формат показан на Фиг. 7. Здесь:

○ в E-DPCCH нет никаких изменений, существующие биты указания удовлетворенности (Happy Bits), порядковый номер при повторной передаче (RSN) и E-TFCI не изменяются. Неиспользуемые битовые комбинации E-TFCI используются для указания того, что вложенный E-DPDCH является командой восходящей линии связи.

○ Для E-DPDCH подразумевается, например, формат E-TFCI=0, который состоит из 18 битов. Следовательно, структура аналогична структуре обособленного E-DPDCH.

Поскольку это является сообщением Уровня 1, пользовательское устройство идентифицируется по используемому коду скремблирования.

Реализация 5 - Модификация Уровня 2

В дополнение к реализации физического канала Уровня 1, для переноса команды восходящей линии связи можно также использовать сообщение канала Уровня 2, такое как короткое сообщение RLC или MAC. В HSPA, Уровень 2 находится на базовой станции, и, следовательно, нет необходимости в прохождении сообщения Уровня 2 от пользовательского устройства через RNC 40, чтобы достичь необслуживающих сот пользовательского устройства. Более того, сообщение MAC может переноситься посредством существующего восходящего канала (например, E-DCH), что таким образом позволяет избежать выполнения каких-либо дополнительных тестов на согласованность рабочих характеристик.

Например, команда восходящей линии связи переносится посредством сообщения MAC Уровня 2. Это сообщение MAC Уровня 2 должно содержать поле заголовка для указания того, что оно представляет собой команду (т.е. с переконфигурированием радиосвязи), идентификатор для идентификации пользовательского устройства, посылающего команду, и саму команду. Поскольку эта команда на Уровне 2, ее можно переносить по существующим физическим каналам.

Преимущества данной реализации заключаются в том, что команда является гибкой в плане ее размера; нового средства поиска не требуется; новой цепи декодера или кодера не требуется; новых тестов на согласованность не требуется. Недостатки состоят в том, что команда восходящей линии связи является медленной в смысле достижения базовой станции, поскольку она на Уровне 2; квитанции, вероятно, будут медленными (по всей вероятности, квитанции RLC - пользовательское устройство может быть реализовано так, чтобы считать квитанции Уровня 1 (например, E-HICH) для этого случая квитанциями Уровня 2).

Иллюстративный формат показан на Фиг. 8. Здесь:

○ ACK_REQ, состоящие из 2 битов, используются для указания того, требуется ли квитанция со стороны обслуживающей или необслуживающей соты, что будет описано более подробно ниже.

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

○ Дополнительные заголовки команды.

○ Представление команды. Каждая битовая комбинация задает команду.

○ Идентификационные данные UE. Здесь используется 16-битовый E-RNTI пользовательского устройства.

Данное сообщение Уровня 2 может переноситься посредством E-DPDCH, и, следовательно, контрольная сумма не требуется, поскольку на физическом уровне (т.е. E-DPDCH) проверка контрольной суммы уже выполнена.

Иллюстративное функционирование - Сценарий 1

Фиг. 9 и 10 иллюстрируют примерную работу сети при использовании команд восходящей линии связи. В этом примере команда восходящей линии связи переносится посредством существующего канала E-DCH и указывается посредством неиспользуемого E-TFCI. Инструкция декодирования E-DPDCH фиксирована, известна для базовой станции и может быть представлена следующим образом:

1) Коэффициент разнесения (SF) 256;

2) E-TFCI=0 (18 информационных битов).

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

○ ACK_REQ=”00” означает, что от обслуживающей и необслуживающих сот не требуется квитанций;

○ ACK_REQ=”01” означает, что квитанция требуется только от необслуживающих сот;

○ ACK_REQ=”10” означает, что квитанция требуется только от обслуживающей соты;

○ ACK_REQ=”11” означает, что квитанция требуется от обслуживающей и необслуживающих сот.

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

○ ACK_REQ=”00” означает, что никаких действий от обслуживающей и необслуживающих сот не требуется;

Это может быть послано исключительно как информация;

○ ACK_REQ=”01” означает, что выполнение действия требуется только от необслуживающих сот;

○ ACK_REQ=”10” означает, что выполнение действия требуется только от обслуживающей соты;

○ ACK_REQ=”11” означает, что выполнение действия требуется от обслуживающей и необслуживающих сот.

Предположим, что пользовательское устройство функционирует в соответствии с 4C-HSDPA по двум полосам частот, как показано на Фиг. 9. Для пользовательского устройства желательно сбережение энергии аккумуляторной батареи, и оно решает отключить неосновные несущие (неосновные несущие 2 и 3) в неосновной полосе.

Как показано на Фиг. 10, пользовательское устройство посылает запрос на свою базовую станцию в виде команды восходящей линии связи с ACK_REQ=”00”, поскольку это всего лишь запрос и действие от этой обслуживающей соты выступает в роли квитанции на эту команду. ACT_REQ устанавливается в ”10”, поскольку от обслуживающей соты требуется только действие (т.е. команда HS-SCCH). Обслуживающая и необслуживающие соты принимают команду восходящей линии связи. Поскольку ACK_REQ=”00”, никакой квитанции сотами не посылается. Поскольку ACT_REQ=”10”, данный запрос касается только обслуживающей соты и, следовательно, никаких действий со стороны необслуживающих сот не требуется. Обслуживающая сота определяет, что она может безопасным образом деактивировать неосновные несущие 2 и 3, и посылает команду HS-SCCH деактивировать эти несущие. Пользовательское устройство квитирует эту команду и переходит к деактивации целевых несущих.

Иллюстративное функционирование - Сценарий 2

Фиг. 11 и 12 иллюстрируют примерную работу сети при использовании команд восходящей линии связи. В этом примере используется та же самая команда восходящей линии, что и в Сценарии 1. UE 4C-HSDPA имеет такую конфигурацию несущих по частотам, что обозначена как "Исходная конфигурация" на Фиг. 11. Здесь, CP соответствует основной несущей, а CS1, CS2 и CS3 соответствуют неосновной несущей 1, неосновной несущей 2 и неосновной несущей 3, соответственно. На Фиг. 11, CP первоначально фиксируется на частоте F2. В этом примере подразумевается, что в сети 4C-HSDPA для базовой станции является возможным сменять основную несущую пользовательского устройства на одну из его активных неосновных несущих посредством команды HS-SCCH. Базовая станция (т.е. обслуживающая сота) решает сменить CP с F2 на F1, что обозначено как "Целевая конфигурация" на Фиг. 11.

Базовая станция посылает команду HS-SCCH сменить основную несущую, как показано на сигнальной диаграмме по Фиг. 12. Пользовательское устройство принимает команду HS-SCCH и посылает квитанцию на базовую станцию, которая соответствует обслуживающей соте. Поскольку смена основной несущей воздействует на необслуживающие соты, пользовательское устройство посылает команду восходящей линии связи для информирования необслуживающей соты об изменении в основной несущей. Как ACK_REQ, так и ACT_REQ устанавливаются в ”01” и, следовательно, только от необслуживающей соты требуется отправка квитанции и выполнение действия. Необслуживающая сота, таким образом, становится осведомленной о том, что пользовательское устройство сменит свою основную несущую с F1 на F2, и квитирует команду восходящей линии связи посредством E-HICH на пользовательское устройство. От обслуживающей соты не требуется никакого действия. По приему квитанции (E-HICH) от необслуживающей соты пользовательское устройство переходит к смене своей основной несущей (следует отметить, что эта одна и та же команда восходящей линии связи достигнет других необслуживающих сот, если имеется более одной необслуживающей соты).

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

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

Специалист без труда поймет, что этапы различных способов, описанных выше, могут выполняться запрограммированными компьютерами. Здесь некоторые варианты осуществления также подразумеваются охватывающими устройства хранения программ, например, носители для хранения цифровых данных, которые являются машино- или компьютерно-читаемыми и на которых закодированы машиноисполняемые или компьютерно-исполняемые программы, состоящие из инструкций, где этими инструкциями выполняются некоторые или все из этапов упомянутых вышеописанных способов. Устройства хранения программ могут представлять собой, например, цифровые запоминающие устройства, магнитные носители информации, такие как магнитные диски и магнитные ленты, накопители на жестких магнитных дисках или оптически-считываемые носители для хранения цифровых данных. Варианты осуществления также подразумеваются охватывающими компьютеры, запрограммированные для выполнения упомянутых этапов вышеописанных способов.

Функции различных элементов, показанных на фигурах, включая любые функциональные блоки, помеченные как ”процессоры” или ”логические средства” (”логика”), могут обеспечиваться посредством использования специализированного аппаратного обеспечения, а также аппаратного обеспечения, выполненного с возможностью исполнения программного обеспечения, в сочетании с соответствующим программным обеспечением. Упомянутые функции, когда они обеспечиваются процессором, могут обеспечиваться одиночным специализированным процессором, одиночным совместно используемым процессором или посредством множества отдельных процессоров, некоторые из которых могут быть совместно используемыми. Более того, явное использование термина ”процессор” или ”контроллер” или ”логические средства” не следует толковать как относящееся исключительно к аппаратному обеспечению, приспособленному для исполнения программного обеспечения, и может неявным образом охватывать, но не в ограничительном смысле, аппаратное обеспечение процессора обработки цифровых сигналов (DSP), сетевой процессор, специализированную интегральную схему (ASIC), вентильную матрицу с эксплуатационным программированием (FPGA), постоянное запоминающее устройство (ROM) для хранения программного обеспечения, оперативное запоминающее устройство (RAM) и энергонезависимые запоминающие устройства. Также может охватываться и другое аппаратное обеспечение, общего назначения и/или заказное. Аналогично, любые переключатели, показанные на фигурах, являются лишь концептуальными. Их функция может выполняться посредством функционирования программной логики, посредством специализированной логики, посредством взаимодействия программного управления и специализированной логики или даже вручную, при этом конкретная методика выбирается реализующей стороной, как может быть более детально понято из контекста.

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

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

Изобретение относится к мобильной связи. Технический результат заключается в обеспечении возможности для пользовательского устройства запрашивать переконфигурацию радиоинтерфейса между пользовательским устройством и базовой станцией в системе беспроводной связи с множеством несущих. Заявленный способ содержит этапы, на которых: определяют переконфигурацию, которая должна быть выполнена базовой станцией; кодируют указание данной переконфигурации совместно с индикатором в сообщение запроса переконфигурации, указывающим ответ, требующийся от принимающей базовой станции по приему данного сообщения запроса переконфигурации; и передают сообщение запроса переконфигурации из пользовательского устройства. 4 н. и 11 з.п. ф-лы, 12 ил.

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

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

3. Способ по п.1 или 2, в котором упомянутый индикатор содержит запрос действия, запрашивающий по меньшей мере одну из обслуживающей базовой станции и необслуживающих базовых станций реализовать упомянутую переконфигурацию.

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

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

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

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

8. Способ по п.6, в котором упомянутый восходящий канал управления содержит усовершенствованный выделенный физический канал управления (E-DPCCH), а упомянутый восходящий канал данных содержит усовершенствованный выделенный физический канал данных (E-DPDCH).

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

10. Способ по п.1, в котором на упомянутом этапе кодирования кодируют упомянутое указание переконфигурации и упомянутый индикатор, указывающий, требуется ли ответ, в сообщение уровня два, и на упомянутом этапе передачи передают это сообщение уровня два, в котором закодировано упомянутое сообщение запроса переконфигурации.

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

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

13. Пользовательское устройство, выполненное с возможностью запрашивания переконфигурации радиоинтерфейса между этим пользовательским устройством и одной или более базовыми станциями в системе беспроводной связи, при этом пользовательское устройство содержит:
логическое средство определения, выполненное с возможностью определять переконфигурацию, которая должна быть выполнена одной или более базовыми станциями;
логическое средство кодирования, выполненное с возможностью кодировать указание данной переконфигурации совместно с индикатором в сообщение запроса переконфигурации, причем этот индикатор указывает для каждой базовой станции из по меньшей мере одной принимающей базовой станции, требуется ли от этой базовой станции ответ по приему данного сообщения запроса переконфигурации; и
логическое средство передачи, выполненное с возможностью передавать сообщение запроса переконфигурации из пользовательского устройства.

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

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