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

Иллюстрации

Показать все

Обеспечены способ функционирования шлюза управления устройствами (DM) в системе связи, включающей в себя шлюз DM, сервер DM и конечное устройство, которым сервер DM не может непосредственно управлять, чтобы обеспечить возможность управления устройством посредством сервера DM, через шлюз DM, способ для шлюза DM в системе связи для обновления информации начальной загрузки для некоторого класса устройств, способ для шлюза DM в системе связи для обрабатывания команд DM, способ для шлюза DM в системе связи для обрабатывания сообщений о прерывании, способ для шлюза DM в системе связи для обрабатывания периодического информационного сообщения об услугах/возможностях и способ для шлюза DM в системе связи для обрабатывания окончания интервала контроля времени. Способ функционирования шлюза DM в системе связи, включающей в себя шлюз DM, сервер DM и устройство, включает в себя прием шлюзом DM информационного сообщения об услугах/возможностях от устройства, определение шлюзом DM одной или более характеристик устройства на основании информации, включенной в принятое информационное сообщение об услугах/возможностях, и активизирование шлюзом DM алгоритма на основании определяемой одной или более характеристик устройства, при этом шлюз DM функционирует в соответствии с активизированным алгоритмом так, чтобы сервер DM мог впоследствии управлять устройством, отправляя команды управления на устройство, через шлюз DM, и обрабатывая предупреждения, принимаемые от устройства, через шлюз DM. 7 н. и 21 з.п. ф-лы, 13 ил.

Реферат

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

Настоящее изобретение относится к управлению устройствами (DM) в системе связи. Более конкретно, настоящее изобретение относится к методикам управления функциональными возможностями шлюзов для поддержки DM в системе связи.

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

С повсеместным ростом технологий и систем связи увеличиваются функциональные возможности и сложность устройств. Однако с увеличением функциональных возможностей и сложности устройств проявляется потребность в управлении этими устройствами. В ответ на такую потребность открытый союз связи с мобильными объектами (ОМА) установил Рабочую группу управления устройствами (DM), чтобы определить протоколы и механизмы, которые осуществляют управление устройствами. Рабочая группа DM ОМА разработала спецификацию OMA-DM, которая определяет двухсторонний протокол между сервером DM и программой-клиентом DM, связанной с устройством, который используется для дистанционного управления устройством. Пример связи между сервером DM и программой-клиентом DM упоминается как сеанс связи DM и может инициироваться либо программой-клиентом DM, либо сервером DM. Программа-клиент DM постоянно находится в устройстве, и сервер DM управляет устройством, активизируя команды в программе-клиенте DM. Программа-клиент DM обрабатывает команду и отсылает ответ обратно на сервер DM. Установление связи между сервером и программой-клиентом содержит обмен сообщениями маркировочного языка синхронизации (SyncML). Исторически устройства были беспроводными устройствами, но в последнее время OMA-DM также начал обращаться к потребностям дистанционного управления проводных устройств. Примеры OMA-DM включают в себя установку информации о начальной конфигурации в устройствах, последующую инсталляцию и обновление перманентной информации в устройствах, извлечение информации управления из устройств и обработку событий и аварийных сигналов, генерируемых устройствами.

Пример архитектуры OMA-DM описывается ниже со ссылкой на фиг.1.

Фиг.1 иллюстрирует архитектуру OMA-DM в соответствии с предшествующим уровнем техники.

Что касается фиг.1, то на ней архитектура OMA-DM включает в себя сервер 140 DM, программу-клиента 110 DM и объекты управления (MO) 120 стандарта DM. Программа-клиент 110 DM и объекты MO 120 стандарта DM совместно размещены в устройстве 100. Архитектура OMA-DM может включать в себя дополнительные структурные элементы. Однако описание дополнительных структурных элементов архитектуры OMA-DM для краткости опущено.

