Управление поведением пользовательского оборудования выпуска 7 и выпуска 8 в ходе конфигурирования режима непрерывной пакетной передачи

Управление поведением пользовательского оборудования выпуска 7 и выпуска 8 в ходе конфигурирования режима непрерывной пакетной передачи

Иллюстрации

Показать все

Реферат

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

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

Уровень техники

Режим непрерывной пакетной передачи (CPC), введенный в выпуске 7 спецификаций проекта партнерства третьего поколения (3GPP) для универсальной системы мобильной связи (UMTS), ставит своей целью улучшение восприятия пользователя путем увеличения срока эксплуатации батареи. CPC также служит для повышения емкости сети путем снижения помех.

Фактически CPC является совокупностью нескольких функций. Во-первых, CPC включает в себя поддержку прерывистой передачи на восходящей линии связи (UL-DTX). Эти функции позволяют мобильной станции (пользовательскому оборудованию или UE, в терминологии 3GPP) прерывисто передавать на канале управления восходящей линии связи (выделенном физическом канале управления восходящей линии связи или U-DPCCH) в течение периодов неактивности, то есть когда UE не имеет данных для отправки. Это позволяет экономить энергию батареи, поскольку UE может отключать схему передатчика, и также снижает помехи, что позволяет повысить емкость системы. Во-вторых, CPC включает в себя поддержку прерывистого приема передач нисходящей линии связи (DL-DRX), что позволяет UE периодически отслеживать канал управления нисходящей линии связи (высокоскоростной совместно используемый канал управления или HS-SCCH) и, таким образом, также снижает энергопотребление батареи на UE. В-третьих, CPC добавляет новый формат слотов на канале управления восходящей линии связи (U-DPCCH) для улучшения управления мощностью нисходящей линии связи.

Работа CPC поддерживается функцией, именуемой «команды HS-SCCH», которая обеспечивает быстрый механизм сигнализации уровня 1 (L1) для активации или деактивации прерывистой передачи восходящей линии связи (UL-DTX) и/или прерывистого приема нисходящей линии связи (DL-DRX). Эти команды активации или деактивации отправляются обслуживающей базовой станцией на мобильный терминал путем отправки команды сигнализации уровня 1 (L1) на UE на высокоскоростном совместно используемом канале управления (HS-SCCH) без участия контроллера радиосети (RNC).

Сигнализация управления радиоресурсами (RRC) используется для конфигурирования поведения UE в отношении UL-DTX и DL-DRX. В частности, конфигурация RRC задает несколько параметров хронирования, применяемых UE для определения, как часто и когда UE должно передавать на канале управления восходящей линии связи и как часто и когда UE должно отслеживать HS-SCCH.

CPC был впервые введен в выпуске 7 спецификаций 3GPP и используется с тех пор. Однако недавно было установлено, что поведение UE, отвечающих версиям выпуска 7 и выпуска 8 спецификаций 3GPP, не полностью задано в отношении переконфигурирования UL-DTX и DL-DRX. В частности, если UE уже сконфигурировано согласно DTX/DRX и принимает сообщение переконфигурирования RRC, в котором значение информационного элемента (IE) «информация хронирования DTX-DRX» не задано равным «Продолжать», и если обслуживающая сота высокоскоростного совместно используемого канала нисходящей линии связи (HS-DSCH) не изменилась в результате этого сообщения, поведение UE в отношении «запоминания» его статуса активации CPC отчетливо не задано. Первоначальная идея при создании спецификаций CPC состояла в том, что UE запоминает статус активации CPC. Таким образом, если CPC был активирован до переконфигурирования, CPC будет по-прежнему активирован после переконфигурирования RRC. Аналогично, если CPC не был активирован до переконфигурирования, он останется в этом состоянии и далее. Однако в зависимости от конкретной реализации UE может быть предусмотрено или не предусмотрено предписание физическому уровню учитывать, что команды HS-SCCH, связанные с DTX/DRX, принятые до переконфигурирования, никогда не принимаются. Другими словами, некоторые UE выпуска 7 и выпуска 8 могут забывать статус активации CPC вследствие вышеописанного переконфигурирования RRC. Это будет приводить к рассогласованию между обслуживающей базовой станцией («узлом B», в терминологии 3GPP) и UE в отношении статуса активации CPC. Один пример конфигурации RRC, для которого будет иметь место это рассогласование, осуществляется в ходе мягкого хэндовера и более мягкого хэндовера, когда новая информация хронирования DTX-DRX задается на UE посредством сообщения обновления активного набора RRC.

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

