Результат интеллектуальной деятельности: СПОСОБ УПРАВЛЕНИЯ ТАБЛИЦЕЙ ПОСРЕДНИКОВ В БЕСПРОВОДНОЙ СЕТИ, ИСПОЛЬЗУЮЩЕЙ УСТРОЙСТВА-ПОСРЕДНИКИ

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

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

Данное изобретение, например, относится к сетям, содержащим узлы ZigBee Green Power (ʺзеленая энергияʺ).

УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ

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

Одним примером такой технологии является создаваемый стандарт ZigBee Green Power.

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

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

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

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

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

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

Текущая спецификация ZGP предлагает следующие механизмы для обслуживания таблиц посредников.

Создание записи в таблице посредников:

- в процессе ввода в эксплуатацию (возможно, с участием пользователя), когда целевой объект или инструмент ввода в эксплуатацию отправляет управляющее извещение (ZGP: команда ZGP Pairing (создание пар) с флагом AddSink (добавление приемника), установленным в 0b1), информирующее посредника (посредников) о новом созданном отношении управления, включающее идентификатор ограниченного устройства и соответствующий целевой объект (объекты); его можно отправить по широковещанию (с ограниченным диапазоном), с необязательным добавлением посредника (посредников) в таблицу, только если они находятся в диапазоне ограниченного устройства, особенно если устройство указывает постоянное местоположение;

- во время работы,

* посредником, принимающим незатребованное управляющее извещение;

* посредником, принимающим связь от неизвестного ограниченного устройства и наблюдающим другого посредника (посредников), перенаправляющего ее;

* посредником, принимающим связь от неизвестного ограниченного устройства и делающим запрос отношений управления (ZGP: команда ZGP Pairing Search (поиск пар) или широковещательная команда ZGP Notification (уведомление)).

Удаление записи из таблицы посредников:

- прием GPDF вывода из эксплуатации от ограниченного узла в режиме ввода в эксплуатацию (специально инициированный на ограниченном узле);

- прием команды снятия контроля (ZGP: ZGP Pairing с флагом AddSink, установленным в 0b0, или с RemoveZGPD (удаление устройства ZigBee Green Power), установленным в 0b1), специально инициированный на целевом объекте/инструменте ввода в эксплуатацию.

Следующие операции посредника дополнительно выполняются автоматически:

- после приема перенаправленной связи сбрасывается флаг первого для перенаправления;

- после приема запроса на передачу к ограниченному устройству (ZGP: ZGP Response (ответ)) с помощью назначаемого другого посредника он сбрасывает флаг первого для перенаправления и удаляет любые пакеты, стоящие в очереди для доставки этому ограниченному устройству.

Устройство с ограниченными ресурсами может быть, например, устройством ZigBee Green Power (ZGPD) или т.п., которые не имеют батареи или лишь небольшой объем памяти и могут принимать только в незапланированных случаях. Например, ZGPD может быть безбатарейным переключателем, который может принимать только в течение короткого времени, как только он приводится в действие пользователем и передал свой сигнал. Другим примером ZGPD является периодически сообщающий датчик, поглощающий энергию из своего окружения, например, посредством фотогальванического элемента.

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

Цель изобретения - предложить способ эффективного управления таблицей посредников в узле-посреднике.

Другая цель изобретения - достичь одной или более из следующих целей:

1. Удаление устаревших записей в таблице посредников.

2. Предупреждение переполнения таблицы посредников.

3. Предотвращение слишком многих активных посредников на одно ограниченное устройство (в плотных сетях).

4. Гарантия наличия по меньшей мере одного посредника на ограниченное устройство (в плотных сетях).

5. Гарантия оптимальной надежности посредника в соответствии с требованиями приложения (например, требованиями важности и rt).

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Подробная формулировка проблемы

Рассмотрим беспроводную ячеистую сеть, содержащую:

- одно или более ограниченных устройств R, которые ограничены в своей способности отправлять много пакетов или длинные беспроводные пакеты и ограничены в своей способности прослушивать пакеты в течение длительных периодов времени или вообще принимать. Например, устройства, питаемые с помощью механизмов аккумулирования энергии. Ограниченные устройства могут отправлять сообщения, помещая их в пакеты и отправляя их;

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

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

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

Назовем это ʺячеистойʺ сетью для указания, что имеется по меньшей мере одно устройство, которое способно работать в качестве ретранслятора для сообщения.

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

Типичная топология сети показана на фиг. 1. Стрелки на фиг. 1 показывают пакеты, которые отправляются и принимаются, чтобы доставить сообщение от R1 к T1. Пунктирная стрелка указывает, что в этом примере исходный пакет, отправленный R1, также принимается P1, но P1 не воздействует на него. Существует несколько (известных) методик, с помощью которых P1 и P2 могут координироваться для предотвращения неэкономного действия, когда они оба перенаправляют пакет. Такие методики включаются, например, в предстоящий стандарт ZigBee Green Power.

Фиг. 1 показывает, что P1 и P2 являются посредниками, которые находятся в диапазоне R1. Существует несколько причин, почему может быть выгодно иметь исполнение системы, при котором несколько устройств в диапазоне могут работать в качестве посредников для R1:

1. Надежность. Для каждого сообщения M_i, R1 может обладать только ограниченной энергией, с помощью которой может отправить пакеты, содержащие то сообщение. Например, R1 может быть способен отправить только 2 пакета, кодирующих сообщение, в течение очень короткого временного промежутка (например, заданного доступностью поглощенной энергии); также он может быть не способен выполнить необходимые механизмы доступа к каналу и/или ожидать приема кадра квитирования, и все это может отрицательно влиять на надежность связи. В этом случае наличие большего количества посредников вокруг R1, которые будут прослушивать и также будут способны перенаправить пакеты от R1, увеличивает вероятность того, что по меньшей мере один посредник примет пакет с M_i.

