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

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

Иллюстрации

Показать все

Реферат

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

Настоящая заявка относится к беспроводной связи.

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

Высокоскоростной пакетный доступ по нисходящей линии связи (HSDPA) является характеристикой, которая была внедрена в 5 Выпуске спецификации проекта партнерства третьего поколения (3GPP). HSDPA достигает максимальной спектральной эффективности с использованием трех ключевых концепций: адаптивные модуляция и кодирование (АМС), быстрые повторные передачи физического уровня, осуществляющие гибридный автоматический запрос на повторную передачу данных (HARQ) и быстрое планирование работы Узла В.

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

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

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

Традиционно, сообщение передачи обслуживания управления радиоресурсами (RRC) отправляется в WTRU через исходную соту. Задержка, ассоциированная с изменением обслуживающей соты HS-DSCH, может привести к ошибке сообщения передачи обслуживания, таким образом приводя к неприменимой частоте сброшенных вызовов.

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

WTRU продолжительно измеряет силу сигнала соседних сот. На основании измерений на соседних сотах WTRU передает сообщение MEASUREMENT REPORT (отчет измерения) 1A или 1C, содержащее результаты внутричастотных измерений, запрашивающие добавление новой соты в активный набор. Как часть процедуры обновления активного набора SRNC устанавливает новую радиолинию в целевом Узле В для выделенных физических каналов. SRNC затем передает сообщение ACTIVE SET UPDATE (обновить активный набор) в WTRU. Сообщение ACTIVE SET UPDATE включает в себя необходимую информацию для установления выделенных физических каналов в добавленную радиолинию. Если SRNC решает заранее конфигурировать целевую соту, сообщение ACTIVE SET UPDATE будет также включать в себя конфигурацию, относящуюся к обслуживающей соте HS-DSCH (например, конфигурацию H-RNTI, HS-SCCH и т.д.) для целевой соты. Когда WTRU добавил новую радиолинию, WTRU возвращает сообщение ACTIVE SET UPDATE COMPLETE (завершить обновление активного набора).

Когда WTRU обнаруживает изменение лучшей соты, WTRU передает сообщение MEASUREMENT REPORT 1D для запроса изменения HS-DSCH обслуживающей соты на целевую соту. Отчет содержит измеренное значение и идентификацию (ID) соты. WTRU затем начинает отслеживать один из предварительно сконфигурированных HS-SCCH в целевой соте в добавление к HS-SCCH в исходной соте.

По приему этого события обслуживающий RNC (SRNC) принимает решение выполнить передачу обслуживания к новой соте. SRNC запрашивает управляющий RNC (CRNC), чтобы назначить HS-DSCH ресурсы (такие как временная HS-DSCH радиосетевая идентификация (H-RNTI), HS-SCCH коды, HARQ ресурсы и т.д.) для WTRU в целевой соте, через сообщения части приложения радиосетевой подсистемы (RNSAP) и части приложения Узла В (NBAP). Когда ресурсы HS-DSCH резервируются, CRNC обеспечивает всю информацию для SRNC, который в свою очередь отправляет сообщение передачи обслуживания RRC в WTRU по исходной соте.

SRNC может отправить сообщение RADIO BEARER SETUP (установка радиоканала-носителя), сообщение RADIO BEARER RECONFIGURATION (реконфигурирование радиоканала-носителя), сообщение TRANSPORT CHANNEL RECONFIGURATION (реконфигурирование транспортного канала) или сообщение PHYSICAL CHANNEL RECONFIGURATION (реконфигурирование физического канала), которые указывают целевую соту HS-DSCH и опционально время активации в WTRU. Сообщение RRC может также включать в себя параметры, связанные с конфигурацией транспортного канала, для целевой соты HS-DSCH, включая индикацию для сброса элемента MAC-hs или MAC-ehs.

Параллельно, целевой Узел B может передать HS-SCCH директиву в целевой соте, чтобы инициировать изменение обслуживающей соты HS-DSCH. Эта HS-SCCH директива может упоминаться как директива изменения обслуживающей соты HS-DSCH или как директива целевой соты HS-SCCH. Если WTRU не принял сообщение RRC (то есть, сообщение RADIO BEARER SETUP, сообщение RADIO BEARER RECONFIGURATION, сообщение TRANSPORT CHANNEL RECONFIGURATION или сообщение PHYSICAL CHANNEL RECONFIGURATION), WTRU после приема HS-SCCH директивы в целевой соте выполнит изменение обслуживающей соты HS-DSCH.

