Результат интеллектуальной деятельности: СПОСОБ КОНФИГУРИРОВАНИЯ УЗЛА

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

Настоящее изобретение относится к способу конфигурирования сети, к объекту технического обслуживания и сети связи, содержащей объект технического обслуживания и множество узлов.

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

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

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

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

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

Более того, продолжительность возможностей приема при работе может быть очень короткой, в частности, после передачи пакетов данных. Например, Устройство ZigBee Green Power указывает способность приема в обычном кадре, который оно отправляет (после инициирующего события со стороны пользователя/датчика/приложения), посредством установки флага RxAfterTx («прием после передачи»). Через 5 мс после данной передачи, ZGPD активирует свой радиоприемник для приема, по меньшей мере, на 0,576 мс, что соответствует наиболее короткому Кадру Устройства Green Power. Данная продолжительность недостаточна, например, для приема пакета, содержащего новый ключ.

Международная Патентная Заявка № WO 2011/055292 раскрывает способ беспроводной связи в сети, содержащей ограниченное по ресурсам устройство, и устройство-посредник для осуществления связи с ограниченным по ресурсам устройством. В этом способе, в частности, излагается то, что ограниченное по ресурсам устройство (ZGPD) передает кадр, содержащий идентификатор источника, который должен быть переадресован устройству назначения в сети, и то, что посредник создает, из кадра, пакет, который должен быть переадресован устройству назначения. Устройство-посредник извлекает связанную с источником информацию из принятого пакета и включает данную информацию в пакет.

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

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

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

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

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

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

(a) обнаруживают, что требуется обновление значения параметра конфигурации сети для ограниченного узла;

(b) принимают решение о том, изменить ли поведение ограниченного узла с первого поведения, на основании, по меньшей мере частично, характеристик связи ограниченного узла, при этом упомянутое изменение поведения включает в себя увеличение возможности приема на ограниченном узле;

(c) в зависимости от принятого решения на этапе (b), инициируют доставку запроса изменения поведения ограниченному узлу во время первой возможности приема ограниченного узла;

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

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

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

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

на объекте технического обслуживания, (1d) инициируют доставку обновленного значения параметра конфигурации сети ограниченному устройству;

(1e) выполняют способ первого аспекта изобретения.

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

средство обнаружения для обнаружения того, что требуется обновление значения параметра конфигурации сети для ограниченного узла;

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

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

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

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

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

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

- Фиг. 2 является блок-схемой, изображающей способ в соответствии с первым вариантом осуществления изобретения.

- Фиг. 3A и 3B являются структурными схемами, показывающими предложенный формат для нового командного кадра, используемого в варианте осуществления.

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

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

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

Другим видом Устройства ZigBee Green Power является узел-датчик, который преобразует энергию окружения в электрическую энергию для работы. Например, такой узел-датчик может быть датчиком света, который работает, только когда он принимает достаточно света. Аналогичным образом, могут быть использованы другие датчики, подобные: датчикам температур или тепла, питание которых осуществляется термоэлементом; датчику расхода, питание которого осуществляется потоком; датчикам мощности, питание которых осуществляется электромагнитным излучением; или акустическим датчикам для определения присутствия пользователя.

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

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

Соответственно, предлагается, в соответствии с текущим определением изобретения, способ конфигурирования этих особых ограниченных узлов. В частности, такой способ может потребовать конкретной команды Устройству ZigBee Green Power для изменения нормального режима работы ограниченного узла на «режим приема параметра». Такой режим приема параметра включает в себя особое поведение ZGPD для передачи и/или приема, для повышения шансов того, что обновление будет принято ZGPD.

Когда ожидается обновление параметра для ZGPD, то сначала ZGPD может быть отправлена команда «Ожидания Обновления», в зависимости от критерия, как, например, приоритета обновленного параметра конфигурации сети, длины кадра обновленного параметра конфигурации сети, продолжительности возможностей приема ограниченного узла, частоты возможностей приема ограниченного узла, способности ограниченного узла, функциональности приложения ограниченного узла, местоположения ограниченного узла, приоритета ограниченного узла. Такая команда может быть очень короткой и может быть передана неоднократно для увеличения вероятности приема. Данная команда может быть передана устройством инфраструктуры ZigBee Green Power - одним/любым Потребителем ZigBee Green Power (ZGPS), образующим пару с ZGPD, или любым Посредником ZigBee Green Power (ZGPP), назначенным в качестве TempMaster (Временное Ведущее Устройство), устройство с возможностями стандарта ZigBee Green Power, переводящее команды ZGPD в обычные команды ZigBee для переадресации обычным узлам ZigBee - для информирования ZGPD об ожидании обновления. Тем не менее, как будет более подробно здесь описано, отправка сообщения и отслеживание хода обновления также может быть выполнено любым из следующих устройств/ролей: Устройством технического обслуживания стандарта ZigBee (Центр Управления Безопасностью ZigBee, Устройство Координации ZigBee, Устройство Управления Сетью), устройством технического обслуживания Устройства ZigBee Green Power, Инструментом Ввода в Эксплуатацию, концентратором, шлюзом. В ответ, ZGPD может модифицировать свое поведение. Более того, команда может быть завершена, чтобы повлиять на модификацию поведения требуемым образом. Находясь в режиме приема параметра, ZGPD может отправлять другие команды, нежели команды нормального кадра «данных», чтобы избежать ненужной путаницы в системе после приема, и также, чтобы сэкономить энергию для приема. Хорошим кандидатом является команда Запроса Канала ZGPD с обоими подполями канала, установленными в текущий рабочий канал, как известно ZGPD, или команда Успеха ZGPD.

