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

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

 

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

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

Предшествующий уровень техники

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

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

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

Обратимся к фиг.1, где центр услуг мультивещания/широковещания (MB-SC) 110 служит источником потока MBMS. Он планирует потоки MBMS и передает эти потоки в транзитную сеть (NW) 120. Транзитная сеть NW 120, расположенная между центром MB-SC 110 и обслуживающим узлом 130(SGSN) поддержки GPRS (услуга пакетной передачи данных по радиоканалу), пересылает принятые потоки MBMS в SGSN 130. Узел SGSN 130 может быть сконфигурирован вместе со шлюзовым узлом поддержки GPRS (GGSN) и внешней сетью. Здесь предполагается, что множество UE, состоящее из UE 1 161, UE 2 162, UE 3 163 в узле В 1 (то есть, сота 1) 160 и UE 4 171 и UE 5 172 в узле В 2 (то есть, сота 2) 170, должны принимать услугу MBMS. Узел SGSN 130 управляет услугами, относящимися к MBMS, для единиц UE, такими как управление данными о выписывании счетов, относящихся к MBMS, и избирательная передача данных по услуге MBMS в конкретный контроллер RNC 140. Для простоты узел В используется здесь для описания самой соты. Очевидно, что узел В управляет одной или несколькими сотами.

Узел SGSN избирательно передает данные по услуге MBMS в контроллер RNC 140, а RNC 140 избирательно передает данные по услуге MBMS в соты. Для избирательной передачи узел SGSN 130 должен знать, какие RNC должны принимать данные по услуге MBMS, включая RNC 140, а также какие соты должны принимать данные по услуге MBMS. Таким образом, контроллер RNC 140 может предоставить сотам услугу MBMS. RNC 140 управляет множеством сот, передает данные по услуге MBMS сотам, единицы UE которых запрашивают услугу MBMS, управляет радиоканалами, установленными для обеспечения услуги MBMS, и управляет информацией, относящейся к MBMS, используя потоки MBMS, принятые от узла SGSN 130. Как показано на фиг.1, один радиоканал устанавливается для услуги MBMS между узлом В и UE в зоне обслуживания узла В, например, между сотой 2 170 и единицами UE 171 и 172. Регистр местоположения собственных абонентов (HLR) (не показан) подсоединен к узлу SGSN 130 и аутентифицирует абонентов MBMS.

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

На фиг.2 представлена диаграмма, иллюстрирующая потоки сигналов для предоставления услуги MBMS между UE и сетью в системе мобильной связи.

Обратимся к фиг.2, где на этапе 201 (подписка) UE подписывается на услугу MBMS через базовую сеть (CN). Сеть CN включает в себя центр MB-SC, транзитную сеть NW и узел SGSN, как показано на фиг.1. Подписка - это процесс обмена базовой информацией, относящейся к выписыванию счетов за услуги MBMS или приему MBMS между поставщиком услуг и пользователем. Когда подписка завершена, сеть CN на этапе 202 (объявление) уведомляет единицы UE о доступных в данный момент услугах MBMS с помощью базовой информацией о них, например, информации меню. Информация меню содержит моменты времени и продолжительность предоставления услуг MBMS. Сеть CN выполняет широковещательную рассылку информации меню в виде общего объявления, например, с помощью CBS, либо передает ее только на те UE, которые запрашивают услуги MBMS. Сеть CN также уведомляет единицы UE об идентификаторах (ID) услуг, идентифицирующих соответствующие услуги MBMS с помощью информации меню.

После приема на этапе 202 информации меню UE выбирает намеченную услугу MBMS из информации меню и передает на этапе 203 (соединение) в сеть CN сообщение с запросом на эту услугу. Сообщение с запросом на услугу включает в себя ID выбранной услуги MBMS и ID данного UE. Затем сеть CN идентифицирует запрашиваемую услугу MBMS и устанавливает на этапе 204 (настройка однонаправленного радиоканала мультивещательного режима) однонаправленный радиоканал мультивещательного режима для данного UE. Во время настройки однонаправленного радиоканала мультивещательного режима транспортные однонаправленные радиоканалы можно настроить по сети CN заранее, то есть, между узлом SGSN и транзитной сетью NW. Например, между узлом SGSN и узлом GGSN можно заранее установить однонаправленный радиоканал GTP-U/UDP/IP/L2/L1 (смотри стандарт TS 23.060 проекта Партнерства в области систем связи Третьего Поколения (36РР)). Затем на этапе 205 (уведомление) сеть CN уведомляет UE о том, что вскоре начнется предоставление запрошенной услуги MBMS посредством уведомления типа сообщения поискового вызова. Поисковый вызов может быть выполнен обычным образом, либо оптимизированным способом поискового вызова для MBMS, описанным в патентной заявке Кореи №2002-34704, поданной тем же заявителем. Затем на этапе 206 (выделение радиоресурсов) оборудованию действительно выделяются радиоресурсы, необходимые для предоставления услуги MBMS, в ходе процедуры выделения радиоресурсов с помощью CN, и UE реализует выделенные радиоресурсы аппаратными средствами.

Выделение радиоресурсов выполняется в два этапа: этап, на котором RNC уведомляет единицы UE, находящиеся в произвольной соте, об информации относительно каналов RB, установленных для услуги MBMS в данной соте (здесь это называют настройкой однонаправленного радиоканала); и этап, на котором RNC передает сотам, имеющим единицы UE, которые запрашивали информацию об услугах MBMS, информацию о транспортных однонаправленных радиоканалах и однонаправленных радиоканалах, подлежащих настройке через lub - интерфейсы (интерфейс между узлом В и RNC) (здесь это называют настройкой радиосвязи). Настройка RB описывается ниже со ссылками на фиг.4. После завершения выделения радиоресурсов все UE, которые запрашивали услугу MBMS, информируются о линиях радиосвязи, по которым предоставляется услуга MBMS, и о более высоких уровнях, на которых обрабатывается услуга MBMS. Соты, в которых находятся эти единицы UE, окончательно устанавливают линии радиосвязи и lub - интерфейсы. Завершив подготовку для услуги MBMS между RNC и единицами UE, сеть CN передает на этапе 207 (пересылка данных) данные по услуге MBMS на единицы UE через контроллер RNC. На этапе 208 радиоресурсы, то есть транспортные однонаправленные радиоканалы и однонаправленные радиоканалы между единицами UE и CN, освобождаются после завершения передачи данных MBMS (освобождение радиоресурсов).

