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

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

Изобретение относится к вводу в эксплуатацию устройств с ограничением по энергии в сеть. В частности, оно относится к вводу в эксплуатацию устройств ZigBee Green Power (ZGPD) согласно спецификации ZigBee Green Power (ZigBee «Зеленая Энергия») в сеть ZigBee, включающую в себя устройства с возможностями ZGP.

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

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

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

Еще одним примером ZGPD является RC с нажимной кнопкой или с питанием от солнечной батареи.

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

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

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

В контексте настоящего описания изобретения, термин “посредник” используется в отношении устройства, способного принимать сигналы от ZGPD/устройства с ограничением по энергии.

В случае ZGPD согласно спецификации ZGP, это может быть ZGPP, или ZGPT+, или ZGPC согласно спецификации ZigBee Green Power. В случае любой другой технологии это приемник, предусмотренный этой технологией.

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

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

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

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

Пассивное или активное сканирование сетевой активности (согласно процедурам IEEE 802.15.4) слишком энергозатратно для ZGPD.

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

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

Сущность изобретения

Задачей изобретения является предложить способ определения рабочего канала c_op по п.1 и устройство-посредник по п.15.

В одном конкретном варианте осуществления способа устройство с ограничением по энергии передает последующие сообщения с маяком, пока не будет принят ответ на маяк, для каждого маяка i на канале succⁱ(c) в широковещательном режиме MAC,

- причем succ - арифметическая функция, из C в C, i - неотрицательное целое число, succⁱ указывает, что функция succ применяется i раз, так что succ^m(c)=succ(succ^m-1(c)), и переключается в режим приема на канале listen(succⁱ(c)),

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

- временное ведущее устройство переключает свой радиоприемник на канал succ^m(c),

- после приема маяка на succ^m(c) временное ведущее устройство передает ответ на маяк по каналу listen(succ^m(c)),

- устройство с ограничением по энергии принимает ответ на маяк по каналу listen(succ^m(c)) и определяет c_op.

В другом варианте осуществления, функции listen и succ таковы, что существует целое число d, при котором listen(succ^d(c))=c.

В другом варианте осуществления функции listen и succ и целое число d таковы, что listen(succ^d(c))=c, и параметр m имеет фиксированное значение m=d, так что устройство с ограничением по энергии принимает ответ на маяк по рабочему каналу.

В другом варианте осуществления функция listen такова, что listen(c)=c, поэтому устройству с ограниченными энергоресурсами не приходится переключаться на другой радиоканал для приема сигналов.

В другом варианте осуществления функция listen является постоянной функцией, поэтому устройство с ограничением по энергии всегда слушает один и тот же канал.

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

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

В другом варианте осуществления функции succ и/или listen известны как устройству с ограничением по энергии, так и посредникам.

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

В другом варианте осуществления параметр m фиксируется согласно спецификации или при изготовлении ZGPD.

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

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

В другом варианте осуществления определение временного ведущего устройства осуществляется согласно любому распределенному или централизованному алгоритму.

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

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

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

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

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

Изобретение также относится к устройству с ограничением по энергии, содержащему средство для осуществления способа согласно изобретению. Это устройство является, например, устройством ZigBee Green Power.

Изобретение также относится к устройству-посреднику, содержащему средство для осуществления способа согласно изобретению. Устройство-посредник является, например, устройством ZigBee Green Power Proxy (посредником ZigBee Green Power) или устройством ZigBee Green Power Combo (комбинированным устройством ZigBee Green Power).

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

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

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

Для этого ZGPD передает несколько сообщений с маяком (“маяк”) на разных радиоканалах и слушает ответ на это сообщение с маяком (“ответ на маяк”).

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

Такое действие может включить режим ввода в эксплуатацию или требоваться для каждой отправки маяка.

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

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