Когда WTRU завершает изменение обслуживающей соты HS-DSCH, WTRU возвращает сообщение RADIO BEARER SETUP COMPLETE (завершить установку радиоканала-носителя), сообщение RADIO BEARER RECONFIGURATION COMPLETE (завершить реконфигурирование радиоканала-носителя), сообщение TRANSPORT CHANNEL RECONFIGURATION COMPLETE (завершить реконфигурирование транспортного канала) или сообщение PHYSICAL CHANNEL RECONFIGURATION COMPLETE (завершить реконфигурирование физического канала) в сеть, независимо от того, было ли запущено изменение соты приемом сообщения RRC в исходной соте или приемом HS-SCCH директивы в целевой соте.

Когда используется улучшенная процедура изменения обслуживающей соты, сеть будет сконфигурирована с возможностью отправки сообщения RRC WTRU по исходной соте или HS-SCCH директивы по целевой соте, если сконфигурировано. Однако сообщение RRC может не быть успешно доставлено из-за ухудшения радиоусловий в исходной ячейке. Кроме того, имеет место проблема, когда WTRU принимает сообщение RRC и HS-SCCH директиву целевой соты, и они конфликтуют друг с другом. Например, когда HS-SCCH директива целевой соты принята, элемент RRC в WTRU, как предполагается, выполняет изменение обслуживающей соты HS-DSCH в пределах требуемого периода времени (то есть, 40 мс). Однако сообщение RRC может содержать номер кадра соединения (CFN) в качестве времени активации, которое возникает намного позже, чем предел в 40 мс. Дополнительно, сообщение RRC может содержать новые параметры конфигурации, которые могут конфликтовать с предварительно сконфигурированными параметрами HS-DSCH. Это может вызвать неоднозначность в WTRU. На сетевой стороне это может вызвать проблемы, так как в то время, когда сеть полагает, что WTRU готов и перенаправил данные к целевой соте, сеть может не знать, какую конфигурацию использует WTRU и в какое время выполняется повторная конфигурация (то есть, спустя 40 мс после директивы целевой соты HS-SCCH или во время активации, заданном в сообщении RRC). Это обусловлено тем, что WTRU мог не принять сообщение RRC и мог быть реконфигурирован с использованием старых предварительно сконфигурированных параметров. Кроме того, в случае, если оба сообщения приняты, поведение WTRU относительно того, как и какое сообщение обработать в элементе RRC, должно быть определено.

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

Раскрыты способ и устройство для изменения обслуживающей соты HS-DSCH. WTRU принимает предварительно конфигурированную информацию обслуживающей соты или параметры для целевой соты из сети. WTRU сообщает отчет об измерении и начинает отслеживание HS-SCCH из целевой соты. WTRU может принимать HS-SCCH директиву по целевой соте и/или сообщение реконфигурирования RRC по исходной соте, указывающей смену обслуживающей HS-DSCH соты на целевую соту. WTRU может действовать в соответствии со всеми принятыми информационными элементами сообщения реконфигурирования RRC, если сообщение реконфигурирования RRC принимается до HS-SCCH директивы, и действовать в соответствии с предварительно конфигурированной информацией обслуживающей соты, если HS-SCCH директива принимается до сообщения реконфигурирования RRC. WTRU может прекратить отслеживать HS-SCCH на целевой соте при условии, что сообщение реконфигурирования RRC принимается до приема HS-SCCH директивы. WTRU может игнорировать сообщение реконфигурирования RRC, принятое после приема HS-SCCH директивы.

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

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

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

Фиг.2 является блок-схемой WTRU и Узла В системы беспроводной связи по Фиг.1;

Фиг.3 является схемой последовательности операций примерного процесса обработки сообщения RRC в соответствии с одним вариантом осуществления, в котором WTRU игнорирует сообщение RRC после приема HS-SCCH директивы целевой соты; и