Этапы с 203 по 206, показанные на фиг.2, более подробно описываются со ссылками на фиг.3. Хотя сеть CN в общем относится к SGSN 130, транзитной сети NW 120 и центру MB-SC 110, далее в связи с работой RNC 140 рассматривается только узел SGSN 130.

На фиг.3 представлена диаграмма, подробно иллюстрирующая поток сигналов для этапов с 203 по 206, показанных на фиг.2.

Обратимся к фиг.3, где UE 161 после приема на этапе 202 базовой информации о конкретной услуге MBMS передает на этапе 301 в узел SGSN 130 в состоянии CELL_FACH (Сота_Прямой Канал Доступа) сообщение ACTIVATE MBMS PDP CONTEXT REQUEST (запрос на активизацию контекста протокола пакетной передачи данных MBMS). Здесь контекст протокола PDP (протокол пакетной передачи данных) включает в себя первичный контекст PDP и вторичный контекст PDP. Вторичный контекст PDP существует только в том случае, если существует первичный контекст PDP. Он имеет ту же информацию, что и первичный контекст PDP, но использует другой тоннель протокола туннелирования GPRS (протокол GTP для GPRS). GPRS - это услуга по пакетной передаче данных, развернутая в сети UMTS (универсальная система мобильной связи). Сообщение ACTIVATE MBMS PDP CONTEXT REQUEST включает в себя параметры NSAPI (идентификатор точки доступа к услугам на уровне сети), TI (указатель времени), тип PDP, адрес PDP, сеть точки доступа и QoS (качество обслуживания). Система мобильной связи создает тоннель GTP к узлу SGSN_130 в том случае, когда UE 161 запрашивает это (то есть, активизация, инициированная UE), или к сети CN в том случае, когда запрос идет от внешней сети (то есть, активизация по запросу сети).

После приема сообщения ACTIVATE MBMS PDP CONTEXT REQUEST узел SGSN 130 создает контекст PDP MBMS для услуги MBMS, если UE 161 является первым UE, которое запросило услугу MBMS, запоминает информацию о UE 161 в контексте PDP MBMS и выполняет заранее определенную операцию вместе с узлом GGSN, подсоединенным к узлу SGSN 130. Эта операция относится к туннелированию GTP. Когда узел SGSN 130 уведомляет узел GGSN о параметрах, установленных в сообщении ACTIVATE MBMS PDP CONTEXT REQUEST, узел GGSN настраивает на основе этих параметров туннель GTP. Контекст PDP MBMS представляет собой набор переменных, содержащих информацию об услуге MBMS. Он включает в себя список единиц UE, которые передали сообщение ACTIVATE MBMS PDP CONTEXT REQUEST, местоположения этих UE и транспортные однонаправленные радиоканалы, по которым передаются данные по услуге MBMS. Затем на шаге 302 узел SGSN 130 передает на UE 161 сообщение ACTIVATE MBMS PDP CONTEXT REQUEST ACCEPT (прием запроса на активизацию контекста PDP MBMS). Это сообщение содержит TMGI (временный идентификатор группы мультивещания) для групповой передачи сообщений поискового вызова в связи с услугой MBMS и структуру данных DRX (прерывистый прием). DRX относится к циклу, в котором UE 161 отслеживает канал индикатора поискового вызова (PICH). DRX содержит коэффициент длины цикла (CL) DRX и Np. Np представляет количество случаев поискового вызова (PI) в одном системном кадре и задается как системная информация (SI). Его значение берется из набора [18, 36, 72, 144].

Использование TMGI и DRX раскрыто в патентной заявке Кореи №2002-34704, поданной тем же заявителем. После приема сообщения ACTIVATE MBMS PDP CONTEXT REQUEST ACCEPT, UE 161 переходит в состояние незанятости. Между тем, узел SGSN 130 передает сообщение NOTIFICATION (уведомление) в контроллер RNC 140, которому принадлежит UE 161, когда услуга MBMS готова к запуску или когда узел SGSN 130 принимает на этапе 303 первые данные по услуге MBMS из центра MB-SC 110. Поскольку узел SGSN 130 запоминает список единиц UE, запросивших услугу MBMS, и контроллеров RNC, которым они принадлежат, SGSN 130 передает сообщение NOTIFICATION в контроллеры RNC, когда инициирована услуга MBMS. Сообщение NOTIFICATION содержит TMGI и DRX.

После приема сообщения NOTIFICATION контроллер RNC 140 выполняет этап 304. В частности, RNC 140 рассчитывает удобный момент для выполнения поискового вызова (PO) и PI, используя TMGI и DRX. Таким же образом UE 161 вычисляет PO и PI, используя TMGI и DRX, содержащиеся в сообщении ACTIVATE MBMS PDP CONTEXT REQUEST ACCEPT. Контроллер RNC 140 информирует UE 161 о том, будет ли приниматься канал поискового вызова (PCH) путем установки PICH в состояние "включено" или "выключено" в момент времени, указанный параметрами PI и PO. Если PICH находится в состоянии "включено" в соответствии с параметром PI параметра PO, то UE 161 принимает сигнал PCH и определяет, что ему послан поисковый вызов. В противном случае, если PICH находится в состоянии "выключено", UE 161 не принимает PCH. Между тем, если для UE 161 выполнен поисковый вызов, то RNC 140 передает на UE 161 сообщение NOTIFICATION, либо сообщение поискового вызова по каналу PCH, связанному с PICH, в заданное время после передачи PICH, так что UE 161 может быть проинформировано о том, что вскоре будет запущена услуга MBMS, либо будет принято сообщение NOTIFICATION или сообщение поискового вызова. Сообщение NOTIFICATION - это тип сообщения поискового вызова, которое содержит информацию о типе сообщения, причине поискового вызова и TMGI. Причина поискового вызова указывает основание для поискового вызова связи. В современной системе мобильной связи широкополосного МДКР (W-CDMA) в качестве причины поискового вызова для MBMS выступает так называемое «завершение потокового вызова». Кроме существующей причины поискового вызова может быть определена новая причина поискового вызова для MBMS. Для простоты сообщение NOTIFICATION или сообщение поискового вызова далее называют «сообщением поискового вызова MBMS».