Как иллюстрируется на Фиг. 1, первый вариант осуществления изобретения может быть выполнен в ячеистой сети 100 ZigBee, содержащей Устройство 101 Координации и множество радиоузлов 110. В данном примере, сеть 100 дополнительно содержит устройства, совместимые с техническим описанием ZigBee Green Power, подобные переключателям 1000 ZGPD или датчикам 1001 ZGPD, которые организуют пару с Потребителями 1020 ZigBee Green Power (ZGPS) или с Посредниками ZigBee Green Power (не показаны). ZGPS может быть исполнительным устройством, управление которым может осуществляться одним или более переключателями 1000 или датчиками 1001 ZGPD. Например, ZGPS являются лампами. Часто множество ZGPS управляется одним ZGPD, особенно в случае освещения. ZGPS, обычно соединенные с электрическими сетями, как правило, не ограничены в возможностях приема или передачи, в противоположность ZGPD, которое может осуществлять прием только в течение непредсказуемых возможностей приема. Чтобы избежать конфликтов при осуществлении связи между ZGPD 1000 или 1001 и ZGPS 1020, посредник или TempMaster 1021 потребителей может быть назначен для осуществления связи с ZGPD.

В соответствии с первым вариантом осуществления изобретения, ZGPS 1020, который осведомлен о требовании обновления, осуществляет связь с удаленным TempMaster 1021. Процесс полностью прозрачен для выбранного TempMaster, которое может просто (i) сохранить GPDF в своей zgpTxQueue (очередь передачи ZigBee Green Power), который должен быть передан ZGPD, как проинструктировано ZGPS, и (ii) отправить GPDF (Кадр Устройства Green Power), если какой-либо присутствует в zgpTxQueue, после приема GPDF от ZGPD.

Данный способ будет проиллюстрирован со ссылкой на блок-схему с Фиг. 2.

На этапе S201. ZGPS 1020, образующий пару с ZGPD 1000, узнает об ожидании обновления параметра, например, посредством приема Ответа ZGP или Предупреждения Технического Обслуживания Системы ZGP.

На этапе S202. ZGPS 1020 может выдвинуть кандидатуру TempMaster или инициировать выборы TempMaster. TempMaster выбирается из множества ZGPS, включая его себя самого, и доступных посредников переадресации в диапазоне радиосвязи ZGPD и способных осуществлять связь с ZGPD. Выбранное устройство будет выступать в роли TempMaster для ZGPD 1000.

На этапе S203. ZGPS 1020 может определить, требуется ли или предпочтительно ли изменить режим работы ZGPD для выполнения обновления параметра конфигурации. Данное решение может быть принято в зависимости от текущих способностей ZGPD и некоторых параметров, связанных с командой обновления, подобных длине кадра команды обновления, ее приоритета. Инициирующее событие для изменения режима работы ZGPD также может быть внешним (например, включенным в принятый Ответ ZGP или Предупреждения Технического Обслуживания Системы ZGP, как здесь описывается позже в дополнительном решении).

На этапе S204. ZGPS 1020 может отправить TempMaster Ответ ZGP, с командным кадром Ожидания Обновления ZGPD. Некоторые дополнительные опции могут быть установлены соответствующим образом.

Например, могут быть просигнализированы следующие дополнительные опции:

расширить Rx (приемное) Окно для увеличения продолжительности возможности приема. Эта опция может быть установлена, если кадр обновления длиннее минимального Rx кадра, который определен техническим описанием ZGP. В примере, если выбрана данная дополнительная опция, то ZGPD остановит отправку нормальных пакетов данных, и будет передавать только короткие назначенные сообщения (например, команду Запроса Канала ZGPD с обоими подполями канала, установленными в текущий рабочий канал, как известно ZGPD или команду Успеха ZGPD), чтобы указать предстоящую возможность приема после предварительно определенного времени; более того, в дополнение, поле, несущее точную длину в байтах или продолжительность времени ожидающего кадра обновления, может быть включено в команду Ожидания Обновления ZGPD, чтобы более точно проинструктировать ZGPD в отношении поведения. Следовательно, ZGPD может соответствующим образом отреагировать и расширить свое окно приема.

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

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