Сервер 140 DM и программа-клиент 110 DM, которые были описаны выше, осуществляют связь через сопряжения DM-1 130 и DM-2 132. Программа-клиент 110 DM осуществляет связь через сопряжение DM-5 134 с объектами MO 120 стандарта DM.

Протокол DM определяет три объекта управления (MO) 120 стандарта DM, которые должны поддерживать все реализации программы-клиента 110 DM. Эти объекты MO 120 стандарта DM включают в себя MO 122 учетной записи (Acc) DM (DMACC MO), MO 124 информации об устройстве (DevInfo) и MO 126 деталей устройства (DevDetail).

MO 122 Acc DM используется для управления информацией, имеющей отношение к серверам 140 DM с самозагрузкой. Для каждого сервера 140 DM, который был успешно загружен для устройства 100 DM, MO 122 Acc DM поддерживает информацию об идентификаторе сервера DM (ID), информацию о возможности соединения, адрес сервера, верительные данные сервера и программы-клиента и т.д. MO 124 DevInfo обеспечивает основную информацию об устройстве 100, связанном с программой-клиентом 110 DM. Основная информация включает в себя ID устройства, ID изготовителя устройства, ID модели и настройки языков. MO 126 DevDetail обеспечивает дополнительную информацию об устройстве 100, связанном с программой-клиентом 110 DM. Дополнительная информация включает в себя тип устройства, производителя оригинального оборудования (OEM), модификацию аппаратного обеспечения, модификацию микропрограммного обеспечения, модификацию программного обеспечения, индикацию относительно того, поддерживает ли устройство 100 дополнительные функции (например, возможность манипулирования большими объектами), максимальную глубину дерева управления, максимальную полную длину любого унифицированного идентификатора ресурса (URI) и максимальную полную длину любого сегмента URI.

Пример системы связи, применяющей OMA-DM, описывается ниже в отношении фиг.2.

Фиг.2 иллюстрирует примерную систему связи, применяющую OMA-DM в соответствии с предшествующим уровнем техники.

Что касается фиг.2, то на ней примерная система связи, применяющая OMA-DM, может включать в себя проводную сеть 200, беспроводную сеть 202, проводное устройство 210, беспроводное устройство 212, сервер 220 DM и орган 230 управления DM. Каждое из проводного устройства 210 и беспроводного устройства 212 связано с программой-клиентом DM (не показано). Кроме того, орган 230 управления DM может быть системой поддержки операций (OSS). На фиг.2 сплошные линии представляют возможность физического соединения, а пунктирные линии представляют возможность логического соединения.

Примерная система связи, применяющая OMA-DM, которая иллюстрируется на фиг.2, является просто одной из многих возможных реализаций. Например, одна из проводной сети 200 и беспроводной сети 202 может быть опущена. В качестве альтернативы, проводная сеть 200 и беспроводная сеть 202 могут быть объединены. Кроме того, хотя сервер 220 DM и орган 230 управления DM показаны подсоединенными к проводной сети 200, в качестве альтернативы один или оба из сервера 220 DM и органа 230 управления DM могут быть подсоединены к беспроводной сети 202.

Чтобы способствовать выполнению OMA-DM в системе связи, иллюстрируемой на фиг.2, между сервером 220 DM и программой-клиентом DM, связанной с беспроводным устройством 212, и между сервером 220 DM и программой-клиентом DM, связанной с проводным устройством 210, используется двухсторонний протокол, основанный на спецификации OMA-DM. Орган 230 управления DM может направлять операции DM программы-клиента DM, связанной с каждым из проводного устройства 210 и беспроводного устройства 212, через сервер 220 DM. В рамках спецификации OMA-DM находится только взаимодействие между сервером 220 DM и программой-клиентом DM, связанной с каждым из проводного устройства 210 и беспроводного устройства 212.

Пример инициируемого сервером DM сеанса связи DM с программой-клиентом DM описывается ниже в отношении фиг.3.

