Результат интеллектуальной деятельности: СПОСОБЫ И УСТРОЙСТВА В МОБИЛЬНОЙ ТЕЛЕКОММУНИКАЦИОННОЙ СИСТЕМЕ

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

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

УРОВЕНЬ ТЕХНИКИ

Протокол управления радиоресурсами (RRC) в долгосрочном развитии (LTE) 3GPP, также упоминаемом как развитая UTRAN (E-UTRAN), является протоколом сигнализации для конфигурирования и переконфигурирования конфигурации радиоинтерфейса пользовательского оборудования (UE), также называемого мобильными терминалами. Протокол раскрыт в документе технической спецификации TS 36.331 3GPP.

Первая версия, Rel-8, RRC (описанная в TS 36.331 3GPP) LTE использует решение, в котором поля в информационных элементах (IE) могут быть не включены в сообщение. IE состоит из полей. Каждое поле содержит индивидуальное содержание или дополнительный IE, который, в свою очередь, содержит поля или дополнительный IE. Кроме того, одно сообщение содержит множество IE, как проиллюстрировано на фиг.1. В документе технической спецификации TS 36.331 3GPP IE и поле определены следующим образом:

информационный элемент: структурный элемент, содержащий одно или множество полей, упоминают как информационный элемент.

Поле: индивидуальные содержания информационного элемента упоминают как поля.

Использование полей в IE может быть необязательным. Если поле в IE является необязательным, режим работы UE обычно задают для случая, когда это поле отсутствует. Одной мотивацией для определения необязательных полей в сообщениях является уменьшить или минимизировать размер сообщений сигнализации. Типичной ситуацией является случай, когда только части конфигурации пользовательского оборудования (UE) изменяют с помощью сообщения, в то время как большая часть конфигурации UE остается неизмененной. Таким образом, часто задают, чтобы терминал продолжал работать с конкретной функции, когда связанное поле, которое является необязательным в рассматриваемом сообщении, не присутствует в принятом сообщении.

Пример необязательного поля проиллюстрирован ниже, в котором раскрыт IE, содержащий множество полей. Указатель качества канала (CQI) сконфигурирован с информационным элементом, названным CQI-ReportConfig:

CQI-ReportConfig::= SEQUENCE{

Cqi-ReportModeAperiodicENUMERATED{

rm12,rm20,rm22,rm30,rm31,

spare3, spare2, spare1} OPTIONAL-Need OR

nomPDCSH-RS-EPRE-Offset INTEGER(-1..6),

Cqi-ReportPeriodic Cqi-ReportPeriodic OPTIONAL-Need ON

}

В этом IE как Cqi-ReportModeAperiodic, так и Cqi-ReportPeriodic, оба, являются необязательными полями, что указано с помощью синтаксиса OPTIONAL выше.

Таким образом, должен быть задан режим работы UE, когда отсутствуют необязательные параметры. Это может быть сделано с помощью использования тэгов «Need OR» и «Need ON» соответственно, что задает режим работы UE, когда не присутствуют необязательные параметры. Need OR означает, что в случае, когда информационный элемент отсутствует в сообщении, UE должно прекратить использование/прервать или удалить любую существующую конфигурацию или значения, которые иначе были бы сконфигурированы, если бы информационный элемент присутствовал. В противоположность этому с помощью тэга Need ON отсутствие информационного элемента означает, что UE должно продолжить использовать уже существующие значения и связанные функциональные возможности. После чего режим работы, в котором UE должно сохранить конфигурацию и связанные функциональные возможности без изменения каких-либо параметров в моменты времени, когда необязательное поле является пропущенным, называют «необязательным продолжением».

