Идентификация результатов подсчета ue b embms

Идентификация результатов подсчета ue b embms

Иллюстрации

Показать все

Реферат

РОДСТВЕННЫЕ ЗАЯВКИ

Настоящая заявка испрашивает приоритет предварительной патентной заявки США № 61/513,024, поданной 29 июля 2011 г.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

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

Проект партнерства 3-го поколения (3GPP) разработал спецификации для поставки широковещательных многоадресных услуг мультимедиа (MBMS), которая предоставляет широковещательные и многоадресные услуги через беспроводные сети. MBMS может использоваться для услуг широковещательной передачи мобильного телевидения и радио услуг, а также для поставки файлов, экстренных уведомлений и тому подобного. В настоящее время разрабатываются спецификации для развитой MBMS, для развертывания с сетями на основе спецификаций 3GPP для развитого универсального наземного радиодоступа (E-UTRA), также известного как долгосрочное развитие (LTE).

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

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

Общее описание и требования верхнего уровня для MBMS даны в спецификации “3^rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Stage 1 (Release 10),” 3GPP TS 22.146, v 10.0.0, March 2011. Дополнительная спецификация “3^rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS) user services; Stage 1 (Release 10),” 3GPP TS 22.246, v 10.0.0, March 2011 описывает пользовательские услуги и требования к пользовательским услугам. Наконец более подробное описание архитектуры и функциональных возможностей системы MBMS дано в “3^rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 10),” 3GPP TS 23.246, v 10.1.0, June 2011.

Фиг. 1 иллюстрирует общую архитектуру части “развитой универсальной наземной сети радиодоступа” (E-UTRAN) сети 10 LTE. Сеть 10 включает в себя часть E-UTRAN 12 и развитого пакетного ядра 14 (или “базовой сети”) сети 10. E-UTRAN 12 включает в себя базовые станции (или “eNodeB”) 16, которые поддерживают беспроводную связь с одним или более пользовательскими оборудованиями (UE) 18. Более конкретно, eNodeB 16 обеспечивают оконечные элементы протокола плоскости пользователя (PDCP/RLC/MAC/PHY) E-UTRA и плоскости управления (RRC) по отношению к UE 18. eNodeB 16 взаимно соединены друг с другом с помощью интерфейса Х2. eNodeB 18 также соединены с ЕРС 14 с помощью интерфейса S1. Более конкретно, eNodeB 18 соединены с ММЕ (объектом управления мобильностью) посредством интерфейса S1-MME и с обслуживающим шлюзом (S-GW) посредством интерфейса S1-U. Интерфейс S1 поддерживает отношение “многие со многими” между MME/обслуживающими шлюзами и eNodeB. Несмотря на то, что один ссылочный номер 20 используется, чтобы идентифицировать MME и S-GW на фиг. 1, понятно, что они являются отдельными логическими объектами и, возможно, отдельными узлами сети, причем ММЕ устанавливает связь с eNodeB 18 с помощью интерфейса S1-MME, а S-GW устанавливает связь с eNodeB 18 с помощью интерфейса S1-U.

Стандарт TS 36.300 3GPP очень подробно описывает функции, выполняемые MME и S-GW. Фиг. 2 иллюстрирует некоторые из этих функциональных возможностей. В частности, фиг. 2 иллюстрирует функциональное разделение между E-UTRAN 12 и ЕРС 14. Как изображено на фиг. 2, eNodeB 18 выступает в роли ведущего следующих функций:

- функции для управления радио ресурсами: управление однонаправленными радиоканалом, управление радио допуском, управление мобильностью соединения, динамическое назначение ресурсов в UE, как в восходящей линии связи, так и в нисходящей линии связи (планирование);

- выбор ММЕ при подключении UE, когда никакая маршрутизация в MME не может быть определена из информации, предоставленной с помощью UE;

- маршрутизация данных плоскости пользователя по направлению к обслуживающему шлюзу;

- планирование и передача пейджинговых сообщений (берущих начало из ММЕ);

