Повторный выбор соты и передача обслуживания с помощью услуги мультимедийного широковещания/мультивещания

Повторный выбор соты и передача обслуживания с помощью услуги мультимедийного широковещания/мультивещания

Иллюстрации

Показать все

Реферат

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

Данная заявка имеет отношение к беспроводной связи.

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

Одной из главных проблем, когда модуль беспроводной передачи/приема (WTRU) принимает услуги мультимедийного широковещания/мультивещания (MBMS), является поддержание непрерывности услуги и минимизация задержки во время передачи обслуживания и повторного выбора соты. Кроме того, непрерывность услуги должна поддерживаться, и задержка должна минимизироваться, когда WTRU перемещается из зоны обслуживания сети мультимедийного широковещания на одной частоте (MBSFN) в зону обслуживания не-MBSFN, но в рамках той же зоны обслуживания MBMS.

Возникли разные этапы, которые нужно продумывать, когда WTRU в режиме ожидания, принимающий передачу с MBMS в зоне обслуживания MBSFN, приближается к границе зоны обслуживания MBSFN. Этапы включают в себя: 1) обнаружить, что WTRU приближается к границе зоны обслуживания MBSFN; 2) перейти в активный режим и 3) запросить прием услуги MBMS в режиме одной соты с двухточечным соединением (PTP). Усовершенствованный Узел Б (eNodeB) целевой соты также вынужден проверять, доступна ли запрошенная услуга, и если нет, то 4) присоединиться к дереву многоадресного распространения для услуги MBMS; и 5) в конечном счете, начать предоставлять данные MBMS для WTRU в режиме одной соты.

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

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

Раскрываются способ и устройство для предоставления услуг беспроводной связи (например, MBMS). WTRU обнаруживает множество eNodeB в целевой соте, которые граничат с eNodeB обслуживающей соты. WTRU оценивает критерии повторного выбора соты и определяет соседний eNodeB целевой соты для повторного выбора. WTRU принимает и считывает главный информационный блок (MIB) и системные информационные сообщения соседнего eNodeB целевой соты и подтверждает, что определенный соседний eNodeB целевой соты не является частью MBSFN. WTRU указывает для eNodeB обслуживающей соты определенный соседний eNodeB целевой соты. WTRU затем еще раз принимает и считывает сообщения MIB соседнего eNodeB целевой соты, чтобы определить, изменилась ли системная информация, и если это так, то WTRU считывает системную информацию и повторно выбирает соседний eNodeB целевой соты. WTRU затем отправляет соседнему eNodeB целевой соты сообщение обновления соты с информацией о возможностях и требованиями к услуге, который в свою очередь отправляет к WTRU сообщение с подтверждением обновления соты, указывающее, что eNodeB целевой соты готов начать предоставление услуг беспроводной связи.

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

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

Фиг. 1А - схема прохождения сигнала, которая показывает повторный выбор соты от соты MBSFN на соту не-MBSFN, в котором WTRU принимает информацию о соседних сотах от eNodeB обслуживающей соты;

Фиг. 1В - схема сигнала, аналогичная фиг. 1А, за исключением того, что к WTRU отправляется указание посредством широковещательного или любого другого сообщения, указывающее, что eNodeB целевой соты готов запустить услугу MBMS;

Фиг. 2А - схема прохождения сигнала, которая показывает повторный выбор соты от соты MBSFN на соту не-MBSFN, в котором WTRU не принимает информацию о соседних сотах от eNodeB обслуживающей соты;

Фиг. 2В - схема сигнала, аналогичная фиг. 2А, за исключением того, что к WTRU отправляется указание посредством широковещательного или любого другого сообщения, указывающее, что eNodeB целевой соты готов запустить услугу MBMS;

Фиг. 3А - типовая схема сигнала, показывающая WTRU, перемещающийся из соты не-MBSFN в соту не-MBSFN, где список соседних узлов для сот MBMS передается обслуживающей сотой;