Также другие состояния и функциональный режим работы могут быть явно заданы в процедурах спецификации, т.е. разные режимы работы могут быть заданы, когда необязательное поле не включено в соответствующее сообщение. Например, также IE CQI-ReportConfig является необязательным в IE PhysicalConfigDedicated. IE PhysicalConfigDedicated, в свою очередь, является «необязательным продолжением» в IE RadioResourceConfigDedicated, который, в свою очередь, является необязательным в сообщении RRCConnectionReconfiguration. RRCConnectionReconfiguration является сообщением, посылаемым из EUTRAN в UE для конфигурирования и переконфигурирования функциональных возможностей и связанных параметров в UE. Таким образом, решение для «необязательного продолжения» используют в спецификации таким образом, что только эти поля релевантности для желаемого переконфигурирования должны быть включены в IE сообщения.

Вышеупомянутое решение, использующее «необязательное продолжение», используют, например, во внутренней мобильности LTE. Это также проиллюстрировано на фиг.2. В дальнейшем для случая, когда передача обслуживания мобильного терминала происходит из первой соты во вторую соту, первая сота обозначена как исходная сота, а вторая сота обозначена как целевая сота. Аналогично, когда сотами управляют с помощью разных базовых станций, это обозначено как исходная eNB и целевая eNB соответственно. В этой спецификации eNB также упомянуты как базовые станции. Желательно обмениваться только небольшими сообщениями между UE и eNB при передаче обслуживания. Можно допустить, что многие из функциональных возможностей, используемых в исходной соте, останутся неизмененными в целевой соте, и, следовательно, было бы излишним переконфигурировать все функциональные возможности в целевой соте.

Следовательно, если передача обслуживания происходит между разными eNB, т.е. из исходной eNB в целевую eNB, исходная eNB посылает полную конфигурацию UE в целевую eNB при подготовке к передаче обслуживания. Сообщение «запрос передачи обслуживания» из исходной eNB содержит контекст RRC, который включает в себя «сообщение информации подготовки передачи обслуживания», как определено в TS 36.331 3GPP. Теперь целевая eNB после декодирования принятого контекста уровня доступа может решить, какие части конфигурации UE он находит допустимыми без изменения и какие части должны быть переконфигурированы. Например, вероятно, что ближайшие базовые станции, которыми управляет один и тот же оператор, и, возможно, произведенные одним изготовителем предпочитают одни и те же параметры, которые описывают периодическое сообщение CQI. В таком случае нет необходимости для целевой eNB посылать какую-либо обновленную конфигурацию в UE, поскольку цель без труда принимает эту часть настоящей конфигурации UE. Однако если случается, что целевая eNB осуществляет, например, другую конфигурацию произвольного доступа по сравнению с исходной eNB, может случиться, что цель должна обновить некоторые параметры релевантности произвольного доступа в UE.

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

Протоколы 3GPP опубликованы в разных версиях. Функциональные возможности могут быть изменены между версиями протоколов, и является типичным, что новые, усовершенствованные функциональные возможности добавляют в новые версии протокола. Например, после того как Rel-8 протоколов E-UTRAN будут считать как функционально стабильные, будущие изменения будут добавлены в Rel-9, Rel-10 и т.д.

Обычно невозможно добавлять обратно несовместимые функциональные возможности и расширения протоколов к стабильному протоколу, поскольку это могло бы дать в результате неправильную работу UE и узлов уже вне, в поле, которое не поддерживает такие улучшения. RRC осуществляют с помощью абстрактно-синтаксической нотации один (ASN.1), с помощью которой можно обмениваться сообщениями в новых версиях. Такие расширения обычно включают в себя параметры релевантности для функциональной возможности, которую добавляют в последней версии. Могут быть добавлены как «не критические», так и «критические» расширения.

Критическое расширение предполагает, что приемник более ранней версии такого расширения не будет понимать содержания сообщения. Например, если eNB версии Rel-8 посылала сообщение Rel-9 в UE Rel-8, причем сообщение включает в себя критическое расширение, тогда UE может не достичь успеха, чтобы декодировать сообщение.

