СПОСОБЫ И УСТРОЙСТВА УВЕДОМЛЕНИЯ ОБ АВАРИЙНЫХ СИГНАЛАХ WLAN В СОТОВЫХ СЕТЯХ СВЯЗИ Российский патент 2018 года по МПК H04L12/24 

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

Данная заявка испрашивает приоритет заявки на патент США №14/668,663, поданной 25 марта 2015 года и озаглавленной "СПОСОБЫ И УСТРОЙСТВА ДЛЯ УВЕДОМЛЕНИЯ ОБ АВАРИЙНОМ СИГНАЛЕ WLAN В СОТОВЫХ СЕТЯХ 3GPP", которая испрашивает приоритет по предварительной заявке США №62/062,711, поданной 10 октября 2014 года и озаглавленной "Способ и устройство для уведомлений об аварийных сигналах WLAN для выгрузки WLAN в сотовых сетях 3GPP", полное раскрытие которых включено сюда во всей своей полноте для всех целей путем ссылки, за исключением тех разделов, если таковые имеются, которые не соответствуют данному описанию.

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

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

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

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

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

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

На фиг.1 показан пример сетевой среды высокого уровня в соответствии с различными вариантами осуществления.

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

На фиг.3 показаны иерархия именования/вместимости модели сетевых ресурсов WLAN и ассоциации классов в соответствии с различными вариантами осуществления.

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

На фиг.5 показан менеджер элементов в соответствии с различными вариантами осуществления.

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

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

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

Иллюстративные варианты осуществления настоящего раскрытия включают в себя, но не ограничиваются ими, способы, системы, машиночитаемые носители и устройства для уведомления об аварийном сигнале WLAN в сотовых сетях.

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

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

Фраза "в некоторых вариантах осуществления" используется повторно. Как правило, фраза не относится к одним и тем же вариантам осуществления; однако это возможно. Термины "содержащий", "имеющий" и "включающий в себя" являются синонимами, если из контекста не следует иное.

Фразы "A или B", "A/B" и "A и/или B" означают (A), (B) или (A и B).

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

На фиг.1 схематично показана сетевая среда 100 в соответствии с различными вариантами осуществления. Сетевая среда 100 включает в себя сетевой менеджер 104, коммуникативно связанный с менеджером 108 элементов. Сетевой менеджер 104 может организовывать работу множества менеджеров элементов, в том числе одного или более менеджеров элементов в дополнение к менеджеру 108 элементов. Сетевой менеджер 104 и менеджер 108 элементов могут быть частью сотовой сети, такой как сеть 3GPP LTE Advanced (LTE-A). В других вариантах осуществления можно использовать другие технологии сотовой сети.

В различных вариантах осуществления AP 120 WLAN может быть коммуникативно связана с менеджером 108 элементов. В некоторых вариантах осуществления сетевая среда 100 может дополнительно включать в себя контроллер 124 доступа для управления одной или более AP 120 WLAN через интерфейс AC-AP. В этих вариантах осуществления менеджер 108 элементов может поддерживать связь с одной или более AP 120 WLAN через контроллер 124 доступа. Другие варианты осуществления не включают в себя контроллер 124 доступа. В этих вариантах осуществления менеджер 108 элементов может поддерживать связь непосредственно с AP 120 WLAN.

В различных вариантах осуществления сетевой менеджер 104 может включать в себя менеджер 128 эталонных точек интеграции (IRP) для управления множеством менеджеров элементов, включая менеджер 108 элементов, сети LTE-A. Менеджер 128 IRP может поддерживать связь с менеджером 108 элементов через проводной и/или беспроводный интерфейс. В некоторых вариантах осуществления менеджер 128 IRP может поддерживать связь с менеджером 108 элементов через интерфейс 2-го типа, который связан с протоколом управления сетью (и связанными с ним данными управления сетью), чьи характеристики определены техническими требования 3GPP. В некоторых вариантах осуществления менеджер 128 IRP может быть включен в и/или реализован с помощью микросхемы, набора микросхем или другого семейства программируемых и/или переконфигурируемых схем.

В различных вариантах осуществления менеджер 108 элементов может включать в себя агент 132 IRP. Агент 132 IRP может поддерживать связь с менеджером 128 IRP сетевого менеджера 104 (например, через интерфейс 2-го типа). В некоторых вариантах осуществления агент 132 IRP и/или функция 136 отображения могут быть включены в и/или реализованы с помощью микросхемы, набора микросхем или другого семейства программируемых и/или переконфигурируемых схем.

Менеджер 128 IRP и агент 132 IRP могут выполнять ряд функций IRP в сетевой среде 100, включая, но не ограничиваясь ими, операции управления сбоями и конфигурацией. В вариантах осуществления настоящего раскрытия описаны, в частности, операции управления сбоями, выполняемые компонентами IRP.

В различных вариантах осуществления агент 132 IRP может выполнять функцию 136 отображения для преобразования данных управления, например, уведомлений об аварийных сигналах, из первого формата, выработанного и/или используемого AP 120 WLAN, во второй формат, который используется менеджером 128 IRP сетевого менеджера 104, который управляет сетью LTE-A. Например, агент 132 IRP может принимать уведомления об аварийных сигналах из AP 120 WLAN в соответствии с первым форматом, и агент 132 IRP, наряду с функцией 136 отображения, может преобразовывать уведомления об аварийных сигналах из первого формата во второй формат. Агент 132 IRP может в дальнейшем отправить уведомления об аварийных сигналах во втором формате в сетевой менеджер 104 (например, в менеджер 128 IRP сетевого менеджера 104).

В некоторых вариантах осуществления первый формат, в котором уведомления об аварийных сигналах принимаются из AP 120 WLAN, может представлять собой стандартизированный формат Интернет, такой как, но неограниченный этим, формат рабочей группы проектирования Интернет (IETF). Второй формат, в котором уведомления об аварийных сигналах передаются в менеджер 128 IRP, может представлять собой формат сотовых стандартов, такой как, но не ограниченный этим, формат 3GPP. В некоторых вариантах осуществления уведомления об аварийных сигналах во втором формате могут быть совместимыми с уведомлениями об аварийных сигналах, заданными в стандарте 3GPP TS 32.111-2, версии V12.0.0 (2014-10-02).