- планирование и передача широковещательной информации (берущей начало из ММЕ или O&M);

- измерение и конфигурирование сообщения измерения для мобильности и планирования; и

- планирование и передача сообщений PWS (которое включает в себя ETWS и CMAS) (берущих начало из ММЕ).

Кроме того, как дополнительно изображено на фиг. 2, ММЕ 22 выступает в роли ведущего следующих функций:

- сигнализация NAS;

- защита сигнализации NAS;

- управление защитой AS;

- сигнализация между узлами CN для мобильности между сетями доступа 3GPP;

- достижимость UE свободного режима (включая управление повторными пейджинговыми передачами и их выполнение)

- управление списком зоны отслеживания (для UE в свободном и активном режиме);

- выбор PDN GW и обслуживающего GW;

- выбор ММЕ для передач обслуживания с изменением ММЕ;

- выбор SGSN для передач обслуживания в сети доступа 2G или 3G 3GPP;

- роуминг;

- аутентификация;

- функции управления однонаправленным каналом, включая создание специализированного однонаправленного канала;

- поддержка для передачи сообщения PWS (которое включает в себя ETWS и CMAS); и

- выборочно оптимизации выполнения пейджинговых сообщений.

Фиг. 3 иллюстрирует логическую архитектуру eMBMS. Компоненты, специфические для MBMS, на фиг. 3 включают в себя объект многоячеечной/многоадресной координации (МСЕ) 24 и шлюз MBMS (GW MBMS) 26. МСЕ 24 является логическим объектом, который может быть автономным узлом сети или может быть частью другого узла сети (например, eNodeB 16 или ММЕ 22). MCE 24 обрабатывает управление допуском и назначение радио ресурсов, используемых всеми eNodeB 16 в зоне MBSFN для многоячеечных передач MBMS, с использованием операции MBSFN. MCE 24 принимает решение не создавать однонаправленный радиоканал (радиоканалы) новой услуги (услуг) MBMS, если радио ресурсы являются недостаточными для соответствующей услуги (услуг) MBMS, или может предварительно освобождать радио ресурсы из другого однонаправленного канала (каналов) текущей услуги (услуг) MBMS, в соответствии с ARP. Помимо назначения временных/частотных радио ресурсов, это также включает в себя принятие решения о дополнительных деталях конфигурации радиосвязи, например, схеме модуляции и кодирования. МСЕ 24 также выполняет следующие функции:

- подсчет и получение результатов подсчета для услуги (услуг) MBMS;

- возобновление сеанса (сеансов) MBMS в зоне (зонах) MBSFN на основе, например, ARP и/или результатов подсчета для соответствующей услуги (услуг) MBMS; и

- приостановка сеанса (сеансов) MBMS в зоне (зонах) MBSFN на основе, например, ARP и/или результатов подсчета для соответствующей услуги (услуг) MBMS.

МСЕ 24 занимается сигнализацией управления сеансом MBMS, но не выполняет сигнализацию UE-MCE. Когда МСЕ 24 является частью другого элемента сети, eNodeB 16 обслуживается одним МСЕ 24.

GW 26 MBMS также является логическим объектом. GW 26 MBMS может быть автономным узлом сети или может быть частью другого узла сети. GW 26 MBMS присутствует между центром широковещательных многоадресных услуг мультимедиа (MBMS) и eNodeB 12, принципиальными функциями которого является посылка/широковещательная передача пакетов MBMS в каждый eNodeB, передающий услугу. GW 26 MBMS использует многоадресную передачу IP в качестве средства передачи пользовательских данных MBMS в eNodeB. GW 26 MBMS выполняет сигнализацию управления сеансом MBMS (например, начало/остановку сеанса) по направлению к E-UTRAN с помощью ММЕ 22.