Фиг. 3В - типовая схема сигнала, показывающая WTRU, перемещающийся из соты не-MBSFN в соту не-MBSFN, где список соседних узлов для сот MBMS не передается обслуживающей сотой;

Фиг. 4 - блок-схема WTRU и

Фиг. 5 - блок-схема eNodeB.

ПОДРОБНОЕ ОПИСАНИЕ

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

В текущей рабочей группе (WG) по сетям радиодоступа - 2 (RAN2) идет много споров относительно того, мог ли список соседних сот быть нужен для повторного выбора соты. Хотя список соседних сот не считается обязательным для повторного выбора соты, все еще есть неопределенность в том, имеется ли необходимость указывать конкретные внутричастотные соседние соты, чтобы повысить производительность их обнаружения. Этот принцип способности сигнализировать конкретные внутричастотные соседние соты используется для улучшения характеристики непрерывности услуги MBMS. Также имеются случаи и сценарии, в которых список соседних узлов не передается обслуживающей сотой.

Данная заявка охватит два сценария, для случаев повторного выбора соты и передачи обслуживания с происходящими услугами MBMS. Для обоих сценариев предполагается, что WTRU прикрепляется к соте в области MBSFN до того, как начинается процедура повторного выбора.

Повторный выбор соты

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

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

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

WTRU, который находится на границе такой соты MBSFN, таким образом, имел бы список соседних сот и информацию о возможностях для каждой из тех сот.

В таком сценарии, когда он выполняет процедуру повторного выбора соты, он сначала бы придал значение тем сотам на границе, которые являются частью области MBSFN. Если он не обнаруживает ни одной такой соты, то он отдаст преимущество тем сотам, которые являются частью защитной области MBSFN. В конечном счете он попытался бы и повторно выбрал соту из области не-MBSFN на основе процедур повторного выбора соты, например раскрытых в принадлежащей тому же правообладателю Предварительной заявке США 60/894588, зарегистрированной 13 марта 2007 г., которая включается путем отсылки, как если бы она полностью изложена. WTRU, зная свои собственные требования к услуге, не выбрал бы повторно те соты (если они есть), которые не являются ни частью области MBSFN, ни частью зоны обслуживания MBMS. Если сеть захотела бы управлять процедурой повторного выбора (например, она может не захотеть, чтобы WTRU не выбирал повторно никакую конкретную соту из-за загрузки соты или других причин), она может указывать очень высокое смещение для той (конкретной) соты или включать в "черный список" соседних сот или вероятно даже белый список только некоторых соседей.

Передача обслуживания

В первом сценарии передачи обслуживания обычная передача обслуживания происходит там, где WTRU находится в активном состоянии и выполняет обычную, управляемую WTRU передачу обслуживания к eNodeB целевой соты. Если WTRU желает передать обслуживание к соте в области не-MBSFN, то возможности и требования WTRU могли бы передаваться в сообщении с запросом передачи обслуживания от eNodeB обслуживающей соты к eNodeB целевой соты, у которого затем было бы время для присоединения к дереву многоадресного распространения и подготовке к услуге PTP MBMS. Если eNodeB целевой соты не находится в таком положении, он мог бы отклонить запрос передачи обслуживания, и WTRU имел бы возможность передать обслуживание другому eNodeB целевой соты.

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

Как упоминалось ранее, WTRU исходно мог бы находиться в нерабочем состоянии, но затем связаться с eNodeB целевой соты и перейти в активное состояние путем установления соединения управления радиоресурсами (RRC) с eNodeB обслуживающей соты, когда он обнаруживает, что он находится в граничной соте области MBSFN, в соответствии с одним из первого и второго сценариев передачи обслуживания (например, eNodeB целевой соты или считывание SIB), или посредством явного индикатора, который транслируется и указывает, что eNodeB обслуживающей соты находится на границе области MBSFN. Сообщения установления соединения RRC могут быть усовершенствованы, чтобы указывать, что WTRU в настоящее время принимает трафик MBMS.

