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

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

 

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

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

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

В последнее время благодаря развитию технологии связи услуги, предоставляемые системой мобильной связи, развиваются в сторону создания системы мультимедийной широковещательной/ мультивещательной передачи данных для передачи речевых данных и данных мультимедиа с высокой пропускной способностью, таких как пакетные данные и канальные данные. Для поддержки мультимедийной широковещательной/мультивещательной передачи данных была предложена услуга мультимедийного широковещания/мультивещания (далее называемая «MBMS»), где один или несколько источников данных мультимедиа предоставляют услугу множеству UE. Услуга MBMS поддерживает данные мультимедиа, такие как видеоданные и речевые данные в реальном времени, данные неподвижных изображений и текстовые данные. Кроме того, услуга MBMS одновременно предоставляет речевые данные и видеоданные и требует большого объема ресурсов для передачи. Таким образом, услуга MBMS предоставляется по широковещательному каналу благодаря возможности одновременного предоставления множества услуг в пределах одной соты. Кроме того, MBMS может обеспечить услугу передачи по схеме «точка - точка» (далее называется «PtP») для предоставления независимых услуг соответствующим абонентам, а также услугу передачи по схеме «точка - множество точек» (далее называется «PtM») для предоставления одних и тех же данных MBMS множеству абонентов. Система мобильной связи 3GPP (Проект партнерства в области систем связи 3-го поколения), в которой применяется услуга MBMS, описывается со ссылками на фиг.1.

На фиг.1 схематически показана структура системы мобильной связи для предоставления услуги MBMS. Как показано на фиг.1, система мобильной связи для предоставления услуги MBMS включает в себя UE 101, сеть (UTRAN) 102 радиодоступа Универсальной системы мобильных телекоммуникаций (UMTS), обслуживающий узел (SGSN) 103 поддержки общей услуги пакетной радиопередачи данных (GPRS), принадлежащий базовой сети (CN), реестр (HLR) 104 местоположения собственных абонентов, шлюзовый узел (GGSN) 105 поддержки GPRS, центр (BM-SC) 106 услуги широковещания/ мультивещания, пограничный шлюз (BG) 108, источник (MBS) 107 мультивещания/широковещания, поставщик (CP) 109 контента (информационного наполнения) и источник (MBS) 110 мультивещания/широковещания. Устройство пользователя UE 101 непосредственно принимает данные MBMS и включает в себя аппаратное или программное обеспечение, поддерживающее услугу MBMS. UTRAN 102 представляет собой сеть радиосвязи для соединения UE 101 с сетью CN. Структура UTRAN 102 описывается со ссылками на фиг.2.

На фиг.2 схематически представлена структура UTRAN 102, показанная на фиг.1. Обратимся к фиг.2, где UTRAN 102 включает в себя множество контроллеров (RNC) радиосети, множество узлов B, управляемых контроллерами RNC, и множество сот, принадлежащих узлам В. Хотя сеть UTRAN 102 может включать в себя множество RNC, для простоты, как показано на фиг.2, UTRAN 102 включает в себя только один RNC 201. RNC 201 управляет множеством узлов В, то есть, узлом B#1 201, узлом B#2 203, ..., узлом B#n 204. Узел B#1 202 управляет множеством сот, а именно, сотой #1 205, сотой #2 206, ..., сотой #m 207. Общее количество узлов В, управляемых контроллером RNC 201, и общее количество сот, управляемых каждым из узлов В, определяются в соответствии с параметрами системы мобильной связи с MBMS.

UE 101 подсоединено к UTRAN 102 через Uu-интерфейс 121. UTRAN 102 подсоединена к SGSN, принадлежащему сети CN, через Iu-интерфейс 122. В Таблице 1, приведенной ниже, указаны различные роли элементов MBMS, показанных на фиг.1, а в Таблице 2, приведенной ниже, показаны интерфейсы между этими элементами.

Таблица 1
№	Наименование	Роль
101	UE	Принимает услугу MBMS и обеспечивает услугу MBMS для пользователю
102	UTRAN	Доставляет данные MBMS на UE и доставляет запрос на услугу MBMS от UE в CN. Подробности см. на фиг.2.
103	SGSN	Аутентифицирует UE, запрашивающее услугу MBMS, путем приема данных от HLR, и аутентифицирует UE путем приема от HLR данных о праве UE использовать услугу MBMS, запрошенную UE. SGSN настаивает однонаправленный канал радиодоступа (RAB), для услуги MBMS, запрошенной UE. SGSN поддерживает услугу MBMS даже тогда, когда UE перемещается из одной соты в другую. SGSN соединяется с источником MBMS через узел GGSN. SGSN собирает учетные данные для услуги MBMS, используемой оборудованием UE.
104	HLR	Означает реестр местоположения собственных абонентов, который управляет информацией для аутентификации для каждой единицы UE, а также контентом для типа услуги MBMS, доступного каждой единице UE.
105	GGSN	Означает шлюзовый узел услуги GPRS,который непосредственно принимает данные MBMS, предоставляемые для UE, от источника 110 мультивещания/широковещания через центр BM-SC 106 и BG 108 и передает принятые данные MBMS в узел SGSN. GGSN собирает учетные данные для UE, контролирует ситуацию, связанную с перемещением каждого UE, и управляет качеством обслуживания (QoS) для услуги MBMS, предоставляемой устройству UE.
106	BM-SC	Означает центр услуг широковещания/мультивещания, который аутентифицирует поставщика контента, определяет QoS услуги MBMS, исправляет ошибки в данных MBMS, предоставляет учетные
		данные поставщику контента, принимает данные MBMS от поставщика 109 контента и предоставляет принятые данные MBMS узлу GGSN 105. Центр ВМ-SC уведомляет UE о предоставляемой в данный момент услуге MBMS.
107	Источник мультивещания/ широковещания	Непосредственно предоставляет данные MBMS в GGSN.
108	BG	Означает пограничный шлюз, который принимает данные MBMS от источника мультивещания/ широковещания в сети, не управляемой в данный момент поставщиком услуг, и передает принятые данные MBMS в GGSN.
109	Поставщик контента	Предоставляет контент MBMS в BM-SC 106
110	Источник мультивещания/ широковещания	Непосредственно предоставляет данные MBMS в GGSN.
	Таблица 2
№	Наименование	Роль
121	Uu	Интерфейс между UE и UTRAN
122	Iu	Интерфейс между UTRAN и CN
123	Gr	Интерфейс между SGSN и HLR
124	Gn/Gp	Интерфейс между SGSN и GGSN
125	Gi	Интерфейс между GGSN и BM-SC
126	Gi	Интерфейс между GGSN и источником мультивещания/широковещания
127	Gi	Интерфейс между GGSN и BG
128	Gn/Gp	Интерфейс между BM-SC и поставщиком контента
129	Gi	Интерфейс между BG и источником мультивещания/широковещания

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

На фиг.3 схематически показана структура верхнего уровня сети UTRAN 102, показанной на фиг.1. Обратимся к фиг.3, где сообщения верхнего уровня, обработанные в сети UTRAN 102, ориентировочно классифицируются на управляющий сигнал и данные пользователя. На фиг.3 управляющий сигнал представлен как сигнализация плоскости управления (сигнализация С-плоскости) 301, а данные пользователя представлены как информация плоскости пользователя (информация U-плоскости) 302. Сигнализация 301 С-плоскости и информация 302 U-плоскости являются сообщениями слоя, не связанного с предоставлением доступа (NAS), при этом сообщения NAS представляют сообщения, не используемые для радиосоединения между UE 101 и UTRAN 102. Здесь сообщение NAS представляет сообщение, содержимое которого сети UTRAN 102 знать не требуется. В отличие от сообщения NAS сообщение слоя, связанного с предоставлением доступа (AS), является сообщением, непосредственно используемым для радиосоединения между UTRAN 102 и UE 101, причем это сообщение представляет данные или управляющую сигнализацию, используемую уровнем (RRC) 303 управления радиоресурсами и его нижерасположенным уровнем.

Уровень RRC 303 управляет уровнем 1 (L1) 310, который является физическим уровнем, относящимся к соединению между UE 101 и UTRAN 102, уровнем (L2/MAC) 308 управления доступом к среде передачи из состава уровня 2, уровнем (L2/RLC) 306 управления линией радиосвязи из состава уровня 2, уровнем (L2/PDCP) 304 протокола корвенгенции пакетных данных из состава уровня 2 и уровнем (L2/BMC) 305 управления широковещанием/ мультивещанием из состава уровня 2; тем самым уровень RRC обеспечивает управление операциями, относящимися к соединению между UE 101 и UTRAN 102, такими как настройка физического вызова, настройка логического вызова, передача/прием управляющей информации и передача/прием измерительной информации.

Уровень L2/PDCP 304 принимает данные, переданные с уровня NAS, и передает принятые данные передачи на уровень L2/RLC 306, используя соответствующий протокол. Уровень L2/BMC 305 принимает данные, необходимые для широковещания и мультивещания с уровня NAS, и передает принятые данные на уровень L2/RLC 306.