Сущность изобретения

Как упомянуто выше, в случаях когда обслуживающий узел B деактивировал CPC и затем UE переконфигурируется с помощью сообщения переконфигурирования RRC, где значением IE «информация хронирования DTX-DRX» не является «Продолжать», и обслуживающая сота HS-DSCH не изменилась в результате этого сообщения, может случиться, что UE будет действовать так, как будто бы CPC активирован, тогда как обслуживающий узел B, с другой стороны, может действовать, как будто бы функциональные возможности CPC все еще деактивированы.

Поскольку при этом предполагается, что CPC деактивирован, то узел B принимает решения по планированию исходя из того, что UE непрерывно отслеживает нисходящую линию связи. Однако если UE (после сообщения переконфигурирования RRC) действует, как будто бы оно было сконфигурировано с CPC, то оно будет прослушивать нисходящую линию связи только в определенных TTI. Если узел B передает пакеты нисходящей линии связи в интервалах времени передачи (TTI), в течение которого UE в состоянии DRX не осуществляет прослушивание, количество повторных передач управления линиями радиосвязи (RLC) будет возрастать, что негативно скажется на производительности на стороне системы и пользователя. Один пример конфигурации RRC, для которого это рассогласование может иметь место, реализуется в ходе мягкого хэндовера и более мягкого хэндовера, когда новая информация хронирования DTX-DRX задается на UE посредством сообщения обновления активного набора RRC.

Эту проблему можно решить, внося очень незначительные изменения в стандарт, с использованием методов, реализованных на RNC, или узле B, или на обоих. В некоторых вариантах осуществления этих методов ранее известные сообщения сигнализации и/или заголовки кадров плоскости пользователя модифицируются для включения новых индикаторов/параметров, которые используются для сигнализации того, что данное UE предположительно имеет неоднородное поведение в отношении запоминания статуса активации CPC после действия по сообщению переконфигурирования RRC, поскольку оно является мобильной станцией выпуска 7 или выпуска 8. Эти новые индикаторы/параметры также могут использоваться узлом B в некоторых вариантах осуществления для квитирования получения от RNC индикации того, что для данного UE следует ожидать неоднородного поведения.

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

В некоторых вариантах осуществления способ, кратко описанный выше, выполняется в контексте процедуры мягкого хэндовера. Например, этот способ может осуществляться по завершении процедуры мягкого хэндовера для UE. В ряде случаев индикатор восстановления CPC отправляется в кадре управления «запрос емкости HS-DSCH», например, с использованием ранее зарезервированного бита. В некоторых вариантах осуществления ответ квитирования принимается от узла B через кадр управления «выделение емкости».

Другие примерные способы включают в себя дополнительные способы, реализованные базовой станцией/узлом B. Один такой способ содержит прием индикатора восстановления CPC, соответствующего UE, обслуживаемого базовой станцией, в заголовке кадра, по меньшей мере, одного кадра плоскости пользователя, отправленного RNC на базовую станцию. В ответ на индикатор восстановления CPC инициируется механизм восстановления CPC. Эта процедура может содержать, например, передачу команды HS-SCCH для активации или деактивации CPC на UE. В некоторых вариантах осуществления базовая станция отправляет предварительно определенное количество экземпляров команды, тогда как в других - базовая станция неоднократно отправляет команду, пока не примет от UE индикатор, указывающий, что оно приняло команду. В некоторых вариантах осуществления базовая станция отправляет квитирование индикатора восстановления CPC на RNC, откуда она приняла его. Затем базовая станция может игнорировать последующие индикаторы восстановления CPC от RNC, например, до истечения предварительно определенного времени или только после приема от RNC одного или более кадров, которые не включают в себя индикатор восстановления CPC.