Фиг.4 является схемой последовательности операций примерного процесса обработки сообщения RRC в соответствии с одним вариантом осуществления, в котором WTRU игнорирует HS-SCCH директиву целевой соты после приема сообщения RRC.

Осуществление изобретения

При упоминании здесь термин "WTRU" включает в себя, но не ограничивается пользовательским оборудованием (UE), мобильной станцией, фиксированным или мобильным абонентским модулем, пейджером, мобильным телефоном, персональным цифровым секретарем (PDA), компьютером или каким-либо другим типом пользовательского устройства, способного к работе в беспроводной среде. При упоминании здесь термин "Узел B" включает в себя, но не ограничивается базовой станцией, контроллером станции, точкой доступа (AP) или каким-либо другим типом взаимодействующего через интерфейс устройства, способного к работе в беспроводной среде.

В дальнейшем термин "предварительно сконфигурированная информация обслуживающей соты" относится к параметрам обслуживающей соты или информационным элементам, которые обеспечиваются для WTRU как часть активной процедуры обновления набора, включая, но не ограничиваясь параметрами HS-DSCH, (такими как код HS-SCCH, информация HARQ, H-RNTI и т.д.) и дополнительно параметрами улучшенного выделенного канала (E-DCH) (такими как Е-DCH абсолютный канал разрешения (Е-AGCH), E-DCH радиосетевые временные идентификационные данные (Е-RNTI) и относительный канал разрешения обслуживающей соты Е-DCH (Е-RGCH), E-DCH HARQ канал индикатора (Е-HICH) и т.д.). Предварительно сконфигурированная информация о обслуживающей соте позволит WTRU выполнять быстрое изменение обслуживающей соты к целевой соте, как только HS-SCCH директива на передачу обслуживания принимается по целевой соте. Термины "параметр" и "информация" или "информационный элемент" могут использоваться взаимозаменяемо. Здесь и далее термины "HS-SCCH директива", "директива изменения обслуживающей соты HS-DSCH" и "директива HS-SCCH целевой соты" могут использоваться взаимозаменяемо.

Фиг. 1 иллюстрирует систему 100 беспроводной связи, включающую в себя множество WTRU 110, Узел B 120, управляющий контроллер радиосети (CRNC) 130, обслуживающий контроллер радиосети (SRNC) 140 и базовую сеть 150. Узел B 120 и CRNC 130 могут все вместе упоминаться как универсальная сеть наземного радиодоступа (UTRAN).

Как показано на Фиг. 1, WTRU 110 находятся в соединении с Узлом B 120, который находится в соединении с CRNC 130 и SRNC 140. Хотя на фиг. 1 показаны три WTRU 110, один Узел B 120, один CRNC 130 и один SRNC 140, нужно отметить, что любая комбинация беспроводных и проводных устройств может содержаться в системе 100 беспроводной связи.

Фиг. 2 является функциональной блок-схемой WTRU 110 и Узла B 120 системы 100 беспроводной связи по Фиг. 1. Как показано на Фиг. 2, WTRU 110 находится в соединении с Узлом B 120, и оба являются сконфигурированными с возможностью осуществления способа выполнения изменения обслуживающей соты HS-DSCH.

В дополнение к компонентам, которые могут быть найдены в типичном WTRU, WTRU 110 включает в себя процессор 115, приемник 116, передатчик 117, запоминающее устройство 118 и антенну 119. Запоминающее устройство 118 обеспечивается для хранения программного обеспечения, включающего в себя операционную систему, приложение и т.д. Процессор 115 обеспечивается для выполнения, самостоятельно или в соединении с программным обеспечением, способа изменения обслуживающей соты HS-DSCH в соответствии с вариантами осуществления, раскрытыми ниже. Приемник 116 и передатчик 117 находятся в соединении с процессором 115. Антенна 119 находится в соединении с приемником 116 и с передатчиком 117, чтобы способствовать передаче и приему беспроводных данных.

В дополнение к компонентам, которые могут быть найдены в типичной базовой станции, Узел B 120 включает в себя процессор 125, приемник 126, передатчик 127, запоминающее устройство 128 и антенну 129. Процессор 125 является сконфигурированным с возможностью поддержки способа изменения обслуживающей соты HS-DSCH в соответствии с вариантами осуществления, раскрытыми ниже. Приемник 126 и передатчик 127 находятся в соединении с процессором 125. Антенна 129 находится в соединении с приемником 126 и с передатчиком 127, чтобы способствовать передаче и приему беспроводных данных.

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

