Управление обработкой отказов однонаправленных mbms-каналов на основе хвостовой части

Управление обработкой отказов однонаправленных mbms-каналов на основе хвостовой части

Иллюстрации

Показать все

Реферат

Перекрестные ссылки на родственные заявки

[0001] Данная заявка притязает на приоритет ранее поданной предварительной заявки на патент (США) номер 61/951472, озаглавленной "Tail End MBMS Bearer fault Management" и поданной 11 марта 2014 года, содержимое которой содержится в данном документе по ссылке.

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

[0002] Данное раскрытие сущности, в общем, относится к услуге широковещательной и многоадресной передачи мультимедиа (MBMS), и, в частности, настоящее раскрытие сущности относится к системам и способам для обнаружения, указания, локализации и исправления отказов однонаправленных MBMS-каналов.

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

[0003] Услуга широковещательной и многоадресной передачи мультимедиа (MBMS) представляет собой широковещательную услугу, предложенную через сотовые сети, включающие в себя широкополосный множественный доступ с кодовым разделением каналов (WCDMA) и стандарт долгосрочного развития (LTE). MBMS представляет собой услугу "точка-многоточка" или многоадресную услугу, в которой данные передаются из одного исходного объекта в несколько целевых получателей. MBMS-услуга может использоваться как для загрузки файлов, так и для услуг потоковой передачи, таких как мобильное телевидение. Усовершенствованная MBMS (eMBMS) используется для того, чтобы обозначать MBMS-услугу в усовершенствованных системах с пакетной коммутацией, включающих в себя усовершенствованную наземную сеть радиодоступа UMTS (E-UTRAN) или стандарт долгосрочного развития (LTE). В настоящем раскрытии сущности, термин "MBMS" используется, в общем, чтобы означать одну или обе из MBMS- и eMBMS-услуг.

[0004] Сетевая MBMS-архитектура, функции узла, архитектура протоколов плоскости управления и архитектура протоколов пользовательской плоскости задаются в документе "E-UTRAN overall description", 3GPP TS 36.300 ("TS 36.300"), который полностью содержится в данном документе по ссылке. На фиг. 1 проиллюстрирован примерный вариант осуществления этой архитектуры, который показывает MBMS-развертывание в LTE-сети с распределенной архитектурой объекта координации многосотовой/многоадресной передачи (MCE), в которой MCE распределяется и совместно размещается с каждым E-UTRAN узлом B (eNB).

[0005] Центр 100 широковещательных и многоадресных услуг (BM-SC) инициирует MBMS-сеанс, с использованием контента, по меньшей мере, из одного поставщика 102 контента. BM-SC подключается к компонентам пользовательской плоскости 104 (UP) и плоскости 106 управления (CP), по меньшей мере, одного MBMS-шлюза 108 (MBMS GW) посредством SGi-mb UP-интерфейса 110 и SGmb CP-интерфейса 112, соответственно. CP-компонент 106 MBMS-GW 108 подключается к объекту 114 управления мобильностью (MME) по Sm CP-интерфейсу 116.

[0006] Интерфейсы SGi-mb 110, SGmb 112 и Sm 116 работают по одноадресной сети на основе Интернет-протокола (IP) (IPv4 или IPv6).

[0007] В некоторых примерных вариантах осуществления, BM-SC 100 может подключаться к шлюзу 118 сети передачи данных общего пользования (PDN) посредством SGi-интерфейса 120.

[0008] MME 114 обменивается данными с MCE 122a/122b в eNB 124a/124b по M3 CP-интерфейсу 126a/126b. Два eNB 124a/124b показаны в сети в примерных целях. UP-компонент 104 MBMS-GW 108 обменивается данными с MCE 122a/122b по M1-интерфейсу 128a/128b. Протокол прикладного уровня E-UTRAN M3 описывается в документе 3GPP TS 36.444 ("TS 36.444"), который полностью содержится в данном документе по ссылке.

[0009] CP-интерфейсы представляют собой интерфейсы SGmb 112, Sm 116 и M3 126a/126b. CP-интерфейсы не переносят пользовательские данные, но отвечают за процедуры передачи служебных сигналов, чтобы устанавливать или завершать MBMS-сеансы по одноадресным IP-сетям (IPv4 или IPv6).

[0010] UP-интерфейсы представляют собой интерфейсы SGi-mb 110 и M1 128a/128b. M1-интерфейс 128a/128b отвечает за установление состояний протоколов прослушивания многоадресной передачи и независимой от протокола многоадресной передачи (PIM), а также связанного дерева распространения по кратчайшим путям, переносящего пользовательские MBMS-данные и данные синхронизации.