Запрос ACK (квитанции), чтобы запросить у ZGPD выполнение квитирования в отношении принятого сообщения. Эта опция может быть установлена в соответствии с приоритетом обновления и запросом объекта технического обслуживания, как выражено в Ответе ZGP или Предупреждении Технического Обслуживания Системы ZGP. Следует отметить, что только некоторые режимы подтверждения должны распространяться на ZGPD. Более того, может не требоваться отправка NACK (отрицательной квитанции) в случае неправильного декодирования принятого пакета в ZGPD с целью экономии энергии для возможностей приема.

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

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

Использовать особые команды для Tx (передачи); опция, которая запрашивает ZGPD использовать назначенную команду (например, команду Запроса Канала ZGPD с обоими подполями, установленными в текущий рабочий канал, как известно ZGPD, или команды Успеха ZGPD) для объявления возможностей приема.

Войти/выйти в/из режима; опция, которая запрашивает у ZGPD выполнение переключения на особое поведение или переключения обратно на рабочий режим.

На этапе S205. TempMaster может поместить команду Ожидания Обновления ZGPD в свою zgpTxQueue, и будет пытаться доставить ее в следующую возможность приема ZGPD. Данная возможность приема обычно сигнализируется посредством приема первого GPDF с установленным RxAfterTx от данного ZGPD.

На этапе S206. После приема команды Ожидания Обновления ZGPD, ZGPD - если способно и проверки после приема пройдены - модифицирует связанное с обновлением поведение, как запрашивается командой Ожидания Обновления ZGPD и в соответствии со своими способностями. Например, ZGPD входит в «режим приема параметра» (может потребовать установки внутренней переменной в «режим приема параметра») или «режим ввода в эксплуатацию»; применительно к запросам ACK: оно устанавливает внутреннюю переменную для отправки после приема новых параметров команды Успеха ZGPD, используя старые/новые параметры. Кроме того, оно может ограничить количество повторных передач в GPDF или время между повторными передачами своих собственных пакетов данных (GPDF), или использовать назначенный короткий GPDF, чтобы сэкономить больше энергии для приема/сохранения нового параметра. Оно также может изменить интервал представления отчета.

На этапе S207. После доставки GPDF, TempMaster может отправить подтверждение ZGPS, чтобы указать то, что ZGPD в настоящий момент обновлено. Может быть использовано Уведомление ZGP с подполем Доставленного GPDF поля Опции, установленным в значение 0b1.

На этапе S208. После приема подтверждения от TempMaster, ZGPS создает кадр обновления ZGPD (конфигурацию Канала ZGPD/Ответ Ввода в Эксплуатацию), и отправляет его TempMaster в ответе ZGP. TempMaster может поместить команду ZGPD в свою zgpTxQueue. В качестве варианта данного варианта осуществления, Кадр Обновления также может быть передан совместно с Кадром команды ожидания Обновления.

На этапе S209. После своей следующей передачи, в «режиме приема параметра», ZGPD может предпочтительно отправить Запрос Канала ZGPD с номерами каналов для будущих передач, включенными в подполя поля поведения с переключениями Канала. Следует отметить, что Запрос Канала ZGPD используется здесь как своего рода «фиктивный» пакет для инициирования осуществления связи со стороны TempMaster (не вызывая путаницы в системе GPDF Данных). Более того, в особенности в случае, когда было запрошено переключение каналов, ZGPD может указать в ответ на фиктивный пакет последующие каналы, по которым он будет осуществлять прием, тем самым позволяя посреднику настроить свой Tx канал и пакет, который должен быть доставлен. Впрочем, также может быть использован другой формат для «фиктивного» пакета.

На этапе S210. После приема GPDF от ZGPD, TempMaster отправляет команду обновления ZGPD. Затем, оно может отправить подтверждение ZGPS (например, уведомление ZGP).

На этапе S211. В зависимости от значения параметра ACK, ZGPS рассматривает, что обновление выполнено успешно:

если NO ACK (НЕТ ACK): После передачи Ответа ZGP с командой обновления ZGPD;

если SENT (ОТПРАВЛЕНО): После приема Уведомления ZGP с Запросом Канала ZGPD;

если ACK: когда ZGPD отправляет команду Успеха ZGPD;

если ACK вида «ZGPD использует параметр» (и обновлялся канал), то продолжают следующим образом (S212-S214);

если ACK вида «ZGPD использует параметр» (и обновлялся PANId (идентификатор персональной сети)/ключ), то продолжают следующим образом, как на этапах S215-S218.

На этапе S212. ZGPS может отправить Ответ ZGP, предпочтительно без команды ZGPD, или с назначенной «фиктивной» командой ZGPD (например, командой Ожидания Обновления ZGPD с подполем Войти/выйти, установленным в значение «Выход») и инструктирующий TempMaster о прослушивании НОВОГО рабочего канала (как указано в поле Tx канала TempMaster/поле Tx канала ZGPP команды Ответа ZGP) для некоторой связи от ZGPD.

На этапе S213. После приема Ответа ZGP, TempMaster переключается на канал, указанный ZGPS, и запускает таймер. Как только оно принимает GPDF от данного ZGPD (и проверки после приема пройдены), оно сразу переключается обратно на старый рабочий канал и отправляет туда Уведомление ZGP.