Сообщение реконфигурирования RRC может содержать набор информации об обслуживающей соте (такой как HS-DSCH и Е-DCH параметры) и дополнительно время активации для изменения обслуживающей соты HS-DSCH, которое отличается от "сейчас". Информация об обслуживающей соте, включенная в сообщение реконфигурирования RRC, может быть той же, что и предварительно конфигурированная информация об обслуживающей соте, или может включать в себя новую информацию, отличающуюся от предварительно конфигурированной информации об обслуживающей соте. Новая информация об обслуживающей соте может включать в себя информационный элемент радиоканала-носителя, параметры транспортного канала или параметры физического канала.

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

Альтернативно, даже если WTRU принял сообщение реконфигурирования RRC со временем активации (отличающимся от "сейчас"), как только WTRU принимает HS-SCCH директиву, WTRU может инициировать реконфигурирование к целевой соте, даже если время активации еще не было достигнуто. Если новые параметры включаются в сообщении реконфигурирования RRC, WTRU может применить эти параметры перед временем активации, если принята HS-SCCH директива.

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

Альтернативно, WTRU может только действовать по HS-SCCH директиве целевой соты и игнорировать последующее сообщение реконфигурирования RRC. WTRU может реконфигурироваться согласно предварительно сконфигурированной информации об обслуживающей соте и может игнорировать любые новые параметры или информацию, предоставленную в сообщении реконфигурирования RRC.

Альтернативно, WTRU может действовать по HS-SCCH директиве целевой соты, реконфигурироваться согласно предварительно сконфигурированной информации об обслуживающей соте (даже если сообщение реконфигурирования RRC содержит конфликтные параметры или информацию) и действовать на любых новых параметрах или информации в сообщении реконфигурирования RRC, которые не являются частью предварительно сконфигурированной информации об обслуживающей соте для целевой соты.

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

Приоритет сообщения может быть определен так, чтобы WTRU мог обработать сообщение реконфигурирования RRC и HS-SCCH директиву целевой соты в соответствии с приоритетом.

В соответствии с одним вариантом осуществления, WTRU может быть сконфигурирован с возможностью обработки сообщения реконфигурирования RRC и HS-SCCH директивы целевой соты в порядке приема. Более конкретно, если процедура изменения обслуживающей соты HS-DSCH инициировалась одним из сообщений реконфигурирования RRC и HS-SCCH директивы целевой соты, WTRU может проигнорировать принятое последним сообщение (то есть HS-SCCH директиву целевой соты или сообщение реконфигурирования RRC) и продолжить выполнение текущего процесса. Например, если WTRU принимает HS-SCCH директиву целевой соты сначала, WTRU может проигнорировать и отклонить принятое затем сообщение реконфигурирования RRC или наоборот.

Альтернативно, сообщение реконфигурирования RRC может переопределить предварительно сконфигурированную конфигурацию обслуживающей соты. Более определенно, WTRU может быть сконфигурирован, чтобы всегда отдавать приоритет сообщению реконфигурирования RRC, несмотря на то что HS-SCCH директива целевой соты могла инициировать процедуру изменения обслуживающей соты HS-DSCH. Если во время приема сообщения реконфигурирования RRC WTRU продолжает процедуру изменения обслуживающей соты HS-DSCH, запущенную приемом HS-SCCH директивы по целевой соте, продолжающаяся процедура изменения обслуживающей соты HS-DSCH может быть остановлена, и могут выполняться действия, связанные с сообщением реконфигурирования RRC. Если первым принято сообщение реконфигурирования RRC, WTRU может проигнорировать принятую затем HS-SCCH директиву целевой соты и действовать только согласно сообщению реконфигурирования RRC.

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