Прочие примерные способы включают в себя другие способы, реализованные базовой станцией/узлом B. Один такой способ содержит определение статуса активации CPC для UE. В некоторых вариантах осуществления это осуществляется путем вычисления шаблона приема HS-SCCH для DRX, который соответствует UE, и наблюдения, квитирует ли UE передачи на HS-SCCH, которые соответствуют шаблону.

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

Краткое описание чертежей

Фиг. 1 - схема обмена сигналами, демонстрирующая обмен сообщениями согласно некоторым вариантам осуществления настоящего изобретения.

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

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

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

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

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

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

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

Как упомянуто выше, в случаях когда обслуживающий узел B деактивировал CPC и затем UE переконфигурируется с помощью сообщения переконфигурирования RRC, где значением IE «информация хронирования DTX-DRX» не является «Продолжать», и обслуживающая сота HS-DSCH не изменилась в результате этого сообщения, может случиться, что UE будет действовать так, как будто бы CPC активирован, тогда как обслуживающий узел B, с другой стороны, может действовать, как будто бы функциональные возможности CPC все еще деактивированы.

Поскольку при этом предполагается, что CPC деактивирован, то узел B принимает решения по планированию исходя из того, что UE непрерывно отслеживает нисходящую линию связи. Однако если UE (после сообщения переконфигурирования RRC) действует, как будто бы оно было сконфигурировано с CPC, то оно будет прослушивать нисходящую линию связи только в определенных TTI. Если узел B передает пакеты нисходящей линии связи в интервалах времени передачи (TTI), в течение которого UE в состоянии DRX не осуществляет прослушивание, количество повторных передач управления линиями радиосвязи (RLC) будет возрастать, что негативно скажется на производительности на стороне системы и пользователя. Один пример конфигурации RRC, для которого это рассогласование может иметь место, реализуется в ходе мягкого хэндовера и более мягкого хэндовера, когда новая информация хронирования DTX-DRX задается на UE посредством сообщения обновления активного набора RRC.

Сигнализация между обслуживающим контроллером радиосети (SRNC) и узлом B отправляется по интерфейсу Iub, тогда как сигнализация между SRNC и дрейфующей подсистемы радиосети (DRNS) имеет место по интерфейсу Iur. В заданной в настоящее время сигнализации ничто не указывает на то, что этот тип переконфигурирования CPC имел место. В результате узлу B ничего не известно о ситуации потенциального рассогласования активации CPC. Однако эта проблема ограничивается только UE выпуска 7 и выпуска 8, поскольку поведение UE в ответ на переконфигурации RRC является строго определенным начиная с выпуска 9 спецификаций 3GPP.

Нижеследующее рассмотрение включает в себя описание нескольких возможных решений этой проблемы. Первый подход можно описать как смешанную сигнализацию плоскости управления и плоскости пользователя. Два тесно связанных дополнительных подхода основаны на использовании кадров управления в плоскости пользователя; оба эти подхода используют кадр управления «запрос емкости HS-DSCH», при этом один из них добавляет использование кадра управления «выделение емкости». Наконец, четвертый подход опирается на обслуживающий узел B для определения для самого себя, произошло ли потенциальное рассогласование в отношении статуса активации CPC. Ниже все эти четыре решения описаны более подробно.

Решение 1: смешанное решение плоскости управления и плоскости пользователя

Согласно этому первому подходу индикатор плоскости управления вводится в интерфейсах Iub и Iur для решения рассогласования статуса активации CPC между UE и узлом B. Обслуживающий RNC (SRNC) может использовать этот индикатор для информирования узла B или дрейфовых подсистем радиосети (DRNS) о том, что UE имеет неоднородное поведение в отношении запоминания статуса активации CPC после действия по сообщению переконфигурирования RRC. В этом контексте «неоднородное поведение в отношении запоминания статуса активации CPC» просто означает, что поведение UE в отношении запоминания статуса активации CPC после переконфигурирования RRC не является строго определенным, что, в свою очередь, означает, что между узлом B и UE существует потенциальное рассогласование в отношении статуса активации CPC.