Фиг.3 представляет схему прохождения сигнала для инициируемого сервером DM сеанса связи DM с программой-клиентом DM в системе связи в соответствии с предшествующим уровнем техники.

Что касается фиг.3, то на ней инициируемый сервером DM сеанс связи DM между сервером 302 DM и программой-клиентом 304 DM включает в себя две фазы. Первая фаза представляет собой фазу 310 настройки, а вторая фаза представляет собой фазу 320 управления. Фаза 310 настройки включает в себя обмен информацией для аутентификации и информацией об устройстве. Обмен информацией в фазе 310 настройки включает в себя три пакета, каждый из которых может содержать множество сообщений, а именно Пакет 0 (312), Пакет 1 (314) и Пакет 2 (316). Пакет 0 (312) отправляется от сервера 302 DM программе-клиенту 304 DM и упоминается как уведомляющее сообщение. Пакет 1 (314) отправляется от программы-клиента 304 DM на сервер 302 DM. Пакет 1 (314) включает в себя информацию об инициализации программы-клиента и информацию об устройстве. Информация об инициализации программы-клиента включает в себя верительные данные программы-клиента. Пакет 2 (316) отправляется от сервера 302 DM программе-клиенту 304 DM. Пакет 2 (316) включает в себя информацию об инициализации сервера и начальную операцию управления. Информация об инициализации сервера включает в себя одно или более верительных данных сервера.

Фаза 320 управления включает в себя обмен двумя пакетами, а именно Пакетом 3 (322) и Пакетом 4 (324). Пакет 3 (322) отправляется от программы-клиента 304 DM на сервер 302 DM. Пакет 3 (322) включает в себя ответную информацию программы-клиента на операцию управления, инициированную Пакетом 2 (316). Пакет 4 (324) отправляется от сервера 302 DM программе-клиенту 304 DM. Пакет 4 (324) включает в себя по меньшей мере одну из дополнительной операции управления и одну или более дополнительных команд взаимодействия с пользователем, если сеанс связи DM продолжается вне сообщения 316 Пакета 2. Дополнительные циклы сообщения 322 Пакета 3 и сообщения 324 Пакета 4 могут передаваться между сервером 302 DM и программой-клиентом 304 DM до тех пор, пока сеанс связи DM не завершится.

Применяемая в настоящее время версия стандарта OMA-DM представляет собой версию 1.2.1. Рабочая группа OMA-DM в настоящее время разрабатывает две новые версии протокола DM, а именно версию 1.3 OMA-DM и версию 2.0 OMA-DM. Версия 1.3 OMA-DM разрабатывается для того, чтобы рассматривать некоторые из слабых мест в системе безопасности в версии 1.2.1 OMA-DM.

Раскрытие сущности изобретения

Техническая проблема

Однако разработка более новых версий OMA-DM ставит некоторые новые проблемы, которые должна рассматривать Рабочая группа DM. Например, в отличие от версии 1.2.1 OMA-DM, устройства, которыми управляют с помощью новых версий OMA-DM, могут не иметь глобально маршрутизируемого адреса. Главная причина для этого состоит в том, что по соображениям безопасности многие из устройств, являющихся целевым объектом в новых версиях OMA-DM, могут быть размещены после устройства, которое обеспечивает функциональные возможности трансляции сетевых адресов (NAT) и/или брандмауэра. Дополнительно, многие из устройств могут быть кочующими, и их адрес контролируется сетью, в которой они размещены. Другая проблема, которую ставят новые версии OMA-DM, состоит в том, что некоторые из устройств могут не иметь встроенной программы-клиента OMA-DM.

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

В отличие от этого, в современной концепции OMA-DM шлюзовое устройство, как ожидают, будет играть главную роль в управлении устройствами в новых версиях OMA-DM. Соответственно, разрабатывается механизм реализации MO шлюза (GwMO) для использования с новыми версиями OMA-DM.

Поэтому существует потребность в методиках управления функциональными возможностями шлюза для поддержки DM в системе связи.