Тем временем UE 161 отслеживает PICH в соответствии с параметром PI из состава PO. UE 161 принимает сообщение поискового вызова MBMS по соответствующему каналу PCH, если PICH находится в состоянии "включено", и не принимает его, если PICH находится в состоянии "выключено". Когда в PI параметра PO установлена '1', это означает, что PICH находится в состоянии "включено". С другой стороны, когда в PI параметра PO установлен '0', это значит, что PICH находится в состоянии "выключено". После приема сообщения поискового вызова MBMS UE 161 определяет, какая услуга MBMS будет инициирована, на основе TMGI, содержащегося в сообщении поискового вызова MBMS. Если TMGI указывает на услугу MBMS, которую запрашивало оборудование UE 161, то UE 161 будет ждать приема данных по соответствующей услуге MBMS.

После приема сообщения поискового вызова MBMS оборудование UE 161 переходит в состояние CELL_FACH и передает в узел SGSN 130 сообщение NOTIFICATION RESPONSE (ответ на уведомление), указывающее о нормальном приеме сообщения NOTIFICATION на этапе 305. Узел SGSN 130 передает на этапе 306 в RNC 140 сообщение MBMS RAB ASSIGNMENT REQUEST (запрос на назначение однонаправленного канала радиодоступа для MBMS). Сообщение MBMS RAB ASSIGNMENT REQUEST может содержать параметр QoS и список единиц UE, для которых должен быть установлен RAB (однонаправленный канал радиодоступа) MBMS. Хотя описание сосредоточено на UE 161, если множество UE запрашивает услугу MBMS, то в RNC 140 доставляется сообщение MBMS RAB ASSIGNMENT REQUEST, включающее список единиц UE. Затем RNC 140 выполняет предварительно установленную операцию, необходимую для предоставления услуги MBMS для множества UE. RAB представляет собой набор ресурсов для передачи, сконфигурированных в RNC для предоставления услуги MBMS. В частности, RAB включает в себя транспортный однонаправленный радиоканал через lub-интерфейс между узлом SGSN 130 и RNC 140, транспортный однонаправленный радиоканал через lub-интерфейсе между RNC 140 и узлом В 160, и радиоканалы.

RNC 140 определяет информацию RB MBMS об услуге MBMS в связи с сообщением MBMS RAB ASSIGNMENT REQUEST. Информация RB MBMS охватывает информацию уровня 2 (L2) и информацию уровня 1 (L1). Информация L2 может представлять собой информацию, относящуюся к RLC/PDCP (протокол управления радиоканалом/протокол конвергенции пакетных данных). Информация L1 может включать в себя информацию о наборе транспортных форматов (TFS), наборе комбинаций транспортных форматов (TFCS), каналообразующий код и мощность передачи. Контроллер RNC 140 определяет соты, для которых установлен RAB MBMS в соответствии со списком единиц UE. Поскольку RNC 140 воспринимает местоположения единиц UE в состоянии CELL_FACH по сотам, RNC 140 может преобразовать список единиц UE в список сот. Таким образом, RNC 140 передает сообщение MBMS RB SETUP (настройка однонаправленного радиоканала MBMS) в отдельные соты в количестве, равном количеству сот.

На этапе 307 RNC 140 передает на UE 161 сообщение MBMS RB SETUP. Затем UE 161 настраивает RB MBMS в соответствии с информацией RB MBMS и передает на этапе 308 сообщение MBMS RB SETUP COMPLETE (завершение настройки MBMS RB) в RNC 140. На этапе 309 RNC 140 передает в узел SGSN 130 сообщение MBMS RAB ASSIGNMENT RESPONSE (ответ на выделение RAB MBMS). Затем SGSN 130 на этапе 207 начинает передачу данных по услуге MBMS на UE 161.

Сообщения NOTIFICATION и MBMS RB SETUP, показанные на фиг.3, являются групповыми сообщениями. Групповое сообщение определяется как сообщение, передаваемое на множество UE. То есть, на этапе 304 единицы UE решают, должны ли они принимать сообщение NOTIFICATION по каналу PICH, относящемуся к одному и тому же PI одного и того же параметра PO. Поскольку TMGI указывает единицам UE о необходимости приема сообщения NOTIFICATION, единицы UE могут принимать это сообщение. Также на единицы UE по прямому каналу доступа (FACH) передается сообщение MBMS RB SETUP с введенным в него TMGI.

На фиг.4 более подробно показаны этапы 307 и 308, изображенные на фиг.3. Перед описанием фиг.4 следует учесть, что RNC 140 управляет сотами 160 и 170, и здесь предполагается, что n единиц UE, включая UE 161 и 162 в соте 160, запрашивают одну и ту же услугу MBMS. Также следует отметить, что одинаковые ссылочные позиции обозначают идентичные этапы, показанные на фиг.3.

Обратимся к фиг.4, где RNC 140 принимает на этапе 306 сообщение MBMS RAB ASSIGNMENT REQUEST от узла SGSN 130. Затем на этапе 401 RNC 140 выполняет широковещательную рассылку сообщения MBMS RB SETUP на n единиц UE. Сообщение MBMS RB SETUP содержит информацию MBMS RB и индикатор состояния RRC (управления радиоресурсами). Индикатор состояния RRC устанавливают для индикации перехода в состояние CELL_PCH (Сота_Канал Поискового Вызова) в случае завершения передачи управляющих сообщений между RNC 140 и n единицами UE (индикатор состояния RRC=CELL_PCH). Сообщение MBMS RB SETUP передают в соты по каналу FACH, и, следовательно, единицы UE в состоянии CELL_FACH могут принимать сообщение MBMS RB SETUP. Таким образом, сообщение MBMS RB SETUP предназначено для предоставления общей информации RB MBMS в пределах одной соты. Следовательно, общая передача сообщения MBMS RB SETUP на единицы UE в пределах их соты предпочтительна для передачи сообщения MBMS RB SETUP на отдельные UE. Таким образом, использование канала широковещания, определенного как канал FACH, позволяет обеспечить широковещательную рассылку сообщения MBMS RB SETUP.

Каждая из n единиц UE на этапах с 402-1 по 402-n передает сообщение MBMS RB SETUP COMPLETE на RNC 140 и переходит в состояние CELL_PCH, поскольку индикатор состояния RRC=CELL_PCH.

Между тем, RNC 140 передает на этапе 309 в узел SGSN 130 сообщение MBMS RAB ASSIGNMENT RESPONSE в ответ на сообщение MBMS RAB ASSIGNMENT REQUEST.