В современном протоколе сигнализации, заданном в спецификациях прикладной части узла B (NBAP) и прикладной части подсистемы радиосети (RNSAP) 3GPP, можно вводить этот индикатор без значительных изменений, например, используя некоторые из существующих резервных битов. Хотя этот подход решает проблему в большинстве сценариев трафика, он не подходит к сценарию, где UE действует в условиях мягкого хэндовера и добавляется новая линия радиосвязи. Дело в том, что SRNC не сообщается с обслуживающим узлом B в ходе мягкого хэндовера через плоскость управления. Таким образом, вышеописанного индикатора плоскости управления по Iub и Iur недостаточно для охвата всех сценариев.

Для обработки этого сценария мягкого хэндовера одно решение состоит в использовании внутриполосной сигнализации плоскости пользователя, которая позволяет SRNC сообщаться с обслуживающим узлом B. В частности, заголовки кадров HS-DSCH имеют резервные биты, которые можно использовать для сигнализации узлу B о том, что UE имеет неоднородное поведение в отношении запоминания статуса активации CPC после действия по сообщению переконфигурирования RRC.

Когда обслуживающему узлу B сообщается о неоднородности UE, он может разрешить потенциальное рассогласование путем передачи команды HS-SCCH целевой соты для активации или деактивации CPC. В дальнейшем действия узла B в ответ на обучение потенциальному рассогласованию в отношении статуса активации CPC будут именоваться «процедурой восстановления CPC» или «восстановлением CPC». Одна проблема, которую следует упомянуть, состоит в том, что если UE действует, как если бы CPC был активирован, то оно будет отслеживать только канал HS-SCCH в определенных TTI. Конкретные отслеживаемые TTI будут зависеть от номера кадра соединения (CFN) и сконфигурированного цикла DRX, как задано в 3GPP TS 25.214, «Physical Layer Procedure» v. 11.0.0 (Dec. 2012; доступном по адресу www.3gpp.org). Чтобы обеспечить, что UE принимает команду HS-SCCH, узел B может передавать команду HS-SCCH во множественных TTI, например нескольких последовательных TTI, пока не примет HARQ-ACK, соответствующий команде. Альтернативно узел B может ждать следующего доступного TTI, в течение которого UE будет прослушивать нисходящую линию связи, если оно сконфигурировано с CPC, прежде чем передавать команду HS-SCCH.

Теперь более подробно опишем этот первый подход к разрешению потенциального рассогласования в статусе активации CPC. При установлении линий радиосвязи для высокоскоростного пакетного доступа на множественных несущих (HSPA) (например, вторичных линий радиосвязи), или добавлении линий радиосвязи, или при переконфигурировании линий радиосвязи и использовании CPC SRNC будет указывать в одном или более сообщениях прикладной части узла B (NBAP) и/или сообщениях прикладной части подсистемы радиосети (RNSAP), имеет ли UE однородное поведение в отношении команд HS-SCCH, связанных с DTX/DRX. UE можно рассматривать как неоднородное, когда версией выпуска UE является выпуск 7 или выпуск 8, и если IE «информация хронирования DTX_DRX» в сообщении переконфигурирования RRC не задано равным «Продолжать», в отсутствие изменений обслуживающей соты. Обслуживающий узел B, подключенный к SRNC или в DRNS, будет использовать эту информацию для отправки команды HS-SCCH для активации или деактивации CPC для решения рассогласования ситуации.

В ходе мягкого хэндовера, когда линии радиосвязи добавляются на новом узле B, в то время как обслуживающие соты остаются неизменными и когда CPC сконфигурирован для UE и для узлов B, принадлежащих активному набору, SRNC будет использовать кадровый протокол плоскости пользователя (протокол UP; см. 3GPP TS 25.435, v. 10.2.0, и 3GPP TS 25.427, v. 10.1.0, доступные по адресу www.3gpp.org) для указания обслуживающему узлу B, имеет ли UE однородное поведение в отношении команд HS-SCCH, связанных с DTX/DRX. Обслуживающий узел B будет использовать эту информацию для принятия решения, нужно ли отправлять команды HS-SCCH для разрешения потенциальной неопределенности в отношении статуса активации CPC между UE и узлом B.

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

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