При отправке сообщений с маяком в широковещательном режиме MAC множественные посредники могут отправлять ответ на маяк. Поскольку эти посредники могут находиться за пределами дальности радиосвязи друг друга, их ответные сообщения могут конфликтовать на ZGPD, что не позволит ZGPD правильно принять ответ на маяк. Эта проблема известна в уровне техники как проблема скрытого узла. Однако известные в уровне техники решения этой проблемы нелегко применить к устройству с ограничением по энергии, поскольку ему может не хватить энергии для нескольких попыток или для приема передачи с большой задержкой. Механизм, позволяющий гарантировать, что только один посредник отправляет ответ на устройство с возможностью отбора энергии и, таким образом, что сообщение ответа на маяк правильно принято, известен в стандарте ZGP [1, раздел 6.3 и A.3.6.2.3]. Время выполнения этого механизма, однако, будет, вероятно, значительно больше времени, в течение которого ZGPD сможет хранить отобранную энергию, поэтому ZGPD не может уверенно принимать ответ на маяк посредством того же нажатия кнопки, которое использовалось для передачи этого маяка.

Таким образом, задачей изобретения является обеспечение способа, позволяющего ZGPD определять c_op, радиоканал, на котором канал фактически работает.

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

Набор C каналов может быть полным набором каналов, поддерживаемых данной технологией и полосой и регионом. Например, для ZGPD, работающего в полосе 2,4 ГГц, C может включать в себя все каналы 11-25(26) IEEE802.15.4. Это обеспечивает полную функциональную совместимость с принимающими устройствами, где реализована эта конкретная технология, но может увеличивать длительность и сложность (в зависимости от того, как инициируется отправка маяка) процедуры ввода в эксплуатацию. Набор C каналов также может содержать выбранный поднабор всех доступных каналов. Например, спецификация ZGP рекомендует использовать следующие 4 канала: 11, 15, 20, 25; последние три находятся между неперекрывающимися каналами, используемыми стандартом 802.11, действующим в той же полосе 2,4 ГГц; канал 11 является каналом, принятым по умолчанию, в реализациях многих платформ.

Кроме того, ZGPD знает две функции, succ («последующий канал») и listen («прослушивание»), обе из C в C, т.е. обе функции принимают входные сигналы из C и вырабатывают выходные сигналы в C. Функция succ описывает порядок, в котором ZGPD переключается между каналами для передачи своих маяков. После отправки на канале c ZGPD будет отправлять на канале succ(c) при следующем нажатии кнопки или, в более общем случае, при следующей попытке найти рабочий канал. Для неотрицательного целого числа m обозначение succ^m указывает, что функция succ применяется m раз. Таким образом, succ⁰(c)=c, и для m≥1, succ^m(c)=succ(succ^m-1(c)).

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

Три параметра - набор C, а также функции succ и listen - могут быть предварительно определены в спецификации и, следовательно, быть известны всем устройствам в сети. Это может быть одно определение, включенное в спецификацию; таким образом, ZGPD не требуется включать эту информацию в явном виде в маяк или. Может существовать несколько альтернатив, заданных в спецификации, кодированных во флаге или поле перечисления (одном для всех трех параметров) или в некотором количестве из 2-3 флагов/полей перечисления для комбинаций параметров или каждого параметра в отдельности. Предпочтительно включать их в маяк (передавать иначе, например, посредством информации об изделии, что требует потенциально другого взаимодействия с пользователем или режима ввода в эксплуатацию на стороне сети).

Определение поведения ZGPD при переключении каналов может выходить за рамки спецификации и оставаться в ведении разработчиков. Затем, все/некоторые/части параметров следует в явном виде передавать в маяке. Например, ZGPD может включать в маяк полный список каналов C или следующие N каналов, где N может быть равно 1. ZGPD может включать формулу функции для succ и listen.

Возможна также любая комбинация вышеперечисленных вариантов.

Согласно изобретению для каждого случая этой попытки определения рабочего канала (далее именуемой “попытка”) ZGPD использует доступную энергию (например, отбираемую при нажатии кнопки в случае электромеханического переключателя с нажимной кнопкой или, например, в случае переключателя с питанием от солнечной батареи, оставшейся после предыдущей попытки и отобранной с тех пор) для осуществления этапов, содержащих:

- отправку маяка в сеть по радиоканалу c;

- прием, по радиоканалу listen(c), ответа на маяк, отправленного в любой предыдущей попытке, если любой такой ответ на маяк отправлен;

- вычисление функции succ;

- сохранение информации состояния, относящейся к succ.

Порядок операций и количество конкретных операций на каждом этапе может изменяться. Некоторые примеры описаны в нижеприведенных вариантах осуществления.

Все посредники работают на рабочем канале и, следовательно, не принимают маяк, если c≠c_op. Если c=c_op, один или более посредников принимают маяк, и применяется механизм для выбора уникального “временного ведущего устройства”, которое будет отправлять ответ на маяк.

Предпочтительно использовать механизм, описанный для ZGP (описанный в [1], раздел 6.3 и A.3.6.2.3), предусматривающий, что устройство спаривается с ZGPD (так называемым ZigBee Green Power Sink (ZGPS) (потребителем ZigBee Green Power), установленным на режим ввода в эксплуатацию) в процессе выбора временного ведущего устройства с кратчайшим расстоянием до ZGPD. Альтернативно, можно применять любой другой протокол/механизм, позволяющий выбирать одно (если возможно: с учетом дополнительных критериев, таких как расстояние/интенсивность сигнала) устройство для группы устройств, будь то распределенный или централизованный механизм.

Это временное ведущее устройство отвечает за отправку ответа на маяк на устройство с ограничением по энергии, но не передает ответ на маяк немедленно. Напротив, временное ведущее устройство переключает свой радиоприемник на канал succ^m(c_op) (где m - положительное целое число), канал, по которому ZGPD будет отправлять (один из) свой(их) следующий(х) маяк(ов). Когда временное ведущее устройство слышит этот следующий маяк на канале succ^m(c_op), оно передает ответ на маяк на канале listen(succ^m(c_op)); заметим, что это канал, который ZGPD слушает при отправке на канале succ^m(c_op). Ответ на маяк может предварительно вычисляться и считываться из буфера после приема сообщения с маяком или может вычисляться после приема сообщения с маяком.

Заметим, что временному ведущему устройству не нужно знать m: ему нужно знать значение функции succ^m (c_op) и знать, что если оно принимает следующий маяк на канале x, оно должно отправить ответ на маяк на канале listen(x). Наличие значения m ослабляет ограничение по минимальному времени между двумя последовательными нажатиями кнопки, но также увеличивает время выполнения процедуры. Для некоторых вариантов осуществления параметр m должен иметь фиксированное значение (равное 1 или большее чем 1), заданное спецификацией или задаваемое и сообщаемое для каждого устройства с возможностью отбора энергии или; в других вариантах осуществления, m может изменяться (например, в зависимости от нагрузки по трафику, расстояния (например, выраженного в количестве скачков) между ZGPD и устройством, с которым оно спаривается, плотности посредников и т.д.). Если m может изменяться, то его следует выбирать в ходе процедуры выбора временного ведущего устройства (в случае спецификации ZGP: посредством ZGPS в режиме ввода в эксплуатацию) или посредством самого временного ведущего устройства. Временному ведущему посреднику (или ZGPS, если используется процедура выбора временного ведущего устройства ZGP, и канал предписывается в этой процедуре) должно быть ясно, когда оно имеет возможность выбирать m и когда это число является фиксированным. Это может определяться спецификацией или от случая к случаю.

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

В первом и втором вариантах осуществления succ и listen таковы, что listen(succ^d(c))=c для всех c в C, где d - неотрицательное целое число.