Фиг. 3 иллюстрирует интерфейсы М1, М2 и М3. В то время как М1 является интерфейсом плоскости пользователя между eNodeB 16 и GW 26 MBMS, интерфейсы М2 и М3 являются интерфейсами плоскости управления. МСЕ 24 и ММЕ 22 устанавливают связь с помощью интерфейса плоскости управления М3. Как описано в TS 36.300 3GPP, “прикладная часть определена для этого интерфейса между ММЕ и МСЕ. Эта прикладная часть предусматривает сигнализацию управления сеансом MBMS на уровне E-RAB (т.е. не передает данные конфигурации радиосвязи). Процедуры содержат, например, начало и окончание сеанса MBMS. SCTP используется в качестве транспортного протокола сигнализации, т.е. применяется сигнализация “точка-точка””.

eNodeB 16 и МСЕ 24 устанавливают связь с помощью интерфейса М2. Как описано в TS 36.300 3GPP, “прикладная часть определена для этого интерфейса, которая передает, по меньшей мере, данные конфигурации радиосвязи для сигнализации управления eNodeB и сеансом многоячеечного режима передачи. SCTP используется в качестве транспортного протокола сигнализации, т.е. применяется сигнализация “точка-точка””.

В eMBMS процедура подсчета используется, чтобы определять количество UE 18, которые заинтересованы в приеме услуги. Помимо прочего, это позволяет оператору системы принимать решение, должна ли услуга быть поставлена с использованием одночастотной сети MBMS (MBSFN), что заключает в себе передачу потока из множества синхронизированных во времени eNodeB 16, обслуживающих конкретную зону.

Процедура подсчета инициируется сетью 10 с помощью запроса, посланного в каждый eNodeB 16, содержащийся в области MBSFN, чтобы выполнить подсчет. Этот запрос, называемый “запрос подсчета услуг MBMS”, посылается с помощью МСЕ 24 в каждый eNodeB 16. Это инициирует eNodeB 16 послать запрос подсчета в их поддерживаемые UE 18 через многоадресный управляющий канал (МССН). UE 18, в свою очередь, отвечают их поддерживающим eNodeB 16 с помощью сообщений ответа подсчета управления радио ресурсами (RRC), которые идентифицируют услуги MBMS, представляющие интерес для UE 18.

Запрос подсчета услуг MBMS (или “запрос подсчета базовой станции”) посылается с помощью МСЕ 24 в eNodeB 16, чтобы запросить, чтобы eNodeB запросил число UE 18 соединенного режима, которые принимают или заинтересованы в приеме одной или более идентифицированных услуг MBMS. Запрос подсчета услуг MBMS в настоящее время определен в 3GPP TS 36.443, v 10.20 (June 2011). Как описано в этой спецификации, запрос подсчета услуг MBMS включает в себя следующее:

- тип сообщения;

- время обновления МССН;

- ID зоны MBSFN; и

- один или более идентификаторов TMGI (т.е. множество TMGI).

Время обновления MCCH (многоадресного управляющего канала) указывает период времени, в котором запрос должен считаться эффективным в МССН, передаваемом из eNodeB. “TMGI” - временный идентификатор группы мобильных устройств. TMGI используется, чтобы идентифицировать однонаправленные каналы услуг MBMS (т.е. отдельные услуги MBMS).

В ответ на запрос подсчета базовой станции eNodeB 16 посылает обратно сообщение результатов подсчета MBMS. Это сообщение посылается с помощью eNodeB 16 в МСЕ 24, чтобы сообщить число UE 18 соединенного режима, которые принимают или заинтересованы в приеме одной или более услуг MBMS, указанных в сообщении запроса подсчета услуг MBMS. Сообщение запроса подсчета услуг MBMS определено в 3GPP TS 36.443, v 10.20, как включающее в себя следующее:

- тип сообщения;

- ID зоны MBSFN; и

- список результатов подсчета MBMS (включающий в себя для каждой запрошенной услуги, TMGI, идентифицирующий услугу и результат подсчета).