Как только WTRU переходит в активное состояние или для WTRU уже в активном состоянии, WTRU может отправить отчеты об измерениях в сеть, указывающие качество сигнала, которое он наблюдает. Как только eNodeB обслуживающей соты ставится в известность о наличии (или измерения) WTRU, eNodeB обслуживающей соты следит за измерениями от WTRU и принимает решение, приказать/переназначить ли WTRU на другую соту, где он может получать услуги PTP MBMS.

Если eNodeB обслуживающей соты решает приказать/переназначить WTRU на другую соту (то есть eNodeB целевой соты), где он может получать услуги PTP MBMS, то eNodeB обслуживающей соты связывается с eNodeB целевой соты, отправляя ему подходящие параметры для подготовки к услуге PTP MBMS. Целевой eNodeB готовит услугу PTP MBMS для WTRU и отправляет подтверждающий это сигнал обратно к eNodeB обслуживающей соты. eNodeB обслуживающей соты затем приказывает/переназначает WTRU на доступ к целевому eNodeB. WTRU обращается к целевому eNodeB, к которому ему приказано обратиться, и принимает услугу PTP MBMS.

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

Далее описаны способы, при помощи которых понятие ТА может использоваться для содействия непрерывности услуги MBMS. Отметим, что эти способы могут использоваться либо в сочетании, либо независимо от способов для обеспечения непрерывности услуги MBMS, которые ранее описывались в этом документе.

Исполнение и использование Областей слежения для содействия непрерывности услуги MBMS

Области слежения (TA) проектируются так, что сота MBSFN, которая находится на границе области MBSFN (то есть граничная сота), будет принадлежать TA, которая отличается от областей слежения для неграничных сот (то есть внутренних сот) области MBSFN.

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

Сообщение обновления TA может включать в себя указание того, принимает ли WTRU услуги MBMS, тип услуги MBMS, которую он принимает (PTP или MBSFN), и/или любые другие конфигурационные параметры или контекстную информацию, имеющие отношение к услуге MBMS.

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

Когда WTRU находится внутри граничной соты, одна альтернатива для отправки сообщения TAU - включить только важную информацию, например WTRU, находящийся в настоящее время в граничной соте, или, может быть, мобильность или направление траектории (обслуживающий eNodeB может знать, выходит ли все еще WTRU из области MBSFN или может задерживаться внутри области MBSFN). Этой информации достаточно для eNodeB обслуживающей соты, чтобы знать заранее, нужно ли запускать подготовку к передаче обслуживания. Соответственно, служебная нагрузка сигнализации восходящей линии связи может быть минимизирована.

Отчет об измерениях может отправляться вместе с обновлением TA или в любое время после того, как WTRU входит в соту. Этот отчет об измерениях был бы отчетом, который отправляется после выполнения передачи обслуживания и используется граничной сотой для будущих передач обслуживания. При приеме обновления TA (с необязательным указанием или контекстной информацией об услугах MBMS, используемых WTRU) eNodeB выполнит переключение с услуг MBMS на услуги PTP MBMS. Например, если eNodeB находится в защитной области MBSFN, eNodeB сначала установит услуги PTP MBMS путем пейджинга WTRU, который, в свою очередь, будет запрашивать соединение RRC, и процедура настройки продолжается с этого момента. Если eNodeB находится в граничной области MBSFN, то eNodeB запросит подготовку ресурсов MBMS у подходящего eNodeB целевой соты (например, на основе отчетов об измерениях WTRU и других критериев допущения), а затем прикажет/переназначит WTRU к eNodeB целевой соты, аналогично тому, что ранее описано для других сценариев/случаев этого документа.

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

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

Фиг. 1А - схема прохождения сигнала, которая показывает сценарий повторного выбора соты в системе 100 беспроводной связи, включающей в себя WTRU 105, eNodeB 110 обслуживающей соты (области MBSFN), eNodeB 115 целевой (то есть соседней) соты (области не-MBSFN) и AGW 120. WTRU 105 перемещается от eNodeB 110 обслуживающей соты в области MBSFN к eNodeB 115 целевой соты в области не-MBSFN.