2. Мобильность. Если R1 может перемещаться, то он может выйти из диапазона какого-нибудь одиночного посредника, посредник может переместиться/выключиться, либо условия распространения могут измениться (например, вследствие временных или постоянных перестановок в пространстве).

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

Данное изобретение применяется главным образом к системам с возможностью иметь несколько посредников для каждого ограниченного устройства R1.

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

1. Адреса (идентификаторы) целевого устройства (или устройств) для некоторых сообщений от R1, если R1 не может внедрить или не внедряет эту информацию в свои пакеты сообщений.

2. Информация, которая делает надежнее связь от или к R1, например ключ шифрования, используемый R1, защитный счетчик кадров, использованный недавно R1 (счетчики кадров могут защитить от атак с повторением пакетов и/или используются в качестве векторов начального заполнения для ключа).

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

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

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

Например, на фиг. 1 было бы полезно, если бы P1 и P2 хранили информацию для R1 в своих таблицах посредников. Если R1 может перемещаться, также было бы полезно, если бы ту информацию хранило P3. Однако в наиболее продуманных ячеистых сетях память в узлах-посредниках ограничивается, поэтому не всегда будет возможно сохранить информацию обо всех ограниченных узлах Rx во всех таблицах посредников всех узлов-посредников Px (с функцией посредника).

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

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

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

Предпочтительно, чтобы расстановка в сети была такова, что каждый ограниченный узел Rx в своем диапазоне передачи имеет по меньшей мере несколько посредников раннего действия. Однако при такой расстановке предпочтительно нужны механизмы для предотвращения того, чтобы каждый посредник с возможностью действия решал действовать во всех случаях, когда он принимает сообщение от Rx в своем диапазоне. Если это не предотвратить, то наличие нескольких действующих посредников может вызвать увеличение задержки доставки сообщений или даже уменьшение надежности доставки. Одним из таких предусмотренных механизмов предотвращения является тот, что если некоторый посредник Px воздействует на принятое сообщение от Rx и доставляет его, существует средство для других посредников в диапазоне Rx, чтобы узнать о воздействии Px. Если они узнают, то они смогут воздержаться от собственных действий. Такой информационный механизм может принимать следующий вид. Предположим, что посредник P1 принял сообщение M_i от R1 и теперь должен решить, воздействовать ли на него. Затем он запустит счетчик лимита времени и будет прослушивать канал сети. Если он наблюдает пакет от другого посредника, например P2, содержащий полезную нагрузку, которая указывает, что P2 воздействовал на то же сообщение M_i от R1, то P1 решает не действовать и останавливает счетчик. Если счетчик достигает нуля без приема пакета от другого посредника для сообщения M_i от R1, то P1 действует. Из-за различий в диапазонах отправки сети и некоторой присущей ненадежности доставки беспроводных пакетов механизмы вроде этого не запретят во всех случаях, что несколько посредников решат воздействовать на одно и то же сообщение от R1. Поэтому предусмотрено, что также имеются механизмы, например на целевых узлах, для отфильтровывания идентичных сообщений от нескольких посредников, которые действовали.

В предстоящем стандарте ZigBee Green Power используются следующие механизмы для активных и действительных записей в таблице посредников (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.1, страница 120, строка 6 - страница 121, строка 17). В случае одноадресного перенаправления посредники, имеющие запись в таблице посредников для конкретного ограниченного устройства Rx, вычисляют задержку перенаправления на основе критериев типа: качества принятого сигнала от ограниченного устройства, доступности одноадресных маршрутов к целевым устройствам и факта того, что являлись первыми для перенаправления в прошлом. По истечении задержки перенаправления посредник отправляет сообщение ZGP Tunneling Stop (остановка туннельной передачи) в 2-скачковом широковещании с альтернативным сетевым адресом источника и альтернативным сетевым порядковым номером, выведенными из информации в GPDF, чтобы информировать других посредников, что он перенаправит сообщение, а позднее отправляет сообщение (сообщения) ZGP Notification в одноадресной рассылке. После приема сообщения ZGP Tunneling Stop для одной и той же команды ZGPD в течение задержки перенаправления посредник отменяет свою запланированную передачу. В случае групповой связи для GPDF, указывающей возможность приема, посредники, имеющие запись в таблице посредников для конкретного ограниченного устройства Rx, вычисляют задержку перенаправления, как описано выше. По истечении задержки перенаправления посредник отправляет сообщение (сообщения) ZGP Notification в многоадресной рассылке APS, и оно включает в себя его короткий адрес и индикатор качества сигнала, принятого от ограниченного устройства Rx. После приема сообщения ZGP Notification для одной и той же команды ZGPD в течение задержки перенаправления, если ZGP Notification имеет лучший индикатор качества или равный индикатор качества и более младший короткий адрес, то посредник отменяет свою запланированную передачу. В случае групповой связи для GPDF, не указывающей возможность приема, посредники, имеющие запись в таблице посредников для конкретного ограниченного устройства Rx, перенаправляют сообщение (сообщения) ZGP Notification в многоадресной рассылке APS с альтернативным сетевым адресом источника и альтернативным сетевым порядковым номером, выведенными из информации в GPDF, что заставляет независимо сформированные пакеты ZGP Notification выглядеть идентичными Таблице широковещательных транзакций (Broadcast Transaction Table) в ZigBee. Такой же механизм используется приемниками, допускающими групповое перенаправление на основе таблицы приемников (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.4, страница 128, строка 25-29).