Обычно, информационный элемент (IE) "идентификатор транзакции" в сообщении RRC может использоваться вместе с IE "тип сообщения" сообщения RRC, для идентификации вызова процедуры нисходящей линии связи. WTRU получает идентификатор транзакции RRC с первым сообщением RRC нисходящей линией связи, (например, реконфигурированием радиоканала-носителя). WTRU или принимает или отклоняет транзакцию, основанную на IE "тип сообщения" и "идентификатор транзакции RRC" принятого сообщения RRC. IE "идентификатор транзакции RRC" добавляется в сообщение RRC, и если последующее сообщение RRC имеет тот же самый идентификатор транзакции RRC, оно отклоняется. В случае сообщения реконфигурирования сообщение RRC отклоняется даже с отличающимся идентификатором транзакции RRC, если сообщение RRC имеет тот же самый тип сообщения. Как только процедура RRC выполнена, WTRU отправляет идентификатор транзакции RRC исходного сообщения в сообщении завершения RRC.

В настоящий момент IE "тип сообщения" и "идентификатор транзакции RRC" в переменной TRANSACTION (транзакция) сохраняются, только если принимается сообщение RRC нисходящей линии связи. В соответствии с одним вариантом осуществления, WTRU сохраняет "тип сообщения" и "идентификатор транзакции RRC" в переменной TRANSACTION после приема HS-SCCH директивы по целевой соте. "Тип сообщения" может быть установлен в одно из следующего: (1) новый тип сообщения, например, "HS-SCCH директива", (2) существующий тип сообщения реконфигурирования RRC (такой как "реконфигурирование физического канала" или "реконфигурирование транспортного канала") или (3) ACTIVE SET UPDATE (обновление активного набора). Так как стандартная HS-SCCH директива не может содержать значение "идентификатор транзакции RRC", WTRU RRC элемент должен установить "идентификатор транзакции RRC" неявно как часть процедуры приема HS-SCCH директивы целевой соты. Например, "идентификатор транзакции RRC" может быть установлен в произвольное значение (например, ноль) или другое значение, которое не будет использоваться сетью и резервироваться для HS-SCCH директивы целевой соты.

Если WTRU принимает HS-SCCH директиву целевой соты до приема сообщения реконфигурирования RRC и WTRU обнаруживает, что транзакция, указанная "идентификатором транзакции RRC" и "типом сообщения" принятого сообщения реконфигурирования RRC, имеет место ввиду ранее принятой HS-SCCH директивы целевой соты, WTRU игнорирует сообщение реконфигурирования RRC и продолжает текущий процесс реконфигурирования. Иначе, WTRU принимает транзакцию.

Если сообщение реконфигурирования RRC принимается до приема HS-SCCH директивы целевой соты и WTRU обнаруживает, что транзакция, запрашиваемая HS-SCCH директивой целевой соты, имеет место (то есть, ORDERED_RECONFIGURATION (предписываемое реконфигурирование) устанавливается в TRUE (истинно)) и дополнительно "тип сообщения" в переменных TRANSACTIONS устанавливается как тип для реконфигурирования RRC, WTRU игнорирует транзакцию, запрашиваемую HS-SCCH директивой целевой соты и продолжает текущие процессы, как если бы HS-SCCH директива целевой соты не была принята. В противном случае транзакция, запрашиваемая HS-SCCH директивой целевой соты, принимается, и WTRU устанавливает "тип сообщения" и "идентификатор транзакции RRC" применимыми для HS-SCCH директивы целевой соты в переменных TRANSACTIONS. Дополнительно, после приема и принятия транзакции, запрашиваемой HS-SCCH директивой целевой соты, WTRU устанавливает переменную ORDERED_RECONFIGURATION в TRUE.

Как только процедура реконфигурирования завершена, WTRU подготавливает RRC сообщение завершения. Если транзакция соответствовала HS-SCCH директиве целевой соты, WTRU добавляет свой идентификатор транзакции RRC, который используется только для HS-SCCH директивы, или, альтернативно, дополнительный IE к RRC сообщению завершения. Альтернативно, новое сообщение RRC (например, сообщение завершения изменения обслуживающей соты HS-SCCH (SCC)), может быть определено и использоваться, когда изменение обслуживающей соты HS-DSCH произошло из-за HS-SCCH директивы целевой соты.

Примерные процедуры для принятия или игнорирования транзакций, которые обрабатывают изменение обслуживающей соты HS-DSCH, описываются ниже.