Существует несколько сообщений, отправляемых с узла B/DRNS для информирования SRNC об обновлениях, в которых с этой целью можно добавить дополнительный параметр. С этой целью можно использовать, например, сообщение «обновления параметра RL» в спецификациях интерфейсов Iub и Iur.

Ниже представлена примерная процедура, которая представляет одно такое решение «короткого пакета», применительно к интерфейсу Iub. Фиг. 1 иллюстрирует эту процедуру. Работая на интерфейсе Iur, узел B будет отправлять обновление параметра RL NBAP на DRNC, и затем DRNC будет отправлять обновление параметра RL RNSAP на SRNC (этап 5).

1. RNC отправляет сообщение обновления активного набора RRC на UE для завершения процедуры мягкого хэндовера. Это показано как сообщение 110 на фиг. 1.

2. В ответ UE отправляет сообщение «обновление активного набора RRC (RRC ASU) завершено». (Сообщение 120 на фиг. 1.)

3. RNC на основании следующей информации решает, включать ли индикатор «Восстановление CPC» в последующие кадры Iub, отправляемые на узел B:

a. CPC сконфигурирован в активном наборе,

b. UE имеет версию выпуска 7 или 8,

c. Новая информация хронирования DTX-DRX передается UE в сообщении обновления активного набора RRC.

RNC продолжает включать индикатор «Восстановление CPC» в кадры Iub плоскости пользователя, пока узел B не отправит индикацию обновления параметра RL NBAP с указанием, что он инициировал механизм восстановления CPC. На фиг. 1 индикаторы восстановления CPC отправляются с использованием резервного бита в кадрах HS-DSCH. (Сообщения 130 на фиг. 1.)

4. Если узел B принимал кадры без «восстановления CPC», но теперь принимает кадры с «восстановлением CPC», то узел B инициирует процедуру восстановления CPC. Узел B отправляет на нужное UE команду HS-SCCH для активации или деактивации CPC (восстановления CPC) на UE, на основании последнего известного статуса активации CPC. (Сообщение 140 на фиг. 1.)

5. Узел B отправляет индикацию обновления параметра RL NBAP на RNC для указания инициирования механизма восстановления CPC. (Сообщение 150 на фиг. 1.)

6. RNC, приняв индикацию обновления параметра RL NBAP, перестает включать индикатор «Восстановление CPC» в последующие кадры Iub. (Сообщения 160 на фиг. 1.)

Следует понимать, что этап 3, подробно описанный выше, также может выполняться до этапа 2, то есть RNC может начинать отправку кадров Iub с индикатором «Восстановление CPC» до поступления от UE сообщения ASU RRC.

В ряде случаев узел B примет еще несколько кадров, включающих в себя индикатор «Восстановление CPC», после отправки на RNC сообщения индикация обновления параметра RL NBAP. Дело в том, что RNC отправляет короткий пакет кадров Iub с индикатором «восстановление CPC» «Включено», и узел B действует на первом принятом кадре. В одном подходе к работе с этими дополнительными индикациями узел B выполнен с возможностью игнорировать индикатор «Восстановление CPC» в принятых кадрах в течение предварительно определенного периода времени «T» после инициирования процедуры восстановления CPC. При этом в ряде случаев T можно устанавливать согласно стандарту или в других случаях в соответствии с реализацией. Этот период T также может конфигурироваться посредством сигнализации RRC. В этих системах, если узел B продолжает принимать кадры с индикатором «Восстановление CPC» «Включено» по истечении периода «T», то узел B может снова инициировать процедуру восстановления CPC. Другой путь решения этого вопроса множественных кадров предусматривает простой механизм, где узел B может инициировать процедуру восстановления CPC согласно шаблону «выключено-включено-выключено» для индикатора «восстановление CPC» в принятых кадрах Iub. Другими словами, если узел B сначала принимает последовательность кадров с «восстановлением CPC», но затем начинает принимать кадры без «восстановления CPC», узел B должен затем инициировать процедуру восстановления CPC.