Если посредник имеет успех при передаче ZGP Notification, то он устанавливает флаг FirstToForward (ʺпервый на перенаправлениеʺ) в своей таблице посредников в ИСТИНУ; он сбрасывает его после приема ZGP Notification Response от одноадресного приемника с флагом FirstToForward, установленным в ЛОЖЬ (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.1, страница 121, строка 12-17).

Приемники фильтруют принятые команды ZGPD на основе идентификатора ZGPD (SrcID) и значения счетчика кадров (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.6.1.2, страница 132, строка 2 - страница 134, строка 4).

Записи в таблице посредников нужно создавать с самого начала. Они могут создаваться, например, как часть процесса ввода в эксплуатацию, привлекающего пользователя и/или инструмент.

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

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

В предстоящем стандарте ZigBee Green Power используются следующие механизмы для конфигурирования информации в таблицы посредников (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.1, страница 118, строка 32-39; раздел A.3.9, страница 165, строка 2). Как часть успешной процедуры ввода в эксплуатацию, ZGPS или ZGPCT отправляет сообщение ZGP Pairing с флагом AddSink, установленным в 0b1, обычно в виде широковещательной передачи по всей сети, переносящей, среди прочего, SrcID, настройки безопасности и необходимый режим связи. После приема ZGP Pairing посредники создают/расширяют записи в таблице посредников поступившей информацией. Для приемников, допускающих перенаправление на основе таблицы приемников, записи в Таблице приемников создаются после приема команды Configure Pairing (конфигурация создания пар), которая может быть отправлена другим ZGPS или ZGPCT (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.4, страница 127, строка 35 - страница 128, строка 1).

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

Предположим, что посредник позднего действия принимает сообщение от R1, а затем не получает никакой информации вообще посредством информационного механизма типа, описанного выше, указывающей, что другой посредник уже произвел действие. В этом случае посреднику приходится принимать трудное решение. Если он решает воздержаться от действия, то сообщение может остаться недоставленным. Однако если он решает действовать, то это будет означать взаимодействие с сетью, чтобы получить необходимую информацию о том, как действовать. Такому взаимодействию обычно придется принять форму запроса широковещательного или многоадресного типа (ʺкто может сказать мне, что делать с сообщениями от R1ʺ), и поскольку наличие некоторой специализированной информации на узлах потенциально предъявляет к ним высокие требования к ресурсам (особенно памяти) и требует, чтобы их местоположение было известно/поддавалось обнаружению посредниками, это также может ввести одну точку отказа. Такие широковещательные или многоадресные запросы могут потреблять значительную полосу пропускания. Что особенно важно, может иметь место ухудшение надежности: при неблагоприятных условиях (особенно в большой и оживленной сети) трафик широковещательных/многоадресных запросов мог бы заглушить сообщения от других устройств, в частности от других ограниченных узлов, заставляя их остаться недоставленными. Однако если широковещательный/многоадресный трафик ограничивается сетью, то Px может потерпеть неудачу в получении необходимой информации, нужной для действия без превышения предусмотренного предельного срока для доставки сообщения от R1 к T1. Существует даже вероятность того, что Px вообще не сможет получить нужную информацию.

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

В предстоящем стандарте ZigBee Green Power используются следующие механизмы для обслуживания информации в таблицах посредников.

После непосредственного приема GPDF от Rx ZGPD посредник Px устанавливает флаг InRange (в диапазоне) у записи в таблице посредников для Rx в ИСТИНУ (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.1, страница 119, строка 44 - страница 120, строка 5). После приема команды ZGP Notification или ZGP Tunneling Stop, для которой Px не наблюдает инициирующего GPDF, Px устанавливает флаг FirstToForward в ЛОЖЬ (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.2.2, страница 124, строка 25-28). Если Px принимает команду ZGP Response, переносящую адрес другого устройства в поле Proxy, то Px устанавливает флаг FirstToForward в ЛОЖЬ и удаляет GPDF, стоящие в очереди для доставки этому ZGPD, при наличии (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.1, страница 118, строка 43 - страница 119, строка 6). Для посредников, работающих в области автоматизации зданий, рекомендуется сбрасывать флаг InRange при пропуске десяти последовательных GPDF от Rx (см. ZigBee Green Power, рекомендованные методы для ZBA, 11-0196-01, раздел 5.3.2.1, страница 24, строка 21-24).

Нижеследующие механизмы являются частью функции Обслуживания таблиц посредников (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.2, страница 124, строка 2-6; раздел A.3.5.2.2.3, раздел A.3.5.2.2.4, раздел A.3.5.2.1, страница 118, строка 27-30). Если посредник Px принимает GPDF от неизвестного Rx ZGPD, то посредник запускает таймер задержки обнаружения. Px затем прослушивает сообщения ZGP Notification/ZGP Tunneling Stop, перенаправленные другими посредниками от имени того же ZGPD, чтобы вывести необходимую информацию. Оба сообщения переносят, среди прочего, флаги, указывающие используемые режимы перенаправления. После истечения таймера задержки обнаружения, если никакие сообщения не принимались или по-прежнему имеется отсутствующая информация (например, адреса одноадресных приемников или ранее введенных в эксплуатацию групп), то Px отправляет широковещательную команду ZGP Pairing Search, запрашивающую у приемников, сопряженных с ZGPD в указанном режиме (режимах) связи, ответить с помощью ZGP Pairing. После приема ZGP Pairing таблица посредников обновляется. Если команды ZGP Pairing Search или ZGP Pairing для Rx принимаются в пределах задержки обнаружения, то Px отменяет свою передачу ZGP Pairing Search. Неактивные записи в таблице посредников можно удалить, а вместо этого сохранить SrcID в списке заблокированных SrcID.

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

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