Фиг. 3 является блок-схемой примерного процесса обработки сообщения RRC в соответствии с одним вариантом осуществления, в котором WTRU игнорирует сообщение RRC после приема HS-SCCH директивы целевой соты. WTRU принимает сообщение RRC от сети (этап 302). Если IE "идентификатор транзакции RRC" включен в принятом сообщении RRC, WTRU определяет, является ли принятое сообщение RRC одним из RADIO BEARER SETUP сообщения, RADIO BEARER RECONFIGURATION сообщения, RADIO BEARER RELEASE сообщения, TRANSPORT CHANNEL RECONFIGURATION сообщения или PHYSICAL CHANNEL RECONFIGURATION сообщения (этап 304). Если так, WTRU определяет, удовлетворяются ли следующие условия на этапе 306:

(1) переменная ORDERED_RECONFIGURATION установлена в FALSE (ложно);

(2) переменная CELL_UPDATE_STARTED (начато обновление соты) установлена в FALSE;

(3) сообщение реконфигурирования RRC не содержит ошибку протокола и переменная PROTOCOL_ERROR_REJECT (отклонить ошибку протокола) установлена в FALSE;

(4) таблица «принятые транзакции» в переменной TRANSACTIONS не содержит записи c IE «тип сообщения», установленным в ACTIVE SET UPDATE;

(5) таблица «принятые транзакции» в переменной TRANSACTION не содержит записи с «типом сообщения», установленным в HS-SCCH директиве (если определен новый тип сообщения «HS-SCCH директива»); и

(6) таблица «принятые транзакции» в переменной TRANSACTION не содержит записи с «идентификатором транзакции RRC», установленным на зарезервированный ID транзакции, используемый для HS-SCCH директив (если новый идентификатор транзакции RRC определен, чтобы отличить транзакцию HS-SCCH директивы).

Если все условия (1)-(6) удовлетворяются, WTRU принимает транзакцию и сохраняет IE "тип сообщения" и "идентификатор транзакции RRC" принятого сообщения RRC в таблице "принятые транзакции" в переменных TRANSACTIONS (этап 308). Если какое-либо из условий (1)-(6) не удовлетворяется, WTRU, например, может проигнорировать транзакцию и продолжать текущие процессы и процедуры, как если бы сообщение RRC не было принято (этап 310).

Фиг. 4 является примерной блок-схемой процесса обработки сообщения RRC в соответствии с одним вариантом осуществления, в котором WTRU игнорирует HS-SCCH директиву целевой соты после приема сообщения RRC. WTRU принимает HS-SCCH по целевой соте (этап 402). WTRU анализирует переменные "TRANSACTIONS", чтобы установить, имеет ли место выполнение реконфигурирования. При приеме HS-SCCH директивы целевой соты WTRU определяет, удовлетворяются ли все следующие условия (1)-(6) на этапе 404:

(1) переменная ORDERED_RECONFIGURATION установлена в FALSE;

(2) переменная CELL_UPDATE_STARTED установлена в FALSE;

(3) принятое сообщение не содержит ошибку протокола и переменная PROTOCOL_ERROR_REJECT установлена в FALSE;

(4) таблица «принятые транзакции» в переменных TRANSACTIONS не содержит записи с IE «тип сообщения», установленным в ACTIVE SET UPDATE;

(5) таблица «принятые транзакции» в переменной TRANSACTION не содержит записи с «типом сообщения», установленным в HS-SCCH директиве (если определяется новый тип сообщения «HS-SCCH директива»); и

(6) таблица «принятые транзакции» в переменной TRANSACTION не содержит записи с «идентификатором транзакции RRC», установленным на зарезервированный ID транзакции, используемый для HS-SCCH директив целевой соты (если определен новый идентификатор транзакции RRC, чтобы отличить транзакцию HS-SCCH директивы).

Если все условия (1)-(6) удовлетворяются, WTRU принимает транзакции и сохраняет IE "тип сообщения" и "идентификатор транзакции", используемые для HS-SCCH директивы в переменных TRANSACTIONS (этап 406). Если какое-либо из условий (1)-(6) не удовлетворяется, WTRU игнорирует транзакцию и продолжает выполнять текущие процессы и процедуры, как если бы HS-SCCH директива целевой соты не была принята (этап 408).