Решение проблемы

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

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

В соответствии с другим аспектом настоящего изобретения обеспечен способ функционирования шлюза DM в системе связи, включающей в себя шлюз DM, сервер DM и устройство. Способ включает в себя прием шлюзом DM информационного сообщения об услугах/возможностях от устройства, определение шлюзом DM, поддерживает ли устройство протокол DM, используемый сервером DM, основываясь на информационном сообщении об услугах/возможностях, если определено, что устройство не поддерживает протокол DM, используемый сервером DM, определение, установлен ли флаг информирования сервера DM для устройства на истину в объекте управления (MO) конфигурации (Config) шлюза, и если определено, что флаг информирования сервера DM для устройства установлен на истину, попытку установления связи с сервером DM от имени устройства и обновление атрибута возможности соединения сервера DM для устройства в MO учетной записи устройств локальной сети (LAN).

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

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

В соответствии с другим аспектом настоящего изобретения обеспечен способ для шлюза DM в системе связи для обрабатывания сообщений о прерывании. Способ включает в себя прием шлюзом DM сообщения о прерывании от устройства, определение шлюзом DM, имеется ли запись для устройства в MO учетной записи устройств LAN, если определено, что для устройства в MO учетной записи устройств LAN записи нет, активизирование шлюзом DM одной из роли прокси-сервера и роли адаптации протокола и определение шлюзом DM, имеется ли информация о пункте назначения, идентифицирующая сервер DM в принятом сообщении прерывания, если определено, что для устройства в MO учетной записи устройств LAN запись имеется, определение шлюзом DM, имеется ли информация о пункте назначения, идентифицирующая сервер DM в принятом сообщении прерывания, и если определено, что информация о пункте назначения в принятом сообщении прерывания, идентифицирующем сервер DM, имеется, передачу сообщения о прерывании на сервер DM, идентифицированный в информации о пункте назначения.

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

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

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

Выгодные эффекты от изобретения

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

Краткое описание чертежей

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

фиг.1 иллюстрирует архитектуру открытого союза связи с мобильными объектами (ОМА) - управления устройствами (DM) в соответствии с предшествующим уровнем техники;

фиг.2 иллюстрирует примерную систему связи, применяющую OMA-DM в соответствии с предшествующим уровнем техники;

фиг.3 представляет схему прохождения сигнала для сервера DM, инициируемого сеансом связи DM с программой-клиентом DM в системе связи, в соответствии с предшествующим уровнем техники;

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

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

фиг.6 представляет блок-схему процесса для алгоритма роли прокси-сервера в соответствии с примерным вариантом осуществления настоящего изобретения;

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

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

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

фиг.10 представляет блок-схему процесса для обработки сообщений о прерывании в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения;

фиг.11 представляет блок-схему процесса для обработки периодического сообщения об услугах/возможностях в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения;

фиг.12 представляет блок-схему процесса для обработки сообщения об окончании интервала контроля времени в шлюзе DM в соответствии с примерным вариантом осуществления настоящего изобретения;

фиг.13 представляет блок-схему шлюза DM в соответствии с примерным вариантом осуществления настоящего изобретения.

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

Способ выполнения изобретения

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

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

Должно быть понятно, что формы единственного числа "a", "an" и "the" включают в себя множественные ссылки, если контекст ясно не диктует иначе. Таким образом, например, ссылка на "компонентную поверхность" включает в себя ссылку на одну или более таких поверхностей.

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

Описанные ниже примерные варианты осуществления настоящего изобретения относятся к методикам управления устройствами (DM) в системе связи. Более конкретно, описанные ниже примерные варианты осуществления настоящего изобретения относятся к методикам управления функциональными возможностями шлюза для поддержки DM в системе связи. Хотя методики управления функциональными возможностями шлюза для поддержки DM в системе связи могут быть описаны ниже в контексте версии 2.0 открытого союза связи с мобильными объектами (OMA)-DM (в дальнейшем именуемой как DM 2.0) и/или механизма реализации объекта функционирования шлюза (GwMO), настоящее изобретение также применимо к другому DM или другим версиям OMA-DM и механизмам реализации. Ниже, шлюзовое устройство, предназначенное для поддержки DM в системе связи, упоминается как шлюз DM.

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