Агент 132 IRP и функция 136 отображения могут позволить сетевому менеджеру 104 и/или менеджеру 108 элементов извлечь уведомления об аварийных сигналах (и другие данные) из AP 120 WLAN. Сетевой менеджер 104 и/или менеджер 108 элементов могут использовать уведомления об аварийных сигналах из AP 120 WLAN для управления сетью LTE-A. Например, аварийный сигнал может показывать рабочее состояние AP WLAN, чтобы показать, является ли доступным сетевое соединение через AP 120 WLAN (например, способно ли AP 120 WLAN передавать пакеты данных). Например, в некоторых вариантах осуществления аварийный сигнал может включать в себя объект ifOperStatus, управляемый AP 120 WLAN, чтобы показать рабочее состояние интерфейса, связанного с AP 120 WLAN. Интерфейс, связанный с AP 120 WLAN, может относиться к интерфейсу связи, который можно использовать для передачи пакетов данных/управления из/в AP 120 WLAN.

Объект ifOperStatus может представлять собой объект, такой, например, который описан в документе IETF RFC 2863 (2000). AP 120 WLAN может внедрить объект ifOperStatus в уведомление linkUp/linkDown для передачи отчетов о различных аварийных сигналах AP WLAN. Примеры аварийных сигналов на основе уведомлений linkUp/linkDown, аналогичных тем, которые описаны в документе IETF RFC 3877 (2004), показаны ниже.

linkDown NOTIFICATION-TYPE

OBJECTS { iflndex, ifAdminStatus, ifOperStatus }

STATUS current

DESCRIPTION

""

::= { snmpTraps 3 }

linkUp NOTIFICATION-TYPE

OBJECTS { iflndex, ifAdminStatus, ifOperStatus }

STATUS current

DESCRIPTION

""

::= { snmpTraps 4 }"

alarmModellndex 3

alarmModelState 1

alarmModelNotificationld linkUp

alarmModelVarbindlndex 0

alarmModelVarbindValue 0

alarmModelDescription "linkUp"

alarmModelSpecificPointer ituAlarmEntry.3.1

alarmModelVarbindSubtree iflndex (1.3.6.1.2.1.2.2.1.1)

alarmModelResourcePrefix 0.0

alarmModelRowStatus active (1)

ituAlarmEventType communicationsAlarm (2)

ituAlarmPerceivedSeverity cleared (1)

ituAlarmGenericModel alarmModelEntry.3.1

alarmModellndex 3

alarmModelState 3

alarmModelNotificationld linkDown

alarmModelVarbindlndex 2

alarmModelVarbindValue up (1)

alarmModelDescription "linkDown - confirmed problem"

alarmModelSpecificPointer ituAlarmEntry .3.3

alarmModelVarbindSubtree iflndex (1.3.6.1.2.1.2.2.1.1)

alarmModelResourcePrefix 0.0

alarmModelRowStatus active (1)

ituAlarmEventType communicationsAlarm (2)

ituAlarmPerceivedSeverity critical (3)

ituAlarmGenericModel alarmModelEntry.3.3

AP 120 WLAN может отправить уведомление об аварийном сигнале тогда, когда объект ifOperStatus изменяет свое значение. Значение объекта ifOperStatus будет показано ниже в соответствии с RFC 2863 согласно некоторым вариантам осуществления.

ifOperStatus OBJECT-TYPE

SYNTAX INTEGER {

up(l), -- готов передавать пакеты

down(2),

testing(3), -- находится в некотором тестовом режиме

unknown(4), -- статус нельзя определить по какой-либо причине

dormant(5),

notPresent(6), -- какой-то компонент отсутствует

lowerLayerDown(7) -- не готов передавать пакеты из-за состояния интерфейса(ов) более низкого уровня

}

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Текущее рабочее состояние интерфейса. Состояние testing(3) показывает, что могут передаваться нерабочие пакеты. Если ifAdminStatus имеет значение down(2), то ifOperStatus должен иметь значение down(2). Если ifAdminStatus изменяется на значение up(l), то ifOperStatus должен изменяться на значение up(l), если интерфейс готов передавать и принимать сетевой трафик; необходимо изменить значение на dormant(5), если интерфейс ожидает внешних действий (таких как последовательная линия, ожидающая входящего соединения); следует сохранить состояние down(2), если и только если существует сбой, который предотвращает его переход в состояние up(l); следует оставить состояние notPresent(6), если интерфейс имеет отсутствующие компоненты (как правило, аппаратные средства)".

:= { iffintry 8 }

Состояние lowerLayerDown(7) может представлять собой тип состояния down, которое показывает, что интерфейс, который основывается на этом более низком уровне, не готов передавать пакеты (down), например, не работает. Управление ifAdminStatus может осуществляться администратором или оператором. Например, администратор может принять решение отключить AP 120 WLAN и установить ifAdminStatus на значение down. В этом случае ifOperStatus может также равняться значению down. Администратор может включить AP 120 WLAN путем установки ifAdminStatus на значение up. ifOperStatus можно затем также установить на значение up (до тех пор, пока нет других проблем с интерфейсом, которые помешали бы ему находиться в рабочем состоянии, при этом он будет по-прежнему не готов передавать пакеты).

После приема уведомления об аварийном сигнале из AP 120 WLAN в первом формате агент 132 IRP вместе с функцией 136 отображения может отобразить уведомление об аварийном сигнале в уведомление об аварийном сигнале во втором формате. На фиг.2 показана блок-схема последовательности операций, которая описывает операции агента 132 IRP в соответствии с некоторыми вариантами осуществления.

Как описано в данном документе, агент 132 IRP может выполнять много операций. Можно понять, что при выполнении этих операций агент 132 IRP может получить доступ к или иным образом использовать функцию 136 отображения. Функция 136 отображения может содержать правила или логику, такие, например, которые, в общем, проиллюстрированы и описаны на схеме языка спецификации и описания (SDL) фиг.2, которые обеспечивают отображение уведомлений об аварийных сигналах в первом формате в уведомления об аварийных сигналах во втором формате. Таким образом, в некоторых вариантах осуществления описанные операции, которые выполняются агентом 132 IRP, могут быть выполнены с помощью агента 132 IRP совместно с функцией 136 отображения.

