ЭФФЕКТИВНАЯ СВЯЗЬ ДЛЯ УСТРОЙСТВ ДОМАШНЕЙ СЕТИ Российский патент 2020 года по МПК H04L12/28 H04L29/06 

ПредПОСЫЛКИ ИЗОБРЕТЕНИЯ

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

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

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

[0004] Многочисленные электронные устройства в настоящее время способны соединяться с беспроводными сетями. Например, технологии интеллектуальных измерительных приборов используют беспроводную сеть для передачи данных потребления электрической энергии, ассоциированных со связанной с местом жительства недвижимостью, обратно к предприятию коммунального обслуживания для мониторинга, выставления счетов и тому подобное. Ряд стандартов беспроводных сетей в настоящее время доступен, чтобы позволять электронным устройствам осуществлять связь друг с другом. Некоторые реализации интеллектуальных измерительных приборов, например, используют Интернет-протокол версии 6 (IPv6) в маломощных беспроводных персональных сетях (6LоWPAN), чтобы позволять электронным устройствам осуществлять связь с интеллектуальным измерительным прибором. Однако имеющиеся в настоящее время стандарты беспроводных сетей, такие как 6LоWPAN, в общем случае не могут быть хорошо оснащены, чтобы поддерживать электронные устройства, рассредоточенные по месту жительства или дому для одного или более практических сценариев. То есть, имеющиеся в настоящее время стандарты беспроводных сетей не могут эффективно соединять все электронные устройства сети безопасным, но простым, удобным для потребителя способом ввиду одного или более известных практических ограничений. Кроме того, для одного или более практических сценариев, имеющиеся в настоящее время стандарты беспроводных сетей не могут обеспечивать эффективный способ для добавления новых электронных устройств к существующей беспроводной сети специальным (ad hoc) образом.

[0005] Кроме того, при предоставлении стандарта беспроводной сети для электронных устройств для использования внутри и вокруг дома, было бы полезно использовать стандарт беспроводной сети, который обеспечивает открытый протокол для различных устройств, чтобы узнать, как получить доступ к сети. Кроме того, учитывая количество электронных устройств, которые могут быть ассоциированы с домом, было бы полезно, если бы стандарт беспроводной сети был способен поддерживать связь согласно Интернет-протоколу версии 6 (IPv6) таким образом, что каждое устройство может иметь уникальный IP-адрес и может быть доступным через Интернет, через локальную сеть в домашней среде и т.п. Кроме того, было бы полезно для стандарта беспроводной сети позволять электронным устройствам осуществлять связь в беспроводной сети с использованием минимальной величины мощности. Принимая во внимание эти признаки, представляется, что один или более недостатков представлены каждым известным доступным в настоящее время стандартом беспроводной сети в контексте обеспечения стандарта маломощной, основанной на IPv6 беспроводной ячеистой сети, который имеет открытый протокол и может быть использован для электронных устройств внутри и вокруг дома. Например, стандарты беспроводных сетей, такие как Bluetooth®, Dust Networks®, Z-Wave®, WiFi и ZigBee®, не могут обеспечить одну или более желательных функций, описанных выше.

[0006] Bluetooth®, например, в общем, обеспечивает стандарт беспроводной сети для передачи на короткие расстояния с помощью коротковолновых радиопередач. Как таковой, стандарт беспроводной сети Bluetooth® не может поддерживать сеть связи ряда электронных устройств, рассредоточенных по всему дому. Кроме того, стандарт беспроводной сети Bluetooth® не может поддерживать беспроводную ячеистую связь или IPv6-адреса.

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

[0008] Подобно стандарту беспроводной сети Dust Networks®, стандарт беспроводной сети, ассоциированный с Z-Wave®, не может быть открытым протоколом. Вместо этого, стандарт беспроводной сети Z-wave® может быть доступным только для авторизованных клиентов, которые встраивают конкретный чип приемопередатчика в свое устройство. Кроме того, стандарт беспроводной сети Z-wave® не может поддерживать связь, основанную на IPv6. То есть стандарт беспроводной сети Z-wave® может потребовать мостового устройства, чтобы преобразовывать данные, сгенерированные на Z-Wave®-устройстве, в данные, основанные на IP, которые могут быть переданы через Интернет.

[0009] Что касается стандартов беспроводной сети ZigBee®, то ZigBee® имеет два стандарта, обычно известные как ZigBee® Pro и ZigBee® IP. Кроме того, ZigBee® Pro может иметь один или более недостатков в контексте поддержки беспроводных ячеистых сетей. Вместо этого, ZigBee® Pro может зависеть, по меньшей мере частично, от центрального устройства, которое облегчает связь между каждым устройством в сети ZigBee® Pro. В дополнение к требованиям повышенной мощности для такого центрального устройства, те устройства, которые остаются включенными, чтобы обрабатывать, или отклоняют определенный беспроводный трафик, могут генерировать дополнительное тепло в своих корпусах, что может изменять некоторые показания датчика, например, показания температуры, получаемые устройством. Поскольку такие показания датчика могут быть полезны в определении того, каким образом каждое устройство в доме может работать, может быть выгодным избегать ненужной генерации тепла внутри устройства, которое может изменить показания датчика. Кроме того, ZigBee® Pro не может поддерживать связь по протоколу IPv6.

[0010] Что касается ZigBee® IP, то ZigBee® IP может привести к одному или более недостаткам в контексте прямой связи от устройства к устройству. ZigBee® IP направлен на облегчение связи посредством ретрансляции данных устройства к центральному маршрутизатору или устройству. Таким образом, центральный маршрутизатор или устройство может требовать постоянного питания и поэтому не может представлять собой маломощное средство связи между устройствами. Кроме того, IP-ZigBee® IP может иметь практическое ограничение на число узлов (т.е., ~20 узлов на каждую сеть), которые могут быть использованы в одной сети. Кроме того, IP-ZigBee® IP использует протокол маршрутизации “Ripple” (RPL), который может проявлять высокие требования к ширине полосы, обработке и памяти, что может быть связано с дополнительной мощностью для каждого подключенного устройства ZigBee® IP.

[0011] Подобно стандартам беспроводной сети ZigBee®, обсужденным выше, беспроводная сеть WiFi может проявлять один или более недостатков с точки зрения обеспечения возможности связи между устройствами, имеющими требования малой мощности. Например, стандарт беспроводной сети WiFi может также требовать, чтобы каждое сетевое устройство всегда было включено, и, кроме того, может требовать наличия центрального узла или концентратора. Как известно в данной области, WiFi является относительно распространенным стандартом беспроводной сети, который может быть идеальным для передачи данных относительно высокой ширины полосы (например, потоковое видео, синхронизация устройств). Как таковые, WiFi устройства, как правило, связаны с непрерывным источником питания или перезаряжаемыми аккумуляторами для поддержки постоянного потока передач данных между устройствами. Кроме того, беспроводная сеть WiFi может не поддерживать беспроводные ячеистые сети.

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

[0012] Сущность определенных раскрытых здесь вариантов осуществления изложена ниже. Следует понимать, что эти аспекты представлены только для того, чтобы предоставить читателю краткое изложение этих вариантов осуществления, и что эти аспекты не предназначены для ограничения объема настоящего раскрытия. Действительно, настоящее раскрытие может охватывать самые различные аспекты, которые могут не быть изложены ниже.

[0013] Предложены системы и способы для эффективной связи в инфраструктурной сети устройств в домашней среде или аналогичной среде. Например, электронное устройство может эффективно управлять связью, чтобы сбалансировать факторы мощности и надежности, может эффективно передавать сообщения к некоторым предпочтительным сетям на основе анализа заголовков пакетов Интернет-протокола версии 6 (IPv6), которые используют расширенный уникальный локальный адрес (EULA), может эффективно передавать обновления программного обеспечения и отчеты о состоянии во всей инфраструктурной сети и/или может просто и эффективно подключаться к инфраструктурной сети.

[0014] Например, электронное устройство может включать в себя память или хранилище, хранящее инструкции для работы сетевого стека, процессор для исполнения инструкций и сетевой интерфейс для присоединения к подключенной к сети инфраструктуре устройств и передавать сообщение к целевому устройству инфраструктуры устройств с использованием сетевого стека. Сетевой стек может включать в себя уровень приложения, чтобы обеспечивать полезную нагрузку приложения с данными, которые должны передаваться в сообщении, уровень платформы, чтобы инкапсулировать полезную нагрузку приложения в общем формате сообщения для сообщения, транспортный уровень, чтобы избирательно транспортировать сообщение с использованием либо протокола пользовательских дейтаграмм (UDP), либо протокола управления передачей (TCP), и сетевой уровень, чтобы передавать сообщение с использованием Интернет-протокола версии 6 (IPv6) через одну или более сетей. Эти сети могут включать в себя, например, беспроводную сеть 802.11, беспроводную сеть 802.15.4, сеть на линиях питания, сеть сотовой связи и/или сеть Ethernet. Кроме того, уровень приложения, уровень платформы, транспортный уровень и/или сетевой уровень могут определять свойство способа передачи сообщения к целевому узлу, основываясь, по меньшей мере частично, на типе сообщения, сети, по которой сообщение должно быть отправлено, расстоянии, которое сообщение может проходить через инфраструктуру, режиме потребления мощности электронного устройства, режиме потребления мощности целевого устройства и/или режиме потребления мощности промежуточного устройства инфраструктуры устройств, которое должно передавать сообщение между данным электронным устройством и целевым устройством. Кроме того, изменение свойства способа передачи может вызвать то, что электронное устройство, целевое устройство и/или промежуточное устройство будут потреблять различные величины мощности, и вызвать то, что сообщение будет достигать целевого узла более надежно или менее надежно.

[0015] В другом примере, вещественный долговременный (нетранзиторный) считываемый компьютером носитель может включать в себя инструкции, подлежащие исполнению первым электронным устройством, коммуникативно связанным с другими электронными устройствами инфраструктуре устройств в домашней среде. Инструкции могут включать в себя инструкции, чтобы принимать сообщение Интернет-протокола версии 6 (IPv6) в первом электронном устройстве от второго электронного устройства по первой сети инфраструктуры устройств. Сообщение может предназначаться для целевого электронного устройства. Инструкции могут дополнительно включать в себя инструкции для идентификации Расширенного Уникального Локального Адреса, закодированного в заголовке IPv6 сообщения. Здесь Расширенный Уникальный Локальный Адрес может указывать, что вторая сеть является предпочтительной для достижения целевого электронного устройства. Инструкции также могут включать в себя инструкции, чтобы передавать сообщение через инфраструктуру устройств к целевому электронному устройству с использованием второй сети, основываясь, по меньшей мере частично, на Расширенном Уникальном Локальном Адресе.

[0016] Способ передачи обновления программного обеспечения по инфраструктурной сети могут включать передачу сообщения запроса образа из первого устройства в инфраструктурной сети ко второму устройству в инфраструктурной сети или локальному или удаленному серверу. Сообщение запроса образа может включать в себя информацию о программном обеспечении, сохраненном на первом устройстве, и возможностях пересылки первого устройства. Ответ на запрос образа может быть получен первым устройством от второго устройства или локального или удаленного сервера. Ответ на запрос образа может указывать, доступно ли обновление программного обеспечения и включает ли в себя информацию загрузки, имеющую универсальный идентификатор ресурса (URI), чтобы позволить первому устройству загрузить обновление программного обеспечения. Сообщение запроса образа может включать в себя информацию отправителя относительно программного обеспечения, сохраненного на устройстве-отправителе, и возможностях пересылки устройства-отправителя и приоритета обновления. С использованием URI, обновление программного обеспечения может быть загружено в первом устройстве от устройства-отправителя. Программное обеспечение может быть загружено единовременно, основываясь, по меньшей мере частично, на приоритете обновления и сетевом трафике в инфраструктурной сети, и может быть загружено таким образом, основываясь, по меньшей мере частично, на обычных возможностях пересылки, указанных в запросе образа и ответе на запрос образа.

[0017] В другом примере, вещественный долговременный считываемый компьютером носитель может хранить формат отчетности о состоянии. Формат отчетности о состоянии может включать в себя поле профиля для указания типа обновления состояния из множества типов обновлений состояния, код состояния для указания состояния, о котором предоставляется отчет - код состояния может интерпретироваться, основываясь, по меньшей мере частично, на типе обновления состояния - и поле следующего состояния для указания, включено ли дополнительное состояние в отчет о состоянии, формируемый с использованием формата отчетности о состоянии.

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

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

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

[0020] Различные аспекты этого раскрытия можно лучше понять из нижеследующего подробного описания и со ссылками на чертежи, на которых:

[0021] Фиг. 1 иллюстрирует блок-схему обобщенного устройства, которое может осуществлять связь с другими устройствами, расположенными в домашней среде, с использованием эффективного протокола сетевого уровня, в соответствии с вариантом осуществления;

[0022] Фиг. 2 иллюстрирует блок-схему домашней среды, в которой обобщенное устройство по фиг. 1 может осуществлять связь с другими устройствами посредством протокола эффективного сетевого уровня в соответствии с вариантом осуществления;

[0023] Фиг. 3 иллюстрирует примерную беспроводную ячеистую сеть, ассоциированную с устройствами, изображенными в домашней среде по фиг. 2, в соответствии с вариантом осуществления;

[0024] Фиг. 4 иллюстрирует блок-схему модели взаимодействия открытых систем (OSI), которая характеризует систему связи для домашней среды по фиг. 2, в соответствии с вариантом осуществления;

[0025] Фиг. 5 иллюстрирует подробный вид эффективного сетевого уровня в модели OSI по фиг. 4 в соответствии с вариантом осуществления;

[0026] Фиг. 6 иллюстрирует блок-схему способа для реализации сети Протокола Информации Маршрутизации - Следующего Поколения (RIPng) в качестве механизма маршрутизации в эффективном сетевом уровне по фиг. 5 в соответствии с вариантом осуществления;

[0027] Фиг. 7A-7D иллюстрируют пример того, каким образом может быть реализована сеть RIPng в способе по фиг. 6 в соответствии с вариантом осуществления;

[0028] Фиг. 8 иллюстрирует блок-схему процесса производства, который включает в себя встраивание сертификата безопасности в обобщенное устройство по фиг. 1, с соответствии в вариантом осуществления;

[0029] Фиг. 9 иллюстрирует пример протокола квитирования между устройствами в домашней среде на фиг. 2 с использованием протокола Безопасности Транспортного Уровня Дейтаграмм (DTLS) в эффективном сетевом уровне по фиг. 5, в соответствии с вариантом осуществления.

[0030] Фиг. 10 иллюстрирует инфраструктурную сеть, имеющую топологию одиночной логической сети, в соответствии с вариантом осуществления;

[0031] Фиг. 11 иллюстрирует инфраструктурную сеть, имеющую топологию звездообразной сети, в соответствии с вариантом осуществления;

[0032] Фиг. 12 иллюстрирует инфраструктурную сеть, имеющую топологию перекрывающихся сетей, в соответствии с вариантом осуществления;

[0033] Фиг. 13 иллюстрирует службу, осуществляющую связь с одной или более инфраструктурных сетей, в соответствии с вариантом осуществления;

[0034] Фиг. 14 иллюстрирует два устройства в инфраструктурной сети в коммуникативном соединении, в соответствии с вариантом осуществления;

[0035] Фиг. 15 иллюстрирует формат уникального локального адреса (ULA), который может быть использован для адресации устройств в инфраструктурной сети, в соответствии с вариантом осуществления;

[0036] Фиг. 16 иллюстрирует процесс представления периферийных устройств в сети-концентраторе, в соответствии с вариантом осуществления;

[0037] Фиг. 17 иллюстрирует пакет тег-длина-значение (TLV), который может быть использован для передачи данных по инфраструктурной сети, в соответствии с вариантом осуществления;

[0038] Фиг. 18 иллюстрирует общий протокол сообщения (GMP), который может использоваться для передачи данных по инфраструктурной сети, которые могут включать в себя пакет TLV по фиг. 17, в соответствии с вариантом осуществления;

[0039] Фиг. 19 иллюстрирует поле заголовка сообщения GMP по фиг. 18 в соответствии с вариантом осуществления;

[0040] Фиг. 20 иллюстрирует поле идентификатора ключа GMP по фиг. 18 в соответствии с вариантом осуществления;

[0041] Фиг. 21 иллюстрирует поле полезной нагрузки приложения GMP по фиг. 18 в соответствии с вариантом осуществления;

[0042] Фиг. 22 иллюстрирует схему отчетности о состоянии, которая может использоваться для обновления информации о состоянии в инфраструктурной сети, в соответствии с вариантом осуществления;

[0043] Фиг. 23 иллюстрирует поле профиля схемы отчетности о состоянии по фиг. 22 в соответствии с вариантом осуществления;

[0044] Фиг. 24 иллюстрирует протокольную последовательность, которая может быть использована для выполнения обновления программного обеспечения между клиентом и сервером, в соответствии с вариантом осуществления;

[0045] Фиг. 25 иллюстрирует кадр запроса образа, который может использоваться в протокольной последовательности по фиг. 24, в соответствии с вариантом осуществления;

[0046] Фиг. 26 иллюстрирует поле управления кадра в кадре запроса образа по фиг. 25 в соответствии с вариантом осуществления;

[0047] Фиг. 27 иллюстрирует поле спецификации продукта в кадре запроса образа по фиг. 25 в соответствии с вариантом осуществления;

[0048] Фиг. 28 иллюстрирует поле спецификации версии в кадре запроса образа по фиг. 25 в соответствии с вариантом осуществления;

[0049] Фиг. 29 иллюстрирует поле локальной спецификации в кадре запроса образа по фиг. 25 в соответствии с вариантом осуществления;

[0050] Фиг. 30 иллюстрирует поле поддерживаемых типов целостности в кадре запроса образа по фиг. 25 в соответствии с вариантом осуществления;

[0051] Фиг. 31 иллюстрирует поле поддерживаемых схем обновления в кадре запроса образа по фиг. 25 в соответствии с вариантом осуществления;

[0052] Фиг. 32 иллюстрирует кадр ответа на запрос образа, который может быть использован в протокольной последовательности по фиг. 24, в соответствии с вариантом осуществления;

[0053] Фиг. 33 иллюстрирует поле унифицированного идентификатора ресурса (URI) в кадре ответа на запрос образа по фиг. 32 в соответствии с вариантом осуществления;

[0054] Фиг. 34 иллюстрирует поле спецификации целостности в кадре ответа на запрос образа по фиг. 32 в соответствии с вариантом осуществления;

[0055] Фиг. 35 иллюстрирует поле схемы обновления в кадре ответа на запрос образа по фиг. 32 в соответствии с вариантом осуществления;

[0056] Фиг. 36 иллюстрирует последовательность, используемую для применения протокола управления данными для управления данными между устройствами в инфраструктурной сети, в соответствии с вариантом осуществления;

[0057] Фиг. 37 иллюстрирует кадр запроса моментального снимка, который может быть использован в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0058] Фиг. 38 иллюстрирует схему примерного профиля, которая может быть доступной с использованием кадра запроса моментального снимка по фиг. 37, в соответствии с вариантом осуществления;

[0059] Фиг. 39 представляет собой бинарный формат пути, который может указывать на путь в схеме профиля, в соответствии с вариантом осуществления;

[0060] Фиг. 40 иллюстрирует кадр запроса наблюдения, который может быть использован в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0061] Фиг. 41 иллюстрирует кадр запроса периодического обновления, который может быть использован в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0062] Фиг. 42 иллюстрирует кадр запроса регенерации, который может быть использован в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0063] Фиг. 43 иллюстрирует запрос отмены просмотра, который может быть использован в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0064] Фиг. 44 иллюстрирует кадр ответа просмотра, который может быть использован в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0065] Фиг. 45 иллюстрирует кадр явного запроса обновления, который может использоваться в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0066] Фиг. 46 иллюстрирует кадр запроса обновления просмотра, который может использоваться в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0067] Фиг. 47 иллюстрирует кадр элемента обновления, который может быть обновлен с использованием последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0068] Фиг. 48 иллюстрирует кадр ответа обновления, который может быть отправлен как сообщение ответа обновления в последовательности по фиг. 36, в соответствии с вариантом осуществления;

[0069] Фиг. 49 иллюстрирует коммуникативное соединение между отправителем и получателем в пересылке массивов данных в соответствии с вариантом осуществления;

[0070] Фиг. 50 иллюстрирует сообщение SendInit, которое может быть использовано, чтобы инициировать коммуникативное соединение отправителем по фиг. 49, в соответствии с вариантом осуществления;

[0071] Фиг. 51 иллюстрирует поле управления передачей сообщения SendInit по фиг. 50, в соответствии с вариантом осуществления;

[0072] Фиг. 52 иллюстрирует поле управления диапазоном сообщения SendInit по фиг. 51, в соответствии с вариантом осуществления;

[0073] Фиг. 53 иллюстрирует сообщение SendAccept, которое может быть использовано для принятия соединения связи, предложенного сообщением SendInit по фиг. 50, отправленным отправителем по фиг. 50, в соответствии с вариантом осуществления;

[0074] Фиг. 54 иллюстрирует сообщение SendReject, которое может быть использовано для отклонения соединения связи, предложенного сообщением SendInit по фиг. 50, отправленного отправителем по фиг. 50, в соответствии с вариантом осуществления;

[0075] Фиг. 55 иллюстрирует сообщение ReceiveAccept, которое может быть использовано для принятия соединения связи, предложенного получателем по фиг. 50, в соответствии с вариантом осуществления.

[0076] Фиг. 56 является блок-схемой примера заголовка IPv6 пакета, использующего Расширенный Уникальный Локальный Адрес (EULA), в соответствии с вариантом осуществления;

[0077] Фиг. 57 является схематичным представлением передачи IPv6 пакета, имеющего IPv6 пакет по фиг. 56, через топологию инфраструктуры, имеющую две сети, в соответствии с вариантом осуществления;

[0078] Фиг. 58 является блок-схемой последовательности операций способа для эффективной передачи IPv6 пакета через инфраструктуру по фиг. 57 с использованием заголовка IPv6 пакета по фиг. 56 в соответствии с вариантом осуществления;

[0079] Фиг. 59 является блок-схемой последовательности операций способа для выбора эффективного транспортного протокола, по которому посылать сообщение, основываясь, по меньшей мере частично, на одном или нескольких факторах надежности, в соответствии с вариантом осуществления;

[0080] Фиг. 60 представляет собой диаграмму, иллюстрирующую случай использования инфраструктуры устройств, в которой одно устройство вызывает способ другого устройства, в соответствии с вариантом осуществления;

[0081] Фиг. 61 представляет собой диаграмму, иллюстрирующую случай использования инфраструктуры устройств, в которой сообщение тревоги распространяется через ряд маломощных, находящихся в спящем режиме устройств, в соответствии с вариантом осуществления;

[0082] Фиг. 62-64 являются блок-схемами последовательности операций способа для введения нового устройства в инфраструктуру устройств, в соответствии с вариантом осуществления; и

[0083] Фиг. 65-67 являются блок-схемами другого способа для введения нового устройства в инфраструктуру устройств, в соответствии с вариантом осуществления.

ПОДРОБНОЕ ОПИСАНИЕ

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

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

[0086] Как используется здесь, термин “HVAC” включает в себя системы, обеспечивающие как отопление, так и охлаждение, только отопление, только охлаждение, а также системы, которые имеют другие функциональные возможности обеспечения комфорта и/или кондиционирования для обитателей, включая увлажнение, осушение и вентиляцию.

[0087] Как используется здесь, термины “сбор”, “совместное использование” и “захват”, когда речь идет о домашних устройствах, относятся к получению мощности от силового трансформатора через нагрузку оборудования без использования прямого или общего проводного источника непосредственно из трансформатора.

[0088] Как используется здесь, термин “термостат” означает устройство или систему для регулирования параметров, таких как температура и/или влажность, в пределах по меньшей мере части корпуса. Термин “термостат” может включать в себя блок управления для системы отопления и/или охлаждения или составную часть нагревателя или кондиционера. Как используется здесь, термин “термостат” может также относиться в целом к универсальному блоку восприятия и управления (блоку VSCU), который сконфигурирован и адаптирован для обеспечения сложного, настроенного, энергосберегающего функционального средства управления HVAC и в то же время является визуально привлекательным, неустрашающим, элегантным на вид и восхитительно легким в использовании.

[0089] Как используется здесь, термин “детектор опасности” относится к любому домашнему устройству, которое может обнаружить свидетельства пожара (например, дым, тепло, угарный газ) и/или другие опасные условия (например, экстремальные температуры, скапливание опасных газов).

[0090] Настоящее раскрытие относится к эффективной связи, которая может быть использована устройствами, осуществляющими связь друг с другом в домашней среде. Эффективная связь согласно настоящему раскрытию может позволить инфраструктуре устройств и/или служб, осуществлять связь в домашней среде. Действительно, для потребителей, проживающих в домах, может оказаться полезным координировать операции различных устройств в их доме, чтобы все их устройства работали эффективно. Например, устройство термостата может быть использовано, чтобы определять температуру в доме и координировать активность других устройств (например, осветительных приборов) на основе определенной температуры. Устройство термостата может определить температуру, которая может указывать на то, что температура вне дома соответствует часам дневного света. Затем устройство термостата может сообщить осветительному устройству, что в доме может быть достаточным дневной свет, и, таким образом, освещение должно быть выключено. В другом примере, интеллектуальный детектор опасности может быть способен обнаруживать условия окружающей среды, которые указывают на занятость помещения. Устройство термостата может запросить детектор опасности относительно этих условий окружающей среды и изменить свою работу соответствующим образом. В дополнение к эффективности, потребители обычно предпочитают использовать удобные для пользователя устройства, которые требуют минимального количества действий по настройке или инициализации. То есть потребители, как правило, предпочитают устройства, которые полностью работоспособны после выполнения нескольких этапов инициализации, особенно таких, которые могут выполняться практически любым человеком, независимо от возраста или технического опыта.

[0091] Чтобы обеспечить возможность эффективной передачи данных между устройствами в домашней среде, устройства могут использовать инфраструктурную сеть, которая включает в себя одну или более логических сетей, чтобы управлять связью между устройствами. То есть эффективная инфраструктурная сеть может позволить множеству устройств в пределах дома осуществлять связь друг с другом с использованием одной или более логических сетей. Инфраструктурная сеть может поддерживаться эффективной схемой связи, использующей, например, эффективный сетевой уровень, эффективный уровень платформы и/или эффективный уровень приложения, чтобы управлять связью. Инфраструктурная сеть может поддерживать связь согласно Интернет-протоколу версии 6 (IPv6), так что каждое подключенное устройство может иметь уникальный локальный адрес (ULA). В некоторых примерах, IPv6 передачи могут использовать Расширенный Уникальный Локальный Адрес (EULA). Кроме того, чтобы позволить интеграцию каждого устройства в доме, может быть полезным для каждого устройства осуществлять связь в сети с использованием малых уровней мощности. То есть при обеспечении возможности устройствам осуществлять связь с использованием малой мощности, устройства могут быть размещены в любом месте в доме, не будучи связанными с непрерывным источником питания (например, с питанием от батареи).

[0092] На относительно низком уровне протокола связи (например, сетевом уровне), инфраструктурный эффективной сетевой уровень может создать сеть связи, в которой множество устройств в пределах дома могут осуществлять связь друг с другом с помощью беспроводной ячеистой сети. Сеть связи может поддерживать связь согласно Интернет-протоколу версии 6 (IPv6), так что каждое подключенное устройство может иметь уникальный адрес Интернет-протокола (IP). Кроме того, чтобы позволить интеграцию каждого устройства в доме, может быть полезным для каждого устройства осуществлять связь в сети с использованием малых уровней мощности. То есть при обеспечении возможности устройствам осуществлять связь с использованием малой мощности, устройства могут быть размещены в любом месте в доме, не будучи связанными с непрерывным источником питания.