В сценарии повторного выбора соты из фиг. 1А информация о соседних сотах (например, список соседних сот) и информация о возможностях для сот MBMS в области MBSFN передается посредством AGW 120 к eNodeB 110 обслуживающей соты (этап 125). В качестве альтернативы eNodeB 110 обслуживающей соты может быть предварительно сконфигурирован с помощью информации о соседних сотах (например, списка соседних сот) и информации о возможностях для сот MBMS в области MBSFN, например посредством периодического сообщения. eNodeB 110 обслуживающей соты затем передает информацию о соседних сотах к WTRU 105 (этап 130). На этапе 135 WTRU 105 оценивает критерии повторного выбора соты и определяет соседнюю целевую соту для повторного выбора. Перед тем, как он начинает процедуру повторного выбора, WTRU 105 сначала отправляет преамбулу канала с произвольным доступом (RACH) или сообщение RACH к текущему eNodeB 110 обслуживающей соты, к которому он прикрепился (этап 140), указывающее соседнюю соту, которую он планирует для повторного выбора (то есть eNodeB 115 целевой соты). Также, если возможно, специальные подписи могут быть зарезервированы для этой цели, чтобы минимизировать время перерыва при повторном выборе соты. На этапе 145 eNodeB 110 обслуживающей соты отправляет сигнал eNodeB 115 целевой соты, включающий в себя ID WTRU 105 (например, международный идентификатор абонента мобильной связи (IMSI), временный идентификатор мобильного абонента (TMSI)) и указывающий, что WTRU 105 необходима услуга PTP MBMS.

По-прежнему ссылаясь на фиг. 1А, на этапе 150 eNodeB 115 целевой соты определяет, есть ли у него доступная необходимая услуга PTP MBMS. Если это не так, то eNodeB 115 целевой соты отправляет сигнал к AGW 120, запрашивающий, чтобы AGW 120 присоединил eNodeB 115 целевой соты к дереву многоадресного распространения для предоставления необходимой услуги (этап 155), при помощи чего AGW 120 предоставляет eNodeB 115 целевой соты информацию MBMS, который, в свою очередь, предоставляется WTRU 105 информацию MBMS. После того как AGW 120 присоединяет eNodeB 115 целевой соты к дереву многоадресного распространения (этап 160), AGW 120 может сигнализировать явное положительное подтверждение приема (АСК) к eNodeB 115 целевой соты (этап 165), либо это может предполагаться неявно без сигнализации. Если eNodeB 115 целевой соты не соединен с деревом многоадресного распространения, то WTRU 105 был бы информирован надлежащим образом.

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

В качестве альтернативы WTRU 105 может всего лишь отправить сообщение к текущему eNodeB 110 обслуживающей соты, в котором он закрепился, указывающее eNodeB 115 целевой соты, который он планирует выбрать повторно, как упоминалось раньше. eNodeB 110 обслуживающей соты мог бы получить информацию о eNodeB 115 целевой соты из сети, и соответственно зная возможности обслуживания у eNodeB 115 целевой соты, eNodeB 110 обслуживающей соты может определить, допускает ли eNodeB 115 целевой соты предоставление услуги, и если нет, eNodeB 110 обслуживающей соты может перенаправить ID WTRU вместе с необходимыми услугами к eNodeB 115 целевой соты. После отправки сигнала к eNodeB 110 обслуживающей соты WTRU 105 начинает процедуру повторного выбора соты в области не-MBSFN.