На этапе 204 AP 120 WLAN может передать уведомление об аварийном сигнале WLAN, включая объект ifOperStatus, в агент 132 IRP. На этапе 208 агент 132 IRP может определить, соответствует ли недавно принятое уведомление об аварийном сигнале WLAN активному аварийному сигналу.

Агент 132 IRP может определить, соответствует ли недавно принятое уведомление об аварийном сигнале WLAN активному аварийному сигналу путем проверки списка аварийных сигналов, доступного менеджеру 108 элементов для информации об аварийном сигнале, которая соответствует недавно принятому уведомлению об аварийном сигнале. Список аварийных сигналов можно хранить локальным образом в менеджере 108 элементов или можно хранить удаленным образом, но доступным для менеджера 108 элементов. Информацию об аварийном сигнале можно идентифицировать в списке аварийных сигналов с помощью ID аварийных сигналов. В различных вариантах осуществления информация об аварийном сигнале может быть связана с рядом различных атрибутов. Например, информация об аварийном сигнале может включать в себя notificationID для идентификации уведомления, которое несет в себе информацию об аварийном сигнале; alarmRaisedTime для указания даты и времени, когда первоначально появился аварийный сигнал за счет аварийного ресурса; alarmChangedTime для указания последней даты и времени, когда изменилась информация об аварийном сигнале в соответствии с аварийным ресурсом; alarmClearedTime для указния даты и времени, когда был сброшен аварийный сигнал; eventType, который может также упоминаться как alarmType для указаний типа событий/аварийного сигнала; probableCause для оценки аварийного сигнала и предоставления информации в дополнение к информации о типе события; perceivedSeverity для указания относительного уровня срочности для привлечения внимания оператора; и т.д. В различных вариантах осуществления список аварийных сигналов может быть аналогичным списку, описанному в документе 3GPP TS 32.11 1-2.

Если на этапе 208 определяется, что отсутствует информация об аварийном сигнале в списке аварийных сигналов, который соответствует уведомлению об аварийном сигнале WLAN, агент 132 IRP может выработать преобразованное уведомление об аварийном сигнале, которое показывает, что новый аварийный сигнал был выдан AP 120 WLAN. Параметры преобразованного уведомления об аварийном сигнале могут быть основаны на значении объекта ifOperStatus.

Например, на этапе 212 агент 132 IRP определяет, равен ли ifOperStatus значению down. Это значение может указывать на то, что рабочее состояние интерфейса, связанного с AP 120 WLAN, имеет значение down, то есть не работает. Интерфейс можно быть интерфейсом связи AP 120 WLAN, который поддерживает связь с сетевыми компонентами или пользовательским оборудованием (UE) LTE.

Если ifOperStatus равен значению down, агент 132 IRP может, на этапе 216, добавить информацию об аварийном сигнале, соответствующую уведомлению об аварийном сигнале WLAN, в список аварийных сигналов активных аварийных сигналов. Агент 132 IRP может также выработать преобразованное уведомление об аварийном сигнале и отправить преобразованное уведомление об аварийном сигнале в менеджер 128 IRP.

В некоторых вариантах осуществления преобразованное уведомление об аварийном сигнале, выработанное после положительного определения на этапе 212, может иметь тип уведомления "notifyNewAlarm"; экземпляр объекта, который показывает ID AP 120 WLAN; возможную причину "сбой приемопередатчика"; воспринятый уровень серьезности как "критический" или "важный"; и тип аварийного сигнала как "аварийный сигнал связи". Тип аварийного сигнала связи может быть связан с процедурой и/или процессом, который использует передачу информации из одного пункта в другой. Уведомление об аварийном сигнале, имеющее тип уведомления "notifyNewAlarm", которое может также упоминаться просто как уведомление notifyNewAlarm, может уведомлять менеджер 128 IRP о наличии нового аварийного сигнала по отношению к интерфейсу, связанному с AP 120 WLAN.

Если на этапе 212 агент 132 IRP определяет, что ifOperStatus не равен значению down, процесс может перейти к этапу 220, где агент 132 IRP может определить, равен ли ifOperStatus значению lowerLayerDown, который может показывать, что более низкий уровень, от которого может зависеть интерфейс, является нерабочим.

Если на этапе 220 агент 132 IRP определяет, что ifOperStatus равен значению lowerLayerDown, агент 132 IRP на этапе 226 может добавить информацию об аварийном сигнале, соответствующую уведомлению об аварийном сигнале WLAN, в список аварийных сигналов активных аварийных сигналов. Агент 132 IRP может также выработать преобразованное уведомление об аварийном сигнале и отправить преобразованное уведомление об аварийном сигнале в менеджер 128 IRP. В этом случае преобразованное уведомление об аварийном сигнале может быть уведомлением об аварийном сигнале notifyNew, которое имеет экземпляр объекта, который показывает ID AP 120 WLAN; возможную причину "сбой системы связи"; воспринятый уровень серьезности как "незначительный"; и тип аварийного сигнала как "аварийный сигнал связи".

Если на этапе 208 агент 132 IRP определяет, что недавно принятое уведомление об аварийном сигнале равносильно активному аварийному сигналу, процесс может перейти к этапу 228. На этапе 228 агент 132 IRP может определить, равен ли ifOperStatus значению down. Если это так, агент 132 IRP может обновить информацию об аварийном сигнале в списке аварийных сигналов и выработать преобразованное уведомление об аварийном сигнале, имеющее тип уведомления "notifyChangedAlarm", который может также упоминаться как уведомление notifyChangedAlarm, которое показывает, что аварийный сигнал был изменен, но еще не сброшен. Уведомление notifyChangedAlarm может включать в себя экземпляр объекта, который показывает ID AP 120 WLAN; возможную причину "сбой приемопередатчика"; воспринятый уровень серьезности как "значительный" или "критический"; и тип аварийного сигнала как "аварийный сигнал связи". Агент 132 IRP может затем отправить уведомление notifyChangedAlarm в менеджер 128 IRP.