[0011] Каждый eNB 124a/124b может быть соединен по E-UTRAN Uu-интерфейсу 130, по меньшей мере, с одним абонентским устройством 132 (UE). Одно UE 132 показано в примерных целях.

[0012] Фиг. 2 иллюстрирует вариант осуществления альтернативного примера MBMS-развертывания в LTE-сети, в которой MCE не размещается совместно с каждым eNB, а вместо этого представляет собой автономный компонент или необязательно часть другого сетевого элемента (не показан), что приводит к централизованной MCE-архитектуре.

[0013] В варианте осуществления по фиг. 2, централизованный MCE 134 обменивается данными с MME 114 по M3 CP-интерфейсу 126c, в то время как MCE 134 обменивается данными с каждым eNB 124a/124b по M2 CP-интерфейсу 136a/136b. Протокол прикладного уровня E-UTRAN M2, описанный в документе 3GPP TS 36.443 ("TS 36.443"), который полностью содержится в данном документе по ссылке, также не переносит пользовательские данные и работает на основе одноадресных IP-сетей (IPv4 или IPv6).

[0014] Аналогично фиг. 1, UP-компонент 104 MBMS-GW 108 обменивается данными с каждым eNB 124a/124b по M1 UP-интерфейсу 128a/128b.

[0015] Фиг. 3 иллюстрирует примерный вариант осуществления трафика данных (пользовательской плоскости) через примерные варианты осуществления, показанные на фиг. 1 и 2. MBMS-пакеты инкапсулируются в протокольных единицах данных (PDU) по протоколу MBMS-синхронизации (SYNC), описанных в документе "MBMS Synchronization Protocol (SYNC)", 3GPP TS 25.446 ("TS 25.446"), который полностью содержится в данном документе по ссылке.

[0016] Один SYNC-экземпляр 140 поддерживается в расчете на однонаправленный MBMS-канал. SYNC-протокол завершается в eNB 124a, который отвечает за передачу MBMS-пакета 142 по Uu-интерфейсу 130 в UE 132.

[0017] MBMS-GW 108 выделяет пользовательский туннель 144 по протоколу GPRS-туннелирования (GTP) (GTP-U) для каждого однонаправленного MBMS-канала. Протокол туннелирования GTP-U описывается в документе "GPRS Tunneling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 ("TS 29.281"), который полностью содержится в данном документе по ссылке. В некоторых примерных вариантах осуществления, в eNB 124a, сокет, используемый для завершения всех многоадресных GTP-туннелей, представляет собой UDP-порт 2152.

[0018] Однонаправленный MBMS-канал работает по многоадресной IP-сети 146 с использованием конкретного для источника многоадресного (SSM) канала, описанного в документе "An Overview of Source-Specific Multicast", IETF RFC 3569 ("RFC 3569"), который полностью содержится в данном документе по ссылке, причем источник SSM-канала представляет собой MBMS-GW 108. Каждый SSM-канал представляет собой дерево однонаправленного распространения по кратчайшим путям из конкретного исходного IP-адреса. Каждый SSM-канал уникально идентифицируется, в некоторых примерных вариантах осуществления, посредством комбинации целевого SSM-адреса G (многоадресного IPv4-адреса в диапазоне 232/8 или многоадресного IPv6-адреса с префиксным FF3x::/32) и исходного IP-адреса S (IPv4- или IPv6-адреса для одноадресной передачи, принадлежащего MBMS-GW). SSM-канал состоит из PIM-маршрутизаторов с использованием протокола на основе разреженного PIM-режима (SM) (PIM-SM), описанного в документе "Protocol Independent Multicast - Sparse Mode", IETF RFC 4601 ("RFC 4601"), который полностью содержится в данном документе по ссылке.

[0019] ENB 124a запрашивает интерес в приеме многоадресных IP-пакетов для конкретного SSM-канала. Соответственно, eNB124a считается приемным или прослушивающим SSM-устройством. Он использует протокол управления Интернет-группами (IGMP) версия 3 (IGMPv3) или протокол обнаружения прослушивающих устройств многоадресной передачи (MLD) версия 2 (MLDv2), чтобы обмениваться данными с PIM-маршрутизаторами. IGMPv3-протокол описывается в документе "Internet Group Management Protocol Version 3 (IGMPv3)", IETF RFC 3810 ("RFC 3810"), который полностью содержится в данном документе по ссылке, а MLDv2-протокол описывается в документе "Multicast Listener Discovery Version 2 (MLDv2)", IETF RFC 3810 ("RFC 3810"), который полностью содержится в данном документе по ссылке.