[0093] Эффективный сетевой уровень может, таким образом, установить процедуру, в котором данные могут передаваться между двумя или более устройствами, так что создание сети связи использует незначительный пользовательский ввод, связь между устройствами использует мало энергии, и сама сеть связи является безопасной. В одном варианте осуществления эффективный сетевой уровень может быть основанной на IPv6 сетью связи, которая использует Протокол Информации Маршрутизации - Следующего Поколения (RIPng) в качестве своего механизма маршрутизации и протокол Безопасности Транспортного Уровня Дейтаграмм (DTLS) в качестве своего механизма безопасности. Таким образом, эффективный сетевой уровень может обеспечить простое средство для добавления или удаления устройств в доме при обеспечении защиты информации, передаваемой между подключенными устройствами.

[0094] На относительно высоких уровнях протокола связи (например, уровнях платформы и/или приложения) может создаваться и поддерживаться инфраструктура устройств. Эти уровни могут позволять параметрические обновления программного обеспечения и отчеты о состоянии во всей инфраструктуре. Эти уровни могут также обеспечивать связь, которая может быть осведомлена о некоторых ограничениях по мощности сети, таких как ограничения по мощности “спящих” устройств или устройств с батарейным питанием, и могут передавать сообщения с учетом этих факторов.

[0095] Варианты осуществления настоящего раскрытия относятся к системам и способам инфраструктурной сети, которая включает в себя одну или более логических сетей, которая позволяет устройствам, соединенным с инфраструктурой, осуществлять связь друг с другом с использованием списка протоколов и/или профилей, известных устройствам. Связь между устройствами может следовать согласно типовому формату сообщения, который позволяет устройствам понимать передачи между устройствами независимо от того, с какими логическими сетями соединены осуществляющие связь устройства в инфраструктуре. В формате сообщения, полезная нагрузка данных может быть включена для сохранения и/или обработки принимающим устройством. Формат и содержание полезной нагрузки может варьироваться в соответствии с заголовком в полезной нагрузке, который указывает профиль (включая один или более протоколов) и/или тип сообщения, отправляемого в соответствии с профилем.

[0096] В соответствии с некоторыми вариантами осуществления, два или более устройств в инфраструктуре могут осуществлять связь с использованием протоколов или профилей отчетности о состоянии. Например, в некоторых вариантах осуществления, протокол или схема отчетности о состоянии могут быть включены в базовый профиль, который доступен для устройств, соединенных с инфраструктурой. Используя протокол отчетности о состоянии, устройства могут передавать или запрашивать информацию о состоянии к или от других устройств в инфраструктуре.

[0097] Кроме того, в некоторых вариантах осуществления, два или более устройств в инфраструктуре могут осуществлять связь с использованием протоколов или профилей обновления программного обеспечения. В некоторых вариантах осуществления, протокол или схема обновления программного обеспечения могут быть включены в базовый профиль, который доступен для устройств, соединенных с инфраструктурой. Используя протокол обновления программного обеспечения, устройство может запрашивать, передавать или уведомлять о наличии обновлений в пределах инфраструктуры.

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

[0099] Кроме того, в некоторых вариантах осуществления, два или более устройств в инфраструктуре могут передавать данные с использованием протоколов или профилей передачи больших массивов данных (групповой пересылки данных). В некоторых вариантах осуществления протокол или схема передачи больших массивов данных могут быть включены в базовый профиль, который доступен для устройств, соединенных с инфраструктурой. Используя протокол передачи больших массивов данных, устройства могут инициировать, передавать или принимать большие массивы данных, используя любые логические сети в инфраструктуре. В некоторых вариантах осуществления, либо передающее, либо приемное устройство, использующее протокол передачи больших массивов данных, может быть в состоянии “приводить в действие” синхронную передачу между устройствами. В других вариантах осуществления передача больших массивов данных может быть выполнена посредством асинхронной передачи.

Введение в инфраструктуру

[00100] В качестве введения, фиг. 1 иллюстрирует пример обобщенного устройства 10, которое может осуществлять связь с другими подобными устройствами в домашней среде. В одном варианте осуществления устройство 10 может включать в себя один или несколько датчиков 12, компонент 14 пользовательского интерфейса, источник 16 питания (например, включая соединение питания и/или батарею), сетевой интерфейс 18, процессор 20 и т.п. Конкретные датчики 12, компоненты 14 пользовательского интерфейса и конфигурации источника питания могут быть одинаковыми или аналогичными в каждом из устройств 10. Тем не менее, следует отметить, что в некоторых вариантах осуществления, каждое устройство 10 может включать в себя конкретные датчики 12, компоненты 14 пользовательского интерфейса, конфигурации источника питания и т.п., в зависимости от типа устройства или модели.

[00101] Датчики 12, в некоторых вариантах осуществления, могут обнаруживать различные свойства, такие как ускорение, температура, влажность, вода, поставляемая мощность, близость, внешнее движение, движение устройства, звуковые сигналы, ультразвуковые сигналы, световые сигналы, огонь, дым, угарный газ, спутниковые сигналы системы глобального позиционирования (GPS), радиочастотные (RF) сигналы, другие электромагнитные сигналы или поля и т.п. Таким образом, датчики 12 могут включать в себя температурный(е) датчик(и), датчик(и) влажности, связанный(е) с опасностью датчик(и) или другие датчики окружающей среды, акселерометр(ы), микрофон(ы), оптические датчики вплоть до и включая камеру(ы) (например, на приборах с зарядовой связью или видеокамеры), активные или пассивные датчики излучения, GPS приемник(и) или детектор(ы) радиочастотной идентификации. В то время как фиг. 1 иллюстрирует вариант осуществления с одним датчиком, многие варианты осуществления могут включать в себя множество датчиков. В некоторых случаях устройство 10 может включать в себя один или более первичных датчиков и один или более вторичных датчиков. Здесь, первичный(е) датчик(и) может (могут) воспринимать данные, являющиеся центральными для базовой операции устройства (например, восприятие температуры в термостате или восприятие дыма в детекторе дыма), а вторичный(е) датчик(и) может (могут) воспринимать другие типы данных (например, движение, свет или звук), которые могут использоваться для целей энергоэффективности или целей интеллектуальной операции.

[00102] Один или более компонентов 14 пользовательского интерфейса в устройстве 10 может принимать ввод от пользователя и/или представлять информацию пользователю. Принятый ввод может быть использован для определения настройки. В некоторых вариантах осуществления компоненты пользовательского интерфейса могут включать в себя механический или виртуальный компонент, который реагирует на движение пользователя. Например, пользователь может механически переместить скользящий компонент (ползунок) (например, вдоль вертикальной или горизонтальной направляющей) или вращать поворотное кольцо (например, по круговой направляющей), или может обнаруживаться движение пользователя вдоль сенсорной панели. Такие движения могут соответствовать корректировке настройки, что может определяться на основе абсолютного положения компонента 104 пользовательского интерфейса или на основе смещения компонентов 104 пользовательского интерфейса (например, корректировки температуры заданного значения на 1 градус F для каждого поворота на 10° компонента поворотного кольца). Физически и виртуально подвижные компоненты пользовательского интерфейса могут позволить пользователю установить настройку вдоль части видимого континуума. Таким образом, пользователь не ограничивается выбором между двумя дискретными опциями (например, как это было бы в случае, если бы использовались кнопки “вверх” и “вниз”), но может быстро и интуитивно определить настройку в диапазоне возможных значений настроек. Например, величина перемещения компонента пользовательского интерфейса может быть ассоциирована с величиной корректировки настройки, так что пользователь может резко изменить настройку большим движением или точно установить настройку малым движением.

[00103] Компоненты 14 пользовательского интерфейса также могут включать в себя одну или несколько кнопок (например, кнопки “вверх” и “вниз”), клавиатуру, цифровую панель, переключатель, микрофон и/или камеру (например, для обнаружения жестов). В одном варианте осуществления компонент 14 пользовательского интерфейса может включать в себя компонент кругового кольца с функцией “нажать и повернуть”, который может позволить пользователю взаимодействовать с компонентом, вращая кольцо (например, для корректировки настройки) и/или нажимая кольцо в направлении внутрь (например, чтобы выбрать скорректированную настройку или выбрать опцию). В другом варианте осуществления компонент 14 пользовательского интерфейса может включать в себя камеру, которая может обнаруживать жесты (например, чтобы указать, что питание или состояние тревожной сигнализации устройства должно быть изменено). В некоторых случаях устройство 10 может иметь один первичный компонент ввода, который может быть использован для установки множества типов настроек. Компоненты 14 пользовательского интерфейса также могут быть сконфигурированы, чтобы предоставлять информацию пользователю через, например, визуальное отображение (например, дисплей на тонкопленочных транзисторах или дисплей на органических светоизлучающих диодах) и/или аудио динамик.

[00104] Компонент 16 источника питания может включать в себя соединение питания и/или локальную батарею. Например, соединение питания может соединять устройство 10 с источником питания, таким как источник напряжения линии. В некоторых случаях, источник питания переменного тока (АС) может быть использован для подзарядки (например, подзаряжаемой) локальной аккумуляторной батареи, так что батарея может в дальнейшем использоваться для подачи питания на устройство 10, когда источник питания АС не доступен.

[00105] Сетевой интерфейс 18 может включать в себя компонент, который позволяет устройству 10 осуществлять связь между устройствами. В одном варианте осуществления сетевой интерфейс 18 может осуществлять связь с использованием эффективного сетевого уровня как части его модели взаимодействия открытых систем (OSI). В одном варианте осуществления эффективный сетевой уровень, который будет описан более детально ниже со ссылкой на фиг. 5, может позволить устройству 10 осуществлять беспроводную передачу данных или трафика IPv6-типа, используя механизм маршрутизации RIPng и схему безопасности DTLS. Таким образом, сетевой интерфейс 18 может включать в себя беспроводную карту или некоторое другое соединение приемопередатчика.

[00106] Процессор 20 может поддерживать одну или более из множества различных функциональностей устройства. Как таковой, процессор 20 может включать в себя один или более процессоров, сконфигурированных и запрограммированных для выполнения и/или инициирования выполнения одной или более функциональностей, описанных здесь. В одном варианте осуществления процессор 20 может включать в себя процессоры общего назначения, выполняющие компьютерный код, хранящийся в локальной памяти (например, флэш-памяти, на жестком диске, в оперативной памяти), процессоры специального назначения или специализированные интегральные схемы, их комбинации и/или использовать другие типы платформ обработки на аппаратных средствах/прошивке/программном обеспечении. Кроме того, процессор 20 может быть реализован как локализованные версии или дубликаты алгоритмов, выполняемых или регулируемых дистанционно центральными серверами или облачными системами, такими как на основании исполнения виртуальной машины Java (JVM), которая исполняет инструкции, предоставляемые от облачного сервера с использованием Асинхронного JavaScript и XML (AJAX) или аналогичных протоколов. В качестве примера, процессор 20 может обнаружить, когда некоторое местоположение (например, дом или комната) занято, вплоть до и включая то, занято ли оно конкретным лицом или занято определенным количеством людей (например, по отношению к одному или более пороговым значениям). В одном варианте осуществления это обнаружение может выполняться, например, путем анализа микрофонных сигналов, обнаружения движений пользователя (например, перед устройством), обнаружения открываний и закрытий дверей или гаражных дверей, обнаружения беспроводных сигналов, обнаружения IP-адреса принятого сигнала, обнаружения функционирования одного или более устройств в некотором временном окне и т.п. Кроме того, процессор 20 может включать в себя технологии распознавания образов, чтобы идентифицировать конкретные лица или объекты.

[00107] В некоторых вариантах осуществления процессор 20 может также включать в себя процессор высокой мощности и процессор малой мощности. Процессор высокой мощности может исполнять вычислительные операции высокой интенсивности, такие как управление компонентами 14 пользовательского интерфейса и т.п. Процессор малой мощности, с другой стороны, может управлять менее сложными процессами, такими как обнаружение опасности или температуры от датчика 12. В одном варианте осуществления процессор малой мощности может активировать или инициализировать процессор высокой мощности для вычислительных процессов высокой интенсивности.

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

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

[00110] В качестве примера, устройство 10 может включать в себя термостат, такой как Nest® обучающийся термостат. Здесь термостат может включать в себя датчики 12, например, датчики температуры, датчики влажности и т.п., так что термостат может определить существующие климатические условия в здании, где расположен термостат. Компонент 16 источника питания для термостата может быть локальной батареей, так что термостат может быть размещен в любом месте в здании без учета размещения в непосредственной близости от непрерывного источника питания. Поскольку термостат может питаться с помощью локальной батареи, термостат может минимизировать свое использование энергии, так что батарея редко заменяется.

[00111] В одном варианте осуществления термостат может включать круговую направляющую, которая может иметь поворотное кольцо, расположенное на ней, в качестве компонента 14 пользовательского интерфейса. Таким образом, пользователь может взаимодействовать с термостатом или программировать его с помощью поворотного кольца таким образом, что термостат контролирует температуру здания с помощью блока управления отоплением, вентиляцией и кондиционированием воздуха (HVAC) или тому подобного. В некоторых случаях термостат может определять, когда здание может быть свободным, на основе его программирования. Например, если термостат запрограммирован, чтобы поддерживать блок HVAC с выключенным питанием в течение длительного периода времени, термостат может определить, что здание будет свободно в течение этого периода времени. Здесь термостат может быть запрограммирован, чтобы выключать переключатели освещения приборов или другие электронные устройства, когда он определяет, что здание пустует. Таким образом, термостат может использовать сетевой интерфейс 18 для осуществления связи с устройством переключения освещения таким образом, что он может посылать сигнал на устройство переключения освещения, когда определено, что здание пустует. Таким образом, термостат может эффективно управлять использованием энергии здания.

[00112] С учетом вышеизложенного, фиг. 2 иллюстрирует блок-схему домашней среды 30, в которой устройство 10 по фиг. 1 может осуществлять связь с другими устройствами через эффективный сетевой уровень. Изображенная домашняя среда 30 может включать в себя структуру 32, например, дом, офисное здание, гараж или мобильный дом. Следует иметь в виду, что устройства также могут быть интегрированы в домашнюю среду, которая не включает в себя всю структуру 32, например, квартиру, кондоминиум, офисное помещение или тому подобное. Кроме того, домашняя среда 30 может управлять и/или может быть связана с устройствами за пределами фактической структуры 32. В самом деле, различные устройства в домашней среде 30 не обязательно должны физически находиться в структуре 32. Например, устройство, управляющее нагревателем 34 бассейна, или система 36 орошения могут быть расположены за пределами структуры 32.

[00113] Изображенная структура 32 включает в себя ряд помещений 38, отделенных по меньшей мере частично друг от друга с помощью стен 40. Стены 40 могут включать в себя внутренние стены или наружные стены. Каждое помещение 38 может также включать в себя пол 42 и потолок 44. Устройства могут монтироваться на стенах 40, на полу 42 или потолке 44, встраиваться в них и/или поддерживаться ими.

[00114] Домашняя среда 30 может включать в себя множество устройств, в том числе интеллектуальные, мульти-сенсорные, соединенные с сетью устройства, которые могут плавно интегрироваться друг с другом и/или с облачными серверными системами, чтобы обеспечивать любую из множества полезных целей домашней среды. Одно, несколько или каждое из устройств, показанных в домашней среде 30, может включать в себя один или несколько датчиков 12, пользовательский интерфейс 14, источник 16 питания, сетевой интерфейс 18, процессор 20 и т.п.

[00115] Примерные устройства 10 могут включать в себя подключенный к сети термостат 46, например, Nest® обучающийся термостат 1-го поколения Т100577 или Nest® обучающийся термостат 2-го поколения T200577 от Nest Labs, Inc. Термостат 46 может обнаруживать климатические характеристики окружающей среды (например, температуру и/или влажность) и управлять системой 48 отопления, вентиляции и кондиционирования воздуха (HVAC). Другое примерное устройство 10 может включать в себя блок 50 обнаружения опасности, такой как блок обнаружения опасности согласно Nest®. Блок 50 обнаружения опасности может обнаруживать присутствие опасного вещества и/или опасной ситуации в домашней среде 30 (например, дыма, огня или угарного газа). Кроме того, интерфейсные устройства 52 передней (входа), которые могут определяться понятием “интеллектуальный дверной звонок”, могут обнаруживать приближение или удаление человека от данного места, управлять звуковой функцией, оповещать о приближении или удалении человека с помощью аудио или визуальных средств или управлять настройками на системе безопасности (например, чтобы активировать или деактивировать систему безопасности).

[00116] В некоторых вариантах осуществления устройство 10 может включать в себя переключатель 54 освещения, который может обнаруживать условия внешнего освещения, обнаруживать состояния занятости помещений и управлять мощностью и/или состоянием ослабления света одного или более осветительных приборов. В некоторых случаях переключатели 54 освещения могут управлять состоянием мощности или скоростью вентилятора, такого как потолочный вентилятор.

[00117] Кроме того, интерфейсы 56 штепсельных вилок для стенных розеток могут обнаруживать занятость помещения или огороженного пространства и управлять подачей питания на одну или более штепсельных вилок для стенных розеток (например, так, что питание не подается на вилку, если никого нет дома). Устройство 10 в домашней среде 30 может дополнительно включать в себя бытовые устройства 58, такие как холодильники, кухонные плиты и/или печи, телевизоры, стиральные машины, сушилки, осветительные приборы (внутри и/или снаружи структуры 32), стереосистемы, системы внутренней связи, устройства отпирания гаражных дверей, напольные вентиляторы, потолочные вентиляторы, вентиляторы целого дома, настенные кондиционеры, нагреватели 34 бассейнов, системы 36 орошения, системы безопасности и т.д. В то время как описание фиг. 2 может идентифицировать конкретные датчики и функциональности, связанные с конкретными устройствами, следует понимать, что любые из множества датчиков и функциональностей (таких как те, которые описываются во всей спецификации) могут быть интегрированы в устройство 10.

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

[00119] В одном варианте осуществления беспроводной маршрутизатор 60 может дополнительно осуществлять связь с устройствами 10 в домашней среде 30 через беспроводную ячеистую сеть. Беспроводной маршрутизатор 60 может тогда осуществлять связь с сетью Интернет 62 таким образом, что каждое устройство 10 может осуществлять связь с центральным сервером или облачной вычислительной системой 64 через Интернет 62. Центральный сервер или облачная вычислительная система 64 могут быть ассоциированы с производителем, объектом поддержки или поставщиком услуг, ассоциированным с конкретным устройством 10. Таким образом, в одном варианте осуществления, пользователь может связываться с клиентской службой поддержки с использованием самого устройства, а не с использованием некоторого другого средства связи, такого как телефон или соединенный с Интернетом компьютер. Кроме того, обновления программного обеспечения могут автоматически отправляться с центрального сервера или облачной вычислительной системы 64 на устройства (например, при их доступности, при покупке или с регулярными интервалами).

[00120] Ввиду подключения к сети, одно или более устройств 10 могут дополнительно позволять пользователю взаимодействовать с устройством, даже если пользователь не находится в непосредственной близости к устройству. Например, пользователь может осуществлять связь с устройством с использованием компьютера (например, настольного компьютера, ноутбука или планшета) или другого портативного электронного устройства (например, смартфона) 66. Веб-страница или приложение может принимать сообщения от пользователя и управлять устройством 10 на основе принятых сообщений. Кроме того, веб-страница или приложение может предоставлять информацию о работе устройства пользователю. Например, пользователь может просматривать текущую заданную температуру для устройства и корректировать ее с помощью компьютера, который может быть подключен к Интернету 62. В этом примере термостат 46 может принимать запрос просмотра текущей заданной температуры через беспроводную ячеистую сеть, созданную с использованием эффективного сетевого уровня.

[00121] В некоторых вариантах осуществления домашняя среда 30 может также включать в себя различные, не осуществляющие связь унаследованные бытовые устройства 68, такие как устаревшие традиционные стиральные машины/сушилки, холодильники и т.п., которыми можно управлять, хотя и грубо (включение/выключение), на основе интерфейсов 56 штепсельных вилок стенных розеток. Домашняя среда 30 дополнительно может включать в себя множество частично осуществляющих связь унаследованных бытовых устройств 70, таких как управляемые с помощью инфракрасного (IR) излучения настенные кондиционеры или другие IR-управляемые устройства, которыми можно управлять с помощью IR-сигналов, предоставляемых блоками 50 обнаружения опасности или переключателями 54 освещения.

[00122] Как упоминалось выше, каждое из примерных устройств 10, описанных выше, может устанавливать беспроводную ячеистую сеть, так что данные могут передаваться к каждому устройству 10. Принимая во внимание примерные устройства по фиг. 2, фиг. 3 иллюстрирует примерную беспроводную ячеистую сеть 80, которая может быть использована для облегчения связи между некоторыми из примерных устройств, описанных выше. Как показано на фиг. 3, термостат 46 может иметь непосредственное беспроводное соединение с интерфейсом 56 штепсельной вилки, которое может быть соединено беспроводным способом с блоком 50 обнаружения опасности и с переключателем 54 освещения. Таким же образом, переключатель 54 освещения может быть беспроводным способом связан с бытовым устройством 58 и портативным электронным устройством 66. Бытовое устройство 58 может быть просто соединено с нагревателем 34 бассейна, и портативное электронное устройство 66 может быть просто связано с системой 36 орошения. Система 36 орошения может иметь беспроводное соединение с интерфейсным устройством 52 в передней. Каждое устройство в беспроводной ячеистой сети 80 на фиг. 3 может соответствовать узлу в пределах беспроводной ячеистой сети 80. В одном варианте осуществления эффективный сетевой уровень может определять, что каждый узел передает данные с использованием протокола RIPng и протокола DTLS, так что данные могут быть безопасно переданы к узлу-получателю при минимальном количестве транзитных участков между узлами.

[00123] Как правило, эффективный сетевой уровень может быть частью модели 90 взаимодействия открытых систем (OSI), как показано на фиг. 4. Модель OSI 90 иллюстрирует функции системы связи по отношению к уровням абстракции. То есть модель OSI может задавать сетевую архитектуру или то, как могут быть реализованы коммуникации между устройствами. В одном варианте осуществления, модель OSI может включать в себя шесть уровней: физический уровень 92, уровень 94 канала данных, сетевой уровень 96, транспортный уровень 98, уровень 100 платформы и уровень 102 приложения. Как правило, каждый уровень в модели OSI 90 может обслуживать уровень над ним и может обслуживаться уровнем под ним. По меньшей мере в некоторых вариантах осуществления, более высокий уровень может быть безразличным по отношению к технологиям, используемым на более низких уровнях. Например, в некоторых вариантах осуществления уровень 100 платформы может быть безразличным к типу сети, используемому на сетевом уровне.

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

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

[00126] Сетевой уровень 96 может определять, каким образом маршрутизируются данные, передаваемые в узел-получатель. Сетевой уровень 96 может также обеспечивать протокол безопасности, который может поддерживать целостность передаваемых данных.

[00127] Транспортный уровень 98 может определять прозрачную пересылку данных от узла-источника к узлу-получателю. Транспортный уровень 98 может также управлять тем, как прозрачная пересылка данных остается надежной. Таким образом, транспортный уровень 98 может быть использован для проверки того, что пакеты данных, предназначенные для пересылки на узел-получатель, действительно достигли узла-получателя. Примерные протоколы, которые могут быть использованы на транспортном уровне 98, могут включать в себя Протокол Управления Передачей (TCP) и Протокол Пользовательских Дейтаграмм (UDP).

[00128] Уровень 100 платформы может устанавливать соединения между устройствами в соответствии с протоколом, заданным в транспортном уровне 98. Уровень 100 платформы может также преобразовывать пакеты данных в форму, которую может использовать уровень 102 приложения. Уровень 102 приложения может поддерживать приложение программного обеспечения, которое может непосредственно взаимодействовать с пользователем. Таким образом, уровень 102 приложения может реализовывать протоколы, определенные приложением программного обеспечения. Например, приложение программного обеспечения может обеспечивать сервисы, такие как передача файлов, электронная почта и т.п.

Эффективный сетевой уровень

[00129] Со ссылкой на фиг. 5, в одном варианте осуществления сетевой уровень 96 и транспортный уровень 98 могут быть сконфигурированы определенным образом, чтобы формировать эффективную маломощную беспроводную персональную сеть (ELoWPAN) 110. В одном варианте осуществления ELoWPAN 110 может быть основана на сети IEEE 802.15.4, которая может соответствовать низкоскоростным беспроводным персональным сетям (LR-WPAN). ELoWPAN 110 может задавать, что сетевой уровень 96 может маршрутизировать данные между устройствами 10 в домашней среде 30 с использованием протокола связи, основанного на Интернет-протоколе версии 6 (IPv6). Таким образом, каждое устройство 10 может включать в себя 128-битный IPv6-адрес, который может обеспечить каждое устройство 10 уникальным адресом, используемым, чтобы идентифицировать себя в Интернете, локальной сети во всей домашней среде 30 и т.п.

[00130] В одном варианте осуществления сетевой уровень 96 может задавать, что данные могут маршрутизироваться между устройствами с использованием Протокола Информации Маршрутизации - Следующего Поколения (RIPng). RIPng является протоколом маршрутизации, который маршрутизирует данные через беспроводную ячеистую сеть на основе числа транзитных участков между узлом-источником и узлом-получателем. То есть RIPng может определить маршрут к узлу-получателю от узла-источника, который использует наименьшее количество транзитных участков, при определении того, каким образом данные будут маршрутизироваться. В дополнение к поддержке передач данных по беспроводной ячеистой сети, RIPng способен поддерживать IPv6 сетевой трафик. Таким образом, каждое устройство 10 может использовать уникальный IPv6-адрес, чтобы идентифицировать себя, и уникальный IPv6-адрес, чтобы идентифицировать узел-получатель, при маршрутизации данных. Дополнительные подробности в отношении того, каким образом RIPng может посылать данные между узлами, будут описаны ниже со ссылкой на фиг. 6.

[00131] Как упоминалось выше, сетевой уровень 96 может также обеспечивать протокол безопасности, который может управлять целостностью передаваемых данных. Здесь эффективный сетевой уровень может защищать данные, передаваемые между устройствами, с использованием протокола Безопасности Транспортного Уровня Дейтаграмм (DTLS). В общем, протокол Безопасности Транспортного Уровня (TLS) обычно используется, чтобы защищать пересылки данных через Интернет. Однако, для того, чтобы протокол TLS был эффективным, протокол TLS может транспортировать данные с использованием надежного транспортного канала, например, соответствующего Протоколу Управления Передачей (TCP). DTLS обеспечивает подобный уровень безопасности для пересылаемых данных при поддержке ненадежных транспортных каналов, таких как соответствующие Проколу Пользовательских Дейтаграмм (UDP). Дополнительные подробности в отношении протокола DTLS будут описаны ниже со ссылкой на фиг. 8 и 9.

[00132] Сетевой уровень 96, изображенный на фиг. 5, характеризуется здесь как эффективный сетевой уровень, упомянутый выше. То есть эффективный сетевой уровень маршрутизирует IPv6 данные с использованием RIPng и защищает маршрутизируемые данные с использованием протокола DTLS. Поскольку эффективный сетевой уровень использует протокол DTLS для защиты пересылки данных между устройствами, транспортный уровень 98 может поддерживать схемы передачи TCP и UDP для данных.

[00133] На фиг. 6 изображена блок-схема последовательности операций способа 120, который может использоваться для определения таблицы маршрутизации для каждого устройства 10 в ячеистой беспроводной сети 80 по фиг. 3 с использованием RIPng. Способ 120 может выполняться каждым устройством 10 в домашней среде 30 таким образом, что каждое устройство 10 может генерировать таблицу маршрутизации, которая указывает, как каждый узел в беспроводной ячеистой сети 80 может быть соединены друг с другом. Таким образом, каждое устройство 10 может независимо определять, как маршрутизировать данные к узлу-получателю. В одном варианте осуществления процессор 20 устройства 10 может выполнять способ 120 с использованием сетевого интерфейса 18. Таким образом, устройство 10 может посылать данные, ассоциированные с датчиком 12 или определенные процессором 18, к другим устройствам 10 в домашней среде 30 через сетевой интерфейс 18.