Если на этапе 228 агент 132 IRP определяет, что ifOperStatus не равен значению down(2), процесс может перейти к этапу 232. На этапе 232 агент 132 IRP может определить, равен ли ifOperStatus значению lowerLayerDown. Если это так, агент 132 IRP может обновить информацию об аварийном сигнале в списке аварийных сигналов и выработать уведомление notifyChangedAlarm, имеющее экземпляр объекта, который показывает ID AP 120 WLAN; возможную причину "сбой системы связи"; воспринятый уровень серьезности как "незначительный"; и тип аварийного сигнала как "аварийный сигнал связи". Агент 132 IRP может затем отправить уведомление notifyChangedAlarm в менеджер 128 IRP.

Если на этапе 232 агент 132 IRP определяет, что ifOperStatus не равен значению lowerLayerDown, процесс может перейти к этапу 236. На этапе 236 агент 132 IRP может определить, равен ли ifOperStatus значению up, которое может показывать, что интерфейс стал работающим. В этой ситуации агент 132 IRP может удалить недавно принятый аварийный сигнал из списка активных аварийных сигналов на этапе 240 и выработать преобразованное уведомление об аварийном сигнале, имеющее тип уведомления "notifyClearedAlarm", которое может упоминаться как уведомление notifyClearedAlarm. Уведомление notifyClearedAlarm может включать в себя экземпляр объекта, который показывает ID AP 120 WLAN; возможную причину "сбой приемопередатчика"; воспринятый уровень серьезности "сброшен"; и тип аварийного сигнала "аварийный сигнал связи". Агент 132 IRP может затем отправить преобразованное уведомление об аварийном сигнале в менеджер 128 IRP.

Если на этапе 236 агент 132 IRP определяет, что ifOperStatus не равен значению up, процесс может закончится. В этой ситуации ifOperStatus можно установить на значение, которое не соответствует уведомлению об аварийном сигнале, который имеет второй формат.

Модель сетевых ресурсов (NRM) AP 120 WLAN может быть определена способом, распознаваемым системой операций, администрирования и управления (OAM) сотовой сети, например, сети 3GPP. Создание соответствующей модели сетевых ресурсов AP 120 WLAN позволяет обеспечить передачу информацию о сетевом ресурсе между агентом 132 IRP и менеджером 128 IRP для целей управления телекоммуникационной сетью, в том числе, например, для управления конвергированными сетями.

В некоторых вариантах осуществления множество классов, например, классов информационных объектов (IOC), может инкапсулировать информацию, имеющую отношение к компонентам IRP. IOC может представлять собой аспект управления сетевыми ресурсами. Это позволяет описывать информацию, которая может проходить и/или использоваться в интерфейсах управления. Представления могут быть технологическими агностическими объектами программного обеспечения. IOC может иметь атрибуты, которые представляют различные свойства класса объектов. IOC может поддерживать операции, предоставляющие услуги управления сетью, и может быть задействован по мере необходимости для этого конкретного класса объектов. IOC может поддерживать уведомления, которые сообщают о появлении событий, относящихся к этому классу объектов. IOC можно моделировать, используя стандартный "класс" в метамодели унифицированного языка моделирования (UML). NRM может представлять собой семейство IOC, представляющее собой множество сетевых ресурсов в оперативном управлении.

На фиг.3 показана иерархия именования/вместимости NRM WLAN и ассоциации классов 300 в соответствии с некоторыми вариантами осуществления. Таким образом, AP WLAN IOOC может представлять собой AP WLAN и может содержаться в ManagedElement IOC, как показано на фиг.3.

На фиг.4 показана иерархия 400 наследования NRM WLAN в соответствии с различными вариантами осуществления. Иерархия 400 может показывать, что WLAN AP IOC может наследоваться от ManagedFunction IOC.

IOC ManagedElement и IOC ManagedFunction (фиг.3 и 4) могут иметь элементы, аналогичные тем, которые описаны в документах 3GPP TS 32,622 версии 11 (2013-06-28) и 3GPP TS 28.622 VI 1.0.0 (2012-12).

Для того, чтобы представить функциональные возможности точки доступа WLAN, можно определить класс точки доступа WLAN. Класс может включать в себя атрибуты, которые представлены в таблице 1.

Таблица 1

Имя атрибута Квалификатор поддержки Считываемый Записываемый Инвариантный Уведомляемый wlanApID M - - - M

Множество действующих уведомлений для AP WLAN, идентифицированных с помощью wlanApID, может включать в себя notifyChangedAlarm, notifyClearedAlarm и notifyNewAlarm. Эти уведомления могут быть аналогичными уведомлениям, заданным по отношению к IRP аварийного сигнала в стандарте 3GPP TS 32.111-2.

wlanApID может быть атрибутом, который присутствует в нескольких IOC. Этот атрибут может иметь параметр "имя+значение", который можно использовать в качестве относительно различимого имени (RDN) при наименовании экземпляра класса объекта. Это RDN может идентифицировать уникальным образом экземпляр объекта в пределах своего содержания, например, родительский экземпляр объекта.

На фиг.5 показан менеджер 108 элементов в соответствии с различными вариантами осуществления. Менеджер 108 элементов может включать в себя схему 504 передачи и схему 508 приема, соединенную со схемой 512 отображения.

Схема 504 передачи и схема 508 приема могут включать в себя соответствующую схему для обеспечения связи через один или более интерфейсов связи. В некоторых вариантах осуществления схема 504 передачи и схема 508 приема могут включать в себя схему для обеспечения связи через интерфейс 2-го типа с сетевым менеджером 104 и могут дополнительно включать в себя схему для обеспечения связи через интерфейс для поддержания связи с контроллером 124 доступа и/или AP 120 WLAN.