Должно быть понятно, что последующее описание может ссылаться на термины, используемые в различных стандартах, только для простоты объяснения. Например, последующее описание может ссылаться на термины, используемые в одном из стандартов ОМА, таких как стандарт OMA-DM. Однако это описание не должно интерпретироваться как ограничиваемое такими стандартами. Независимо от механизма, используемого для управления функциональными возможностями шлюза для поддержки DM в системе связи, для такой возможности выгодно соответствовать стандартизированному механизму.

Ниже описаны различные роли шлюза DM и функциональные возможности новых объектов управления (MO) в соответствии с примерными вариантами осуществления настоящего изобретения.

Роли шлюза DM

Шлюз DM может играть любую из некоторого количества ролей, включающих в себя роль сервера начальной загрузки, роль прокси-сервера и роль адаптации протокола. В роли сервера начальной загрузки шлюз DM отвечает за начальную загрузку программы-клиента DM в устройстве (то есть за установление соединения между сервером DM и программой-клиентом DM, связанной с устройством). Помимо всего прочего, роль сервера начальной загрузки может вызывать отображение локального транспортного адреса устройства в его адрес глобальной сети (WAN). Здесь следует отметить, что адрес локальной сети (LAN) устройства может быть не маршрутизируемым в WAN. Как только соединение между сервером DM и программой-клиентом DM, связанной с устройством, установлено, шлюз DM не играет дальнейшую роль в управлении устройством.

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

В роли адаптации протокола шлюз DM обеспечивает функциональные возможности прокси-сервера, описанные выше. Дополнительно, шлюз DM выполняет адаптацию между собственным протоколом управления устройства и протоколом OMA-DM, который используется сервером DM.

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

Новые функциональные возможности MO

Чтобы учесть различные роли, в которых может функционировать шлюз DM, обеспечены новые функциональные возможности MO в соответствии с примерными вариантами осуществления настоящего изобретения. Новые функциональные возможности MO иллюстрируются в данном описании с помощью новых объектов MO, которые включают в себя MO конфигурации (Config) шлюза и MO учетной записи устройств LAN. Термины "MO Config" и "MO учетной записи устройств LAN" используются просто для удобства в объяснении и могут изменяться в зависимости от системы условных обозначений, принятой основной частью стандартизации. Кроме того, хотя для удобства в объяснении MO Config и MO учетной записи устройств LAN описываются в данном описании как отдельные объекты MO, их совместные функциональные возможности могут быть распределены среди различного количества объектов MO, и/или все или часть их совместных функциональных возможностей могут быть включены в другие объекты MO. Эти новые объекты MO сосредотачиваются на функциональных возможностях, которые должен поддерживать шлюз DM, в то же время оставляя множество деталей, таких как выявление устройств, отображение адресов LAN/WAN, адаптация протокола управления и т.д., для конкретной реализации.

Функциональные возможности MO Config шлюза заключаются в том, чтобы поддерживать профили учетной записи (Acc) DM для различных типов устройств. Каждый профиль Acc DM включает в себя информацию, которая подобна той, что включена в соответствующий MO Acc DM. Информация включает в себя идентификатор (ID) сервера DM, адрес сервера DM и верительные данные. Каждый профиль Acc DM имеет уникальный ID, и множество устройств могут совместно использовать один и тот же профиль Acc DM. Каждый профиль Acc DM может быть определенным для некоторого типа устройств. Для каждого типа устройств, MO Config шлюза может включать в себя Булев флаг, чтобы указывать, нужно ли с сервером (серверами) DM осуществлять связь после выявления нового устройства указанного типа. У сервера DM имеется доступ чтения-записи к MO Config шлюза.

