Инфраструктурная сеть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0071] Сетевой интерфейс 18 может включать в себя один или более компонентов, которые позволяют устройству 10 осуществлять связь между устройствами с использованием одной или более логических сетей в инфраструктурной сети. В одном варианте осуществления сетевой интерфейс 18 может осуществлять связь с использованием эффективного сетевого уровня как части его модели взаимодействия открытых систем (OSI). В некоторых вариантах осуществления один компонент сетевого интерфейса 18 может осуществлять связь с одной логической сетью (например, WiFi), а другой компонент сетевого интерфейса может осуществлять связь с другой логической сетью (например, 802.15.4). Другими словами, сетевой интерфейс 18 может позволять устройству 10 осуществлять беспроводную связь через множество IPv6-сетей. Таким образом, сетевой интерфейс 18 может включать в себя беспроводную карту, порт Ethernet и/или другие подходящие соединения приемопередатчика.

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

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

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

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

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

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

[0078] Примерные устройства 10 могут включать в себя подключенный к сети термостат 46, который может обнаруживать климатические характеристики окружающей среды (например, температуру и/или влажность) и управлять системой 48 отопления, вентиляции и кондиционирования воздуха (HVAC). Другое примерное устройство 10 может включать в себя блок 50 обнаружения опасности, который может обнаруживать присутствие опасного вещества и/или опасной ситуации в домашней среде 30 (например, дыма, огня или угарного газа). Кроме того, интерфейсные устройства 52 передней (входа), которые могут определяться понятием “интеллектуальный дверной звонок”, могут обнаруживать приближение или удаление человека от данного места, управлять звуковой функцией, оповещать о приближении или удалении человека с помощью аудио или визуальных средств или управлять настройками на системе безопасности (например, чтобы активировать или деактивировать систему безопасности).

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

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

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

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

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

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

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

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

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

[0088] Сетевой уровень 96 может определять, каким образом маршрутизируются данные, передаваемые в узел-получатель. Сетевой уровень 96 может также обеспечивать протокол безопасности, который может поддерживать целостность передаваемых данных. Эффективный сетевой уровень, обсужденный выше, соответствует сетевому уровню 96. В некоторых вариантах осуществления, сетевой уровень 96 может быть полностью независимым от уровня 100 платформы и включать любой подходящий тип IPv6 сети (например, WiFi, Ethernet, HomePlug, 802.15.4 и т.д.).

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

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

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

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

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

[0092] Фиг. 4 иллюстрирует вариант осуществления инфраструктуры 1000, имеющей топологию одиночной сети. Как показано, инфраструктура 1000 включает в себя одиночную логическую сеть 1002. Сеть 1002 может включать в себя Ethernet, WiFi, 802.15.4, сети на линиях питания и/или другие подходящие типы сетей в протоколах IPv6. В самом деле, в некоторых вариантах осуществления, когда сеть 1002 включает в себя сеть WiFi или Ethernet, сеть 1002 может охватывать несколько сегментов Wi-Fi и/или 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. Звездообразная сетевая топология

[0094] На фиг. 5 показан альтернативный вариант осуществления инфраструктуры 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 включают в себя несколько периферийных сетей того же типа.

[0095] Хотя проиллюстрированная инфраструктура 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. Топология перекрывающихся сетей

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

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

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

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

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

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

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

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

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

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

[00103] 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 инфраструктуры остается, пока инфраструктура не будет аннулирована.

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

[00105] Наконец, 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. Маршрутизация передач между логическими сетями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[00129] В некоторых вариантах осуществления 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 узла-получателя

[00130] 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 ключа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b. URI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

i. SendInit

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

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

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

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

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

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

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

ii. SendAccept

[00204] Сообщение принятия передачи передается от ответчика, чтобы указать режим пересылки, выбранный для пересылки. Вариант осуществления сообщения SendAccept 1500 представлен на фиг. 47. Сообщение 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

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

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

iv. ReceiveInit

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

v. ReceiveAccept

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

vi. ReceiveReject

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

vii. BlockQuery

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

viii. Block

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

ix. BlockEOF

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

x. Ack

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

xi. AckEOF

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

xii. Error

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

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

1. Электронное устройство, сконфигурированное для осуществления связи в инфраструктурной сети, содержащее:

память для хранения инструкций;

систему обработки, коммуникационно связанную с памятью, причем система обработки выполнена с возможностью:

генерировать сообщение запроса просмотра, причем сообщение запроса просмотра содержит:

ID транзакции, приспособленный идентифицировать запрашиваемый просмотр, и

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

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

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

ID транзакции, переданный в запросе просмотра через инфраструктурную сеть, и

состояние запроса просмотра, приспособленное указывать состояние запроса просмотра.

2. Электронное устройство по п.1, при этом запрос просмотра содержит случайное 16-битовое число в качестве ID транзакции.

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

4. Электронное устройство по п.1, при этом список путей содержит двоичный формат профиля, причем двоичный формат профиля содержит поле идентификатора профиля, приспособленное идентифицировать схему профиля пути схемы.

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

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

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

8. Вещественный долговременный машиночитаемый носитель, на котором сохранены инструкции, причем инструкции предназначены:

генерировать сообщение запроса просмотра, причем сообщение запроса просмотра содержит:

ID транзакции, приспособленный идентифицировать запрашиваемый просмотр, и

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

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

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

ID транзакции, переданный в запросе просмотра через инфраструктурную сеть, и

состояние запроса просмотра, приспособленное указывать состояние запроса просмотра.

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

10. Долговременный машиночитаемый носитель по п.8, при этом состояние запроса просмотра отформатировано в соответствии с форматом обновления состояния.

11. Долговременный машиночитаемый носитель по п.8, при этом список путей содержит двоичный формат профиля, причем двоичный формат профиля содержит:

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

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

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

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

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

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

генерируют сообщение запроса просмотра, причем сообщение запроса просмотра содержит:

ID транзакции, чтобы идентифицировать запрашиваемый просмотр, и

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

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

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

ID транзакции, переданный в запросе просмотра через инфраструктурную сеть, и

состояние запроса просмотра, приспособленное указывать состояние запроса просмотра.

16. Способ по п.15, в котором запрос просмотра содержит случайное 16-битовое число в качестве ID транзакции.

17. Способ по п.15, в котором список путей содержит тег, длину и значение, чтобы указывать путь схемы.

18. Способ по п.15, в котором список путей содержит двоичный формат профиля, причем двоичный формат профиля содержит поле идентификатора профиля, приспособленное идентифицировать схему профиля пути схемы.

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

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