Согласно варианту вышеописанного подхода вместо использования индикатора NBAP и RNSAP в случае немягкого хэндовера и использования кадрового протокола плоскости пользователя в случае мягкого хэндовера, кадровый протокол плоскости пользователя SRNC может использовать в обеих ситуациях для указания обслуживающему узлу B, ожидается ли однородное поведение UE в отношении команд HS-SCCH, связанных с DTX/DRX.

Также вместо использования сообщений NBAP и RNSAP для обслуживающего узла B для квитирования RNC можно использовать кадровый протокол Iub. Например, можно использовать резервный бит в кадре управления «выделение емкости» Iub.

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

Во-первых, в главе 9.2.2.103 3GPP TS 25.423, v. 11.0.0 (доступной по адресу www.3gpp.org) задан информационный элемент расширения индикатора поддержки UE в протоколе сигнализации RNSAP, который используется для указания DRNS уровня поддержки необязательных функций HSDPA на UE. Согласно этому современному определению этот информационный элемент (IE) включает в себя несколько резервных битов. Бит 4, например, можно использовать для указания, является ли поведение UE однородным или нет, в отношении команд DTX-DRX HS-SCCH.

Во вторых, в главе 9.2.2.117 3GPP TS 25.433, v. 11.0.0 (доступной по адресу www.3gpp.org) задан информационный элемент расширения индикатора поддержки UE в протоколе сигнализации NBAP, который используется для указания узлу B уровня поддержки необязательных функций HSDPA на UE. Опять же, резервный бит 4, например, можно использовать для указания, является ли поведение UE однородным или нет, в отношении команд DTX-DRX HS-SCCH.

В главе 6.2.6A 3GPP TS 25.435, v. 10.4.0 («UP Protocol», доступной по адресу www.3gpp.org) заданы кадры HS-DSCH плоскости пользователя, отправленные по интерфейсу Iub. Фиг. 2 иллюстрирует структуру кадра HS-DSCH типа 1. В этом кадре 0-й резервный бит в заголовке можно использовать для указания обслуживающему узлу B, является ли поведение UE однородным или нет, в отношении команд DTX-DRX HS-SCCH. Заметим, что в протоколах плоскости пользователя существует соответствующая структура для интерфейса Iur UTRAN, которую можно найти в 3GPP TS 25.425, v. 10.2.0.

Аналогично в кадре HS-DSCH типе 2, 3-й резервный бит в заголовке можно использовать для указания обслуживающему узлу B, является ли поведение UE однородным или нет, в отношении команд DTX-DRX HS-SCCH. Заголовок кадра типа 2 изображен на фиг. 3.

В главе 9.1.58.1 3GPP TS 25.423 задана индикация обновления параметра линии радиосвязи в протоколе сигнализации RNSAP. В сообщение можно добавлять дополнительный параметр для указания (де)активации HS-SCCH, связанной с CPC. Аналогично в главе 9.1.89.1 3GPP TS 25.433 задана индикация обновления параметра линии радиосвязи для протокола сигнализации NBAP. Опять же, можно добавлять дополнительный параметр для указания (де)активации HS-SCCH, связанной с CPC.

Решение 2: использование кадра управления «запрос емкости»

Еще один подход к решению проблемы рассогласования CPC предполагает использование резервных битов в кадре управления «запрос емкости HS-DSCH» для предупреждения узла B о возможности рассогласования CPC. Это резервные биты, которые RNC может использовать, чтобы предписывать обслуживающему узлу B инициировать процедуру восстановления CPC.

Фиг. 4 иллюстрирует кадр управления Iub «запрос емкости HS-DSCH», который задан в главе 6.3.3.10 3GPP TS 25.435 (протокол UP). Один из резервных битов, например бит 4, RNC может использовать для указания узлу B о наличии ситуации потенциального рассогласования CPC.

