Способ конфигурирования узла

Способ конфигурирования узла

Иллюстрации

Показать все

Реферат

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

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

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