[00134] Нижеследующее обсуждение способа 120 будет описано со ссылкой на фиг. 7A-7D, чтобы четко проиллюстрировать различные блоки способа 120. Имея это в виду и ссылаясь на фиг. 6 и фиг. 7A, в блоке 122 устройство 10 может послать запрос 132 на любое другое устройство 10, которое может быть непосредственно (то есть с нулем транзитных участков) связано с запрашивающим устройством 10. Запрос 132 может включать в себя запрос на всю информацию маршрутизации из соответствующего устройства 10. Например, как показано на фиг. 7A, устройство 10 в узле 1 может посылать запрос 132 в устройство 10 в узле 2 на отправку всех маршрутов (т.е. маршрутов N2), включенных в память узла 2.

[00135] В блоке 124 запрашивающее устройство 10 может получить сообщение от соответствующего устройства 10, которое может включать в себя все маршруты, включенные в соответствующую память соответствующего устройства 10. Маршруты могут быть организованы в таблице маршрутизации, которая может задавать, как каждый узел в беспроводной ячеистой сети 80 может быть соединен с каждым другим узлом. То есть таблица маршрутизации может задавать, к каким промежуточным узлам могут быть переданы данные, чтобы данные от узла-источника были переданы к узлу-получателю. Возвращаясь к примеру, приведенному выше, и к фиг. 7В, в ответ на запрос узла 1 о маршрутах N2, в блоке 124 узел 2 может послать узлу 1 все маршруты (маршруты 144 N2), включенные в память или хранилище узла 2. В одном варианте осуществления каждый узел беспроводной ячеистой сети 80 может посылать запрос 132 к своему соседнему узлу, как показано на фиг. 7A. В ответ, каждый узел может затем послать свои маршруты к своему соседнему узлу, как показано на фиг. 7В. Например, фиг. 7В иллюстрирует, как каждый узел отправляет свои данные маршрутов к каждому соседнему узлу, как показано маршрутами 142 N1, маршрутами 144 N2, маршрутами 146 N3, маршрутами 148 N4, маршрутами 150 N5, маршрутами 152 N6, маршрутами 154 N7, маршрутами 156 N8 и маршрутами 158 N9.

[00136] Первоначально, каждый узел может знать узлы, с которыми он может иметь прямое соединение (например, нуль транзитных участков). Например, первоначально, узел 2 может только знать, что он напрямую соединен с узлом 1, узлом 3 и узлом 4. Однако после получения маршрутов 142 N1, маршрутов 146 N3 и маршрутов 148 N4, процессор 20 узла 2 может построить таблицу маршрутизации, которая включает всю информацию, включенную в маршруты 142 N1, маршруты 146 N3 и маршруты 148 N4. Таким образом, в следующий раз, когда узел 2 получит запрос на его маршруты или таблицу маршрутизации (т.е. маршруты 144 N2), узел 2 может отправить таблицу маршрутизации, которая включает в себя маршруты 142 N1, маршруты N2, маршруты 146 N3 и маршруты 148 N4.

[00137] Имея это в виду и возвращаясь к фиг. 6, в блоке 126 запрашивающее устройство 10 может обновлять свою локальную таблицу маршрутизации, чтобы включать информацию маршрутизации, полученную от соседнего устройства 10. В некоторых вариантах осуществления, каждое устройство 10 может выполнять способ 120 периодически, так что каждое устройство 10 включает обновленную таблицу маршрутизации, которая характеризует, каким образом каждый узел в беспроводной ячеистой сети 80 может быть соединен с каждым другим. Как упоминалось выше, каждый раз, когда способ 120 выполняется, каждое устройство 10 может принимать дополнительную информацию от своего соседнего устройства 10, если соседнее устройство 10 обновило свою таблицу маршрутизации информацией, полученной свих соседних устройств. В результате, каждое устройство 10 может понять, каким образом каждый узел в беспроводной ячеистой сети 80 может быть соединен с каждым другим.

[00138] Фиг. 7C, например, иллюстрирует таблицу 172 маршрутизации, которая может быть определена устройством 10 в узле 1 с использованием способа 120. В этом примере таблица 172 маршрутизации может определять каждый узел в беспроводной ячеистой сети 80 в качестве узла-получателя, промежуточные узлы между узлом 1 и каждым узлом-получателем, и число транзитных участков между узлом 1 и узлом-получателем. Число таких транзитных участков соответствует количеству раз, когда данные, посланные к узлу-получателю, могут направляться к промежуточному узлу перед достижением узла-получателя. При отправке данных к конкретному узлу-получателю, схема маршрутизации RIPng может выбрать маршрут, который включает наименьшее количество транзитных участков. Например, если узел 1 намеревается послать данные к узлу 9, схема маршрутизации RIPng будет маршрутизировать данных через узлы 2, 4, 5 и 8, что включает в себя четыре транзитных участка, в противоположность маршрутизации данных через узлы 2, 4, 6, 7 и 8, включающей в себя пять транзитных участков.

[00139] При использовании схемы маршрутизации RIPng, каждое устройство 10 может независимо определять то, каким образом данные должны маршрутизироваться к узлу-получателю. Обычные схемы маршрутизации, такие как Протокол Маршрутизации “Ripple” (RPL), используемые в устройствах 6LoWPAN, с другой стороны, могут маршрутизировать данные через центральный узел, который может быть единственным узлом, который знает структуру беспроводной ячеистой сети. Более конкретно, протокол RPL может создать беспроводную ячеистую сеть в соответствии с ориентированным ациклическим графом (DAG), которая может быть структурирована в виде иерархии. На вершине этой иерархии может располагаться граничный маршрутизатор, который может периодически выполнять многоадресную передачу запросов к узлам нижнего уровня, чтобы определять ранг для каждого из соединений узла. В сущности, когда данные передаются из узла-источника к узлу-получателю, данные могут передаваться вверх по иерархии узлов, а затем обратно вниз к узлу-получателю. Таким образом, узлы, расположенные выше в иерархии, могут маршрутизировать данные чаще, чем узлы, расположенные ниже в иерархии. Кроме того, пограничный маршрутизатор системы RPL также может работать более часто, так как он управляет тем, как данные будут маршрутизироваться через иерархию. В обычной системе RPL, в противоположность системе RIPng, раскрытой здесь, некоторые узлы могут маршрутизировать данные на более частой основе просто в силу своего расположения в иерархии, а не из-за своего расположения по отношению к узлу-источнику и узлу-получателю. Эти узлы, которые маршрутизируют данные чаще в соответствии с системой RPL, могут потреблять больше энергии и, следовательно, не могут быть подходящими для реализации с устройствами 10 в домашней среде 30, которая работает с использованием малой мощности. Кроме того, как упоминалось выше, если пограничный маршрутизатор или любой другой узел более высокого уровня системы RPL соответствует термостату 46, повышенная активность маршрутизации данных может увеличить тепло, производимое в термостате 46. В результате показание температуры термостата 46 может некорректно представлять температуру домашней среды 30. Поскольку другие устройства 10 могут выполнять определенные операции на основании показания температуры термостата 46, и поскольку термостат 46 может посылать команды на различные устройства 10 на основе своего показания температуры, может быть выгодным гарантировать, что показание температуры термостата 46 является точным.

[00140] В дополнение, чтобы гарантировать, что ни одно из устройств 10 не маршрутизирует данные несоразмерное количество раз, с использованием схемы маршрутизации RIPng, новые устройства 10 могут добавляться к беспроводной ячеистой сети с минимальными усилиями со стороны пользователя. Например, фиг. 7D иллюстрирует новый узел 10, добавляемый к беспроводной ячеистой сети 80. В некоторых вариантах осуществления, как только узел 10 устанавливает соединение с беспроводной ячеистой сетью 80 (например, через узел 4), устройство 10, которое соответствует узлу 10, может выполнить способ 120, описанный выше, чтобы определить, каким образом данные могут маршрутизироваться к каждому узлу в беспроводной ячеистой сети 80. Если каждый узел в беспроводной ячеистой сети 80 уже выполнил способ 120 несколько раз, устройство 10 в узле 10 может принимать всю структуру маршрутизации беспроводной ячеистой сети 80 от устройства 10 в узле 4. Таким же образом, устройства 10 могут удаляться из беспроводной ячеистой сети 80, и каждый узел может обновлять свою таблицу маршрутизации относительно просто путем выполнения снова способа 120.

[00141] После установления схемы маршрутизации с использованием схемы маршрутизации RIPng, ELoWPAN 110 может использовать протокол DTLS для защиты передач данных между каждым устройством 10 в домашней среде 30. Как упоминалось выше, путем использования протокола DTLS вместо протокола TLS, ELoWPAN 110 может разрешить транспортному уровню 98 передавать данные посредством TCP и UDP. Хотя UDP, в общем случае, может быть менее надежным по сравнению с TCP, UDP передачи данных используют простую схему передачи без выделенных каналов передачи или путей данных, устанавливаемых перед использованием. Таким образом, новые устройства 10, добавляемые к беспроводной ячеистой сети 80, могут использовать UDP передачи данных, чтобы эффективно осуществлять связь с другими устройствами 10 в беспроводной ячеистой сети более быстро. Кроме того, UDP передачи данных обычно используют меньше энергии устройством 10, которое передает или пересылает данных, поскольку не имеется никакой гарантии доставки. Таким образом, устройства 10 могут передавать некритичные данные (например, о присутствии человека в помещении), используя UDP передачу данных, тем самым экономя энергию в устройстве 10. Однако критические данные (например, тревожная сигнализация дыма) могут посылаться через TCP передачу данных, чтобы гарантировать, что соответствующая сторона примет данные. Повторяем, что использование схемы безопасности DTLS с ELoWOAN 110 может облегчать UDP и TCP передачи данных.

[00142] Имея в виду вышеописанное, ELoWPAN 110 может использовать протокол DTLS, чтобы защищать данные, передаваемые между устройствами 10. В одном варианте осуществления протокол DTLS может защищать передачи данных с использованием протокола квитирования. Как правило, протокол квитирования может аутентифицировать каждое устройство связи, использующее сертификат безопасности, который может быть предоставлен каждым устройством 10. Фиг. 8 иллюстрирует пример процесса 190 производства, который показывает, каким образом сертификат безопасности может встраиваться в устройство 10.

[00143] Со ссылкой на фиг. 8, доверенному производителю 192 устройства 10 может быть предоставлено множество сертификатов безопасности, которые он может использовать для каждого производимого устройства. Таким образом, при производстве устройства 10, которое может использоваться в домашней среде 30 и связываться с беспроводной ячеистой сетью 80, доверенный производитель 192 может встраивать сертификат 194 в устройство 10 в процессе 190 производства. То есть сертификат 194 может быть встроен в аппаратные средства устройства 10 во время изготовления устройства 10. Сертификат 194 может включать в себя открытый ключ, личный ключ или другие криптографические данные, которые могут использоваться для аутентификации различных устройств связи в беспроводной ячеистой сети 80. В результате, как только пользователь получает устройство 10, пользователь может интегрировать устройство 10 в беспроводную ячеистую сеть 80 без инициализации или регистрации устройства 10 в центральном узле безопасности или т.п.

[00144] В обычных протоколах безопасности передачи данных, таких как Протокол для Выполнения Аутентификации для Сетевого Доступа (PANA), используемых в устройствах 6LоWPAN, каждое устройство 10 может аутентифицировать себя в конкретном узле (т.е. агенте аутентификации). Таким образом, прежде чем данные передаются между любыми двумя устройствами 10, каждое устройство 10 может аутентифицировать себя в узле-агенте аутентификации. Узел-агент аутентификации может затем передать результат аутентификации в узел точки обеспечения исполнения, который может быть расположен совместно с узлом-агентом аутентификации. Узел точки обеспечения исполнения может затем установить канал передачи данных между двумя устройствами 10, если аутентификации действительны. Кроме того, в PANA, каждое устройство 10 может осуществлять связь друг с другом через узел точки обеспечения исполнения, который может верифицировать, что аутентификация для каждого устройства 10 действительна.

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

[00146] Имея это в виду, фиг. 9 иллюстрирует пример протокола 200 квитирования, который может использоваться между устройствами 10 при передаче данных между собой. Как показано на фиг. 9, устройство 10 в узле 1 может послать сообщение 202 на устройство 10 в узле 2. Сообщение 202 может быть приветственным сообщением, которое может включать в себя комплекты шифров, алгоритмы хеширования и сжатия и случайное число. Устройство 10 в узле 2 может затем ответить сообщением 204, которое может верифицировать, что устройство 10 в узле 2 приняло сообщение 202 от устройства 10 в узле 1.

[00147] После установления соединения между узлом 1 и узлом 2, устройство в узле 1 может снова передать сообщение 202 к устройству 10 в узле 2. Устройство 10 в узле 2 может затем ответить сообщением 208, которое может включать приветственное сообщение от узла 2, сертификат 194 от узла 2, обмен ключами от узла 2 и запрос сертификата для узла 1. Приветственное сообщение в сообщении 208 может включать в себя комплекты шифров, алгоритмы хеширования и сжатия и случайное число. Сертификат 194 может быть сертификатом безопасности, встроенным в устройство 10 доверенным производителем 192, как описано выше со ссылкой на фиг. 8. Обмен ключами может включать в себя открытый ключ, личный ключ или другую криптографическую информацию, которая может быть использована для определения секретного ключа для установления канала связи между двумя узлами. В одном варианте осуществления обмен ключами может быть сохранен в сертификате 194 соответствующего устройства 10, расположенного в соответствующем узле.

[00148] В ответ на сообщение 208, устройство 10 в узле 1 может отправить сообщение 210, которое может включать в себя сертификат 194 от узла 1, обмен ключами от узла 1, верификацию сертификата узла 2 и спецификацию изменения шифра от узла 1. В одном варианте осуществления устройство 10 в узле 1 может использовать сертификат 194 узла 2 и обмен ключами от узла 1 для верификации сертификата 194 узла 2. То есть устройство 10 в узле 1 может верифицировать, что сертификат 194, полученный от узла 2, действителен, на основании сертификата 194 узла 2 и обмена ключами от узла 1. Если сертификат 194 от узла 2 действителен, устройство 10 в узле 1 может послать сообщение спецификации изменения шифра к устройству 10 в узле 2, чтобы объявить, что канал связи между двумя узлами является безопасным.

[00149] Аналогичным образом, после приема сообщения 210, устройство 10 в узле 2 может использовать сертификат 194 узла 1 и обмен ключами от узла 2 для верификации сертификата 194 узла 1. То есть устройство 10 в узле 2 может верифицировать, что сертификат 194, полученный от узла 1, действителен, на основании сертификата 194 узла 1 и обмена ключами от узла 2. Если сертификат 194 от узла 1 действителен, то устройство 10 в узле 2 может также послать сообщение спецификации изменения шифра на устройство 10 в узле 1, чтобы объявить, что канал связи между двумя узлами является безопасным.

[00150] После установления, что канал связи является безопасным, устройство 10 в узле 1 может послать групповой сетевой ключ 214 к устройству 10 в узле 2. Групповой сетевой ключ 214 может быть ассоциирован с ELoWPAN 110. Таким образом, когда новые устройства присоединяются к ELoWPAN 110, устройства, ранее авторизованные для связи в ELoWPAN 110, могут обеспечивать новым устройствам доступ к ELoWPAN 110. То есть устройства, ранее авторизованные для осуществления связи в ELoWPAN 110, могут предоставлять новым устройствам групповой сетевой ключ 214, который может позволять новым устройствам осуществлять связь с другими устройствами в ELoWPAN 110. Например, групповой сетевой ключ 214 может быть использован для осуществления связи с другими устройствами, которые были надлежащим образом аутентифицированы и которые имеют ранее предоставленный групповой сетевой ключ 214. В одном варианте осуществления, после выполнения обмена сообщением спецификации изменения шифра между устройством 10 в узле 1 и устройством 10 в узле 2, идентификационная информация, такая как номер модели, функциональные возможности устройства и т.п., может передаваться между устройствами. Однако после того, как устройство 10 в узле 2 получает групповой сетевой ключ 214, дополнительная информация, такая как данные от датчиков, расположенных на устройстве 10, анализ данных, выполненный устройством 10, и т.п., может быть передана между устройствами.

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

Эффективные уровни платформы и/или приложения

[00152] С использованием вышеописанных ELowPAN 110 и/или других подходящих логических сетей IPv6, эффективные уровни платформы и/или приложения могут быть использованы для генерации инфраструктуры устройств в домашней среде или подобных средах. Инфраструктура устройств может позволить многим, в общем, локальных устройств осуществлять связь, совместно использовать данные и информацию, вызывать способы друг друга, параметрически обеспечивать обновления программного обеспечения через сеть и, в общем, передавать сообщения эффективным, осмысленным по мощности способом.

Взаимосвязь устройства с инфраструктурой

[00153] Как описано выше, инфраструктура может быть реализована с использованием одного или более подходящих протоколов связи, таких как протоколы IPv6. Фактически, инфраструктура может быть частично или полностью безразлична к базовым технологиям (например, типам сетей или протоколам связи), используемым для реализации инфраструктуры. В одном или более протоколах связи, инфраструктура может быть реализована с использованием одного или более типов сетей, используемых, чтобы коммуникативно связывать электрические устройства с использованием беспроводных или проводных соединений. Например, некоторые варианты осуществления инфраструктуры могут включать в себя Ethernet, WiFi, 802.15.4, ZigBee®, ISA100.11a, WirelessHART, MiWi^TM, сети на линиях питания и/или другие подходящие типы сетей. В рамках инфраструктуры, устройства (например, узлы) могут обмениваться пакетами информации с другими устройствами (например, узлами) в инфраструктуре, непосредственно или через промежуточные узлы, такие как интеллектуальные термостаты, выступающие в качестве IP-маршрутизаторов. Эти узлы могут включать в себя устройства от производителей (например, термостаты и детекторы дыма) и/или клиентские устройства (например, телефоны, планшеты, компьютеры и т.д.). Кроме того, некоторые устройства могут быть “всегда включены” и непрерывно получают питание с использованием электрических соединений. Другие устройства могут иметь частично сниженное потребление мощности (например, средний рабочий цикл), используя соединение пониженного/прерывистого питания, например, соединение питания термостата или дверного звонка. Наконец, некоторые устройства могут иметь короткий рабочий цикл и работают только от батарейного питания. Другими словами, в некоторых вариантах осуществления, инфраструктура может включать разнородные устройства, которые могут быть соединены с одной или более подсетями в соответствии с типом соединения и/или желательной потребляемой мощностью. Фиг. 10-12 иллюстрируют три варианта осуществления, которые могут быть использованы для соединения электрических устройств через одну или более подсетей в инфраструктуре.

A. Топология одиночной сети

[00154] Фиг. 10 иллюстрирует вариант осуществления инфраструктуры 1000, имеющей топологию одиночной сети. Как показано, инфраструктура 1000 включает в себя одиночную логическую сеть 1002. Сеть 1002 может включать в себя Ethernet, WiFi, 802.15.4, сети на линиях питания и/или другие подходящие типы сетей в протоколах IPv6. Фактически, в некоторых вариантах осуществления, когда сеть 1002 включает в себя сеть WiFi или Ethernet, сеть 1002 может охватывать несколько сегментов WiFi и/или Ethernet, которые перекрываются мостами на канальном уровне.

[0093] Сеть 1002 включает в себя один или несколько узлов 1004, 1006, 1008, 1010, 1012, 1014 и 1016, совместно упоминаемых как 1004-1016. Хотя показанная сеть 1002 включает в себя семь узлов, некоторые варианты осуществления сети 1002 могут включать в себя один или несколько узлов, взаимосвязанных с использованием сети 1002. Кроме того, если сеть 1002 является сетью WiFi, каждый из узлов 1004-1016 может быть взаимосвязан с помощью узла 1016 (например, WiFi-маршрутизатора) и/или формировать пары с другими узлами, используя WiFi Direct (прямое соединение) (т.е. WiFi P2P).

B. Звездообразная сетевая топология

[00156] На фиг. 11 показан альтернативный вариант осуществления инфраструктуры 1000 в форме инфраструктуры 1018, имеющей звездообразную сетевую топологию. Инфраструктура 1018 включает в себя сеть-концентратор 1020, которая соединяет вместе две периферийные сети 1022 и 1024. Сеть-концентратор 1020 может включать в себя домашнюю сеть, например, сеть WiFi/Ethernet или сеть на линиях питания. Периферийные сети 1022 и 1024 могут быть дополнительными сетевыми соединениями различных типов, иных, чем сеть-концентратор 1020. Например, в некоторых вариантах осуществления, сеть-концентратор 1020 может представлять собой сеть WiFi/Ethernet, периферийная сеть 1022 может включать в себя сеть 802.15.4, и периферийная сеть 1024 может включать в себя сеть на линиях питания, сеть ZigBee®, сеть ISA100.11а, сеть WirelessHART или сеть MiWi^МТ. Кроме того, хотя показанный вариант осуществления инфраструктуры 1018 включает в себя три сети, некоторые варианты осуществления инфраструктуры 1018 могут включать в себя любое количество сетей, такое как 2, 3, 4, 5 или более сетей. Реально, некоторые варианты осуществления инфраструктуры 1018 включают в себя несколько периферийных сетей того же типа.

[00157] Хотя проиллюстрированная инфраструктура 1018 включает в себя четырнадцать узлов, обозначенные, каждый, индивидуально ссылочными позициями 1024-1052, соответственно, следует понимать, что инфраструктура 1018 может включать в себя любое количество узлов. Связь в каждой сети 1020, 1022 или 1024 может происходить непосредственно между устройствами и/или через точку доступа, например, узел 1042 в сети WiFi/Ethernet. Связь между периферийной сетью 1022 и 1024 проходит через сеть-концентратор 1020 с использованием узлов межсетевой маршрутизации. Например, в показанном варианте осуществления, узлы 1034 и 1036 соединены с периферийной сетью 1022 с использованием первого типа сетевого соединения (например, 802.15.4) и с сетью-концентратором 1020 с использованием второго типа сетевого соединения (например, WiFi), в то время как узел 1044 соединен с сетью-концентратором 1020 с использованием второго типа сетевого соединения и с периферийной сетью 1024 с использованием третьего типа сетевого соединения (например, линии питания). Например, сообщение, посланное от узла 1026 к узлу 1052, может проходить через узлы 1028, 1030, 1032, 1036, 1042, 1044, 1048 и 1050 по пути к узлу 1052.

C. Топология перекрывающихся сетей

[00158] Фиг. 12 иллюстрирует альтернативный вариант осуществления инфраструктуры 1000 как инфраструктуры 1054, имеющей топологию перекрывающихся сетей. Инфраструктура 1054 включает в себя сети 1056 и 1058. Как показано, каждый из узлов 1062, 1064, 1066, 1068, 1070 и 1072 может быть соединен с каждой из сетей. В других вариантах осуществления, узел 1072 может включать в себя точку доступа для сети Ethernet/WiFi, а не конечную точку, и может не присутствовать либо в сети 1056, либо в сети 1058, той, которая не является сетью Ethernet/WiFi. Соответственно, сообщение от узла 1062 к узлу 1068 может быть передано через сеть 1056, сеть 1058 или некоторую их комбинацию. В показанном варианте осуществления каждый узел может связываться с любым другим узлом через любую сеть с использованием любой желательной сети. Соответственно, в отличие от звездообразной сетевой топологии по фиг. 11, топология перекрывающихся сетей может осуществлять связь непосредственно между узлами с использованием любой сети без использования межсетевой маршрутизации.

D. Соединение инфраструктурной сети со службами

[00159] В дополнение к осуществлению связи между устройствами в пределах дома, инфраструктура (например, инфраструктура 1000) может включать в себя службы, которые могут быть расположены физически рядом с другими устройствами в инфраструктуре или физически удалены от таких устройств. Инфраструктура соединяется с этими службами через одну или более конечных точек служб. Фиг. 13 иллюстрирует вариант осуществления службы 1074, осуществляющей связь с инфраструктурами 1076, 1078 и 1080. Служба 1074 может включать в себя различные службы, которые могут быть использованы устройствами в инфраструктурах 1076, 1078 и/или 1080. Например, в некоторых вариантах осуществления, служба 1074 может быть службой времени суток, которая предоставляет время суток на устройства, службой погоды, чтобы обеспечивать различные метеорологические данные (например, внешнюю температуру, закат, информацию о ветре, прогноз погоды и т.д.), эхо-службой, которая “опрашивает” каждое устройство, службами управления данными, службами управления устройствами и/или другими подходящими службами. Как показано, служба 1074 может включать в себя сервер 1082 (например, веб-сервер), который хранит/обращается к соответствующим данным и передает информацию через конечную точку 1084 службы к одной или более конечным точкам 1086 в инфраструктуре, такой как инфраструктура 1076. Хотя проиллюстрированный вариант осуществления включает в себя только три инфраструктуры с одним сервером 1082, следует понимать, что служба 1074 может соединяться с любым количеством инфраструктур и может включать в себя серверы в дополнение к серверу 1082 и/или соединения с дополнительными службами.

[00160] В некоторых вариантах осуществления служба 1074 также может соединяться с потребительским устройством 1088, таким как телефон, планшет и/или компьютер. Потребительское устройство 1088 может быть использовано для соединения со службой 1074 через инфраструктуру, например, инфраструктуру 1076, Интернет-соединение и/или другой подходящий способ соединения. Потребительское устройство 1088 может быть использовано для доступа к данным из одной или нескольких конечных точек (например, электронных устройств) в инфраструктуре либо непосредственно через инфраструктуру, либо через службу 1074. Другими словами, используя службу 1074, потребительское устройство 1088 может быть использовано для доступа/управления устройствами в инфраструктуре дистанционно от инфраструктуры.

E. Связь между устройствами в инфраструктуре

[00161] Как описано выше, каждое электронное устройство или узел может связываться с любым другим узлом в инфраструктуре, прямо или косвенно в зависимости от топологии инфраструктуры и типа сетевого соединения. Дополнительно, некоторые устройства (например, удаленные устройства) могут осуществлять связь через службу, чтобы осуществлять связь с другими устройствами в инфраструктуре. Фиг. 14 иллюстрирует вариант осуществления связи 1090 между двумя устройствами 1092 и 1094. Связь 1090 может охватывать одну или более сетей, прямо или косвенно, через дополнительные устройства и/или службы, как описано выше. Дополнительно, связь 1090 может происходить в соответствующем протоколе связи, таком как IPv6, с использованием одного или более транспортных протоколов. Например, в некоторых вариантах осуществления связь 1090 может включать в себя использование протокола управления передачей (TCP) и/или протокола пользовательских дейтаграмм (UDP). В некоторых вариантах осуществления устройство 1092 может передавать первый сигнал 1096 на устройство 1094 с использованием протокола без установления соединения (например, UDP). В некоторых вариантах осуществления устройство 1092 может осуществлять связь с устройством 1094 с использованием протокола, ориентированного на соединение (например, TCP). Хотя проиллюстрированная связь 1090 изображена как двунаправленное соединение, в некоторых вариантах осуществления связь 1090 может быть однонаправленным широковещанием.

i. Уникальный локальный адрес

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

[00163] Каждому узлу может быть назначен набор локальных для линии адресов (LLA), по одному, присваиваемому каждому сетевому интерфейсу. Эти LLA могут быть использованы для связи с другими узлами в той же сети. Кроме того, LLA могут быть использованы для различных процедур связи, таких как IPv6 Протокол Обнаружения Соседа. В дополнение к LLA, каждому узлу назначается уникальный локальный адрес (ULA). В некоторых вариантах осуществления он может упоминаться как Расширенный Уникальный Локальный Адрес (ЕULA), поскольку он содержит информацию относительно инфраструктуры устройств, а также предпочтительной сети, по которой устройство достигается через инфраструктуру.

[00164] Фиг. 15 иллюстрирует вариант осуществления уникального локального адреса (ULA) 1098, который может использоваться для адресации каждого узла в инфраструктуре. В некоторых вариантах осуществления ULA 1098 может быть отформатирован как формат IPv6-адреса, содержащий 128 бит, разделенный на глобальный ID 1100, ID 1102 подсети и ID 1104 интерфейса. Глобальный ID 1100 включает в себя 40 бит, и ID 1102 подсети включает в себя 16 бит. Глобальный ID 1100 и ID 1102 подсети вместе образуют ID 1103 инфраструктуры для инфраструктуры.