В вышеописанной процедуре каждая из единиц UE может передавать по каналу произвольного доступа (RACH) сообщение MBMS RB SETUP COMPLETE. Однако из-за ограниченной пропускной способности канала RACH, если множество UE попытается одновременно передавать сообщение MBMS RB SETUP COMPLETE, то системные рабочие характеристики могут серьезно ухудшиться. Как показано на фиг.4, поскольку каждая единица UE передает сообщение MBMS RB SETUP COMPLETE, когда этап 401 практически завершен, можно сказать, что единицы UE передают сообщение MBMS RB SETUP COMPLETE одновременно. Возникающая при этом перегрузка трафика сообщений MBMS RB SETUP COMPLETE приводит к ухудшению рабочих характеристик системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

фиг.3 - схема, подробно иллюстрирующая поток сигналов для этапов с 203 по 206, показанных на фиг.2;

фиг.4 - схема, подробно иллюстрирующая поток сигналов для этапов 307 и 308, показанных на фиг.3;

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

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

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

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

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

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

фиг.11 - пример передачи CTCH (совмещенного транспортного канала) согласно второму варианту настоящего изобретения;

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

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

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

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

Настоящее изобретение обеспечивает способы, позволяющие единицам UE, которые приняли групповое управляющее сообщение (например, MBMS RB SETUP), необходимое для предоставления услуги MBMS, не передавать ответное сообщение (например, MBMS RB SETUP COMPLETE) на принятое сообщение, что решает проблемы, возникающие в случае отсутствия приема ответного сообщения. Эти способы направлены на предотвращение ухудшения рабочих характеристик системы, которое может возникнуть, когда множество UE одновременно передают ответное сообщение на групповое управляющее сообщение, как было описано выше. В действительности, перегрузка, являющаяся результатом одновременной передачи ответного сообщения, затрудняет оценку состояний единиц UE для приема услуги MBMS. Кроме того, если единицы UE, принимающее услугу MBMS, невозможно отличить от единиц UE, не принимающих услугу MBMS, могут возникнуть серьезные проблемы, когда выписывание счетов выполняется одновременно с инициированием услуги MBMS. Следовательно, настоящее изобретение пытается бороться с проблемами, возникающими в результате перегрузки из-за ответных сообщений от множества UE.

Групповое сообщение определено как единое сообщение RRC, которое обычно передается сетью на множество UE. Контроллер RNC предоставляет информацию RB MBMS для единиц UE, которые запрашивают прием конкретной услуги MBMS, с помощью группового сообщения MBMS RB SETUP. Другим примером группового сообщения является сообщение MBMS RB SETUP COMPLETE. Это сообщение используется контроллером RNC, чтобы подтвердить, что единицы UE нормально приняли информацию RB MBMS стандартным образом. Обычно, если UE не передает ответное сообщение, то RNC предпринимает необходимые меры, такие как повторная передача сообщения MBMS RB SETUP COMPLETE на это UE, полагая, что данное UE не приняло информацию RB MBMS. Однако, согласно варианту осуществления настоящего изобретения информацию RB MBMS передают периодически, так что единицы UE, хотя они и не приняли сообщение MBMS RB SETUP, могут принимать информацию RB MBMS. Согласно другому варианту осуществления настоящего изобретения RNC передает информацию о выполняющихся в данный момент услугах MBMS, предоставляемых на сотовой основе единицам UE конкретной соты, так что эти UE, хотя они и не принимали сообщения MBMS RB SETUP, могут запросить у RNC информацию RB MBMS о намеченных ими услугах MBMS, которые в данный момент выполняются.

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

1. Первый вариант осуществления

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

1.1 Сигнализация

На фиг.5 представлена схема, иллюстрирующая поток сигналов для процедуры настройки RB MBMS согласно первому варианту осуществления настоящего изобретения. На фиг.5 все сообщения, направленные от RNC 140 на единицы UE, доставляются с помощью групповой сигнализации. Групповая сигнализация относится к схеме передачи сигналов, где RNC 140 обычно передает информацию на множество UE или сот с помощью единого сообщения, как было описано выше.

Обратимся к фиг.5, где RNC 140 на этапе 501 принимает сообщение MBMS RAB ASSIGNMENT REQUEST от узла SGSN 130. Сообщение MBMS RAB ASSIGNMENT REQUEST вдобавок к TMGI, DRX, QoS и списку единиц UE для конкретной услуги MBMS содержит время повторения (R_T). Затем RNC 140 вычисляет PO и PI на основе TMGI и DRX, определяет соты, для которых согласно списку единиц UE должны быть установлены каналы RB MBMS, и определяет параметры RB MBMS в соответствии с QoS. Другими словами, RNC 140 определяет соты для приема услуги MBMS в соответствии с местоположениями UE, запрашивающими услугу MBMS, и определяет соответствующую информацию RB MBMS. На этапах 503, 504 и 505 контроллер RNC 140 передает информацию RB MBMS на единицы UE.

RNC 140 устанавливает PICH в состояние «включено» или «выключено» в момент, указанный параметрами PI и PO, чтобы указать, должны ли UE принимать PCH, то есть, сообщение поискового вызова. После передачи PICH контроллер RNC 140 активизирует таймер повторения для контроля времени повторения, установленного в сообщении MBMS RAB ASSIGNMENT REQUEST. Активизация этого таймера может происходить до или после передачи PICH.

Единицы UE также вычисляют PO и PI исходя из TMGI и DRX, установленных в сообщении ACTIVATE MBMS PDP CONTEXT ACCEPT. На этапе 503 единицы UE принимают PICH и проверяют, находится ли PICH в состоянии "включено" или "выключено" в момент времени, указанный PI параметра PO. Единицы UE определяют, будут ли они принимать сообщение поискового вызова по каналу PCH в соответствии с результатом проверки. То есть, если PICH находится в состоянии "включено" в PI параметра PO, то UE, соответствующее PI параметра PO, определяет, что оно будет принимать сообщение поискового вызова. В противном случае, UE, соответствующее состоянию "выключено" PI параметра PO, не принимает PCH.

Между тем, если для конкретных UE должен быть выполнен поисковый вызов, то RNC 140 передает на этапе 504 на эти UE сообщение поискового вызова по соответствующему каналу PCH в заданное время после передачи PICH для уведомления этих UE о том, что они вскоре получат услугу MBMS. Сообщение поискового вызова вместо идентификаторов ID упомянутых UE содержит групповой ID, такой как TMGI или ID услуги.