На этапе S214. ZGPS рассматривает обновление как успешное, если оно принимает Уведомление ZGP, несущее Успех ZGPD.

На этапе S215. Обновляемый параметр должен быть временно модифицирован в Посреднике TempMaster:

если параметр это PANId, то он может быть временно перезаписан новым значением. Или предпочтительно TempMaster может быть временно переведено в беспорядочный режим.

Если параметр - это ключ, то временно может быть перезаписан атрибут ключа ZGPD. Или предпочтительно, новый ключ может быть сохранен в атрибуте Альтернативного Ключа ZGPD.

Если особые мандаты (ключ, адрес) требуются для выполнения такого обновления на ZGPP, то ZGPS может проинформировать правильный объект технического обслуживания, чтобы разрешить ему выполнить сначала обновления, перед тем как выполняются этапы S216-S218. Это может быть выполнено самое раннее на этапе S202, и самое позднее на этапе S216.

На этапе S216. ZGPS отправляет Ответ ZGP, предпочтительно без команды ZGPD, или с назначенной «фиктивной» командой ZGPD (например, командой Ожидания Обновления ZGPD с подполем Войти/Выйти, установленным в значение «Выйти») и инструктирует TempMaster доставить его по рабочему каналу.

На этапе S217. После приема данного Ответа ZGP, TempMaster запускает таймер. Если оно принимает GPDF от ZGPD (и проверки после приема пройдены), то оно отправляет ZGPS Уведомление ZGP с принятым GPDF.

На этапе S218. ZGPS рассматривает обновление как успешное, если он принимает Уведомление ZGP с Успехом ZGPD.

На этапе S219. Как только обновление выполнено успешно (в соответствии с требуемым критерием), то ZGPS - если запрошено, и в запрашиваемом режиме - может отправить подтверждение объекту технического обслуживания в примере реализации.

В варианте данного варианта осуществления, чтобы убедиться в том, что данный способ также работает при централизованной установке (при инициировании процесса объектом технического обслуживания ZigBee/ZGPD), объекту технического обслуживания может потребоваться убедиться в том, что подтверждения доставляются себе самому, так что он может разместить следующий GPDF в TempMaster.

Это может быть выполнено посредством того, что объект технического обслуживания (временно) становится членом управляемой группы ZGPD [т.е., добавляя группу в свой список APS, для соответствующей конечной точки], если это имеет место, или посредством временного добавления в TempMaster одноадресного объединения в пару со своим собственным адресом, так, что он принимает Уведомления ZGP. Также, могут быть установлены команды Статуса Обновления Параметра ZGP.

При такой установке, устройство, инициирующее обновление параметра (объект технического обслуживания ZigBee/ZGPD), также может предоставить установки для команды Ожидания Обновления ZGPD, либо посредством отправки команды TempMaster/потребителю, либо посредством включения их в инициирующую команду (Ответ ZGP или Предупреждение Технического Обслуживания Системы ZGP).

Во втором варианте осуществления, больше решения принимается в TempMaster, которое может быть «интеллектуальным» ZGPP/ZGPS/ ZGPC.

На этапе 1. ZGPS, организованный в пару с ZGPD, узнает об ожидающем обновлении параметра (например, посредством способа, описываемого здесь позже в дополнительном решении, т.е. посредством приема Ответа ZGP или Предупреждения Технического Обслуживания Системы ZGP).

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

На этапе 3. Он формирует команду Ожидания Обновления ZGPD, и ее дополнительные опции устанавливает соответственно.

Например:

- Расширить Rx Окно - устанавливается, если кадр обновления длиннее минимального Rx кадра, который определен стандартом;

- Увеличить частоту представления отчета - устанавливается, если время обновления (например, как указывается объектом технического обслуживания ZigBee) короткое;

- ACK - может быть установлена в соответствии с приоритетом обновления и запросом со стороны объекта технического обслуживания;

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

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

- Использовать особую команду для Tx; опция, которая запрашивает ZGPD использовать назначенную команду (например, команду Запроса Канала ZGPD с обоими подполями канала, установленными в текущий рабочий канал, как известно ZGPD, или команду Успеха ZGPD) для объявления возможностей приема;

- Войти/Выйти в/из Режима; опция, которая запрашивает у ZGPD выполнение переключения на особое поведение или переключения обратно на рабочий режим.

На этапе 4. TempMaster помещает команду Ожидания Обновления ZGPD в свою zgpTxQueue, и доставляет ее ZGPD после приема первого GPDF с установленным RxAfterTx от данного ZGPD.

На этапе 5. После приема команды Ожидания Обновления ZGPD, ZGPD - если способно и проверки после приема пройдены - модифицирует связанное с обновлением поведение, как запрашивается командой Ожидания Обновления ZGPD и в соответствии с его способностями. Например, ZGPD входит в «режим приема параметра» (может потребовать установки внешней переменной в значение «режим приема параметра») или «режим ввода в эксплуатацию»; применительно к запросам ACK: оно устанавливает внешнюю переменную для отправки после приема новых параметров команды Успеха ZGPD, используя старые/новые параметры. Кроме того, оно может ограничить количество повторных передач в GPDF или время между повторными передачами своих собственных пакетов данных (GPDF), или использовать назначенный короткий GPDF, чтобы сэкономить больше энергии для приема/сохранения нового параметра. Оно также может изменить интервал представления отчета.