Однако, согласно конфигурации сообщения в спецификациях 3GPP, обсужденных выше, имеется ряд проблем с сообщением результатов подсчета MBMS, так как имеются определенные сценарии, при которых непонятно в МСЕ, как обрабатывать результаты подсчета.

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

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

Также раскрыта соответствующая базовая станция, действующая с возможностью поддержки MBMS. Базовая станция включает в себя приемопередатчик и одну или более схем обработки, выполненных с возможностью: приема запроса подсчета базовой станции из MCE, включающего в себя идентификатор для каждой из одной или более услуг MBMS, а также включающего в себя время обновления; и передачи соответствующих запросов подсчета UE в UE, поддерживаемые базовой станцией, чтобы определить, принимают ли или желают ли принять UE одну или более услуг MBMS. Если никакие результаты подсчета не принимаются из поддерживаемых UE в определенном окне сообщения для одной или более идентифицированных услуг MBMS, приемопередатчик и одна или более схем обработки выполнены с возможностью передачи пустого списка идентификаторов услуг в МСЕ. Иначе, если результаты подсчета принимаются из поддерживаемых UE для одной или более идентифицированных услуг MBMS в определенном окне сообщения, приемопередатчик и одна или более схем обработки выполнены с возможностью передачи сообщения в МСЕ, которое включает в себя определенное количество UE для каждой из одной или более идентифицированных услуг, а также включает в себя время обновления из принятого запроса.

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

Также раскрыт соответствующий МСЕ, действующий с возможностью поддержки MBMS. МСЕ включает в себя приемопередатчик и одну или более схем обработки, выполненных с возможностью: передачи запроса подсчета базовой станции в базовую станцию в зоне обслуживания MBMS, причем запрос включает в себя время обновления и один или более идентификаторов услуг MBMS. Запрос подсчета базовой станции запрашивает, для каждой из идентифицированных услуг MBMS, количество UE, которые либо принимают, либо желают принять идентифицированную услугу MBMS. Приемопередатчик и одна или более схем обработки дополнительно выполнены с возможностью: приема сообщения подсчета из базовой станции, причем сообщение включает в себя время обновления, и определения, что сообщение подсчета соответствует запросу подсчета базовой станции, на основе времени обновления в сообщении подсчета, соответствующего времени обновления в запросе подсчета базовой станции. Любые данные подсчета, включенные в сообщение, которые соответствуют услугам, не идентифицированным в переданном запросе, игнорируются. Если сообщение включает в себя пустой список идентификаторов услуг, определяется, что базовая станция не принимала результаты подсчета из своих UE для одной или более идентифицированных услуг MBMS в определенном окне сообщения.

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

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

Фиг. 1 - части иллюстративной сети LTE.

Фиг. 2 - функциональное разделение между частью сети радиодоступа (E-UTRAN) и базовой сети LTE.

Фиг. 3 - интерфейсы М1, М2 и М3.

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

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

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

Фиг. 7 - иллюстративный способ сообщения результатов подсчета MBMS.

Фиг. 8 - иллюстративный способ обработки сообщенных результатов подсчета MBMS.

Фиг. 9А и фиг. 9В - иллюстративные конфигурации МСЕ.

Фиг. 10 - иллюстративный МСЕ.

Фиг. 11 - иллюстративная базовая станция.

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

Раскрыты способы и устройства, направленные на решение проблем с обработкой сообщения результатов подсчета MBMS предшествующего уровня техники. Первая такая проблема относится к приему, в МСЕ 24, ненужных результатов сообщения. Если сообщение сообщения результатов подсчета услуг MBMS для данной зоны MBMS содержит один или более TMGI, соответствующих конфигурации одного сообщения запроса подсчета услуг MBMS, и некоторые другие TMGI не являются частью этой конфигурации, стандарт TS 36.443 v 10.2.0 предлагает, что МСЕ 24 должен игнорировать результат, соответствующий этим другим TMGI. Однако в некоторых случаях в стандарте непонятно, как МСЕ 24 должен обнаруживать, какие TMGI принимать, а какие отвергать.