[0020] Однонаправленный MBMS-канал может быть локальным, региональным или национальным по дальности и может охватывать более тысячи eNB и значительно большее число UE, подключенных к этим eNB.

[0021] Отсутствие отслеживания подключений в пользовательской плоскости и индикатора отказа между eNB и BM-SC может непосредственно затрагивать развертывание MBMS-услуг в сетях мобильных операторов вследствие проблем с ухудшением производительности и потенциальными дырами в покрытии предоставления многоадресных услуг. Любая линия связи, узел, состояние многоадресной передачи или сбой перенаправления в обратном тракте (RPF) в многоадресной IP-сети потенциально могут вызывать необнаруженное прерывание предоставления MBMS-услуг.

[0022] Операторы пытаются разрешать эти проблемы посредством добавления избыточности в многоадресную IP-сеть, в случае экономической целесообразности, с тем чтобы повторно маршрутизировать трафик при конкретных и известных сценариях сбоев. Тем не менее, такие схемы резервирования по принципу избыточности являются дорогими и не могут предусматривать все возможные случаи возникновения сбоев, в частности, таких сбоев, которые не могут быть легко обнаруживаемыми на физическом (канальном) уровне.

[0023] Технические требования 3GPP не предусматривают способы для системы, чтобы обнаруживать потерю подключения по M1-интерфейсу пользовательской плоскости или потерю непрерывности предоставления услуг по однонаправленному MBMS-каналу для конкретного eNB.

[0024] SYNC- и GTP-U-протоколы не предоставляют механизмы обнаружения отказов для многоадресных однонаправленных каналов. Например, TS 29.281 предусматривает то, что сообщения управления двунаправленным GTP-U-трактом, такие как, в качестве неограничивающего примера, эхо-запрос и/или эхо-ответ, не должны использоваться для многоадресного MBMS IP-распространения.

[0025] В любом случае, существующие двунаправленные эхо-сигналы или проверки досягаемости не могут предоставлять точный вид подключений в многоадресной сети, поскольку набор приемных eNB-устройств может быть неизвестным для отправляющего MBMS-GW-устройства (источника), которому не предоставляется ни число, ни идентификационные приемных eNB-устройств (назначения).

[0026] Протокол обнаружения двунаправленного перенаправления (BFD), описанный посредством IETF в документе "Bidirectional Forwarding Detection", RFC 5880 ("RFC 5880"), который полностью содержится в данном документе по ссылке, может использоваться для того, чтобы отслеживать одноадресные IP-подключения между двумя узлами с поддержкой BFD. Одноадресное BFD может обнаруживать сбой линии связи между двумя прямыми равноправными узлами и немедленно уведомлять таблицу одноадресной или многоадресной маршрутизации. Такое обнаружение сбоев инициирует PIM-SM-протокол, работающий в этих узлах, чтобы отправлять и распространять объединенные PIM-сообщения в восходящем направлении по альтернативному тракту к источнику S, чтобы восстанавливать состояние многоадресного дерева (S, G), с тем чтобы перенаправлять MBMS-пакеты около сбоя линии связи.

[0027] Тем не менее, одноадресное BFD использует BFD-сеанс в каждой линии связи в сети. Использование таких BFD-характеристик недоступно в сочетании с многоадресной IP-связью во многих маршрутизаторах. Кроме того, BFD не обнаруживает множество UP-проблем, таких как, в качестве неограничивающего примера, состояние многоадресного канала и RPF-сбой, который может затрагивать сквозной однонаправленный MBMS UP-канал, включающий в себя, без ограничения, внутренние отказы в головной части или хвостовой части MBMS-услуги, в MBMS-GW или eNB, соответственно.

[0028] Следовательно, должно быть желательным предоставлять систему и способ, которые исключают или уменьшают вышеописанные проблемы.

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

[0029] Цель настоящего изобретения заключается в том, чтобы исключать или уменьшать, по меньшей мере, один недостаток уровня техники.