Зная, что они будут принимать сообщение поискового вызова, UE принимают его на этапе 504. Они определяют, выполняется ли для них поисковый вызов для конкретной услуги MBMS. Если TMGI или ID услуги идентичен ID намеченной услуге MBMS, то UE переходят в состояние CELL_FACH для приема данных по услуге MBMS по каналу FACH.

На этапе 505 RNC передает на единицы UE по каналу FACH сообщение MBMS RB SETUP. Здесь определенные параметры RB MBMS вводятся в сообщение MBMS RB SETUP. Затем единицы UE устанавливают каналы RB, необходимые для услуги MBMS. В частности, UE устанавливают уровни L2/L1 в соответствии с информацией RB MBMS, включенной в сообщение MBMS RB SETUP, и принимают затем данные услуги MBMS через каналы RB MBMS.

Может получиться, что некоторые из единиц UE не сумели принять сообщение MBMS RB SETUP по каналу FACH. Причиной этого является неспособность определить, что PI находится в состоянии "включено", либо плохое состояние линии радиосвязи. Единицы UE не передают сообщений, указывающих о срыве приема. Кроме того, они ожидают приема сообщения MBMS RB SETUP, непрерывно отслеживая PI параметра PO по каналу PICH, который передается многократно и периодически. Однако позднее эти UE могут принимать услугу MBMS.

RNC 140 может передать сообщение MBMS RAB ASSIGNMENT RESPONSE в узел SGSN 130 во время этапов 503, 504 и 505, либо после передачи сообщения MBMS RB SETUP по каналу FACH. Сообщение MBMS RAB ASSIGNMENT RESPONSE уведомляет SGSN 130 об успешной настройке запрошенного RAB MBMS. В настоящем изобретении, поскольку единицы UE не передают ответные сообщения на сообщение MBMS RB SETUP, контроллер RNC 140 не может определить, был ли успешно установлен RAB MBMS. Кроме того, RNC 140 считает установку MBMS RAB успешной, когда он полностью передал сообщение MBMS RB SETUP, и на этапе 502 передает в узел SGSN 130 сообщение MBMS RAB ASSIGNMENT RESPONSE (ответ на запрос на назначение RAB MBMS).

Затем контроллер RNC 140 проверяет состояние таймера повторения, чтобы определить, истекло ли время повторения. Окончание времени повторения объявляется, когда таймер повторения устанавливается в нулевое состояние. После истечения времени повторения RNC 140 вновь запускает таймер повторения и повторно передает FACH для доставки PICH, PCH и сообщения MBMS RB SETUP на этапах 506, 507 и 508 таким же образом, как и на этапах 503, 504 и 505. Что касается этапов 506, 507 и 508, то единицы UE действуют таким же образом, как было описано выше. После каждого момента истечения таймера контроллер RNC 140 вновь запускает таймер и повторно передает FACH, как, опять же, показано на этапах 509, 510 и 511.

1.2. Работа UE

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

Перед описанием фиг.6 сначала будут описаны переходы из состояния в состояние для UE. CELL_PCH - это состояние, в котором UE настраивает только PICH без установки выделенных каналов, и принимает сигнал PICH. Если сигнал PICH указывает, что это UE в состоянии CELL_PCH будет принимать сообщение поискового вызова по каналу PCH, то это UE принимает сигнал PCH. CELL_FACH - это состояние, в котором UE настраивает канал FACH без установки выделенных каналов, принимает управляющие сообщения по каналу FACH и работает соответствующим образом. После приема PCH в состоянии CELL_PCH UE переходит в состояние CELL_FACH.

Обратимся к фиг 6, где после приема TNGI и DRX с помощью сообщения ACTIVATE MBMS PDP CONTEXT ACCEPT оборудование UE на этапе 601 вычисляет PO и PI, используя TMGI и DRX. Затем на шаге 602 UE непрерывно отслеживает PI в составе PO по каналу PICH, принимаемому от контроллера RNC 140, и на этапе 603 определяет, находится ли PI в состоянии "включено". Если PI находится в состоянии "выключено", то UE возвращается к этапу 602. В противном случае, если PI находится в состоянии "включено", то UE переходит к этапу 604.

На этапе 604 UE принимает соответствующий PCH от RNC 140. PCH передается от RNC 140 через заданное время после передачи PI, установленного в состояние «включено». Затем на этапе 605 UE определяет, совпадает ли TMGI или ID услуги, установленный в сообщении поискового вызова, с TMGI или ID услуги, указывающим намеченную услугу MBMS. Если они отличаются, то UE непрерывно отслеживает PICH, который периодически передается от RNC 140. Если они идентичны, то UE переходит к этапу 606.

На этапе 606 UE переходит в состояние CELL_FACH и принимает по каналу FACH данные от RNC 140. Затем UE устанавливает уровни L2 и L1 в соответствии с информацией RB MBMS, включенной в сообщение MBMS RB SETUP, принятое по каналу FACH на шаге 607, а на этапе 608 принимает через RB MBMS данные по услуге MBMS от RNC 140.

Хотя на фиг.6 не показана работа UE в случае неудачного приема сообщения MBMS RB SETUP по каналу FACH, в этом случае UE возвращается к этапу 603. После приема повторно переданного PICH от RNC 140 оборудование UE повторяет вышеописанную процедуру.

1.3. Работа RNC

На фиг.7 представлена блок-схема алгоритма, иллюстрирующая операцию управления RNC 140 согласно первому варианту осуществления настоящего изобретения.

Обратимся к фиг.7, где после приема на этапе 701 сообщения MBMS RAB ASSIGNMENT REQUEST контроллер RNC 140 на этапе 702 вычисляет PO и PI, используя TMGI и DRX, установленные в принятом сообщении. На этапе 703 RNC 140 определяет соты, для которых должны быть установлены каналы RB MBMS в соответствии с QoS и списком единиц UE, включенными в данное сообщение, и задает информацию RB MBMS для отдельных сот.

На этапе 704 контроллер RNC 140 запускает таймер повторения для контроля времени повторения, установленного узлом SGSN 130 в сообщении MBMS RAB ASSIGNMENT REQUEST. Время повторения контролируется для периодического выполнения групповой сигнализации для настройки RB MBMS вместо приема ответного сообщения от единиц UE.

На этапе 705 контроллер RNC 140 выполняет последовательность операций для передачи PICH, PCH и сообщения MBMS RB SETUP по каналу FACH. PICH устанавливается в состояние «включено» в PI параметра PO, а по каналу PCH доставляется сообщение поискового вызова, включающее в себя TMGI. Сообщение MBMS RB SETUP, передаваемое по каналу FACH, включает в себя определенную информацию RB MBMS.