Некритическое расширение имеет признак, что приемник более ранней версии может игнорировать некритическое расширение, но приемник все же может успешно декодировать части сообщения, которое соответствует более ранней версии. Например, если eNB Rel-9 послала бы сообщение в UE Rel-8, причем сообщение включает в себя некритическое расширение, тогда UE все же может декодировать части сообщения, которое следует синтаксису Rel-8. Rel-8 RRC включает в себя шаблоны в сообщениях и соответствующие IE для таких некритических расширений. Это сделано для того, чтобы подготовиться к расширяемости протокола RRC.

Замечено, что «необязательное продолжение» может вызвать проблему при передаче обслуживания для тех случаев, в которых исходная eNB и целевая eNB осуществляют разные варианты версий протоколов. Заявитель предполагает, что целевая eNB осуществляет протокол и функциональные возможности, заданные в Rel-8. Кроме того, заявитель дополнительно допускает, что исходная eNB осуществляет более позднюю версию с дополнительной функциональной возможностью, например Rel-9. Дополнительно допускают, что добавленная функциональная возможность в протоколе RRC Rel-9 добавлена с использованием расширений протокола и что UE сконфигурировано с признаками, связанными с новыми признаками Rel-9. Одна проблема, связанная с этим сценарием, происходит, если вышеупомянутые новые информационные элементы или поля в более поздней версии (например, Rel-9) добавлены с использованием критических расширений, т.е. исходная eNB посылает сообщение «информации подготовки передачи обслуживания» в целевую eNB, поскольку приведенная в качестве примера целевая eNB Rel-8 может не достичь успеха, чтобы декодировать сообщение контекста уровня доступа, принятое в сообщении подготовки передачи обслуживания. В таком случае целевой eNB необходимо послать полное сообщение переконфигурирования в UE в «команде передачи обслуживания», так как цель не может декодировать конфигурацию UE, т.е. целевая eNB не знает, какую конфигурацию имеет UE в текущий момент. Следовательно, «необязательное продолжение» было бы невозможным для eNB предыдущей версии, и были бы необходимы большие сообщения передачи обслуживания. Другая связанная проблема происходит, если вышеупомянутые новые информационные элементы или поля в более поздней версии (например, Rel-9) добавлены с использованием некритических расширений. В этом случае приведенная в качестве примера eNB Rel-8, поддерживающая предыдущую версию, может успешно декодировать параметры, включенные в предыдущей версии. Однако целевая eNB не будет понимать кодирования полей более поздней версии, и она должна была бы игнорировать эти поля. Следовательно, эти поля не присутствовали бы в «команде передачи обслуживания», поскольку целевая eNB не знала бы, как кодировать такие поля.

Проблема происходит в UE более поздней версии (например, Rel-9), которое принимает «команду передачи обслуживания». Если принцип «необязательного продолжения» был осуществлен для новых полей, тогда UE должно продолжить использование сконфигурированных признаков более поздней версии после передачи обслуживания без каких-либо изменений. Однако в примере неприсутствие этих новых полей было вследствие того факта, что целевая eNB не понимала этих полей и целевая eNB совершенно не поддерживала признаки протокола более поздней версии. Следовательно, может произойти несоответствие, когда UE продолжает использовать функциональную возможность, которую не осуществляет целевая eNB, и могли бы происходить серьезные протокольные и функциональные ошибки, поскольку взаимодействующие равноправные объекты (UE и целевая eNB) допускали бы разные конфигурации.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг.2 иллюстрирует сценарий мобильности в соответствии с предшествующим уровнем техники.

Фиг.3 иллюстрирует сценарий мобильности.

Фиг.4 и фиг.5 иллюстрируют блок-схемы последовательности этапов способов в соответствии с вариантами осуществления настоящего изобретения.

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

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

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

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