[0030] В первом аспекте настоящего изобретения предусмотрен способ для управления обработкой отказов в однонаправленном интерфейсе пользовательской плоскости однонаправленного канала для предоставления услуг широковещательной и многоадресной передачи мультимедиа (MBMS) для доставки типа "точка-многоточка" MBMS-трафика из исходного узла, по меньшей мере, в один узел назначения. Способ может осуществляться посредством узла назначения. Способ содержит этапы задания временного интервала обнаружения отказов, ассоциированного с однонаправленным MBMS-каналом. Таймер запускается в ответ на прием первого пакета синхронизации из исходного узла по однонаправленному интерфейсу пользовательской плоскости. Отказ обнаруживается в однонаправленном интерфейсе пользовательской плоскости в ответ на определение того, что таймер превышает временной интервал обнаружения отказов, и последующий пакет синхронизации не принят в течение временного интервала обнаружения отказов.

[0031] Во втором аспекте настоящего изобретения, предусмотрен сетевой узел для управления отказами в однонаправленном интерфейсе пользовательской плоскости однонаправленного канала для предоставления услуг широковещательной и многоадресной передачи мультимедиа (MBMS) для доставки типа "точка-многоточка" MBMS-трафика из исходного узла, по меньшей мере, в один узел назначения. Сетевой узел содержит процессор и запоминающее устройство, причем запоминающее устройство содержит инструкции, выполняемые посредством процессора, в силу которых сетевой узел выполнен с возможностью задавать временной интервал обнаружения отказов, ассоциированный с однонаправленным MBMS-каналом. Сетевой узел выполнен с возможностью запускать таймер в ответ на прием первого пакета синхронизации из исходного узла по однонаправленному интерфейсу пользовательской плоскости. Сетевой узел выполнен с возможностью обнаруживать отказ в однонаправленном интерфейсе пользовательской плоскости в ответ на определение того, что таймер превышает временной интервал обнаружения отказов, и последующий пакет синхронизации не принят в течение временного интервала обнаружения отказов.

[0032] В другом аспекте настоящего изобретения, предусмотрен диспетчер отказов, содержащий модуль задания временных интервалов, модуль приема пакетов, модуль таймера и модуль обнаружения отказов. Модуль задания временных интервалов выполнен с возможностью задания временного интервала обнаружения отказов, ассоциированного с однонаправленным каналом для предоставления услуг широковещательной и многоадресной передачи мультимедиа (MBMS). Модуль приема пакетов выполнен с возможностью приема первого пакета синхронизации из исходного узла по однонаправленному интерфейсу пользовательской плоскости однонаправленного MBMS-канала. Модуль таймера выполнен с возможностью запуска таймера в ответ на прием первого пакета синхронизации. Модуль обнаружения отказов выполнен с возможностью обнаружения отказа в однонаправленном интерфейсе пользовательской плоскости в ответ на определение того, что таймер превышает временной интервал обнаружения отказов, и последующий пакет синхронизации не принят в течение временного интервала обнаружения отказов.

[0033] В некоторых вариантах осуществления, временной интервал обнаружения отказов задается в соответствии с синхронизирующей MBMS SYNC-последовательностью. Временной интервал обнаружения отказов может задаваться таким образом, что он превышает кратное число синхронизирующей MBMS SYNC-последовательности.

[0034] В некоторых вариантах осуществления, таймер может сбрасываться в ответ на прием второго пакета синхронизации, из исходного узла, по однонаправленному интерфейсу пользовательской плоскости.

[0035] В некоторых вариантах осуществления, первый пакет синхронизации может представлять собой управляющую протокольную SYNC-единицу данных (SYNC PDU) тип 0 или управляющую протокольную SYNC-единицу данных (SYNC PDU) тип 3. В некоторых вариантах осуществления, первый пакет синхронизации принимается по однонаправленному интерфейсу пользовательской плоскости независимо от активности однонаправленного MBMS-канала.

[0036] В некоторых вариантах осуществления, в ответ на обнаружение отказа в однонаправленном интерфейсе пользовательской плоскости, сообщение с индикатором отказа передается в объект управления мобильностью по интерфейсу плоскости управления. Сообщение с индикатором отказа может передаваться в объект управления мобильностью для корреляции, по меньшей мере, с еще одним сообщением с индикатором отказа. Сообщение с индикатором отказа может передаваться в объект управления мобильностью для формирования уменьшенного числа уведомлений об отказе, ассоциированных с однонаправленным MBMS-каналом, в объект управления сетью.

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