На этапе 6. После доставки команды Ожидания Обновления ZGPD, TempMaster создает кадр обновления ZGPD (конфигурация Канала ZGPD/Ответ Ввода в Эксплуатацию), и помещает его в свою zgpTxQueue.

На этапе 7. После приема следующей передачи, в «режиме приема параметра», ZGPD может предпочтительно отправить Запрос Канала ZGPD с номерами каналов для дальнейших передач, включенными в подполя поля поведения с переключением Каналов.

На этапе 8. После приема GPDF от ZGPD, TempMaster отправляет команду обновления.

На этапе 9. Как и в первом варианте осуществления, затем, в зависимости от значения параметра ACK:

a. Если NO ACK/SENT: то ZGPD рассматривает обновление, как выполненное успешно.

b. Если ACK (и обновляемым параметром был канал), продолжают как этапе (10).

c. Если ACK (и обновляемым параметром был PANID/ключ), то продолжают как на этапе (11).

На этапе 10. TempMaster переходит на новый рабочий канала (как указано Ответом ZGP или командой Предупреждения Технического Обслуживания Системы ZGP), и запускает таймер. Если до таймаута не принята команда Успеха ZGPD, то он переключается обратно на рабочий канал и вновь переходит к этапу 6. ZGPS рассматривает обновление как успешное, если он принимает команду Успеха ZGPD.

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

a. Если новым параметром является PANId, то PANId TempMaster может быть временно перезаписан новым значением. Или предпочтительно TempMaster может быть временно переведен в беспорядочный режим.

b. Если новым параметром является ключ, то атрибут ключа ZGPD может быть временно перезаписан. Или предпочтительно, новый ключ может быть сохранен в атрибуте Альтернативного Ключа ZGPD.

Это может быть выполнено самое раннее на этапе 2 (например, если изменение обеспечивает возможность приема как со старым, так и с новым параметрами, в качестве указанных выше предпочтительных опций), и самое позднее на этапе 12.

ZGPS рассматривает обновление как успешное, если он принимает команду Успеха ZGPD.

На этапе 12. Как только обновление выполнено успешно (в соответствии с требуемым критерием), ZGPS - если запрошено, и в запрошенном режиме - отправляет подтверждение объекту технического обслуживания.

Следует понимать, что точно такое же поведение, как то, что описывается здесь для TempMaster ZGPS, может быть выполнено TempMaster ZGPP. Тем не менее, ZGPP должен был бы иметь понимание о процессе обновления (в соответствии с текущим техническим описанием ZGP, он только отправляет команды ZGPD, сформированные ZGPS или объектом технического обслуживания, и осуществляет туннелирование команд, принятых от ZGPD).

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

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

Пример формата кадра команды Ожидания Обновления ZGPD иллюстрируется на Фиг. 3A и 3B.

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

В дополнение, команда Ожидания Обновления ZGPD может, как иллюстрируется на Фиг. 3A, включать в себя поле с некоторым количеством подполей/флагов, для модификации поведения ZGPD особым образом, как описано выше в первом и втором варианте осуществления. После ее приема, ZGPD модифицирует свое поведение, как оно может, учитывая значения в команде.

Подполе Войти/Выйти в/из Режима, если установлено в значение 0b1, указывает на то, что ZGPD должно - если способно - выйти из рабочего режима и войти в особый режим обновления - либо режим приема параметра, если поддерживается, либо режим ввода в эксплуатацию, если поддерживается - если установлено подполе Войти в Режим Ввода в Эксплуатацию. Если подполе Войти/Выйти в/из Режима установлено в значение 0b0, то это указывает на то, чтобы ZGPD переключилось обратно в рабочий режим.

Подполе Расширить Rx Окно, если установлено в значение 0b1, то указывает на то, что ZGPD должен - если способен - расширить продолжительность окна приема после следующей передачи ZGPD за пределы минимально, определенной стандартом продолжительности ZGPD. Это затем позволяет осуществлять прием более длинных кадров, отправляемых ZGPD, и/или передачу TempMaster кадра ZGPD более одного раза (чтобы обеспечить надежный прием даже в случае, когда первая передача частично испорчена). Для удовлетворения этого, ZGPD - в зависимости от его энергетических ресурсов и способностей - может потребоваться сократить передачу/ограничить количество повторных попыток или отправить более короткие кадры.

Подполе Увеличить Частоту Представления Отчета, если установлено в значение 0b1, указывает на то, что ZGPD должно - если способно - временно увеличить свою частоту представления отчета. Для удовлетворения этого, ZGPD - в зависимости от его энергетических ресурсов - может потребоваться сократить передачу/ограничить количество повторов.

