УПРАВЛЕНИЕ ОБРАБОТКОЙ ОТКАЗОВ ОДНОНАПРАВЛЕННЫХ MBMS-КАНАЛОВ НА ОСНОВЕ ХВОСТОВОЙ ЧАСТИ Российский патент 2018 года по МПК H04W24/04 

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

[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 дополнительно может обнаруживать восстановление подключения. В таких вариантах осуществления, при обнаружении восстановления подключения, eNB может отправлять сообщение восстановления после отказов, к примеру, в качестве неограничивающего примера, M1-сообщение с индикатором восстановления, в MME способом и в обстоятельствах, аналогичных сообщениям с индикаторами отказов, описанным относительно фиг. 5. Аналогично, при приеме MME может обрабатывать принимаемое сообщение(я) восстановления после отказов способом и в обстоятельствах, аналогичных сообщению с индикатором отказа, поясненному выше.

[0089] В некоторых вариантах осуществления, обработка посредством MME может включать в себя очистку сигналов предупреждения в FM- или OAM-систему для одного или более сообщений с индикаторами исправления.

[0090] Фиг. 6 иллюстрирует примерный способ для локализации отказов. Вариант осуществления по фиг. 6 может реализовываться посредством инициирования посредством OAM- или FM-модуля многоадресного тестового сеанса для локализации, по меньшей мере, одного отказа в многоадресной IP-сети после приема сигнала предупреждения или уведомления по однонаправленному MBMS-каналу.

[0091] Как пояснено в данном документе, MBMS-сети используют дерево однонаправленного тракта из MBMS-GW в каждый eNB, подписанный на сеанс связи по однонаправленному MBMS-каналу, и в конечном счете, в одно или более UE, соединенных посредством Uu-интерфейса с eNB. По этой причине, традиционные способы, заключающие в себе BFD, не поддаются простой локализации отказов в MBMS-сетях.

[0092] Фиг. 6 включает в себя примерную систему 230 управления сетью (NMS), MME 240, MBMS-GW 250, eNB 260 и определенное число объектов PIM-маршрутизаторов 270, 272, 274, 276 согласно вариантам осуществления настоящего изобретения. NMS 230 необязательно может включать в себя определенное число модулей, к примеру, модуль 232 управления обработкой отказов (FM), модуль 234 управления конфигурацией (CM) и/или модуль 236 управления производительностью (PM).

[0093] При приеме сигнала предупреждения относительно подключения по однонаправленному MBMS-каналу (этап 280) из MME 240, NMS 230 может коррелировать сигнал предупреждения с любыми другими связанными принимаемыми сигналами предупреждения и идентифицирует PIM-маршрутизатор 270, который может быть подходящим для передачи односторонних многоадресных тестовых пакетов в eNB 260, который обнаруживает отказ, сообщаемый в принимаемом сигнале 280 предупреждения относительно подключения по однонаправленному MBMS-каналу, по части SSM-канала, ассоциированной с сеансом связи по однонаправленному MBMS-каналу, с которым ассоциирован сигнал предупреждения.

[0094] Когда PIM-маршрутизатор 270 идентифицирован, NMS 230 верифицирует состояние многоадресного дерева (S, G) для выбранного PIM-маршрутизатора и конфигурирует односторонний многоадресный тестовый сеанс (этап 282) с использованием исходного адреса S для одноадресной передачи и целевого адреса G для многоадресной передачи, но с использованием UDP-сокета P в eNB 260, который отличается от сокета, используемого для завершения всех многоадресных GTP-туннелей в eNB, который, в некоторых примерных вариантах осуществления, может представлять собой UDB-порт 2152 в соответствии с TS 29.281. Соответственно, eNB 260 должен иметь возможность отличать тестовые пакеты, принятые из многоадресного тестового сеанса по многоадресному дереву (S, G), от многоадресного GTP-туннеля для сеанса связи по однонаправленному MBMS-каналу.

[0095] Выбранный PIM-маршрутизатор 270 устанавливает управляющее соединение по TCP или SCTP на адрес для одноадресной передачи интерфейса eNB 260 и запрашивает установление одностороннего многоадресного тестового сеанса с использованием исходного адреса S для одноадресной передачи, целевого адреса G для многоадресной передачи и целевого UDP-порта P (этап 284). Таким образом, тестовый сеанс использует часть SSM-канала, ассоциированную с сеансом связи по однонаправленному MBMS-каналу, с которым ассоциирован сигнал предупреждения.

[0096] Необязательно, установление тестового сеанса также может включать в себя определенное число многоадресных тестовых пакетов, которые должны передаваться, а также начальное время и конечное время для тестового сеанса.

[0097] В соответствии с тестовым сеансом, выбранный PIM-маршрутизатор 270 передает поток многоадресных тестовых пакетов по части SSM-канала, ассоциированной с сеансом связи по однонаправленному MBMS-каналу, с которым ассоциирован сигнал предупреждения (этап 286). В некоторых вариантах осуществления, каждый тестовый пакет может включать в себя порядковый номер и временную метку выхода. В некоторых вариантах осуществления, тестовый пакет представляет собой тестовый OWAMP-пакет в неаутентифицированном режиме с целевым IP-адресом G, к примеру, как описывается в RFC 4656.

[0098] Тестовые пакеты следуют после части SSM-канала, идентифицированной в направлении eNB 260. Если и когда тестовые пакеты принимаются посредством eNB 260, eNB 260 снабжает временной меткой каждый принимаемый пакет и сохраняет порядковый номер, TTL или лимит перескоков частот и временные метки выхода и приема (этап 288). В некоторых вариантах осуществления, эта информация может передаваться в тестовых записях непосредственно в NMS 230 по выделенной линии OAM-связи в промежутке (этапом 290). В некоторых альтернативных вариантах осуществления, эта информация может возвращаться в инициатор тестового сеанса, например, PIM-маршрутизатор 270 (этап 292). Инициатор тестового сеанса затем может консолидировать и передавать тестовые записи в NMS 230 по выделенной линии OAM-связи в промежутке.

[0099] Таким образом, NMS 230 может формировать показатели задержки и потерь при передаче пакетов для тестового сеанса и определять то, могут или нет дополнительные тестовые сеансы из идентичного или из различного PIM-маршрутизатора быть надлежащими для того, чтобы локализовать отказ. Разумный выбор надлежащих PIM-маршрутизаторов и соответствующих частей SSM-канала позволяет разрешать локализацию отказа с относительной простотой.

[00100] Фиг. 7 иллюстрирует примерный способ для исправления отказов. Вариант осуществления по фиг. 7 может включать в себя операции по протоколу многоадресной IP-передачи, инициируемые посредством eNB, чтобы помогать в разрешении проблем подключений в PIM-сети без прекращения MBMS-сеанса. Фиг. 7 включает в себя примерные объекты BM-SC 300, MBMS-GW 302, MME 304, PIM-сеть 306, eNB/MCE 308 и UE 310 согласно вариантам осуществления настоящего изобретения.

[00101] Этап 320 включает в себя операции по протоколу, соответствующие процедуре начала MBMS-сеанса. Это может включать в себя сообщение с запросом на начало MBMS-сеанса, передаваемое из BM-SC 300 в MBMS-GW 302 и перенаправленное в MME 304 и eNB 308. Надлежащий ресурс сети радиодоступа может быть сконфигурирован (например, относительно UE 310), и eNB 304 может отправлять сообщение с подпиской в PIM-сеть 306. MBMS-данные 322 пользовательской плоскости затем могут передаваться посредством BM-SC 300 и передаваться в многоадресном режиме 324 в PIM-сеть 306.

[00102] ENB 308 может обнаруживать отказ и/или потерю подключения с использованием технологии, как описано в данном документе, на этапе 326. ENB 308 может передавать M1-сообщение 328 с индикатором сбоя в MME 304. В некоторых вариантах осуществления, eNB 308 может инициировать операции по протоколу многоадресной IP-передачи, чтобы пытаться исправлять обнаруженный отказ без прекращения неисправного MBMS-сеанса.

[00103] В некоторых вариантах осуществления, это может быть выполнено посредством отправки сообщения 330 с подпиской, к примеру, сообщения с отчетом о членах IGMPv3-группы и/или отчетом об изменении MLDv2-состояния (включающего в себя повторные передачи) в PIM-маршрутизатор многоадресной передачи, непосредственно рядом с eNB 308, по SSM-каналу, соответствующему неисправному MBMS-сеансу. Сообщение 322 с подпиской может указывать желание прослушивать SSM-канал. В некоторых вариантах осуществления, это сообщение может отправляться автоматически. В некоторых вариантах осуществления, это сообщение может отправляться вручную по пользовательской команде.

[00104] Этот запрос 330 на подписку моделирует, хотя в ходе установленного MBMS-сеанса, сценарий, в котором MBMS-сеанс только что создан, и/или в котором состояние прослушивания многоадресной передачи в интерфейсе eNB 308 изменено, оба из которых хорошо известны и описываются в RFC 3376 и/или RFC 3810, соответственно. Необязательно, это сообщение может содержать информацию, идентичную информации, первоначально передаваемой, когда MBMS-сеанс первоначально установлен (например, на этапе 320). Эта информация может включать в себя запись об изменении в списке источников с типом 5 записи (ALLOW_NEW_SOURCES) с исходным адресом=S и адресом для многоадресной передачи=G.

[00105] Сообщение 330 с подпиской предназначено для того, чтобы инициировать PIM-маршрутизатор с возможностью выполнять операцию и обновлять любое существующее состояние прослушивающего устройства адресов для многоадресной передачи в маршрутизаторе. После приема такого сообщения, PIM-маршрутизатор должен также отправлять соответствующее PIM-сообщение присоединения (S, G) в следующий непосредственно вышележащий маршрутизатор многоадресной передачи в PIM-сети 306.

[00106] Если потеря подключения сохраняется, eNB 308 может после этого отправлять сообщение 332 с отменой подписки. Отмена 332 подписки может включать в себя сообщение с отчетом о членах IGMPv3-группы и/или отчетом об изменении MLDv2-состояния (включающего в себя повторные передачи) в PIM-маршрутизатор многоадресной передачи, непосредственно рядом с eNB 308, по SSM-каналу, соответствующему неисправному MBMS-сеансу. Сообщение 332 с отменой подписки может указывать желание более не прослушивать SSM-канал и достигать этого без прекращения MBMS-сеанса. В некоторых вариантах осуществления, это сообщение может отправляться автоматически. В некоторых вариантах осуществления, это сообщение может отправляться вручную по пользовательской команде. В некоторых вариантах осуществления, сообщение 332 с отменой подписки включает в себя запись об изменении в списке источников с типом 6 записи (BLOCK_OLD_SOURCE) с исходным адресом=S и адресом для многоадресной передачи=G.

[00107] Эта операция предназначена для того, чтобы инициировать PIM-маршрутизатор с возможностью выполнять запрос на предмет других возможных прослушивающих устройств в присоединенной линии связи и в конечном счете удалять адрес для многоадресной передачи в состоянии своего прослушивающего устройства адресов для многоадресной передачи. После приема такого сообщения, PIM-маршрутизатор должен также отправлять соответствующие PIM-сообщение отсечения (S, G) в следующий непосредственно вышележащий маршрутизатор многоадресной передачи в PIM-сети 306.

[00108] PIM-маршрутизатор, выступающий в качестве объекта выполнения запроса, необязательно может отправлять сообщение 334 с конкретным для источника запросом, чтобы верифицировать то, имеются или нет другие прослушивающие устройства для идентичного источника в линии связи. Если ответ, который включает в себя этот источник, принимается до истечения таймера, все маршрутизаторы многоадресной передачи в линии связи могут обновлять таймер источника. Если ответ не принимается, источник удаляется из списка включенных элементов. Список включенных элементов представляет собой набор источников, которые одно или более прослушивающих устройств в линии связи запрашивают на предмет приема. Любой другой источник, который не находится в списке включенных элементов, может блокироваться посредством маршрутизатора. В некоторых вариантах осуществления, конкретный для источника запрос 334 может включать в себя исходный адрес=S и адрес для многоадресной передачи=G.

[00109] После периода времени, eNB 308 может снова подписываться на SSM-канал с помощью сообщения 336 с подпиской. Подписка 336 может включать в себя сообщение с отчетом о членах IGMPv3-группы и/или отчетом об изменении MLDv2-состояния (включающее в себя повторные передачи) в PIM-маршрутизатор многоадресной передачи, непосредственно рядом с eNB 308, по SSM-каналу, соответствующему неисправному MBMS-сеансу, указывающее желание прослушивать SSM-канал. Этот запрос моделирует, хотя и в ходе установленного MBMS-сеанса, сценарий, в котором MBMS-сеанс только что создан, который хорошо известен и описывается в RFC 3376 и/или RFC 3810, соответственно.

[00110] В некоторых вариантах осуществления, сообщение 336 с подпиской может содержать информацию, идентичную информацию, первоначально передаваемой, когда MBMS-сеанс первоначально установлен. Эта информация может включать в себя запись об изменении в списке источников с типом 5 записи (ALLOW_NEW_SOURCES) с исходным адресом=S и адресом для многоадресной передачи=G. Эта операция предназначена для того, чтобы удалять и перекомпоновывать состояние многоадресной передачи (S, G) и дерево распространения без затрагивания скорости MBMS-сеанса.

[00111] Фиг. 8 является блок-схемой последовательности операций, иллюстрирующей способ для обнаружения отказа по пользовательской плоскости для сеанса связи по однонаправленному MBMS-каналу, устанавливаемого по дереву однонаправленного распространения, исходящему от головной части. Способ может осуществляться посредством узла в хвостовой части дерева, подписанного на многоадресный сеанс. Хвостовой конечный узел или узел назначения может представлять собой eNB, как описано в данном документе.

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

[00113] По меньшей мере, один пакет синхронизации, выданный посредством головной части по дереву многоадресного распространения, принимается посредством хвостового конечного узла (этап 410). Пакеты синхронизации могут представлять собой SYNC PDU, выбранные из группы, состоящей из следующего: SYNC PDU пользовательских данных (тип 0), управляющие SYNC PDU (тип 0), управляющие SYNC PDU (тип 3) и/или любая комбинация означенного. В некоторых вариантах осуществления, пакет синхронизации передается в конце синхронизирующей последовательности независимо от активности однонаправленного канала.

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

[00115] Отказ по пользовательской плоскости обнаруживается, если время между приемом последовательных пакетов синхронизации превышает интервал (этап 430). Операция обнаружения может включать в себя определение того, что таймер подсчитан в обратном порядке до нуля. В некоторых вариантах осуществления, обнаруженный отказ указывается посредством сообщения с индикатором отказа, передаваемого посредством хвостового конечного узла в управляющий объект.

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

[00117] Фиг. 9 является блок-схемой последовательности операций, иллюстрирующей способ для указания отказа по пользовательской плоскости сеанса связи по однонаправленному MBMS-каналу, устанавливаемого по дереву однонаправленного распространения, исходящему от головной части. Способ может осуществляться посредством узла мониторинга. Узел мониторинга может представлять собой MME- или MCE-узел, как описано в данном документе.

[00118] В некоторых вариантах осуществления, способ по фиг. 9 может осуществляться после обнаружения отказа, к примеру, в качестве неограничивающего примера, как проиллюстрировано на фиг. 8.

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

[00120] Принимаемое сообщение(я) с индикатором отказа обрабатывается посредством узла мониторинга (этап 450). Операция обработки может включать в себя активность, выбранную из группы, состоящей из следующего: постепенное увеличение счетчика общего числа услуг однонаправленного MBMS-канала, затрагиваемых посредством отказа, постепенное увеличение счетчика общего числа узлов обнаружения отказов, затрагиваемых посредством отказа, и/или любая комбинация означенного.

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

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

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

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

[00125] Односторонний многоадресный тестовый сеанс затем устанавливается из начального узла с использованием идентификаторов, соответствующих головной части и хвостовому конечному узлу, и сокета хвостового конечного узла, отличающегося от сеанса связи по однонаправленному MBMS-каналу (этап 480). В некоторых вариантах осуществления, сокет хвостового конечного узла может быть представлять собой любой UDP-сокет, кроме UDP-сокета 2152. Тестовый пакет передается из начального узла в хвостовой конечный узел по установленному многоадресному тестовому сеансу (этап 490). В сценарии, в котором предполагаемый отказ не является постоянным, тестовый пакет должен приниматься посредством хвостового конечного узла (этап 500). Диагностическая информация, соответствующая принимаемому пакету(ам), затем может сообщаться в систему обработки отказов для использования в локализации отказа.

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

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

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

[00129] Способ начинается посредством отправки сообщения с подпиской в промежуточный узел (этап 520). Промежуточный узел может представлять собой соседний маршрутизатор многоадресной передачи, который является непосредственно вышележащим по дереву распространения. Сообщение с подпиской может представлять собой сообщение начала прослушивания, которое может запрашивать то, что промежуточный узел должен прослушивать многоадресный канал (SSM-канал). Сообщение с подпиской дополнительно может инициировать промежуточный узел с возможностью отправлять сообщение присоединения в следующий вышележащий узел.

[00130] В некоторых необязательных вариантах осуществления, хвостовой конечный узел может определять то, что отказ пользовательской плоскости сохраняется (этап 530). Хвостовой конечный узел может отправлять отправку сообщения с отменой подписки в промежуточный узел (этап 540). Сообщение с отменой подписки может представлять собой сообщение прекращения прослушивания, запрашивающее то, что промежуточный узел более не должен прослушивать многоадресный канал. Хвостовой конечный узел затем может инициировать повторную подписку на многоадресный канал (этап 550). Это может включать в себя отправку второго сообщения с подпиской в промежуточный узел (этап 560), запрашивающего то, что промежуточный узел должен повторно начинать прослушивание многоадресного канала. В некоторых вариантах осуществления, передаваемые сообщения могут выбираться из группы, состоящей из следующего: стадия отчета о членах IGMPv3-группы, отчета об изменении MLDv2-состояния и/или любая комбинация означенного.

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

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

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

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

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

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

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

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

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

[00140] Сетевой узел 700 включает в себя процессор 702, запоминающее устройство или репозиторий 704 инструкций и интерфейс 706 связи. Интерфейс 706 связи может включать в себя, по меньшей мере, один порт ввода и, по меньшей мере, один порт вывода. Запоминающее устройство 704 содержит инструкции, выполняемые посредством процессора 702, в силу которых сетевой узел 700 выполнен с возможностью осуществлять различные варианты осуществления, как описано в данном документе. В некоторых вариантах осуществления, сетевой узел 700 может представлять собой виртуализированное приложение, хостящееся посредством базового физического оборудования.

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

[00142] Фиг. 14 является блок-схемой объекта-диспетчера 800 отказов, который может включать в себя множество модулей, включающих в себя, но не только, модуль 802 задания временных интервалов, модуль 804 приема пакетов, модуль 806 таймера и модуль 808 обнаружения отказов. Модуль 802 задания временных интервалов выполнен с возможностью задавать временной интервал обнаружения отказов, ассоциированный с однонаправленным MBMS-каналом. Модуль 804 приема пакетов выполнен с возможностью принимать первый пакет синхронизации из исходного узла по однонаправленному интерфейсу пользовательской плоскости. Модуль 806 таймера выполнен с возможностью запускать таймер в ответ на прием первого пакета синхронизации. Модуль 808 обнаружения отказов выполнен с возможностью обнаруживать отказ в однонаправленном интерфейсе пользовательской плоскости в ответ на определение того, что таймер превышает временной интервал обнаружения отказов, и последующий пакет синхронизации не принят в течение временного интервала обнаружения отказов.

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

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

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

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

- задают временной интервал обнаружения отказов, ассоциированный с однонаправленным MBMS-каналом;

- запускают таймер в ответ на прием первого пакета синхронизации из исходного узла по однонаправленному интерфейсу пользовательской плоскости; и

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

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

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

4. Способ по любому из пп. 1-3, дополнительно содержащий этап, на котором сбрасывают таймер в ответ на прием второго пакета синхронизации из исходного узла по однонаправленному интерфейсу пользовательской плоскости.

5. Способ по п. 1, в котором первый пакет синхронизации представляет собой управляющую протокольную SYNC-единицу данных (SYNC PDU) тип 0 или тип 3.

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

7. Способ по любому из пп. 1-3, 5, 6, дополнительно содержащий этап, на котором:

- в ответ на обнаружение отказа в однонаправленном интерфейсе пользовательской плоскости передают сообщение с индикатором отказа в объект управления мобильностью по интерфейсу плоскости управления.

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

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

10. Способ по любому из пп. 1-3, 5, 6, 8, 9, дополнительно содержащий этапы, на которых:

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

- подсчитывают число принимаемых дополнительных пакетов синхронизации; и

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

11. Способ по п. 10, дополнительно содержащий этап, на котором:

- в ответ на обнаружение восстановления после отказов передают сообщение восстановления после отказов в объект управления мобильностью по интерфейсу плоскости управления.

12. Способ по любому из пп. 1-3, 5, 6, 8, 9, 11, дополнительно содержащий этап, на котором в ответ на обнаружение отказа инициируют по меньшей мере одну операцию получения членства в многоадресном IP-канале без высвобождения однонаправленного MBMS-канала.

13. Способ по любому из пп. 1-3, 5, 6, 8, 9, 11, в котором первая операция получения членства в многоадресном IP-канале включает в себя этап, на котором отправляют сообщение с подпиской в соседний маршрутизатор многоадресной передачи, запрашивающее прослушивание многоадресного IP-канала, ассоциированного с однонаправленным MBMS-каналом.

14. Способ по п. 13, в котором сообщение с подпиской выбирается из группы, состоящей из стадии отчета о членах IGMPv3-группы и отчета об изменении MLDv2-состояния.

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

16. Способ по любому из пп. 1-3, 5, 6, 8, 9, 11, 14, 15, в котором вторая операция получения членства в многоадресном IP-канале включает в себя этапы, на которых:

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

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

17. Способ по п. 16, в котором сообщение с отменой подписки и второе сообщение с подпиской выбираются из группы, состоящей из стадии отчета о членах IGMPv3-группы и отчета об изменении MLDv2-состояния.

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

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

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

- задавать временной интервал обнаружения отказов, ассоциированный с однонаправленным MBMS-каналом;

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

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

21. Сетевой узел по п. 20, в котором временной интервал обнаружения отказов задается в соответствии с синхронизирующей MBMS SYNC-последовательностью.

22. Сетевой узел по любому из пп. 20-21, дополнительно выполненный с возможностью сбрасывать таймер в ответ на прием второго пакета синхронизации из исходного узла по однонаправленному интерфейсу пользовательской плоскости.

23. Сетевой узел по п. 20, в котором первый пакет синхронизации принимается по однонаправленному интерфейсу пользовательской плоскости независимо от активности однонаправленного MBMS-канала.

24. Сетевой узел по любому из пп. 20, 21, 23, дополнительно выполненный с возможностью в ответ на обнаружение отказа в однонаправленном интерфейсе пользовательской плоскости передавать сообщение с индикатором отказа в объект управления мобильностью по интерфейсу плоскости управления.

25. Сетевой узел по любому из пп. 20, 21, 23, дополнительно выполненный с возможностью:

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

- подсчитывать число принимаемых дополнительных пакетов синхронизации; и

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

26. Сетевой узел по любому из пп. 20, 21, 23, дополнительно выполненный с возможностью в ответ на обнаружение отказа инициировать по меньшей мере одну операцию получения членства в многоадресном IP-канале без высвобождения однонаправленного MBMS-канала.

27. Сетевой узел по любому из пп. 20, 21, 23, в котором первая операция получения членства в многоадресном IP-канале включает в себя отправку сообщения с подпиской в соседний маршрутизатор многоадресной передачи, запрашивающего прослушивание многоадресного IP-канала, ассоциированного с однонаправленным MBMS-каналом.

28. Сетевой узел по любому из пп. 20, 21, 23, в котором вторая операция получения членства в многоадресном IP-канале включает в себя:

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

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

29. Диспетчер отказов, содержащий:

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

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

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

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