Когда обслуживающий узел B принимает кадр управления «запрос емкости» Iub с индикатором «Восстановление CPC» (например, резервный бит 4) «Включено», он, таким образом, получает информацию о том, что это не сообщение управления обменом данными от RNC, и не будет возвращать на RNC кадр «выделение емкости». Вместо этого он будет инициировать механизм восстановления CPC.

Решение 3: использование «запроса емкости» и ответа

В другом, непосредственно связанном подходе можно также организовать процедуру запроса/ответа между RNC и узлом B в отношении инициирования процедуры восстановления CPC с использованием кадров управления Iub «запрос емкости» и «выделение емкости». Опять же, существуют резервные биты, которые можно использовать с этой целью.

Как описано выше, RNC включает индикатор в кадр управления Iub «запрос емкости HS-DSCH» для инициирования процедуры восстановления CPC. Кроме того, обслуживающий узел B может отправлять в ответ кадр управления Iub «выделение емкости» с использованием одного из резервных битов, например резервного бита 6, для указания RNC, что он инициировал процедуру восстановления CPC.

Существующая информация кадра, задокументированная в главе 6.3.3.11 3GPP TS 25.435, v. 10.2.0, показана на фиг. 5 и 6. Существует два типа кадров управления «выделение емкости HS-DSCH» для выделения емкости HS-DSCH, то есть кадр управления «выделение емкости HS-DSCH» 1 типа и кадр управления «выделение емкости HS-DSCH» 2 типа. Они проиллюстрированы на фиг. 5 и 6 соответственно. Любой из них можно использовать в целях, описанных в этом разделе, поскольку каждый включают в себя резервные биты.

Фиг. 7 иллюстрирует примерную процедуру для обработки рассогласования CPC в ходе мягкого хэндовера согласно этому подходу. Эта процедура подробно описана ниже:

1. RNC отправляет сообщение обновления активного набора RRC для завершения процедуры мягкого хэндовера. (Сообщение 710 на фиг. 7)

2. В ответ UE отправляет сообщение «обновление активного набора RRC завершено». (Сообщение 720)

3. RNC на основании следующей информации решает, включать ли индикатор «Восстановление CPC» (например, резервный бит 4) в кадр управления Iub «запрос емкости», направляемый на обслуживающий узел B:

a. CPC сконфигурирован в активном наборе,

b. UE имеет версию выпуска 7 или 8,

c. Новая информация хронирования DTX-DRX передается UE в сообщении обновления активного набора RRC.

Если эти условия выполняются, отправляется кадр управления Iub «запрос емкости». (Сообщение 730)

4. Обслуживающий узел B отправляет команду HS-SCCH для активации или деактивации CPC (восстановления CPC) на UE. Команда HS-SCCH основана на последнем известном статусе активации CPC. (Сообщение 740)

5. Обслуживающий узел B отправляет кадр управления Iub «выделение емкости» с индикатором «восстановление CPC активировано» (например, резервным битом 6) на RNC для указания инициирования механизма восстановления CPC. (Сообщение 750)

Следует понимать, что этап 3, подробно описанный выше, также может выполняться до этапа 2, то есть RNC может начинать отправку кадра управления Iub «запрос емкости» с индикатором «Восстановление CPC» «Включено» до поступления от UE сообщения ASU RRC. Также, хотя это не показано на фиг. 7, RNC может продолжать отправлять кадры управления Iub «запрос емкости», которые включают в себя битовый индикатор «восстановление CPC», пока не получит квитирование от обслуживающего узла B. Это квитирование может принимать форму кадра управления «выделение емкости», который включает в себя, например, битовый индикатор «восстановление CPC активировано».

Решение 4: обнаружение обслуживающего узла B