[00165] ID 1103 инфраструктуры представляет собой уникальный 64-битный идентификатор, используемый для идентификации инфраструктуры. ID 1103 инфраструктуры может быть сгенерирован при создании ассоциированной инфраструктуры с использованием псевдослучайного алгоритма. Например, псевдо-случайный алгоритм может 1) получать текущее время суток в 64-битном формате NTP, 2) получать ID 1104 интерфейса для устройства, 3) выполнять конкатенацию времени суток с ID 1104 интерфейса, чтобы создать ключ, 4) вычислять SHA-1 дайджест на ключе с получением 160 бит, 5) использовать младшие 40 бит в качестве глобального ID 1100 и 6) выполнять конкатенацию ULA и устанавливать младший бит в 1, чтобы создать ID 1103 инфраструктуры. В некоторых вариантах осуществления, как только ID 1103 инфраструктуры создан с инфраструктурой, ID 1103 инфраструктуры остается, пока инфраструктура не будет аннулирована.

[00166] Глобальный ID 1100 идентифицирует инфраструктуру, к которой принадлежит узел. ID 1102 подсети идентифицирует логические сети в инфраструктуре. ID подсети F3 может быть назначен монотонно, начиная с единицы, с добавлением каждой новой логической сети к инфраструктуре. Например, сеть WiFi может быть идентифицирована шестнадцатеричным значением 0x01, а позднее подключенная сеть 802.15.4 может быть идентифицирована шестнадцатеричным значением 0x02, продолжая с приращением после подсоединения каждой новой сети к инфраструктуре.

[00167] Наконец, ULA 1098 включает в себя ID 1104 интерфейса, который включает в себя 64 бита. ID 1104 интерфейса может быть назначен с использованием глобально уникального 64-битного идентификатора в соответствии со стандартом IEEE EUI-64. Например, устройства с интерфейсами сети IEEE 802 могут получать ID 1104 интерфейса с использованием прожженного MAC-адреса для “первичного интерфейса” устройств. В некоторых вариантах осуществления, обозначение, какой интерфейс является первичным интерфейсом, может быть определено произвольно. В других вариантах осуществления некоторый тип интерфейса (например, WiFi) может считаться первичным интерфейсом, когда он присутствует. Если МАС-адрес для первичного интерфейса устройства является 48-битовым, а не 64-битовым, 48-битовый МАС-адрес может быть преобразован в значение EUI-64 с помощью инкапсуляции (например, инкапсуляции организационно уникального идентификатора). В потребительских устройствах (например, телефонах или компьютерах), ID 1104 интерфейса может быть назначен локальными операционными системами потребительских устройств.

ii. Маршрутизация передач между логическими сетями

[00168] Как обсуждалось выше по отношению к звездообразной топологии сети, межсетевая маршрутизация может происходить при осуществлении связи между двумя устройствами через логические сети. В некоторых вариантах осуществления межсетевая маршрутизация основана на ID 1102 подсети. Каждый узел межсетевой маршрутизации (например, узел 1034 на фиг. 11) может поддерживать список других узлов маршрутизации (например, узла В 14 на фиг. 11) на сети-концентраторе 1020 и их соответствующих присоединенных периферийных сетях (например, периферийной сети 1024 на фиг. 11). Когда поступает пакет, адресованный узлу, иному, чем сам узел маршрутизации, адрес места назначения (получателя) (например, адрес для узла 1052 на фиг. 11) сравнивается со списком сетевых префиксов, и выбирается узел маршрутизации (например, узел 1044), который присоединен к желательной сети (например, периферийной сети 1024). Затем пакет пересылается к выбранному узлу маршрутизации. Если несколько узлов (например, 1034 и 1036) присоединены к той же периферийной сети, то узлы маршрутизации выбираются в чередующемся порядке.

[00169] Кроме того, узлы межсетевой маршрутизации могут регулярно передавать сообщения оповещения маршрутизатора Протокола Обнаружения Соседа (NDP) по сети-концентратору, чтобы оповещать потребительские устройства о существовании сети-концентратора и позволять им получать префикс подсети. Оповещения маршрутизатора могут включать в себя одну или несколько опций информации маршрутов для оказания помощи в маршрутизации информации в инфраструктуре. Например, эти опции информации маршрутов могут информировать потребительские устройства о существовании периферийных сетей и о том, как маршрутизировать пакеты в периферийных сетях.

[00170] В дополнение или вместо опций информации маршрутов, узлы маршрутизации могут выступать в качестве посредников (прокси), чтобы обеспечивать соединение между потребительскими устройствами и устройствами в периферийных сетях, как процесс 1105, проиллюстрированный на фиг. 16. Как показано, процесс 1105 включает в себя назначение каждому устройству периферийной сети виртуального адреса в сети-концентраторе путем объединения ID 1102 подсети с ID 1104 интерфейса для устройства в периферийной сети (блок 1106). Для представления с использованием виртуальных адресов, узлы маршрутизации поддерживают список всех периферийных узлов в инфраструктуре, которые напрямую достижимы через один из ее интерфейсов (блок 1108). Узлы маршрутизации прослушивают сеть-концентратор на предмет сообщений запроса о соседях, запрашивающих канальный адрес периферийного узла с использованием своего виртуального адреса (блок 1110). При приеме такого сообщения, узел маршрутизации пытается назначить виртуальный адрес своему интерфейсу концентратора спустя некоторый период времени (блок 1112). Как часть назначения, узел маршрутизации выполняет обнаружение дубликатов адреса, чтобы блокировать представление виртуального адреса более чем одним узлом маршрутизации. После назначения, узел маршрутизации отвечает на сообщение запроса о соседях и принимает пакет (блок 1114). После приема пакета, узел маршрутизации переписывает адрес места назначения на реальный адрес периферийного узла (блок 1116) и пересылает сообщение на соответствующий интерфейс (блок 1118).

iii. Соединение потребительских устройств с инфраструктурой

[00171] Чтобы присоединиться к инфраструктуре, потребительское устройство может обнаружить адрес узла уже в инфраструктуре, к которой потребительскому устройству желательно присоединиться. Кроме того, если потребительское устройство было отсоединено от инфраструктуры в течение длительного периода времени, возможно, потребуется заново обнаруживать узлы в сети, если топология/расположение инфраструктуры изменилось. Чтобы способствовать обнаружению/повторному обнаружению, инфраструктурные устройства в сети-концентраторе могут публиковать отчеты Службы Обнаружения Системы Доменных Имен (DNS-SD) посредством mDNS, которые оповещают о присутствии инфраструктуры и обеспечивают адреса для потребительского устройства.

III. Данные, передаваемые в инфраструктуре

[00172] После создания инфраструктуры и создания адреса для узлов, данные могут передаваться через инфраструктуру. Данные, передаваемые через инфраструктуру, могут быть упорядочены в формат, общий для всех сообщений и/или общий для определенных типов диалогов в инфраструктуре. В некоторых вариантах осуществления, формат сообщения может позволить отображение один-к-одному на JavaScript Object Notation (JSON) с использованием формата преобразования в последовательную форму TLV, обсужденного ниже. Кроме того, хотя следующие кадры данных описаны как включающие определенные размеры, следует отметить, что длина полей данных в кадрах данных может изменяться на другие подходящие битовые длины.

А. Безопасность

[00173] Наряду с данными, предназначенными для передачи, инфраструктура может передавать данные с дополнительными мерами безопасности, такими как шифрование, проверки целостности сообщений и цифровые подписи. В некоторых вариантах осуществления уровень безопасности, поддерживаемый для устройства, может варьироваться в соответствии с физической безопасностью устройства и/или возможностями устройства. В некоторых вариантах осуществления, сообщения, передаваемые между узлами в инфраструктуре, могут быть зашифрованы с использованием блочного шифра Усовершенствованного Стандарта Шифрования (AES), работающего в режиме счетчика (AES-CTR) с 128-битным ключом. Как обсуждено ниже, каждое сообщение содержит 32-битный идентификатор (id) сообщения. id сообщения может быть объединен с id передающего узла для формирования защитного слова для алгоритма AES-CTR. 32-битный счетчик позволяет зашифровывать и отправлять 4 млрд сообщений каждым узлом, прежде чем будет согласован новый ключ.

[00174] В некоторых вариантах осуществления инфраструктура может обеспечить целостность сообщения, используя код аутентификации сообщения, например HMAC-SHA-1, который может быть включен в каждое зашифрованное сообщение. В некоторых вариантах осуществления код аутентификации сообщения может быть сгенерирован с использованием 160-битного ключа целостности сообщения, который образует пару в соотношении один к одному с ключом шифрования. Кроме того, каждый узел может проверить id сообщения входящих сообщений по отношению к списку недавно принятых id, поддерживаемых на основе по каждому узлу, чтобы блокировать воспроизведение сообщений.

B. Форматирование значения длины тега (TLV)

[00175] Для снижения потребления мощности, желательно передавать по меньшей мере часть данных, передаваемых по инфраструктуре, компактно, при этом позволяя контейнерам данных гибко представлять данные, что учитывает пропуск данных, которые не распознаны или не понятны, пропуская до следующего местоположения данных, которые понятны, при преобразовании данных в последовательную форму. В некоторых вариантах осуществления, форматирование “тег-длина-значение” (TLV) может быть использовано для компактного и гибкого кодирования/декодирования данных. Путем сохранения по меньшей мере части передаваемых данных в TLV, данные могут быть компактно и гибко сохранены/посланы с низкой служебной нагрузкой кодирования/декодирования и памяти, как описано ниже со ссылкой на таблицу 7. В некоторых вариантах осуществления TLV могут быть использованы для некоторых данных как гибкие, расширяемые данные, но другие части данных, которые не являются расширяемыми, могут быть сохранены и отправлены в понятном стандартном протокольном блоке данных (PDU).

[00176] Данные, отформатированные в формате TLV, могут быть закодированы как элементы TLV различных типов, таких как примитивные типы и контейнерные типы. Примитивные типы включают значения данных в некоторых форматах, таких как целые числа или строки. Например, формат TLV может кодировать: числа в 1, 2, 3, 4 или 8 байт со знаком/без знака, UTF-8 строки, байтовые строки, числа с плавающей запятой одинарной/двойной точности (например, формата IEEE 754-1985), булевы, нулевые и другие подходящие типы формата данных. Контейнерные типы включают в себя совокупности элементов, которые затем подразделяются на контейнерные или примитивные типы. Контейнерные типы могут быть классифицированы по различным категориям, таким как словари, массивы, пути или другие подходящие типы для группировки элементов TLV, известных в качестве членов. Словарь представляет собой совокупность членов, каждый из которых имеет четкие определения и уникальные теги в словаре. Массив - это упорядоченная совокупность членов с подразумеваемыми определениями или без отдельных определений. Путь представляет собой упорядоченную совокупность элементов, которая описывает, как пройти дерево элементов TLV.

[00177] Как показано на фиг. 11, вариант осуществления пакета 1120 TLV включает в себя три поля данных: поле 1122 тега, поле 1124 длины и поле 1126 значения. Хотя показанные поля 1122, 1124 и 1126 проиллюстрированы как приблизительно эквивалентные по размеру, размер каждого поля может быть переменным и различается по размеру по отношению друг к другу. В других вариантах осуществления пакет 1120 TLV может дополнительно включать в себя байт управления перед полем 1122 тега.

[00178] В вариантах осуществления, имеющих байт управления, байт управления может быть подразделен на поле типа элемента и поле управления тега. В некоторых вариантах осуществления поле типа элемента включает в себя 5 младших бит байта управления, и поле управления тега занимает верхние 3 бита. Поле типа элемента указывает тип элемента TLV, а также то, как кодированы поле 1124 длины и поле 1126 значения. В некоторых вариантах осуществления поле типа элемента также кодирует булевы значения и/или нулевые значения для TLV. Например, вариант осуществления перечисления поля типа элемента приведен в таблице 1 ниже.

Таблица 1 Примерные значения поля типа элемента 7 6 5 4 3 2 1 0 0 0 0 0 0 Целое со знаком, значение 1 байт 0 0 0 0 1 Целое со знаком, значение 2 байта 0 0 0 1 0 Целое со знаком, значение 4 байта 0 0 0 1 1 Целое со знаком, значение 8 байт 0 0 1 0 0 Целое без знака, значение 1 байт 0 0 1 0 1 Целое без знака, значение 2 байта 0 0 1 1 0 Целое без знака, значение 4 байт 0 0 1 1 1 Целое без знака, значение 8 байт 0 1 0 0 0 Булево ложно 0 1 0 0 1 Булево истинно 0 1 0 1 0 Число с плавающей запятой, значение 4 байта 0 1 0 1 1 Число с плавающей запятой, значение 8 байт 0 1 1 0 0 UTF8-строка, длина 1 байт 0 1 1 0 1 UTF8-строка, длина 2 байта 0 1 1 1 0 UTF8-строка, длина 4 байта 0 1 1 1 1 UTF8-строка, длина 8 байт 1 0 0 0 0 Байтовая строка, длина 1 байт 1 0 0 0 1 Байтовая строка, длина 2 байта 1 0 0 1 0 Байтовая строка, длина 4 байта 1 0 0 1 1 Байтовая строка, длина 8 байт 1 0 1 0 0 Нуль 1 0 1 0 1 Словарь 1 0 1 1 0 Массив 1 0 1 1 1 Путь 1 1 0 0 0 Конец контейнера

Поле управления тега указывает форму тега в поле 1122 тега, назначенном элементу TLV (включая тег нулевой длины). Примеры значений поля управления тега представлены ниже в таблице 2.

Таблица 2 Примерные значения для поля управления тега 7 6 5 4 3 2 1 0 0 0 0 Анонимное, 0 байт 0 0 1 Контекстно-специфический тег, 1 байт 0 1 0 Тег базового профиля, 2 байта 0 1 1 Тег базового профиля, 4 байта 1 0 0 Тег неявного профиля, 2 байта 1 0 1 Тег неявного профиля, 4 байта 1 1 0 Полностью определенный тег, 6 байт 1 1 1 Полностью определенный тег, 8 байт

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

[00179] В некоторых вариантах осуществления поле 1122 тега может включать от нуля до восьми байт, например, восемь, шестнадцать, тридцать два или шестьдесят четыре бита. В некоторых вариантах осуществления тег поля тега может быть классифицирован как профильно-специфические теги или контекстно-специфические теги. Профильно-специфические теги идентифицируют элементы глобально, используя Id поставщика, Id профиля и/или номер тега, как описано ниже. Контекстно-специфические теги идентифицируют элементы TLV в пределах контекста содержащего словарь элемента и могут включать однобайтовый номер тега. Так как контекстно-специфические теги определены в контексте их контейнеров, одиночный контекстно-специфический тег может иметь различные интерпретации, когда включен в различные контейнеры. В некоторых вариантах осуществления контекст может быть также получен из вложенных контейнеров.

[00180] В вариантах осуществления, имеющих байт управления, длина тега кодируется в поле управления тега, и поле 1122 тега включает в себя возможные три поля: поле Id поставщика, поле Id профиля и поле номера тега. В полностью определенной форме, поле 1122 кодированного тега включает в себя все три поля с полем номера тега, включающим в себя 16 или 32 бита, определенным полем управления тега. В неявной форме, тег включает в себя только номер тега, и Id поставщика и номер профиля выводятся из контекста протокола элемента TLV. Форма базового профиля включает в себя профильно-специфические теги, как описано выше. Контекстно-специфические теги кодируются как один байт, переносящий номер тега. Анонимные элементы имеют поля 1122 тега нулевой длины.

[00181] В некоторых вариантах осуществления без байта управления два бита могут указывать длину поля 1122 тега, два бита могут указывать длину поля 1124 длины, и четыре бита могут указывать тип информации, сохраненной в поле 1126 значения. Пример возможного кодирования для верхних 8 бит для поля тега показан ниже в таблице 3.

Таблица 3 Поле тега пакета TLV Байт 0 7 6 5 4 3 2 1 0 Описание 0 0 - - - - - - Тег равен 8 битам 0 1 - - - - - - Тег равен 16 битам 1 0 - - - - - - Тег равен 32 битам 1 1 - - - - - - Тег равен 64 битам - - 0 0 - - - - Длина равна 8 битам - - 0 1 - - - - Длина равна 16 битам - - 1 0 - - - - Длина равна 32 битам - - 1 1 - - - - Длина равна 64 битам - - 0 0 0 0 Булево - - 0 0 0 1 Фиксированное 8-битовое без знака - - 0 0 1 0 Фиксированное 8-битовое со знаком - - 0 0 1 1 Фиксированное 16-битовое без знака - - 0 1 0 0 Фиксированное 16-битовое со знаком - - 0 1 0 1 Фиксированное 32-битовое без знака - - 0 1 1 0 Фиксированное 32-битовое со знаком - - 0 1 1 1 Фиксированное 64-битовое без знака - - 1 0 0 0 Фиксированное 64-битовое со знаком - - 1 0 0 1 32-битовое с плавающей запятой - - 1 0 1 0 64-битовое с плавающей запятой - - 1 0 1 1 UTF-8 строка - - 1 1 0 0 Непрозрачные данные - - 1 1 0 1 Контейнер

Как показано в таблице 3, верхние 8 битов поля 1122 тега могут быть использованы для кодирования информации о поле 1122 тега, поле 1124 длины и поле 1126 значения, так что поле 112 тега может быть использовано для определения длины для поля 122 тега и поля 1124 длины. Остальные биты в поле 1122 тега могут быть сделаны доступными для распределенных пользователем и/или назначенных пользователем значений тегов.

[00182] Поле 1124 длины может включать в себя восемь, шестнадцать, тридцать два или шестьдесят четыре бита, как указано полем 1122 тега, как показано в таблице 3, или полем элемента, как показано в таблице 2. Кроме того, поле 1124 длины может включать в себя целое число без знака, которое представляет длину закодированного в поле 1126 значения. В некоторых вариантах осуществления длина может быть выбрана устройством, передающим элемент TLV. Поле 1126 значения включает данные полезной нагрузки, подлежащие декодированию, но интерпретация поля 1126 значения может зависеть от полей длины тега и/или байта управления. Например, пакет TLV без байта управления, включающий 8-битный тег, показан в таблице 4 ниже для иллюстрации.

Таблица 4 Пример пакета TLV, включающего 8-битный тег Тег Длина Значение Описание 0×0d 0×24 0×09 0×04 0×42 95 00 00 74.5 0×09 0×04 0×42 98 66 66 76.2 0×09 0×04 0×42 94 99 9a 74.3 0×09 0×04 0×42 98 99 9a 76.3 0×09 0×04 0×42 95 33 33 74.6 0×09 0×04 0×42 98 33 33 76.1

Как показано в таблице 4, первая строка указывает, что поле 1122 тега и поле 1124 длины имеет, каждое, длину 8 бит. Кроме того, поле 1122 тега указывает, что тип тега для первой строки является контейнером (например, пакет TLV). Поле 1124 тега для строк от второй до шестой указывают, что каждая запись в пакете TLV имеет поле 1122 тега и поле 1124 длины, состоящие из 8 битов каждое. Кроме того, поле 1124 тега указывает, что каждая запись в пакете TLV имеет поле 1126 значения, которое включает в себя 32-битовое значение с плавающей запятой. Каждая запись в поле 1126 значения соответствует числу с плавающей запятой, которое может декодироваться с использованием соответствующей информации поля 1122 тега и поля 1124 длины. Как показано в этом примере, каждая запись в поле 1126 значения соответствует температуре в градусах Фаренгейта. Как можно понять, путем сохранения данных в пакете TLV, как описано выше, данные могут быть переданы компактно, оставаясь гибкими для различных длин и информации, как может использоваться различными устройствами в инфраструктуре. Кроме того, в некоторых вариантах осуществления, поля мульти-байтовых целых чисел могут быть переданы в прямом порядке или в обратном порядке.

[00183] При передаче TLV пакетов с использованием протокола порядка (например, прямого порядка), который может быть использован форматами передающего/принимающего устройства (например, JSON), данные, передаваемые между узлами, могут передаваться в протоколе порядка, используемом по меньшей мере одним из узлов (например, прямого порядка). Например, если один или более узлов включают в себя ARM или i×86 процессоры, передачи между узлами могут передаваться с использованием упорядочения байтов в прямом порядке, чтобы снизить использование переупорядочения байтов. Путем снижения включения переупорядочения байтов, формат TLV позволяет устройствам осуществлять связь с использованием меньшей мощности, чем в случае передачи, которая использует переупорядочение байтов на обоих концах передачи. Кроме того, форматирование TLV может быть определено, чтобы обеспечивать преобразование один к одному между другими методами хранения данных, такими как JSON+Extensible Markup Language (XML). В качестве примера, формат TLV может быть использован для представления следующего XML списка свойств:

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

Таблица 5 Примерное представление XML списка свойств в формате TLV XML ключ Тип тега Номер тега OfflineMode Булев 1 IPv4 Контейнер 3 IPv6 Контейнер 4 Method Строка 5 Technologies Контейнер 6 WiFi Контейнер 7 802.15.4 Контейнер 8 Enabled Булев 9 Devices Контейнер 10 ID Строка 11 Services Контейнер 12 Name Строка 13 SSID Данные 14 EPANID Данные 15 Frequency 16-битовый без знака 16 AutoConnect Булев 17 Favorite Булев 18 Error Строка 19 DHCP Строка 20 LastAddress Данные 21 Device Контейнер 22 Service Контейнер 23

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

Таблица 6 Пример буквальных значений для полей тега, длины и значения для XML списка свойств Тег Длина Значение Описание 0×40 01 0×01 0 OfflineMode 0×4d 02 0×14 Network 0×4d 03 0×07 Network.IPv4 0×4b 05 0×04 “dhcp” Network.IPv4.Method 0×4d 04 0×07 Network.IPv6 0×4b 05 0×04 “auto” Network.IPv6.Method 0×4d 06 0×d6 Technologies 0×4d 07 0×65 Technologies.wifi 0×40 09 0×01 1 Technologies.wifi.Enabled 0×4d 0a 0×5e Technologies.wifi.Devices 0×4d 16 0×5b Technologies.wifi.Devices.Device.[0] 0×4b 0b 0×13 “wifi_18b43…” Technologies.wifi.Devices.Device.[0].ID 0×40 09 0×01 1 Technologies.wifi.Devices.Device.[0].Enabled 0×4d 0c 0×3e Technologies.wifi.Devices.Device.[0].Services 0×0b 0×3c “wifi_18b43…” Technologies.wifi.Devices.Device.[0].Services.[0] 0×4d 08 0×6b Technologies.802.15.4 0×40 09 0×01 1 Technologies.802.15.4.Enabled 0×4d 0a 0×64 Technologies.802.15.4.Devices 0×4d 16 0×61 Technologies.802.15.4.Devices.Device.[0] 0×4b 0b 0×1a “802.15.4_18” Technologies.802.15.4.Devices.Device.[0].ID 0×40 09 0×01 1 Technologies.802.15.4.Devices.Device.[0].Enabled 0×4d 0c 0×3d Technologies.802.15.4.Devices.Device.[0].Services 0×0b 0×3b “802.15.4_18” Technologies.802.15.4.Devices.Device.[0].Services.[0] 0×4d 0c 0×cb Services 0×4d 17 0×75 Services.Service.[0] 0×4b 0b 0×13 “wifi_18b43…” Services.Service.[0].ID 0×4b 0d 0×14 “998-3 Alp…” Services.Service.[0].Name 0×4c 0f 0×28 3939382d… Services.Service.[0].SSID 0×45 10 0×02 2642 Services.Service.[0].Frequency 0×40 11 0×01 1 Services.Service.[0].AutoConnect 0×40 12 0×01 1 Services.Service.[0].Favorite 0×4d 02 0×0d Services.Service.[0].Network 0×4d 03 0×0a Services.Service.[0].Network.IPv4 0×4d 14 0×07 Services.Service.[0].Network.IPv4.DHCP 0×45 15 0×04 0×0a02001e Services.Service.[0].Network.IPv4.LastAddress 0×4d 17 0×50 Services.Service.[1] 0×4b 0b 0×1a “802.15.4_18” Services.Service.[1].ID 0×4c 0d 0×10 “998-3 Alp…” Services.Service.[1].Name 0×4c 0f 0×10 3939382d… Services.Service.[1].EPANID 0×45 10 0×02 2412 Services.Service.[1].Frequency 0×40 11 0×01 1 Services.Service.[1].AutoConnect 0×40 12 0×01 1 Services.Service.[1].Favorite

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

Таблица 7 Сравнение размеров для размеров данных списков свойств Тип списка Размер в байтах Процент от размера XML XML 2199 - Двоичный 730 -66,8% TLV 450 -79,5%

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

С. Общий протокол сообщения

[00185] В дополнение к отправке отдельных записей различных размеров, данные могут передаваться в инфраструктуре с использованием общего протокола сообщения, который может включать в себя форматирование TLV. Вариант осуществления общего протокола сообщения (GMP) 1128 показан на фиг. 18. В некоторых вариантах осуществления, общий протокол сообщения (GMP) 1128 может быть использован для передачи данных в инфраструктуре. GMP 1128 может быть использован для передачи данных посредством протоколов без установления соединения (например, UDP) и/или ориентированных на соединение протоколов (например, TCP). Соответственно, GMP 1128 может гибко адаптировать информацию, которая используется в одном протоколе, игнорируя такую информацию, когда используется другой протокол. Кроме того, GMP 1226 может допускать пропуск полей, которые не используются в конкретной передаче. Данные, которые могут быть опущены из одной или более пересылок GMP 1226, как правило, указываются с использованием серых границ вокруг блоков данных. В некоторых вариантах осуществления мульти-байтовые целочисленные поля могут передаваться в прямом порядке или в обратном порядке.

i. Длина пакета

[00186] В некоторых вариантах осуществления GMP 1128 может включать в себя поле 1130 длины пакета. В некоторых вариантах осуществления, поле 1130 длины пакета содержит 2 байта. Значение поля 1130 длины пакета соответствует целому числу без знака, указывающему общую длину сообщения в байтах, исключая само поле 1130 длины пакета. Поле 1130 длины пакета может присутствовать, когда GMP 1128 передается через соединение TCP, но когда GMP 1128 передается через соединение UDP, длина сообщения может быть равна длине полезной нагрузки основного UDP пакета, за исключением поля 1130 длины пакета.

ii. Заголовок сообщения

[00187] GMP 1128 может также включать в себя заголовок 1132 сообщения независимо от того, передается ли GMP 1128 с использованием соединений TCP или UDP. В некоторых вариантах осуществления заголовок 1132 сообщения включает в себя два байта данных, расположенных в формате, показанном на фиг. 19. Как показано на фиг. 19, заголовок 1132 сообщения включает в себя поле 1156 версии. Поле 1156 версии соответствует версии GMP 1128, который используется для кодирования сообщения. Соответственно, когда GMP 1128 обновляется, новые версии GMP 1128 могут быть созданы, но каждое устройство в инфраструктуре может быть способно принимать пакет данных в любой версии GMP 1128, известной устройству. В дополнение к полю 1156 версии, сообщение 1132 заголовка может включать в себя поле 1158 S флага и D флаг 1160. S флаг 1158 представляет собой один бит, который указывает, включено ли поле Id узла-источника (обсуждается ниже) в передаваемый пакет. Аналогично, D флаг 1160 является одним битом, который указывает, включено ли поле Id узла-получателя (обсуждается ниже) в передаваемый пакет.

[00188] Заголовок 1132 сообщения также включает в себя поле 1162 типа шифрования. Поле 1162 типа шифрования включает в себя четыре бита, которые определяют, какой тип шифрования/проверки целостности применяется к сообщению, если таковые имеются. Например, 0×0 может указывать, что шифрование или проверка целостности сообщения не включены, но десятичное 0×1 может указывать, что включены шифрование AES-128-CTR с проверкой целостности сообщения HMAC-SHA-1.

[00189] Наконец, заголовок 1132 сообщения дополнительно включает в себя поле 1164 типа подписи. Поле 1164 типа подписи включает в себя четыре бита, которые определяют, какой тип цифровой подписи применяется к сообщению, если таковая имеется. Например, 0×0 может указывать, что никакая цифровая подпись не включена в сообщение, а 0×1 может указывать, что алгоритм цифровой подписи эллиптический кривой (ECDSA) с параметрами эллиптической кривой Prime256v1 включен в сообщение.