Следующее подробное описание описывает варианты осуществления настоящего изобретения, проиллюстрированные посредством конкретных примеров. В примерах допускают, что передача обслуживания пользовательского оборудования (UE) будет выполнена из первой базовой станции во вторую базовую станцию, также упомянутые как исходная базовая станция и целевая базовая станция соответственно. Также следует заметить, что базовые станции упоминаются как eNB, так как варианты осуществления ниже описаны совместно с LTE. Первая eNB содержит, по меньшей мере, функциональную возможность, поддерживающую определенную конфигурацию UE, которая не содержится во второй eNB. В описании ниже это описано как то, что первая eNB является более поздней версией, чем вторая eNB. Более поздняя версия приведена в качестве примера как Rel-9 LTE, а версия второй eNB приведена в качестве примера как Rel-8 LTE. Кроме того, UE сконфигурировано с новой функциональной возможностью, которую не поддерживают в Rel-8 LTE. Новая функциональная возможность связана с первым полем информационного элемента (IE) сообщения, в соответствии с протоколом сигнализации Rel-9. Новая функциональная возможность также может быть охарактеризована с помощью множества таких первых полей информационного элемента сообщения. Следует понимать, что пример также является действующим в любом сценарии, в котором исходная eNB и UE поддерживают функциональную возможность, еще не поддерживаемую целевой eNB.

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

В соответствии с вариантами осуществления настоящего изобретения со ссылкой на фиг.3 исходная eNB 310 посылает 301 сообщение 330 в целевую eNB 312, причем сообщение 330 содержит информационный элемент (IE) 320, который, в свою очередь, содержит первое поле 322, связанное с конфигурацией UE, поддерживаемой исходной eNB 310, но не поддерживаемой с целевой eNB 312. IE 320 дополнительно содержит другие конфигурации UE, поддерживаемые как исходной, так и целевой eNB. В этом примере первое поле закодировано как некритические расширения версии 9. Конфигурацию UE обычно туннелируют или встраивают в сообщение «запроса передачи обслуживания» из исходной eNB 310 в целевую eNB 312. Целевая eNB 312 может декодировать сообщение за исключением некритических расширений, которые целевая eNB 312 игнорирует. Поскольку целевая eNB 312 не поддерживает конфигурацию UE, связанную с первым полем, целевая eNB 312 пропускает первое поле при создании 302 сообщения переконфигурирования, посылаемого в UE 314 исходной eNB 310. Вместо этого целевая eNB может добавить флаг или другое указание во втором поле, где указано, что целевая eNB не поддерживает конфигурацию UE, которую поддерживают UE и eNB более поздних версий, например, с помощью сообщения UE, чтобы прекратить использование этой конфигурации UE.

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

Затем целевая eNB 312 посылает 303 команду передачи обслуживания, например, с использованием сообщения RRCConnectionReconfiguration, причем это сообщение кодируют в соответствии с версией, поддерживаемой целевой eNB 312. Это сообщение переконфигурирования соединения RRC адресуют в UE и его обычно туннелируют или встраивают в сообщение подтверждения передачи обслуживания из целевой eNB в исходную eNB. Сообщение переконфигурирования обычно передают немодифицированным, т.е. прозрачно, с помощью исходной eNB. Таким образом, именно целевая eNB берет ответственность за конфигурирование UE некоторым способом, который является подходящим для целевой eNB, если передача обслуживания завершена.

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

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

(1) Целевая eNB запрашивает UE продолжить с конфигурацией UE, связанной с пропущенным полем,

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

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

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