Для каждой попытки ZGPD, таким образом, передает и принимает на разных радиоканалах, а именно радиоканалах c и listen(c), соответственно, благодаря чему, канал, на котором оно слушает, является каналом, на котором оно передавало в предыдущей попытке. Кроме того, временное ведущее устройство отправляет по радиоканалу (а именно, listen(succ^d(c_op))), который отличается от того, на котором оно приняло триггер для отправки ответа (канала succ^d(c_op).

В первом варианте осуществления значение m, таким образом, является фиксированным m=d согласно ZGPD или согласно спецификации. Преимущество этого варианта осуществления состоит в том, что ZGPD принимает ответ на маяк по рабочему каналу c_op и, следовательно, больше не нуждается в переключении каналов или в непосредственном получении значения c_op. Если устройство сохраняет канал, который оно слушает в каждой данной попытке, он равен c_op, поэтому его больше не нужно сохранять. Если устройство сохранило канал, на котором оно отправляет, оно может вычислить c_op как функцию, обратную succ(c), и должно сохранить его. Значение succ^m(c_op) должно быть известно временному ведущему устройству либо за счет наличия значения succ^m(c) в маяке, отправленном на канале c, либо за счет знания функции succ(c) в спецификации и знания m, либо за счет знания функции succ(c) и функции listen(c), либо в спецификации, либо присутствующей в маяке. Временное ведущее устройство также должно знать, что оно должно отправлять на c_op, либо поскольку это предписано в спецификации, либо за счет знания функции listen, либо из спецификации, либо из присутствия в маяке.

Во втором варианте осуществления значение m может изменяться. Временное ведущее устройство, таким образом, слушает на любом канале succ^m(c_op) и после приема маяка отправляет по радиоканалу listen(succ^m(c_op). Затем рабочий канал должен быть передан в ответе на маяк и сохранен ZGPD.

В третьем, четвертом и пятом вариантах осуществления listen(c)=c для всех c в C. В этом случае с помощью энергии, отбираемой из одного нажатия кнопки, ZGPD, таким образом, передает и принимает на одном и том же радиоканале, и временное ведущее устройство передает на канале, на котором оно приняло триггер для отправки ответа на маяк (а именно, канале succ^m(c_op)).

В третьем варианте осуществления значение m является фиксированным согласно ZGPD или согласно спецификации. Код ZGPD для управления попытками позволяет ZGPD сохранять значение c канала, на котором ZGPD передавало в m предыдущих попытках (а не значение, подлежащее использованию в текущей попытке succ^m(c)). Таким образом, ZGPD располагает значениями c_op, succ(c_op),…, succ^m-1(c_op) после приема ответа на маяк и, следовательно, не нуждается в повторном его сохранении или в непосредственном получении значения c_op (самое старое из m сохраненных значений - это значение, принимаемое за c_op). Альтернативно, временное ведущее устройство m раз применяет функцию, обратную функции последующего канала, к каналу, на котором оно приняло маяк.

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

В пятом варианте осуществления значение m может изменяться. В этом варианте осуществления значение c_op включается в сообщение ответа на маяк. Таким образом, ZGPD не нужно сохранять значения m, как во втором варианте осуществления; ему даже не нужно знать значение m. Нужно только, чтобы временное ведущее устройство, после приема второго маяка, например, на канале x, передавало свой ответ на маяк на канале listen(x) (в этом случае =x).

В шестом и седьмом вариантах осуществления ZGPD всегда слушает на одном и том же канале, т.е. listen(c)=k для всех c в C и некотором фиксированном k в C. Значение k может быть известно, поскольку оно установлено в спецификации, или оно может быть включено в маяк.

В шестом варианте осуществления значение m является фиксированным согласно ZGPD или согласно спецификации. ZGPD получает значение c_op из своей памяти (аналогично третьему варианту осуществления).

В седьмом варианте осуществления, значение m может изменяться. В этом варианте осуществления значение c_op включается в сообщение ответа на маяк, и, таким образом, ZGPD не нужно его помнить. Заметим, что в седьмом варианте осуществления ZGPD не нужно знать значение m; нужно только, чтобы временное ведущее устройство, после приема маяка, например, на канале x, передавало свой ответ на маяк на канале listen(x) (в этом случае =k).

После успешной попытки ZGPD больше не нужно перебирать каналы.

Это можно реализовать, например, с помощью переменной состояния, управляющей этим поведением перебора каналов. Это может быть, например, булево значение step_channel («перебор_каналов») (ИСТИНА/ЛОЖЬ), устанавливаемое при входе в рабочий режим и очищаемое в случае приема ответа на маяк.

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

Во 2-й альтернативе данные конфигурации включаются в ответ на маяк, также для обеспечения некоторых начальных проверок на стороне сети - некоторая информация о ZGPD должна быть включена в маяк (например, уникальный идентификатор устройства (в ZGPD: SrcID), тип устройства (в ZGP: DeviceID), возможности безопасности, ключ безопасности, запрошенные параметры); тогда как в случае реального обмена для ввода в эксплуатацию требуется дополнительный этап для обмена данными конфигурации (запрашивание и/или прием).

Первый способ также имеет несколько преимуществ, которые делают его предпочтительным вариантом:

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

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

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

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

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

Расширения

Для повышения надежности процесса присоединения в случаях проблем с распространением сигнала или помехи. Если вокруг ZGPD имеется несколько устройств, претендующих на роль посредников, можно назначить несколько N>1 “временных ведущих” посредников, каждый из которых будет работать на отдельном канале c_k, выбранном из набора C каналов, поддерживаемых ZGPD. Если временное ведущее устройство k (1≤k≤N) слышит маяк на канале c_k, оно отправляет ответ на маяк на канале listen(c_k). Предпочтительно, каналы c_1,…, c_n выбираются так, что ZGPD передает на них вскоре после приема посредниками (первого) маяка. Если функция succ известна, предпочтительным выбором для канала c_j является succ^j+s(c_op), где s - фиксированное целое число, например s=0, и j=1, 2,…, N (заметим, что маяк был принят на c_op). Значение c_op включается в ответ на маяк, т.е. можно использовать варианты осуществления 2, 5 и 7. Для применения варианта осуществления 7 требуется, чтобы никакие два ведущих устройства не отправляли одновременно, что, конечно, имеет место, если каждое ведущее устройство слушает на отдельном канале ZGPD и не передает на разных каналах c_i и c_j (где 1≤i≤N, 1≤j≤N ) до той же попытки прослушивания. Каждому из множественных временных ведущих устройств должно быть ясно, что они не могут свободно выбирать канал для прослушивания.

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

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

- Для каждой попытки ZGPD осуществляет много раз последовательность действий: отправку на канале c, переход в режим приема, прием на listen(c); в случае отсутствия приема ответа на маяк; и повторение последовательности. Где-то в ходе последовательности следующий канал для осуществления передачи будет определяться через succ(c) и некоторая соответствующая информация состояния будет сохраняться; это можно делать до отправки, после отправки, до входа в режим приема, после определения неудачного приема (например, по истечении лимита времени приема) или в любой другой момент, что очевидно специалистам в данной области техники.

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

- Для каждой попытки ZGPD сначала передает маяк по N каналам и затем слушает. Таким образом, для всех каналов, предназначенных для передачи в каждой конкретной попытке, listen(c) имеет одно и то же значение. Это может быть указано в маяке или быть предварительно задано, как описано выше.

В этом случае временное ведущее устройство может слушать следующий маяк на любом из каналов в следующей попытке (предполагая m=1). В качестве одного варианта временное ведущее устройство слушает последний канал, на котором осуществляется передача в следующей попытке. Этот канал может быть либо включен в маяк, либо (посредством модифицированной версии функции succ, известной в спецификации) выводиться из канала c_op, на котором был принят маяк.

Пример полной процедуры ввода в эксплуатацию

Выше был описан способ, позволяющий ZGPD находить рабочий канал сети ZigBee, существенный этап при вводе в эксплуатацию ZGPD. Далее мы опишем два примера ввода в эксплуатацию с использованием указанного способа в объеме спецификации ZGP [1], для ZGPD, и ZGPP, и ZGPS, заданных в ZG.

1-й способ ввода в эксплуатацию: короткие маяки

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

2. ZGPS извещает о режиме ввода в эксплуатацию все устройства с возможностями ZGP в сети ZigBee. Они входят в режим ввода в эксплуатацию на рабочем канале.

3. ZGPD отправляет короткий маяк, возможно, даже не несущий идентификатор ZGPD, но, возможно, содержащий информацию, касающуюся его будущих действий по перебору канала (если они уникально не предписаны спецификацией ZGP), на канале c, и затем слушает на канале listen(c).

4. ZGPD передает последовательные сообщения с маяком, пока не будет принят ответ на маяк, для каждого маяка i на канале succⁱ(c) и слушает на канале listen(succⁱ(c)).

5. Посредник сообщает ZGPS о приеме маяка на рабочем канале (и о его содержимом).

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

7. Назначенное(ые) временное(ые) ведущее(ие) устройство(а) активирует(ют) свой(и) приемник(и) на выбранном(ых) канале(ах) c, на которых ZGPD будет отправлять в будущем (когда их несколько: как указано ZGPS; если один: если не указано ZGPD и не задано профилем/ZGPD/способом, он может быть выбран самим ведущим устройством).

8. Назначенное временное ведущее устройство принимает маяк на канале c и отправляет ответ на маяк, указывающий прием маяка и, в необязательном порядке (варианты осуществления 2, 5 и 7), включающий в себя рабочий канал c_op.

9. ZGPD принимает запрос с маяком, в необязательном порядке сохраняет рабочий канал и сохраняет информацию состояния, указывающую, что рабочий канал найден (на фигуре, булево значение step_channel=ЛОЖЬ).

10. ZGPD и временное ведущее устройство возвращаются на рабочий канал (если c != c_op).

11. ZGPD и ZGPS обмениваются (через (одно из) временное(ых) ведущее(их) устройство(устройств)) данными конфигурации.

12. Ввод в эксплуатацию выполнен успешно, ZGPS и ZGPP могут выйти из режима ввода в эксплуатацию.

2-й способ ввода в эксплуатацию: длинные маяки

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

2. ZGPS извещает о режиме ввода в эксплуатацию все устройства с возможностями ZGP в сети ZigBee. Они входят в режим ввода в эксплуатацию на рабочем канале.

3. ZGPD отправляет длинный маяк, включающий в себя тип устройства (ZGPD DeviceID), поддерживаемый уровень безопасности и другие возможности устройства, его идентификатор (ZGPD SrcID), необязательно ключ безопасности и необязательно счетчик кадров безопасности, и информацию, касающуюся его будущих действий по перебору канала (если они уникально не предписаны спецификацией ZGP), на канале c, и затем слушает на канале listen (c).

4. ZGPD передает последовательные сообщения с маяком, пока не будет принят ответ на маяк, для каждого маяка i на канале succⁱ(c) и слушает на канале listen(succⁱ(c)).

5. Посредник сообщает ZGPS о приеме маяка на рабочем канале (и о его содержимом).

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

7. Временное(ые) ведущее(ие) устройство(а) слушает(ют) на (разных) канале(ах) c, на котором(ых) ZGPD будет отправлять в будущем.

8. После приема маяка на канале c временное ведущее устройство отправляет ответ на маяк на канале listen(c), указывающий прием маяка и содержащий данные конфигурации (если требуемы/запрошены) и в необязательном порядке (варианты осуществления 2, 5 и 7) рабочий канал.

9. ZGPD принимает запрос с маяком, в необязательном порядке сохраняет рабочий канал, сохраняет информацию состояния, указывающую, что рабочий канал найден (на фигуре, булево значение step_channel=ЛОЖЬ), и сохраняет сообщенные параметры конфигурации, при наличии.

10. Ввод в эксплуатацию выполнен успешно, ZGPS и ZGPP могут выйти из режима ввода в эксплуатацию.