Схема 512 отображения может обеспечить функциональные возможности, ранее описанные по отношению к агенту 132 IRP и функции 136 отображения. Схема 512 отображения может осуществлять доступ к списку 516 аварийных сигналов и логической схеме 520 с функцией отображения для обеспечения операций преобразования. Список 516 аварийных сигналов и логическая схема 520 с функцией отображения могут находиться в компонентах запоминающего устройства/памяти схемы 512 отображения, которые показаны в общих чертах, или к ним можно получить доступ удаленным образом, например, через схему 504 передачи и схему 508 приема.

Компоненты менеджера 108 элементов можно сконфигурировать с возможностью выполнения процессов, которые показаны на фиг.6 в соответствии с некоторыми вариантами осуществления. В частности, на этапе 604 схема 508 приема может принять, из AP 120 WLAN, уведомление об аварийном сигнале согласно первому формату. Уведомление об аварийном сигнале можно подать в схему 512 отображения.

На этапе 608 схема 512 отображения может преобразовать уведомление об аварийном сигнале из первого формата в преобразованное уведомление об аварийном сигнале согласно второму формату, который будет использоваться менеджером 128 IRP, который может управлять аспектами сети LTE-A. Схема 512 отображения может использовать список 516 аварийных сигналов и логическую схему 522 с функцией отображения для выполнения процесса преобразования, аналогичного тому, который описан выше по отношению к схеме SDL (фиг.2) в соответствии с некоторыми вариантами осуществления.

На этапе 612 схема 512 отображения может управлять схемой передачи для передачи преобразованного уведомления об аварийном сигнале в менеджер 128 IRP. Как описано выше, преобразованные уведомления об аварийном сигнале можно передать в менеджер 128 IRP через интерфейс 2-го типа.

Cетевой менеджер 104, менеджер 108 элементов, AP 120 WLAN и/или контроллер 124 доступа, описанный в данном документе, можно реализовать в виде системы, используя любые подходящие аппаратные средства и/или программное обеспечение для конфигурирования по своему желанию. На фиг.7 показан еще один вариант осуществления примерной системы 700, содержащей схему 704 связи, схему 708 приложения, память/запоминающее устройство 712, дисплей 716, камеру 720, датчик 724 и интерфейс 728 ввода/вывода (I/O), которые соединены друг с другом по меньшей мере так, как это показано. В некоторых вариантах осуществления некоторые или все компоненты, образующие схему 704 связи, схему 708 приложения и/или память/запоминающее устройство 712, можно выполнить вместе в виде системы на кристалле (SOC).

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

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

В вариантах осуществления, в которых система 700 сконфигурирована для беспроводной связи, схема 704 связи может включать в себя радиочастотную или основополосную схему для обеспечения связи, совместимой с одной или более технологиями радиосвязи. Например, в некоторых вариантах осуществления схема 704 связи может поддерживать связь с помощью развитой универсальной земной сети радиодоступа (EUTRAN) и/или других беспроводных городских сетей (WMAN), беспроводной локальной сети (WLAN), беспроводной персональной сети (WPAN).

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

В различных вариантах осуществления интерфейс 728 I/O может включать в себя один или более пользовательских интерфейсов, предназначенных для обеспечения взаимодействия между пользователем и системой, и/или интерфейсы периферийных компонентов, предназначенных для обеспечения взаимодействия между периферийными компонентами и системой. Пользовательские интерфейсы могут включать в себя, но не ограничиваться ими, физическую клавиатуру или кнопочную панель, сенсорную панель, динамик, микрофон и т.д. Интерфейсы периферийных компонентов могут включать в себя, но не ограничиваются ими, порт энергонезависимой памяти, порт универсальной последовательной шины (USB), аудиоразъем и интерфейс питания.

В различных вариантах осуществления датчик 724 может включать в себя одно или более воспринимающих устройств для определения условий окружающей среды и/или информации о местоположении, которая относится к системе. В некоторых вариантах осуществления датчики могут включать в себя, но не ограничиваться ими, гиродатчик, акселерометр, датчик близости, датчик внешней освещенности и блок определения местоположения. Блок определения местоположения может быть также частью или взаимодействовать со схемой 704 связи для поддержания связи с компонентами сети определения местоположения, например, с глобальной спутниковой системой определения местоположения (GPS).

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

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

В различных вариантах осуществления система может иметь большее или меньшее количество компонентов и/или различные архитектуры.

Некоторые неограничивающие примеры представлены ниже.

Пример 1 включает в себя один или более постоянных машиночитаемых носителей, имеющих инструкции, которые при их исполнении предписывают менеджеру элементов: определить первое уведомление об аварийном сигнале, принятое из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), которое включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние интерфейса, связанного с AP WLAN, имеет значение down; определить, что первое уведомление об аварийном сигнале не соответствует активному аварийному сигналу в списке аварийных сигналов, хранящемся в менеджере элементов; и выработать на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение down, и определения, что первое уведомление об аварийном сигнале не соответствует активному аварийному сигналу, второе уведомление об аварийном сигнале, имеющее тип уведомления об аварийном сигнале notifyNew, для уведомления менеджера эталонных точек интеграции (IRP) сотовой сети о новом аварийном сигнале.

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

Пример 3 включает в себя один или более постоянных машиночитаемых носителей согласно примеру 1 или 2, в которых инструкции, при их исполнении, дополнительно предписывают менеджеру элементов: проверить список аварийных сигналов для информации об аварийном сигнале, которая соответствует первому уведомлению об аварийном сигнале; и определить, что первое уведомление об аварийном сигнале не соответствует активному аварийному сигналу на основании упомянутой проверки списка аварийных сигналов.

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

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

Пример 6 включает в себя один или более постоянных машиночитаемых носителей из любых примеров 1-5, в которых второе уведомление об аварийном сигнале включает в себя идентификационные данные AP WLAN.

Пример 7 включает в себя один или более постоянных машиночитаемых носителей из любых примеров 1-6, в которых второе уведомление об аварийном сигнале включает в себя тип аварийного сигнала для аварийного сигнала связи.

Пример 8 включает в себя один или более постоянных машиночитаемых носителей из любых примеров 1-7, в которых второе уведомление об аварийном сигнале содержит уведомление об аварийном сигнале проекта партнерства 3-го поколения (3GPP).