[0038] В некоторых вариантах осуществления, в ответ на обнаружение отказа, по меньшей мере, одна операция получения членства в многоадресном IP-канале инициируется без высвобождения однонаправленного MBMS-канала. Первая операция получения членства в многоадресном IP-канале может включать в себя отправку сообщения с подпиской в соседний маршрутизатор многоадресной передачи, запрашивающего прослушивание многоадресного IP-канала, ассоциированного с однонаправленным MBMS-каналом. Сообщение с подпиской может выбираться из группы, состоящей из стадии отчета о членах IGMPv3-группы и отчета об изменении MLDv2-состояния. Сообщение с подпиской отправляется для того, чтобы инициировать соседний маршрутизатор многоадресной передачи с возможностью обновлять состояние своего прослушивающего устройства адресов для многоадресной передачи и отправлять сообщение присоединения в следующий вышележащий маршрутизатор многоадресной передачи.

[0039] В некоторых вариантах осуществления, вторая операция получения членства в многоадресном IP-канале может включать в себя отправку сообщения с отменой подписки в соседний маршрутизатор многоадресной передачи, запрашивающего прекращение прослушивания многоадресного IP-канала, ассоциированного с однонаправленным MBMS-каналом; и отправку, после предварительно определенного периода времени, второго сообщения с подпиской в соседний маршрутизатор многоадресной передачи, запрашивающего прослушивание многоадресного IP-канала, ассоциированного с однонаправленным MBMS-каналом. Сообщение с отменой подписки и/или второе сообщение с подпиской могут выбираться из группы, состоящей из стадии отчета о членах IGMPv3-группы и отчета об изменении MLDv2-состояния. Сообщение с отменой подписки может отправляться для того, чтобы инициировать соседний маршрутизатор многоадресной передачи с возможностью удалять состояние своего прослушивающего устройства адресов для многоадресной передачи и отправлять сообщение отсечения в следующий вышележащий маршрутизатор многоадресной передачи. Второе сообщение с подпиской отправляется для того, чтобы инициировать соседний маршрутизатор многоадресной передачи с возможностью воссоздавать состояние своего прослушивающего устройства адресов для многоадресной передачи и отправлять сообщение присоединения в следующий вышележащий маршрутизатор многоадресной передачи.

[0040] Различные аспекты и варианты осуществления, описанные в данном документе, могут комбинироваться альтернативно, необязательно и/или в дополнение между собой.

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

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

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

[0043] Фиг. 1 является примерным вариантом осуществления MBMS-развертывания в LTE-сети с распределенной MCE-архитектурой;

[0044] Фиг. 2 является примерным вариантом осуществления MBMS-развертывания в LTE-сети с централизованной MCE-архитектурой;

[0045] Фиг. 3 является примерным вариантом осуществления трафика данных в LTE-сети;

[0046] Фиг. 4 является примерной схемой состояний, которых может придерживаться eNB для однонаправленного MBMS-канала;

[0047] Фиг. 5 является схемой последовательности сигналов для передачи индикатора отказа;

[0048] Фиг. 6 иллюстрирует примерный способ для локализации отказов;

[0049] Фиг. 7 иллюстрирует примерный способ для исправления отказов;

[0050] Фиг. 8 является блок-схемой последовательности операций, иллюстрирующей способ для обнаружения отказа;

[0051] Фиг. 9 является блок-схемой последовательности операций, иллюстрирующей способ для указания отказа;

[0052] Фиг. 10 является блок-схемой последовательности операций, иллюстрирующей способ для локализации отказа;

[0053] Фиг. 11 является блок-схемой последовательности операций, иллюстрирующей способ для исправления отказа;

[0054] Фиг. 12 является блок-схемой последовательности операций, иллюстрирующей способ для управления обработкой отказов;

[0055] Фиг. 13 является блок-схемой, иллюстрирующей примерный сетевой узел; и

[0056] Фиг. 14 является блок-схемой объекта-диспетчера отказов.

Подробное описание изобретения

[0057] Ниже следует обратиться к конкретным элементам, пронумерованным в соответствии с прилагаемыми чертежами. Нижеприведенное пояснение должно рассматриваться как примерное по своему характеру, а не в качестве ограничения объема настоящего изобретения. Объем настоящего изобретения задается в формуле изобретения и не должен считаться ограниченным посредством сведений по реализации, описанных ниже, которые, как должны принимать во внимание специалисты в данной области техники, могут модифицироваться посредством замены элементов эквивалентными функциональными элементами.

[0058] Варианты осуществления настоящего раскрытия сущности направлены на системы и способы для управления отказами в интерфейсе пользовательской плоскости, ассоциированном с однонаправленным MBMS-каналом.