Подполе Требуется ACK указывает на то, запрашивает ли TempMaster от ZGPD подтверждение приема новых параметров. Оно может принимать следующие значения:

00 - нет ACK;

01 - ACK, посредством отправки команды Успеха ZGPD, используя старый параметр (отсрочка переключения параметров);

10 - ACK, посредством отправки команды Успеха ZGPD, используя новый параметр (немедленное переключение параметров);

11 - зарезервировано.

Значения могут быть определены устройством, которое управляет процессом обновления ZGPD (потребителем/TempMaster/объект технического обслуживания) или могут быть извлечены из команды, инициирующей процесс обновления параметра, например, расширенный Запрос ACK из Ответа ZGP или команды Предупреждения Технического Обслуживания Системы ZGP.

Подполе Разрешить Поведение с Переключением Каналов, если установлено в значение 0b1, указывает на то, что ZGPD должно - если способно - выбрать канал из поддерживаемого набора каналов для каждой последующей передачи.

Подполе Войти в Режим Ввода в Эксплуатацию, если установлено в значение 0b1, указывает на то, что ZGPD должно, если способно, переключиться на режим ввода в эксплуатацию.

Подполе Использовать Особую Команду Для Tx, если установлено в значение 0b1, указывает на то, что ZGPD должно - если способно - использовать назначенную команду (например, команду Запроса Канала ZGPD или команду Успеха ZGPD) для указания дополнительных возможностей приема в особом режиме. Особая команда предпочтительно отправляется единожды, или может быть повторена, как определено для обычного GPDF.

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

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

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

Дополнительное решение, которое может быть объединено с предыдущими вариантами осуществления, обеспечивает эффективную и надежную доставку измененных параметров сети к ZGPD, работающему в сетях ZigBee. С этой целью, устройства инфраструктуры ZGP, т.е. устройства ZigBee, которые выполнены с возможностью осуществления связи с ZGPD, в соответствии со стандартом ZGP, информируются о планируемом изменении параметра заранее посредством несущего ответственность объекта технического обслуживания ZigBee, например, Центра Управления Безопасностью, Устройства Координации PAN ZigBee или Устройства Управления Сетью, таким образом, что они имеют время для обновления ZGPD. Как только обновление выполнено, устройство инфраструктуры ZGP может предоставить несущему ответственность объекту технического обслуживания ZigBee ответ статуса обновления. Для этих целей определены новые форматы кадра ZGP и расширения кадра.

В соответствии с техническим описанием ZigBee, Документ ZigBee 053474r19, «ZigBee specification», ревизия 19, 12 октября 2010г., раздел 4.6.3.4, обновление ключа защиты выполняется с помощью подхода из 2 сообщений. С помощью первого сообщения, ключ распространяется всем устройствам ZigBee посредством одноадресной или широковещательной передачи. С помощью второго сообщения, устройства должны переключиться на использование нового ключа.

В соответствии с техническим описанием ZigBee документ 053474r19, «ZigBee specification», ревизия 19, 12 октября 2010г., раздел 3.10 и Приложение E, обновления канала и PANId выполняются посредством широковещательной передачи от Устройства Управления Сетью/Устройства Координации PAN ZigBee. Через фиксированный промежуток времени после приема данного сообщения (nwkNetworkBroadcastDeliveryTime (время широковещательной доставки NWK по сети), соответствующий паре секунд в сетях ZigBee-PRO), каждое устройство переключается на новую конфигурацию.

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

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

В соответствии с техническим описанием ZGP, как определено в Документе ZigBee 095499, «Draft ZigBee Green Power Specification», версия 0.9, ревизия 16, 16 мая 2011 г., ZGPD, если оно обладает достаточными энергетическими ресурсами, может, в выбранные моменты времени, принять сообщение в течение ограниченного времени непосредственно после того, как оно отправило сообщение. В случае переключателя ZGPD, энергия как для приема, так и для отправки, поступает от одного и того же переключения коромысла пользователем. Из-за ограничений на энергетические ресурсы, эти устройства также не могут обнаружить новые параметры посредством активного поиска. ZGPD указывает способность приема в обычном кадре, который оно отправляет после инициирующего события со стороны пользователя или датчика или приложения или времени или устройства для сбора энергии/хранилища энергии, посредством установки флага RxAfterTx. Пять (5) миллисекунд спустя данной передачи, ZGPD активирует свой радиоприемник на прием, в течение, по меньшей мере, 0,576 мс и, как правило, не дольше. Из-за этого очень ограниченного по времени механизма, отправитель не использует множественный доступ с контролем несущей и предотвращением конфликтов (CSMA/CA), чтобы не тратить впустую возможность передачи. Следовательно, критично то, что только одно устройство осуществляет передачу к ZGPD, в противном случае, несколько передач будут конфликтовать с вероятностью близкой к 1. Для этого, техническое описание ZGP определяет процедуру выборов TempMaster, таким образом, что потребитель, управляемый ZGPD, выбирает одно устройство из посредников, выполняющее переадресацию от имени данного конкретного ZGPD, и самого себя, если оно находится в диапазоне радиосвязи ZGPD, посредством использования критерия расстояния до исходного ZGPD и короткого адреса устройства инфраструктуры ZGP. Тем не менее, недостаток данного механизма состоит в том, что он не обеспечивает разрешение между несколькими потребителями, которые управляются одним и тем же ZPGD, в частности, если они назначают себя в качестве TempMaster. Настоящее решение предлагает изменить процедуру выборов TempMaster, и кадр Ответа ZGP для обеспечения этого.