Каждая сота в зоне обслуживания MBMS периодически передает MIB и системные информационные сообщения. MIB и системные информационные сообщения включают в себя информацию, указывающую, является ли сота частью области MBSFN или поддерживает ли сота только услугу PTP. Таким образом, когда WTRU 105 считывает MIB и системные информационные сообщения, которые передаются посредством eNodeB 115 целевой соты (этап 170), WTRU 105 может подтвердить, что новая сота, которую он планирует выбрать повторно, не является частью области MBSFN (этап 175). В качестве альтернативы только сота в области PTP MBMS или в области MBSFN может передавать информацию относительно того, является ли сота частью области MBSFN. Как только WTRU 105 закончил считывание MIB и системных информационных сообщений (этап 170), WTRU 105 повторно выбирает eNodeB 115 целевой соты (этап 180) и отправляет сообщение обновления соты к eNodeB 115 целевой соты, указывающее его TMSI или некоторый другой ID, собственные возможности и требования для услуги PTP MBMS (этап 185).

eNodeB 115 целевой соты, будучи предварительно информированным о требованиях WTRU 105, должен допускать поддержку услуги PTP MBMS и подтверждение этой поддержки путем передачи WTRU 105 сообщения с подтверждением обновления соты. Если eNodeB 115 целевой соты не может присоединиться к дереву многоадресного распространения, то он может указать это WTRU 115 в сообщении с подтверждением обновления соты (этап 190). Таким образом, у WTRU 105 был бы выбор - повторно выбрать другую соту, которая обладает возможностью, используя предыдущую информацию, либо вообще инициировать другую новую процедуру повторного выбора, но это может привнести дополнительные задержки. В качестве альтернативы предлагается, что eNodeB 115 целевой соты может переназначить WTRU 105 на eNodeB другой соты, который допускает предоставление услуги PTP MBMS. eNodeB 115 целевой соты может использовать последнюю информацию отчета об измерениях WTRU (если доступна), чтобы выбрать eNodeB, на который был бы переназначен WTRU 105, например WTRU 105 отправлял бы отчет об измерениях, когда он отправил сообщение обновления соты, или в любое другое время.

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

Фиг. 1В - схема сигнала, аналогичная фиг. 1А, за исключением того, что к WTRU отправляется указание посредством широковещательного или любого другого сообщения, указывающее, что eNodeB целевой соты готов запустить услугу MBMS (этап 195).

Фиг. 2А - схема прохождения сигнала, которая показывает сценарий повторного выбора соты в системе 200 беспроводной связи, включающей в себя WTRU 205, eNodeB 210 обслуживающей соты (области MBSFN), eNodeB 215 целевой (то есть соседней) соты (области не-MBSFN) и AGW 220. WTRU 205 перемещается от eNodeB 210 обслуживающей соты в области MBSFN к eNodeB 215 целевой соты в области не-MBSFN, но в отличие от сценария повторного выбора соты из фиг. 2А, информация о соседних сотах и информация о возможностях для сот MBMS не передается обслуживающей сотой к WTRU.

Когда не передается информация о соседних сотах (например, список идентификаторов (ID) соседних сот), eNodeB 210 обслуживающей соты в области MBSFN может обладать или не обладать информацией о соседних сотах и информацией о возможностях. Сначала предполагается, что у eNodeB 210 обслуживающей соты нет никакой информации о соседних сотах (этап 225). В этом сценарии WTRU 205 не знал бы, является ли сота, которую он планирует повторно выбрать, частью области MBSFN, и поэтому WTRU 205 потребуется обнаружить возможные соседние eNodeB целевой соты, оценить критерии повторного выбора соты и определить eNodeB 215 целевой соты для повторного выбора (этап 230). На основе определения WTRU 205 потребуется приступить к считыванию MIB и системных информационных сообщений (этап 235).

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

Все же предлагается, что все соты в зоне обслуживания MBMS должны передавать информацию относительно того, является ли это частью области MBSFN, защитной области MBSFN или поддерживает ли сота только услугу PTP, в системных информационных сообщениях. Таким образом, когда WTRU 205 считывает системные информационные сообщения, которые передаются посредством eNodeB 215 целевой соты, WTRU 205 подтверждает, что новая сота (то есть eNodeB 215 целевой соты), которая планируется для повторного выбора, не является частью области MBSFN (этап 240). В качестве альтернативы только сота в области PTP MBMS или в области MBSFN может передавать информацию, указывающую, является ли сота частью области MBSFN.