[0059] В документе "BFD For Multipoint Networks", IETF draft-ietf-bfd-multipoint-03.txt ("Multipoint BFD"), который полностью содержится в данном документе по ссылке, предложен способ для верификации сквозных однонаправленных многоадресных подключений между головными частями и хвостовыми частями с использованием BFD, но этот способ в настоящее время не стандартизирован и недоступен ни у одного известного поставщика оборудования. Кроме того, маловероятно, что это произойдет, по ряду причин, включающих в себя, без ограничения:

a) большое число многоадресных BFD-сеансов, которые следует инициировать, конфигурировать и поддерживать в MBMS-GW и eNB, при условии, что предусмотрен один многоадресный BFD-сеанс для каждого однонаправленного MBMS-канала;

b) потребление ресурсов MBMS-GW, eNB и полосы пропускания посредством вызываемого дополнительного управляющего протокола, в частности, со сложностью масштабирования BFD-состояния в сетевой головной части (в качестве неограничивающего примера, в MBMS-GW или вышележащем PIM-маршрутизаторе); и

c) проект технических требований, в котором межсетевое взаимодействие и координация многоадресного BFD-протокола между различными производителями, к примеру, в качестве неограничивающего примера, производителями MBMS-GW и eNB, в данный момент не предусматривается.

[0060] Односторонний протокол измерения описывается посредством IETF в документе "A One-Way Active Measurement Protocol (OWAMP)", RFC 4656 ("RFC 4656"), который полностью содержится в данном документе по ссылке. Этот протокол разрешает поиск неисправностей в отношении производительности сети. Тем не менее, отсутствует указание в отношении того, как использовать или применять этот протокол в многоадресной сети.

[0061] Как IETF, так и 3GPP указывают то, что операции IGMPv3- и MLDv3-протокола членов многоадресной передачи посредством прослушивающего устройства (в качестве неограничивающего примера, eNB) ограничены следующим:

a) запуск конкретного таймера IGMPv3/MLDv2-протокола;

b) прием сообщения с запросом, отправленного посредством PIM-маршрутизатора; и

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

[0062] Такие ограничения могут не допускать инициирования операций по протоколу многоадресной IP-передачи посредством оператора из прослушивающего устройства, которое может разрешать проблемы подключений в одном или более eNB, без высвобождения всего однонаправленного MBMS-канала из базовой сети.

[0063] В некоторых вариантах осуществления настоящего изобретения, до установления однонаправленного MBMS-канала, eNB может быть сконфигурирован с конфигурационными MBMS-данными, включающими в себя интервал активности состояния M1-подключения для eNB. В некоторых вариантах осуществления, предусмотрен интервал активности состояния M1-подключения, ассоциированный с каждым однонаправленным MBMS-каналом, ассоциированным с eNB.

[0064] Интервал активности состояния M1-подключения представляет собой предварительно определенный временной интервал, который считается надлежащим для того, чтобы обнаруживать изменение состояния подключения ассоциированного однонаправленного MBMS-канала.

[0065] В некоторых вариантах осуществления, интервал активности состояния M1-подключения может задаваться в соответствии с предполагаемой синхронизирующей MBMS SYNC-последовательностью. Интервал активности состояния M1-подключения может задаваться таким образом, что он превышает или равен кратному числу (например, три раза) предполагаемой синхронизирующей MBMS SYNC-последовательности.

[0066] В некоторых вариантах осуществления, интервал активности состояния M1-подключения в 0 может указывать то, что ассоциированный однонаправленный MBMS-канал (или eNB) не подвергается действию функции проверки M1-подключения.

[0067] Фиг. 4 иллюстрирует примерную схему состояний однонаправленного MBMS-канала, которых может придерживаться eNB. Показаны два состояния, а именно, рабочее состояние и состояние подключения. Первоначально, рабочее состояние однонаправленного MBMS-канала является деактивированным 200. После того, как установлен однонаправленный MBMS-канал, сеанс связи по однонаправленному MBMS-каналу начинается, и рабочее состояние однонаправленного MBMS-канала переключается на активированное 202. Если сеанс связи по однонаправленному MBMS-каналу завершается, то рабочее состояние однонаправленного MBMS-канала должно возвращаться в деактивированное 200.

[0068] Когда рабочее состояние однонаправленного MBMS-канала является активированным 202, состояние подключения по однонаправленному MBMS-каналу задается как неактивное 204.