Если время активации не предусмотрено в сообщении реконфигурирования RRC, то сеть предположит, что реконфигурирование к целевой соте будет готово в пределах, например, 40 мс передачи одной или более директив HS-SCCH целевой соты. В это же время сеть может начать передачу по целевой соте, но если сообщение реконфигурирования RRC обеспечило набор новых HS-DSCH параметров, сеть не знает в данный момент, действовал ли WTRU согласно сообщению RRC или HS-SCCH директиве целевой соты. Это может привести к использованию сетью неправильной конфигурации и WTRU, возможно, не примет намеченные данные.

Для того чтобы решить эту проблему, может быть применено ограничение так, чтобы не допускался конфликт между предварительно сконфигурированной информацией об обслуживающей соте и информацией об обслуживающей соте, предоставленной в сообщении реконфигурирования RRC. Если конфликтующая информация обнаруживается посредством WTRU, то возникает недопустимая конфигурация. Это потребовало бы, чтобы сетевой объект RRC посылал ту же самую конфигурацию обслуживающей соты, обеспеченную в предварительной конфигурации обновления активного набора. Сеть отправляет сообщение реконфигурирования RRC, но поле, содержащее IE, которые были предварительно сконфигурированы в процедуре обновления активного набора, может быть оставлена пустым. Сообщение реконфигурирования RRC может быть упрощенным сообщением, которое только подтверждает для WTRU, что передача обслуживания была одобрена сетью. Если требуются дополнительные IE (например, другое реконфигурирование радиоканалов-носителей или транспортного канала, которые не являются частью предварительно сконфигурированных ресурсов), сообщение реконфигурирования RRC может включать в себя такие параметры. Если сеть решила выполнить передачу обслуживания к целевой соте, сообщение реконфигурирования RRC может содержать все необходимые IE, чтобы позволить WTRU выполнять передачу обслуживания к целевой соте.

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

Если возникает конфликтное реконфигурирование и для WTRU не разрешается иметь конфликтные реконфигурирования, процедура RRC может быть отклонена с использованием механизм идентификатора транзакции. Более определенно, если существует конфликтная конфигурация, WTRU устанавливает "идентификатор транзакции RRC" в таблице "отклоненные транзакции" в переменных TRANSACTIONS. WTRU затем передает сообщение отказа RRC сети.

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

В соответствии с одним вариантом осуществления, синхронизируемая передача обслуживания может не разрешаться для изменения обслуживающей соты HS-DSCH. Более конкретно, если конфигурация целевой соты была предварительно загружена, после ID инициирующего события WTRU не ожидает время активации, отличающегося от "сейчас". Если время активации, отличающееся от "сейчас", обеспечивается в сообщении реконфигурирования RRC, поведение WTRU является неопределенным, или результатом является недопустимая конфигурация. Альтернативно, если время активации отличается от "сейчас", WTRU может проигнорировать время активации и выполнить передачу обслуживания после приема HS-SCCH директивы целевой соты. Сеть может только выполнить несинхронизированную передачу обслуживания.

Альтернативно, сети разрешается передать время активации, но сеть конфигурирует целевой Узел B, чтобы отправить HS-SCCH директиву целевой соты в заданное время активации или X мс до истечения времени активации, где X определяется на основании времени требования реконфигурирования (то есть, 40 мс) и дополнительно на количестве раз повторения HS-SCCH директивы целевой соты.

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

Варианты осуществления

1. Способ, осуществляемый в WTRU для изменения обслуживающей соты HS-DSCH.

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

3. Способ в соответствии с вариантом осуществления 2, включающий в себя этап, на котором сообщают отчет об измерении.

4. Способ в соответствии с любым из вариантов осуществлений 2-3, включающий в себя этап, на котором отслеживают HS-SCCH на целевой соте.

5. Способ в соответствии с любым из вариантов осуществлений 2-4, включающий в себя этап, на котором принимают одно из HS-SCCH директивы по целевой соте и сообщения реконфигурирования RRC по исходной соте, указывающего смену обслуживающей HS-DSCH соты на целевую соту.

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

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

8. Способ в соответствии с любым из вариантов осуществлений 5-7, в котором WTRU игнорирует сообщение реконфигурирования RRC, принятое после приема HS-SCCH директивы.

9. Способ в соответствии с любым и