В дополнение, текущие выборы TempMaster/посредника FirstToForward (Первого для Переадресации) могут быть выполнены сразу после приема командного кадра ZGPD с установленным подполем RxAfterTx. Тем не менее, ни адрес выбранного TempMaster, ни информация о том, находится ли потребитель в непосредственном диапазоне радиосвязи ZGPD, в настоящее время не сохраняется в потребителе. Буферизация кадра обновления до тех пор, пока не произойдет следующее взаимодействие с ZGPD, чтобы сначала определить TempMaster, а затем подготовить кадр обновления ZGPD, привносит дополнительную задержку, и, следовательно, может привести к сокращению доли успешных попыток обновления. Вследствие этого, самоорганизующуюся доставку кадра к ZGPD подобно той, например, что инициируется обновлением параметра ZigBee, выполнить сложно. Чтобы справиться с этим, предлагается хранить связанную с TempMaster информацию в потребителе. В частности, предлагается применительно к потребителю хранить дополнительно следующую информацию о каждом (со способностью RxAfterTx) организованном в пару ZGPD:

(i) Флаг InRange (В Диапазоне) - указывающий на то, способен ли потребитель осуществлять прием непосредственно от ZGPD и

(ii) Поле TempMaster - указывающее последнее избранное TempMaster или текущего первого для переадресации посредника.

(iii) Поле Расстояние до TempMaster - указывающее расстояние до TempMaster, также, если им является сам потребитель. Эти элементы могут быть сохранены в записи Таблица Потребителя или отдельно; все или только некоторые из них, в качестве обязательных или опциональных элементов.

Для того чтобы выполнить обновление ZGPD, объект технического обслуживания ZigBee имеет - в дополнение к функциям, которые определены техническим описанием ZigBee - следующие функции:

1) Он знает, используются ли устройства ZGP в системе.

2) Он включает в себя политику, чтобы отложить обновление параметра ZigBee, чтобы предоставить дополнительные возможности обновления для ZGPD.

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

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

(ii) Если объект технического обслуживания ZigBee обладает способностью поддержки ключа NWK для ZGPD, то он предпочтительно будет знать, извлечен ли ключ, используемый для защиты связи ZGPD, из обновляемого ключа NWK ZigBee, и, следовательно, требуется ли обновление ZGPD и откладывание обновления параметра ZigBee. В качестве альтернативы, если он не обладает способностью обнаружения/получения информации об используемом типе ключа защиты ZGPD (конкретным ZGPD), то объект технического обслуживания ZGPD/устройства инфраструктуры ZGP принимают данное решение, посредством проверки используемого типа ключа защиты (конкретным ZGPD). Это выполняется как можно раньше в процессе обновления, чтобы ограничить трафик.

(iii) Если объект технического обслуживания ZigBee способен поддерживать PANId, то он предпочтительно будет знать, использует ли любое ZGPD значение PANId (а не используемое по умолчанию широковещательное значение PANId соответствующее 0xffff), и, следовательно, требуется ли обновление ZGPD и откладывание обновления параметра ZigBee.

(iv) Откладывание может зависеть от типа обновляемого параметра и способа ZigBee его обновления. В одном примере, может откладываться как доставка нового параметра узлам ZigBee, так и активация нового параметра. В другом примере, может откладываться только активация нового параметра; это возможно для обновления Ключа Сети ZigBee.

3) Он может иметь политику инициирования обновления параметра ZigBee в зависимости от хода обновления ZGPD. Критерии политики относятся к продавцу объекта технического обслуживания ZigBee, профилю приложения, его использующее, или администратору конкретной сети, и могут включать в себя:

(i) предоставление ZGPD фиксированного количества дополнительного времени для обновления;

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

(iii) обновлен заданный процент (подмножества) ZGPD.

4) Объект технического обслуживания ZigBee обладает способностью инициирования обновления ZGPD, посредством отправки:

(i) Команды Предупреждения Технического Обслуживания Системы ZGP;

(ii) И/или команды Ответа ZGP - модифицированной, как предложено ниже;

5) Опционально, объект технического обслуживания ZigBee обладает способностью назначения TempMaster для ZGPD.

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

7) Кроме того, объект технического обслуживания ZigBee может быть выполнен с возможностью представления результатов обновления пользователю (например, администратору сети), например, в качестве карты узлов, указывающей местоположение ZGPD, требующих обновления вручную.