Одним способом управления таблицами посредников было бы использование стратегий замены ʺнаиболее давнего по использованиюʺ. По стратегии ʺнаиболее давнего по использованиюʺ, если посреднику Px нужно добавить узел Rx в свою таблицу, которая уже заполнена, то он удалит узел R_i, который является наиболее давним по использованию, например:

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

b) R_i выбирается в качестве узла среди всех узлов в таблице, который Px наблюдал наиболее давно в качестве генерирующего какое-либо сообщение.

Существуют проблемы с такими стратегиями замены ʺнаиболее давнего по использованиюʺ. Предположим, что таблицы посредников ограничиваются 5 записями, и сеть содержит 15 посредников и 15 ограниченных узлов, причем все они находятся в диапазоне приема всех остальных. Предположим, что 10 из ограниченных узлов являются датчиками температуры, которые сообщают данные каждую минуту, а 5 являются кнопочными выключателями света, которые используются в среднем один раз в день. В этом случае существует высокая вероятность того, что каждое утро независимо от точной стратегии замены ʺнаиболее давнего по использованиюʺ все таблицы посредников на всех посредниках будут заполнены данными о датчиках температуры, при этом все выключатели света исчезли из таблиц. В зависимости от исполнения других аспектов сети это сделает обработку сообщений от выключателей света медленной, ненадежной или даже невозможной. Поэтому нужна стратегия лучше, чем ʺнаиболее давнего по использованиюʺ. 15 посредников имеют 15⋅5=75 записей в таблице среди них, поэтому должна быть возможность иметь каждый из 15 ограниченных узлов в таблице по меньшей мере одного посредника.

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

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

Предстоящий стандарт ZigBee Green Power предлагает следующие механизмы для удаления записи из таблицы посредников.

Удаление устройства ZGPD из сети, включая удаление связанных записей в таблице посредников, может инициироваться отправкой ZGPD команды ZGPD Decommissioning (вывод из эксплуатации) и/или отправкой приемником/инструментом ввода в эксплуатацию команды ZGP Pairing с флагом RemoveZGPD, установленным в ИСТИНУ (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.5, страница 129, строка 10-15). Оба действия предполагаются инициированными пользователем. Удаление конкретного сопряжения из таблицы посредников может инициироваться отправкой приемником/инструментом ввода в эксплуатацию команды ZGP Pairing с флагом AddSink, установленным в ЛОЖЬ. Приемники удаляют устаревшие одноадресные сопряжения путем отправки ZGP Notification Response с флагом NoPairing, установленным в ИСТИНУ (см. Спецификацию ZigBee Green Power, 09-5499-18, раздел A.3.5.2.5, страница 130, строка 32 - страница 131, строка 2).

Для посредников, работающих в области автоматизации зданий, рекомендуется очищать записи в таблице посредников с флагом InRange, установленным в ЛОЖЬ (см. ZigBee Green Power, рекомендованные методы для ZBA, 11-0196-01, раздел 5.3.2.1, страница 24, строка 18-20).

Хотя записи в таблице для неизвестных устройств можно обнаружить ʺсвоевременноʺ, например при первом наблюдении устройства, и однажды удаленные/аннулированные записи в таблице можно повторно обнаружить/снова активировать, следует быть осторожным, чтобы плохая эвристика не привела к серьезному сбою системы. Представим себе портативную аварийную кнопку, предназначенную для приведения в действие, когда носителю требуется помощь. Ее реализация в виде устройства с ограниченными ресурсами, в особенности поглощающего энергию устройства, может быть полезной, так как это гарантирует, что никому не придется столкнуться с разряженными батареями/заменой батарей. Будет создано сопряжение с целевым объектом. Но кнопка будет приводиться в действие очень редко (например, пару раз в год), возможно, каждый раз в разном местоположении (поскольку ее носитель перемещается); и даже операции обслуживания, при наличии, будут нечастыми (например, каждые две недели). Если после активизации кнопки ни у какого посредника нет записи в таблице, то в одной предусмотренной реализации системы сообщение не будет перенаправлено, а вместо этого может быть отправлен запрос; и только результат запроса может использоваться для перенаправления следующего сообщения. Однако текущий важный сигнал тревоги может быть не перенаправлен.

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

Далее раскрываются методики, которые предотвращают ненужный рост таблиц посредников:

1. Классы записей в таблице посредников, включающие в себя:

a) Методики подстановки, которые позволяют хранить информацию таблицы посредников компактнее;

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

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

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

2. Идентификация устаревших записей, которые можно удалить, не вызывая потери производительности.

3. Средство для определения, какие оставшиеся записи желательнее сохранить по сравнению с другими.

a. Средство, которое зависит от использования информации о состоянии, разосланной в сети.

Данное изобретение дополнительно раскрывает способы, которые помогают посредникам позднего действия в принятии решений, действовать или нет.

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

(4ʹ/5ʹ)

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