Функциональные возможности MO учетной записи устройств LAN заключаются в том, чтобы поддерживать перечень устройств, которые находятся в LAN и которые обнаруживаются шлюзом DM. Как упомянуто выше, механизм для выявления устройств шлюзом DM оставляется для конкретной реализации. В отличие от MO Config шлюза, сервер DM может иметь доступ только для чтения к MO учетной записи устройств LAN. MO учетной записи устройств LAN заполняется программой-клиентом DM, выполняемой в шлюзе DM, когда шлюз DM обнаруживает новые устройства в LAN. Примеры информации, которую MO учетной записи устройств LAN может поддерживать относительно каждого устройства, обнаруживаемого в LAN, включают в себя один или больше из следующих элементов:

- Тип устройства и/или подтип устройства

- Аппаратный адрес устройства (то есть адрес управления доступом к среде передачи данных (MAC), международный идентификационный номер оборудования подвижной станции (IMEI), ID аппаратуры мобильной связи (MEID) и т.д.)

- ID профиля Acc DM

- Роль, которую играет шлюз DM для этого устройства (то есть сервер начальной загрузки, прокси-сервер или адаптация протокола)

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

- Отображение между адресами сторон WAN и LAN устройства (только для роли сервера начальной загрузки)

- Состояние возможности соединения сервера DM (то есть установлено ли успешно соединение с сервером (серверами) DM)

- Информация о приостановленной транзакции DM.

Функциональные возможности шлюза DM с использованием примерных новых объектов MO

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

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

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

На этапе 404 шлюз DM определяет, соединено ли устройство непосредственно с сервером DM и, таким образом, обходит шлюз DM. В этот момент шлюз DM может определить, соединено ли устройство непосредственно с сервером DM, посредством проверки информации, включенной в информационное сообщение об услугах/возможностях. Дополнительно следует отметить, что устройства, которые непосредственно соединяются с сервером DM (то есть устройства, который обходят шлюз DM), могут не выпускать информационное сообщение об услугах/возможностях. Кроме того, для устройств, которые непосредственно соединяются с сервером DM, шлюз DM может быть не осведомлен о таких устройствах в LAN. Если шлюз DM определяет, что устройство непосредственно соединено с сервером DM и, таким образом, обходит шлюз DM, процесс завершается. В противоположность этому, если шлюз DM определяет, что устройство непосредственно не соединено с сервером DM и, таким образом, не обходит шлюз DM, процесс переходит к этапу 406.

На этапе 406 шлюз DM определяет, поддерживает ли устройство OMA-DM. В этот момент шлюз DM может определить, поддерживает ли устройство OMA-DM, посредством проверки информации, включенной в информационное сообщение об услугах/возможностях. Если шлюз DM определяет, что устройство не поддерживает OMA-DM, на этапе 408 шлюз DM активизирует алгоритм роли адаптации протокола. После этого процесс завершается. Алгоритм роли адаптации протокола описывается более подробно ниже в отношении фиг.7. В противоположность этому, если шлюз DM определяет, что устройство поддерживает OMA-DM, процесс переходит к этапу 410.

На этапе 410 шлюз DM определяет, выполнено ли устройство с возможностью прокси-соединения с сервером DM. В этот момент шлюз DM может определять, выполнено ли устройство с возможностью прокси-соединения с сервером DM, посредством проверки информации, включенной в информационное сообщение об услугах/возможностях. Если шлюз DM определяет, что устройство не выполнено с возможностью прокси-соединения с сервером DM, на этапе 412 шлюз DM активизирует алгоритм роли сервера начальной загрузки. После этого процесс завершается. Алгоритм роли сервера начальной загрузки описывается более подробно ниже в отношении фиг.5. В противоположность этому, если шлюз DM определяет, что устройство выполнено с возможностью прокси-соединения с сервером DM, на этапе 414 шлюз DM активизирует алгоритм роли прокси-сервера. После этого процесс завершается. Алгоритм роли прокси-сервера описывается более подробно ниже в отношении фиг.6.