Это подчеркивается ниже в примере таблицы 1, которая включает в себя последовательность сообщений запроса подсчета услуг MBMS, посланных с помощью МСЕ 24. Каждая строка таблицы представляет запрос подсчета услуг MBMS (т.е. “запрос подсчета базовой станции”). Левый столбец изображает время обновления МССН, когда МСЕ 24 инициирует сообщение, а остальные три столбца изображают информацию, предоставленную в сообщении.

Предположим, что время обновления МССН=6, МСЕ 24 принимает сообщение ответа результатов подсчета услуг MBMS, содержащее следующие данные:

- ID зоны MBSFN=1

- TMGI=1; результат подсчета=3

- TMGI=2; результат подсчета=3

На основе этого сообщения МСЕ должен принять решение, должны ли быть игнорированы или нет результаты для TMGI=2. Двумя примерными интерпретациями являются: (1) МСЕ 24 должен игнорировать результат подсчета для TMGI=2, поскольку подсчет для TMGI=1 был запрошен и не был принят; или (2) МСЕ должен принять результат подсчета для TMGI=1 и TMGI=2, поскольку подсчет для обоих TMGI был запрошен. Однако непонятно, какой вариант выбрать, поскольку непонятно, какому конкретному запросу подсчета услуг MBMS соответствуют принятые результаты.

К этой проблеме можно обратиться с помощью добавления информационного элемента (IE) времени обновления МССН в сообщении результата подсчета услуг MBMS. Когда МСЕ 24 принимает свое переданное время обновления МССН, он определяет, какому запросу подсчета услуг MBMS соответствуют принятые результаты, и затем становится понятным, какие результаты, если они имеют место, должны быть игнорированы. Согласно этому соглашению, при времени обновления МССН=6 МСЕ 24 может принять сообщение ответа результатов подсчета услуг MBMS, включающее в себя следующие данные:

- ID зоны MBSFN=1

- время обновления МССН=5

- TMGI=1; результат подсчета =3

- TMGI=2; результат подсчета =3

Ссылаясь опять на таблицу 1, для времени обновления МССН=5 МСЕ запрашивал результаты подсчета для TMGI 1 и 2. Следовательно, после приема времени обновления МССН в результатах подсчета МСЕ узнает, чтобы принимать результаты подсчета для обоих TMGI=1 и TMGI=1.

Таблица 2 изображает возможные случаи для сценария, приведенного выше, когда различные времена обновления МССН вводятся в сообщения ответа. Значения для результатов подсчета не нужны для обсуждения и поэтому не включены в таблицу. В таблице 2 три столбца слева изображают информацию, принимаемую в сообщении сообщения результатов подсчет услуг MBMS, когда добавляется время обновления МССН. Столбец справа изображает результат, когда МСЕ 24 оценивает ненормальное условие

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

Другой проблемой с обработкой сообщения результатов подсчета MBMS предшествующего уровня техники является трактовка частичной или полной неудачи сообщения. Например, заявители допускают, что МСЕ 24 запросил подсчет для множества услуг, и eNodeB 16 ответил с помощью сообщения ответа подсчета услуг MBMS (подтверждения приема запроса подсчета базовой станции). Потом eNodeB 17 узнает, что он не может предоставить результаты подсчета для подмножества или полного множества TMGI, запрошенных МСЕ 24 в определенном окне сообщения (например, поскольку результаты подсчета не были приняты из поддерживаемых UE 18 для некоторых или всех из идентифицированных услуг). Как обсуждено ниже, это может дать в результате, что МСЕ 24 не принимает результаты подсчета и, таким образом, инициирует множество услуг, для которых имеется небольшой спрос или отсутствие спроса. Эта проблема подчеркнута на фиг. 4-фиг. 6. В обсуждении, приведенном ниже, T относится к минимальному периоду времени для передачи данных MBMS (смотри TS 36.444 3GPP, который определяет прикладной протокол М3), а T w a i t относится к периоду времени пока МСЕ 24 ожидает принять успешный результат подсчета (т.е. “окну сообщения”).