В одном варианте осуществления этого способа посредникам предоставляется ʺподстановочнаяʺ запись, позволяющая обращаться с ограниченными устройствами, для которых нет выделенной записи в таблице посредников. При поиске ограниченного устройства Rx в таблице посредников, содержащей ʺподстановочнуюʺ запись, если Rx не соответствует никакой обычной записи, то он все же может соответствовать ʺподстановочнойʺ записи. ʺПодстановочнаяʺ запись может задавать, что она соответствует всем устройствам, не подходящим в других отношениях, или только подмножеству, заданному некоторым образом, например, тем устройствам Rx, которые имеют глобальный уникальный идентификатор устройства, оканчивающийся двумя разрядами ʺ01ʺ. Такая ʺподстановочнаяʺ запись должна указывать предназначенный целевой объект, который может быть широковещательным, групповым или одиночным адресом (адресами) (их списком). В случае одноадресной или группой/многоадресной рассылки адрес предпочтительно указывает некоторое устройство (устройства), способное к обращению с несколькими ограниченными устройствами и соответствующими приемниками; например, система управления зданием, способная обрабатывать пакеты, идентифицировать участвующие устройства и направлять сообщение соответствующим образом, если необходимо. Целевой адрес в ʺподстановочнойʺ записи в таблице также может быть недействительным адресом, указывающим, что посредник не должен перенаправлять от имени ограниченных устройств, о которых у него нет записи. В самой простой реализации посредник перенаправляет необработанный пакет ограниченного устройства. В другой реализации запись в таблице может содержать информацию, допускающую некоторую фильтрацию и приведение перенаправления к условному. Например, она может включать в себя тип устройства, возможности устройства, тип сообщения или протокола. Кроме того, запись в таблице может содержать некоторую информацию о безопасности, включающую предполагаемый уровень безопасности, предполагаемый тип ключа, предполагаемое значение ключа, так что посредник может выполнить аутентификацию/шифрование/проверку подлинности; и посредник может перенаправить сообщение ограниченного устройства. Может быть несколько подстановочных записей, охватывающих разные характеристики устройства. Подстановочные записи могут создаваться на всех или на тщательно отобранных посредниках, например, чтобы минимизировать объем связи для устройства обработки подстановочного трафика; это может дополнительно опираться на тщательный выбор выделенных записей и критериев подстановочной фильтрации. Подстановочная запись может создаваться во время ввода в эксплуатацию, может быть доступна по умолчанию или может создаваться при попытке принятия решения, инициированной приемом первого пакета от неизвестного ограниченного устройства. Подстановочные записи также могут использоваться, если вся информация, необходимая для перенаправления, является выводимой из принятого сообщения ограниченных устройств. Подстановочная запись также может задавать, что должно произойти, если фильтрация/обработка, при ее наличии, терпит неудачу; посреднику можно дать указание перенаправить необработанный, предоставить дополнительную информацию или удалить кадр. Подстановочные записи в таблице также могут использоваться, если обработка в соответствии с данными в выделенной записи в таблице возвращает ошибку, например ошибку безопасности. Тогда сообщение ограниченного устройства может быть перенаправлено необработанным обработчику подстановочного трафика, в дополнение или вместо отправки запроса широковещательного/многоадресного типа об ограниченном устройстве. Когда используются подстановочные записи, можно рассмотреть полный запрет автоматического обнаружения записей в таблице.

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

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

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

Предпочтительно, чтобы решение о том, каким ограниченным устройствам нужны выделенные записи в таблице посредников, основывалось на характеристиках ограниченных устройств. Одним критерием может быть частота передачи сообщений. Ограниченные устройства, которые взаимодействуют очень часто, предпочтительно имеют выделенные записи, чтобы предотвратить частое обнаружение/обходной подстановочный трафик. Другим критерием могут быть требования к задержке у ограниченного устройства. Ограниченные устройства, сообщения которых требуют быстрой обработки, предпочтительно имеют выделенные записи, чтобы избежать (непредсказуемой) задержки, вызванной обнаружением или обработкой подстановок. Типичным примером является управляемое пользователем освещение. Пользователь ожидает, что команда освещения вступит в силу (или будет предоставлена другая заметная обратная связь) не позже 200 мс после действия пользователя. Другим критерием может быть требование к надежности. Другими критериями могут быть возможности ограниченного устройства, например его способность также и принимать. Например, если ограниченное устройство не способно принимать, то может быть не нужно выделять определенного посредника для доставки пакетов, а посреднику - отслеживать условие FirstToForward или InRange, поэтому выделенная запись может быть не нужна. Другим критерием могут быть шаблоны мобильности ограниченных устройств; если они передвигаются слишком быстро, то создание и удаление выделенных записей в таблице посредников может не иметь смысла. Другими критериями может быть количество сопряженных целевых объектов; может быть лучше повторно обнаружить одиночный одноадресный целевой объект, чем несколько групп целевых объектов. Разные вышеупомянутые критерии можно выгодно объединять.

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

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

Для реализации в Спецификации ZigBee Green Power ʺподстановочнаяʺ запись в таблице посредников может идентифицироваться посредством включения в нее поля SrcID ZGPD, установленного в зарезервированное/недействительное/неопределенное значение (например, 0xffffffff), и/или задания одного из зарезервированных в настоящий момент подполей поля Options (параметры) в качестве ʺподстановочногоʺ флага. Любое другое поле записи в таблице посредников можно установить в определенное значение, чтобы использовать для проверки и фильтрации, или в зарезервированное/недействительное/неопределенное значение, указывающее, что эта информация игнорируется после приема.