iii. Id сообщения

[00190] Со ссылкой на фиг. 18, GMP 1128 также включает в себя поле 1134 Id сообщения, которое может быть включено в передаваемое сообщение независимо от того, отправляется ли сообщение с использованием TCP или UDP. Поле 1134 Id сообщения включает в себя четыре байта, которые соответствуют целочисленному значению без знака, которое однозначно идентифицирует сообщение с точки зрения передающего узла. В некоторых вариантах осуществления узлы могут назначать увеличенные значения поля 1134 Id сообщения каждому сообщению, которые они отправляют, возвращающиеся к нулю после достижения 2³² сообщений.

iv. Id узла-источника

[00191] В некоторых вариантах осуществления GMP 1128 также может включать в себя поле 1136 Id узла-источника, которое включает в себя восемь байтов. Как упоминалось выше, поле 1136 Id узла-источника может присутствовать в сообщении, когда однобитовый S флаг 1158 в заголовке 1132 сообщения установлен в 1. В некоторых вариантах осуществления поле 1136 Id узла-источника может содержать Id 1104 интерфейса ULA 1098 или весь ULA 1098. В некоторых вариантах осуществления байты поля 1136 Id узла-источника передаются в восходящем порядке значения индекса (например, EUI[0], затем EUI[1], затем EUI[2], затем EUI[3] и т.д.).

v. ID узла-получателя

[00192] GMP 1128 может включать в себя поле 1138 Id узла-получателя, которое включает в себя восемь байт. Поле 1138 Id узла-получателя подобно полю 1136 Id узла-источника, но поле 1138 Id узла-получателя соответствует узлу-получателю сообщения. Поле 1138 Id узла-получателя может присутствовать в сообщении, когда однобитовый D флаг 1160 в заголовке 1132 сообщения установлен в 1. Также, аналогично полю 1136 Id узла-источника, в некоторых вариантах осуществления, байты поля 1138 Id узла-получателя могут передаваться в восходящем порядке значения индекса (например, EUI[0], затем EUI[1], затем EUI[2], затем EUI[3] и т.д.).

vi. Id ключа

[00193] В некоторых вариантах осуществления GMP 1128 может включать в себя поле 1140 Id ключа. В некоторых вариантах осуществления поле 1140 Id ключа включает в себя два байта. Поле 1140 Id ключа включает в себя целочисленное значение без знака, которое идентифицирует ключи шифрования/целостности сообщения, используемые для шифрования сообщения. Наличие поля 1140 Id ключа может быть определено значением поля 1162 типа шифрования заголовка 1132 сообщения. Например, в некоторых вариантах осуществления, когда значение поля 1162 типа шифрования заголовка 1132 сообщения равно 0×0, поле 1140 Id ключа может быть опущено из сообщения.

[00194] Вариант осуществления поля 1140 Id ключа представлен на фиг. 20. В показанном варианте осуществления поле 1140 Id ключа включает в себя поле 1166 типа ключа и поле 1168 номера ключа. В некоторых вариантах осуществления поле 1166 типа ключа включает в себя четыре бита. Поле 1166 типа ключа соответствует целочисленному значению без знака, которое идентифицирует тип шифрования/целостности сообщения, используемый для шифрования сообщения. Например, в некоторых вариантах осуществления, если поле 1166 типа ключа равно 0×0, то ключ инфраструктуры совместно используется всеми или большинством узлов в инфраструктуре. Однако если поле 1166 типа ключа равно 0×1, то ключ инфраструктуры совместно используется парой узлов в инфраструктуре.

[00195] Поле 1140 Id ключа также включает в себя поле 1168 номера ключа, которое включает в себя двенадцать бит, которые соответствуют целочисленному значению без знака, которое идентифицирует конкретный ключ, используемый для шифрования сообщения из набора доступных ключей, либо совместно используемый, либо инфраструктурный ключи.

vii. Длина полезной нагрузки

[00196] В некоторых вариантах осуществления GMP 1128 может включать в себя поле 1142 длины полезной нагрузки. Поле 1142 длины полезной нагрузки, когда оно присутствует, может включать в себя два байта. Поле 1142 длины полезной нагрузки соответствует целочисленному значению без знака, которое указывает размер в байтах поля полезной нагрузки приложения. Поле 1142 длины полезной нагрузки может присутствовать, когда сообщение зашифровано с использованием алгоритма, который использует заполнение сообщения, как описано ниже по отношению к полю заполнения.

viii. Вектор инициализации

[00197] В некоторых вариантах осуществления GMP 1128 также может включать в себя поле 1144 вектора инициализации (IV). Поле IV 1144, если оно присутствует, содержит переменное число байт данных. Поле IV 1144 содержит криптографические значения IV, используемые для шифрования сообщения. Поле IV 1144 может быть использовано, когда сообщение зашифровано с помощью алгоритма, который использует IV. Длина поля IV 1144 может быть выведена из типа шифрования, используемого для шифрования сообщения.

ix. Полезная нагрузка приложения

[00198] GMP 1128 включает в себя поле 1146 полезной нагрузки приложения. Поле 1146 полезной нагрузки приложения включает в себя переменное число байт. Поле 1146 полезной нагрузки приложения включает в себя данные приложения, передаваемые в сообщении. Длина поля 1146 полезной нагрузки приложения может быть определена из поля 1142 длины полезной нагрузки, когда оно присутствует. Если поле 1142 длины полезной нагрузки отсутствует, длина поля 1146 полезной нагрузки приложения может быть определена путем вычитания длины всех других полей из общей длины сообщения и/или значений данных, включенных в поле 1146 полезной нагрузки приложения (например, TLV).

[00199] Вариант осуществления поля 1146 полезной нагрузки приложения показан на фиг. 21. Поле 1146 полезной нагрузки приложения включает в себя поле APVersion 1170. В некоторых вариантах осуществления поле APVersion 1170 включает в себя восемь бит, которые указывают, какая версия программного обеспечения инфраструктуры поддерживается передающим устройством. Поле 1146 полезной нагрузки приложения также включает в себя поле 1172 типа сообщения. Поле 1172 типа сообщения может включать в себя восемь бит, которые соответствуют коду операции сообщения, который указывает тип сообщения, передаваемого в профиле. Например, в профиле обновления программного обеспечения, 0×00 может указывать, что посланное сообщение является оповещением образа. Поле 1146 полезной нагрузки приложения дополнительно включает в себя поле 1174 Id обмена, которое включает в себя шестнадцать бит, что соответствует идентификатору обмена, который является уникальным для передающего узла для транзакции.

[00200] Кроме того, поле 1146 полезной нагрузки приложения включает в себя поле 1176 Id профиля. Поле 1176 Id профиля указывает “тему обсуждения”, используемую для обозначения типа передачи в сообщении. Поле 1176 Id профиля может соответствовать одному или более профилям, которые устройство может передавать. Например, поле 1176 Id профиля может указывать, что сообщение относится к базовому профилю, профилю обновления программного обеспечения, профилю обновления состояния, профилю управления данными, профилю климата и комфорта, профилю безопасности, профилю надежности и/или другим подходящим типам профиля. Каждое устройство в инфраструктуре может включать в себя список профилей, которые релевантны для устройства и в которых устройство способно “участвовать в дискуссии”. Например, многие устройства в инфраструктуре могут включать в себя базовый профиль, профиль обновления программного обеспечения, профиль обновления состояния и профиль управления данными, но только некоторые устройства будут включать в себя профиль климата и комфорта. Поле 1170 APVersion, поле 1172 типа сообщения, поле Id обмена, поле 1176 Id профиля и поле 1176 специфического для профиля заголовка, если присутствуют, могут упоминаться в комбинации как “заголовок приложения”.

[00201] В некоторых вариантах осуществления указание Id профиля посредством поля 1176 Id профиля может предоставить достаточную информацию, чтобы обеспечить схему для данных, передаваемых для профиля. Однако в некоторых вариантах осуществления дополнительная информация может быть использована для определения дальнейших указаний для декодирования поля 1146 полезной нагрузки приложения. В таких вариантах осуществления поле 1146 полезной нагрузки приложения может включать в себя поле 1178 специфического для профиля заголовка. Некоторые профили могут не использовать поле 1178 специфического для профиля заголовка, тем самым позволяя полю 1146 полезной нагрузки приложения опускать поле 1178 специфического для профиля заголовка. После определения схемы из поля 1176 Id профиля и/или поля 1178 специфического для профиля заголовка, данные могут кодироваться/декодироваться в суб-поле 1180 полезной нагрузки приложения. Суб-поле 1180 полезной нагрузки приложения включает в себя базовые данные приложения, подлежащие передаче между устройствами и/или службами, которые сохраняются, ретранслируются и/или на которые оказывается воздействие посредством принимающего устройства/службы.

x. Проверка целостности сообщений

[00202] Со ссылкой на фиг. 18, в некоторых вариантах осуществления GMP 1128 может также включать в себя поле 1148 проверки целостности сообщения (MIC). Поле 1148 MIC, если присутствует, включает в себя переменную длину в байтах данных, содержащих MIC для сообщения. Длина и порядок байт поля зависят от используемого алгоритма проверки целостности. Например, если сообщение проверяется на целостность сообщения, используя HMAC-SHA-1, поле 1148 MIC включает в себя двадцать байт в обратном порядке. Кроме того, наличие поля 1148 MIC может быть определено тем, включает ли в себя поле 1162 типа шифрования заголовка 1132 сообщения значение, отличное от 0×0.

xi. Заполнение

[00203] GMP 1128 может также включать в себя поле 1150 заполнения. Поле 1150 заполнения, когда оно присутствует, включает в себя последовательность байт, представляющих собой криптографическое заполнение, добавляемое к сообщению, чтобы сделать зашифрованную часть сообщения делимой нацело на размер блока шифрования. Наличие поля 1150 заполнения может быть определено тем, использует ли тип алгоритма шифрования (например, блочные шифры в режиме сцепления блоков шифра), указанный полем 1162 типа шифрования в заголовке 1132 сообщения, криптографическое заполнение.

xii. Шифрование

[00204] Поле 1146 полезной нагрузки приложения, поле 1148 MIC и поле 1150 заполнения вместе образуют блок 1152 шифрования. Блок 1152 шифрования включает в себя части сообщения, которые зашифрованы, когда поле 1162 типа шифрования в заголовке 1132 сообщения имеет любое значение кроме 0×0.

xiii. Подпись сообщения

[00205] GMP 1128 может также включать в себя поле 1154 подписи сообщения. Поле 1154 подписи сообщения, когда оно присутствует, включает в себя последовательность байт переменной длины, которая содержит криптографическую подпись сообщения. Длина и содержание поля подписи сообщения могут быть определены в соответствии с используемым типом алгоритма подписи и указаны полем 1164 типа подписи заголовка 1132 сообщения. Например, если используемым алгоритмом является ECDSA, использующий параметры эллиптической кривой Prime256v1, то поле 1154 подписи сообщения может включать в себя два 32-битных целых числа, закодированных в прямом порядке.

Профили и протоколы

[00206] Как описано выше, одна или более схем информации могут быть выбраны на основе общего обсуждения желательного типа для сообщения. Профиль может состоять из одной или нескольких схем. Например, один набор схем информации может быть использован для кодирования/декодирования данных в суб-поле 1180 полезной нагрузки приложения, когда один профиль указан в поле 1176 Id профиля полезной нагрузки 1146 приложения. Однако другой набор схем может быть использован для кодирования/декодирования данных суб-поля 1180 полезной нагрузки приложения, когда другой профиль указан в поле 1176 Id профиля полезной нагрузки 1146 приложения.

[00207] Дополнительно, в некоторых вариантах осуществления, каждое устройство может включать в себя набор методов, используемых для обработки профилей. Например, базовый протокол может включать в себя следующие профили: GetProfiles, GetSchema, GetSchemas, GetProperty, GetProperties, SetProperty, SetProperties, RemoveProperty, RemoveProperties, RequestEcho, NotifyPropertyChanged и/или NotifyPropertiesChanged. Метод GetProfiles может возвращать массив профилей, поддерживаемых запрошенным узлом. Методы GetSchema и GetSchemas могут соответственно возвращать одну или все схемы для конкретного профиля. GetProperty и GetProperties могут, соответственно, возвращать значение или все пары значений для схемы профиля. SetPropertiy и SetProperties могут, соответственно, устанавливать одно или несколько значений для схемы профиля. RemoveProperty и RemoveProperties могут, соответственно, пытаться удалить одно или несколько значений из схемы профиля. RequestEcho может отправить произвольную полезную нагрузку данных к указанному узлу, которую этот узел возвращает неизмененной. NotifyPropertyChange и NotifyPropertiesChanged могут, соответственно, выдавать уведомление, если одна/несколько пар значений изменились для схемы профиля.

[00208] Для помощи в понимании профилей и схем, неисключительной список профилей и схем приведен ниже в иллюстративных целях.

А. Отчетность о состоянии

[00209] Схема отчетности о состоянии представлена как кадр 1182 отчетности о состоянии на фиг. 22. Схема отчетности о состоянии может быть отдельным профилем или может быть включена в один или несколько профилей (например, базовый профиль). В некоторых вариантах осуществления кадр 1182 отчетности о состоянии включает в себя поле 1184 профиля, поле 1186 кода состояния, поле 1188 следующего состояния и может включать в себя поле 1190 дополнительной информации о состоянии.

i. Поле профиля

[00210] В некоторых вариантах осуществления поле 1184 профиля включает в себя четыре байта данных, которые определяют профиль, при котором информация в представленном отчете о состоянии должна быть интерпретирована. Вариант осуществления поля 1184 профиля показан на фиг. 23 с двумя суб-полями. В показанном варианте осуществления поле 1184 профиля включает в себя суб-поле 1192 Id профиля, которое включает в себя шестнадцать бит, которое соответствует специфическому для поставщика идентификатору для профиля, под которым определено значение поля 1186 кода состояния. Поле 1184 профиля может также включать в себя суб-поле 1194 Id поставщика, которое включает в себя шестнадцать бит, которое идентифицирует поставщика, обеспечивающего профиль, идентифицированный в суб-поле 1192 Id профиля.

ii. Код состояния

[00211] В некоторых вариантах осуществления поле 1186 кода состояния включает в себя шестнадцать бит, которые кодируют состояние, о котором сообщается. Значения в поле 1186 кода состояния интерпретируются по отношению к значениям, закодированным в суб-поле 1192 Id поставщика и суб-поле 1194 Id профиля, представленным в поле 1184 профиля. Кроме того, в некоторых вариантах осуществления пространство кодов состояния может быть разделено на четыре группы, как показано ниже в таблице 8.

Таблица 8 Таблица диапазонов кодов состояния Диапазон Наименование Описание 0×0000…0×0010 Успешно Запрос был успешно обработан 0×0011…0×0020 Клиентская ошибка Ошибка возникла или могла возникнуть на клиентской стороне обмена клиент-сервер. Например, клиент сделал плохо сформированный запрос. 0×0021…0×0030 Серверная ошибка Ошибка возникла или могла возникнуть на серверной стороне обмена клиент-сервер. Например, сервер не смог обработать ошибку клиентского запроса к операционной системе. 0×0031…0×0040 Продолжить/перенаправить Будет использована дополнительная обработка, такая как перенаправление, чтобы завершить конкретный обмен, но еще без ошибки.

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

iii. Следующее состояние

[00212] В некоторых вариантах осуществления поле 1188 кода следующего состояния включает в себя восемь бит. Поле 1188 кода следующего состояния указывает, имеется ли информация о следующем состоянии после сообщенного в текущее время состояния. Если информации о следующем состоянии должна быть включена, то поле 1188 кода следующего состояния указывает, какой тип информации о состоянии должен быть включен. В некоторых вариантах осуществления поле 1188 кода следующего состояния может быть включено всегда, таким образом, потенциально увеличивая размер сообщения. Однако, предоставляя возможность сцепления информации о состоянии вместе, потенциал для общего сокращения пересылаемых данных может быть снижен. Если поле 1186 следующего состояния равно 0×00, то поле 1190 информации о следующем состоянии не включено. Однако ненулевые значения могут указывать, что данные могут быть включены, и указывать форму, в которой данные включены (например, в пакете TLV).

iv. Дополнительная информация о состоянии

[00213] Когда поле 1188 кода следующего состояния не является нулевым, то поле 1190 дополнительной информации о состоянии включено в сообщение. Если присутствует, то поле элемента состояния может содержать состояние в такой форме, которая может быть определена значением поля типа предшествующего состояния (например, формат TLV).

В. Обновление программного обеспечения

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

i. Общие заголовки приложения для полезной нагрузки приложения

[00215] Для того, чтобы распознаваться и обрабатываться надлежащим образом, кадры профиля обновления программного обеспечения могут быть идентифицированы в поле 1146 полезной нагрузки приложения GMP 1128. В некоторых вариантах осуществления, все кадры профиля обновления программного обеспечения могут использовать общий Id 1176 профиля, такой как 0×0000000С. Кроме того, кадры профиля обновления программного обеспечения могут включать в себя поле 1172 типа сообщения, которое указывает дополнительную информацию и может выбираться в соответствии с таблицей 9 ниже и типом отправляемого сообщения.

Таблица 9 Типы сообщения профиля обновления программного обеспечения Тип Сообщение 0×00 Оповещение образа 0×01 Запрос образа 0×02 Ответ на запрос образа 0×03 Уведомление о загрузке 0×04 Ответ на уведомление 0×05 Уведомление об обновлении 0×06…0×ff Зарезервировано

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

ii. Протокольная последовательность

[00216] Фиг. 24 иллюстрирует вариант осуществления протокольной последовательности 1196 для обновления программного обеспечения между клиентом 1198 обновления программного обеспечения и сервером 1200 обновления программного обеспечения. В некоторых вариантах осуществления любое устройство в инфраструктуре может быть клиентом 1198 обновления программного обеспечения или сервером 1200 обновления программного обеспечения. Некоторые варианты осуществления протокольной последовательности 1196 могут включать в себя дополнительные этапы, такие как те, которые показаны пунктирными линиями, которые могут быть опущены в некоторых передачах обновления программного обеспечения.

1. Обнаружение службы

[00217] В некоторых вариантах осуществления протокольная последовательность 1196 начинается с того, что сервер профиля обновления программного обеспечения оповещает о наличии обновления. Однако в других вариантах осуществления, например, показанном варианте осуществления, протокольная последовательность 1196 начинается с обнаружения 1202 службы, как описано выше.

2. Оповещение образа

[00218] В некоторых вариантах осуществления сообщение 1204 оповещения образа может передаваться сервером 1200 обновления программного обеспечения посредством многоадресной передачи или одноадресной передачи. Сообщение 1204 оповещения образа информирует устройства в инфраструктуре, что сервер 1200 имеет обновления программного обеспечения, чтобы предоставлять их. Если обновление применимо к клиенту 1198, после приема сообщения 1204 оповещения образа, клиент 1198 обновления программного обеспечения отвечает сообщением 1206 запроса образа. В некоторых вариантах осуществления сообщение 1204 оповещения образа может не включаться в протокольную последовательность 1196. Вместо этого, в таких вариантах осуществления, клиент 1198 обновления программного обеспечения может использовать график опроса, чтобы определять, когда следует послать сообщение 1206 запроса образа.

3. Запрос образа

[00219] В некоторых вариантах осуществления сообщение 1206 запроса образа может передаваться путем одноадресной передачи от клиента 1198 обновления программного обеспечения либо в ответ на сообщение 1204 оповещения образа, либо в соответствии с графиком опроса, как описано выше. Сообщение 1206 запроса образа включает в себя информацию от клиента 1198 о самом себе. Вариант осуществления кадра сообщения 1206 запроса образа показан на фиг. 25. Как показано на фиг. 25, некоторые варианты осуществления сообщения 1206 запроса образа могут включать в себя поле 1218 управления кадра, поле 1220 спецификации продукта, поле 1222 данных, специфических для поставщика, поле 1224 спецификации версии, поле 1226 спецификации места, поле 1228 поддерживаемого типа целостности и поле 1230 поддерживаемых схем обновления.

а. Управление кадра

[00220] Поле 1218 управления кадра включает в себя 1 байт и указывает различную информацию о сообщении 1204 запроса образа. Пример поля 128 управления кадра показан на фиг. 26. Как показано, поле 1218 управления кадра может включать три суб-поля: флаг 1232, специфический для поставщика, флаг 1234 спецификации места и зарезервированное поле S3. Флаг 1232, специфический для поставщика, указывает, включено ли поле 1222 специфических для поставщика данных в сообщение запроса образа. Например, когда флаг 1232, специфический для поставщика, равен 0, то поле 1222 специфических для поставщика данных может отсутствовать в сообщении запроса образа, а если флаг 1232, специфический для поставщика, равен 1, то поле 1222 специфических для поставщика данных может присутствовать в сообщении запроса образа. Аналогичным образом, значение 1 во флаге 1234 спецификации места указывает, что поле 1226 спецификации места присутствует в сообщении запроса образа, а значение 0 указывает, что поле 1226 спецификации места не присутствует в сообщении запроса образа.

b. Спецификация продукта

[00221] Поле 1220 спецификации продукта является 6-байтовым полем. Вариант осуществления поля 1220 спецификации продукта показан на фиг. 27. Как показано, поле 1220 спецификации продукта может включать в себя три суб-поля: поле 1236 Id поставщика, поле 1238 Id продукта и поле 1240 модификации продукта. Поле 1236 Id поставщика включает в себя шестнадцать бит, которые указывают поставщика для клиента 1198 обновления программного обеспечения. Поле 1238 Id продукта включает в себя шестнадцать бит, которые указывают продукт устройства, которое посылает сообщение 1206 запроса образа в качестве клиента 1198 обновления программного обеспечения. Поле 1240 модификации продукта включает в себя шестнадцать бит, которые указывают атрибут модификации клиента 1198 обновления программного обеспечения.

с. Данные, специфические для поставщика

[00222] Поле 1222 данных, специфических для поставщика, если оно присутствует в сообщении 1206 запроса образа, имеет длину переменного числа байт. Наличие поля 1222 данных, специфических для поставщика, может быть определено из специфического для поставщика флага 1232 поля 1218 управления кадра. Если присутствует, то поле 1222 специфических для поставщика данных кодирует специфическую для поставщика информацию о клиенте 1198 обновления программного обеспечения в формате TLV, как описано выше.

d. Спецификация версии

[00223] Вариант осуществления поля 1223 спецификации версии показан на фиг. 28. Поле 1224 спецификации версии включает в переменное число байт, подразделенных на два суб-поля: поле 1242 длины версии и поле 1244 строки версии. Поле 1242 длины версии включает в себя восемь бит, которые указывают длину поля 1244 строки версии. Поле 1244 строки версии является переменным по длине и определяется полем 1242 длины версии. В некоторых вариантах осуществления поле 1244 строки версии может быть ограничено сверху 255 UTF-8 символами по длине. Значение, кодируемое в поле 1244 строки версии, указывает атрибут версии программного обеспечения для клиента 1198 обновления программного обеспечения.

е. Спецификация места

[00224] В некоторых вариантах осуществления поле 1226 спецификации места может быть включено в сообщение 1206 запроса образа, когда флаг 1234 спецификации места поля 1218 управления кадра равен 1. Вариант осуществления поля 1226 спецификации места показан на фиг. 29. Показанный вариант осуществления поля 1226 поля спецификации места включает в себя переменное число байт, разделенных на два суб-поля: поле 1246 длины строки места и поле 1248 строки места. Поле 1246 длины строки места включает в себя восемь бит, которые указывают длину поля 1248 строки места. Поле 1248 строки места поля 1226 спецификации места может быть переменной длины и может содержать строку UTF-8 символов, кодирующих описание места на основе кодов места интерфейса портативной операционной системы (POSIX). Стандартный формат для кодов места POSIX имеет вид [language[_territory][.codeset][@modifier]]. Например, представление POSIX для австралийского английского имеет вид en_AU.UTF8.

f. Поддерживаемые типы целостности

[00225] Вариант осуществления поля 1228 типов целостности показан на фиг. 30. Поле 1228 поддерживаемых типов целостности включает в себя от двух до четырех байт данных, разделенных на два суб-поля: поле 1250 длины списка типов и поле 1252 списка типов целостности. Поле 1250 длины списка типов включает в себя восемь бит, которые указывают длину в байтах поля 1252 списка типов целостности. Поле 1252 списка типов целостности указывает значение атрибута типа целостности обновления программного обеспечения клиента 1198 обновления программного обеспечения. В некоторых вариантах осуществления тип целостности может быть получен из таблицы 10 ниже.

Таблица 10 Примерные типы целостности Значение Тип целостности 0×00 SHA-160 0×01 SHA-256 0×02 SHA-512

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

g. Поддерживаемые схемы обновления

[00226] Вариант осуществления поля 1230 поддерживаемых схем показан на фиг. 31. Поле 1230 поддерживаемых схем включает в себя переменное число байт, разделенных на два суб-поля: поле 1254 длины списка схем и поле 1256 списка схем обновления. Поле 1254 длины списка схем включает в себя восемь бит, которые указывают длину поля списка схем обновления в байтах. Поле 1256 списка схем обновления поля 1222 поддерживаемых схем обновления имеет переменную длину, определяемую полем 1254 длины списка схем. Поле 1256 списка схем обновления представляет атрибуты схем обновления профиля обновления программного обеспечения клиента 1198 обновления программного обеспечения. Вариант осуществления примерных значений показан в таблице 11 ниже.

Таблица 11 Примерные схемы обновления Значение Схема обновления 0×00 HTTP 0×01 HTTPS 0×02 SFTP 0×03 Специфический для инфраструктуры протокол передачи файлов (например, групповой пересылки данных, обсужденный ниже)

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

4. Ответ на запрос образа

[00227] Со ссылкой на фиг. 18, после того как сервер 1200 обновления программного обеспечения получает сообщение 1206 запроса образа от клиента 1198 обновления программного обеспечения, сервер 1200 обновления программного обеспечения отвечает ответом 1208 на запрос образа. Ответ 1208 на запрос образа включает в себя либо информацию, детализирующую, почему образ обновления не доступен для клиента 1198 обновления программного обеспечения, либо информацию о доступном обновлении образа, чтобы позволить клиенту 1198 обновления программного обеспечения загрузить и установить обновление.

[00228] Вариант осуществления кадра ответа 1208 на запрос образа показан на фиг. 32. Как показано, ответ 1208 на запрос образа включает в себя пять возможных суб-полей: поле 1258 состояния запроса, поле 1260 унифицированного идентификатора ресурса (URI), поле 1262 спецификации целостности, поле 1264 схемы обновления и поле 1266 опций обновления.

а. Состояние запроса

[00229] Поле 1258 состояния запроса включает в себя переменное число байт и содержит отформатированные данные отчетности о состоянии, как описано выше со ссылкой на отчетность о состоянии. Например, поле 1258 состояния запроса может включать в себя коды состояния ответа на запрос образа, такие, как показаны ниже в таблице 12.

Таблица 12 Примерные коды состояния ответа на запрос образа Профиль Код Описание 0×00000000 0×0000 Сервер обработал сообщение 1206 запроса образа и имеет обновление для клиента 1198 обновления программного обеспечения. 0×0000000С 0×0001 Сервер обработал сообщение 1206 запроса образа, но сервер не имеет обновления для клиента 1198 обновления программного обеспечения. 0×00000000 0×0010 Сервер не мог обработать запрос из-за ненадлежащей формы запроса. 0×00000000 0×0020 Сервер не мог обработать запрос ввиду внутренней ошибки.

b. URI

[00230] Поле 1260 URI включает в себя переменное число байт. Наличие поля 1260 URI может быть определено полем 1258 состояния запроса. Если поле 1258 состояния запроса указывает, что доступно обновление, поле 1260 URI может быть включено. Вариант осуществления поля 1260 URI показан на фиг. 33. Поле 1260 URI включает в себя два суб-поля: поле 1268 длины URI и поле 1270 строки URI. Поле 1268 длины URI включает в себя шестнадцать бит, которые указывают длину поля 1270 строки URI в UTF-8 символах. Поле 1270 строки URI указывает атрибут URI представленного обновления образа программного обеспечения, так что клиент 1198 обновления программного обеспечения может быть в состоянии найти, загрузить и установить обновление образа программного обеспечения, когда оно присутствует.