На этапе 245 WTRU 205 сначала отправляет преамбулу канала с произвольным доступом (RACH) или сообщение RACH к текущему eNodeB 110 обслуживающей соты, к которому он прикрепился (этап 245), указывающее соседнюю соту, которую он планирует для повторного выбора (то есть eNodeB 115 целевой соты). Также, если возможно, специальные подписи могут быть зарезервированы для этой цели, чтобы минимизировать время перерыва при повторном выборе соты. На этапе 250 eNodeB 210 обслуживающей соты отправляет сигнал eNodeB 215 целевой соты, включающий в себя ID WTRU 205 (например, международный идентификатор абонента мобильной связи (IMSI), временный идентификатор мобильного абонента (TMSI)) и указывающий, что WTRU 205 необходима услуга PTP MBMS.

По-прежнему ссылаясь на фиг. 2А, на этапе 255 eNodeB 215 целевой соты определяет, есть ли у него необходимая услуга PTP MBMS. Если нет, то eNodeB 215 целевой соты отправляет сигнал к AGW 220, запрашивающий, чтобы AGW 220 присоединил eNodeB 215 целевой соты к дереву многоадресного распространения для предоставления услуги (этап 260). После того как AGW 220 присоединяет eNodeB 215 целевой соты к дереву многоадресного распространения (этап 265), AGW 220 может сигнализировать явное положительное подтверждение приема (АСК) к eNodeB 215 целевой соты (этап 270) либо это может предполагаться неявно без сигнализации. Если eNodeB 215 целевой соты не соединен с деревом многоадресного распространения, то WTRU 205 был бы информирован надлежащим образом.

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

В качестве альтернативы WTRU 205 может всего лишь отправить сообщение к текущему eNodeB 210 обслуживающей соты, в котором он закрепился, указывающее eNodeB 215 целевой соты, который он планирует выбрать повторно, как упоминалось раньше. eNodeB 210 обслуживающей соты мог бы получить информацию о eNodeB 215 целевой соты из сети, и соответственно зная возможности обслуживания у eNodeB 215 целевой соты, eNodeB 110 обслуживающей соты может определить, допускает ли eNodeB 215 целевой соты предоставление услуги, и если нет, eNodeB 210 обслуживающей соты может перенаправить ID WTRU вместе с необходимыми услугами к eNodeB 215 целевой соты. После отправки сигнала к eNodeB 210 обслуживающей соты WTRU 205 начинает процедуру повторного выбора соты в области не-MBSFN.

На этапе 275 WTRU 205 затем еще раз считывает сообщения MIB, чтобы подтвердить, что системная информация не изменилась с последнего считывания (этап 275). Это может быть необходимым, поскольку в результате отправки сообщения к eNodeB 210 обслуживающей соты (этапы 245 и 250) после считывания системных информационных сообщений, принятых от eNodeB 215 целевой соты, имеется небольшая пауза, внесенная между считыванием MIB и системных информационных сообщений и отправкой сообщения обновления соты. Однако поскольку очень вероятно, что системные информационные сообщения не изменились с последнего считывания, небольшая внесенная задержка не должна быть проблемой. Поэтому WTRU 205 не должен столкнуться с большой задержкой в повторном выборе. Если есть какие-либо изменения в системной информации, то WTRU считывает системные информационные сообщения и повторно выбирает eNodeB целевой соты (этап 280).

Как только WTRU 205 закончил считывание системных информационных сообщений, WTRU 205 может отправить сообщение обновления соты к eNodeB 215 целевой соты, указывающее его TMSI или некоторый другой ID, собственные возможности и требования для услуги PTP MBMS (этап 285).