На этапе 706 контроллер RNC 140 проверяет, истекло ли время повторной передачи. Это подразумевает обнуление таймера повторения. Либо таймер повторения может быть установлен таким образом, чтобы указывать заданное значение после истечения заданного времени. После окончания времени повторения контроллер RNC 140 возвращается к этапу 704 для повторного запуска таймера повторения и переходит к этапу 705 для повторной передачи PICH, PCH и сообщения MBMS RB SETUP. Узел SGSN 140 определяет повторение в соответствии с типом услуги MBMS. Поскольку время повторения является переменной величиной, зависящей от различных ситуаций, оно в настоящем изобретении явно не оговорено. Тем не менее, время повторения должно быть больше, чем временной интервал между передачей PICH и передачей FACH для сообщения MBMS RB SETUP, и меньше длительности услуги MBMS. Хотя это на фиг.7 не показано, RNC 140 передает на единицы UE данные по услуге MBMS с помощью успешно установленных каналов RB MBMS, повторно передавая PICH, PCH и FACH. Между тем, RNC 140 на этапе 707 непрерывно определяет, не закончилось ли предоставление услуги MBMS. Если предоставление услуги MBMS завершено, то повторная передача на этапах 704, 705 и 706 не требуется.

Как было описано выше, PICH, PCH и FACH передаются периодически на этапах с 704 по 707 в соответствии с заданным временем повторения согласно первому варианту осуществления настоящего изобретения.

2. Второй вариант осуществления

RNC 140 периодически передает на единицы UE соты информацию CBS, указывающую на то, выполняются или нет в текущий момент запрошенные отдельные услуги MBMS. Если UE обнаруживает в этой информации выполняющуюся в данный момент услугу, которая была запрошена этим UE, но не принята, оно индивидуально запрашивает у RNC 140 информацию RB MBMS о данной услуге MBMS. Таким образом, услуги MBMS могут предоставляться без необходимости передачи ответного сообщения на сообщение MBMS RB SETUP от единиц UE, запрашивающих услуги MBMS.

2.1. Сигнализация

На фиг.8 представлена диаграмма, иллюстрирующая поток сигналов для процедуры настройки RB MBMS, чтобы предоставить услугу MBMS согласно второму варианту осуществления настоящего изобретения. На фиг.8 начальные сообщения, относящиеся к настройке RB и направляемые от RNC 140 на единицы UE, доставляются посредством групповой сигнализации. Групповая сигнализация относится к передаче единого сообщения от RNC 140 на множество объектов (например, единиц UE или сот). Однако повторно передаваемые сообщения, связанные с настройкой RB, доставляются на единицы UE посредством индивидуальной сигнализации. Индивидуальная сигнализация относится к сигнализации между RNC 140 и отдельным UE. Здесь «единицы UE» обозначают единицы UE, запрашивающие услугу MBMS в одной и той же соте. Единицы UE уже завершили процедуру запроса услуги MBMS, состоящую в передаче сообщения ACTIVATE MBMS PDP CONTEXT REQUEST и приеме сообщения ACTIVATE MBMS PDP CONTEXT REQUEST ACCEPT.

Обратимся к фиг.8, где этапы с 501 по 505 выполняются таким же образом, как показано на фиг.5, для настройки каналов RB MBMS. Поэтому их описание здесь не приводится.

После настройки каналов RB MBMS единицы UE и узел SGSN 130 передают/принимают на шаге 207 данные по услуге MBMS через указанные каналы RB MBMS.

С другой стороны, другая сигнализация предлагается для тех UE, которым не удалось настроить RB MBMS. Помимо пересылки данных MBMS RNC 140 сначала на этапах 801, 805 и 806 выполняет широковещательную рассылку сообщения MBMS STATUS (состояние MBMS) с помощью CBS. Сообщение MBMS STATUS передается на сотовой основе. Это сообщение указывает единицам UE одной и той же соты, какие услуги MBMS выполняются в данный момент.

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

Что касается подробностей работы UE, то UE запоминает ID запрошенной им услуги MBMS в переменной MBMS_SERVICE_JOINED. Если UE на этапе 505 нормально принимает сообщение MBMS RB SETUP и начинает принимать услугу MBMS, оно удаляет из указанной переменной идентификатор ID этой услуги и взамен запоминает ID этой услуги в переменной MBMS_SERVICE_ONGOING. Вместе с одним или несколькими идентификаторами ID услуг, сохраненных в MBMS_SERVICE_ONGOING, UE принимает с помощью CBS сообщение MBMS STATUS и сравнивает идентификатор ID услуги, сохраненный в MBMS_SERVICE_JOINED, с идентификаторами услуг, установленными в принятом сообщении. Если в сообщении обнаружен ID услуги такой же, как MBMS_SERVICE_JOINED, то UE передает на этапе 802 сообщение с запросом на повторную передачу информации об однонаправленном радиоканале MBMS (MBMS RB info RTX REQ) на RNC 140 путем индивидуальной сигнализации. Сообщение MBMS RB info RTX REQ содержит тип сообщения, ID UE и ID услуги.

После приема сообщения MBMS RB info RTX REQ контроллер RNC 140 проверяет ID услуги в этом сообщении и создает сообщение MBMS RB SETUP, содержащее информацию RB MBMS об услуге MBMS, соответствующей ID услуги. RNC 140 на этапе 803 передает по каналу FACH сообщение MBMS RB SETUP на данное UE. Поскольку сообщение MBMS RB SETUP передается на UE посредством индивидуальной сигнализации, оно не достигнет других UE. При индивидуальной сигнализации RNC 140 устанавливает идентификатор ID, уникальный для данного UE, RNTI (временный идентификатор радиосети), в сообщении MBMS RB SETUP. Согласно второму варианту осуществления настоящего изобретения RNC 140 не принимает ответные сообщения для информации RB MBMS от единиц UE. Вместо этого он непрерывно предоставляет информацию о выполняющихся в данный момент услугах MBMS и определяет исходя из сообщений CBS, принятых от единиц UE, приняли ли они текущую информацию RB MBMS. Если UE не удалось принять информацию RB MBMS, то оно запрашивает RB MBMS от RNC 140. Затем RNC 140 передает информацию RB MBMS только на запрашивающее UE. Хотя в данном варианте осуществления настоящего изобретения UE обнаруживает, удалось ему или нет принять информацию RB MBMS, посредством информации о выполняющихся в данный момент услугах MBMS, очевидно, что могут быть рассмотрены и другие способы.