8) Опционально, объект технического обслуживания ZigBee обладает способностью повторного инициирования процесса обновления для выбранных ZGPD после того, как обновление параметра вступило в силу в сети ZigBee, например, в случае обновления канала посредством повторной отправки команды Ответа ZGP выбранному TempMaster, инструктирующей его временно переместиться на старый рабочий канал.

Все вышеупомянутые функции могут быть выполнены актуальным несущим ответственность объектом технического обслуживания ZigBee (Центром Управления Безопасностью, Устройством Координации PAN ZigBee, Устройством Управления Сетью).

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

Первым примером данного решения является обновление канала с помощью полуцентрализованных выборов TempMaster. Предварительными условиями являются то, что объект технического обслуживания ZigBee (Устройство Управления Сетью ZigBee или Устройство Координации PAN ZigBee в данном случае) осведомлен о наличии ZGPD в сети, и то, что для каждого ZGPD со способностью RxAfterTx, по меньшей мере, один ZGPS, который управляется этим ZGPD, известен объекту технического обслуживания ZigBee (например, в результате ввода в эксплуатацию или на основании планирования, назначения групп, или на основании считывания таблиц потребителей). Кроме того, он имеет некоторые критерии политики в отношении того, когда выполнять обновления параметра ZigBee (например, истек Таймаут ZGPD, или был успешно обновлен заданный процент заданного подмножества ZGPD).

На первом этапе, объект технического обслуживания ZigBee отправляет команды Предупреждения Технического Обслуживания Системы ZGP выбранному набору потребителей. Объект технического обслуживания ZigBee определил набор потребителей и списки ZGPD для этих потребителей таким образом, что каждое ZGPD со способностью RxAfterTx встречается в списке ZGPD ровно одной переданной команды Предупреждения Технического Обслуживания Системы ZGP. Подполе наличия Параметров указывает на наличие поля Нового Канала. Поле Нового Канала указывает значение нового рабочего канала. Подполе Выполнения выборов TempMaster устанавливается в значение 0b1. Подполе AckReqest (Запрос ACK) устанавливается в соответствии с критерием политики обновления объекта технического обслуживания ZigBee.

На втором этапе, каждый потребитель, принимающий команду Предупреждения Технического Обслуживания Системы ZGP, выполняет два подэтапа в виде определения TempMaster и создания команды Конфигурации Канала ZGPD, в силу чего очередность их выполнения несущественна. Опционально, каждый потребитель проверяет флаг RxOnCapability каждого ZGPD в поле ZGPDList (список ZGPD), и выбирает для обновления только те, для которых он соответствует значению ИСТИНА. Каждый потребитель определяет TempMaster для каждого из обновляемых ZGPD.

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

Для каждого обновляемого ZGPD, потребитель, принимающий команду Предупреждения Технического Обслуживания Системы ZGP, создает команду Конфигурации Канала ZGPD в соответствии с техническим описанием ZGP со значением подполя Рабочего Канала поля Канал, установленным в значение поля NewChannel (новый канал) из команды Предупреждения Технического Обслуживания Системы ZGP. Если выбранным TempMaster является другое устройство (посредник или потребитель), то потребитель отправляет команду Ответа ZGP. Значение поля Запрос Ack и других связанных (под)полей команды Ответа ZGP устанавливаются в значения соответствующих (под)полей в команде Предупреждения Технического Обслуживания Системы ZGP. Подполе команды Приоритета ZGPD устанавливается в значение 0b1. Поле Таймаут имеет значение, равное полю времени Обновления в команде Предупреждения Технического Обслуживания Системы ZGP. Поле ID Команды ZGP и Полезной Нагрузки Команды ZGPD имеют значения, как определено выше.

На третьем этапе, каждое TempMaster помещает команду ZGPD для ZGPD в свою zgpTxQueue, в соответствии с битом приоритета, т.е., если уже существует запись для данного SrcID (идентификатора источника) в zgpTxQueue, она замещается текущей командой Конфигурации Канала ZGPD, установлен или нет бит приоритета в старом сообщении. Если потребитель сам является TempMaster, то он действует, как если бы он принял команду Ответа ZGP с подполем команды Приоритета ZGPD, установленным в значение 0b1.

На четвертом этапе, каждый ZGPP и ZGPS, который является TempMaster для некоторого ZGPD отправляет команду ZGPD каждому ZGPD, для которого он является TempMaster, когда бы у него ни появилась возможность сделать это и в течение времени, составляющего Таймаут мс с момента приема команды Ответа ZGP/команды Предупреждения Технического Обслуживания Системы ZGP.

На пятом этапе, если подполе Запроса Ack имеет значение 0b1, то TempMaster информирует объект технического обслуживания ZigBee в любое время, когда бы он ни отправил команду Конфигурации Канала ZGPD к ZGPD, посредством отправки команды Статуса Обновления Параметра ZGP с соответствующим значением статуса обновления.

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

Возможны другие варианты данного примера, с централизованным процессом выборов посредника (Устройство Координации, или объект технического обслуживания берет на себя выборы) или распределенным процессом выборов посредника (потребители, связанные с ZGPD, автоматически избирают посредника).

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

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

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