Пример 9 включает в себя устройство, например, менеджер элементов, содержащее: схему приема для приема, из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), уведомления об аварийном сигнале согласно первому формату; схему отображения, соединенную со схемой приема, для преобразования уведомления об аварийном сигнале из первого формата в преобразованное уведомление об аварийном сигнале согласно второму формату, которое будет использоваться менеджером эталонных точек интеграции (IRP), который управляет аспектами сотовой сети, причем преобразованное уведомление об аварийном сигнале представляет собой уведомление об аварийном сигнале notifyNew, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный значению down, и уведомление об аварийном сигнале не совпадает с любым существующим активным аварийным сигналом в устройстве; и схему передачи, соединенную со схемой отображения, для передачи преобразованного уведомления об аварийном сигнале в менеджер IRP.

Пример 10 включает в себя устройство примера 9, в котором устройство содержит агент IRP, и менеджер IRP представляет собой менеджер IRP сетевого менеджера (NM).

Пример 11 включает в себя устройство примера 9 или 10, в котором объект ifOperStatus, равный значению down, должен указывать, что интерфейс, связанный с AP WLAN, не работает.

Пример 12 включает в себя устройство из любых примеров 9-11, в котором схема отображения должна добавить уведомление об аварийном сигнале в активный список аварийных сигналов.

Пример 13 включает в себя устройство из любых примеров 9-12, в котором схема передачи должна передать преобразованное уведомление об аварийном сигнале в менеджер IRP через интерфейс 2-го типа.

Пример 14 включает в себя устройство из любых примеров 9-13, в котором преобразованное уведомление об аварийном сигнале представляет собой уведомление notifyClearedAlarm, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный значению up, и уведомление об аварийном сигнале соответствует существующему активному аварийному сигналу в устройстве.

Пример 15 включает в себя устройство примера 14, в котором схема отображения должна удалять, из списка аварийных сигналов, информацию об аварийном сигнале, соответствующую уведомлению об аварийном сигнале, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный значению up.

Пример 16 включает в себя устройство из любых примеров 9-15, в котором преобразованное уведомление об аварийном сигнале представляет собой уведомление об аварийном сигнале notifyNew, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный lowerLayerDown, и уведомление об аварийном сигнале не соответствует существующему активному аварийному сигналу в устройстве.

Пример 17 включает в себя устройство из любых примеров 9-16, в котором преобразованное уведомление об аварийном сигнале представляет собой уведомление notifyChangedAlarm, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный значению down, и уведомление об аварийном сигнале соответствует существующему активному аварийному сигналу в устройстве.

Пример 18 включает в себя устройство из любых примеров 9-17, в котором преобразованное уведомление об аварийном сигнале представляет собой уведомление notifyChangedAlarm, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный lowerLayerDown, и уведомление об аварийном сигнале соответствует существующему активному аварийному сигналу в устройстве.

Пример 19 включает в себя один или более постоянных машиночитаемых носителей, имеющих инструкции, которые при их исполнении предписывают менеджеру элементов: определить первое уведомление об аварийном сигнале, принятое из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), которое включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние интерфейса, связанного с AP WLAN, имеет значение up; определить, что первое уведомление об аварийном сигнале соответствует активному аварийному сигналу в списке аварийных сигналов, хранящемся в менеджере элементов; и выработать на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение up, и определения, что первое уведомление об аварийном сигнале соответствует активному аварийному сигналу, второе уведомление об аварийном сигнале, имеющее тип уведомления notifyClearedAlarm, для уведомления менеджера эталонных точек интеграции (IRP) сотовой сети об измененном аварийном сигнале.

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

Пример 21 включает в себя один или более постоянных машиночитаемых носителей согласно примеру 19 или 20, в котором инструкции, при их исполнении, дополнительно предписывают менеджеру элементов: проверить список аварийных сигналов для информации об аварийном сигнале, которая соответствует первому уведомлению об аварийном сигнале; и определить, что первое уведомление об аварийном сигнале соответствует активному аварийному сигналу на основании упомянутой проверки списка аварийных сигналов.

Пример 22 включает в себя один или более постоянных машиночитаемых носителей согласно примеру 21, в котором инструкции, при их исполнении, дополнительно предписывают менеджеру элементов, удалить информацию об аварийном сигнале, которая соответствует первому уведомлению об аварийном сигнале из списка аварийных сигналов на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение up.

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

Пример 24 включает в себя один или более постоянных машиночитаемых носителей из любых примеров 19-23, в котором второе уведомление об аварийном сигнале включает в себя идентификационные данные AP WLAN.

Пример 25 включает в себя один или более постоянных машиночитаемых носителей из любых примеров 19-24, в котором второе уведомление об аварийном сигнале включает в себя тип аварийного сигнала для аварийного сигнала связи.

Пример 26 включает в себя способ, выполняемый, например, менеджером элементов, причем способ содержит определение первого уведомления об аварийном сигнале, принятого из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), которое включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние интерфейса, связанного с AP WLAN, имеет значение down; определение, что первое уведомление об аварийном сигнале не соответствует активному аварийному сигналу в списке аварийных сигналов, хранящемся в менеджере элементов; и выработку на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение down, и определения, что первое уведомление об аварийном сигнале не соответствует активному аварийному сигналу, второе уведомление об аварийном сигнале, имеющее тип уведомления об аварийном сигнале notifyNew, для уведомления менеджера эталонных точек интеграции (IRP) сотовой сети о новом аварийном сигнале.

Пример 27 включает в себя способ согласно примеру 26, дополнительно содержащий: передачу второго уведомления об аварийном сигнале в менеджер IRP через интерфейс 2-го типа.

Пример 28 включает в себя способ согласно примеру 26 или 27, дополнительно содержащий: проверку списка аварийных сигналов для информации об аварийном сигнале, которая соответствует первому уведомлениюоб аварийном сигнале; и определение, что первое уведомление об аварийном сигнале не соответствует активному аварийному сигналу на основании упомянутой проверки списка аварийных сигналов.