После приема от RNC 140 сообщения MBMS RB SETUP оборудование UE в ответ на принятое сообщение передает на RNC сообщение MBMS RB SETUP COMPLETE. Поскольку сообщение MBMS RB SETUP COMPLETE доставляется по каналу RACH, оно содержит RNTI для UE. Индивидуальная сигнализация противоположна групповой сигнализации. Она реализуется между одним передатчиком и одним приемником. Сообщение MBMS RB SETUP является примером групповой сигнализации, поскольку один передатчик отправляет сообщение на множество UE.

Предложенное во втором варианте осуществления новое сообщение MBMS STATUS повторяется многократно на этапах 801, 805 и 806 в соответствии с расписанием CBS. Расписание CBS известно единицам UE благодаря сообщению с расписанием CBS, что позволяет единицам UE принимать сообщение MBMS STATUS на основе информации, содержащейся в сообщении с расписанием CBS.

Между тем, если любая услуга MBMS завершается, то освобождаются радиоресурсы, выделенные для этой услуги MBMS. RNC 140 предоставляет на этапе 806 информацию о выполняющихся в данный момент услугах MBMS за исключением завершенной услуги MBMS с помощью сообщения MBMS STATUS.

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

2.2 Определение новых сообщений

2.2.1 Сообщение с расписанием

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

Обратимся к фиг.9, где сообщение с расписанием предоставляет информацию о расписании передач сообщения MBMS STATUS на сотовой основе. Сообщение с расписанием доставляется на единицы UE каждой соты. То есть, RNC создает сообщение с расписанием для каждой соты и транслирует его в эту соту. Сообщение с расписанием содержит информацию о данных, подлежащих передаче в течение одного периода планирования. Период планирования состоит из множества блочных наборов совмещенного транспортного канала (CTCH). Размер блочного набора CTCH задается числом радиокадров. Сообщение с расписанием является сигналом высокого уровня и совместно используется единицами UE и контроллером RNC.

На фиг.11 показан пример передачи блочных наборов CTCH в течение одного периода планирования вместе с сообщением с расписанием.

Обратимся к фиг.11, где один период 1106 планирования содержит блочные наборы CTCH в количестве, равном длине периода 904 планирования CBS, установленного в сообщении 1101 с расписанием. Начальная точка периода планирования 1106 отстоит от сообщения 1101 с расписанием на величину сдвига для начального индекса блочного набора CTCH (903). Описания сообщений с 906 по 907 на фиг.9 описывают блочные наборы CTCH. Описания сообщений находятся во взаимно однозначном соответствии с блочными наборами CTCH. Описания сообщений включают в себя информацию о типах описания сообщений для блочных наборов CTCH. Типы описаний сообщений задаются заранее установленными значениями. В настоящем изобретении тип описания сообщения MBMS STATUS определяется в виде неиспользуемого числа «9». Сдвиг на начальный индекс блочного набора CTCH (903) составляет 8 битов и указывает значение между 1 и 255. Длина периода планирования CBS (904) также равна 8 битам и указывает значение между 1 и 255.

После приема сообщения 1101 с расписанием, единицы UE, поддерживающие второй вариант осуществления настоящего изобретения, определяют начальную и конечную точки периода планирования, используя сдвиг 903 и длину 904 периода планирования CBS, и обнаруживают блочный набор CTCH с типом описания сообщения, установленным на 9, используя описания сообщений с 906 по 907. Таким образом, единицы UE могут избирательно принимать блочный набор CTCH с типом описания сообщения, установленным на 9.

Для более краткого описания структуры сообщения 1101 с расписанием тип сообщения задан равным 2. Битовая карта 905 нового сообщения указывает, является ли каждый блочный набор CTCH новым либо старым сообщением. Размер битовой карты 905 нового сообщения является переменной величиной, зависящей от количества блочных наборов CTCH в одном периоде планирования. Например, если в битовой карте блочный набор CTCH установлен равным 0, то этот блочный набор CTCH доставляет старое сообщение, а если он установлен равным 1, то значит, он доставляет новое сообщение. Как показано на фиг.11, единицы UE обнаруживают блочный набор CTCH, который доставляет сообщение MBMS STATUS, из сообщения 1101 с расписанием и избирательно принимает этот блочный набор CTCH.

2.2.2 Сообщение MBMS STATUS

На фиг.10 показана структура сообщения MBMS STATUS, необходимого для реализации второго варианта осуществления настоящего изобретения. Показанное сообщение имеет такую же структуру, как типовое сообщение CBS.

Обратимся к фиг.10, где тип 1051 сообщения может быть установлен равным неиспользуемому значению 4. ID 1052 сообщения идентифицирует конкретное сообщение CBS. Обычно UE идентифицирует сообщение CBS посредством идентификатора 1052 сообщения. Однако, поскольку UE идентифицирует сообщение MBMS STATUS по типу 1051 сообщения, идентификатор ID 1052 сообщения является в действительности неэффективным в настоящем изобретении. Контроллер RNC устанавливает ID 1052 сообщения равным неиспользуемому значению до передачи сообщения MBMS STATUS, а UE запоминает значение ID сообщения.

Порядковый номер 1053 состоит из 16 битов, указывающих, является ли сообщение обновленной версией либо нет. Здесь идентичным сообщением считают сообщение CBS, имеющее тот же самый ID сообщения. В настоящем изобретении порядковый номер 1053 изменяется при модификации содержания сообщения MBMS STATUS, когда услуга MBMS добавляется на этапах 805 и 806 по фиг.8 в соответствующую соту либо убирается из этой соты.

Схема 1054 кодирования данных указывает язык, используемый для полезной нагрузки сообщения CBS, как определено в стандарте TS 23.081 3GPP. В настоящем изобретении схема 1054 кодирования данных не имеет значения. Однако для совместимости с существующей технологией схема 1054 кодирования данных устанавливается на значение, которое не используется в TS 23.081 3GPP.

Данные 1055 сообщения MBMS STATUS являются полезной нагрузкой сообщения MBMS STATUS. Они содержат идентификаторы с 1056 по 1058 услуг, используемых в данный момент для данной соты. Если в качестве идентификаторов услуг используются адреса IPV6, то размер полей составляет 128 битов.

2.3 Работа UE

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