Фиг. 4 - блок-схема 100 последовательности этапов вызова, иллюстрирующая сценарий успешного подсчета MBMS. Ссылаясь на фиг. 4, МСЕ 24 принимает “запрос начала сеанса MBMS” из ММЕ 22, включающий в себя один или более TMGI, которые действуют как идентификаторы услуг, и минимальное время для периода времени T передачи данных MBMS, из ММЕ 22 (этап 302). МСЕ 24 отвечает успешно в ММЕ 22 с помощью “ответа начала сеанса MBMS” (этап 104). МСЕ 24 уведомляет, что T > T w a i t и посылает запрос подсчета услуг MBMS в eNodeB 16 (этап 106). eNodeB 24 подтверждает запрос подсчета (этап 108) и посылает “сообщение результатов подсчета услуг MBMS”, содержащее результат для запрошенного TMGI (множества TMGI) (этап 110), которое принимается МСЕ 24 через период времени T w a i t после 106. Затем МСЕ 24 использует данные результатов подсчета, чтобы принять решение об услуге (этап 112) (например, решение не начинать сеанс, если недостаточное количество UE 18 желают рассматриваемую услугу). Таким образом, в этом примере запрошенные результаты подсчета успешно принимаются.

Фиг. 5 - блок-схема 200 последовательности этапов вызова, иллюстрирующая сценарий неуспешного подсчета MBMS, в котором МСЕ 24 не принимает запрос подсчета услуг MBMS из eNodeB и, следовательно, не имеет достаточной информации, чтобы принять решение о сеансе услуги. Ссылаясь на фиг. 5, МСЕ 24 принимает сообщение запроса начала сеанса MBMS, содержащее TMGI и минимальное время для передачи данных MBMS, из ММЕ 22 (этап 202), и МСЕ 24 успешно отвечает с помощью ответа начала сеанса MBMS в ММЕ 22 (этап 204). МСЕ 24 уведомляет, что T > T w a i t и посылает запрос подсчета услуг MBMS в eNodeB 16 (этап 206), и eNodeB 24 подтверждает запрос подсчета (этап 208). eNodeB 16 обнаруживает, что он не может предоставить результат подсчета в МСЕ 24 (этап 210). Этап 210 может соответствовать определению с помощью eNodeB 14, что он не принял никакие данные подсчета для услуги, идентифицированной на этапе 202, в определенном окне сообщения (например, T w a i t ). Ввиду этого, eNodeB 16 не посылает “сообщение результатов подсчета услуг MBMS” (поскольку он должен иметь данные подсчета, по меньшей мере, для одного TMGI, чтобы послать такой ответ). Потом при отсутствии достаточной информации подсчета из eNodeB, чтобы определить, должна ли быть начата рассматриваемая услуга, МСЕ 24 принимает решение об услуге без результатов подсчета (этап 212). На основе этого решения МСЕ 24 может принять решение начать услугу без результатов (этап 214), а eNodeB 16 отвечает с помощью ответа начала сеанса MBMS (этап 216).

Чтобы решить эту проблему, eNodeB 16 может быть выполнен с возможностью передачи пустого списка идентификаторов услуг, если никакие результаты подсчета не принимаются из его поддерживаемых UE 18 для одной или более услуг MBMS, идентифицированных в первоначальном запросе (например, на этапе 102, 202). Это позволяет eNodeB предоставлять информацию в МСЕ 24, когда нет результатов подсчета, чтобы сообщить, с помощью разрешения пустого списка сообщаемых результатов подсчета MBMS.