[0069] При установлении однонаправленного MBMS-канала, BM-SC традиционно отправляет MBMS-пакеты, инкапсулируемые в SYNC PDU пользовательских данных (например, SYNC PDU тип 0). Дополнительно, в некоторых вариантах осуществления, BM-SC отправляет управляющую SYNC PDU (например, SYNC PDU тип 0 или 3), в конце каждой синхронизирующей последовательности, которая может колебаться от 80 мс, 160 мс или вплоть до 1024 мс, независимо от активности однонаправленного канала.

[0070] В некоторых примерных вариантах осуществления, eNB отслеживает на предмет приема или отсутствия приема входящих управляющих SYNC PDU для каждого отдельного однонаправленного MBMS-канала. При приеме управляющей SYNC PDU, состояние M1-подключения по однонаправленному MBMS-каналу задается как активное 206.

[0071] Если временной интервал активности состояния подключения, ассоциированный с однонаправленным MBMS-каналом, проходит между последовательными принимаемыми управляющими SYNC PDU, состояние подключения по однонаправленному MBMS-каналу возвращается в неактивное 204, и eNB может объявлять, что отказ обнаружен для однонаправленного MBMS-канала.

[0072] В некоторых вариантах осуществления, таймер активности состояния M1-подключения задается и ассоциируется с каждым однонаправленным MBMS-каналом. Таймер активности состояния M1-подключения может представлять собой таймер обратного отсчета, который первоначально задается равным ассоциированному интервалу активности состояния подключения. Когда управляющая SYNC PDU принимается для однонаправленного MBMS-канала, eNB может сбрасывать ассоциированный таймер активности состояния M1-подключения на ассоциированный интервал активности состояния подключения. Если время активности состояния M1-подключения подсчитывается в обратном порядке до нуля, то состояние подключения по однонаправленному MBMS-каналу должно возвращаться в неактивное 204, и eNB может объявлять, что отказ обнаружен для однонаправленного MBMS-канала.

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

[0074] Хотя состояние подключения по однонаправленному MBMS-каналу является неактивным 204, eNB продолжает отслеживать однонаправленный MBMS-канал на предмет входящих управляющих SYNC PDU. В некоторых примерных вариантах осуществления, когда предварительно определенное число пакетов с управляющими SYNC PDU тип 0 или тип 3 принимается из BM-SC в пределах интервала активности состояния подключения, состояние подключения по однонаправленному MBMS-каналу возвращается в активное 206, и eNB может объявлять, что восстановление подключения обнаружено для однонаправленного MBMS-канала. В некоторых примерных вариантах осуществления, предварительно определенное число пакетов может составлять три.

[0075] В некоторых вариантах осуществления настоящего изобретения, когда eNB обнаруживает потерю подключения для однонаправленного MBMS-канала, eNB может отправлять сообщение с индикатором отказа, к примеру, в качестве неограничивающего примера, M1-сообщение с индикатором сбоя, в объект управления мобильностью, к примеру, MME.

[0076] В примерной сетевой архитектуре по фиг. 1, это может достигаться посредством отправки посредством MCE 122a (совместно размещаемого на eNB 124a) сообщения с индикатором отказа по M3 CP-интерфейсу 126a непосредственно в MME 114. В примерной сетевой архитектуре по фиг. 2, это может достигаться посредством отправки посредством eNB 124a сообщения с индикатором отказа по M2 CP-интерфейсу 136a в централизованный MCE 134. MCE 134 перенаправляет сообщение с индикатором отказа по M3 CP-интерфейсу 126c в MME 114.

[0077] Фиг. 5 является схемой последовательности сигналов, иллюстрирующей примерную передачу служебных сигналов для индикатора отказа. С использованием M2-интерфейса 136a, eNB 124a отправляет M1-сообщение 210 с индикатором сбоя в MCE 134. С использованием M3-интерфейса 126a, MCE 122a отправляет M1-сообщение 220 с индикатором сбоя в MME 114.

[0078] В некоторых вариантах осуществления, ответ из MCE и/или MME не требуется при приеме сообщения с индикатором отказа. Это позволяет дополнительно уменьшать объем служебной информации в сети.