eNodeB 215 целевой соты, будучи предварительно информированным о требованиях WTRU 205, должен допускать поддержку услуги PTP MBMS и подтверждение этой поддержки путем передачи WTRU 205 сообщения с подтверждением обновления соты (этап 290). Если eNodeB 215 целевой соты не может присоединиться к дереву многоадресного распространения, eNodeB 215 целевой соты может запросить пакеты у eNodeB 210 обслуживающей соты, и eNodeB 210 обслуживающей соты мог бы перенаправить пакеты MBMS к eNodeB 215 целевой соты. eNodeB 215 целевой соты мог бы тогда перенаправлять их к WTRU 205, пока он не присоединится к дереву многоадресного распространения.

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

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

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

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

Вся процедура даже могла бы быть быстрее или лучше управляться, чем во втором сценарии, поскольку этот список ID соседних сот может действовать как белый список, упоминающий только соты, к которым WTRU 205 разрешено прикрепляться, посредством этого предоставляя eNodeB 210 обслуживающей соты больше контроля над процедурой повторного выбора, и eNodeB 210 обслуживающей соты мог бы оказывать некоторое влияние на процедуры повторного выбора. Например, предпочтение может отдаваться некоторым соседним сотам или переназначению на некоторые соты посредством характерных для сот параметров повторного выбора, например описанных в Предварительной заявке США 60/894588, поскольку есть сведения о возможностях соседних сот.

eNodeB 210 обслуживающей соты обладает информацией о возможностях и списком ID соседних сот, но не передает информацию, чтобы сэкономить ресурсы. В этом сценарии, если информация о возможностях и список ID соседних сот MBMS известны, но не передаются посредством eNodeB 210 обслуживающей соты, то WTRU 205 может потребоваться обнаружить eNodeB 215 целевой соты и считать системную информацию, чтобы понять, предоставляет ли eNodeB 215 целевой соты необходимую услугу. Процедура тогда может быть аналогична той, которая упоминалась ранее во втором сценарии.

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

Фиг. 2В - схема сигнала, аналогичная фиг. 2А, за исключением того, что к WTRU отправляется указание посредством широковещательного или любого другого сообщения, указывающее, что eNodeB целевой соты готов запустить услугу MBMS (этап 295).

Фиг. 3А показывает систему 300 беспроводной связи, включающую в себя WTRU 305, eNodeB 310 обслуживающей соты (области не-MBSFN), eNodeB 315 целевой (то есть соседней) соты (область не-MBSFN) и AGW 320. WTRU 305 перемещается из одной соты области не-MBSFN в другую соту области не-MBSFN, где информация о соседних сотах и информация о возможностях передается обслуживающей сотой не-MBSFN.

Фиг. 3В - схема сигнала, аналогичная фиг. 3А за исключением того, что информация о соседних сотах и информация о возможностях для сот MBMS не передается обслуживающей сотой к WTRU.

Фиг. 4 - блок-схема WTRU 400, сконфигурированного для выполнения любой из операций, выполняемых WTRU 105, 205 и 305. WTRU 400 включает в себя антенну 405, приемник 410, процессор 415 и передатчик 420.

Приемник 410 конфигурируется для приема информации соты, ассоциированной с eNodeB целевой соты, которые граничат с eNodeB обслуживающей соты. Процессор 415 конфигурируется для оценки критериев повторного выбора соты и определения соседнего eNodeB целевой соты для повторного выбора. Передатчик 420 конфигурируется для передачи преамбулы RACH или сообщения RACH, указывающих соседний eNodeB целевой соты. Приемник 410 дополнительно конфигурируется для приема и считывания MIB и системных информационных сообщений. Процессор 415 дополнительно конфигурируется для подтверждения, что определенный соседний eNodeB целевой соты не является частью MBSFN.

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

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

Фиг. 5 - блок-схема eNodeB 500, сконфигурированного для выполнения любой из операций, выполняемых eNodeB 110, 115, 210, 215, 310 и 315. eNodeB 500 включает в себя антенну 505, приемник 510, процессор 515 и передатчик 520. eNodeB 500 может быть eNodeB обслуживающей соты или eNodeB целевой сот