Уровень L2/RLC 306 принимает управляющее сообщение, переданное с уровня RRC 303 на UE 101, обрабатывает принятое управляющее сообщение в соответствующем формате на уровне RLC с первого (RLC#1) 361 по m-й (RLC#m) 362 и передает обработанное управляющее сообщение на уровень L2/MAC 308, используя логический канал 307. Кроме того, уровень L2/RLC 306 принимает данные с уровня L2/PDCP 304 и уровня L2/BMC 305, обрабатывает принятые данные в соответствующем формате на уровне RLC, с первого (RLC#1) 363 по n-й (RLC#n) 364, и передает обработанные данные на уровень L2/MAC 308, используя логический канал 307. Здесь количество уровней RLC, сформированных на уровне L2/RLC 306, определяется количеством радиоканалов между UE 101 и UTRAN 102, а уровни RLC с первого (361) по m-й (362) формируются для управляющей сигнализации, в то время как уровни RLC c первого (363) по n-й (364) формируются для данных пользователя.

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

Таблица 3
Наимено-вание	Роль
BCCH	Означает канал управления широковещанием, который используют для передачи по нисходящей линии связи от UTRAN 102 к UE и для передачи системной управляющей информации, относящейся к UTRAN 102.
PCCH	Означает канал управления поисковыми вызовами, который используют для передачи по нисходящей линии связи от UTRAN 102 к UE и при передаче управляющей информации на UE, когда расположение соты, которой принадлежит данное UE, неизвестно.
CCCH	Означает общий канал управления, который используют для передачи управляющей информации между UE и сетью, а также в тех случаях, когда у UE нет канала, соединенного с RRC.
DCCH	Означает выделенный канал управления, который используют для передачи управляющей информации между UE и сетью по схеме PtP, а также в случаях, когда UE имеет канал, соединенный с RRC.
CTCH	Означает общий канал трафика, который используют для передачи данных между сетью и множеством UE по схеме PtM.
DTCH	Означает выделенный канал трафика, который используют для передачи данных между сетью и одним UE по схеме PtP.

Уровень L2/MAC 308 обеспечивает управление радиоресурсами между UE 101 и UTRAN 102, а также управляет соединением между UE 101 и UTRAN 102 под управлением уровня RRC 303. Кроме того, уровень L2/MAC 308 принимает сигналы по логическому каналу 307 с уровня L2/RLC 306, отображает принятые сигналы в транспортные каналы 309, а затем передает отображенные сигналы на уровень L1 310. В Таблице 4, представленной ниже, показаны типы и роли транспортных каналов, используемых в проекте 3GPP.

Таблица 4
Наиме- нование	Роль
BCH	Означает канал широковещания, который отображается в BCCH для передачи данных по BCCH.
PCH	Означает канал поискового вызова, который отображается в PCCH для передачи данных по PCCH.
RACH	Означает канал произвольного доступа, который используют для передачи от UE в сеть, а также для сетевого соединения и передачи управляющего сообщения и коротких данных. Каналы DCCH, CCCH и DTCH могут быть отображены в RACH.
FACH	Означает прямой канал доступа, который используют для передачи управляющего сообщения и данных из сети на конкретное UE или несколько UE. Каналы BCCH, CTCH, CCCH, DTCH и DCCH могут быть отображены в FACH.
DCH	Означает выделенный канал, который используют для передачи данных и управляющей сигнализации между сетью и одним UE. Каналы DTCH и DCCH отображаются в DCH.
DSCH	Означает совместно используемый канал нисходящей линии связи, то есть это канал нисходящей линии связи от сети к UE, используемый для передачи данных с высокой пропускной способностью. Каналы DTCH и DCCH отображаются в DSCH.
HS-DSCH	Означает высокоскоростной канал DSCH, то есть канал нисходящей линии связи от сети к UE, созданный путем повышения пропускной способности при передаче по каналу DSCH. Каналы DTCH и DCCH отображаются в HS-DSCH.

В дополнение к транспортным каналам, показанным в Таблице 4, имеются совместно используемый канал (USCH) восходящей линии связи и общий пакетный канал (CPCH). Однако, поскольку эти каналы не относятся к настоящему изобретению, их подробное описание для простоты опускается.

Транспортные каналы 309, передаваемые на уровень L1 310, передаются на UE 101 или UTRAN 102 после отображения в действительные физические каналы на уровне L1 310. Физические каналы включают в себя основной общий физический канал (P-CCPCH) управления для передачи канала (BCH) широковещания, дополнительный общий физический канал (S-CCPCH) управления для передачи канала (PCH) поискового вызова и прямого канала (FACH) доступа, выделенный физический канал (DPCH) для передачи выделенного канала (DCH), физический совместно используемый канал (PDSCH) нисходящей линии связи для передачи совместно используемого канала (DSCH) нисходящей линии связи, высокоскоростной совместно используемый физический канал (HS-PDSCH) нисходящей линии связи для передачи высокоскоростного совместно используемого канала (HS-DSCH) нисходящей линии связи и физический канал (PRACH) произвольного доступа для передачи канала (RACH) произвольного доступа. В дополнение к вышеуказанным физическим каналам имеется канал (PCH) пилот-сигнала, который является чисто физическим каналом, не передающим данные верхнего уровня или управляющие сигналы, основной канал (P-SCH) синхронизации, дополнительный канал (S-SCH) синхронизации, канал (PICH) индикатора поискового вызова, канал (AICH) индикатора получения и физический общий пакетный канал (PCPCH).

Далее со ссылками на фигуры 4А, 4В, 5 и 6 описываются некоторые проблемы, которые могут возникнуть при предоставлении услуги MBMS в известной системе мобильной связи, которая не поддерживает услугу MBMS.

На фиг.4А схематически показана конфигурация для предоставления услуги MBMS в системе мобильной связи, к которой подсоединены SGSN 401, обслуживающий контроллер 402 радиосети (SRNC), и множество UE (UE#1 403, UE# 404,..., UE#m 406). Обратимся к фиг.4А, где SGSN 401 выполняет ту же функцию, что и SGSN 103, описанный со ссылкой на фиг.1. Контроллер RNC классифицируется на SRNC и управляющий RNC (CRNC) в соответствии с характером взаимосвязи с UE. Контроллер SRNC - это RNC, имеющий всю информацию о UE, при этом SRNC присваивает UE временный идентификатор обслуживающей радиосети (S-RNTI). Когда UE перемещается в новую соту, а эта новая сота находится под управлением конкретного RNC, но не SRNC, этот контроллер RNC служит в качестве CRNC, причем этот CRNC присваивает UE временный идентификатор сотовой радиосети (C-RNTI) и управляет этим UE. На фиг.4А устройства UE#1 403, UE#2 404,...,UE#m 406 принимают от SRNC 402 данные MBMS, а также принимают от SRNC 402 данные, если таковые имеются, передаваемые по выделенному каналу управления (DCCH) или выделенному каналу трафика (DTCH).

На фиг.4В схематически показана конфигурация для предоставления услуги MBMS в системе мобильной связи, к которой подсоединены SGSN 411, SRNC 412, CRNC 413 и UE 414, 415 и 416. На фиг.4В предполагается, что UE#m 416 переместилось в другую соту после посылки запроса на услугу MBMS в SRNC 412, который является SRNC для UE#m 416, так что с точки зрения UE#m 416 контроллер RNC, который управляет UE#m 416, может быть контролером CRNC 413.

Обратимся к фиг.4В, где SGSN 411 также выполняет ту же функцию, что и SGSN 103, показанный на фиг.1. UE#1 414 и UE#2 415 принимают данные MBMS или данные, переданные по каналу DCCH или DTCH от SRNC 412. Устройство UE#m 416 подсоединено к CRNC 413 и принимает запрошенные данные MBMS от SRNC 412 через CRNC 413. Описывая взаимосвязь между CRNC 413 и UE#m 416, следует сказать, что контроллер CRNC 413 может непосредственно передавать на UE#m 416 такие сигналы, как системная информация, то есть, сигналы, передаваемые по общему каналу трафика (CTCH) или по общему каналу управления (CCCH). Однако CRNC 413 принимает управляющую сигнализацию и информацию пользователя, переданную от SRNC 412 по DCCH и DTCH, за исключением CTCH или CCCH, и передает принятую управляющую сигнализацию и данные пользователя на UE#m 416. Кроме того, интерфейс между CRNC 413 и SRNC 412 является Iur-интерфейсом (интерфейс между контроллерами радиосети), через который нельзя передать никакого сигнала, кроме сигналов, передаваемых по каналу DTCH или DCCH.

Хотя на фиг.4В предполагается, что CRNC 413 управляет только одним UE, то есть UE#m 416, под управлением CRNC 413 и SRNC 412 в реальной ситуации может одновременно находиться множество UE. В этом случае эти UE управляются контроллером CRNC одновременно, а SRNC должен безусловно принимать данные MBMS через Iur-интерфейс, чтобы соответствовать спецификациям стандарта, предложенного в проекте 3GPP. Когда все UE, имеющие одновременно CRNC и SRNC, принимают одни и те же данные MBMS, то есть когда соответствующим UE через Iur-интерфейс предоставляются одни и те же данные MBMS, эти одинаковые данные MBMS передаются многократно, что приводит к расточительному использованию проводных ресурсов. Кроме того, даже если CRNC предоставляет одну и ту же услугу MBMS, контроллер CRNC не может непосредственно передавать данные MBMS на единицы UE, имеющие этот CRNC, так что те же данные MBMS передаются на единицы UE, имеющие данный CRNC, и на единицы UE, имеющие данный SRNC, через радиооборудование, что приводит к расточительному использованию радиоресурсов.

На фиг.5 представлена диаграмма сигнализации, иллюстрирующая процедуру предоставления услуги MBMS в системе мобильной связи, подсоединенной, как показано на фиг.4А. На фиг.5 предполагается, что SRNC 531 не предоставляет в данный момент услугу MBMS, запрошенную устройством UE 541, то есть SRNC 531 посылает в SGSN 521 запрос на запрошенную услугу MBMS в ответ на запрос услуги MBMS от UE 541, и UE 541 принимает от SGSN 521 запрошенную услугу MBMS.

Обратимся к фиг.5, где центр BM-SC 501 передает в узел GGSN 511 (этап 502) данные MBMS, а GGSN 511 передает (этап 512) в SGSN 521 необходимые в SGSN 521 данные, которые выделяют из данных MBMS. Между тем, UE 541 передает в SGSN 521 сообщение об активизации запроса контекста MBMS (Activate MBMS Context Request) (этап 550) для того, чтобы принять услугу MBMS. Здесь «контекст MBMS» представляет набор данных, относящихся к услуге MBMS, которую хочет получить UE 541. После приема сообщения Activate MBMS Context Request узел SGSN 521 передает (этап 522) на SRNC 531 сообщение с уведомлением о MBMS (MBMS Notification), которое является ответным сообщением на сообщение Activate MBMS Context Request. После приема сообщения MBMS Notification контроллер SRNC 531 передает на UE 541 сообщение MBMS Notification (этап 532). Здесь «уведомление о MBMS» указывает, что должна выполняться услуга MBMS, запрошенная данным UE. SGSN 521 имеет контекст MBMS, а содержимое контекста MBMS может стать списком протоколов пакетной передачи данных (протоколов PDP) для множества услуг MBMS, которые могут предоставляться узлом SGSN 521. Список PDP может включать в себя адреса для услуг MBMS, а в качестве PDP могут быть использованы такие протоколы пакетной передачи данных, как X.25 или IP (протокол Интернет). Узел SGSN 521 передает в SRNC 531 сообщение с запросом на настройку канала RAB MBMS (MBMS RAB Setup Request) для запроса настройки однонаправленного канала радиодоступа (RAB) с целью передачи данных MBMS (этап 524). После приема сообщения MBMS RAB Setup Request контроллер SRNC 531 передает в SGSN 521 сообщение о завершении настройки RAB услуги MBMS (MBMS RAB Setup Complete), которое является ответным сообщением на сообщение MBMS RAB Setup Request (этап 525). Узел SGSN 521 передает данные MBMS на SRNC 531 через установленный канал RAB услуги MBMS (этап 526). Контроллер SRNC 531 передает на UE 541 информацию об однонаправленном канале RB для сообщения о настройке данных MBMS (MBMS data Setup) с целью запроса настройки однонаправленного радиоканала (RB), по которому данные MBMS могут быть переданы на UE 541 (этап 533). После приема данных о RB для сообщения MBMS data Setup оборудование UE 541 передает в SRNC 531 информацию о RB для сообщения о завершении настройки данных MBMS (MBMS Data Setup Complete) как ответного сообщения на сообщение MBMS data Setup (этап 544). После приема данных о RB для сообщения MBMS Data Setup Complete контроллер SRNC 531 передает на UE 541 данные MBMS (этап 545). Между тем, если выполняющаяся услуга MBMS приостановлена, то SRNC 531 освобождает канал RAB услуги MBMS, установленный для SGSN 521 с целью предоставления услуги MBMS (освобождение RAB услуги MBMS) (этап 527), и освобождает канал RB услуги MBMS, настроенный для UE 541, чтобы предоставить услугу MBMS (освобождение канала RB данных MBMS) (этап 546).

На фиг.6 представлена диаграмма сигнализации, иллюстрирующая процедуру предоставления услуги MBMS в системе мобильной связи, соединенной, как показано на фиг.4В. На фиг.6 предполагается, что UE 640 одновременно имеет CRNC 630 и SRNC 620, так как UE 640 переместился в новую соту после передачи в SRNC 620 сообщения Activate MBMS Context Request, и UE 640 не обменивается сигналами DCH с SRNC 620. Взаимосвязь между UE 640 и сетью UTRAN ориентировочно разделяется на режим незанятости и режим соединения. Режим соединения подразделяется на состояние URA_PCH, состояние CELL_PCH, состояние CELL_FACH и состояние CELL_DCH в соответствии с типом транспортных каналов, используемых тогда, когда UE 640 обменивается сигналами с сетью UTRAN. В состоянии URA_PCH сеть UTRAN не знает местонахождение UE 640, и UE 640 принимает только сигнал PCH. В состоянии CELL_PCH сеть UTRAN знает, в какой соте находится UE 640, но UE 640 продолжает принимать только сигнал PCH. В состоянии CELL_FACH устройство UE 640 обменивается сигналами с UTRAN по каналам RACH и FACH. В состоянии CELL_DCH устройство UE 640 обменивается сигналами с UTRAN по каналу DCH. При описании фиг.6 предполагается, что UE 640 находится в состоянии CELL_FACH, а SGSN 610 уже принял необходимые данные MBMS от узла GGSN 600.

Обратимся к фиг.6, где UE 640 передает сообщение Activate MBMS Context Request на узел SGSN 610 (этап 651). Кроме того, узел GGSN 600 передает данные MBMS на узел SGSN 610 (этап 653). Помимо этого UE 640, которое переместилось в соту, управляемую контроллером CRNC 630 в состоянии CELL_FACH, передает сообщение об обновлении соты (Cell Update) на SRNC 620 (этап 655). После приема сообщения Cell Update контроллер SRNC 630 передает на UE 640 сообщение о подтверждении обновления соты (Cell Update Confirm) в качестве ответного сообщения на сообщение Cell Update (этап 657).

После приема от UE 640 сообщения Activate MBMS Context Request узел SGSN 610 передает сообщение MBMS Notification в контроллер SRNC 620 (этап 659). SRNC 620 передает сообщение MBMS Notification в CRNC 630, а CRNC 630 предает сообщение MBMS Notification без изменения на UE 640, не зная содержания сообщения MBMS Notification (этап 661). Здесь CRNC 630 предоставляет радиоресурсы для UE 640 и просто ретранслирует сигналы, переданные на SRNC 640 и принятые от SRNC 640.

После передачи сообщения MBMS Notification узел SGSN 610 передает на SRNC 620 сообщение MBMS RAB Setup Request (этап 663). Поскольку UE 640 в данный момент находится в соте, управляемой контроллером CRNC 630, контроллер SRNC 620 передает на CRNC 630 сообщение MBMS RAB Setup Request (этап 665). После приема сообщения MBMS RAB Setup Request контроллер CRNC 630 передает на SRNC 620 сообщение MBMS RAB Setup Complete как ответное сообщение на сообщение MBMS RAB Setup Request (этап 667). После приема от CRNC 630 сообщения MBMS RAB Setup Complete контроллер SRNC 620 передает сообщение MBMS RAB Setup Complete на узел SGSN 610 (этап 669). Кроме того, SRNC 620 передает на UE 640 сообщение о настройке канала RB услуги MBMS (MBMS RB Setup) (этап 671). В качестве ответного сообщения на сообщение MBMS RB Setup оборудование UE 640 передает на SRNC 620 сообщение о завершении настройки канала RB для MBMS (MBMS RB Setup Complete) (этап 673). Узел SGSN 610 предает данные MBMS на SRNC 620 (этап 675), а SRNC 620 передает данные MBMS на CRNC 630 (этап 677). Контроллер CRNC 630 передает данные MBMS на UE 640 (этап 679). Если выполняющаяся услуга MBMS приостановлена, то SRNC освобождает канал RAB услуги MBMS, настроенный для CRNC 630, чтобы предоставить услугу MBMS (освобождение канала RAB услуги MBMS) (этап 681), освобождает канал RB услуги MBMS, настроенный для UE 640, чтобы предоставить услугу MBMS (освобождение канала RB услуги MBMS) (этап 683), и освобождает канал RAB услуги MBMS, настроенный для узла SGSN 610 (освобождение канала RAB услуги MBMS) (этап 685).

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

Во-первых, даже в том случае, когда все UE, принимающие данные MBMS из соты, управляемой контроллером SRNC, изменили свое местоположение, SRNC должен поддерживать Iu-интерфейс и передавать данные, принимаемые через Iu-интерфейс, на CRNC, к которому переместились UE, через Iur-интерфейс, что приводит к расточительному использованию ресурсов Iu-интерфейса между SRNC и SGSN. Кроме того, если в соте, управляемой контроллером CRNC, предоставлялась одна и та же услуга MBMS, то CRNC многократно принимает от узла SGSN данные MBMS через Iu-интерфейс между SRNC и SGSN, даже если он уже принял данные MBMS, предоставляемые единицам UE в его соте.

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

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

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

Таким образом, задачей настоящего изобретения является обеспечение устройства и способа для предоставления услуги MBMS, когда осуществляется эстафетная передача обслуживания UE от контроллера SRNC к контролеру CRNC в системе мобильной связи с MBMS.

Другой задачей настоящего изобретения является обеспечение устройства и способа для предоставления услуги MBMS без отдельного Iur-интерфейса между SRNC и CRNC, когда осуществляется эстафетная передача обслуживания UE от SRNC к CRNC в системе мобильной связи с MBMS.

Еще одной задачей настоящего изобретения является обеспечение устройства и способа для эффективного управления проводными/беспроводными ресурсами для услуги MBMS в системе мобильной связи с MBMS.

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

Еще одной задачей настоящего изобретения является обеспечение устройства и способа для эффективного управления проводными/беспроводными ресурсами путем определения нового сообщения между SRNC и CRNC в системе мобильной связи с MBMS.

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

Очередной задачей настоящего изобретения является обеспечение устройства и способа для раздельной передачи/приема сигнала данных и управляющего сигнала в соответствии с перемещениями единиц UE в системе мобильной связи с MBMS.

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

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

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

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

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

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

фиг.1 - схематическое представление структуры системы мобильной связи для предоставления услуги MBMS;

фиг.2 - схематическое представление структуры сети UTRAN, показанной на фиг.1;

фиг.3 - схематическое представление структуры верхнего уровня сети UTRAN, показанной на фиг.1;

фиг.4А - схематическое представление конфигурации для предоставления услуги MBMS в системе мобильной связи, к которой подсоединены узел SGSN, контроллер SRNC, контроллер CRNC и единицы UE;

фиг.4В - схематическое представление конфигурации для предоставления услуги MBMS в системе мобильной связи, к которой подсоединены узел SGSN, контроллер SRNC, контроллер CRNC и единицы UE;

фиг.5 - диаграмма сигнализации, иллюстрирующая процедуру предоставления услуги MBMS в системе мобильной связи, соединенной, как показано на фиг.4А;

фиг.6 - диаграмма сигнализации, иллюстрирующая процедуру предоставления услуги MBMS в системе мобильной связи, соединенной, как показано на фиг.4В;

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

фиг.8 - диаграмма сигнализации, иллюстрирующая процедуру предоставления UE услуги MBMS во время эстафетной передачи обслуживания от SRNC к CRNC согласно варианту осуществления настоящего изобретения;

фиг.9 - блок-схема алгоритма, иллюстрирующая процедуру предоставления узлом SGSN услуги MBMS согласно варианту осуществления настоящего изобретения;

фиг.10 - блок-схема алгоритма, иллюстрирующая процедуру выполнения контроллером SRNC услуги MBMS согласно варианту осуществления настоящего изобретения;

фиг.11 - блок-схема алгоритма, иллюстрирующая процедуру предоставления контроллером CRNC услуги MBMS согласно варианту осуществления настоящего изобретения;

фиг.12 - блок-схема алгоритма, иллюстрирующая процедуру предоставления оборудованием UE услуги MBMS согласно варианту осуществления настоящего изобретения;

фиг.13 - блок-схема алгоритма, иллюстрирующая процедуру управления контекстом MBMS со стороны узла SGSN, согласно варианту осуществления настоящего изобретения;

фигуры 14А, 14В, 15 и 16 - блок-схемы алгоритмов, иллюстрирующие процедуру управления контекстом MBMS со стороны контроллера RNC согласно варианту осуществления настоящего изобретения;

фиг.17 - схематическое представление структуры уровня L2/MAC для непосредственной передачи данных от CRNC на UE согласно варианту осуществления настоящего изобретения.

Подробное описание предпочтительного варианта осуществления изобретения

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

На фиг.7 схематически показана конфигурация системы мобильной связи, предоставляющей услугу MBMS, согласно варианту осуществления настоящего изобретения. Описание фиг.7 основано на следующих предположениях. А именно, оборудование (UE) пользователя передало сообщение Activate MBMS Context Request в обслуживающий контроллер радиосети (SRNC), передало сообщение Cell Update Confirm после перемещения в соту, управляемую управляющим контроллером RNC (CRNC), приняло сообщение MBMS Notification для услуги MBMS от обслуживающего узла (SGSN) поддержки GPRS и передало сообщение с ответом на поисковый вызов (Paging Response) в ответ на сообщение MBMS Notification. Здесь передача сообщения Paging Response является необязательным процессом, выполняемым в зависимости от способа функционирования сетевого оператора.

Обратимся к фиг.7, где SGSN 701 соединен с SRNC 702 и CRNC 703 через Iu-интерфейс 711 и Iu-интерфейс 712 соответственно. Здесь Iu-интерфейс обозначает интерфейс между SGSN и RNC. SGSN 701 передает на SRNC 702 данные MBMS для единиц UE, находящихся в сотах, управляемых контроллером SRNC 702, то есть UE#1 704 и UE#2 705, а CRNC 703 передает данные MBMS для UE#m 706, так что UE#m 706 может принимать данные MBMS под управлением контроллера CRNC 703. UE#m 706 находится под управлением SRNC 702 для управления сетью и другими услугами кроме услуги MBMS, такими как однонаправленный радиоканал (RB) или однонаправленный канал (RAB) радиодоступа. То есть в изобретении при предоставлении UE#m 706 услуги MBMS передается управляющее сообщение через SRNC 702 и Iur-интерфейс 713, а также передаются действительные данные MBMS через CRNC 703. Другими словами, в изобретении предлагается способ обслуживания для разделения трассы передачи управляющего сообщения и трассы передачи данных MBMS, когда UE, принимающее услугу MBMS через SRNC, переместилось в соту, управляемую контроллером CRNC. Впрочем, операции, вызванные разделением трассы передачи управляющего сообщения и трассы передачи данных MBMS, описываются ниже.

Другие услуги и управляющее сообщение, обеспечиваемые сетью, доставляются на UE#m 706 через Iur-интерфейс 713 между SRNC 702 и CRNC 703. Здесь Iur-интерфейс представляет интерфейс между контроллерами RNC. UE#m 706 принимает данные MBMS через CRNC 703. Поскольку данные MBMS доставляются на UE#m 706 через CRNC 703, можно сэкономить проводные ресурсы однонаправленного канала Iur между SRNC 702 и CRNC 703 и поскольку CRNC 703 непосредственно предоставляет услугу на UE#m 706, контроллер CRNC 703 может более эффективно управлять беспроводными ресурсами сот, управляемых самим CRNC 703.

Далее описываются: (1) содержимое контекстов, создаваемых объектами, то есть SGSN, SRNC и CRNC, из-за разделения трассы передачи управляющего сообщения и трассы передачи данных MBMS после перемещения UE при предоставлении услуги MBMS; (2) поток сигнализации между соответствующими объектами и (3) структура соответствующих объектов.

Система мобильной связи согласно варианту осуществления настоящего изобретения имеет формат контекста MBMS, отличный от стандартной системы мобильной связи с MBMS. Контекст MBMS представляет содержимое, необходимое для предоставления услуги MBMS, а соответствующие объекты, существующие в сети для предоставления услуги MBMS, запоминают контекст MBMS в соответствии с их функциями. Контексты MBMS, принадлежащие узлу SGSN, контроллеру SRNC, контроллеру CRNC и устройствам UE могут иметь разное содержимое. В Таблице 5, представленной ниже, показаны новые параметры для запоминания контекста MBMS, предложенного в изобретении.

Таблица 5
Эле-мент	Существую-щая функция	Добавленная функция	Описание
SGSN	Контекст ММ каждой единицы UE, контекст PDP MBMS каждой услуги MBMS	Контекст ММ каждой единицы UE + контекст PDP MBMS каждой услуги MBMS вместе со списком идентификаторов UE	Контекст ММ (управление мобильной связью) каждой единицы UE такой же, как был ранее. Для каждой услуги MBMS добавляется список контроллеров RNC, предоставляющих услугу MBMS. Подробности смотри на фиг.13.
SRNC	Контекст UE	Контекст UE с информацией MBMS	Идентификатор услуги MBMS, предоставляемой для UE, добавляется к ранее организованному контексту UE. Подробности смотри на фигурах 14, 15 и 16.
CRNC	Нет	Контекст MBMS для каждой услуги	Обычно контекст MBMS UE под управлением CRNC отсутствует. Даже если контекст MBMS существует, его содержимое контент просто относится к назначению радиоресурсов. Как и вновь добавленное содержимое, список единиц UE добавляется для каждой услуги MBMS. Подробности смотри на фигурах 14, 15 и 16.

Как показано в таблице 5, содержимое контекста MBMS, принадлежащего каждому из SGSN, SRNC и CRNC, включает в себя вновь добавленные параметры в дополнение к таким параметрам, как содержимое контекста MBMS, который формируется в стандартной системе связи с MBMS. Подробное описание контекста MBMS по Таблице 5 приведено ниже со ссылками на фигуры с 13 по 16. Содержимое контекста MBMS UE в настоящем изобретении идентично содержимому контекста MBMS в стандартной системе связи с MBMS. Поэтому это содержимое в Таблице 5 не показано.

На фиг.8 представлена диаграмма сигнализации, иллюстрирующая процедуру предоставления услуги MBMS оборудованию UE во время эстафетной передачи обслуживания от SRNC к CRNC согласно варианту осуществления настоящего изобретения. Описание фиг.8 основано на предположении, что услуга MBMS, запрошенная оборудованием UE#m 840, в данный момент в контроллере CRNC 830 не обслуживается, а UE#m 840 передало сообщение Activate MBMS Context Request в SRNC 820, передало сообщение Cell Update Confirm после перемещения в соту, управляемую контроллером CRNC 830, приняло от SGSN 810 сообщение MBMS Notification и передало сообщение Paging Response в ответ на сообщение MBMS Notification. Здесь передача сообщения Paging Response является необязательным процессом, который выполняется в зависимости от способа функционирования сетевого оператора.

Обратимся к фиг.8, где SGSN 810 передает на SRNC 820 сообщение MBMS RAB Setup Request для запроса настройки канала RAB для передачи данных MBMS (этап 811). После приема сообщения MBMS RAB Setup Request от SGSN 810 контроллер SRNC 820 передает сообщение с запросом на подключение MBMS (MBMS Attach Request) на CRNC 830, который управляет сотой, где находится UE#m 840, поскольку SRNC 820 обнаруживает, что UE#m 840, запрашивающее услугу MBMS, не находится в соте, управляемой самим SRNC 820 (этап 813). Здесь сообщение MBMS Attach Request является новым сообщением, предложенным в изобретении, которое необходимо контроллеру SRNC, чтобы запросить у CRNC предоставление услуги MBMS даже переместившемуся UE, для того чтобы предоставить услугу MBMS оборудованию UE, переместившемуся от SRNC к CRNC.

После приема сообщения MBMS Attach Request контроллер CRNC 830 выполняет операцию передачи данных MBMS даже на переместившееся UE, то есть UE#m 840, когда оборудование UE, желающее получить услугу MBMS, то есть UE#m 840, перемещается в соту, управляемую контроллером CRNC 830. В частности, информация, которая должна быть передана контроллером SRNC 820 контроллеру CRNC 830 посредством сообщения MBMS Attach Request, включает в себя идентификатор (ID) оборудования UE#m 840, идентификатор услуги MBMS, запрошенной оборудованием UE#m 840, и информацию о RB для передачи управляющего сообщения, соответствующего идентификатору услуги MBMS. RB для передачи управляющего сообщения включает в себя, например, выделенный канал управления (DCCH), и в этом случае информация о RB становится информацией, относящейся к DCCH. Здесь идентификатор UE#m 840 указывает, что UE#m 840 принимает услугу MBMS от CRNC 830, а идентификатор услуги MBMS указывает тип услуги MBMS, принимаемой оборудованием UE#m 740. Информация о RB - это информация, которую можно использовать при задании формата выделенного канала (DCH), когда CRNC 830 предоставляет услугу MBMS на основе соединения «точка-точка» (PtP), то есть когда CRNC 830 предоставляет услугу MBMS, используя канал DCH.

После приема сообщения MBMS Attach Request контроллер CRNC 830 передает в узел SGSN 810 сообщение с запросом на услугу MBMS (MBMS Service Request), поскольку он не имеет данных MBMS, относящихся к запрошенной услуге MBMS (этап 815). Поскольку здесь предполагается, что CRNC 830 не предоставляет услугу MBMS, то CRNC 830 посылает в узел SGSN 810 запрос на услугу MBMS, чтобы предоставить услугу MBMS переместившемуся UE#m 840. То есть, поскольку Iu-интерфейс, который должен быть настроен для предоставления услуги MBMS, в данный момент между CRNC 830 и SGSN 810 не настроен, контроллер CRNC 830 должен запросить настройку Iu-интерфейса. Операция, выполняемая при предоставлении контроллером CRNC 830 запрошенной услуги MBMS, будет описана ниже со ссылками на фигуры с 14 по 16.

После приема сообщения MBMS Service Request узел SGSN 810 присоединяет идентификатор контроллера CRNC 830 к контексту протокола пакетной передачи данных (PDP) MBMS, а затем передает сообщение MBMS RAB Setup Request на контроллер CRNC 830, чтобы передать запрошенные данные MBMS (этап 817). В результате между CRNC 830 и SGSN 810 устанавливается Iu-интерфейс для услуги MBMS. Здесь контекст PDP для MBMS является контекстом PDP, сформированным в соответствии с типами услуги MBMS. CRNC 830 в ответ на сообщение MBMS RAB Setup Request передает на SGSN 810 сообщение MBMS RAB Setup Complete (этап 819). Как было описано выше, на этапах 817 и 819 из-за того, что CRNC 830 не предоставляет услугу MBMS, этот CRNC 830 посылает в узел SGSN запрос на информацию о настройке RAB для услуги MBMS 810, и канал RAB настраивается соответствующим образом. Кроме того, CRNC 830 передает сообщение с ответом на запрос на подключение MBMS (MBMS Attach Response) на SRNC 820 (этап 821). Сообщение MBMS Attach Response также является новым сообщением, предложенным в изобретении, и представляет собой ответное сообщение на сообщение MBMS Attach Request. Сообщение MBMS Attach Response является сообщением, используемым контроллером CRNC 830 при присоединении переместившегося UE, то есть UE#m 840, к контексту CRNC, управляемому контроллером CRNC 830, и последующем информировании SRNC 820 о том, что между SGSN 810 и CRNC 830 установлен Iu-интерфейс. Здесь сообщение MBMS Attach Response включает в себя информацию о канале RB, используемую контроллером CRNC 820 для передачи данных MBMS. Таким образом, SRNC 820 передает на UE#m 840 сообщение RB Setup в соответствии с информацией о RB (этап 823). После приема сообщения RB Setup оборудование UE#m 840 передает сообщение RB Setup Complete на SRNC 820 в ответ на принятое сообщение RB Setup (этап 825), так что SRNC 820 уведомляется о завершении настройки RB. После этого CRNC 830 принимает данные MBMS от SGSN 810 через Iu-интерфейс (этап 827) и передает принятые данные MBMS на UE#m 840 (этап 829). В результате в настоящем изобретении контроллер CRNC 830 может непосредственно принимать данные MBMS от узла SGSN 810 через Iu-интерфейс.

Если UE#m 840 не хочет больше принимать выполняющуюся услугу MBMS, то оно передает в узел SGSN 810 сообщение о деактивации услуги MBMS (MBMS Service Deactivation) (этап 831). После приема сообщения MBMS Service Deactivation узел SGSN 810 передает сообщение MBMS Service Deactivation на SRNC 820 (этап 833), а SRNC 820 снова передает сообщение MBMS Service Deactivation на CRNC 830 (этап 835). Кроме того, SRNC 820 передает на UE#m 840 сообщение об освобождении канала RB услуги MBMS (MBMS RB Release) (этап 837). Также процесс деактивации услуги MBMS будет описан ниже со ссылками на фигуры с 14 по 16. Заметим, что, как было описано выше, управление переместившимся оборудованием UE#m 840 осуществляется посредством передачи управляющей информации через SRNC 820, а данные MBMS передаются через CRNC 830. То есть трасса управляющего сообщения отделена от трассы передачи данных.

Вариант осуществления настоящего изобретения, описанный вместе с фигурами 7 и 8, имеет следующие преимущества.

1. Исключается ненужная передача одних и тех же данных MBMS от SRNC на CRNC, в результате чего повышается эффективность использования проводных ресурсов и эффективность сетевого управления. То есть, как было описано выше, предотвращается ненужная повторная передача одних и тех же данных MBMS по Iur-интерфейсу, который является интерфейсом между SRNC и CRNC, при этом SRNC передает только управляющее сообщение, а CRNC передает данные MBMS, что гарантирует эффективное использование проводных/беспроводных ресурсов.

2. Поскольку данные MBMS оборудования UE, имеющего в качестве CRNC контроллер CRNC, непосредственно передаются от SGSN на CRNC, предотвращается ненужная передача данных от UE на SRNC, что гарантирует эффективное использование проводных ресурсов и эффективное сетевое управление. То есть, если все UE, принимающие от SRNC услугу MBMS, переместились, то данные MBMS передаются только через CRNC и в передаче данных MBMS на SRNC нет необходимости. Обычно, даже если все UE, принимающие услугу MBMS от SRNC, переместились, то, поскольку данные должны передаваться через SRNC, требовалась передача данных MBMS от SGSN на SRNC. Однако согласно настоящему изобретению ненужная передача данных MBMS от SGSN на SRNC теперь не потребуется.

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

На фиг.9 представлена блок-схема алгоритма, иллюстрирующая процедуру предоставления услуги MBMS узлом SGSN согласно варианту осуществления настоящего изобретения. Обратимся к фиг.9, где на этапе 901 SGSN принимает сообщение Activate MBMS Context Request от конкретного UE. Сообщение Activate MBMS Context Request является сообщением, используемым UE при запросе услуги MBMS конкретного типа из множества услуг MBMS, предоставляемых узлом SGSN. После приема сообщения Activate MBMS Context Request узел SGSN определяет, является ли тип услуги MBMS, запрошенной оборудованием UE, типом услуги MBMS, доступным UE, путем поиска в реестре (HLR) местоположения собственных абонентов. В результате этого определения на этапе 902, если тип услуги MBMS, запрошенной оборудованием UE, является типом услуги MBMS, доступным UE, то SGSN передает на UE сообщение MBMS Notification, уведомляющее о том, что тип услуги MBMS, запрошенный UE, доступен и запрошенный тип услуги MBMS вскоре будет инициирован.

На этап 903 узел SGSN принимает сообщение Paging Response, переданное от UE в ответ на переданное сообщение MBMS Notification. Процесс приема сообщения Paging Response в ответ на переданное сообщение MBMS Notification, как упоминалось выше, может быть выбран опционально в соответствии с режимом работы системы.

После приема сообщения Paging Response от UE узел SGSN на этапе 904 определяет, обслуживается ли тип услуги MBMS, запрошенный оборудованием UE, в RNC, которому в текущий момент принадлежит UE. Обслуживается ли тип услуги MBMS, запрошенный UE, в RNC, которому в текущий момент принадлежит UE, можно определить по списку контроллеров RNC, предоставляющих услугу MBMS, в контексте MBMS, хранящемся в узле SGSN. Если данный тип услуги MBMS, запрошенный UE, не обслуживается в RNC, которому в данный момент принадлежит UE, то SGSN переходит к этапу 905. На этапе 905 узел SGSN передает на SRNC сообщение MBMS RAB Setup Request для UE, чтобы предоставить услугу MBMS запрошенного типа. Однако, если на этапе 904 определено, что тип услуги MBMS, запрошенный UE, обслуживается в SRNC, которому в данный момент принадлежит UE, то SGSN переходит к этапу 906. На этапе 906 узел SGSN выполняет запрос в SRNC для UE на обслуживание услуги MBMS запрошенного типа для UE. При запросе контроллера SRNC для UE на обслуживание услуги MBMS запрошенного типа узел SGSN может обеспечить управление текущей ситуацией, складывающейся с предоставлением услуги MBMS для UE, путем присоединения идентификатора услуги MBMS, запрошенной UE, к контексту ММ (управление мобильной связью) данного UE.

На этапе 907 узел SGSN ожидает ответ на тип услуги MBMS, запрошенный UE, от контроллера SRNC для UE. В данном варианте осуществления настоящего изобретения, поскольку предполагается, что UE находится в соте, управляемой контроллером SRNC, а не CRNC, узел SGSN не сможет принять ответ от SRNC. Следовательно, SGSN посредством сообщения MBMS RAB Setup Complete либо другого сообщения, способного передать содержимое на SGSN, принимает ответ, указывающий на то, предоставляет ли SRNC услугу для UE после того, как SRNC завершил соответствующую операцию с CRNC для UE, либо запрос на услугу посылают в другой RNC. Кроме того, в данном варианте осуществления настоящего изобретения предполагается, что услуга MBMS, запрошенная UE, в CRNC не обслуживается, и на этапе 908 узел SGSN принимает от CRNC сообщение MBMS Service Request. На этапе 909 узел SGSN обновляет список RNC таким образом, что в список RNC каждого типа услуги MBMS, управляемого узлом SGSN, добавляется идентификатор CRNC. На этапе 910 узел SGSN передает сообщение MBMS RAB Setup Request для передачи данных MBMS на CRNC. На этапе 911 узел SGSN принимает от CRNC сообщение MBMS RAB Setup Complete.

На этапе 912 узел SGSN передает на CRNC данные MBMS, предоставляемые центром (BM-SC) услуг мультивещания/ широковещания. На этапе 913 узел SGSN непрерывно отслеживает наличие сообщения MBMS Service Deactivation от UE. Между тем, если сообщение MBMS Service Deactivation принято, то узел SGSN переходит к этапу 914. То есть после приема сообщения MBMS Service Deactivation узел SGSN выполняет операцию удаления идентификатора услуги MBMS из контекста MM данного UE, управляемого узлом SGSN, а затем на этапе 914 определяет, принято ли от конкретного RNC, подсоединенного к SGSN, сообщение MBMS RAB Release для передачи данных MBMS. Если сообщение MBMS RAB Release для передачи данных MBMS принято от RNC, то узел SGSN переходит к этапу 915. На этапе 915 узел SGSN обновляет список единиц UE, принимающих услуги MBMS, и список контроллеров RNC, предоставляющих соответствующие услуги MBMS.

Если на этапе 914 определено, что сообщение MBMS RAB Release для передачи данных MBMS не принято от RNC, то узел SGSN переходит к этапу 916. На этапе 916 SGSN обновляет список единиц UE, принимающих услуги MBMS, а затем переходит к этапу 917. На этапе 917 узел SGSN доставляет в SRNC для UE сообщение о закрытии услуги MBMS, то есть сообщение MBMS Service Deactivation, приостанавливая тем самым выполнение услуги MBMS для UE и заканчивая данную процедуру.

На фиг.10 представлена блок-схема алгоритма, иллюстрирующая процедуру выполнения контроллером SRNC услуги MBMS согласно варианту осуществления настоящего изобретения. Обратимся к фиг.10, где на этапе 1001 контроллер SRNC принимает от UE сообщение о завершении обновления соты (Cell Update Complete). После приема сообщения Cell Update Complete от UE контроллер SRNC делает вывод, что UE имеет CRNC, когда оно перемещается в другую соту, то есть когда осуществляется эстафетная передача обслуживания этого UE. На этапе 1002 контроллер SRNC передает на UE сообщение Cell Update Confirm, информируя о том, что он воспринял перемещение UE к CRNC. На этапе 1003 контроллер SRNC принимает от SRNC сообщение MBMS RAB Setup Request для передачи данных MBMS, запрошенных UE. На этапе 1004 контроллер SRNC определяет идентификатор услуги MBMS, запрошенной UE, идентификатор данного UE и информацию о канале RB, по которому передается управляющее сообщение на UE, исходя из принятого сообщения MBMS RAB Setup Request, и передает обнаруженный идентификатор услуги MBMS, идентификатор данного UE и информацию о RB на CRNC для UE вместе с сообщением MBMS Attach Request. На этапе 1005 контроллер SRNC обновляет контекст MM данного UE путем добавления идентификатор услуги MBMS, принимаемой UE, к контексту ММ, и удаляет идентификатор данного UE из списка единиц UE каждого типа слуг MBMS, управляемого в SRNC.

На этапе 1006 контроллер SRNC принимает сообщение MBMS Attach Response от CRNC. На этапе 1007 SRNC обнаруживает информацию о RB, подлежащего использованию для передачи данных MBMS на UE, включенную в сообщение MBMS Attach Response и передает на UE сообщение MBMS RB Setup на основе обнаруженной информации о RB. На этапе 1008 контроллер SRNC принимает от UE сообщение MBMS RB Setup Complete, соответствующее сообщению MBMS RB Setup, а затем на этапе 1009 SRNC принимает сообщение MBMS Deactivation для UE от узла SGSN. На этапе 1010 контроллер SRNC удаляет из контекста ММ данного UE идентификатор услуги MBMS, а на этапе 1011 контроллер SRNC передает сообщение MBMS Service Deactivation для UE на CRNC, который предоставляет услугу MBMS для UE. На этапе 1012 SRNC передает на UE сообщение MBMS RB Release для освобождения канала RB услуги MBMS, используемого при приеме данных MBMS, в результате чего данная процедура заканчивается.

На фиг.11 представлена блок-схема алгоритма, иллюстрирующая процедуру предоставления услуги MBMS контроллером CRNC согласно варианту осуществления настоящего изобретения. Обратимся к фиг.11, где на этапе 1101 контроллер CRNC принимает сообщение MBMS Attach Request от SRNC для UE. Контроллер CRNC обнаруживает идентификатор оборудования UE, идентификатор услуги MBMS и информацию о канале RB DCCH для UE, включенные в сообщение MBMS Attach Request. На этапе 1102 котроллер CRNC определяет, обслуживается ли в текущий момент услуга MBMS, указанная идентификатором услуги MBMS. Если услуга MBMS, указанная идентификатором услуги MBMS, в текущий момент обслуживается, то CRNC переходит к этапу 1104. На этапе 1104 контроллер CRNC добавляет идентификатор UE в список идентификатор UE для каждого типа услуги MBMS, управляемого контроллером CRNC, а затем переходит к этапу 1109.

Однако, если на этапе 1102 определено, что услуга MBMS, указанная идентификатором услуги MBMS, не обслуживается, то CRNC переходит к этапу 1103. На этапе 1103 контроллер CRNC передает сообщение MBMS Service Request на узел SGSN, чтобы принять услугу MBMS, а затем переходит к этапу 1105. На этапе 1105 контроллер CRNC принимает сообщение MBMS RB Setup Request, необходимое при приеме данных MBMS от SGSN. На этапе 1106 контроллер CRNC передает сообщение MBMS RB Setup Complete на SGSN как ответ на сообщение MBMS RB Setup Request, а затем на этапе 1107 контролер CRNC принимает от SGSN данные MBMS. Однако в альтернативном варианте на этапе 1103 контроллер CRNC может передавать сообщение MBMS RB Setup Request на SGSN при передаче сообщения MBMS Service Request. В этом случае SGSN может информировать CRNC о том, что передача данных MBMS, запрошенных контроллером CRNC, была принята, посредством сообщения MBMS Setup Complete. На этапе 1108 контроллер CRNC добавляет новый идентификатор услуги MBMS в список MBMS, управляемый контроллером CRNC, и добавляет UE в список единиц UE идентификатора услуги MBMS, а затем переходит к этапу 1109.

На этапе 1109 контроллер CRNC принимает данные MBMS, запрошенные UE, определяет, по какому каналу RB должны передаваться данные MBMS, после добавления в список типа запрошенной услуги MBMS. На этапе 1110 контроллер CRNC передает информацию по определенному RB на SRNC для UE, используя сообщение MBMS Attach Response. На этапе 1111 контроллер CRNC начинает передачу данных MBMS для UE, а на этапе 1112 контроллер CRNC принимает сообщение MBMS Service Deactivation для UE от SRNC для этого UE. На этапе 1113 контроллер CRNC определяет, имеются ли какие-либо другие UE, принимающие услугу MBMS того типа, который принимало указанное UE. Если нет единиц UE, принимающих услугу MBMS того же типа, что принимало указанное UE, то CRNC переходит к этапу 1114. На этапе 1114 контроллер CRNC передает на SGSN сообщение MBMS RAB Release для запроса или предписания на освобождение канала RAB услуги MBMS, настроенного ранее для передачи данных MBMS между CRNC и SGSN. На этапе 1116 контроллер CRNC удаляет идентификатор указанного UE из списка единиц UE для услуги MBMS либо удаляет идентификатор услуги MBMS из списка услуг MBMS, управляемого контроллером CRNC, а затем переходит к этапу 1117.

Однако если на этапе 1113 определено, что имеется другое UE, принимающее услугу MBMS того типа, что принимало упомянутое UE, то CRNC переходит к этапу 1115. На этапе 1115 контроллер CRNC удаляет идентификатор этого UE из списка услуги MBMS, которую принимало оборудование UE#m. На этапе 1117 контролер CRNC передает сообщение с ответом на запрос на деактивацию услуги MBMS (MBMS Deactivation Response) для UE на SRNC для этого UE, а затем переходит к этапу 1118. На этапе 1118 контроллер CRNC освобождает радиоресурс, назначенный UE, а затем заканчивает процедуру. Здесь радиоресурс освобождается в том случае, когда услуга MBMS обслуживалась на основе схемы передачи «точка-точка» (PtP), а также в другом случае, когда услуга MBMS обслуживалась на основе схемы передачи «точка-множество точек» (PtM). В первом случае назначенный оборудованию UE радиоресурс освобождается, а во втором случае из списка MBMS выводится идентификатор этого UE.

На фиг.12 представлена блок-схема алгоритма, иллюстрирующая процедуру предоставления услуги MBMS посредством оборудования UE согласно варианту осуществления настоящего изобретения. Обратимся к фиг.12, где на этапе 1201 оборудование UE передает сообщение Activate MBMS Context Request на SGSN. На этапе 1202 это UE принимает от SGSN сообщение MBMS Notification, уведомляющее о том, что тип услуги MBMS, запрошенный этим UE, разрешен, и услуга MBMS соответствующего типа будет вскоре запущена. Здесь UE может передавать либо не передавать сообщение Paging Response на SGSN в ответ на принятое сообщение MBMS Notification, то есть эта операция не является обязательной в соответствии с режимом работы системы, как упоминалось выше. На фиг.12 предполагается, что сообщение Paging Response в ответ на сообщение MBMS Notification не передается. На этапе 1203 оборудование UE принимает сообщение MBMS RB Setup для настройки канала RB услуги MBMS, по которому должны передаваться данные MBMS от SRNC для UE. На этапе 1204 оборудование UE передает на SRNC сообщение MBMS RB Setup Complete, соответствующее принятому сообщению MBMS RB Setup.

На этапе 1205 оборудование UE принимает данные MBMS. Если на этапе 1206 оборудование UE обнаруживает, что пользователь больше не хочет принимать услугу MBMS соответствующего типа, то UE передает сообщение MBMS Service Deactivation, указывающее на ожидаемую приостановку приема данных MBMS для услуги MBMS этого типа. На этапе 1207 оборудование UE принимает сообщение MBMS RB Release, используемое при приеме данных MBMS от SRNC, а на этапе 1208 оборудование UE передает сообщение о завершении освобождения канала RB услуги MBMS (MBMS RB Release Complete) на SRNC как ответ на сообщение MBMS RB Release после освобождения канала RB услуги MBMS, используемого для приема данных MBMS, и заканчивает тем самым описываемую процедуру.

На фиг.13 представлена блок-схема алгоритма, иллюстрирующая процедуру управления контекстом MBMS, осуществляемую узлом SGSN, согласно варианту осуществления настоящего изобретения. Обратимся к фиг.13, где на этапе 1301 узел SGSN находится в состоянии, в котором он хранит список PDP для услуг MBMS, список единиц UE, принимающих услуги MBMS, для услуг MBMS и список контроллеров RNC, предоставляющих услуги MBMS, для услуг MBMS. На этапе 1302 узел SGSN определяет, принято ли от конкретного UE сообщение Activate MBMS Context Request. Если от конкретного UE принято сообщение Activate MBMS Context Request, то SGSN переходит к этапу 1303. На этапе 1303 узел SGSN определяет, обслуживается ли тип услуги MBMS, запрошенный оборудованием UE, в RNC, которому принадлежит это UE. Здесь список RNC для соответствующих услуг MBMS используется в процессе определения того, обслуживается ли тип услуги MBMS, запрошенный UE, в RNC, которому принадлежит данное UE. Хотя это на фиг.13 не показано, можно также определить, предоставляется ли услуга MBMS запрошенного типа от SRNC, путем непосредственной передачи сообщения MBMS RAB Setup Request для передачи данных MBMS на SRNC для данного UE без определения того, предоставляется ли запрошенный тип услуги MBMS из RNC, которому принадлежит данное UE.

Если тип услуги MBMS, запрошенный оборудованием UE, предоставляется из RNC, которому принадлежит UE, то узел SGSN переходит к этапу 1311. На этапе 1311 узел SGSN передает сообщение MBMS RAB Setup Request на SRNC для этого UE. На этапе 1312 узел SGSN принимает сообщение MBMS RAB Setup Complete от SRNC, а затем на этапе 1313 SGSN определяет, содержит ли информация, включенная в принятое от SRNC сообщение MBMS RAB Setup Complete, указание на то, что SRNC непосредственно обслуживает этот тип услуги MBMS. Если указанная информация содержит указание на то, что SRNC непосредственно обслуживает данный тип услуги MBMS, то SGSN переходит к этапу 1331. На этапе 1331 узел SGSN передает данные MBMS. На этапе 1332 узел SGSN добавляет указанный RNC в список контроллеров RNC, предоставляющих услугу MBMS, добавляет UE в список единиц UE, принимающих эту услугу MBMS, а затем переходит к этапу 1345.

Однако если на этапе 1313 определено, что указанная информация не содержит указания на то, что SRNC непосредственно обслуживает данный тип услуги MBMS, то SGSN переходит к этапу 1380. На этапе 1380 узел SGSN переходит к этапу 1341 без добавления SRNC к списку контроллеров RNC для каждой услуги MBMS. На этапе 1341 узел SGSN определяет, имеется ли сообщение MBMS RAB Setup Request для сообщения с запросом на передачу данных MBMS (MBMS Data Transmission Request) от другого RNC. Здесь термин «другой RNC» относится к CRNC. Если имеется сообщение MBMS RAB Setup Request для сообщения MBMS Data Transmission Request от другого RNC, то SGSN переходит к этапу 1342. На этапе 1342 узел SGSN передает сообщение MBMS RAB Setup Complete на вышеуказанный RNC, а затем переходит к этапу 1343. На этапе 1343 узел SGSN передает данные MBMS на вышеупомянутый контроллер RNC. На этапе 1344 узел SGSN добавляет упомянутый RNC, то есть CRNC для UE, запрашивающего услугу MBMS, в список контроллеров RNC, предоставляющих услугу MBMS, добавляет UE в список единиц UE, принимающих услугу MBMS, а затем переходит к этапу 1345.

Помимо этого, если на этапе 1341 определяют, что нет сообщения MBMS RAB Setup Request для сообщения MBMS Data Transmission Request от другого RNC, то SGSN переходит к этапу 1351. На этапе 1351 узел SGSN добавляет идентификатор услуги MBMS в список единиц UE каждого типа услуги MBMS, то есть контекст ММ UE, а затем переходит к этапу 1345. Если определено, что не было принято сообщение MBMS Data Transmission Request от другого RNC, то это указывает на то, что запрошенный тип услуги MBMS уже обслуживается вышеуказанным RNC.

Однако если на этапе 1303 определяют, что тип услуги MBMS, запрошенный UE, не обслуживается в RNC, которому принадлежит это UE, то SGSN переходит к этапу 1321. На этапе 1321 узел SGSN передает сообщение MBMS Service Request на RNC (SRNC), которому принадлежит UE. На этапе 1322 узел SGSN принимает сообщение с подтверждением, то есть сообщение с ответом на запрос услуги MBMS (MBMS Service Response), для сообщения MBMS Service Request от RNC (SRNC). На этапе 1323 узел SGSN определяет, содержит ли сообщение MBMS Service Response для сообщения MBMS Service Request указание на то, что RNC непосредственно поддерживает соответствующий тип услуги MBMS. Если сообщение MBMS Service Response не содержит указание на то, что RNC поддерживает соответствующий тип услуги MBMS, то SGSN переходит к этапу 1341. Однако если определено, что сообщение MBMS Service Response содержит указание на то, что RNC поддерживает соответствующий тип услуги MBMS, то SGSN переходит к этапу 1351. На этапе 1351 узел SGSN добавляет в список единиц UE, принимающих услугу MBMS, только идентификатор указанного UE. Когда определено, что сообщение MBMS RAB Setup Request для того же сообщения MBMS Data Transmission Request в качестве данных MBMS, запрошенных UE, не было принято, это означает, что тип услуги MBMS, запрошенный UE, уже обслуживается в CRNC для этого UE. Таким образом, узлу SGSN разрешается добавить в контекст ММ указанного UE только идентификатор услуги MBMS, и обновлять список контроллеров RNC каждой услуги MBMS нет необходимости. Если на этапе 1323 определяется, что RNC непосредственно поддерживает соответствующий тип услуги MBMS, то узел SGSN добавляет на этапе 1351 в список единиц UE, принимающих услугу MBMS, только идентификатор указанного UE, и на этапе 1345 ожидает приема от UE сообщения с запросом на деактивацию услуги MBMS (MBMS Deactivation Request).

На этапе 1345 узел SGSN принимает от UE сообщение MBMS Deactivation Request для типа услуги MBMS, предоставляемой UE. На этапе 1346 узел SGSN определяет, принято ли сообщение MBMS RAB Release для услуги MBMS от RNC, то есть SRNC или CRNC для UE. Если сообщение MBMS RAB Release принято, то SGSN переходит к этапу 1347. На этапе 1347 узел SGSN удаляет UE и RNC соответственно из списка единиц UE, принимающих соответствующий тип услуги MBMS, и из списка контроллеров RNC, предоставляющих соответствующий тип услуги MBMS, а затем переходит к этапу 1349. На этапе 1349 узел SGSN передает сообщение MBMS RAB Release Complete на RNC, а затем заканчивает описываемую процедуру.

Однако если на этапе 1346 определяют, что сообщение MBMS RAB Release для услуги MBMS не принято от RNC, то есть от SRNC или CRNC для данного UE, то тогда SGSN переходит к этапу 1348. На этапе 1348 узел SGSN удаляет данное UE из списка единиц UE, принимающих соответствующий тип услуги MBMS, а затем заканчивает описываемую процедуру. Удаление UE из списка единиц UE, принимающих услугу MBMS, означает, что SGSN удаляет идентификатор услуги MBMS из контекста ММ этого UE.

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

Далее со ссылками на фигуры 14А, 14В, 15 и 16 описывается процедура управления контекстом MBMS со стороны RNC. В процедуре управления контекстом MBMS со стороны RNC рассматривается случай, когда услуга MBMS предоставляется на основе PtP, и случай, когда услуга MBMS предоставляется на основе PtM. Поскольку RNC может оказаться либо SRNC, либо CRNC, в зависимости от конкретных обстоятельств, RNC должен иметь как функцию управления контекстом MBMS контроллера SRNC, так и функцию управления контекстом MBMS контроллера CRNC, которые описаны в связи с фигурами 11 и 12. Описывая снова контекст MBMS контроллера SRNC, который был описан в связи с Таблицей 5, следует отметить, что SRNC добавляет идентификатор услуги MBMS в контекст ММ (положение UE, состояние UE и ситуация с использованием канала для UE) единиц UE, управляемых контроллером SRNC. Идентификатор услуги MBMS может оказаться идентификатором услуги MBMS, предоставляемой в SRNC, и идентификатором услуги MBMS, предоставляемой в CRNC. Кроме того, вновь описывая контекст MBMS для CRNC, следует сказать, что CRNC управляет списком единиц UE, принимающих услугу MBMS, для услуги MBMS, предоставляемой в контроллере CRNC. То есть RNC управляет списком услуг MBMS, предоставляемых каждой единице UE, находящейся в зоне обслуживания SRNC, и управляет списком услуг MBMS, предоставляемых в каждом контроллере RNC, находящемся в зоне обслуживания CRNC.

На фигурах 14А, 14В, 15 и 16 представлены блок-схемы алгоритмов, иллюстрирующие процедуру управления контекстом MBMS посредством RNC согласно варианту осуществления настоящего изобретения. Обратимся к фиг.14А, где на этапе 1401 контроллер RNC добавляет идентификатор услуги MBMS в контекст единиц UE, принимающих услугу MBMS, из числа единиц UE в контексте единиц UE, существующих в RNC, и управляет списком единиц UE для каждой услуги MBMS, обслуживаемой в RNC. На этапе 1402 контроллер RNC определяет, принято ли от узла SGSN сообщение MBMS RAB Setup для приема данных MBMS. Если сообщение MBMS RAB Setup для приема данных MBMS принято от SGSN, то RNC переходит к этапу 1403. На этапе 1403 контроллер RNC определяет, существует ли в настоящий момент в соте в зоне обслуживания RNC оборудование UE, запланированное для приема данных MBMS. Если в соте в зоне обслуживания RNC в настоящий момент не существует UE, запланированное для приема данных MBMS, то RNC переходит к этапу 1411. На этапе 1411 контроллер RNC передает сообщение MBMS Attach Request для UE на тот RNC, который управляет сотой, где в настоящий момент находится данное UE. Содержимое сообщения MBMS Attach Request было описано в связи с фигурами 11 и 12, так что оно повторно не описывается. На этапе 1412 контроллер SRNC принимает информацию о канале для передачи данных MBMS на UE от RNC, управляющего сотой, где находится UE, посредством сообщения MBMS Attach Response. На этапе 1413 контроллер SRNC передает сообщение MBMS RB Setup на UE, используя принятую информацию. SRNC принимает на этапе 1414 сообщение MBMS RB Setup Complete от UE, а затем на этапе 1415 удаляет идентификатор этого UE из списка единиц UE каждой услуги MBMS, которым в настоящий момент обладает контроллер SRNC. Если UE не принимало услугу MBMS, обслуживаемую в контроллере RNC, то этап 1415 можно опустить. Данная процедура после этапа 1415 переходит к точке В на фиг.16.

На этапе 1421, если UE, запланированное для приема данных MBMS, находится в RNC, то есть если UE находится в соте, управляемой контроллером RNC, то этот RNC выступает как SRNC. RNC передает на SGSN сообщение MBMS RAB Setup Complete на этапе 1421, а затем принимает данные MBMS от SGSN на этапе 1422. После приема данных MBMS от SGSN на этапе 1422 контроллер RNC на этапе 1423 определяет, будет ли он передавать данные MBMS на основе PtP. Будет ли RNC выполнять услугу MBMS на основе PtP или на основе PtM, можно определить по количеству UE, ожидающих приема услуги MBMS. То есть если количество UE, запланированных для приема данных MBMS, меньше заданного числа, то RNC может выбрать способ передачи данных MBMS на основе PtP, уменьшая тем самым энергопотребление узла В. Если же количество UE, запланированное для приема данных MBMS, больше или равно заданному числу, то RNC может выбрать способ передачи данных MBMS на основе PtM, уменьшая тем самым энергопотребление узла В для данного количества UE. Если RNC определяет на этапе 1423, что он будет передавать данные MBMS на UE на основе PtP, то RNC передает на этапе 1424 сообщение MBMS RB Setup, соответствующее передаче типа PtP на UE, а затем на этапе 1425 передает данные MBMS после приема от UE сообщения MBMS RB Setup Complete. На этапе 1428 контроллер RNC создает список единиц UE для услуги MBMS, а затем добавляет UE в этот список единиц UE для услуги MBMS и добавляет идентификатор услуги MBMS в контекст UE. Если RNC на этапе 1423 определяет, что он будет передавать данные MBMS на основе PtM, то RNC передает на этапе 1426 информацию о канале, используемом для передачи по схеме PtM, используя сообщение MBMS RB Setup, а затем на этапе 1427 принимает от UE сообщение MBMS RB Setup Complete. На этапе 1428 контроллер RNC создает список единиц UE услуги MBMS, а затем добавляет данное UE в список единиц UE указанной услуги MBMS и добавляет идентификатор услуги MBMS в контекст UE. Данная процедура после этапа 1428 переходит к точке В на фиг.16.

После того, как RNC не удалось принять сообщение MBMS RAB Setup Request для приема данных MBMS от SGSN на этапе 1402 по фиг.14А, контроллер RNC переходит к этапу 1430 на фиг.14В. Если на этапе 1430 принят от SGSN запрос на предоставление конкретной услуги MBMS конкретному UE, то RNC выполняет на этапе 1431 соответствующую операцию, а если запрос от SGSN не принят, то RNC переходит к точке А на фиг.15. После приема на этапе 1430 запроса на предоставление конкретной услуги MBMS конкретному UE от SGSN контроллер RNC на этапе 1431 определяет, находится ли в настоящее время UE, запланированное для приема данных MBMS, в соте в зоне обслуживания RNC, и выполняет этапы 1432 и 1441 в соответствии с результатом этого определения. Даже если услуга MBMS обслуживается в RNC, когда UE, запланированное для приема услуги MBMS, не находится в RNC, то есть если UE находится в соте, управляемой контроллером CRNC, то этап 1432 является начальной точкой, где RNC выступает в качестве SRNC. На этапе 1432 RNC передает сообщение MBMS Attach Request для UE на RNC, управляющий сотой, где находится указанное UE. Как было указано выше, содержимое сообщения MBMS Attach Request показано на фигурах 11 и 12. Контроллер SRNC принимает на этапе 1433 информацию о канале для передачи данных MBMS на UE от RNC, управляющего сотой, в которой находится UE, посредством сообщения MBMS Attach Response и передает на этапе 1434 сообщение MBMS RB Setup на UE, используя информацию, обнаруженную в сообщении MBMS Attach Response. Контроллер SRNC на этапе 1435 принимает от UE сообщение MBMS RB Setup Complete, а затем на этапе 1436 удаляет идентификатор указанного UE из списка единиц UE для каждого типа услуги MBMS, которым в настоящий момент обладает контроллер SRNC. Если UE не принимает услугу MBMS в RNC, то этап 1436 можно опустить. После этапа 1436 процедура переходит к точке В на фиг.16.

Когда услуга MBMS обслуживается в RNC и UE, запланированное для приема услуги MBMS, существует в RNC, то есть когда UE находится в соте, управляемой контроллером RNC, то этап 1441 является начальной точкой, где RNC выступает в качестве SRNC. На этапе 1441 контроллер RNC определяет, передаются ли данные MBMS на основе PtP. Если на этапе 1441 определяют, что данные MBMS передаются на основе PtP, то RNC на этапе 1442 передает на UE сообщение MBMS RB Setup, соответствующее передаче по схеме PtP, а затем на этапе 1443 передает данные MBMS после приема от UE сообщения MBMS RB Setup Complete. На этапе 1446 контроллер RNC добавляет упомянутое UE в список единиц UE для указанной услуги MBMS и добавляет идентификатор услуги MBMS в контекст этого UE.

Если на этапе 1441 определяют, что данные MBMS передаются на основе PtM, то RNC на этапе 1444 передает на UE информацию о канале, используемом для передачи по схеме PtM, с использованием сообщения MBMS RB Setup, а затем на этапе 1445 принимает от UE сообщение MBMS RB Setup Complete. На этапе 1446 контроллер RNC добавляет UE в список единиц UE для услуги MBMS и добавляет идентификатор услуги MBMS в контекст этого UE. После этапа 1446 процедура переходит в точку В на фиг.16.

На этапе 1501 по фиг.15 контроллер RNC определяет, принято ли сообщение MBMS Attach Request для UE в соте, управляемой контроллером RNC, от другого RNC. Если сообщение MBMS Attach Request не принято, то процедура переходит в точку С на фиг.14А. То есть контекст ММ всех UE и список единиц UE каждой услуги MBMS, управляемой контроллером RNC, не изменяются. Если на этапе 1501 по фиг.15 в текущий момент принято сообщение MBMS Attach Request для UE в соте, управляемой RNC, от другого RNC, то RNC на этапе 1502 определяет, обслуживается ли в текущий момент запрошенный тип услуги MBMS. Контроллер RNC переходит к этапу 1503 или этапу 1521 в соответствии с результатами определения на этапе 1502. На этапе 1503, когда услуга MBMS, запрошенная другим RNC, обслуживается в текущий момент в RNC, контроллер RNC определяет, передаются ли данные MBMS на основе PtP. Если на этапе 1503 определяют, что данные MBMS передаются на основе PtP, то RNC на этапе 1505 передает информацию о канале, соответствующую передаче по схеме PtP, на SRNC для UE посредством сообщения MBMS Attach Response, и на этапе 1506 передает данные MBMS на UE.

Если на этапе 1503 определяют, что данные MBMS передаются на основе PtM, то RNC на этапе 1504 передает информацию о канале для передачи по схеме PtM на SRNC для UE посредством сообщения MBMS Attach Response, а на этапе 1506 передает данные MBMS на UE. При передаче по схеме PtM этап 1506 указывает, что UE принимает ранее существовавшие данные MBMS, но не указывает назначение нового радиоресурса. На этапе 1507 контроллер RNC добавляет UE в список единиц UE для соответствующего типа услуги MBMS. После этапа 1507 функционирование RNC переходит в точку В на фиг.16.

Если на этапе 1502 определяют, что запрошенная услуга MBMS в текущий момент не обслуживается, то RNC на этапе 1521 передает на SGSN сообщение MBMS RAB Setup Request для приема данных MBMS, на этапе 1522 принимает от SGSN сообщение MBMS RAB Setup Complete для приема данных MBMS, а затем на этапе 1523 принимает от SGSN данные MBMS. На этапе 1524 контроллер RNC определяет, будет ли он передавать данные MBMS, запрошенные другим RNC, на основе PtP или на основе PtM. Если на этапе 1524 определяют, что данные MBMS должны передаваться на основе PtP, то RNC на этапе 1526 передает информацию о канале для передачи по схеме PtP на SRNC для UE посредством сообщения MBMS Attach Response, а на этапе 1527 передает на UE данные MBMS.

Если на этапе 1524 определяют, что данные MBMS передаются на основе PtM, то RNC на этапе 1525 передает информацию о канале для передачи по схеме PtM на SRNC для UE посредством сообщения MBMS Attach Response, а на этапе 1527 передает на UE данные MBMS. При передаче по схеме PtM этап 1527 не указывает назначение нового радиоресурса, поскольку данные MBMS до этого не существовали. На этапе 1528 контроллер RNC создает список единиц UE для соответствующего типа услуги MBMS и добавляет указанное UE в список единиц UE услуги MBMS. После этапа 1528 данная процедура переходит в точку В на фиг.16.

На фиг.16 представлена блок-схема алгоритма, иллюстрирующая функционирование RNC, когда RNC принял от SGSN или другого RNC сообщение MBMS Deactivation Request для UE, имеющего RNC в качестве SRNC или CRNC. На этапе 1601 контроллер RNC определяет, принято ли от SGSN сообщение MBMS Deactivation Request услуги MBMS для UE, принимающего в настоящий момент услугу MBMS, а затем переходит к этапу 1602 или 1611 в зависимости от результатов определения. Если на этапе 1601 определяют, что сообщение MBMS Deactivation Request для UE, принимающего в настоящее время услугу MBMS, было принято от SGSN, то RNC передает на этапе 1602 на UE сообщение MBMS RB Release для освобождения канала RB услуги MBMS, по которому UE принимает в данный момент данные MBMS, а затем на этапе 1603 принимает от UE сообщение MBMS RB Release Complete. Если на этапе 1601 определят, что сообщение MBMS Deactivation Request для UE, принимающего в текущий момент услугу MBMS, не было принято от SGSN, то RNC на этапе 1611 определяет, было ли принято сообщение MBMS Deactivation Request для конкретного UE, принимающего в текущий момент услугу MBMS, от другого RNC. Если на этапе 1611 определяют, что сообщение MBMS Deactivation Request для конкретного UE, принимающего в текущий момент услугу MBMS, было принято от другого RNC, то данный RNC не выполняет операцию обновления списка единиц UE для каждой услуги MBMS и идентификатора услуги MBMS в контексте MM этого UE, управляемого в текущий момент контроллером RNC. Если определяют, что сообщение MBMS Deactivation Request для конкретного UE, принимающего в данный момент услугу MBMS, было принято от другого RNC, то данный RNC на этапе 1612 передает сообщение с подтверждением деактивации услуги MBMS (MBMS Deactivation Confirm) для UE на SRNC для UE, на этапе 1613 определяет, обслуживалась ли услуга MBMS, которая принималась оборудованием UE, на основе PtP, а затем переходит к этапу 1614 или 1615 в зависимости от результатов определения. Если на этапе 1613 определяют, что UE принимало услугу MBMS в соответствии с сообщением MBMS Deactivation Request на основе PtP, то на этапе 1614 контроллером RNC выполняется процесс освобождения радиоресурса, назначенного оборудованию UE. Однако если на этапе 1613 определяют, что UE принимал услугу MBMS, соответствующую сообщению MBMS Deactivation Request, на основе PtM, то на этапе 1615 контроллер SRNC выполняет операцию удаления идентификатора указанного UE.

На этапе 1604 по фиг.16 контроллер RNC определяет, имеется ли другое UE, принимающее услугу MBMS, которую принимало данное UE, а затем выполняется этап 1605 или 1606 в зависимости от результатов определения. Если имеется другое UE, принимающее услугу MBMS, которую принимало данное UE, то RNC на этапе 1605 выполняет операцию удаления этого UE из списка единиц UE данной услуги MBMS. Если нет другого UE, принимающего услугу MBMS, которую принимало данное UE, то RNC на этапе 1606 передает на SGSN сообщение MBMS RAB Release для освобождения канала RAB услуги MBMS, по которому передавались данные MBMS, а затем на этапе 1607 принимает сообщение MBMS RAB Release Complete от SGSN. На этапе 1608 контроллер RNC удаляет UE из списка единиц UE данной услуги MBMS, а также удаляет идентификатор услуги MBMS из списка услуг MBMS в RNC.

На фиг.17 схематически показана структура уровня L2/MAC для непосредственной передачи данных MBMS от CRNC на UE согласно варианту осуществления настоящего изобретения. На фиг.17 контроллер SRNC 1701 является SRNC для управления единицами UE, желающими принять услугу MBMS, и выделяет объект MAC-d 1703 для оборудования UE. MAC-d 1703 является объектом MAC для передачи DCCH 1702 для UE. Контроллер SRNC 1701 передает сигнальное сообщение RRC, переданное из плоскости управления, используя канал DCCH 1702, который является логическим каналом. Сигнальное сообщение RRC, то есть DCCH 1702, может передаваться через объект MAC-MBMS 1713 (объект, манипулирующий MBMS) или объект MAC-c/sh 1715 (объект, манипулирующий общими и совместно используемыми каналами) в соответствии с решением CRNC, как показано на фиг.17. Контроллер CRNC 1711 может определить, будет ли он передавать данные MBMS на основе PtP или на основе PtM, но и в том, и в другом случае функционирование CRNC 1711 может быть разным. Если ожидаемое количество UE, которые собираются принимать услугу MBMS, в зоне обслуживания CRNC 1711 больше или равно заданному числу, то CRNC 1711 определяет, что данные MBMS необходимо передавать на основе PtM, а если это количество UE меньше указанного заданного числа, то CRNC 1711 определяет, что данные MBMS необходимо принимать на основе PtP. То есть CRNC 1711 определяет способ передачи данных, учитывая текущую ситуацию с сотой, для эффективного использования радиоресурсов. Однако в этом случае, даже если ситуация с сотой в CRNC такова, что данные MBMS следует передавать на основе PtM, когда конкретное UE переместилось при приеме услуги MBMS вместе с услугой передачи речи, то CRNC назначает этому конкретному UE выделенный канал на основе PtP и предоставляет услугу MBMS другим UE на основе PtM. Таким образом, в этом случае для одной и той же услуги имеются два способа, PtP и PtM, причем их подробное описание следует ниже.

Сначала будет описан способ передачи данных MBMS на основе PtP.

CRNC 1711 задает MAC-MBMS 1713 согласно соответствующим UE, когда он определил, что данные MBMS следует передавать на основе PtP в соответствующей соте. Заданный MAC-MBMS 1713 отображается в MAC-d 1703 на основе однозначного соответствия. То есть для одного UE контроллер SRNC 1701 формирует MAC-d 1703, а CRNC 1711 формирует MAC-MBMS 1713, причем сформированный MAC-d 1703 имеет однозначное соответствие со сформированным MAC-MBMS 1713. Следовательно, когда CRNC выбирает передачу по схеме PtP, в соответствующий MAC-MBMS 1713 через MAC-d 1703 доставляется сигнальное сообщение RRC, то есть DCCH 1702, и MAC-MBMS 1713 комбинирует соответствующий канал DCCH с каналом M-DTCH 1712, который представляет данные MBMS, и передает скомбинированные данные на соответствующее UE, используя DPCH. Когда трассы передачи назначают по отдельности соответствующим UE или транспортным каналам по Iur-интерфейсу между MAC-d 1703 и MAC-MBMS 1713, MAC-MBMS 1713 назначают трассу передачи к MAC-d 1703 на основе однозначного соответствия. Следовательно, MAC-MBMS 1713 непосредственно принимает данные MBMS, переданные от MAC-d 1703 через Iur-интерфейс. MAC-MBMS 1713 имеет функцию подсоединения данных MBMS (или M-DTCH 1712) для передачи сигнального сообщения каждого UE, принятого через Iur-интерфейс в соответствии с единицами UE, к одному объекту, так что узел В может передавать сигнальное сообщение с помощью одного физического канала. CRNC 1711 копирует данные MBMS, принятые от SGSN через Iu-интерфейс, согласно соответствующим MAC-MBMS и доставляет скопированные данные на MAC-MBMS 1713.

В результате C-плоскость для передачи сигнального сообщения (или DCCH 1702) может быть отделена от U-плоскости для передачи данных MBMS (или M-DTCH 1712). То есть C-плоскость использует существующую трассу через SRNC, а U-плоскость использует Iu-интерфейс к SGSN без прохождения через SRNC, непосредственно используя тем самым трассу через CRNC. MAC-MBMS 1713 комбинирует DCCH 1702 С-плоскости с М-DTCH 1712 U-плоскости, обеспечивая прохождение по разным трассам, и передает комбинированный сигнал на узел В, так что его можно передавать по каналу DPCH. В этот момент набор транспортных форматов данных, проходящих через DCCH 1702, и набор транспортных форматов данных, проходящих через M-DTCH 1712, могут быть независимыми друг от друга, причем комбинация транспортных форматов формируется путем комбинирования наборов транспортных форматов. В результате определяется индикация комбинации транспортных форматов (TFCI), и узел В может определить TFCI.

Далее описывается способ передачи контроллером CRNC данных MBMS на основе PtM.

Когда CRNC 1711 определяет, что необходимо передавать данные MBMS на основе PtM, MAC-MBMS 1713 не создается, а информация DCCH, переданная SRNC 1701, доставляется в MAC-c/sh 1715 через MAC-d 1703. Кроме того, CRNC 1711 принимает данные MBMS от SGSN, преобразует принятые данные MBMS в M-CTCH 1714 и передает M-CTCH 1714 через MAC-c/sh 1715. Здесь DCCH 1701 и M-CTCH 1714 для конкретного UE могут передаваться с использованием транспортного канала и физического канала соответственно, без мультиплексирования в MAC-c/sh 1715. Следовательно, UE отделяет FACH 1717 для передачи DCCH 1702 от FACH 1717 для передачи M-CTCH 1714, который представляет данные MBMS. Заметим, что даже в этом случае DCCH 1702 доставляется оборудованию UE через SRNC 1701, а данные MBMS доставляются от SGSN на UE через CRNC 1711. То есть U-плоскость и С-плоскость отделены друг от друга. В конкретном случае CRNC 1711 определяет, что данные MBMS следует передавать на основе PtM. Однако, когда SRNC 1701 намерен передавать DCCH 1702 соответствующему UE на основе PtP для передачи речи, SRNC 1701 может передавать DCCH 1702 и речевые данные по каналу DCH через MAC-MBMS 1713, используя MAC-d 1703 по фиг.17, и передавать данные MBMS (M-CTCH 1714) по каналу FACH 1717 через MAC-c/sh 1715. В этом случае MAC-MBMS 1713 просто имеет функцию доставки данных. Даже в этом случае CRNC может непосредственно доставить данные MBMS на UE без прохождения через MAC-d 1703.

Когда CRNC 1711 определяет необходимость передачи данных MBMS, принятых через Iu-интерфейс, на основе PtP или на основе PtM в соответствии с сотами или узлами В, контроллер CRNC 1711 может передавать данные MBMS на основе PtP путем задания MAC-MBMS 1713 либо непосредственно передавать M-CTCH 1714 через MAC-c/sh 1715. В этом случае может быть дополнительно установлен уровень для управления указанной функцией, и этот установленный уровень является более высоким, чем уровень MAC. Для этого может быть установлен уровень MBMS, который находится над уровнем управления линией радиосвязи (RLC), либо уровень PDCP, который находится выше уровня RLC. Уровень MBMS копирует данные в соответствии с тем, определены ли данные, принятые через Iu-интерфейс, для передачи на основе PtP или на основе PtM, в соответствии с соответствующими сотами и передает скопированные данные на уровень RLC по каналу M-DTCH 1712 или M-CTCH 1714, так что они доставляются соответственно в MAC-MBMS 1713 и MAC-c/sh 1715. Обмен информацией между SRNC 1701 и CRNC 1711 для формирования DCH 1716 и FACH 1717 осуществляется таким же образом, как было описано в связи с фигурами 8, 10, 11, 14А, 14В, 15 и 16. Как было описано выше, U-плоскость и С-плоскость для услуги MBMS имеют несколько доступных комбинаций в соответствии с состоянием UE и типом услуги MBMS для новой функции MAC по фиг.17, предложенной в изобретении, при этом доступные комбинации показаны в Таблице 6. Термин «состояние UE» относится к CELL_FACH или CELL_DCH.

Таблица 6
Состояние UE	Тип MBMS	Комбинация
CELL_DCH	PtP	Используется Iur-интерфейс между MAC-MBMS и MAC-d и M-DTCH.
CELL_DCH	PtP	Используется Iur-интерфейс между MAC-MBMS и MAC-d и M-CTCH.
CELL_FACH	PtM	Используется Iur-интерфейс между MAC-MBMS и MAC-c/sh и M-CTCH.
CELL_FACH	PtP	Используется Iur-интерфейс между MAC-MBMS и MAC-d и M-DTCH.

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

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

1. Способ предоставления услуги мультимедийного широковещания/мультивещания (MBMS) от обслуживающего узла (SGSN) поддержки общей услуги пакетной радиопередачи данных (GPRS) оборудованию пользователя (UE), когда оборудование пользователя перемещается во вторую соту, управляемую вторым контроллером радиосети (RNC), причем оборудование пользователя запрашивает разрешение на предоставление услуги MBMS в первой соте, управляемой первым RNC, в системе мобильной связи, предоставляющей услугу MBMS, при этом способ включает в себя этапы, на которых передают посредством первого RNC на второй RNC управляющую информацию, необходимую для предоставления услуги MBMS оборудованию пользователя, принимают посредством второго RNC управляющую информацию, определяют посредством второго RNC, предоставляется ли услуга MBMS, соответствующая управляющей информации, передают посредством второго RNC на первый RNC результат определения, передают посредством второго RNC на оборудование пользователя данные услуги MBMS в соответствии с результатом определения.

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

3. Способ по п.1, дополнительно включающий в себя этапы, на которых посылают посредством второго RNC запрос на услугу MBMS в обслуживающий узел (SGSN) поддержки общей услуги пакетной радиопередачи данных (GPRS), когда второй RNC не может предоставить услугу MBMS, посылают посредством узла SGSN второму RNC запрос на назначение радиоресурса для предоставления услуги MBMS в ответ на запрос услуги MBMS от второго RNC, назначают посредством второго RNC радиоресурс для предоставления услуги MBMS в ответ на запрос на назначение радиоресурса, уведомляют посредством второго RNC первый RNC о том, что второй RNC предоставляет услугу MBMS, после назначения радиоресурса.

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

5. Способ по п.3, дополнительно включающий в себя этапы, на которых посылают посредством оборудования пользователя запрос на закрытие услуги MBMS в узел SGSN после обнаружения запроса на закрытие услуги MBMS, посылают посредством узла SGSN в первый RNC запрос на закрытие услуги MBMS оборудованием пользователя в ответ на запрос оборудования пользователя на закрытие услуги MBMS и посылают посредством первого RNCво второй RNC запрос оборудования пользователя на закрытие услуги MBMS в ответ на запрос оборудования пользователя на закрытие услуги MBMS, чтобы второй RNC приостановил передачу данных услуги MBMS на оборудование пользователя.

6. Способ по п.5, дополнительно включающий в себя этапы, на которых приостанавливают посредством второго RNC передачу данных услуги MBMS на оборудование пользователя после приема от первого RNC запроса оборудования пользователя на закрытие услуги MBMS и посылают посредством второго RNC в узел SGSN запрос на закрытие услуги MBMS, когда нет другого оборудования пользователя, принимающего услугу MBMS во второй соте, после приостановления передачи данных услуги MBMS.

7. Способ по п.5, дополнительно включающий в себя этап, на котором обновляют посредством второго RNC контекст услуги MBMS путем включения в контекст услуги MBMS идентификатора оборудования пользователя, когда второй RNC может предоставлять услугу MBMS.

8. Способ по п.7, дополнительно включающий в себя этап, на котором обновляют контекст услуги MBMS путем удаления из контекста услуги MBMS идентификатора оборудования пользователя после приема от первого RNC запроса оборудования пользователя на закрытие услуги MBMS.

9. Устройство для предоставления услуги мультимедийного широковещания/мультивещания (MBMS) оборудованию пользователя (UE), когда оборудование пользователя перемещается во вторую соту, причем оборудование пользователя запрашивает разрешение принять услугу MBMS в первой соте, в системе мобильной связи, предоставляющей услугу MBMS, при этом устройство включает в себя первый RNC, который управляет первой сотой, для передачи управляющей информации, необходимой для предоставления услуги MBMS, оборудованию пользователя, запрашивающему данные услуги MBMS, и второй RNC, который управляет второй сотой, для приема управляющей информации от первого RNC, определения того, предоставляется ли услуга MBMS, соответствующая управляющей информации, уведомления первого RNC о результате определения и передачи на оборудование пользователя данных услуги MBMS в соответствии с результатом определения.

10. Способ предоставления услуги мультимедийного широковещания/мультивещания (MBMS) оборудованию пользователя (UE), когда оборудование пользователя перемещается во вторую соту, управляемую вторым контроллером радиосети (RNC), причем оборудование пользователя запрашивает разрешение принимать услугу MBMS в первой соте, управляемой первым RNC, в системе мобильной связи, предоставляющей услугу MBMS, при этом способ включает в себя этапы, на которых передают посредством первого RNC на второй RNC идентификатор оборудования пользователя, идентификатор услуги, оказывающий услугу MBMS, и информацию о радиоресурсе, настроенном в текущий момент для этого оборудования пользователя; принимают посредством второго RNC идентификатор оборудования пользователя, идентификатор услуги и информацию о радиоресурсе и уведомляют первый RNC о том, что второй RNC предоставляет услугу MBMS, когда второй RNC может предоставлять ту услугу MBMS, которая указана идентификатором услуги, и передают посредством второго RNC на оборудование пользователя данные услуги MBMS.

11. Способ по п.10, дополнительно включающий в себя этапы, на которых посылают посредством второго RNC запрос на услугу MBMS в обслуживающий узел (SGSN) поддержки общей услуги пакетной радиопередачи данных (GPRS), когда второй RNC не может предоставлять услугу MBMS, посылают посредством узла SGSN второму RNC запрос на назначение радиоресурса для предоставления услуги MBMS вместе с идентификатором услуги в ответ на запрос услуги MBMS от второго RNC; назначают посредством второго RNC радиоресурс для предоставления услуги MBMS в ответ на запрос на назначение радиоресурса, уведомляют посредством второго RNC первый RNC о том, что второй RNC предоставляет услугу MBMS, после назначения радиоресурса и передают посредством второго RNC на оборудование пользователя данные услуги MBMS.

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

13. Способ по п.11, дополнительно включающий в себя этапы, на которых посылают посредством оборудования пользователя запрос на закрытие услуги MBMS в узел SGSN после обнаружения запроса на закрытие услуги MBMS, посылают посредством узла SGSN на первый RNC запрос на закрытие услуги MBMS оборудованием пользователя в ответ на запрос оборудования пользователя на закрытие услуги MBMS и посылают посредством первого RNC на второй RNC запрос на закрытие услуги MBMS оборудованием пользователя в ответ на запрос оборудования пользователя на закрытие услуги MBMS, чтобы второй RNC приостановил передачу данных услуги MBMS на оборудование пользователя.

14. Способ по п.13, дополнительно включающий в себя этапы, на которых приостанавливают посредством второго RNC передачу данных услуги MBMS на оборудование пользователя после приема от первого RNC запроса оборудования пользователя на закрытие услуги MBMS и посылают посредством второго RNC в узел SGSN запрос на закрытие услуги MBMS, когда нет другого оборудования пользователя, принимающего эту услугу MBMS во второй соте, после приостановления передачи данных услуги MBMS.

15. Способ по п.13, дополнительно включающий в себя этап, на котором обновляют контекст услуги MBMS путем включения в контекст услуги MBMS идентификатора оборудования пользователя, когда второй RNC может предоставлять услугу MBMS.

16. Способ по п.15, дополнительно включающий в себя этап, на котором обновляют контекст услуги MBMS путем удаления из контекста услуги MBMS идентификатора оборудования пользователя после приема от первого RNC запроса оборудования пользователя на закрытие услуги MBMS.

17. Устройство для предоставления услуги мультимедийного широковещания/мультивещания (MBMS) оборудованию пользователя (UE), когда оборудование пользователя перемещается во вторую соту, причем оборудование пользователя запрашивает разрешение принять услугу MBMS в первой соте, в системе мобильной связи, предоставляющей услугу MBMS, при этом устройство включает в себя первый RNC, который управляет первой сотой, для передачи идентификатора оборудования пользователя, идентификатора услуги, указывающего запрашиваемую услугу MBMS, и информации о радиоресурсе, настроенном в текущий момент оборудованием пользователя; и второй RNC для приема идентификатора оборудования пользователя, идентификатора услуги и информации о радиоресурсе для уведомления первого RNC о том, что второй RNC предоставляет ту же самую услугу MBMS, и для передачи на оборудование пользователя данных услуги MBMS.