[0079] Таким образом, специалисты в данной области техники должны принимать во внимание, что варианты осуществления настоящего изобретения предоставляют индикатор относительно отказа пользовательской плоскости с использованием интерфейса передачи служебных сигналов в плоскости управления. Это должно отличаться от традиционных подходов, в которых отказ указывается по выделенной линии связи для управления, администрирования и обслуживания (OAM) в OAM- или FM-модуль системы управления сетью (NMS). Такие выделенные линии связи типично имеют низкую полосу пропускания, так что линия связи и фактически OAM-модуль могут быть насыщены или переполнены посредством каскада индикаторов отказов или шторма сигналов предупреждения, к примеру, которые могут встречаться в случае катастрофического сбоя сети.

[0080] Использование интерфейса передачи служебных сигналов в плоскости управления дополнительно может помогать в управлении индикаторами отказов с тем, чтобы уменьшать вероятность шторма передачи сигналов предупреждения.

[0081] В некоторых вариантах осуществления, eNB может обнаруживать потерю подключения для множества различных однонаправленных MBMS-каналов. В таком сценарии, eNB может пакетировать множество индикаторов потери подключения в меньшее число сообщений. Например, сообщение с индикатором отказа может допускать размещение вплоть до 256 индикаторов отказов однонаправленных каналов. Чтобы использовать преимущество этих характеристик пакетирования, в некоторых вариантах осуществления, eNB может быть выполнен с возможностью ожидать в течение периода времени (например, порядка нескольких секунд), чтобы потенциально накапливать множество индикаторов потери подключения для формирования отчетов в одном сообщении с индикатором отказа. Несмотря на такую конфигурацию, целесообразно, в частности, в случае катастрофического сбоя сети, если eNB может отправлять множество сообщений с индикаторами отказов в MME.

[0082] В некоторых вариантах осуществления, интервал между передачей сообщений с индикаторами последовательного отказа может задаваться таким образом, чтобы уменьшать вероятность того, что MCE и/или MME становятся перегруженными. В некоторых вариантах осуществления, минимум 60 секунд между передачами для данного типа сообщений посредством eNB может быть надлежащим.

[0083] Тем не менее, небольшое или большое число сообщений с индикаторами отказов отправляются, и насколько часто, при приеме посредством MME, каждое из этих сообщений обрабатывается. Такая обработка может включать в себя функцию регистрации, при которой записываются eNB и, в некоторых примерных вариантах осуществления, однонаправленный MBMS-канал(ы), для которых указаны отказы.

[0084] В некоторых вариантах осуществления, обработка посредством MME может включать в себя постепенное увеличение одного или более сетевых счетчиков MBMS-подключений. Такие счетчики могут включать в себя общее число услуг однонаправленного MBMS-канала, затрагиваемых посредством отказа, и общее число eNB, затрагиваемых посредством отказа, без обязательной идентификации того, связаны или нет отказы.

[0085] В некоторых вариантах осуществления, обработка посредством MME может включать в себя формирование сигнала предупреждения в FM- или OAM-систему для одного или более сообщений с индикаторами отказов. Когда имеется только небольшое число либо имеются изолированные сообщения с индикаторами отказов, сигнал предупреждения может формироваться для каждого сообщения и/или для каждой конкретной услуги однонаправленного MBMS-канала, ассоциированной с ним. Тем не менее, когда затрагивается большое число однонаправленных MBMS-каналов и/или большое число eNB, так что большое число отчетов индикатора отказа принимается посредством MME, MME может определять отправлять только поднабор, например, в качестве неограничивающего примера, десять возможных сигналов предупреждения в FM- или OAM-систему, с тем чтобы не допускать шторма сигналов предупреждения, который может насыщать выделенные линии OAM-связи.

[0086] Тем не менее, формируется множество сигналов предупреждения, каждый сигнал предупреждения может предоставлять информацию относительно затрагиваемого eNB и однонаправленного MBMS-канала(ов). В некоторых вариантах осуществления, текст сигнала предупреждения может утверждать, что подключение к услуге однонаправленного MBMS-канала <TMGI> для усовершенствованного узла B <eNodeB_Identifier> потеряно, при этом TMGI представляет собой временный идентификатор группы мобильных устройств, который уникально идентифицирует однонаправленный MBMS-канал, и eNodeB_Identifier уникально идентифицирует eNB.

[0087] В некоторых вариантах осуществления, текст сигнала предупреждения может включать в себя пару адресов (S, G), которая уникально идентифицирует ассоциированный SSM-канал.

[0088] Как пояснено в данном документе, в некоторых вариантах осуществления, eNB дополнительно может обнаруживать восстановление подключения. В таких вариантах осуществления, при обнаружении восстановления подклю