Здесь следует отметить, что этапы блок-схемы фиг.4 могут быть активизированы в любом порядке. Роль сервера начальной загрузки шлюза DM будет описана ниже в отношении фиг.5.

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

Что касается фиг.5, то на ней шлюз DM на этапе 502 получает адрес стороны WAN для устройства. Шлюз DM может обратиться к любой известной схеме прохождения преобразования сетевых адресов (NAT), такой как простое прохождение протокола пользовательских дейтаграмм через преобразования NAT (STUN), прохождение с использованием NAT ретрансляции (TURN) и т.д., или может использовать для этой цели собственную схему.

На этапе 504 шлюз DM добавляет информацию, имеющую отношение к устройству, к MO учетной записи устройств LAN. На этапе 506 шлюз DM определяет, имеет ли MO Config шлюза информацию начальной загрузки для этого типа устройства. Если шлюз DM определяет, что MO Config шлюза имеет информацию начальной загрузки для этого типа устройства, процесс переходит к этапу 508. На этапе 508 шлюз DM пересылает информацию начальной загрузки на устройство. На этапе 510 шлюз DM может пересылать адрес стороны WAN устройства на устройство. После этого процесс завершается. В противоположность этому, если шлюз DM определяет, что MO Config шлюза не имеет информации начальной загрузки для этого типа устройства, процесс переходит к этапу 512. На этапе 512 шлюз DM может пересылать на устройство только адрес стороны WAN. После этого процесс завершается.

В данном описании этапы 510 и 512 являются необязательными, и, таким образом, один или более из этапов 510 и 512 могут быть опущены. Когда один или больше из этапов 510 и 512 опущены, процесс переходит к следующему этапу.

Роль прокси-сервера шлюза DM будет описана ниже в отношении фиг.6.

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

Что касается фиг.6, то на ней на этапе 602 шлюз DM добавляет информацию, имеющую отношение к устройству, в MO учетной записи устройств LAN. На этапе 604 шлюз DM переходит к начальной загрузке DM устройства собственным адресом шлюза DM. На этапе 606 шлюз DM определяет, содержит ли информационное сообщение об услугах/возможностях, выпущенное устройством, какую-либо информацию начальной загрузки. Если шлюз DM определяет, что информационное сообщение об услугах/возможностях, выпущенное устройством, не содержит какую-либо информацию начальной загрузки, процесс переходит к этапу 608.

На этапе 608 шлюз DM определяет, имеется ли информация начальной загрузки DM для этого типа устройства в MO Config шлюза. Если шлюз DM определяет, что информации начальной загрузки DM для этого типа устройства в MO Config шлюза не имеется, процесс завершается. В противоположность этому, если шлюз DM определяет, что информация начальной загрузки DM для этого типа устройства в MO Config шлюза имеется, процесс переходит к этапу 610. На этапе 610 шлюз DM может обновлять запись для устройства в MO учетной записи устройств LAN со скорректированным ID профиля Acc DM в соответствии с MO Config шлюза. После этого процесс переходит к этапу 616, который дополнительно описывается ниже.

Возвращаясь к этапу 606, отметим, если шлюз DM определяет, что информационное сообщение об услугах/возможностях, выпущенное устройством, содержит информацию начальной загрузки, процесс переходит к этапу 612. На этапе 612 шлюз DM может создавать новый профиль Acc DM в MO Config шлюза. На этапе 614 шлюз DM может обновлять запись устройства в MO учетной записи устройств LAN с новым ID профиля Acc DM. После этого процесс переходит к этапу 616.

На этапе 616 шлюз DM определяет, является ли флаг "информирования сервера DM" для рассматриваемого типа устройства истинным. Если шлюз DM определ