Фиг. 6 иллюстрирует блок-схему 300 последовательности этапов для этого нового сценария. Ссылаясь на фиг. 6, МСЕ 24 принимает сообщение запроса начала сеанса MBMS, содержащее TMGI и минимальное время для передачи данных MBMS, из ММЕ 22 (этап 302), и МСЕ 24 успешно отвечает с помощью ответа начала сеанса MBMS в ММЕ 22 (этап 304). МСЕ 24 уведомляет, что T > T w a i t и посылает запрос подсчета услуг MBMS в eNodeB 16 (этап 306). eNodeB 24 подтверждает запрос подсчета (этап 308), обнаруживает, что он не может предоставить результат подсчета в МСЕ 24 (этап 310), а затем посылает сообщение ответа подсчета услуг MBMS с пустым списком TMGI в МСЕ 24 (этап 312). МСЕ 24 уведомляет, что T > T w a i t , и посылает другой запрос подсчета услуг MBMS в eNodeB 16 (этап 314). eNodeB 16 подтверждает запрос подсчета (этап 316), определяет, что теперь имеет данные подсчета, чтобы сообщить, и посылает сообщение результатов подсчета услуг MBMS, содержащее результат для запрошенного TMGI, в МСЕ 24, который принимается МСЕ 24 в окне сообщения T w a i t после этапа 314 (этап 318). На основе результата, принятого из eNodeB 16 на этапе 318, МСЕ 24 может принять решение не начинать сеанс (этап 320).

Фиг. 7 иллюстрирует способ 400 сообщения результатов подсчета MBMS. Способ 400 выполняется базовой станцией (например, eNodeB 16), которая выполнена для MBMS. В соответствии со способом, базовая станция 16 принимает запрос подсчета базовой станции из МСЕ 24, причем запрос включает в себя идентификатор для каждой из одной или более услуг MBMS, а также включает в себя время обновления (этап 402). Базовая станция 16 передает соответствующие запросы подсчета UE в UE 18, поддерживаемые базовой станцией, чтобы определить, принимают ли или желают ли принять UE 18 одну или более услуг MBMS (этап 404).

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

Как упомянуто выше, если никакие результаты подсчета не приняты для некоторых из одной или более идентифицированных услуг MBMS в определенном окне сообщения, базовая станция 16 передает пустой список идентификаторов услуг в МСЕ 24 (этап 408). Иначе, если результаты подсчета приняты из поддерживаемых UE 18 для одной или более идентифицированных услуг MBMS в определенном окне сообщения, базовая станция 16 передает сообщение в МСЕ 24 (этап 410), причем сообщение включает в себя определенное количество UE для каждой из одной или боле идентифицированных услуг, а также включает в себя время обновления из принятого запроса этапа 402.

Фиг. 8 иллюстрирует способ 500, выполняемый МСЕ 24, чтобы обрабатывать результаты подсчета MBMS. МСЕ 24 передает запрос подсчета базовой станции в базовую станцию (например, eNodeB 16) в зоне обслуживания MBMS (этап 502). Запрос этапа 502 включает в себя время обновления и один или более идентификаторов услуг MBMS. Запрос подсчета базовой станции этапа 502 запрашивает, для каждой из идентифицированных услуг MBMS, количество UE 18, которые либо принимают, либо желают принять идентифицированную услугу MBMS. МСЕ 24 принимает сообщение подсчета из базовой станции 16, которое включает в себя время обновления (этап 504). Выполняется проверка, чтобы определить, имеется ли соответствие между временем обновления принятого сообщения этапа 504 и переданным запросом подсчета этапа 502 (этап 506). Время обновления может быть, например, “временем обновления МССН”. Если нет соответствия (указывая, что принятые результаты не являются результатами, запрошенными на этапе 502), тогда МСЕ 24 ожидает запрошенные результаты.

Иначе, если времена обновления соответствуют, тогда выполняется проверка, чтобы понять, включает ли в себя принятое сообщение пустой список идентификаторов услуг (этап 508). Если принят пустой список идентификаторов, МСЕ 24 определяет, что базовая станция не приняла результаты подсчета из своих UE 18 в окне сообщения для одной или более услуг MBMS, идентифицированных в запросе подсчета (этап 510), и МСЕ может выборочно перейти опять на этап 502, чтобы передать другой запрос подсчета этапа 502.