Пример 29 включает в себя способ из любых примеров 26-28, в котором второе уведомление об аварийном сигнале должно показывать сбой приемопередатчика в качестве возможной причины рабочего состояния.

Пример 30 включает в себя способ из любых примеров 26-29, в котором второе уведомление об аварийном сигнале должно показывать воспринятый уровень серьезности как критический или важный.

Пример 31 включает в себя способ из любых примеров 26-30, в котором второе уведомление об аварийном сигнале включает в себя идентификационные данные AP WLAN.

Пример 32 включает в себя способ из любых примеров 26-31, в котором второе уведомление об аварийном сигнале включает в себя тип аварийного сигнала для аварийного сигнала связи.

Пример 33 включает в себя способ из любых примеров 26-32, в котором второе уведомление об аварийном сигнале содержит уведомление об аварийном сигнале проекта партнерства 3-го поколения (3GPP).

Пример 34 включает в себя способ, выполняемый, например, менеджером элементов, способ содержащий: определение первого уведомления об аварийном сигнале, принятого из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), которое включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние интерфейса, связанного с AP WLAN, имеет значение up; определение, что первое уведомление об аварийном сигнале соответствует активному аварийному сигналу в списке аварийных сигналов, хранящемся в менеджере элементов; и выработку на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение up, и определения, что первое уведомление об аварийном сигнале соответствует активному аварийному сигналу, второе уведомление об аварийном сигнале, имеющее тип уведомления notifyClearedAlarm, для уведомления менеджера эталонных точек интеграции (IRP) сотовой сети об измененном аварийном сигнале.

Пример 35 включает в себя способ согласно примеру 34, дополнительно содержащий: передачу второго уведомления об аварийном сигнале в менеджер IRP через интерфейс 2-го типа.

Пример 36 включает в себя способ согласно примеру 34 или 35, дополнительно содержащий: проверку списка аварийных сигналов для информации об аварийном сигнале, которая соответствует первому уведомлению об аварийном сигнале; и определение, что первое уведомление об аварийном сигнале соответствует активному аварийному сигналу на основании упомянутой проверки списка аварийных сигналов.

Пример 37 включает в себя способ из любых примеров 34-36, дополнительно содержащий: удаление информации об аварийном сигнале, которая соответствует первому уведомлению об аварийном сигнале из списка аварийных сигналов на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение up.

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

Пример 39 включает в себя способ из любых примеров 34-38, в котором второе уведомление об аварийном сигнале включает в себя идентификационные данные AP WLAN.

Пример 40 включает в себя способ из любых примеров 34-39, в котором второе уведомление об аварийном сигнале включает в себя тип аварийного сигнала для аварийного сигнала связи.

Пример 41 может включать в себя способ, содержащий, прием, с помощью агента эталонных точек интеграции (IRP) из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), уведомления об аварийном сигнале согласно первому формату; отображение, с помощью агента IRP, уведомления об аварийном сигнале из первого формата в преобразованное уведомление об аварийном сигнале согласно второму формату, которое будет использоваться менеджером IRP, который управляет сетью стандарта усовершенствованного проекта долгосрочного развития (LTE-A); и передачу, с помощью агента IRP, преобразованного уведомления об аварийном сигнале в менеджер IRP.

Пример 42 может включать в себя способ согласно примеру 41, в котором агент IRP представляет собой агент IRP менеджера элементов (EM) IRP, и менеджер IRP представляет собой менеджер IRP сетевого менеджера (NM) IRP.

Пример 43 может включать в себя способ согласно примеру 41 или 42, в котором уведомление об аварийном сигнале относится к изменению в объекте ifOperStatus, который относится к состоянию AP WLAN.

Пример 44 может включать в себя способ согласно примеру 43, в котором уведомление об аварийном сигнале относится к изменению в значении объекта ifOperStatus.

Пример 45 может включать в себя способ из любых примеров 40-44, в котором первый формат относится к формату WLAN, и второй формат относится к формату проекта партнерства третьего поколения (3GPP), и способ дополнительно содержащее преобразование, с помощью агента IRP, уведомления об аварийном сигнале согласно первому формату в преобразованное уведомление об аварийном сигнале согласно второму формату на основании значения объекта ifOperStatus.

Пример 46 может включать в себя способ из любых примеров 40-45, в котором уведомление об аварийном сигнале не совпадает с любым существующим активным аварийным сигналом в агенте IRP, и способ дополнительно содержит передачу, с помощью агента IRP, уведомлений notifyNewAlarm со значительной серьезностью в менеджер IRP, если ifOperStatus = down; или передачу, с помощью агента IRP, уведомлений notifyNewAlarm с незначительной серьезностью в менеджер IRP, если ifOperStatus = lowerLayerDown.

Пример 47 может включать в себя способ из любых примеров 40-46, в котором уведомление об аварийном сигнале добавлено в активный список аварийных сигналов.

Пример 48 может включать в себя способ из любых примеров 40-47, в котором уведомление об аварийном сигнале совпадает с существующим активным аварийным сигналом, и способ дополнительно содержит передачу, с помощью агента IRP, уведомлений notifyChangedAlarm со значительной серьезностью в менеджер IRP, если ifOperStatus = down; или передачу, с помощью агента IRP, уведомлений notifyChangedAlarm с незначительной серьезностью в менеджер IRP, если ifOperStatus = lowerLayerDown; или передачу, с помощью агента IRP, уведомлений ClearedAlarm со сброшенной серьезностью в менеджер IRP, если ifOperStatus = up.

Пример 49 может включать в себя способ согласно примеру 48, в котором существующий активный аварийный сигнал удаляется из списка активных аварийных сигналов, если ifOperStatus = up.

Пример 50 включает в себя менеджер элементов, имеющий средство для выполнения любого способа из примеров 26-49. Описание, представленное в данном документе, иллюстрированных реализаций, в том числе то, что описано в реферате, не предназначено быть исчерпывающим или ограничивающим настоящее раскрытие точными раскрытыми формами. Хотя конкретные реализации и примеры описаны в данном документе для иллюстративных целях, различные эквивалентные модификации возможны в пределах объема раскрытия, как это будет понятно специалистам в данной области техники. Эти модификации могут быть сделаны в раскрытии в свете вышеописанного подробного описания.

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