Вышеупомянутое второе поле может быть включено в том же самом IE или в другом IE в качестве первого поля, связанного с функциональной возможностью, которую может не поддерживать целевая базовая станция. Примером IE, в котором может быть включено второе поле, является IE управления мобильностью в протоколе RRC. Вышеупомянутый поиск, выполняемый UE, присутствия или значения второго поля после обнаружения, что первое поле является пропущенным, может быть выполнен при передаче обслуживания, т.е. когда UE принимает решение между предприятием первого или второго действия, только если сообщение является сообщением, которое инициирует передачу обслуживания. Следовательно, IE управления мобильностью является одним возможным примером того, где могло бы быть включено второе поле, и следует понимать, что в других вариантах осуществления мог бы быть использован любой IE в команде НО, который непосредственно не связан с новой рассматриваемой функциональной возможностью. Как объяснено выше, указание во втором поле могло бы быть указанием для UE продолжить с ранее сконфигурированной функциональной возможностью в определенном множестве новых функциональных возможностей, если соответствующая информация конфигурирования отсутствует в команде НО, т.е. когда пропущено первое поле. Такое множество новых функциональных возможностей могло бы быть определено как новые функциональные возможности, введенные в конкретной версии спецификации, или, более конкретно, определенная группа функциональных возможностей. Например, если UE сконфигурировано в соответствии с версией N+4, но целевая eNB поддерживает только версию N+2, новые функциональные возможности, введенные в каждой версии, могли бы быть сгруппированы таким образом, что UE в зависимости от значения или присутствия второго поля отдают команду, чтобы продолжить с частями новых функциональных возможностей и прекратить с частями других новых функциональных возможностей. В этом примере UE могла бы быть отдана команда прекратить использование любых функциональных возможностей, введенных после версии N+2, но продолжить со всеми новыми функциональными возможностями, введенными до N+2. Следовательно, новые функциональные возможности, которые подвергнуты вышеупомянутой оценке в UE, могли бы быть сгруппированы в каждой версии. Это указание могло бы быть реализовано с помощью отдельного второго поля на версию или с помощью второго поля, которое может принимать множество значений.

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

Как проиллюстрировано на фиг.4, принимают 401 сообщение запроса, НО из исходной базовой станции, содержащее, по меньшей мере, первое поле информационного элемента, связанного с первой функциональной возможностью, например функциональной возможностью RRC, не поддерживаемой целевой базовой станцией. Целевая базовая станция декодирует 402, по меньшей мере, часть принятого сообщения запроса, НО и составляет 403 сообщение переконфигурирования, используемое, чтобы сконфигурировать UE, передаваемое на обслуживание в целевую базовую станцию. Составление 403 содержит пропуск 404 вставки, по меньшей мере, первого поля и вставку 405 второго поля. Второе поле указывает, как должно быть сконфигурировано UE относительно первой функциональной возможности. Затем базовая станция посылает 406 составленное сообщение переконфигурирования в UE посредством исходной базовой станции.

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

Кроме того, предоставлен способ в UE, как проиллюстрировано на фиг.5. UE сконфигурировано с возможностью быть переданным на обслуживание из исходной базовой станции в целевую базовую станцию в сценарии передачи обслуживания, причем целевая базовая станция может не поддерживать функциональные возможности, например, функциональные возможности RRC, которые поддерживают исходная базовая станция и UE. UE принимает 501 сообщение конфигурирования из целевой базовой станции посредством исходной базовой станции и конфигурирует 502 UE на основании принятого сообщения конфигурирования из целевой базовой станции. Конфигурирование выполняют с помощью поиска 503 второго поля в информационном элементе принятого сообщения конфигурирования. Присутствие/неприсутствие или значение второго поля указывает, как управлять сконфигурированной первой функциональной возможностью, связанной с необязательным первым полем, причем сконфигурированная первая функциональная возможность может не поддерживаться целевой базовой станцией.

Значение второго поля может быть присутствием или неприсутствием флага, причем флаг может быть флагом fullConfig (полной конфигурации).

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

Теперь, обращаясь к фиг.6, проиллюстрирована базовая стация 600, предназначенная для конфигурирования UE 620 в сценарии передачи обслуживания, когда передают обслуживание UE 620 из исходной базовой станции в базовую станцию 600. Базовая станция 600 сконфигурирована без возможности поддержки, по меньшей мере, одной функциональной возможности, которую поддерживают исходная базовая станция и UE. Базовая станция 600 содержит приемник/передатчик и другие радиочастотные функциональные возможности, предназначенные для связи с UE. Базовая станция также сконфигурирована с возможностью связи с другими базовыми станциями. Кроме того, устройства обработки, необходимые для функциональных возможностей, не важных для изобретения, не включены в чертежи и описание.