Обратимся к фиг.12, где после запроса услуги MBMS оборудование UE очищает на этапе 1201 переменную MBMS_SERVICE_JOINED. Если в этой переменной запоминается по меньшей мере один идентификатор услуги путем ее обновления на этапе 1202, то UE на этапе 1203 отслеживает канал S-CCPCH (дополнительный совмещенный физический канал управления), обслуживающий CBS, с использованием системной информации, предоставляемой на сотовой основе. После приема сообщений CBS по указанному каналу UE проверяет типы сообщений CBS. Если обнаружено сообщение CBS с типом сообщения, установленным на 2, то UE на этапе 1204 оценивает период планирования, как показано на фигурах 8 и 9, и на этапе 1205 определяет, существует ли сообщение MBMS STATUS в периоде планирования. Решение зависит от того, имеет ли сообщение с расписанием описание сообщения с типом описания сообщения, установленным на 9. При наличии сообщения MBMS STATUS оборудование UE принимает на этапе 1206 сообщение MBMS STATUS в блочном наборе CTCH, соответствующем описанию сообщения. При отсутствии сообщения MBMS STATUS оборудование UE возвращается к этапу 1203 и ожидает приема следующего сообщения с расписанием.

Между тем, UE определяет на этапе 1207, имеет ли сообщение MBMS STATUS идентификатор ID услуги, сохраненный в переменной MBMS_SERVICE_JOINED. Если это так, то UE определяет, что оно не смогло принять сообщение MBMS RB SETUP для запрошенной им услуги MBMS от RNC 140. Затем на этапе 1208 UE передает сообщение MBMS RB info RTX REQ на RNC 140, запрашивая сообщение MBMS RB SETUP. Сообщение MBMS RB info RTX REQ может быть доставлено по выделенному каналу управления (DCCH), при этом оно содержит ID намеченной услуги MBMS и RNTI для данного UE. На этапе 1209 UE принимает повторно переданное сообщение MBMS RB SETUP от RNC 140. UE устанавливает уровни в соответствии с информацией RB MBMS, заданной в принятом на этапе 1210 сообщении. После подготовки к приему данных по услуге MBMS оборудование UE начинает прием данных по услуге MBMS. Сообщение MBMS RB SETUP доставляется посредством индивидуальной сигнализации на этапе 1209.

Как только услуга MBMS инициирована, UE удаляет ID этой услуги MBMS из переменной MBMS_SERVICE_JOINED и определяет на этапе 1211, пуста ли переменная MBMS_SERVICE_JOINED. Если она не пуста, то UE возвращается к этапу 1203 и повторяет вышеописанную процедуру. В противном случае, если переменная MBMS_SERVICE_JOINED пуста, то UE возвращается к этапу 1201 и ждет, пока в MBMS_SERVICE_JOINED не добавится новый ID услуги.

4. Работа RNC

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

Обратимся к фиг.13, где RNC запоминает в переменной MBMS_STATUS_DATA идентификаторы ID выполняющихся в данный момент услуг MBMS в соте. Если RNC передает на этапе 1301 сообщение MBMS RAB ASSIGNMENT RESPONSE для новой услуги MBMS, либо на этапе 1302 передает сообщение MBMS RAB RELEASE (высвобождение RAB MBMS), указывающее на завершение конкретной выполняющейся услуги MBMS, то RNC на этапе 1303 обновляет MBMS_STATUS_DATA с помощью идентификаторов ID инициированных или завершенных услуг MBMS.

Затем RNC на этапе 1304 планирует сообщения CBS, подлежащие передаче в течение следующего периода планирования, на сотовой основе и определяет на этапе 1305, передавать ли сообщение MBMS STATUS в течение указанного периода планирования. Если сообщение MBMS STATUS должно быть передано, то RNC переходит к этапу 1306. В противном случае он переходит к этапу 1304. На этапе 1304 контроллер RNC ждет окончания планирования для следующего периода планирования.

С другой стороны, RNC на этапе 1306 устанавливает тип описания сообщения, соответствующий блочному набору CTCH, доставляющему сообщение MBMS STATUS, на 9 и передает на этапе 1307 сообщение с расписанием.

RNC устанавливает на этапе 1308 тип сообщения на 4 для сообщения MBMS STATUS, а на этапе 1309 устанавливает ID сообщения на заранее заданное значение для этого сообщения. На этапе 1310 RNC устанавливает соответствующий порядковый номер, а на этапе 1311 вводит идентификаторы услуг ID, сохраненные в MBMS_STATUS_DATA, в данные MBMS STATUS. Если на этапе 1311 данные MBMS STATUS отличаются от ранее переданных данных, то RNC устанавливает другое значение порядкового номера, отличное от предыдущего порядкового номера, а если они идентичны, то RNC на этапе 1310 устанавливает значение порядкового номера равным предыдущему порядковому номеру.

Контроллер RNC 140 на этапе 1312 передает сообщение MBMS STATUS и возвращается к этапу 1304.

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

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

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

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

3. Способ по п.2, в котором уведомляют множество UE в соте о запланированном цикле с помощью услуги сотового широковещания (CBS) на сотовой основе.

4. Способ по п.1, в котором управляющую информацию для услуги передают с помощью услуги сотового широковещания (CBS) на сотовой основе.

5. Способ по п.1, в котором управляющую информацию для услуги широковещания запрашивают с помощью сообщения с запросом на повторную передачу информации об однонаправленном радиоканале, содержащего тип сообщения, идентификатор (ID) UE и ID услуги широковещания.

6. Способ по п.1, в котором управляющая информация для услуги широковещания содержит временный ID радиосети (RNTI).

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

8. Способ по п.7, в котором управляющую информацию для услуги передают с помощью услуги сотового широковещания (CBS) на сотовой основе.

9. Способ по п.7, в котором управляющую информацию для услуги широковещания запрашивают с помощью сообщения с запросом на повторную передачу информации об однонаправленном радиоканале, содержащего тип сообщения, идентификатор (ID) UE и ID услуги широковещания.

10. Способ по п.7, в котором управляющая информация для услуги широковещания содержит временный ID радиосети (RNTI).

11. Способ по п.7, в котором завершенную услугу широковещания исключают из управляющей информации для услуги.

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

13. Способ по п.12, в котором информацию об однонаправленном радиоканале передают периодически с целью поддержки мобильности по меньшей мере одного UE.

14. Способ по п.12, в котором информацию об однонаправленном радиоканале определяют посредством RNC в соответствии с параметрами однонаправленного радиоканала услуги пакетной передачи данных.

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

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

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