1. Один или более постоянных машиночитаемых носителей, имеющих инструкции, которые при их исполнении предписывают менеджеру элементов:

определить первое уведомление об аварийном сигнале, принятое из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), которое включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние интерфейса, связанного с AP WLAN, имеет значение down;

определить, что первое уведомление об аварийном сигнале не соответствует активному аварийному сигналу в списке аварийных сигналов, хранящемся в менеджере элементов; и

выработать, на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение down, и определения, что первое уведомление об аварийном сигнале не соответствует активному аварийному сигналу, второе уведомление об аварийном сигнале, имеющее тип уведомления об аварийном сигнале notifyNewAlarm, для уведомления менеджера эталонных точек интеграции (IRP) сотовой сети о новом аварийном сигнале.

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

3. Один или более постоянных машиночитаемых носителей по п.1, в которых инструкции, при их исполнении, дополнительно предписывают менеджеру элементов: проверить список аварийных сигналов для информации об аварийном сигнале, которая соответствует первому уведомлению об аварийном сигнале; и

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

4. Один или более постоянных машиночитаемых носителей по п.1, в которых второе уведомление об аварийном сигнале должно показывать сбой приемопередатчика в качестве возможной причины рабочего состояния.

5. Один или более постоянных машиночитаемых носителей по п.1, в которых второе уведомление об аварийном сигнале должно показывать воспринятый уровень серьезности как критический или важный.

6. Один или более постоянных машиночитаемых носителей по п.1, в которых второе уведомление об аварийном сигнале включает в себя идентификационные данные AP WLAN.

7. Один или более постоянных машиночитаемых носителей по п.1, в которых второе уведомление об аварийном сигнале включает в себя тип аварийного сигнала для аварийного сигнала связи.

8. Один или более постоянных машиночитаемых носителей по п.1, в которых второе уведомление об аварийном сигнале содержит уведомление об аварийном сигнале проекта партнерства 3-го поколения (3GPP).

9. Устройство уведомления об аварийном сигнале, содержащее:

схему приема для приема, из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), уведомления об аварийном сигнале согласно первому формату;

схему отображения, соединенную со схемой приема, для преобразования уведомления об аварийном сигнале из первого формата в преобразованное уведомление об аварийном сигнале согласно второму формату, которое будет использоваться менеджером эталонных точек интеграции (IRP), который управляет аспектами сотовой сети, причем преобразованное уведомление об аварийном сигнале представляет собой уведомление notifyNewAlarm, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный значению down, и уведомление об аварийном сигнале не совпадает с любым существующим активным аварийным сигналом в устройстве; и

схему передачи, соединенную со схемой отображения, для передачи преобразованного уведомления об аварийном сигнале в менеджер IRP.

10. Устройство по п.9, в котором устройство содержит агент IRP и менеджер IRP представляет собой менеджер IRP сетевого менеджера (NM).

11. Устройство по п.9, в котором объект ifOperStatus, равный значению down, должен указывать, что интерфейс, связанный с AP WLAN, не работает.

12. Устройство по п.9, в котором схема отображения должна добавить уведомление об аварийном сигнале в активный список аварийных сигналов.

13. Устройство по п.9, в котором схема передачи должна передать преобразованное уведомление об аварийном сигнале в менеджер IRP через интерфейс 2-го типа.

14. Устройство по п.9, в котором преобразованное уведомление об аварийном сигнале представляет собой уведомление notifyClearedAlarm, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный значению up, и уведомление об аварийном сигнале соответствует существующему активному аварийному сигналу в устройстве.

15. Устройство по п.14, в котором схема отображения должна удалять из списка аварийных сигналов информацию об аварийном сигнале, соответствующую уведомлению об аварийном сигнале, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный значению up.

16. Устройство по п.9, в котором преобразованное уведомление об аварийном сигнале представляет собой уведомление notifyNewAlarm, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный lowerLayerDown, и уведомление об аварийном сигнале не соответствует существующему активному аварийному сигналу в устройстве.

17. Устройство по п.9, в котором преобразованное уведомление об аварийном сигнале представляет собой уведомление notifyChangedAlarm, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный значению down, и уведомление об аварийном сигнале соответствует существующему активному аварийному сигналу в устройстве.

18. Устройство по п.9, в котором преобразованное уведомление об аварийном сигнале представляет собой уведомление notifyChangedAlarm, если уведомление об аварийном сигнале включает в себя объект ifOperStatus, равный lowerLayerDown, и уведомление об аварийном сигнале соответствует существующему активному аварийному сигналу в устройстве.

19. Один или более постоянных машиночитаемых носителей, имеющих инструкции, которые при их исполнении предписывают менеджеру элементов:

определить первое уведомление об аварийном сигнале, принятое из точки доступа (AP) беспроводной локальной вычислительной сети (WLAN), которое включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние интерфейса, связанного с AP WLAN, имеет значение up;

определить, что первое уведомление об аварийном сигнале соответствует активному аварийному сигналу в списке аварийных сигналов, хранящемся в менеджере элементов; и

выработать на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение up, и определения, что первое уведомление об аварийном сигнале соответствует активному аварийному сигналу, второе уведомление об аварийном сигнале, имеющее тип уведомления notifyClearedAlarm, для уведомления менеджера эталонных точек интеграции (IRP) сотовой сети об измененном аварийном сигнале.

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

21. Один или более постоянных машиночитаемых носителей по п.19, в которых инструкции, при их исполнении, дополнительно предписывают менеджеру элементов:

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

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

22. Один или более постоянных машиночитаемых носителей по п.21, в которых инструкции, при их исполнении, дополнительно предписывают менеджеру элементов удалить информацию об аварийном сигнале, которая соответствует первому уведомлению об аварийном сигнале из списка аварийных сигналов на основании определения, что первое уведомление об аварийном сигнале включает в себя объект ifOperStatus, установленный для указания, что рабочее состояние имеет значение up.