Базовая станция 600 содержит приемник 601, сконфигурированный с возможностью приема сообщения запроса передачи обслуживания (НО) из исходной базовой станции, содержащего, по меньшей мере, первое поле информационного элемента, связанное с первой функциональной возможностью, не поддерживаемой базовой станцией. Базовая станция 600 дополнительно содержит декодер 602, сконфигурированный с возможностью декодирования, по меньшей мере, части принятого сообщения запроса НО, в зависимости от того, декодируют ли сообщение запроса, НО с критическими или некритическими расширениями в версию протокола, которую не поддерживает целевая базовая станция. Базовая станция дополнительно содержит процессор 603, сконфигурированный с возможностью составления сообщения переконфигурирования, используемого, чтобы конфигурировать UE, передаваемое на обслуживание в целевую базовую станцию. Также процессор 603 дополнительно сконфигурирован с возможностью пропуска вставки, по меньшей мере, первого поля и вставки второго поля, причем второе поле указывает, как должно быть сконфигурировано UE относительно первой функциональной возможности. Кроме того, базовая станция содержит передатчик 604, сконфигурированный с возможностью посылки составленного сообщения переконфигурирования в UE посредством исходной базовой станции.

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

Как проиллюстрировано на фиг.6, UE содержит приемник/передатчик 621 и другие радиочастотные функциональные возможности, предназначенные для связи с сетью. Кроме того, устройства обработки, необходимые для функциональных возможностей, не важных для изобретения, не включены в чертежи и описание. В соответствии с настоящим изобретением UE 620 содержит приемник, сконфигурированный с возможностью приема сообщения конфигурирования из целевой базовой станции посредством исходной базовой станции. Процессор 622 в UE сконфигурирован с возможностью поиска второго поля в информационном элементе принятого сообщения конфигурирования. Присутствие/неприсутствие или значение второго поля указывает, как управлять сконфигурированной первой функциональной возможностью, связанной с необязательным первым полем, причем сконфигурированная первая функциональная возможность может не поддерживаться целевой базовой станцией.

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

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

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

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

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

Как объяснено выше, предложено посылать (по меньшей мере) два представления текущей конфигурации UE в целевую eNB, причем одно основано на «аварийной» версии протокола, а другое на критической расширенной версии, поддерживающей полную конфигурацию UE. В этой спецификации Rel-8 LTE приведена в качестве примера как «аварийная» версия.

Однако в будущем, когда, например, Rel-9 LTE и Rel-10 LTE без труда будут осуществлены как в исходной, так и целевой eNB, могло бы быть желательным не посылать дальние «аварийные» альтернативы просто, поскольку неизвестно точное состояние равноправного узла. Следовательно, в дополнительном варианте осуществления «согласуют» между исходной и целевой eNB при создании линии связи Х2, чтобы определить, какую версию протокола использовать. Это могло бы быть реализовано, например, если каждый узел указывает другому, до какой версии протокола он поддерживает. Следовательно, два объекта обеспечивают, по меньшей мере, одну общую поддерживаемую версию в качестве «аварийной» версии. Первая eNB может запросить информацию о варианте версии, поддерживаемой второй eNB. На основании знания варианта версии целевой eNB исходная eNB теперь может принять решение, чтобы утвердить конфигурацию уровня доступа, которую понимает исходная eNB. Тем не менее также с разными вариантами осуществления, связанными с решением посылки информации между разными eNB относительно текущей конфигурации UE, закодированной в соответствии с разными версиями протокола, имеется потребность в указании, с помощью которого UE принимает решение, как действовать, когда необязательные поля или IE более поздней версии не присутствуют в сообщении.

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