В частности, подполя Unicast ZGPS, Derived Group ZGPS и Commissioned Group ZGPS в поле Options, будучи установлены, указывают доступность некоторого типа адреса, на который нужно отправить ZGP Notification. В случае одноадресной рассылки можно рассмотреть пропуск ZGP Tunneling Stop и задержки перенаправления. При установленном в ИСТИНУ подполе AssignedAlias (назначенный псевдоним), поле AssignedAlias может предоставляться для использования для перенаправления команды ZGP Notification (и ZGP Tunneling Stop и/или ZGP Commissioning Notification (уведомление о вводе в эксплуатацию)). Может иметь место средство для указания использования выведенного псевдонима или отсутствия псевдонима вообще, например, с использованием подполя AssignedAlias, установленного в ЛОЖЬ, другого флага или иного зарезервированного значения SrcID ZGPD. Подполе SecurityUse (использование безопасности), будучи установленным в ЛОЖЬ, может указывать, что никакой проверки безопасности выполнять не нужно. Подполе SecurityUse, будучи установленным в ИСТИНУ, может указывать запрос на выполнение обработки обеспечения безопасности в пределах, заданных подполями поля Security Option (параметр безопасности) и оставшимися связанными с безопасностью полями. Уровень безопасности, будучи установленным в значение помимо 0b00, может указывать минимальный или необходимый уровень безопасности. Тип ключа, будучи установленным в значение помимо 0b000, может указывать необходимый тип ключа для использования, и может присутствовать поле ключа. Защитный счетчик кадров ZGPD может использоваться для указания наименьшего приемлемого значения для всех подстановочных ZGPD (и может, например, обновляться периодически на посредниках); его использование может указываться значением помимо 0xffffffff или 0x00000000 и/или путем установки в ИСТИНУ подполя Sequence number capabilities (функциональные возможности у заданного порядкового номера) в поле Options.

Вышеприведенное в равной степени применяется к записям в Таблице приемников у приемников, допускающих функцию перенаправления на основе таблицы приемников. Следует быть осторожным в том, что записи в ZGPD Command Translation Table (таблица перевода команд), будучи заданными по умолчанию или сконфигурированными, имеют сопоставляющую логику, то есть подстановочные записи не смешиваются с записями по умолчанию или конкретными записями.

Чтобы дать посреднику указание использовать информацию ZGPD, но не создавать запись в таблице посредников, приемник/инструмент предпочтительно может установить поле DeviceID в команде ZGP Pairing в недействительное/зарезервированное значение, например 0xff; последнее зарезервированное подполе в поле Options в команде ZGP Pairing можно задать для запроса/запрета создания записи в таблице посредников для этого ZGPD; поле Options также можно расширить до 16-разрядного значения, чтобы предусмотреть дальнейшие будущие модификации. То же самое применяется к созданию Таблицы приемников на приемниках, допускающих перенаправление на основе таблицы приемников; тогда изменения нужно применить к команде ZGP Configure Pairing.

В дополнительном варианте осуществления подстановочная запись может использоваться для операции ввода в эксплуатацию ZGPD и хранить предварительно сконфигурированный/запасной/стандартный ключ безопасности OOB ZGPD или предварительно сконфигурированный/запасной/стандартный ZGPD TC-LK, который ZGPD может использовать в начале или может обращаться к нему, например, после сброса и потери конфигурационных данных. Если объединить с широковещательным адресом приемника, то это поддерживает стандартную процедуру ввода в эксплуатацию на основе посредников ZGP, но защищенную, возможно без потребности обмена ключами в незашифрованном виде. Если объединить с одиночным/групповым адресом (адресами) в Таблице посредников и/или Таблице приемников, переносящей адрес устройства (устройств) централизованного обслуживания, например, ZigBee Trust Centre (доверительный центр), ZigBee Coordinator (координатор), ZigBee Network Manager (менеджер сети) или другой тип контроллера/управляющего узла, то это может позволить использовать Списки управления доступом и/или использовать Правила установки, которые обсуждаются в спецификации ZigBee Smart Energy (ʺинтеллектуальная энергияʺ) 1.0 или спецификации ZigBee Home Automation (автоматизация домохозяйств) 1.2. То же самое применяется к временным записям или несозданным записям.

Чтобы указать класс записи, таблица посредников может использовать зарезервированные в настоящий момент (в ZGP) подполя в поле Options. Можно добавить подполе PermanentEntry/CTentry (постоянная запись/запись CT) для указания записей, которые не следует удалять с помощью процедур автоматизированного обслуживания. Дополнительно/в качестве альтернативы можно добавить подполе AutoDiscoveredEntry (автоматически созданная запись) для указания, что запись создавалась автоматически и может быть удалена с помощью процедур автоматизированного обслуживания.

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

(1ʹ/2ʹ/3ʹ/6ʹ)

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

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

В другом варианте осуществления каждый посредник Px вычисляет коэффициент обслуживания для каждого ограниченного устройства Rx в своей таблице как отношение Ratio(Rx)=RL/RR, где RL - количество раз, которое Px действовал в качестве посредника для Rx с момента T, а RR - количество раз, которое Rx отправило сообщение в период времени, начиная с T. Это требует от посредников хранить счетчик RL обработанных сообщений. В разновидности этого варианта осуществления сочетание данных наиболее давнего по использованию и коэффициента используется для определения, какие устройства удалять. Если не нужно вычислять точный коэффициент, то могут использоваться различные способы приближенного выражения коэффициента.

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

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

Алгоритм A (работающий в посреднике для вычисления коэффициента для того посредника)