c. Спецификация целостности

[00231] Поле 1262 спецификации целостности может иметь переменную длину и присутствует, когда поле 1258 состояния запроса указывает, что доступно обновление от сервера 1198 обновления программного обеспечения для клиента 1198 обновления программного обеспечения. Вариант осуществления поля 1262 спецификации целостности показан на фиг. 34. Как показано, поле 1262 спецификации целостности включает в себя два суб-поля: поле 1272 типа целостности и поле 1274 значения целостности. Поле 1272 типа целостности включает в себя восемь бит, которые указывают атрибут типа целостности для обновления образа программного обеспечения, и может заполняться с использованием списка, аналогичного показанному в таблице 10 выше. Поле 1274 значения целостности включает в себя значение целостности, которое используется для верификации, что сообщение обновления образа сохранило целостность в процессе передачи.

d. Схема обновления

[00232] Поле 1264 схемы обновления включает в себя восемь бит и присутствует, когда поле 1258 состояния запроса указывает, что доступно обновление с сервера 1198 обновления программного обеспечения для клиента 1198 обновления программного обеспечения. Если присутствует, поле 1264 схемы обновления указывает атрибут схемы для обновления образа программного обеспечения, представленного серверу 1198 обновления программного обеспечения.

е. Опции обновления

[00233] Поле 1266 опций обновления включает в себя восемь бит и присутствует, когда поле 1258 состояния запроса указывает, что обновление доступно от сервера 1198 обновления программного обеспечения для клиента 1198 обновления программного обеспечения. Поле 1266 опций обновления может быть подразделено, как показано на фиг. 35. Как показано, поле 1266 опций обновления включает в себя четыре суб-поля: поле 1276 приоритета обновления, поле 1278 условия обновления, флаг 1280 состояния отчета и зарезервированное поле 1282. В некоторых вариантах осуществления поле 1276 приоритета обновления включает в себя два бита. Поле 1276 приоритета обновления указывает атрибут приоритета обновления и может быть определено с использованием значений, таких как те, которые показаны в таблице 13 ниже.

Таблица 13 Примерные значения приоритета обновления Значение Описание 00 Нормальное – обновление в течение периода низкого сетевого трафика 01 Критическое – обновление настолько срочное, насколько возможно

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

Таблица 14 Примерные условия обновления Значение Описание 0 Обновить без условий. 1 Обновить, если версия программного обеспечения, исполняемая на клиенте обновления программного обеспечения, не согласована с версией обновления. 2 Обновить, если версия программного обеспечения, исполняемая на клиенте обновления программного обеспечения, старше, чем версия обновления. 3 Обновить, если пользователь выбирает обновление с помощью пользовательского интерфейса.

Флаг 1280 состояния отчета является одним битом, который указывает, должен ли клиент 1198 обновления программного обеспечения отвечать сообщением 1210 уведомления о загрузке. Если флаг 1280 состояния отчета установлен в 1, то сервер 1198 обновления программного обеспечения запрашивает, чтобы сообщение 1210 уведомления о загрузке было передано после того, как обновление программного обеспечения загружено клиентом 200 обновления программного обеспечения.

[00234] Если ответ 1208 на запрос образа указывает, что доступно обновление, клиент 1198 обновления программного обеспечения загружает 1210 обновление с использованием информации, содержащейся в ответе 1208 на запрос образа, во время, указанное в ответе 1208 на запрос образа.

5. Уведомление о загрузке

[00235] После того как загрузка 1210 обновления успешно завершена или не удалась, и значение флага 1280 состояния отчета равно 1, клиент 1198 обновления программного обеспечения может ответить сообщением 1212 уведомления о загрузке. Сообщение 1212 уведомления о загрузке может быть отформатировано в соответствии с форматом отчетности о состоянии, обсужденным выше. Пример кодов состояния, используемых в сообщении 1212 уведомления о загрузке, показан в таблице 15 ниже.

Таблица 15 Примерные коды состояния уведомления о загрузке Профиль Код Описание 0×00000000 0×0000 Загрузка завершена, и целостность верифицирована. 0×0000000С 0×0020 Загрузка не могла быть завершена из-за ошибочных инструкций загрузки. 0×0000000С 0×0021 Сообщение 1208 ответа на запрос образа выглядит корректным, но верификация загрузки или целостности безуспешна. 0×0000000С 0×0022 Целостность загрузки не могла быть верифицирована.

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

6. Ответ на уведомление

[00236] Сервер 1200 обновления программного обеспечения может ответить сообщением 1214 ответа на уведомление в ответ на сообщение 1212 уведомления о загрузке или сообщение 1216 уведомления об обновлении. Сообщение 1214 ответа на уведомление может включать в себя формат отчетности о состоянии, как описано выше. Например, сообщение 1214 ответа на уведомление может включать в себя коды состояния, перечисленные в таблице 16 ниже.

Таблица 16 Примерные коды состояния ответа на уведомление Профиль Код Описание 0×00000000 0×0030 Продолжить – уведомление подтверждено, но обновление не завершено, так что сообщение 1214 уведомления о загрузке принято, а сообщение 1216 уведомления об обновлении нет. 0×00000000 0×0000 Успешно – уведомление подтверждено, и обновление завершено. 0×0000000С 0×0023 Прервать – уведомление подтверждено, но сервер не может продолжить обновление. 0×0000000С 0×0031 Повторить запрос - уведомление подтверждено, и клиенту 1198 обновления программного обеспечения предписывается повторная попытка обновления путем посылки другого сообщения 1206 запроса образа.

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

7. Уведомление об обновлении

[00237] После того, как обновление успешно завершено или не удалось, и значение флага 1280 состояния отчета равно 1, клиент 1198 обновления программного обеспечения может ответить сообщением 1216 уведомления об обновлении. Сообщение 1216 уведомления об обновлении может использовать формат отчетности о состоянии, описанный выше. Например, сообщение 1216 уведомления об обновлении может включать в себя коды состояния, перечисленные в таблице 17 ниже.

Таблица 17 Примерные коды состояния уведомления об обновлении Профиль Код Описание 0×00000000 0×0000 Успешно – обновление завершено. 0×0000000С 0×0010 Клиентская ошибка – обновление безуспешно вследствие проблемы в клиенте 1198 обновления программного обеспечения.

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

С. Протокол управления данными

[00238] Управление данными может быть включено в общий профиль (например, базовый профиль), используемый в различных электронных устройствах в инфраструктуре, или может быть обозначено как отдельный профиль. В любом случае, протокол управления устройством (DMP) может быть использован для узлов, чтобы выполнять просмотр, совместное использование и/или обновление информации, имеющейся в узле. Последовательность 1284, используемая в DMP, показана на фиг. 36. Последовательность 1284 иллюстрирует просматривающий узел 1286, который запрашивает для просмотра и/или изменения резидентные данные просматриваемого узла 1288. Кроме того, просматривающий узел 1286 может запросить просмотр резидентных данных с использованием одной из нескольких опций просмотра, таких как запрос моментального снимка, запрос наблюдения, чтобы просмотр продолжался в течение некоторого периода времени, или другой подходящий тип просмотра. Каждое сообщение соответствует формату полезной нагрузки 1146 приложения, описанному со ссылкой на фиг. 21. Например, каждое сообщение содержит Id 1176 профиля, который соответствует профилю управления данными и/или релевантному базовому профилю, такому как 0x235A0000. Каждое сообщение также содержит тип 1172 сообщения. Тип 1172 сообщения может быть использован для определения различных факторов, относящихся к диалогу, таких как тип просмотра для просмотра. Например, в некоторых вариантах осуществления, поле 1172 типа сообщения может кодироваться/декодироваться в соответствии с таблицей 18 ниже.

Таблица 18 Примерные типы сообщения профиля обновления программного обеспечения Тип Сообщение 0×00 Запрос моментального снимка 0×01 Запрос наблюдения 0×02 Запрос периодического обновления 0×03 Обновление регенерации 0×04 Обновление отмены просмотра 0×05 Ответ просмотра 0×06 Явный запрос обновления 0×07 Запрос обновления просмотра 0×08 Ответ обновления

i. Запрос просмотра

[00239] Хотя сообщение 1290 запроса просмотра запрашивает просмотр резидентных данных узла, тип запроса может быть определен посредством поля 1172 типа сообщения, как описано выше. Соответственно каждый тип запроса может включать в себя отличающийся кадр запроса просмотра.

1. Запрос моментального снимка

[00240] Запрос моментального снимка может быть отправлен просматривающим узлом 1286, когда просматривающему узлу 1286 желателен моментальный просмотр резидентных данных узла на просматриваемом узле 1288 без запроса будущих обновлений. Вариант осуществления кадра 1292 запроса моментального снимка иллюстрируется на фиг. 37.

[00241] Как показано на фиг. 37, кадр 1292 запроса моментального снимка может быть переменной длины и может включать в себя три поля: поле 1294 дескриптора просмотра, поле 1296 списка длины путей и поле 1298 списка путей. Поле 1294 дескриптора просмотра может включать в себя два бита, которые обеспечивают “дескриптор”, чтобы идентифицировать запрашиваемый просмотр. В некоторых вариантах осуществления, поле 1294 дескриптора просмотра заполняется с использованием случайного 16-битного числа или 16-битного порядкового номера вместе с проверкой уникальности, выполняемой на просматривающем узле 1286, когда запрос сформирован. Поле 1296 длины списка путей включает в себя два байта, которые указывают длину поля 1298 списка путей. Поле 1298 списка путей имеет переменную длину и указывается значением поля 1296 длины списка путей. Значение поля 1298 списка путей указывает путь схемы для узлов.

[00242] Путь схемы представляет собой компактное описание для элемента данных или контейнера, который является частью схемы, резидентной на узлах. Например, на фиг. 38 приведен пример схемы 1300 профиля. В показанной схеме 1300 профиля, путь к элементу 1302 данных может быть записан как “Нечто:велосипед:гора” в двоичном формате. Двоичный формат пути может быть представлен как двоичный формат 1304 профиля, как показано на фиг. 39. Двоичный формат 1304 профиля включает в себя два суб-поля: поле 1306 идентификатора профиля и поле 1308 данных TLV. Поле 1306 идентификатора профиля идентифицирует профиль, на который ссылаются (например, профиль Foo (“нечто”, метасинтаксическая переменная)). Поле 1308 данных TLV содержит информацию о маршруте. Как обсуждалось ранее, данные TLV включают в себя поле тега, которое включает в себя информацию о вложенных данных. Значения поля тега, используемые для ссылки на профиль “нечто” на фиг. 38, могут быть аналогичны значениям, перечисленным в таблице 19.

Таблица 19 Примерные значения тегов для профиля “Нечто” Имя Тег Животное 0×4301 Рыба 0×4302 Дичь 0×4303 Среда 0×43004 Размер 0×4305 Велосипед 0×4306 Дорога 0×4307 Горы 0×4308 Трек 0×4309 Число передач 0×430А Вес 0×430В

Используя таблицу 19 и профиль “нечто” на фиг. 38, двоичная строка в формате TLV, представляющая путь “Нечто:велосипед:гора” может быть представлена, как показано в таблице 20 ниже.

Таблица 20 Примерный список двоичного тега для пути схемы ID профиля Тег и длина (TL) “велосипед” “горы” CD:AB:00:00 0D:02 06:43 08:43

Если просматривающий узел 1286 желает получить весь набор данных, определенный в схеме профиля (например, схеме профиля “нечто” на фиг. 39), то сообщение 1290 запроса просмотра может запрашивать элемент “нуль” (например, 0×0D00 TL и пустую длину, ссылающуюся на контейнер).

2. Запрос наблюдения

[00243] Если просматривающий узел 1286 желает больше, чем моментальный снимок, просматривающий узел 1286 может запрашивать запрос наблюдения. Запрос наблюдения запрашивает у просматриваемого узла 1288 послать обновления, когда вносятся изменения в данные, представляющие интерес, в просматриваемом узле 1288, так что просматривающий узел 1286 может поддерживать синхронизированный список данных. Кадр запроса наблюдения может иметь формат, иной, чем формат запроса моментального снимка по фиг. 37. Вариант осуществления кадра 1310 запроса наблюдения иллюстрируется на фиг. 40. Кадр 1310 запроса наблюдения включает в себя четыре поля: поле 1312 дескриптора просмотра, поле 1314 длины списка путей, поле 1316 списка путей и поле 1318 счета изменений. Поле 1312 дескриптора просмотра, поле 1314 длины списка путей и поле списка путей могут быть соответственно отформатированы подобно полю 1294 дескриптора просмотра, полю 1296 длины списка путей и полю 1298 списка путей запроса моментального снимка согласно фиг. 37. Дополнительное поле, поле 1318 счета изменений, указывает порог числа изменений для запрашиваемых данных, с которым обновление посылается к просматривающему узлу 1286. В некоторых вариантах осуществления, если значение поля 1318 счета изменений равно 0, то просматриваемый узел 1288 может сам определять, когда посылать обновление. Если значение поля 1318 счета изменений не равно нулю, то после числа изменений, равного этому значению, обновление посылается на просматривающий узел 1286.

3. Запрос периодического обновления

[00244] Третий тип просмотра может также запрашиваться просматривающим узлом 1286. Этот третий тип просмотра упоминается как периодическое обновление. Периодическое обновление включает в себя просмотр моментального снимка, а также периодические обновления. Как можно понять, запрос периодического обновления может быть аналогичен запросу моментального снимка с дополнительной информацией, определяющей период обновления. Например, вариант осуществления кадра 1320 запроса периодического обновления показан на фиг. 41. Кадр 1320 запроса периодического обновления включает в себя четыре поля: поле 1322 дескриптора просмотра, поле 1324 длины списка путей, поле 1326 списка путей и поле 1328 периода обновления. Поле 1322 дескриптора просмотра, поле 1324 длины списка путей и поле 1326 списка путей могут быть отформатированы подобно соответствующим им полям в кадре 1292 запроса моментального снимка. Поле 1328 периода обновления имеет четыре байта в длину и содержит значение, которое соответствует периоду времени, проходящему между обновлениями, в соответствующих единицах времени (например, в секундах).

4. Запрос регенерации

[00245] Когда просматривающий узел 1286 желает получить обновленный моментальный снимок, просматривающий узел 1286 может отправить сообщение 1290 запроса просмотра в форме кадра 1330 запроса регенерации, как показано на фиг. 42. Кадр 1330 запроса регенерации по существу пересылает поле дескриптора просмотра моментального снимка (например, поле 1294 дескриптора просмотра) из предыдущего запроса моментального снимка, который просматриваемый узел 1288 может распознать как предыдущий запрос, используя значение дескриптора просмотра в кадре 1330 запроса регенерации.

5. Запрос отмены просмотра

[00246] Когда просматривающий узел 1286 желает отменить текущий просмотр (например, периодическое обновление или просмотр наблюдения), просматривающий узел 1286 может отправить сообщение 1290 запроса просмотра в форме кадра 1332 запроса отмены просмотра, как показано на фиг. 43. Кадр 1332 запроса отмены просмотра по существу пересылает поле дескриптора просмотра из предыдущего просмотра периодического обновления или просмотра наблюдения (например, поля 1310 или 1322 дескриптора просмотра) из предыдущего запроса, который просматриваемый узел 1288 может распознать как предыдущий запрос с использованием значения дескриптора просмотра в кадре 1330 запроса регенерации и отменить текущее периодическое обновление или просмотр наблюдения.

ii. Ответ просмотра

[00247] Со ссылкой на фиг. 36, после того как просматриваемый узел 1288 получает сообщение 1290 запроса просмотра, просматриваемый узел 1288 отвечает сообщением 1334 ответа просмотра. Пример кадра 1336 сообщения ответа просмотра иллюстрируется на фиг. 44. Кадр 1336 сообщения ответа просмотра включает в себя три поля: поле 1338 дескриптора просмотра, поле 1240 состояния запроса просмотра и поле 1242 списка элементов данных. Поле 1338 дескриптора просмотра может быть отформатировано аналогично любому из указанных выше полей 1338 дескриптора просмотра. Дополнительно, поле 1338 дескриптора просмотра содержит значение, которое совпадает с соответствующим полем дескриптора просмотра из сообщения 1290 запроса просмотра, на которое отвечает сообщение 1334 ответа просмотра. Поле 1340 состояния запроса просмотра является полем переменной длины, которое указывает состояние запроса просмотра и может быть отформатировано в соответствии с форматом обновления состояния, обсужденным выше. Поле 1342 списка элементов данных является полем переменной длины, которое присутствует, если поле 1340 состояния запроса просмотра указывает, что запрос просмотра был успешным. Если присутствует, поле 1342 списка элементов данных содержит упорядоченный список запрашиваемых данных, соответствующих списку путей сообщения 1290 запроса просмотра. Кроме того, данные в поле 1342 списка элементов данных могут быть закодированы в формате TLV, как описано выше.

iii. Запрос обновления

[00248] Как описано выше, в некоторых вариантах осуществления, просматриваемый узел 1288 может передавать обновления на просматривающий узел 1286. Эти обновления могут быть отправлены как сообщение 1344 запроса обновления. Сообщение 1344 запроса обновления может включать в себя определенный формат в зависимости от типа запроса обновления. Например, запрос обновления может быть явным запросом обновления или полем запроса обновления просмотра, которое может быть идентифицировано с помощью Id 1172 сообщения.

1. Явный запрос обновления

[00249] Явный запрос обновления может быть передан в любое время как результат желательности информации из другого узла в инфраструктуре 1000. Явный запрос обновления может быть отформатирован в кадре 1346 запроса обновления, показанном на фиг. 45. Показанный кадр 1346 запроса обновления включает в себя четыре поля: поле 1348 дескриптора обновления, поле 1350 длины списка путей, поле 1352 списка путей и поле 1354 списка элементов данных.

[00250] Поле 1348 дескриптора обновления включает в себя два байта, которые могут быть заполнены случайными или последовательными числами с проверками уникальности для идентификации запроса обновления или ответов на запрос. Поле 1350 длины списка путей содержит два байта, которые указывают длину поля 1352 списка путей. Поле 1352 списка путей является полем переменной длины, которое указывает последовательность путей, как описано выше. Поле 1354 списка элементов данных может быть отформатировано подобно полю 1242 списка элементов данных.

2. Запрос обновления просмотра

[00251] Сообщение запроса обновления просмотра может быть передано узлом, который ранее запрашивал просмотр схемы другого узла или узла, который установил просмотр в свои данные от имени другого узла. Вариант осуществления кадра 1356 запроса обновления просмотра показан на фиг. 46. Кадр 1356 запроса обновления просмотра включает в себя четыре поля: поле 1358 дескриптора обновления, поле 1360 дескриптора просмотра, поле 1362 длины списка элементов обновления и поле 1364 списка элементов обновления. Поле 1358 дескриптора обновления может быть составлено с использованием формата, обсужденного выше со ссылкой на поле 1348 дескриптора обновления. Поле 1360 дескриптора просмотра содержит два байта, которые идентифицируют просмотр, созданный релевантным сообщением 1290 запроса просмотра, имеющим тот же дескриптор просмотра. Поле 1362 длины списка элементов обновления включает в себя два байта и указывает количество элементов обновления, которые включены в поле 1364 списка элементов обновления.

[00252] Поле 1364 списка элементов обновления включает в себя переменное число байтов и перечисляет элементы данных, составляющих обновленные значения. Каждый список элементов обновления может включать в себя множество элементов обновления. Отдельные элементы обновления сформатированы в соответствии с кадром 1366 элемента обновления, показанным на фиг. 47. Каждый кадр 1366 элемента обновления включает в себя три суб-поля: поле 1368 индекса элемента, поле 1370 временной метки элемента и поле 1372 элемента данных. Поле 1368 индекса элемента содержит два байта, которые указывают просмотр, для которого запрашивается обновление, и индекс в списке путей этого просмотра для поля 1372 элемента данных.

[00253] Поле 1370 временной метки элемента включает в себя четыре байта и указывает время (например, в секундах), прошедшее от изменения до тех пор, пока не будет выполнено сообщаемое обновление. Если более чем одно изменение было выполнено для элемента данных, то поле 1370 временной метки элемента может указывать самое последнее или самое раннее изменение. Поле 1372 элемента данных является полем переменной длины, кодированным в формате TLV, которое должно приниматься в качестве обновленной информации.

iv. Ответ обновления

[00254] После того как обновление принято, узел (например, просматривающий узел 1286) может послать сообщение 1374 ответа обновления. Сообщение 1374 ответа обновления может быть закодировано с использованием кадра 1376 ответа обновления, показанного на фиг. 48. Кадр 1376 ответа обновления включает в себя два поля: поле 1378 дескриптора обновления и поле 1380 состояния запроса обновления. Поле 1378 дескриптора обновления соответствует значению поля дескриптора обновления сообщения 1344 запроса обновления, на которое отвечает сообщение 1374 ответа обновления. Поле 1380 состояния запроса обновления сообщает состояние обновления в соответствии с форматом отчетности о состоянии, упомянутым выше. Кроме того, профиль, использующий DMP (например, базовый профиль или профиль управления данными), может включать в себя специфические для профиля коды, такие как те, которые перечислены в таблице 21 ниже.

Таблица 21 Пример кодов состояния для профиля, включающего в себя DMP Имя Значение Описание Успешно 0×0000 Запрос успешно обработан Неправильно оформленный
Запрос 0×0010 Принятый запрос не может быть проанализирован (например, пропуск полей, лишние поля и т.д.) Недействительный путь 0×0011 Путь из списка путей просмотра или запроса обновления не согласован с находящейся в узле схемой отвечающего устройства. Неизвестный дескриптор
просмотра 0×0012 Дескриптор просмотра в запросе обновления не согласован с просмотром на принимающем узле. Несанкционированный
запрос считывания 0×0013 Узел, выполняющий запрос на считывание конкретного элемента данных, не имеет разрешения на это. Несанкционированный
запрос записи 0×0014 Узел, выполняющий запрос на запись конкретного элемента данных, не имеет разрешения на это. Внутренняя серверная ошибка 0×0020 Сервер не может обрабатывать запрос из-за внутренней ошибки. Нехватка памяти 0×0021 Запрос обновления не может быть исполнен, так как он переполнил бы доступную память в принимающем устройстве. Продолжить 0×0030 Запрос был успешно обработан, но может произойти дополнительное действие запрашивающего устройства.

Д. Групповая пересылка

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

[00256] Устройства, участвующие в групповой пересылке, могут быть в общем разделены в соответствии с передачей групповой пересылки и созданием события. Как показано на фиг. 49, каждая передача 1400 в групповой пересылке включает в себя отправителя 1402, который является узлом/службой, который(ая) передает массив данных 1404 к получателю 1406, который является узлом/службой, который(ая) получает массив данных 1404. В некоторых вариантах осуществления получатель может послать к отправителю 1402 информацию 1408 о состоянии, указывающую состояние групповой пересылки. Кроме того, событие групповой пересылки может быть инициировано либо отправителем 1402 (например, выгрузка), либо получателем 1406 (например, загрузка) в качестве инициатора. Узел/служба, который(ая) отвечает инициатору, может упоминаться как ответчик в групповой пересылке данных.

[00257] Групповая пересылка данных может происходить с использованием либо синхронного, либо асинхронного режимов. Режим, в котором пересылаются данные, может быть определен с помощью различных факторов, таких, как базовый протокол (например, UDP или TCP), согласно которому выполняется групповая пересылка данных. В протоколах без установления соединения (например, UDP), массив данных может пересылаться с использованием синхронного режима, который позволяет одному из узлов/служб (“драйверу”) управлять скоростью, с которой выполняется пересылка. В некоторых вариантах осуществления, после каждого сообщения в групповой пересылке данных в синхронном режиме, может отправляться подтверждение до посылки следующего сообщения в групповой пересылке данных. Драйвером может быть отправитель 1402 или получатель 1406. В некоторых вариантах осуществления драйвер может переключаться между онлайн-состоянием и офлайн-режимом при отправке сообщений, чтобы способствовать пересылке в онлайн-состоянии. В групповых пересылках данных с использованием протоколов, ориентированных на соединение (например, TCP), массив данных может передаваться с помощью асинхронного режима, который не использует подтверждение перед отправкой последовательных сообщений, или одного драйвера.

[00258] Независимо от того, выполняется ли групповая пересылка данных с использованием синхронного или асинхронного режима, тип сообщения может быть определен с использованием типа 1172 сообщения в полезной нагрузке 1146 приложения в соответствии с Id 1176 профиля в полезной нагрузке приложения. Таблица 22 включает в себя пример типов сообщений, которые могут быть использованы в связи со значением профиля групповой передачи данных в Id 1176 профиля.

Таблица 22 Примеры типов сообщений для профилей групповой пересылки данных Тип сообщения Сообщение 0×01 SendInit 0×02 SendAccept 0×03 SendReject 0×04 ReceiveInit 0×05 ReceiveAccept 0×06 ReceiveReject 0×07 BlockQuery 0×08 Block 0×09 BlockEOF 0×0А Ack 0×0В BlockEOF 0×0С Error

i. SendInit

[00259] Вариант осуществления сообщения SendInit 1420 показан на фиг. 50. Сообщение SendInit 1420 может включать в себя семь полей: поле 1422 управления пересылкой, поле 1424 управления диапазоном, поле 1426 длины обозначения файла, поле 1428 предложенного максимального размера блока, поле 1430 начального смещения, поле 1432 длины и поле 1434 обозначения файла.

[00260] Поле 1422 управления пересылкой включает в себя байт данных, показанных на фиг. 51. Поле управления пересылкой включает в себя по меньшей мере четыре поля: асинхронный флаг 1450, флаг RDrive 1452, флаг SDrive 1454 и поле 1456 версии. Асинхронный флаг 1450 указывает, может ли предложенная пересылка выполняться с использованием синхронного или асинхронного режима. Флаг RDrive 1452 и флаг SDrive 1454, соответственно, указывают, способен ли получатель 1406 пересылать данные, когда получатель 1402 или отправитель 1408 запускают пересылку в синхронном режиме.

[00261] Поле 1424 управления диапазоном включает в себя байт данных, такой как поле 1424 управления диапазоном, показанное на фиг. 52. В показанном варианте осуществления поле 1424 управления диапазоном включает в себя по меньшей мере три поля: флаг BigExtent 1470, флаг 1472 начального смещения и флаг 1474 определения длины. Флаг 1474 определения длины указывает, имеет ли пересылка определенную длину. Флаг 1474 определения длины указывает, присутствует ли поле 1432 длины в сообщении SendInit 1420, и флаг BigExtent 1470 указывает размер для поля 1432 длины. Например, в некоторых вариантах осуществления, значение 1 во флаге BigExtent 1470 указывает, что поле 1432 длины соответствует восьми байтам. В противном случае, поле 1432 длины соответствует четырем байтам, если присутствует. Если пересылка имеет определенную длину, флаг 1472 начального смещения указывает, присутствует ли начальное смещение. Если начальное смещение присутствует, то флаг BigExtent 1470 указывает длину для поля 1430 начального смещения. Например, в некоторых вариантах осуществления, значение 1 во флаге BigExtent 1470 указывает, что поле 1430 начального смещения соответствует восьми байтам. В противном случае, поле 1430 начального смещения соответствует четырем байтам, если присутствует.

[00262] Со ссылкой на фиг. 50, поле 1426 длины обозначения файла включает в себя два байта, которые указывают длину поля 1434 обозначения файла. Поле 1434 обозначения файла, которое является полем переменной длины, зависит от поля 1426 длины обозначения файла. Поле 1428 максимального размера блока предлагает максимальный размер блока, который можно переслать в одной пересылке.

[00263] Поле 1430 начального смещения, если присутствует, имеет длину, указанную флагом BigExtent 1470. Значение поля 1430 начального смещения указывает место в файле, который должен пересылаться, от которого отправитель 1402 может начать пересылку, по существу позволяя сегментировать пересылки больших файлов на несколько сессий групповой пересылки.