Согласно еще одному подходу обслуживающий узел B самостоятельно и непрерывно пытается оценивать, активировало ли CPC сконфигурированное UE, когда узел B предполагает, что статус CPC на UE является «деактивированный». В отношении DRX узел B может делать это путем вычисления шаблона приема HS-SCCH, который описывает TTI HS-SCCH, которые UE будет отслеживать в режиме DRX. (см. подпункт 6C.3 в 3GPP TS 25.214, Physical Layer Procedures, доступный по адресу www.3gpp.org.) Поскольку UE, обнаружив HS-SCCH, будет повторять передачу HARQ-ACK на HS-DPCCH, узел B может определять, активирован ли CPC для UE, отслеживая, передает ли UE на HS-DPCCH в подкадрах восходящей линии связи, которые соответствуют TTI нисходящей линии связи, которые он не отслеживал бы, если бы CPC не был активирован. В порядке дополнительного примера узел B может проверять, находится ли UE в CPC, путем передачи HS-SCCH в кадре, который не соответствует шаблону приема HS-SCCH. Поскольку UE всегда отправляет ACK/NACK для обнаруженных HS-SCCH, узел B, который принимает ACK или NACK в передачах HS-SCCH, может заключить, что UE не активировало CPC. Передача проверочного сигнала либо может повторяться периодически, либо может инициироваться каким-либо внутренним событием узла B. Приведем два примера таких событий:

- Полная BLER на HS-PDSCH превышает целевую BLER, используемую в сети; и

- BLER для пакетов, передаваемых в TTI, которые не принадлежат шаблону приема HS-SCCH, превышает BLER пакетов, передаваемых в TTI, принадлежащих шаблону приема HS-SCCH.

Эти события могут быть связаны с таймерами, а также гистерезисом.

Дополнительно узел B также может оценивать передачи UE по восходящей линии связи для определения статуса активации CPC на UE. Это особенно полезно, если на UE запланировано мало или вовсе не запланировано данных. Поскольку UE, сконфигурированное с DTX (CPC), которое не имеет никаких данных для передачи, только передает свой DPCCH согласно шаблону пакета, то есть только в поднаборе доступных подкадров, и поскольку шаблон пакета DPCCH известен узлу B, узел B может измерять энергию принятого сигнала на DPCCH в подкадрах (слотах), где DPCCH определенно присутствует, и отдельно измерять энергию сигнала в подкадрах (слотах), где DPCCH не должен присутствовать согласно шаблону пакета DPCCH, если CPC был активирован для UE). Сравнивая уровни принятой энергии (например, путем усреднения) этих измерений, узел B может оценивать вероятность того, что UE активировало CPC. Одно сравнение заключается в вычислении разности средней энергии принятого слота для двух типов (как описано выше). Если разность принятой энергии превышает порог (возможно, в течение предварительно определенного времени), узел B может использовать этот факт для определения, что UE активировало CPC.

Согласно любому из вышеперечисленных подходов вышеописанную проблему можно решить, внося очень незначительные изменения в стандарт. Одно преимущество первого вышеописанного решения состоит в том, что большой процент случаев рассогласования CPC происходит в сценариях, где мягкий хэндовер не предусмотрен. В этих сценариях проблему рассогласования просто решить через плоскость управления Iub/Iur, например, путем модификации существующих сообщений NBAP и RNSAP. В качестве преимуществ второго решения можно указать, что уровень 2 на RNC может инициировать механизм восстановления CPC, без необходимости привлечения уровня 3. Кроме того, нет необходимости повторять кадры плоскости пользователя, и решение в целом упрощается. Преимущество третьего решения состоит в том, что с помощью квитирования от узла B система может удостовериться в том, что связь между SRNC и узлом B будет работать. Наконец, преимущество четвертого решения состоит в том, что воздействие оказывается только на узел B.

Как следует из вышесказанного, варианты осуществления различных вышеописанных методов включают в себя способы, реализованные на RNC или на узле B или на обоих. Эти способы включают в себя различные вышеописанные методы сигнализации, которые включают в себя в ряде случаев модификацию ранее известных сообщений сигнализации и/или заголовков кадров плоскости пользователя для включения новых индикаторов/параметров. Эти новые индикаторы/параметры используются для сигнализации, например, того, что данное UE предположительно имеет неоднородное поведение в отношении запоминания статуса активации CPC после действия по сообщению переконфигурирования RRC, поскольку оно является мобильной станцией выпуска 7 или выпуска 8. Эти новые индикаторы/параметры также могут использоваться узлом B в некоторых вариантах осуществления для квитирования получения от RNC индикации того, что для данного UE следует ожидать неоднор