Инициализация Px (в момент создания записи в таблице посредников)

LAST_SEQx:=ʹкак предоставлен в момент создания записи в таблице посредников (в противном случае: none)ʹ

COUNTx:=0; //Если запись в таблице посредников создавалась в результате прямого взаимодействия с ограниченным устройством, то пакеты ограниченного устройства уже могут быть подсчитаны

Когда (Px непосредственно принимает сообщение Mi от ограниченного устройства Rx с SEQi)

если (ограниченное устройство реализует инкрементный порядковый номер AND LAST_SEQx=none)

LAST_SEQx:= SEQi;

COUNTx:=COUNTx+1;

Когда (Px принимает сообщение о состоянии, содержащее значение SEQi)

Px вычисляет Ratio(Rx):= COUNTx/(принятый SEQi-LAST_SEQx)

LAST_SEQx:= принятый SEQi;

COUNTx:=0;

Алгоритм A1

В разновидности этого алгоритма мы сначала инициализируем переменную Ratio(Rx) нулем и используем

o Вычислить Ratio(Rx):=Ratio(Rx)/2+(COUNTx/(принятый SEQx-LAST_SECx))/2

Это обладает преимуществом вычисления большей исторической ʺпамятиʺ для коэффициента.

Алгоритм B (работающий в посреднике для вычисления коэффициента для того посредника):

Инициализация Px:

FIRST_STATUS_SEQx=ʹкак предоставлен в момент создания записи в таблице посредников (в противном случае: none)ʹ;

COUNTx:=0;

Когда (Px непосредственно принимает сообщение Mi от ограниченного устройства Rx с SEQi)

если (ограниченное устройство реализует инкрементный порядковый номер AND FIRST_SEQx=none)

FIRST_SEQx=SEQi;

COUNTx:=COUNTx+1;

Когда (Px принимает сообщение о состоянии, содержащее значение SEQi)

Ratio(Rx):=COUNTx/(SEQi-FIRST_STATUS_SEQx);

если (FIRST_STATUS_SEQx==ʹnoneʹ)

FIRST_STATUS_SEQx=SEQi;

Алгоритм C:

Инициализация Px:

LAST_SEQx=ʹкак предоставлен в момент создания записи в таблице посредников (в противном случае: none)ʹ;

Когда (Px непосредственно принимает сообщение Mi от ограниченного устройства Rx со значением SEQi OR

Когда он принимает сообщение о состоянии, содержащее значение SEQi)

MISS=LAST_SEQx-SEQi;

LAST_SEQx=SEQi;

Устройствам-посредникам, которые находятся в диапазоне R1, типа P1 и P2, нетрудно вычислить (хорошее приближение) Ratio(R1) всего лишь путем прослушивания сообщений от R1 и ведения подсчета непосредственно принятых сообщений, чтобы приблизительно выразить правую сторону формулы коэффициента RR. RL просто отслеживать любому посреднику независимо от того, где он располагается по отношению к R1.

Для устройств-посредников вне диапазона R1, типа R3, или устройств где-то на границе диапазона, или устройств с очень ненадежной линией связи с R1 невозможно или непросто/недостоверно узнать значение текущего счетчика пакетов/RR.

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

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

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

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

Для реализации в стандарте ZigBee Green Power предлагается использовать уже заданное сообщение ZGP Pairing, которое уже включает в себя поле Security Frame Counter (счетчик кадров безопасности), которое может использоваться в качестве сообщения о состоянии с SEQx, чтобы извлечь пользу из повторного использования кода. Отправка сообщения ZGP Pairing может инициироваться ZGPS периодически или после события, например после приема команды ZGP Pairing Search или широковещательной команды ZGP Notification, указывающих посредника с (возможно) устаревшими записями в таблице посредников.

Чтобы дать возможность вычисления индикатора надежности для некой записи в Таблице посредников для ZGPD, не способных обеспечивать безопасность и не способных отправлять инкрементный порядковый номер MAC (который указывается с помощью SecurityLevel=0b00 (уровень безопасности) и MACcapabilities=0b0 (функциональные возможности MAC)), ZGPS просят увеличить параметр Security Frame Counter у их записей в Таблице приемников и предоставить это значение в командах ZGP Pairing. Аналогично посредники должны интерпретировать такой Security Frame Counter (когда SecurityLevel=0b00 и MACcapabilities=0b0) как средство для обслуживания таблиц посредников, а не как индикатор свежести, то есть они не должны сравнивать значение порядкового номера MAC у принятого GPDF со значением, сохраненным в таблице посредников.

После приема сообщения ZGP Pairing посредник должен вычислить индикатор надежности для этого Rx. Он может удалить запись в таблице посредников, если индикатор надежности опускается ниже некой пороговой величины. Для ZGPS, способного выполнять перенаправление на основе таблицы приемников, с этой целью используется сообщение ZGP Configure Pairing.

Для основанной на IP реализации, например в IP-сети на основе 6LoWPAN, содержащей ограниченные устройства - ZGPD и/или собственные ограниченные IP-устройства - и посредников с функцией IP, сообщения на основе IP для перенаправления сообщений ограниченного устройства могут быть устройствами. В частности, одноадресные или многоадресные сообщения CoAP могут использоваться для переноса заданной выше информации в полезной нагрузке CoAP.

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