[00264] Поле 1432 длины, если присутствует, указывает длину файла, подлежащего пересылке, если поле 1474 определения длины указывает, что файл имеет определенную длину. В некоторых вариантах осуществления, если получатель 1402 получает последний блок, прежде чем длина достигается, получатель может считать, что пересылка безуспешна, и сообщить об ошибке, как описано ниже.

[00265] Поле 1434 обозначения файла является идентификатором переменной длина, выбранным отправителем 1402, чтобы идентифицировать файл, подлежащий отправке. В некоторых вариантах осуществления отправитель 1402 и получатель 1406 могут согласовать идентификатор для файла перед пересылкой. В других вариантах осуществления получатель 1406 может использовать метаданные вместе с полем 1434 обозначения файла, чтобы определить, следует ли принимать пересылку, и каким образом обрабатывать данные. Длина поля 1434 обозначения файла может быть определена из поля 1426 длины обозначения файла. В некоторых вариантах осуществления сообщение SendInit 1420 может также включать в себя поле 1480 метаданных переменной длины, закодированное в формате TLV. Поле 1480 метаданных позволяет инициатору отправлять дополнительную информацию, такую как информация конкретного приложения о файле, подлежащем пересылке. В некоторых вариантах осуществления поле 1480 метаданных может быть использовано, чтобы избежать согласования поля 1434 обозначения файла перед групповой пересылкой данных.

ii. SendAccept

[00266] Сообщение принятия передачи передается от ответчика, чтобы указать режим пересылки, выбранный для пересылки. Вариант осуществления сообщения SendAccept 1500 представлен на фиг. 53. Сообщение SendAccept 1500 содержит поле 1502 управления пересылкой, аналогичное полю 1422 управления пересылкой сообщения SendInit 1420. Однако в некоторых вариантах осуществления только флаг RDrive 1452 или SDrive 1454 может иметь ненулевое значение в поле 1502 управления пересылкой, чтобы идентифицировать отправителя 1402 или получателя 1406 как инициатора пересылки в синхронном режиме. Сообщение SendAccept 1500 также включает в себя поле 1504 максимального размера блока, которое указывает максимальный размер блока для пересылки. Поле 1504 размера блока может быть равно значению поля 1428 максимального блока сообщения SendInit 1420, но значение поля 1504 максимального размера блока может быть меньше, чем значение, предлагаемое в поле 1428 максимального блока. Наконец, сообщение SendAccept 1500 может включать в себя поле 1506 метаданных, которое указывает информацию, которую получатель 1506 может послать к отправителю 1402, о пересылке.

iii. SendReject

[00267] Если получатель 1206 отклоняет пересылку после сообщения SendInit, получатель 1206 может отправить сообщение SendReject, которое указывает, что существует одна или более проблем относительно групповой пересылки данных между отправителем 1202 и получателем 1206. Сообщение отклонения передачи может быть отформатировано в соответствии с форматом отчета о состоянии, описанным выше и показанным на фиг. 54. Кадр 1520 отклонения передачи может включать в себя поле 1522 кода состояния, которое включает в себя два байта, которые указывают на причину отклонения пересылки. Поле 1522 кода состояния может быть декодировано с использованием значений, аналогичных тем, которые перечислены в таблице 23 ниже.

Таблица 23 Примерные коды состояния для сообщения отклонения передачи Код состояния Описание 0×0020 Способ передачи не поддерживается 0×0021 Обозначение файла не известно 0×0022 Начальное смещение не поддерживается 0×0011 Требуемая длина 0×0012 Длина слишком велика 0×002F Неизвестная ошибка

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

iv. ReceiveInit

[00268] Сообщение ReceiveInit может быть передано получателем 1206 в качестве инициатора. Сообщение ReceiveInit может форматироваться и кодироваться аналогично сообщению SendInit 1480, показанному на фиг. 50, но поле BigExtent 1470 может упоминаться как поле максимальной длины, которое определяет максимальный размер файла, который получатель 1206 может обрабатывать.

v. ReceiveAccept

[00269] Когда отправитель принимает сообщение ReceiveInit, отправитель 1202 может ответить сообщением ReceiveAccept. Сообщение ReceiveAccept может форматироваться и кодироваться как сообщение ReceiveAccept 1540, показанное на фиг. 55. Сообщение ReceiveAccept 1540 может включать в себя четыре поля: поле 1542 управления пересылкой, поле 1544 управления диапазоном, поле 1546 максимального размера блока и иногда поле 1548 длины. Сообщение ReceiveAccept 1540 может быть отформатировано подобно сообщению SendAccept 1502 на фиг. 53 с вторым байтом, указывающим поле 1544 управления диапазоном. Кроме того, поле 1544 управления диапазоном может форматироваться и кодироваться с использованием методов, описанных выше в отношении поля 1424 управления диапазоном по фиг. 52.

vi. ReceiveReject

[00270] Если отправитель 1202 обнаруживает проблему с пересылкой файла к получателю 1206, отправитель 1202 может отправить сообщение ReceiveReject, отформатированное и закодированное подобно сообщению SendReject 48 с использованием формата отчетности о состоянии, как описано выше. Однако поле 1522 кода состояния может быть кодировано/декодировано с использованием значений, аналогичных перечисленным в таблице 24 ниже.

Таблица 24 Примерные коды состояния для сообщения отклонения приема Код состояния Описание 0×0020 Способ пересылки не поддерживается 0×0021 Обозначение файла не известно 0×0022 Начальное смещение не поддерживается 0×0013 Длина слишком велика 0×002F Неизвестная ошибка

vii. BlockQuery

[00271] Сообщение BlockQuery может быть отправлено посредством инициирующего получателя 1202 в групповой пересылке данных синхронного режима, чтобы запросить следующий блок данных. BlockQuery косвенно подтверждает получение предыдущего блока данных, если явное подтверждение не было отправлено. В вариантах осуществления с использованием асинхронных передач, сообщение BlockQuery может быть опущено из процесса передачи.

viii. Block

[00272] Блоки данных, передаваемых в групповой пересылке данных, могут включать в себя любую длину больше 0 и меньше, чем максимальный размер блока, согласованный отправителем 1202 и получателем 1206.

ix. BlockEOF

[00273] Конечный блок в пересылке данных может быть представлен как блок “конец файла” (BlockEOF). BlockEOF может иметь длину от 0 до максимального размера блока. Если получатель 1206 обнаруживает несоответствие между заранее согласованным размером файла (например, полем 1432 длины) и количеством фактически переданных данных, получатель 1206 может послать сообщение об ошибке, указывающее на сбой, как описано ниже.

x. Ack

[00274] Если отправитель 1202 инициирует пересылку в синхронном режиме, отправитель 1202 может ожидать, пока не будет принято подтверждение (Ack) после отправки блока (Block) перед отправкой следующего блока. Если получатель инициирует пересылку в синхронном режиме, то получатель 1206 может послать либо явное Ack, либо BlockQuery, чтобы подтвердить получение предыдущего блока. Кроме того, в групповых пересылках в асинхронном режиме сообщение Аck может быть вообще опущено из процесса передачи.

xi. AckEOF

[00275] Подтверждение конца файла (AckEOF) может быть отправлено в групповых пересылках, отправленных в синхронном режиме или в асинхронном режиме. Используя AckEOF, получатель 1206 показывает, что при пересылке были получены все данные, и сигнализирует конец сессии групповой пересылки данных.

xii. Error

[00276] При возникновении некоторых проблем при осуществлении связи отправитель 1202 или получатель 1206 может отправить сообщение об ошибке, чтобы преждевременно закончить сессию групповой пересылки данных. Сообщения об ошибках могут форматироваться и кодироваться в соответствии с форматом отчетности о состоянии, описанным выше. Например, сообщение об ошибке может быть отформатировано аналогично кадру SendReject 1520 по фиг. 54. Однако коды состояния могут кодироваться/декодироваться со значениями, включающими в себя или подобными значениям, перечисленным в таблице 25 ниже.

Таблица 25 Примерные коды состояния для сообщения об ошибке в профиле групповой пересылки данных Код состояния Описание 0×001F Пересылка безуспешна ввиду неизвестной ошибки 0×0011 Ошибка переполнения

[00277] Конкретные варианты осуществления, описанные выше, были показаны в качестве примера, и следует понимать, что эти варианты осуществления могут допускать различные модификации и альтернативные формы. Следует также понимать, что формула изобретения не предназначена, чтобы ограничиваться конкретными раскрытыми формами, а скорее охватывает все модификации, эквиваленты и альтернативы, попадающие в рамки сущности и объема настоящего раскрытия.

Случаи использования эффективной связи и информированность о питании

[00278] Протокол эффективной сети IPv6 802.15.4 и/или протокол эффективной платформы, описанные выше, могут обеспечить энергетически эффективные операции в домашней среде. Как будет описано ниже, в одном примере, такая связь может включать в себя передачу IPv6 пакета по конкретной предпочтительный сети. Дополнительно или альтернативно, свойства способа связи, такие как тип транспортного протокола - TCP или UDP – используемого для передачи сообщения, могут также выбираться. Например, для обеспечения большей надежности, но при меньшем энергосбережении, может быть выбран протокол ТСР, в то время как для обеспечения большей экономии мощности, но при меньшей надежности, может быть выбран протокол UDP.

Интеллектуальная связь, использующая поля заголовка IPv6 пакета

[00279] Как указано выше, поля, доступные в заголовке IPv6 пакета, могут быть использованы в системе согласно данному раскрытию, чтобы переносить информацию о целевом узле инфраструктуры 1000, который ориентирован на прием сообщения. Например, как показано на фиг. 56, заголовок 1600 IPv6 пакета, ориентированного на конкретный узел, может включать в себя поле 1602 МАС, поле 1604 подсети и поле 1606 ID инфраструктуры. Поле 1602 МАС может заполнять 64-битную область, как правило, понимаемую, чтобы представлять Расширенный Уникальный Идентификатор (EUI-64). Поле 1602 МАС может включать в себя указание МАС-адреса целевого узла. Поле 1604 подсети и поле 1606 ID инфраструктуры могут коллективно представлять Расширенный Уникальный Локальный Адрес (EULA). В EULA этих полей, поле 1606 ID инфраструктуры может указывать конкретную инфраструктуру 1000, через которую должен посылаться IPv6 пакет, а поле 1604 подсети может идентифицировать предпочтительную сеть в инфраструктуре 1000, по которой целевой узел предпочтительно может принимать сообщения. В примере на фиг. 56, поле 1604 подсети указывает, что целевой узел предпочтительно может принимать сообщения через конкретную сеть WiFi. Следует иметь в виду, что EULA, образованный полем 1606 ID инфраструктуры и полем 1604 подсети, может быть использован, когда IPv6 пакеты отправляются исключительно в пределах одной или более соединенных инфраструктур и/или служб, которые обслуживают эти инфраструктуры. Когда IPv6 пакеты должны быть отправлены от узла инфраструктуры 1000 на внешний Интернет-адрес IPv6, может быть использована другая (например, более традиционная) структура заголовка IPv6 пакета.

[00280] Информация EULA поля 1604 подсети и поля 1606 ID инфраструктуры может быть использована для эффективной передачи IPv6 пакетов через инфраструктуру 1000 к целевому узлу. В примере, показанном на фиг. 57, сообщение посылается через сетевую топологию, описанную выше со ссылкой на фиг. 11. В данном случае узел 1026 является передающим узлом, а узел 1036 является целевым узлом. Узел 1026 работает в 802.15.4 сети 1022, в то время как целевой узел 1036 работает как в 802.15.4 сети 1022, так и в беспроводной сети 1020. Предпочтительная сеть целевого узла 1036 представлена в примере на фиг. 57 как WiFi сеть 1020. Таким образом, IPv6 пакеты, используемые для передачи сообщения от передающего узла 1026 к целевому узлу 1036, обычно могут иметь характеристики, показанные в IPv6 пакете 1600 на фиг. 56.

[00281] Различные узлы 1026, 1028, 1030, 1034 и 1042 показаны на фиг. 57 для передачи сообщения от передающего узла 1026 к целевому узлу 1036. Когда имеется только одна сеть, чтобы передавать сообщение, сообщение может передаваться через эту сеть. Это соответствует случаю узлов 1026, 1028 и 1030 в примере на фиг. 57. Однако когда сообщение достигает узла, который работает в более чем одной сети, такого как узел 1034, этот узел может использовать поле 1604 подсети, чтобы определить, какую сеть следует использовать для передачи сообщения дальше к целевому узлу 1036.

[00282] Блок-схема 1650 последовательности операций на фиг. 58 иллюстрирует пример способа для использования поля 1604 подсети заголовка 1600 пакета для передачи IPv6 пакета к целевому узлу. В способе, узел, который работает в двух сетях (например, узел 1034, который работает как в WiFi сети 1020, так и в 802.15.4 сети 1022), может принимать IPv6 пакет (блок 1652). Узел может анализировать поле 1604 подсети заголовка 1600 IPv6 пакета, чтобы определить, какая сеть является наиболее подходящей сетью для использования, чтобы передать IPv6 пакет к целевому узлу. Поле 1604 подсети может указывать, например, что сообщение должно приниматься целевым узлом (например, узлом 1036) по WiFi сети 1020. Принимающий узел (например, узел 1034) может тогда послать IPv6 пакет к целевому узлу (например, узлу 1036) по сети, указанной полем 1604 подсети (например, WiFi сети 1020) (блок 1654).

[00283] В некоторых примерах, сеть, по которой был принят IPv6 пакет, может отличаться от сети, указанной полем 1604 подсети. На фиг. 57, например, узел 1034 принимает сообщение по 802.15.4 сети 1022. Однако если поле 1604 подсети указывает, что WiFi сеть 1020 является предпочтительной сетью, чтобы использоваться для передачи IPv6 пакета, то вместо этого узел 1034 может передать IPv6 пакет по сети WiFi 1020. Таким образом, поле 1604 подсети может позволить целевому узлу иметь предпочтительную сеть для приема сообщений. В примере на фиг. 57, целевой узел 1036 может быть всегда включенным электронным устройством, которое может осуществлять связь более быстро или более надежно по WiFi сети 1020, чем по 802.15.4 сети 1022. В других примерах, целевой узел 1036 может быть устройством в спящем режиме с батарейным питанием, для которого было бы лучше принимать сообщения по 802.15.4 сети 1022. В таком примере, хотя целевой узел 1036 мог бы принимать сообщения через WiFi сеть 1020, путем приема сообщений через 802.15.4 сеть 1022, как может указываться полем 1604 подсети, целевой узел 1036 может экономить энергию. Таким образом, EULA заголовка 1600 IPv6 пакета (например, поле 1606 ID инфраструктуры и поле 1604 подсети) может быть использован для поддержки эффективной передачи сообщений через инфраструктуру.

Выбор транспортного протокола или предпочтительной целевой сети на основе желательной надежности сообщения

[00284] Тщательный выбор транспортного протокола (например, TCP или UDP) и/или предпочтительной сети целевого узла, используемой для отправки IPv6 пакетов, может также привести к эффективному использованию сети. В самом деле, в то время как TCP является более надежным, чем UDP, надежность TCP проистекает из использования в нем квитирования и подтверждений при передаче сообщений, многие из которых отсутствуют в UDP. Дополнительная надежность TCP, однако, может увеличить затраты на передачу сообщения в терминах потребляемой мощности. В самом деле, имеют место дополнительные затраты мощности на квитирование и подтверждения в TCP. Кроме того, использование TCP будет вызывать повторную передачу отброшенных пакетов, пока они не будут приняты с подтверждением, потребляя дополнительную мощность на всех устройствах, для которых имеют место отброшенные пакеты.

[00285] Таким образом, может быть желательно передавать сообщения посредством UDP, если только не имеется причин, по которым надежность является предпочтительной по сравнению с энергетической эффективностью. Например, как показано в блок-схеме 1670 последовательности операций на фиг. 59, одно из устройств в инфраструктуре 1000 может формировать сообщение (блок 1672). Устройство может учитывать один или более факторов надежности, относящихся к желательной надежности сообщения (блок 1674). Этот учет одного или более факторов надежности может иметь место в уровне 102 приложения или уровне 100 платформы OSI стека 90, исполняемого на устройстве. В любом случае, фактор(ы) надежности, который(е) устройство может учитывать, может (могут) включать в себя (1) тип сообщения, генерируемого в блоке 1672, (2) тип сети, по которой сообщение будет отправлено, (3) расстояние, которое сообщение может проходить в инфраструктуре, (4) чувствительность по мощности целевого узла и/или передающих узлов, которые будут использоваться для передачи сообщения на целевой узел, и/или (5) тип целевого конечного узла (например, является ли он устройством или службой). В некоторых вариантах осуществления может учитываться только один фактор. Кроме того, перечень факторов надежности, обсуждаемых здесь, не является исчерпывающим, но, скорее, приведен в качестве примеров для принятия решения о том, будет ли надежность или энергосбережение более желательной(ым) при передаче сообщения.

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

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

[00288] Третьим фактором, который может повлиять на желательную надежность транспортного протокола, является расстояние, которое сообщение может проходить в инфраструктуре 1000, чтобы достичь целевого узла. Расстояние может представлять собой, например, число “транзитных участков”, чтобы достичь целевого узла, количество различных типов сетей, которые могут быть пройдены, чтобы достичь целевого узла, и/или действительное расстояние по сети.

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

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

[00291] Устройство может учитывать один или более из этих факторов любым подходящим способом. В одном примере, факторам может быть назначен вес, и определение надежности может быть основано на общем взвешивании факторов. В других примерах, некоторые факторы могут иметь более высокий приоритет, чем другие факторы. В таком примере, срочное сообщение может всегда рассматриваться как имеющее более желательную надежность по сравнению с энергосбережением, в то время как желательность надежности для несрочных сообщений может зависеть от других факторов. Таким образом, когда энергосбережение является более желательным, чем надежность (решающий блок 1676), устройство может послать сообщение посредством UDP (блок 1678), чтобы сберечь мощность, несмотря на более низкую надежность. Когда более высокая надежность является желательной по сравнению с энергосбережением (решающий блок 1676), устройство может отправить сообщение посредством TCP (блок 1680), чтобы иметь повышенную надежность, несмотря на более высокое энергопотребление.

[00292] Хотя описанный выше способ был обсужден со ссылкой на выбор отправки сообщения с использованием TCP или UDP, следует понимать, что настоящая система связи может эффективно регулировать любое количество свойств в способе связи, чтобы сбалансировать желательную надежность с потребляемой мощностью. Например, в некоторых вариантах осуществления, когда желательна более высокая надежность, может быть предпочтительной сеть повышенной мощности (например, WiFi), а если желательны более низкая надежность и более высокое энергосбережение, то может быть предпочтительной сеть с низким энергопотреблением (например, 802.15.4). Передающий узел может, например, выбрать другую предпочтительную сеть, чтобы отметить в поле 1604 подсети заголовка 1600 IPv6 пакета, тем самым обеспечивая то, что сообщение будет передаваться, если это возможно, через эту выбранную сеть.

Дополнительные случаи использования

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

Вызов метода с одного устройства на другое

[00294] В одном случае, устройство в одной области инфраструктуры 1000 может вызывать определенный метод на другом совместимом устройстве. Один пример представлен в диаграмме 1700 на фиг. 60. Диаграмма 1700 иллюстрирует взаимодействия между первым устройством 1702 и вторым устройством 1704, при посредничестве устройства каталога (DDS) 1706. Устройство каталога (DDS) 1706 может выдать широковещательную передачу 1708 услуги DDS к различным устройствам в инфраструктуре, включая первое устройство 1702 и второе устройство 1704. В ответ устройство каталога (DDS) 1706 может принять список всех методов и/или профилей различных устройств 1000 поддержки инфраструктуры.

[00295] Когда одно из устройств инфраструктуры, такое как первое устройство 1702, желает выполнить метод (показан на фиг. 60 как метод n), первое устройство 1702 может запрашивать устройство каталога (DDS) 1706 соответствующим сообщением 1710 запроса (например, GetProperty(supports-n)). Устройство каталога (DDS) 1706 может ответить устройствами, которые поддерживают такое свойство, в данном случае отвечая сообщением 1712, указывающим, что второе устройство 1704 поддерживает желательный метод. Располагая этой информацией, первое устройство 1702 может вызвать метод в сообщении 1714 к второму устройству 1704. Второе устройство 1704, то может выдать ответ 1716 с соответствующим откликом.

[00296] Метод, вызываемый посредством первого устройства 1702 на втором устройстве 1704, может быть любым из ряда методов, которые могут быть полезны в домашней сети. Например, первое устройство 1702 может запросить данные датчика окружающей среды от второго устройства 1704. Данные датчика окружающей среды могут указывать движение, температуру, влажность и т.д. Данные датчика окружающей среды могут быть использованы первым устройством 1702, чтобы определять, например, занятость помещения в целях безопасности или определять различные температуры в текущий момент вокруг дома. В другом примере, первое устройство 1702 может запрашивать информацию ввода пользовательского интерфейса от второго устройства 1704. Например, первое устройство 1702 может запросить указание последних заданных значений температуры термостата, чтобы выяснить информацию о последних желательных настройках для обеспечения комфорта обитателей помещений.

Распространение сообщения к различным устройствам инфраструктуры

[00297] В некоторых ситуациях, может быть желательно распространять сообщение к множеству устройств инфраструктуры. Например, как показано на диаграмме 1720 на фиг. 61, несколько устройств 1722, 1724, 1726 и 1728 может быть использовано для распространения сообщения тревожной сигнализации. Действительно, сообщение тревожной сигнализации может распространяться, даже если одно или более из различных устройств 1722, 1724, 1726 и 1728 могут быть устройствами с низким энергопотреблением или в “спящем режиме”. В примере на фиг. 61, устройство 1722 является детектором опасности (например, детектором дыма) в гараже, устройство 1724 является детектором опасности (например, детектором дыма) в столовой, устройство 1726 является интеллектуальным дверным звонком у входной двери, и устройство 1728 является термостатом в прихожей.

[00298] Действие схемы 1720 начинается, когда событие 1730 (например, пожар) обнаруживается гаражным устройством 1722. Гаражное устройство 1722 может распространять сообщение 1732 пробуждения сети к устройству 1724 в столовой, которое может выдать ответ 1734 соответственно. Устройство 1724 в столовой может временно активизироваться из своего спящего состояния в постоянно включенное состояние. Устройство 1724 в столовой также может распространить сообщение 1736 пробуждения сети к устройству 1726 у входной двери, которое может ответить 1738 также распространением другого сообщения 1740 пробуждения сети к устройству 1728 в прихожей.

[00299] Активизировав устройства инфраструктуры, гаражное устройство 1722 может вывести сигнал тревоги 1744, связанный с событием 1730, и может выдать сообщение 1746 оповещения о тревоге к устройству 1724 в столовой. Сообщение 1746 оповещения о тревоге может указывать на тип события и инициирующее устройство (например, событие, происходящее в гараже), среди прочего. Устройство 1724 в соловой может выводить соответствующий сигнал тревоги 1748 и направлять сообщение оповещения о тревоге к устройству 1726 входной двери, которое может само начать выводить сигнал тревоги 1752. Устройство 1726 входной двери может также направлять сообщение оповещения о тревоге к устройству 1728 в прихожей.

[00300] Устройство 1728 в прихожей может отображать сообщение 1756 интерфейса, чтобы позволить пользователю ответить на сигнал тревоги. В то же время, сообщения могут продолжать распространяться по всей инфраструктуре. Они включают в себя дополнительные сообщения 1758, 1760, 1762, 1764 и 1766 пробуждения сети и ответа и дополнительные сообщения 1768, 1770 и 1772 оповещения о тревоге. Когда пользователь предоставляет пользовательскую обратную связь 1774 на устройстве 1728 в прихожей, запрашивающую выключение сигнализации (поняв, например, что сигнализация является ложной или обусловлена не представляющими опасности условиями), устройство 1728 в прихожей может отвечать отправкой сообщения 1776 выключения сигнала тревоги, которое может быть распространено по инфраструктуре 1000 ко всем устройствам. Сообщение 1776 выключения сигнала тревоги может достигать устройства 1726 в прихожей, которое может выключить свою тревожную сигнализацию 1778 и выдать дальнейшее сообщение 1780 выключения сигнала тревоги на устройство 1724 в столовой. В ответ устройство 1724 в столовой может выключить свой сигнал тревоги 1782 выдать дальнейшее сообщение выключения сигнала тревоги на гаражное устройство 1722, которое, в свою очередь, может выключить свой сигнал тревоги 1786.

[00301] После обеспечения выключения устройствами 1726, 1724 и 1722 своих сигналов тревоги, устройство 1728 в прихожей может вызвать перевод устройств 1726, 1724 и 1722 снова в спящее состояние с низким энергопотреблением. В частности, устройство 1728 в прихожей может выдать сообщение 1790 спящего состояния сети к устройству 1726 у входной двери, которое может ввести спящее состояние после выдачи сообщения 1792 спящего состояния сети к устройству 1724 в столовой. Устройство 1724 в столовой может соответственно прейти в спящее состояние после выдачи сообщения 1794 спящего состояние сети в гаражное устройство 1722. После приема сообщения 1794 спящего состояния сети гаражное устройство 1722 может перейти в спящее состояние с низким энергопотреблением.

Присоединение или создание инфраструктуры

[00302] Протоколы, описанные выше, могут быть использованы для присоединения или создания инфраструктуры 1000 устройств в домашней сети или аналогичной среде. Например, фиг. 62-64 относятся к первому способу, в котором новое устройство присоединяется к существующей инфраструктуре 1000 через другое устройство инфраструктуры 1000, которое соединено со службой (например, через Интернет). Фиг. 65-67 относятся к второму способу, в котором новое устройство присоединяется к существующей инфраструктуре 1000 или создает новую инфраструктуру 1000 через соединение одноранговых узлов с другим устройством независимо от того, соединено ли любое устройство с другой службой. Следующие примеры относятся к присоединению к инфраструктуре 1000 с новым устройством, которое может не иметь пользовательского интерфейса с собственным дисплеем и, таким образом, может привлекать помощь от клиентского устройства третьей стороны (например, мобильного телефона или планшетного компьютера). В других вариантах осуществления, например, в которых новое устройство включает в себя пользовательский интерфейс с собственным дисплеем, действия, описанные ниже в качестве выполняемых на клиентском устройстве третьей стороны, вместо этого могут выполняться на новом устройстве.

Присоединение или создание инфраструктуры с использованием Интернет-соединения со службой

[00303] Со ссылкой сначала на блок-схему 1800 последовательности операций, показанную на фиг. 62-64, пользователь может присоединить новое устройство к инфраструктуре 1000 путем открытия окна, в котором устройство было продано (блок 1802), и получения инструкций по установке приложения (блок 1804) на клиентском устройстве третьей стороны (например, мобильном телефоне или планшетном компьютере). Приложение может быть установлено на клиентском устройстве (блок 1806), и пользователь может войти в учетную запись службы, связанную с инфраструктурой 1000, где пользователь может выбрать конкретную инфраструктуру 1000, чтобы присоединить новое устройство (блок 1808). Например, пользователь может установить приложение Nest® и может войти в учетную запись службы Nest®, связанную с инфраструктурой Nest®Weave^TM. Приложение на клиентском устройстве может получить информацию, связанную с конфигурацией службы инфраструктуры 1000 (блок 1810). Информация, связанная с конфигурацией службы инфраструктуры 1000 может включать в себя, например:

- идентификацию узла службы (например, EUI-64 или EULA);

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

- глобально уникальную идентификацию учетной записи, связанной с учетной записью пользователя;

- имя хоста службы доменных имен (DNS), идентифицирующее точку входа для службы; и/или

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

[00304] Пользователь может также сделать выбор, с помощью приложения на клиентском устройстве, чтобы добавить новое устройство в инфраструктуру 1000 (блок 1812). На основе того, имеется ли в текущий момент существующая инфраструктура 1000, ассоциированная с пользователем, или на основе каких-либо других подходящих критериев (решающий блок 1814), приложение может сделать выбор, чтобы создать новую инфраструктуру 1000 (блок 1816) или добавить новое устройство к существующей инфраструктуре 1000 (блок 1818).