Однако, если сообщение не включает в себя пустой список идентификаторов услуг, тогда выполняется проверка, чтобы понять, включает ли в себя сообщение результаты подсчета для услуг, не включенных в запрос подсчета (этап 512). Если никакие такие ненужные результаты не приняты, тогда МСЕ 24 обрабатывает результаты подсчета (этап 514). Иначе, если такие ненужные результаты приняты, тогда МСЕ 24 игнорирует их (этап 516), и они исключаются из обработки МСЕ 24 (этап 514). Таким образом, МСЕ 24 игнорирует любые данные подсчета, включенные в сообщение, которые соответствуют услугам, не идентифицированным в переданном запросе.

Чтобы осуществить способы 400, 500 “сообщение результатов подсчета услуг MBMS” обновляется с возможностью включения в него (1) времени обновления МССН, соответствующего времени обновления МССН, посланному в более раннем сообщении запроса подсчета услуг MBMS, и (2) пустого списка идентификаторов услуг, если eNodeB 16 еще не принял результаты подсчета для некоторых или всех из одной и более услуг, идентифицированных в запросе подсчета. Таким образом, информационный элемент времени обновления МССН, который был ранее послан в eNodeB в сообщении запроса подсчета услуг MBMS, должен быть включен в сообщение сообщения результатов подсчета услуг MBMS, возвращаемое в МСЕ 24. Включение времени обновления МССН в результаты сообщения позволяет МСЕ 24 точно определять, какие TMGI должны быть игнорированы, если имеют место. Также, предоставление возможности eNodeB 16 предоставлять информацию в МСЕ 24, даже когда нет результата подсчета, чтобы сообщить, дает возможность МСЕ 24 принимать лучшие решения об услугах.

Хотя варианты осуществления, обсужденные выше, включают в себя оба из этих признаков (т.е. включение времени обновления МССН в результаты подсчета и передачу пустого списка идентификаторов услуг), понятно, что в данный вариант осуществления может быть включен только один из этих признаков. Например, в одном варианте осуществления базовая станция (например, eNodeB 16) может быть выполнена с возможностью включения времени обновления МССН в свои результаты подсчета, но может быть не выполнена с возможностью передачи пустого списка идентификаторов услуг, если никакие результаты подсчета не приняты из поддерживаемых UE. Аналогично, в другом варианте осуществления базовая станция (например, eNodeB 16) может быть выполнена с возможностью передачи пустого списка идентификаторов услуг, если никакие результаты подсчета не приняты из поддерживаемых UE, но может быть не выполнена с возможностью передачи времени обновления МССН в сообщениях результатов подсчета, когда имеются результаты, чтобы сообщить. Таким образом, в некоторых примерных вариантах осуществления МСЕ 24 может быть аналогично выполнен с возможностью осуществления только одного из признаков, обсужденных выше (т.е. игнорирования не запрошенных результатов подсчета на основе времени обновления МССН, включенного в сообщение, и определения, что базовая станция еще не приняла результаты подсчета для одной или более услуг, если принят пустой список идентификаторов услуг). Специалистам в данной области техники должно быть понятно, что эти специфические варианты осуществления способов, приведенных выше, включают в себя системы, содержащие один или более ММЕ 22 и/или один или более eNodeB 16, причем эти системы выполнены с возможностью выполнения способов 400, 500 (или их отдельных частей, как обсуждено выше).

Как упомянуто выше, МСЕ 24 является логическим объектом и может быть осуществлен в нескольких физических конфигурациях. Например, МСЕ может быть расположен в автономном узле (смотри сеть 600А фиг. 9А), может быть осуществлен в том же узле, что и eNodeB 16 (см. сеть 600В фиг. 9В) или может быть осуществлен в том же узле, что и ММЕ 22. Однако при любой из этих конфигурациях МСЕ 24 и eNodeB 16 по-прежнему устанав