Для реализации в стандарте ZigBee Green Power предлагается, чтобы посредники обменивались записями в таблице посредников; извлекая, таким образом, пользу из повторного использования кода. Они могут обмениваться полным содержимым таблицы или предпочтительно только выбранными записями. Они могут обмениваться записями периодически или предпочтительно по событию (например, один посредник вычисляет низкий/понижающийся индикатор надежности). Обмен таблицами предпочтительно инициируется 2-скачковой широковещательной/групповой рассылкой, без псевдонима, в команде ZCL Read Attributes (считывание атрибутов). Посредник (посредники), включая инициирующего посредника, отвечает таким же образом (широковещательная/групповая рассылка) с помощью ZCL Read Attributes Response (ответ по считыванию атрибутов) записью (записями) в таблице посредников для включенного/всех ZGPD. В качестве альтернативы посредники могут сообщать свои таблицы в ZCL Attributes Report (отчет об атрибутах) в виде одно-/двухскачковой широковещательной/групповой рассылки. Приемники, допускающие функцию перенаправления на основе таблицы приемников, обмениваются своими записями в Таблице приемников таким же образом.

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

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

Для основанной на IP реализации, например в IP-сети на основе 6LoWPAN, содержащей ограниченные устройства - ZGPD и/или собственные ограниченные IP-устройства - и посредников с функцией IP, предлагается, чтобы посредники также могли обмениваться записями в таблице, в силу чего формат записей будет отличаться в основанной на IP реализации. Эти записи в таблице могут содержать кэшированные записи для ограниченных устройств, которые ранее запрашивались, например из DNS посредником, действующим в качестве DNS-клиента, или с использованием эквивалентных механизмов обнаружения (например, RD). Обмен таблицами может инициироваться односкачковой или 2-скачковой многоадресной IP-рассылкой, например многоадресным POST-запросом CoAP с полезной нагрузкой. Посредник (посредники) отвечает таким же образом, используя многоадресную IP-рассылку, например многоадресный ответ CoAP на POST или отдельный (новый) POST-запрос CoAP. В качестве альтернативы можно задать новую команду обслуживания таблицы, предпочтительно переносящую только имеющую отношение к надежности информацию, которая отправляется с помощью многоадресной IP-рассылки одним из только что описанных способов. Вычисления надежности могут выполняться аналогично случаю для ZigBee Green Power.

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

Для реализации в стандарте ZigBee Green Power предлагается, чтобы посредники использовали команды ZGP Tunneling Stop и ZGP Notification, которые они уже принимают для целей надежности и обслуживания таблиц посредников (например, установки InRange и FirstToForward), также для удаления записей из таблицы посредников. Когда посредник принимает ZGP Notification с (виртуальным) защитным счетчиком кадров, он должен вычислить индикатор надежности, и, если он опускается ниже пороговой величины, должен рассмотреть удаление записи (вместо/в дополнение к установке флагов FirstToForward/InRange).

К тому же, предлагается, чтобы посредник сравнивал значение поля Distance (расстояние), принятого в ZGP Notification, отправленном другими перенаправляющими посредниками. Для этого посреднику может понадобиться локально хранить свое значение Distance для ZGPD, например для последнего принятого кадра или предпочтительно усредненным за некий период времени. Если посредник наблюдает некоторое количество других посредников с лучшим значением Distance, особенно если его собственный индикатор надежности низкий, то посредник может решить удалить запись в таблице посредников вместо/в дополнение к воздержанию от перенаправления (если GPDF также был принят непосредственно) и установке FirstToForward в ЛОЖЬ. Для упрощения этого также в случае одноадресного перенаправления команду ZGP Tunneling Stop рекомендуется расширить полем Distance.

ZGP Notification и ZGP Tunneling Stop также можно расширить полем индикатора надежности.

Чтобы позволить посреднику определять идентификатор посредника FirstToForward также в одноадресном случае, ZGP Tunneling Stop может отправляться без псевдонима.

В качестве альтернативы посредники могут быть способны определять исходного отправителя ZGP Tunneling Stop/ZGP Notification/ZGP Commissioning Notification из MAC-адреса источника, если поле числа скачков в заголовке NWK имеет свое начальное значение (например, 2 для ZGP Tunneling Stop).

То же самое может применяться к приемникам, допускающим перенаправление на основе таблицы приемников.

Кроме того, если посредник Px непосредственно принимает GPDF от неизвестного SrcID ZGPD и если он принимает команды ZGP Tunneling Stop и/или ZGP Notification от одного или более других посредников, особенно если они имеют хорошие/лучшие индикаторы надежности и/или значение поля Distance, то Px может воздержаться от отправки команды ZGP Pairing Search и от создания записи в таблице посредников.

Разные вышеупомянутые способы также можно успешно объединять.

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

Для всех вышеупомянутых способов посредник, наряду с удалением записи в таблице посредников, может сохранять SrcID ZGPD в другом списке, чтобы предотвратить последующее повторное обнаружение. Это может быть атрибут zgppBlockedSrcIDs. Также это предпочтительно может быть отдельным атрибутом, хранящим ZGPD, которые являются частью сети, но для которых этот посредник не должен перенаправлять.

Для основанной на IP реализации, например в IP-сети на основе 6LoWPAN, содержащей ограниченные устройства - ZGPD и/или собственные ограниченные IP-устройства - и посредников с функцией IP, сообщения ограниченного устройства могут перенаправляться, например, в виде многоадресного POST-запроса CoAP IPv6, с ограниченным TTL/числом скачков, если предназначено только для связи между посредниками, или, например, в виде одноадресного GET-ответа CoAP IPv6 с параметром Observe. Эти сообщения, будучи приняты другими посредниками, могут использоваться для удаления записей из таблицы посредников, как описано выше.

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

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

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