[00305] Когда приложение делает выбор, чтобы добавить новое устройство в существующую инфраструктуру 1000 (блок 1818), приложение может определить, находятся ли устройства сети в активном, а не в спящем состоянии (решающий блок 1820), активируя устройства (блок 1822), если они находятся в спящем состоянии. Пользователь может выбрать конкретное существующее устройство сети для использования в процессе присоединения, например, нажатием кнопки (блок 1824). Существующее устройство может предоставить информацию присоединения к инфраструктуре в приложение на клиентском устройстве (этап 1826). Например, приложение на клиентском устройстве может установить безопасную сессию с существующим устройством с использованием маркера аутентификации инфраструктуры 1000. Приложение может использовать запросы (например, GetNetworkConfiguration и/или GetFabricConfiguration), чтобы получить от существующего устройства информацию о конфигурации сети и/или информацию о конфигурации инфраструктуры 1000. Приложение может сохранить эту информацию для последующего использования.

[00306] Приложение может дополнительно проинструктировать пользователя, чтобы активировать новое устройство (блок 1828), например, нажатием кнопки на новом устройстве (блок 1830). Затем способ может перейти к блоку (A) 1832, который продолжается на фиг. 63. Здесь приложение на клиентском устройстве может инструктировать существующее устройство соединиться с новым устройством (блок 1834). Например, приложение может установить новую безопасную сессию с существующим устройством с использованием маркера аутентификации инфраструктуры и в этой новой сессии может отправить запрос (например, ConnectOtherDevice) к существующему устройству. Между тем, новое устройство может установить “соединяющую сеть” 802.15.4, специально с целью соединения с существующим устройством. Таким образом, запрос блока 1834 может указывать, что приложение желает, чтобы существующее устройство соединилось с новым устройством через соединение сети 802.15.4 (например, соединяющую сеть 802.15.4, созданную новым устройством). Затем существующее устройство может выполнить сканирование соседних сетей 802.15.4 для поиска сети, созданной новым устройством. После нахождения, существующее устройство может покинуть существующую инфраструктуру, присоединиться к новой соединяющей сети 802.15.4 и прозондировать соединяющую сеть 802.15.4, пытаясь соединиться с адресом рандеву (который может быть установлен ранее с помощью программного обеспечения или прошивки существующего устройства или приложением на клиентском устройстве). После того, как соединение с новым устройством установлено, существующее устройство может ответить на запрос соединения с новым устройством (например, ConnectOtherDevice) из приложения на клиентском устройстве ответом успеха операции. С этого момента, сообщения, выдаваемые на новое устройство из приложения, могут выполняться путем представления существующим устройством через соединяющую сеть 802.15.4. То есть, новое устройство может быть соединено с существующим устройством через соединяющую сеть 802.15.4, существующее устройство может быть соединено с узлом службы через WiFi (и/или Интернет-соединение), и приложение на клиентском устройстве может быть соединено со службой. Таким образом, приложение может соединиться с новым устройством через существующую инфраструктуру, а существующее устройство может использовать только одно соединение WiFi и одно соединение 802.15.4 (тем самым снижая использование в существующем устройстве нескольких приемником и передатчиков на каждый тип сети, что может снизить стоимость устройства и энергопотребление).

[00307] В качестве альтернативы, когда новая инфраструктура 1000 должна быть создана, приложение на клиентском устройстве может соединиться непосредственно с новым устройством, используя соединение WiFi. Таким образом, приложение на клиентском устройстве может инструктировать пользователя переключиться на соединение WiFi (блок 1836). Пользователь может переключить сети WiFi на своем клиентском устройстве, чтобы установить одноранговое соединение WiFi с новым устройством (блок 1838). Например, новое устройство иметь ассоциированное с ним уникальное имя WiFi SSID на задней стороне нового устройства. Приложение на клиентском устройстве может прозондировать наличие нового устройства, повторно пытаясь соединиться с заранее определенным адресом рандеву (например, как предоставлено в приложение посредством информации о конфигурации из службы или как закодировано в приложении).

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

[00309] Используя любое соединение, пользователь может облегчить процедуру аутентификации, когда приложение на клиентском устройстве предписывает пользователю сканировать QR-код или другой код, ассоциированный с новым устройством (например, напечатанный на новом устройстве или на карте, предоставляемой с новым устройством) (блок 1842). Пользователь может ввести код путем сканирования или набора кода в приложение (блок 1844). Эта информация кода может быть предоставлена новому устройству, которое может использовать код, чтобы подтвердить, что приложение используется достоверным образом пользователем, владеющим новым устройством. Новое устройство может, например, подтверждать код, используя встроенную контрольную цифру. Новое устройство может указывать, когда код был введен неправильно, соответствующим ответом. Приложение может устанавливать безопасную сессию с новым устройством, используя любой подходящий протокол, в том числе протокол Weave PASE, с помощью прилагаемого парного кода в качестве пароля (блок 1848). Установив безопасное соединение с новым устройством, приложение на клиентском устройстве может выдать запрос на активацию отказоустойчивого режима на новом устройстве (например, ArmConfigurationFailsafe) (блок 1850). Путем активации отказоустойчивого режима, новое устройство может вернуться к некоторым исходным конфигурациям, если процесс присоединения не завершается некоторым значением тайм-аута. Приложение также может определить, принадлежит ли новое устройство другой существующей инфраструктуре 1000, путем выдачи соответствующего запроса (например, GetFabricState) (решающий блок 1852). Если это так, то приложение может предписывать новому устройству покинуть другую существующую инфраструктуру 1000 путем выдачи другого запроса (например, LeaveFabric) (блок 1854).

[00310] В случае, когда новое устройство должно формировать новую инфраструктуру 1000 с существующим устройством (решающий блок 1856), приложение может инструктировать новое устройство перечислить список сетей WiFi, наблюдаемых новым устройством (например, с помощью запроса EnumerateVisibleNetworks) (блок 1858). Согласно инструкции из приложения (блок 1860), затем пользователь может сделать выбор из этих сетей или может ввести сеть WiFi, к которой должно присоединиться новое устройство (блок 1862). Пользователь может также ввести соответствующий пароль, чтобы присоединиться к сети WiFi (блок 1864). Способ может дальше перейти к блоку (В) 1866, который продолжается на фиг. 64. Приложение может послать информацию о конфигурации сети WiFi к новому устройству (например, с помощью запроса AddNetwork) (блок 1868), и приложение может инструктировать новое устройство протестировать соединение (например, через запрос TestNetwork), пытаясь достичь службы по сети Интернет (блок 1870). Приложение может указать пользователю, что сетевое соединение подтверждено (блок 1872), и новое устройство может затем подтвердить свое соединение в приложение (блок 1874).

[00311] С новым устройством, теперь соединенным с Интернетом через соединение WiFi, если создается новая инфраструктура 1000 (блок 1876), приложение может инструктировать пользователя вернуться к соединению WiFi инфраструктуры 1000 (например, дома пользователя) (блок 1878). Пользователь может изменить сеть WiFi, используемую клиентским устройством, на соединение WiFi, используемое инфраструктурой 1000 (блок 1880).

[00312] Независимо от того, создается ли новая инфраструктура 1000 или осуществляется присоединение к уже существующей инфраструктуре, приложение может инструктировать новое устройство, чтобы выполнять это в данный момент (блок 1882). То есть, приложение может инструктировать новое устройство создать новую инфраструктуру 1000 (например, через запрос CreateFabric) или может инструктировать новое устройство присоединиться к существующей инфраструктуре 1000 (например, через запрос JoinExistingFabric). В случае присоединения к существующей инфраструктуре, приложение может информировать новое устройство о существующем устройстве (например, через запрос RegisterNewFabricMember к новому устройству). В любом случае, приложение может сконфигурировать новое устройство для осуществления связи со службой (например, службой Nest®) путем отправки запроса (например, запроса RegisterService), который содержит информацию о конфигурации службы (например, информацию о конфигурации службы Weave^TM).

[00313] Используя информацию о конфигурации службы, новое устройство может зарегистрироваться в службе (блок 1884). Например, новое устройство может подключиться к службе, используя ID узла службы и имя DNS из информации о конфигурации службы. Новое устройство может зарегистрироваться в службе, используя сертификат, установленный на новом устройстве, и частный ключ. Новое устройство может отправить сообщение (например, сообщение PairDeviceToAccount) к службе, содержащее идентификацию учетной записи службы, ассоциированную с инфраструктурой 1000, и маркер сопряжения с учетной записью, полученный из информации о конфигурации службы. Используя эту информацию, служба может подтвердить маркер сопряжения с учетной записью и может ассоциировать новое устройство с учетной записью службы пользователя, ассоциированной с инфраструктурой. В этот момент, новое устройство может интерпретироваться службой как часть инфраструктуры 1000 и может представляться в качестве ассоциированного устройства, когда пользователь входит в службу. Служба может ответить на сообщение от нового устройства (например, сообщение PairDeviceToAccount), может уничтожить свою копию маркера сопряжения с учетной записью и может ответить на сообщение, отправленное ранее в приложение (например, запрос RegisterService).

[00314] В ответ, чтобы завершить присоединение нового устройства к существующей инфраструктуре 1000 или новой инфраструктуре, приложение может отменить механизм отказоустойчивого присоединения путем отправки соответствующего сообщения на новое устройство (например, запроса DisarmConfigurationFailsafe) (блок 1886). Новое устройство может затем принять этот запрос, чтобы отменить отказоустойчивую конфигурацию (блок 1888). Сопряжение нового устройства с существующим устройством в новой инфраструктуре 1000 или существующей инфраструктуре 1000 теперь можно считать завершенным. Приложение на клиентском устройстве, таким образом, может предоставить пользовательские инструкции для дополнительных настроек установки (блок 1890), из которых пользователь может выбрать (блок 1892). Они могут включать, например, продолжение сопряжения дополнительных устройств или выход из режима установки.

Присоединение или создание инфраструктуры без соединения WiFi с сетью Интернет

[00315] Новое устройство может присоединиться или создать инфраструктуру 1000 без обязательного наличия доступа к соединению WiFi со службой или Интернетом. Например, как показано на фиг. 65-67, такое соединение может быть образовано с помощью другого сетевого соединения без содействия со стороны службы (например, по соединению сети 802.15.4). В этом разделе описываются действия и события, которые могут произойти в процессе присоединения нового устройства в инфраструктуру от устройства к устройству. Используемый здесь термин “инфраструктура от устройства к устройству” представляет собой сеть из двух или более устройств инфраструктуры 1000, соединенных через один сетевой интерфейс (например, только через интерфейсы 802.15.4). Устройства в инфраструктуре 1000 от устройства к устройству не должны обязательно соединяться с сетью WiFi и, таким образом, не могут взаимодействовать с приложением (например, веб или мобильным), исполняемым на клиентском устройстве (как на фиг. 62-64), или со службой по сети Интернет (например, службой Nest®).

[00316] В некоторых случаях, инфраструктуры от устройства к устройству может быть проще сформировать, чем инфраструктуры WiFi, связывая участие пользователя только с тем, что пользователь может нажимать кнопки на двух устройствах в течение короткого периода времени. Процесс соединения от устройства к устройству, описанный на фиг. 65-67, может поддерживать как создание новой инфраструктуры 1000 от устройства к устройству, используя два независимых устройства, так и присоединение нового независимого устройства к существующей инфраструктуре от устройства к устройству. Соединение от устройства к устройству также может быть использовано для удаления устройства из существующей инфраструктуры 1000 от устройства к устройству и присоединения его к другой инфраструктуре от устройства к устройству. Этот последний сценарий может стать особенно полезным, когда пользователь приобретает подержанный прибор, который не был должным образом отделен от своей старой инфраструктуры от устройства к устройству.

[00317] Следует отметить, что процесс присоединения от устройства к устройству не может быть использован для соединения нового устройства в существующую WiFi инфраструктуру 1000 в некоторых вариантах осуществления. Для этого, пользователь может следовать процессу соединения с WiFi, описанному выше со ссылкой на фиг. 62-64. Кроме того, процесс присоединения от устройства к устройству не могут быть использован, чтобы присоединить устройство, которое уже является членом WiFi инфраструктуры 1000, в инфраструктуру от устройства к устройству. Таким образом, в случае, когда пользователь приобретает подержанный прибор, который не был должным образом отделен от своей первоначальной WiFi инфраструктуры, пользователь может выполнить сброс настроек на устройстве, прежде чем приступить к процессу присоединения к инфраструктуре 1000 от устройства к устройству.

[00318] Процесс присоединения от устройства к устройству может начаться, когда, как показано на блок-схеме 1900 последовательности операций на фиг. 65, первое устройство (например, устройство 1) из двух устройств, которые должны быть соединены, активируется (блок 1902). Например, на основании инструкций в окне продаж первого устройства, пользователь может нажать кнопку на первом устройстве. Здесь, если пользователь добавляет устройство в существующую инфраструктуру, пользователь может быть проинструктирован, чтобы нажать кнопку на устройстве, которое должно добавляться. Если пользователь создает новую инфраструктуру 1000 из двух независимых устройств, пользователь может выбрать любое устройство в качестве первого устройства. Кроме того, если первое устройство является членом WiFi инфраструктуры, первое устройство может не предпринимать никаких дальнейших действий, и процедура присоединения останавливается. Когда первое устройство является членом WiFi инфраструктуры, первое устройство может быть отсоединено от WiFi инфраструктуры 1000 перед присоединением к сети от устройства к устройству (например, путем сброса заводских установок).

[00319] Когда первое устройство не является членом существующей WiFi инфраструктуры, первое устройство (например, устройство 1) может начать процедуры инициализации при активации, как в блоке 1902. Например, устройство 1 может запустить счетчик, который увеличивает отсчет во времени (например, несколько раз в секунду). Этот счетчик в дальнейшем будут использован для определения того, какое устройство из двух устройств имеет приоритет в создании инфраструктуры, если это необходимо. Устройство 1 также может создать беспроводную сеть 802.15.4, которая может быть названа соединяющей сетью 802.15.4 (блок 1904). Эта соединяющая сеть 802.15.4 может быть в общем уникальной, незащищенной сетью. Например, соединяющая сеть 802.15.4 может использовать в общем уникальное имя сети ELoWPAN 110, содержащее следующую информацию: (а) строка, идентифицирующая сеть как соединяющую сеть, (b) id узла первого устройства и (с) флаг, указывающий, является ли устройство частью инфраструктуры. Когда соединяющая сеть установлена, устройство 1 также может назначить себе два IPv6-адреса в соединяющей сети (блок 1906). Они могут включать в себя, например: (а) IPv6 ULA или EULA с отличающимся префиксом, который может быть назван префиксом рандеву, и идентификатор интерфейса, полученный из MAC-адреса устройства, и (b) IPv6 ULA или EULA с префиксом рандеву и идентификатор интерфейса 1, который может быть назван адресом рандеву.

[00320] Устройство 1 затем может непрерывно сканировать сеть 802.15.4, созданную другим устройством (блок 1908). Действительно, параллельно или после действий блоков 1902-1908, второе устройство (устройство 2) может выполнять само вышеуказанные действия (блок 1910). Либо устройство 1, либо устройство 2 может обнаружить соединяющую сеть у соответствующего другого устройства (блок 1912). В зависимости от некоторых характеристик устройства - устройства 1 или устройства 2, - которое является первым для обнаружения другого, устройства могут выполнять процесс инициирующего устройства (например, как показано на фиг. 66) или процесс отвечающего устройства (например, как показано на фиг. 67). То есть, когда одно из устройств обнаруживает соединяющую сеть другого, устройство сравнивает информацию, содержащуюся в имени соединяющей сети, с его собственной информацией и может предпринимать следующие действия: (а) если устройство является независимым устройством, а другое устройство является членом инфраструктуры, устройство может выполнять действия, показанные в процессе инициирующего устройства на фиг. 66; или (b) если устройство является членом инфраструктуры 1000, а другое устройство является независимым устройством, устройство может выполнять действия, показанные процессом отвечающего устройства на фиг. 67. Если ни одно устройство не является членом инфраструктуры, или если оба устройства являются членами инфраструктуры, устройство, которое обнаруживает соединяющую сеть другого устройства, может (а) сравнивать свой id узла с id узла другого устройства, и (b) если id узла устройства меньше, чем id узла другого устройства, устройство может выполнять действия из действий, указанных в процессе инициирующего устройства на фиг. 66. Если ни одно устройство не является членом инфраструктуры, или если оба устройства являются членами инфраструктуры, устройство, которое обнаруживает соединяющую сеть другого устройства, может (а) сравнивать свой id узла с id узла другого устройства, и (b) если id узла устройства больше, чем id узла другого устройства, может выполнять действия, показанные процессом отвечающего устройства на фиг. 67.

[00321] Устройство, которое выполняет процесс инициирующего устройства по фиг. 66, может быть либо устройством 1, либо устройством 2, как упоминалось выше. Таким образом, устройство, которое выполняет процесс инициирующего устройства по фиг. 66, теперь будет называться “инициирующим устройством”. Аналогичным образом, устройство, которое выполняет процесс отвечающего устройства по фиг. 67, может быть устройством, не работающим как инициирующее устройство, и может быть либо устройством 1, либо устройством 2, как упоминалось выше. Таким образом, устройство, которое выполняет процесс отвечающего устройства по фиг. 67, будет называться “отвечающим устройством”.

[00322] Как видно из блок-схемы 1920 последовательности операций, процесс инициирующего устройства на фиг. 66 может начаться, когда инициирующее устройство завершает свое присоединение к сети и соединяется с соединяющей сетью, созданной отвечающим устройством (блок 1922). Инициирующее устройство может назначить себе IPv6 ULA или EULA с префиксом рандеву и идентификатором интерфейса, полученным из своего МАС-адреса (блок 1924). Инициирующее устройство может отправить сообщение побуждения к присоединению к отвечающему устройству на его адрес рандеву. Сообщение побуждения к присоединению от инициирующего устройства может включать в себя следующую информацию: (а) числовое значение дискриминатора, установленное в значение счетчика, который был запущен, когда устройство было активировано, и (b) флаг, указывающий, является ли устройство уже членом инфраструктуры. Затем инициирующее устройство может ожидать ответного сообщения от отвечающего устройства, принимая либо запрос на присоединение к существующей инфраструктуре, либо запрос на побуждение к присоединению (блок 1928).

[00323] Когда инициирующее устройство принимает запрос на присоединение к существующей инфраструктуре, инициирующее устройство может покинуть свою текущую инфраструктуру, при необходимости, и может повторно инициализировать себя в качестве независимого устройства, и может сделать себя частью существующей инфраструктуры 1000 с отвечающим устройством, используя информацию в запросе на присоединение к существующей инфраструктуре (блок 1930). Инициирующее устройство может отправить ответ присоединения к существующей инфраструктуре к отвечающему устройству, указывая, что оно сейчас является членом существующей инфраструктуры 1000 (блок 1932).

[00324] Когда инициирующее устройство принимает запрос на побуждение к присоединению, инициирующее устройство может ответить различным образом в зависимости от того, является ли оно независимым устройством или членом существующей инфраструктуры, но в любом случае может послать информацию об инфраструктуре 1000 в запросе на присоединение к существующей инфраструктуре (блок 1934). Например, когда инициирующее устройство является независимым устройством, инициирующее устройство может создать новую инфраструктуру 1000 путем генерации id новой инфраструктуры и соответствующей информации безопасности инфраструктуры, может сделать себя частью новой инфраструктуры и может послать запрос на присоединение к существующей инфраструктуре к отвечающему устройству. Запрос на присоединение к существующей инфраструктуре может содержать информацию для новой инфраструктуры. В противном случае, если устройство является членом инфраструктуры, устройство может отправить запрос на присоединение к существующей инфраструктуре к отвечающему устройству, который содержит информацию для существующей инфраструктуры 1000, членом которой является инициирующее устройство. Затем инициирующее устройство может ожидать и принимать ответ присоединения к существующей инфраструктуре от отвечающего устройства, когда отвечающее устройство присоединяется к инфраструктуре 1000 инициирующего устройства.

[00325] Процесс отвечающего устройства по фиг. 67 описывает способ, которым отвечающее устройство может действовать в отношении инициирующего устройства. Процесс отвечающего устройства по фиг. 67 описывается блок-схемой 1950 последовательности операций. Блок-схема 1950 последовательности операций начинается, когда отвечающее устройство принимает сообщение побуждения к присоединению от инициирующего устройства (блок 1952).

[00326] Если отвечающее устройство является независимым устройством и не находится в существующей инфраструктуре 1000 (решающий блок 1954), отвечающее устройство может создать новую инфраструктуру 1000 путем генерации id новой инфраструктуры и соответствующей информации безопасности инфраструктуры (блок 1956). Отвечающее устройство может сделать себя частью новой инфраструктуры 1000 (блок 1958). Отвечающее устройство может затем послать запрос на присоединение к существующей инфраструктуре к инициирующему устройству, который содержит информацию для новой инфраструктуры 1000 отвечающего устройства (блок 1960). Отвечающее устройство может ожидать ответа присоединения к существующей инфраструктуре от инициирующего устройства.

[00327] В противном случае, после принятия сообщения побуждения к присоединению (блок 1952), если отвечающее устройство находится в существующей инфраструктуре 1000 (решающий блок 1954), отвечающее устройство может принять другое поведение. В частности, если отвечающее устройство находится в инфраструктуре, отвечающее устройство может проанализировать сообщение побуждения к присоединению (блок 1962). Отвечающее устройство может проанализировать значение дискриминатора (значение счетчика инициирующего устройства) и флаг “является членом инфраструктуры” в сообщении побуждения к присоединению.

[00328] В противном случае, если сообщение побуждения к присоединению указывает, что инициирующее устройство не является членом инфраструктуры 1000, или если значение дискриминатора больше или равно счетчику, запущенному отвечающим устройством при его активации (решающий блок 1964), отвечающее устройство может послать запрос на присоединение к существующей инфраструктуре к инициирующему устройству, который содержит информацию для инфраструктуры 1000 отвечающего устройства (блок 1974). Отвечающее устройство может ожидать ответа присоединения к существующей инфраструктуре от инициирующего устройства.

[00329] Если сообщение побуждения к присоединению указывает, что инициирующее устройство является членом инфраструктуры 1000, или если значение дискриминатора меньше, чем счетчик, запущенный отвечающим устройства при его активации (решающий блок 1964), отвечающее устройство может покинуть свою текущую инфраструктуру 1000 и повторно инициализирует себя в качестве независимого устройства (блок 1966). Отвечающее устройство может дополнительно отправить сообщение побуждения к присоединению к инициирующему устройству (блок 1968) и может ожидать запроса на присоединение к существующей инфраструктуре от инициирующего устройства. После приема запроса на присоединение к существующей инфраструктуре от инициирующего устройства (блок 1970), отвечающее устройство может сделать себя частью новой инфраструктуры 1000, используя информацию в запросе на присоединение к существующей инфраструктуре (блок 1972). Отвечающее устройство также может отправить ответ присоединения к существующей инфраструктуре, указывающий, что оно сейчас является членом существующей инфраструктуры 1000 инициирующего устройства.

[00330] Конкретные варианты осуществления, описанные выше, были показаны в качестве примера, и следует понимать, что эти варианты осуществления могут быть восприимчивы к различным модификациям и альтернативным формам. Следует также понимать, что формула изобретения не предназначена, чтобы ограничиваться конкретными раскрытыми формами, а скорее охватывает модификации, эквиваленты и альтернативы, попадающие в рамки сущности и объема настоящего раскрытия.

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

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

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

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

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

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

2. Считываемый компьютером носитель по п. 1, в котором код состояния содержит кодированное значение для указания состояния, о котором предоставляется отчет.

3. Считываемый компьютером носитель по п. 1, в котором поле профиля содержит поле Id профиля и поле Id поставщика.

4. Считываемый компьютером носитель по п. 3, в котором поле Id профиля содержит два байта данных и поле Id поставщика содержит два байта данных.

5. Считываемый компьютером носитель по п. 3, в котором код состояния интерпретируется в отношении поля Id профиля и поля Id поставщика.

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

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

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

9. Считываемый компьютером носитель по п. 1, в котором один или более кодов состояния связан с профилем.

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

11. Электронное устройство, содержащее:

сетевой интерфейс для связи с инфраструктурной сетью;

процессор; и

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

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

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

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

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

12. Электронное устройство по п. 11, в котором поле профиля содержит поле Id профиля и поле Id поставщика.

13. Электронное устройство по п. 12, в котором поле Id профиля содержит два байта данных и поле Id поставщика содержит два байта данных.

14. Электронное устройство по п. 12, в котором код состояния интерпретируется в отношении поля Id профиля и поля Id поставщика.

15. Электронное устройство по п. 11, в котором код состояния содержит кодированное значение для указания состояния, о котором предоставляется отчет.

16. Электронное устройство по п. 11, причем электронное устройство является дверным звонком, при этом процессор дверного звонка сконфигурирован для передачи сообщения в формате отчетности о состоянии другому электронному устройству инфраструктурной сети, при этом другим устройством является камера.

17. Электронное устройство по п. 11, причем электронное устройство является дверным звонком, при этом процессор дверного звонка сконфигурирован для передачи сообщения в формате отчетности о состоянии другому электронному устройству инфраструктурной сети, при этом другим устройством является система безопасности.

18. Электронное устройство по п. 11, причем электронное устройство является переключателем освещения, при этом процессор переключателя освещения сконфигурирован для передачи сообщения в формате отчетности о состоянии другому электронному устройству инфраструктурной сети, при этом другим устройством является вентилятор.

19. Электронное устройство по п. 11, причем электронное устройство является переключателем освещения, при этом процессор переключателя освещения сконфигурирован для передачи сообщения в формате отчетности о состоянии другому электронному устройству инфраструктурной сети, при этом другим устройством является камера.

20. Электронное устройство по п. 11, причем электронное устройство является интерфейсом штепсельной вилки, при этом процессор интерфейса штепсельной вилки сконфигурирован для передачи сообщения в формате отчетности о состоянии другому электронному устройству инфраструктурной сети, при этом другим устройством является блок обнаружения опасности.

21. Электронное устройство по п. 11, причем электронное устройство является датчиком, при этом процессор датчика сконфигурирован для передачи сообщения в формате отчетности о состоянии другому электронному устройству инфраструктурной сети, при этом другим устройством является сигнализация.

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

23. Электронное устройство по п. 11, в котором один или более кодов состояния связан с профилем.

24. Электронное устройство по п. 11, в котором один или более профилей связан с электронным устройством.

25. Способ передачи состояния работоспособности электронного устройства по инфраструктурной сети, содержащий этапы, на которых:

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

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

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

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

26. Способ по п. 25, в котором код состояния содержит кодированное значение для указания состояния, о котором предоставляется отчет.

27. Способ по п. 25, в котором поле профиля содержит поле Id профиля и поле Id поставщика.

28. Способ по п. 27, в котором поле Id профиля содержит два байта данных и поле Id поставщика содержит два байта данных.

29. Способ по п. 27, в котором код состояния интерпретируется в отношении поля Id профиля и поля Id поставщика.

30. Способ по п. 25, в котором электронное устройство является нагревателем бассейна, причем способ содержит передачу, посредством нагревателя бассейна, сообщения в формате отчетности о состоянии на систему орошения.

31. Способ по п. 25, в котором электронное устройство является стиральной машиной, причем способ содержит передачу, посредством стиральной машины, сообщения в формате отчетности о состоянии на сушилку.

32. Способ по п. 25, в котором электронное устройство является потолочным вентилятором, причем способ содержит передачу, посредством потолочного вентилятора, сообщения в формате отчетности о состоянии на кондиционер.

33. Способ по п. 25, в котором электронное устройство является системой безопасности, причем способ содержит передачу, посредством системы безопасности, сообщения в формате отчетности о состоянии на освещение.

34. Способ по п. 25, в котором электронное устройство является телевизором, причем способ передачи, посредством телевизора, сообщения в формате отчетности о состоянии на другое электронное устройство инфраструктурной сети, причем другим электронным устройством является планшет.

35. Способ по п. 25, в котором один или более кодов состояния связан с профилем.

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