RU2507700C2 - Способ, устройство и система управления мобильностью и эффективного поиска информации в сети связи - Google Patents

Abstract

Изобретение относится к области поиска информации в сети связи, в частности к способу и устройству формирования универсальной наложенной сети для эффективного поиска информации в сети связи. Технический результат - создание динамичной и масштабируемой инфраструктуры сети, в которой мобильные узлы всегда доступны для других равноправных узлов и адресуемые посредством универсальной наложенной одноранговой сети, действующей на верхнем уровне комбинации обеих сетей, и стационарной проводной линии связи и мобильной беспроводной связи Способ содержит этапы: получение (204) в доменном маршрутизаторе (103) запроса на регистрацию от мобильного устройства (106) связи, включающего идентификатор указанного мобильного устройства связи, поиск (205) адреса маршрутизатора следующего перехода (104), связанного с указанным идентификатором, передачу (206) указанного запроса к маршрутизатору следующего перехода (104), получение (210) ответа от маршрутизатора следующего перехода (104), и если ответ содержит адрес домашнего маршрутизатора (104), передачу (211) ответа к мобильному устройству (106) связи, включающего адрес домашнего маршрутизатора (104), причем указанный ответ инициирует создание соединения между мобильным устройством (106) связи и домашним маршрутизатором (104).7 н. и 17 з.п. ф-лы, 17 ил.

Description

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

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

УРОВЕНЬ ТЕХНИКИ

Известно, что в одноранговой модели связи любой узел может действовать как сервер для любого другого узла. Ресурсы сети располагаются путем ввода запроса запрашивающим узлом в одноранговую сеть. Каким образом и с помощью какого протокола находят запрашиваемый ресурс зависит от принципа, используемого в одноранговой сети, например, путем рассылки запроса всем узлам, как в неструктурированных одноранговых сетях, или с помощью распределенного механизма просмотра, как в структурированных одноранговых сетях. Однако общее предположение заключается в том, что все узлы, включая запрашивающий узел, узлы поиска и целевой узел (узлы), являются частью одноранговой сети. Данное предположение ограничивает применение и предоставляет более ограниченный сервис, чем распространенная модель сети Интернет, где предполагается, что можно просмотреть любой зарегистрированный сервер посредством открытой Системы Доменных Имен (DNS). Однако в системе DNS предполагается, что сервер имеет постоянный IP адрес. Благодаря способу, согласно которому работает существующая DNS, с распределенными серверами доменных имен и принципами кэширования, смена адреса не может происходить слишком часто, так как это может привести к тому, что во время проведения изменения сервер будет недоступен.

Динамическая система доменных имен (DDNS) является расширением системы DNS. DDNS обеспечивает обновление в режиме реального времени доменного имени, которое хранится на сервере доменных имен, что позволяет устанавливать доменные имена в сети Интернет компьютеру (серверу) с переменным (т.е. динамическим) IP адресом. Сервис обычно включает провайдера DDNS, который управляет процессом регистрации в DNS и процессом обновления. Пользователь обновляет DNS серверы DDNS провайдера с действующим IP адресом сервера всякий раз, когда обнаружено изменение.

Недостатками данного способа являются вовлеченность DDNS провайдера, а также потенциально длительное время ответа прежде, чем полностью будет выполнено обновление всемирной DNS, в течение которого целевой сервер будет недоступен.

Кроме того, способ не решает проблему, когда хосты расположены вне действия Транслятора Сетевого Адреса (далее по тексту NAT), и таким образом, им назначены IP адреса из частных адресных областей (глобально, без возможности маршрутизации).

Поскольку системы DNS и DDNS сами по себе не могут обеспечить достаточную поддержку мобильности хостов в сети Интернет, были предложены различные способы и технологии. Из уровня техники известно два способа решения проблемы, известные как мобильность сетевого уровня и мобильность верхнего уровня.

Документ "IP Mobility Support for IPv4", IETF RFC 3344, C.Perkins, Ed., August 2002 (запрос на комментарии IETF 3344, август 2002) и документ " Mobility Support in IPv6", IETF RFC 3775, D.Johnson et al., June 2004 (запрос на комментарии IETF 3775, июнь 2004) раскрывают текущий стандарт IETF для мобильности на сетевом уровне. Мобильный IP обеспечивает возможность для мобильного пользователя (мобильный узел или компьютер) поддерживать единственный адрес при совершении переходов между сетями и сетевыми носителями. Каждый мобильный узел всегда идентифицируется по его домашнему адресу, независимо от текущей точки присоединения к сети Интернет, обеспечивая ясную адресацию по отношению к сети и всем другим устройствам. Единственными устройствами, которые должны быть осведомлены о перемещении этого узла, являются мобильное устройство и домашний маршрутизатор, действующий по поручению мобильного устройства. Этот способ зависит от поддержки в IP нижнего слоя вовлеченных сетей, что не всегда имеет место. Для поддержки перемещения NAT требуются дополнительные расширения сообщения мобильного IP протокола (формирование пакета IP-in-UDP). Более того, так как мобильный IP протокол является решением для маршрутизации, которое имеет целью прозрачное взаимодействие с вышележащими уровнями стека Интернет протоколов, он не поддерживает эффективный транспорт прикладных данных, что может оказаться критичным в мобильных средах.

Прикладной уровень сквозной архитектуры мобильности хоста раскрыт в документе "An End-to-End Approach to Host Mobility", A. C. Snoeren and H.Balakrishnan, Boston, MA, August 2000 (Процедура Шестой Ежегодной ACM/IEEE Международной Конференции по мобильным вычислениям и сетям, Бостон, Массачусетс, август 2000). Данный подход использует безопасные обновления системы DNS, связанные с изменением адреса, и ряд опций перемещения присоединения для управления изменениями IP адреса хоста без разрушения сквозного соединения. Подход действительно сквозной, поскольку отсутствуют промежуточные узлы, которые непосредственно вовлечены в поддержку мобильности. Как следствие, инфраструктура сама не предлагает эффективный транспорт данных, зависящий от возможностей конечного хоста. Более того, до тех пор, пока этот подход адресует перемещение присоединения через NAT, он не оказывает явной поддержки для достижения мобильных серверов, расположенных вне действия NAT.

Известный из уровня техники документ "The design and implementation of an intentional naming system", W. Adjie-Winoto et.al, Charleston, SC, December 1999 (17-й Симпозиум ACM по принципам Операционных систем), Чарльстон, Южная Каролина, декабрь 1999) раскрывает обнаружение ресурса и систему поиска службы предоставления услуг для динамических и мобильных сетей устройств и компьютеров, известную как система преднамеренного присвоения имен (далее по тексту INS). INS использует отдельный язык, основанный на атрибутах и значениях его имен, и осуществляет механизм позднего соединения, который интегрирует поиск адреса по имени и выбор маршрута сообщения, предоставляя клиентам возможность продолжить общаться с конечными узлами, даже если отображение имени к адресу изменяется в ходе сеанса. Таким образом, для архитектуры INS требуются специальные преобразователи имен для формирования одноранговой сети прикладного уровня.

Существует способ справиться с мобильными сетями и сетями MANET (сокращение от mobile ad-hoc networks), который состоит в применении межуровневой оптимизации для того, чтобы создать одноранговую наложенную структуру маршрутизации, осведомленную о том, что основная сеть имеет свойство изменяться. Данный подход использован в Мобильном Одноранговом протоколе, раскрытом в документах "Performance Evaluation of the Mobile Peer-to-Peer Protocol", I. Graber, R Schollmeier and W. Kellerer, (GP2PC2004), 2004 (Четвертая Международная Конференция по глобальным и одноранговым вычислениям) и "Mobile Peer-to-Peer Networking", W. Kellerer, R. Schollmeier, I. Gruber и F. Niethammer, патент WO2005041534, 2004. Согласно данному подходу межуровневая коммуникация используется для того, чтобы связать уровень маршрутизации с нижележащим физическим уровнем. Данный способ предполагает межуровневые связи, таким образом делая возможным его применение. Вопрос доступа одноранговой сети к мобильным устройствам с ограниченными ресурсами, пытаются решить посредством разгрузки мобильных устройств, а также кэширования содержимого в подключенных частях сети, как раскрыто, например в документе "Enabling mobile peer-to-peer networking", J. Oberender et al, Mobile and Wireless Systems, LNCS 3427, Germany, 2005, или подсоединением устройств к специализированным шлюзам, как раскрыто, например в "Mobile Web Server, Raccoon, project", http://opensource..nokia..com/projects/mobile-web-server/, проверенный: 01 мая 2007 г., или минимизируя передачу служебных сигналов путем модификации протокола доступа, как раскрыто, например в "JXMEproject", http://jxme.jxta.org/, проверенный: 01 мая 2007 г. Эти подходы ограничивают истинно сквозной принцип работы сети Интернет.

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

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

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

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

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

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

Способ содержит:

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

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

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

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

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

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

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

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

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

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

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

на фиг.3А показана структурная схема доменного маршрутизатора согласно одному варианту осуществления,

на фиг.3В показана структурная схема домашнего маршрутизатора согласно одному варианту осуществления,

на фиг.3С показана структурная схема чужого маршрутизатора согласно одному варианту осуществления,

на фиг.4 показана принципиальная схема способа согласно одному варианту осуществления, когда клиент запрашивает содержимое от MN,

на фиг.5 показана принципиальная схема способа согласно второму варианту осуществления, когда клиент запрашивает содержимое от MN,

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

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

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

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

на фиг.10 показан пример осуществления наложенной сети,

на фиг.11 показана маршрутная таблица доменного маршрутизатора, показанного на фиг.10,

на фиг.12 показана маршрутная таблица чужого маршрутизатора, показанного на фиг.10,

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

на фиг.14 показана обновленная маршрутная таблица чужого маршрутизатора, показанного на фиг.13, и

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

ПОДРОБНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

На фиг.1 показан пример инфраструктуры 100 сети с группой элементов, по меньшей мере один из которых является формирующим универсальную наложенную сеть. Элементы могут включать по меньшей мере одного клиента 101, по меньшей мере один сервер доменных имен (далее по тексту DNS) 102, по меньшей мере один доменный маршрутизатор (далее по тексту DR) 103, по меньшей мере один домашний маршрутизатор (HR) 104, по меньшей мере один чужой маршрутизатор (FR) 105 и по меньшей мере один сервер (MN) 106.

Клиенты 101 могут быть обычными хостами (не обязательно являющимися частью наложенной сети) с доступом в глобальную сеть Интернет 107. Любой оснащенный надлежащим образом клиент может получить доступ к приложениям, размещенным на любом мобильном узле MN 106. Аналогично, в других ситуациях MN 106 может действовать как клиент. Элементами сети, которые являются частью наложенной сети, могут быть по меньшей мере один узел DR 103, по меньшей мере один узел HR 104, по меньшей мере один узел FR 105 и по по меньшей мере один мобильный узел MN 106. Количество и тип элементов инфраструктуры сети и наложенной сети, показанной на фиг.1, являются только примерными и не ограничивают объем изобретения.

Доменный маршрутизатор DR 103 является элементом, выполненным с возможностью поиска и переадресации запросов определенного URI или логического имени к точке присоединения, т.е. HR или FR мобильного узла, соединенного с запрашиваемым UR1. Поиск осуществляется путем взаимодействия с другими узлами в наложенной сети, содержащей по меньшей мере один сервер DNS 102, по меньшей мере один маршрутизатор 103 (DR), по меньшей мере один домашний маршрутизатор (HR) 5 104, по меньшей мере один чужой маршрутизатор (FR) 105 и по меньшей мере один мобильномый сервер (MN) 106 или комбинацию этих устройств.

Каждый DR 103 содержит маршрутную таблицу переходов, в которой каждая строка содержит <URI, {маршрутизаторы следующего перехода}, таймер>. Следовательно, таблица содержит упорядоченный список адресов домашних маршрутизаторов HR или чужих маршрутизаторов FR следующего перехода для каждого зарегистрированного универсального идентификатора ресурса (URI), и таймер для отдельной строки URI обновляется для каждого запроса поиска этого URI. Строка URI удаляется из таблицы, когда истекает таймер. DR 103 поддерживает соединения со всеми узлами HR/FR в его маршрутной таблице. Соединение может осуществляться посредством TCP или любого подходящего протокола транспортного уровня. Более того, из соображений производительности и/или избыточности DR 103 может быть сконфигурирован в кластерной топологии. Каждое имя домена управляется одним элементом DR или возможно его кластером. Кроме того, DR 103 поддерживает таблицу адресов клиентов с ожидающими к настоящему времени оставшимися без ответа запросами поиска URI в домене, управляемом DR 103. До получения первого ответа на запрос определенного URI от HR/FR следующего перехода, DR 103 ответит всем клиентам с ожидающими к настоящему времени запросами, таким образом оптимизируя задержку поиска, испытываемую клиентами.

Домашний маршрутизатор, HR 104, является элементом, выполненным с возможностью поиска и переадресации запросов определенного URI или логического имени к точке присоединения, т.е. HR или FR мобильного узла, соединенного с запрашиваемым URI. Поиск осуществляется путем взаимодействия с другими узлами в наложенной сети. Каждый HR 104 содержит маршрутную таблицу, в которой каждая строка содержит <URI, {маршрутизаторы следующего перехода}, {маршрутизаторы предыдущего перехода}, таймер, непосредственный>. Для каждого зарегистрированного URI таблица содержит упорядоченный список адресов HR или FR следующего перехода, адресов DR, HR или FR предыдущего перехода, таймер, который обновляется для каждого запроса поиска для определенного URI, и флаг «непосредственный», который указывает, если MN, связанный с URI, непосредственно соединен с HR 104. В этом случае, HR 104 отвечает своим собственным адресом на любые запросы поиска, которые имеют целью MN. Строка URI удаляется из таблицы, когда истекает таймер. HR 104 поддерживает соединения, которые могут быть осуществлены через TCP или любой подходящий протокол транспортного уровня, со всеми узлами HR/FR в его маршрутной таблице. Если HR 104, напрямую подсоединенный к любому MN (по меньшей мере одному), является ответственным за поддержку прямого соединения, через TCP или любой подходящий протокол транспортного уровня, с тем MN - возможно через NAT и брандмауэры - и действует как узел переключения для прикладного потока между MN и 5 другими узлами. Обычно новый MN регистрирует, возможно до явного приглашения, свой URI с HR для ввода наложенной сети. Только один HR 104 может быть исходным домашним маршрутизатором для MN в любое заданное время, тогда как MN может поддерживать соединения с другими домашними маршрутизаторами.

Чужой маршрутизатор, FR 105, является элементом, выполненным с возможностью поиска и переадресации запросов определенного URI или логического имени к точке присоединения, т.е. HR или FR мобильного узла, соединенного с запрашиваемым URI. Поиск осуществляется путем взаимодействия с другими узлами в наложенной сети. Каждый FR 105 содержит маршрутную таблицу, каждая строка в которой содержит <URI, {маршрутизаторы следующего перехода}, {маршрутизаторы предыдущего перехода}, таймер, непосредственный>. Для каждого зарегистрированного URI, таблица содержит упорядоченный список адресов HR или FR следующего перехода, адресов DR, HR или FR предыдущего перехода, таймер, который обновляется для каждого запроса поиска определенного URI, и флаг «непосредственный», который указывает, если MN, содержащий URI, непосредственно соединен с FR 105. В этом случае, FR 105 отвечает своим собственным адресом на любые запросы поиска, которые направлены MN. Строка URI удаляется из таблицы, когда истекает таймер. FR 105 поддерживает соединения, которые могут быть выполнены посредством TCP или любого подходящего протокола транспортного уровня, со всеми HR или FR в его маршрутной таблице. Если FR 105, подсоединенный напрямую к любому MN (по меньшей мере одному), является ответственным за поддержку прямого соединения, посредством TCP или любого подходящего протокола транспортного уровня, с этим MN - возможно через NAT и брандмауэры - и действует как узел переключения для потока приложений между MN и другими узлами. Узел, функционирующий как чужой маршрутизатор по отношению к одному MN, может работать как домашний маршрутизатор по отношению к другим MN.

Мобильный узел MN 106 является хостом, который может менять свое местоположение из одной сети или подсети в другую и менять свой IP адрес. Это может продолжаться для соединения с другими узлами и для того, чтобы быть доступным другим узлам в сети Интернет при любом местоположении, предполагая соединение на канальном уровне и назначенный и действительный IP адрес. MN 106 может быть выполнен в виде электронного устройства, который может быть осуществлен в виде мобильного терминала системы связи или мобильной сети 107, например GSM, UMTS или любой другой системы или сети такой, как WLAN 108.

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

На фиг.2 показан способ регистрации мобильного устройства связи в качестве мобильного сервера (узла) MN 106 и установления соединения с домашним маршрутизатором HR 104 в наложенной сети электронной сети связи, показанной на фиг.1. Дополнительно к необходимым условиям подключения к сети и при наличии действующего IP адреса, MN 106 должен иметь установленной соответствующую функциональность наложенной сети. Данная функциональность может быть продуктом для содержания компьютерной программы, содержащим читаемый компьютером носитель, содержащий средства компьютерного программного кода, которые при загрузке указанной программы заставляют компьютер выполнить процесс, обеспечивающий функциональность.

В соответствии с вариантом осуществления изобретения, показанном на фиг.2, MN 106 изначально не знает действующий адрес своего HR 104. В этом случае начальная загрузка системы осуществляется при наличии MN 106, разрешающего использовать его имя через DNS 102 путем передачи запроса DNS на этапе 201. DNS находит и возвращает адрес ответственного DR, передавая ответ DNS на этапе 202 тому мобильному узлу, который может направить запрос на регистрацию на этапе 203.

Согласно одному варианту осуществления изобретения на этапе 204 DR получает запрос на регистрацию и на этапе 205 осуществляет поиск на основании имени. Если идентифицирован действующий HR, на этапе 206 DR отправляет запрос на регистрацию к идентифицированному HR. HR получает запрос на регистрацию от DR на этапе 207 и обрабатывает этот запрос на этапе 208. На этапе 209 HR отвечает путем передачи запроса на регистрацию на запрашивающий DR. На этапе 210 DR получает регистрационный ответ от HR. DR продолжает процесс путем возвращения ответа к MN, подтверждая IP адрес для HR, например alice. example. COmQHRIP на этапе 211. На этапе 212 MN получает регистрационный ответ регистрации от DR, и затем на этапе 213 может отправить запрос на регистрацию напрямую на идентифицированный HR путем использования полученного IP адреса. Когда HR получает запрос на регистрацию напрямую от запрашивающего MN на этапе 214, он на этапе 215 проверяет полученный запрос. На этапе 216 HR отправляет регистрационный ответ, полученный MN на этапе 217, являющийся подтверждением того, что было успешно установлено прямое соединение между MN и HR. До завершения показанной последовательности этапов MN 106 может быть адресован другими хостами, подключенными к сети Интернет, как проиллюстрировано ниже.

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

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

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

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

1. MN выполняет локальное обнаружение (т.н. "neighbour solicitation" или «настойчивое обращение к соседу») посредством пересылки сигналов (или групповой передачи по конкретным адресам) в текущей подсети. Это может привести к прямым ответам от представленных в подсети узлов HR/FR. Кроме того, это может вызвать косвенные ссылки на потенциальные узлы HR/FR посредством полученных подсказок, переносимых в ответах имеющихся в подсети других MN (т.е. MN, действующих как агенты переключения запросов). В случае многочисленных альтернатив MN должен выбрать точку привязки на основании конфигурируемых критериев.

2. MN определяет адрес своего DR и соединяется с ним для направления к подходящему HR или FR. DR может основать свой ответ на различных критериях, таких как близость сети (количество интервалов связи, задержка проверки возможности установления соединения посредством запроса/отклика и контроля прохождения сигнала по сети, и перекрывающиеся маршруты и т.д.), географическое положение (например, на основании данных GPS), пропускная способность и полученные измерения трафика (например, текущая ситуация, связанная с обработкой данных и загрузкой в узлах и соединениях) или соглашения об информационном обмене , заключенные на основании сообществ и известной межличностной коммуникации, или другими способами. Данный процесс может зависеть или не зависеть от входной информации от других узлов DR и HR/FR, и, возможно, от других серверов специального назначения в наложенной сети.

3. MN соединяется с известными узлами HR/FR, котированными из предыдущих сеансов или найденными из любого другого репозитория, в соответствии с некоторой заранее заданной схемой упорядочения.

До каждой регистрации с HR/FR MN должен заявить адрес последнего 15 соединенного узла HR/FR, если это имеет место. На основании данной информации новый узел HR/FR связывается с последним соединенным HR/FR для обновления своего маршрута последовательных переходов. Если такой адрес не может быть найден, HR/FR выполнит процесс разрешения имен, основанный на имени, зарегистрированном мобильным узлом MN, которое в конце концов приведет новый HR/FR к последней 20 известной точке присоединения MN, если это имеет место. В противном случае, исходящий HR должен быть подсоединен напрямую.

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

На фиг.3А показана структурная схема доменного маршрутизатора 103, используемого в универсальной наложенной сети для эффективного поиска информации в сети связи. Маршрутизатор 103 сконфигурирован, чтобы регистрировать мобильное устройство 106 связи с домашним маршрутизатором 104 в сети связи. Согласно одному варианту осуществления изобретения маршрутизатор 103 содержит ресивер 301, выполненный с возможностью получать запрос на регистрацию от мобильного устройства 106 связи, причем указанный запрос включает идентификатор мобильного устройства связи. Контролер 302 доменного маршрутизатора выполнен с возможностью поиска адреса маршрутизатора следующего перехода 104 или 105, связанного с этим идентификатором или который должен быть связан с этим идентификатором, т.е. запрашивающим MN 106. Кроме того, маршрутизатор 103 содержит передатчик 303, выполненный с возможностью передавать запрос регистрации к маршрутизатору следующего перехода 104 или 105.

Кроме того, ресивер 301 выполнен с возможностью получать ответ от маршрутизатора следующего перехода 104, 105. Контролер 302 выполнен с возможностью определить, включает ли ответ сетевой адрес домашнего маршрутизатора 104, и передатчик 303 выполнен с возможностью передать ответное сообщение на мобильное устройство связи MN 106, содержащее адрес домашнего маршрутизатора 104. Ответное сообщение инициирует создание соединения между мобильным устройством связи и домашним маршрутизатором, когда оно получено и обработано с помощью мобильного устройства связи.

На фиг.3В показана структурная схема домашнего маршрутизатора 104, используемого в универсальной наложенной сети для эффективного поиска информации в сети связи. Согласно одному варианту осуществления изобретения домашний маршрутизатор 104 содержит ресивер 311, контролер 312 и передатчик 313. Ресивер 311 выполнен с возможностью получать запрос регистрации для мобильного устройства 106 связи от маршрутизатора 103, причем запрос регистрации включает идентификатор мобильного устройства 106 связи. Контролер 312 выполнен с возможностью в ответ на запрос регистрации генерировать ответ, содержащий адрес домашнего маршрутизатора. Передатчик 313 выполнен с возможностью отправить ответ на маршрутизатор 103, содержащий адрес домашнего маршрутизатора, чтобы инициировать пересылку ответа, содержащего адрес домашнего маршрутизатора, на мобильное устройство 106 связи.

В одном варианте осуществления изобретения ресивер 311 также выполнен с возможностью получать запрос регистрации от мобильного устройства 106 связи. Кроме того, контролер 312 выполнен с возможностью в ответ на запрос регистрации от мобильного устройства 106 связи устанавливать соединение между домашним маршрутизатором 104 и мобильным устройством 106 связи.

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

Согласно одному варианту осуществления изобретения чужой маршрутизатор 105 содержит ресивер 321, контролер 322 и передатчик 323.

На фиг.4 показана принципиальная схема способа согласно одному варианту осуществления изобретения, когда клиент запрашивает содержимое от MN. Пример иллюстрирует клиента, запрашивающего веб-страницу (или подобное) с помощью команды HTTP GET. На этапе 401 клиент отправляет в DNS систему запрос DNS с веб-адресом "alice.example.com". Сервер доменных имен DNS на этапе 402 отвечает IP адресом DR домена "example.com". Далее на этапе 403 клиент отправляет команду HTTP GET с адресом "alice.example.com" на IP адрес DR. В ответ на полученный HTTP GET на этапе 404 DR выполняет поиск в своей маршрутной таблице маршрутизатора следующего перехода, к которому должен быть отправлен запрос поиска. На этапе 405 HR, получивший запрос поиска, идентифицирует адрес запрошенного MN, как будто бы он непосредственно подсоединен, и, следовательно, отправляет ответ поиска со своим собственным IP адресом. HR идентифицирует HR запрошенного MN или путем выбора самого себя, если HR является исходным HR мобильного узла, или путем взаимодействия с другими узлами, т.е. с другими HR и/или FR в наложенной сети. В этом примере флаг «непосредственный» указывает на то, что MN, связанный с URI, непосредственно соединен с HR 104. Таким образом, в этом случае HR отвечает на запрос поиска к целевому MN своим собственным адресом, т.е. "alice.example.com". На этапе 406 в ответ на ответ поиска от HR DR генерирует и отправляет запрашивающему клиенту HTTP перенаправленное сообщение с IP адресом HR, подсоединенного к запрошенному MN. Далее с этого времени клиент может отправить команду HTTP GET для alice.example.com на HR, подсоединенный к запрошенному MN, содержащему запрошенную информацию, на этапе 407. HR генерирует и отправляет встроенную команду HTTP GET для alice.example.com к MN на этапе 408 для доступа к запрошенной информации, т.е. в данном примере к веб-странице "alice.example.com". На этапе 409 MN отвечает своему HR встроенной командой HTTP 200 ОК. В ответ на полученную встроенную команду HTTP 200 OK на этапе 410 HR генерирует и отправляет команду HTTP 200 OK для запрашиваемой веб-страницы к запрашивающему клиенту, пользователю, который теперь имеет доступ к информации на запрашиваемой веб-странице.

В других вариантах осуществления изобретения для специалиста очевидно, что вышеизложенные способы могут быть применены к другим прикладным протоколам. Как можно видеть на данном примере, конечный адрес назначения, т.е. адрес MN, скрыт от клиента, клиент установит TCP соединение с HR мобильного узла (или в другом случае FR) в то время, как HR (или FR) пересылает сообщения между клиентом и MN. Предполагается, что данный тип поиска должен быть выполнен только для предварительно неизвестных клиентов, поскольку большинство клиентов будут способны кэшировать адрес HR мобильного узла (или FR) для будущих запросов (конечно, это является типичным свойством современных веб-браузеров). Кроме того, если DR получает дополнительные запросы конкретного URI/имени по меньшей мере с одним предварительно невыполненным поиском, он может использовать первый возвращающийся результат поиска, чтобы отправить ответное сообщение всем запрашивающим клиентам, таким образом также оптимизируя задержку поиска, испытываемую клиентами.

На фиг. 5 показана принципиальная схема способа согласно второму варианту осуществления, когда клиент запрашивает содержимое от MN 106. В данном примере MN 106 переместился в другую подсеть и заново зарегистрировался в соответствии с вышеописанной процедурой перерегистрации. Та же процедура применима, когда MN 106 переместился к другому шлюзу или если изменилась топология сети. MN 106 был зарегистрирован с двумя альтернативными FR 105а и FR 105b, один за другим. В показанной ситуации процедура регистрации сформировала «цепь поиска», состоящую из DR 103 - HR 104 - FR 105а - FR 105b, причем самый нижний FR 105b является текущей точкой присоединения MN. MN может перемещаться путем переключения к новому FR или обратно к своему HR по вышеописанным причинам. Переключение управляется наложенной сетью, чтобы не нарушить любые действующие прикладные сеансы. До перемещения, когда новая точка присоединения (HR/FR) соединяется с последней известной точкой присоединения (HR/FR), любые предыдущие взаимосвязи будут обнаружены путем проверки предыдущих маршрутных таблиц. Как следствие, не будет встречаться петель, и количество маршрутов на пути поиска будет сведено к минимуму. Ниже приводится подробное описание данного процесса.

Этапы 501-504 передачи сообщений, показанные на фиг.5, идентичны этапам 401-404 передачи сообщений, показанным на фиг.4. Однако вместо того, чтобы быть способным ответить непосредственно на этапе 405, как показано на фиг.4, HR 104 сейчас должен передать запрос по «цепочке поиска», т.е. выполнить этапы 505 и 506 через FR 105' и узел привязки FR 105", как показано на фиг. 5. На этапе 507 узел привязки FR 105" возвращает ответ поиска, и ответ достигает HR 104 на этапе 508 и DR 103 на этапе 509, чтобы перенаправленное сообщение могло быть возвращено клиенту 101 на этапе 510. Клиент 101 далее на этапе 511 направляет свой запрос к узлу привязки FR 105", который, в свою очередь, на этапе 512 отправляет запрос к MN 106. Ответы от MN 106 на этапах 513 и 514 проходят через узел привязки FR 105" непосредственно к клиенту. На фиг.6 показан MN 106, содержащий ресурсы, связанные с различными URI, принадлежащими разным доменам, где каждый домен управляется посредством отдельного DR, в данном примере осуществления DR 103а и DR 103b. Ресурсы MN 106 доступны через запрос поиска к любому URI посредством соответствующего DR 103b, причем каждый запрос направляется к соответствующему DR 103b путем просмотра обычным DNS на этапах 601 и 602. В показанном примере запрос выполнен к URI вторичного домена MN 106. В этом случае HR 104а и FR 105а в первичном домене действуют как FR к HR 104b во вторичном домене. Таким образом, сообщения 601-612 аналогичны сообщениям 501-512, показанным на фиг.5.

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

Альтернативой и дополнением к способу одноуровневых соединений между HR для создания альтернативных имен хостов, описанного выше, является способ отображения альтернативных имен DR. Пример показан на фиг.7. В этом случае администраторы DR 104b каждого вторичного домена могут зарегистрировать связь адреса DR 104а первичного домена с альтернативным именем ресурсов MN 106 в их DR. Подобным образом любой запрос дополнительного имени MN 106 направляется к вторичному DR 103b на этапе 703 после поиска DNS на этапах 701 и 702, с последующим перенаправлением ответа на этапе 704, указывающего на DR 103а первичного домена, с последующим запросом поиска на этапе 705. Тогда первоначально обозначенная последовательность запросов поиска в первичном домене выполняется на этапах 706-709 и основана на ответе поиска на этапе 710, прямое соединение устанавливается запрашивающим клиентом с текущим узлом присоединения FR 105 на этапе 711, который переключает запрос поверх предварительно установленного соединения между FR 105 и MN 106 на этапе 712.

Одноранговые соединения между HR могут существовать благодаря описанному выше использованию альтернативных имен хостов, но это может также быть и по другим соображениям, включая обеспечение альтернативных сценариев доступа. Типичные причины использования альтернативных сценариев доступа включают близость сети и кластеризацию, или вопросы производительности и избыточности. Такой тип связей при равноправном информационном обмене обычно имеет место по запросу, и они могут управляться исходя из некоторых критериев режима реального времени, таких, как текущее местоположение узла или других, более сложных, например, результатов обработки метаданных. Пример осуществления способа, используемого для установки одноуровневых соединений, показан на фиг.8. Два DR 103а и DR 103b управляют двумя разными доменами, необязательно связанными посредством соотношения альтернативных имен хостов. MN 106 обнаруживает предварительно неизвестный узел FR 105b с использованием любого из способов начальной загрузки и регистрации, описанных выше в связи с фиг.2. После обнаружения MN 106 на этапе 801 передает запрос на установку одноуровневых соединений между двумя HR 104а и HR 104b. Запрос содержит в качестве параметра адрес HR 104а мобильного узла MN 106. Заново обнаруженный FR 105b передает по цепочке запрос на установку одноуровневых соединений на этапе 802 ко всем или возможно к выбранному подмножеству HR, к которому он подсоединен непосредственно или косвенно (через другие FR) - в данном случае к HR 104b. Любой HR, принимающий запрос, передает к HR 104а мобильного узла MN 106 запрос на установку одноуровневых соединений, как на этапе 803. HR 104а мобильного узла MN 106 на этапе 804 передает ответ ОК или отказ, который, в свою очередь, передается обратно к MN 106 на этапах 805 и 806. Устанавливается запрошенное одноуровневое соединение, что выражается в подсоединении HR 104а и HR 104b и далее к FR 105.

Как указано в этом примере осуществления, заново обнаруженный FR 105b может, если сконфигурирован соответствующим образом, фильтровать некоторые или все запросы на установку одноуровневых соединений вместо передачи их по цепочкам поиска, в состав которых входит FR, на их предшествующие узлы (HR или FR). Это означает, что не требуется пересылать такой запрос на установку одноуровневых соединений на HR, содержащий FR в своей цепи поиска. В более общем примере осуществления любой FR, принимающий запрос на установку одноуровневых соединений данного типа может пересылать запрос на любой из предшествующих узлов (HR или FR) только в случае, если это позволяют его текущие критерии фильтрации. Правила обычной фильтрации могут включать пересылку только тех запросов, которые созданы узлами, принадлежащими к определенному домену. Другой фильтр может направлять запросы к конкретному HR в зависимости от присоединения запрашивающего узла. Причиной для фильтрации может быть авторизация доступа на посещение узлов.

Кроме того, настоящее изобретение предлагает распределенную систему для сбора, хранения, индексации и поиска метаданных, генерируемых узлами, участвующими в системе. Типичный пример применения может содержать MN, оснащенный функциональностью GPS. MN может, во время регистрации и/или в последующие промежутки времени, сообщать свои GPS данные к своей точке присоединения, HR/FR. Точка присоединения может хранить и передавать, возможно после некоторой индексации и обработки вместе с коррелированными данными, GPS метаданные или любые предварительно сконфигурированные из этого индексы к любому другому узлу в системе, обычно HR или DR мобильных узлов или к любому другому специально предназначенному набору (метаданные) серверов. Еще более эффективное использование может включать индексацию метаданных в HR/FR, в то время как вместо передачи самих метаданных, только передают сообщения о «индексах метаданных», тем самым уведомляя соответствующий DR (или несколько DR или любой другой специально предназначенный набор серверов, если применимо), что имеются метаданные и какого типа для последующих запросов, если потребуется. Другим примером прямой пересылки метаданных является использование инфраструктуры наложенных метаданных к подсоединенным MN (и их пользователям), чтобы искать и находить друг друга для формирования и поддержки сообществ пользователей. Это может быть реализовано, если MN регистрирует себя, например с уникальным специальным ID, в своей точке присоединения (HR/FR), и если система способна искать и находить других пользователей с помощью их ID. Таким же способом местонахождение сети и в случае предоставления GPS данных действительное географическое местоположение любого MN может быть определено другими мобильными узлами в системе. В других примерах осуществления специалистам очевидно, что вышеизложенные примеры применения затем могут быть расширены и комбинированы в настоящей инфраструктуре наложения метаданных. Обычно может быть удобно интегрировать поиск метаданных и операции запроса в процессе предварительной самозагрузки и регистрации, упомянутом выше в связи с фиг.2.

Пример осуществления способа запроса метаданных проиллюстрирован на фиг.9. В данном примере на этапе 901 MN 106b передал свои метаданные на свой FR 105b, которые, в свою очередь, могут быть переданы по цепочке, в зависимости от примененных правил фильтрации и возможно после некоторой обработки, на HR 104b на этапе 902 и DR 103b мобильного узла MN 106 на этапе 903 соответственно, в зависимости от того, какая политика индексации использовалась в домене В. Теперь сохраненные метаданные могут использоваться другими мобильными узлами совместно. В настоящем примере другой MN 106а в другом домене А на этапе 904 передает запрос метаданных на установление других одноуровневых соединений с соответствующими данными. FR 105а передает запрос к HR запрашивающего MN на этапе 905, который в свою очередь может передать запрос ко всем HR 104а' под тем же самым DR 103а в домене А на этапе 906, если позволено политикой домена, что обозначено внутридоменным запросом. Адреса всех HR в домене могут сохраняться и управляться доменным маршрутизатором DR. Каждый запрашиваемый HR в домене пересылает запрос к тем FR, которые показали, что собирают соответствующие метаданные (как описано в предыдущем параграфе), в конечном счете возвращая ответ к исходному HR 104а на этапе 907. Процесс запроса предписывает, как и к каким FR направляемые запросы могут следовать любому предопределенному алгоритму графа поиска для ориентированного ациклического графа, например поиск типа «сначала в ширину» или «сначала в глубину». Кроме того, запрос может быть передан к HR в других доменах, с которыми запрашивающий HR 104а имеет прямое равноправное соединение на этапе 908, в данном примере HR 104b домене В. Далее равноправный HR 104b в домене В может запрашивать свой DR 103b на этапе 909, если в домене В позволена внутридоменная пересылка от исходного домена, домена А. Если это позволено, запрос передается внутри домена В к другим HR 104b' на этапе 910. Ответы собираются на этапе 911 и в конечном счете возвращаются к исходному HR 104а в домене А на этапе 912. Аналогично, если это указано в исходном запросе, равноправный HR 104с в другом домене может переслать запрос к своим равноправным HR 104с' на этапе 913, таким образом выполняя косвенный запрос на установку равноправного соединения, в данном случае к домену С. Если позволяет DR 103с в домене С, внутридоменный запрос может быть выполнен в домене С. FR 105а принимает ответы поиска на этапе 914 и в конце концов переключает к MN 106а на этапе 915.

DR поддерживает TCP соединения, или другие подходящие соединения транспортного уровня, к каждому HR в своем домене. По причинам избыточности, он также может установить такие же соединения со вторым и последующими FR, основанные на адресной информации, передаваемой от каждого HR при изменениях ситуации в сети. На фиг.11 показана маршрутная таблица DR 103 при заданных условиях на фиг.10. Как можно видеть, первичные адреса указывают на узлы, FR 105 и FR 105х, разделенные двумя интервалами связи, использующие HR 104 и HR 104х в качестве второй опции, которые будут использоваться только, если первичный путь поиска не срабатывает. Избыточные пути могут охватывать всю целиком или часть цепи поиска, от DR 103, через промежуточные узлы HR/FR 104, 105, 105' и узел привязки HR/FR 105" и, в конце концов, вниз к MN 106. Кроме того, возможно разрешить некоторым HR и FR соединяться с MN, из соображений избыточности это создает различные точки привязки для MN. Несмотря на применяемую здесь политику избыточности первичного/ вторичного пути, следует отметить, что в другом примере осуществления, может быть использовано любое количество доступных альтернативных путей, используемых между любой парой узлов, объединенных в цепь поиска, ведущую к конкретному MN, содержащему конкретный URI.

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

Узлы HR и FR могут соединяться с узлами DR, HR, FR и MN с помощью TCP соединений, причем одно TCP соединение может быть использовано разными путями поиска (с целью передачи запросов поиска). Следует заметить, что в альтернативных примерах осуществления могут быть использованы другие транспортные протоколы, отличающиеся от TCP. Каждое TCP соединение связано с маршрутной таблицей, как показано в примере на фиг.12, ссылающемся на фиг.10. Могут быть использованы избыточные соединения. Это проиллюстрировано двумя альтернативными примерами в каждом направлении на данном примере осуществления. Пути устанавливаются путем передачи сигналов в процессе регистрации MN или вследствие изменений топологии (например, когда узел отключается). Таймер обновляется, или мгновенно или с определенным шагом, для каждого случая поиска или с каждым тактовым импульсом для MN, содержащего URI адрес, если истекает таймер узла (достигает своего конфигурируемого предела), строка с истекшим таймером может быть удалена из

таблицы после последовательности сигналов к соседним узлам. Передача сигналов начнет последовательность строк в маршрутной таблице в соседних узлах. Обычно первичные и вторичные пути (в случае использования для URI двух избыточных путей) корректируются, чтобы указать другие узлы, отличные от узлов с истекшим таймером. При необходимости устанавливаются новые TCP соединения, в противном случае существующие TCP соединения в маршрутных таблицах модифицируются. Устанавливается флаг «непосредственный» в случае, если мобильный узел с URI непосредственно подсоединен к рассматриваемому узлу, в этом случае таймер не является активным для данного URI. Для обеспечения того, что цепь поиска не вырастет слишком длинной, узлы могут сами себя удалять из конкретной цепи поиска, если обнаружена неактивность. Узел маршрутизации является ответственным за обнаружение соединений с MN, имеющими низкую активность. Когда узел обнаруживает соединение к MN, с которым он был непосредственно соединен в течение достаточно продолжительного времени (определяется по значению таймера, возможно в комбинации с измерением активности), он инициирует удаление себя из цепи. Для этого он должен установить соединение со всеми соседними узлами, вовлеченными в процесс поиска для данного MN (т.е. узлами, соединенными посредством его первичной и вторичной связи, и узлами с первичным и вторичным соединением к нему). Ответственность за восстановление сети лежит на остающихся узлах маршрутизации.

На фиг.13 показан обновленный случай варианта, показанного на фиг.10, после перемещения веб-адресом "bob.example.com" мобильного узла MN 106 к FR 105' с адресом 45.678.91.9. На фиг.14 показана обновленная маршрутная таблица FR 105 с адресом 234.567.89.2 после перемещения. Как можно видеть, первичный и вторичный адреса поменяли местами для строк, относящихся к текущему MN в маршрутной таблице FR. Это является результатом обмена сообщениями в цепи узлов об обновлении пути передачи сигналов, как описано в предыдущих абзацах и будет далее пояснено в настоящем описании. Рассмотрим пример цепи поиска с узлами DR- HR- FRI- FR2, причем MN соединен напрямую с FR2. Следующие этапы выполняются до того, как MN переместится к новой, ранее непосещенной точке присоединения, например, FR3.

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

Этап 2. MN соединяется с FR3.

Этап 3. FR3 отправляет сообщение к FR2, информируя его о новом положении MN.

Этап 4. FR2 отвечает и информирует FR3 о предшествующем маршрутизаторе (FRI) в цепи.

Этап 5. FR3 соединяется с маршрутизатором, расположенным на два шага назад (FRI), и информирует его для образования с ним (FR3) первичной связи, в то время как создается вторичная связь с предыдущим маршрутизатором (FR2). Связи затрагиваемых узлов обновляются.

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

Вместо этого, имеют место только изменения в предшествующем узле (узлах), которые имеют новую точку присоединения на их второй ближайшей связи. После изменения два узла, предшествующие текущей точке присоединения, указывают на узел с их первичными связями. Следовательно, попадая на правильный узел, не имеет значения, какой из указанных маршрутизаторов вовлечен в процесс поиска, поскольку сначала проверяют первичные связи. Если MN совершает еще одно перемещение, обратно переключают строки маршрутной таблицы на те, что были до этого последнего изменения, оставляя данную часть цепи такой, какой она была до перемещения. Главной целью манипулирования перемещениями внутри цепи, такой, как эта, является возможность избежать образования циклов и никогда не иметь более, чем одного первичного и вторичного пути к каждому маршрутизатору. Когда MN перемещается от одного узла, например узла А, к другому, например узлу В, не являющемуся частью предыдущей цепи поиска (последовательности взаимосвязанных узлов, управляющей поиском MN), формируется новая ветвь цепи поиска. Узел А будет знать о перемещении посредством получения сообщений регистрации от MN через новый узел привязки В. Перед соединением с новой ветвью, узел А гарантирует, что последующие за ним узлы (если имеются) отсечены правильно в разъединенной теперь цепи поиска. Данное отсечение выполнено посредством отправки демонтирующих сообщений к указанным последующим узлам. В данном примере узел А отправляет демонтирующее сообщение следующему за ним узлу в теперь поврежденной цепи, информируя его, что строки для данного MN недействительны. Узел, получающий демонтирующее сообщение для конкретного URI адреса, очистит свои строки в маршрутной таблице (во всех направлениях) для данного URI и затем перешлет демонтирующее сообщение, которое будет выполнять поиск до тех пор, пока оно не достигнет конца поврежденной цепи. Остальная часть строки в таблице сохраняется, пока не истечет время, в течение которого MN может заново подсоединиться, делая любую сохраненную информацию полезной. Затем узел А соответственно обновит свою маршрутную таблицу, соединится с узлом В и передаст сообщение на установку пути к предшествующим ему узлам, находящимся в пути поиска. Более того, узел А также передаст узлу В адрес предшествующего узла (узлов) для соединения с ними узла В.

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

Следует заметить, что в другом примере осуществления, MN может содержать функциональность STUNT¹) сервера, таким образом любой клиент, имеющий STUNT клиентскую функциональность, способен, в случае успешного отслеживания NAT, устанавливать прямое соединение с MN после передачи STUNT сигналов и процесса отслеживания (как альтернатива соединению переключением HR/FR). В настоящей системе это решается включением STUNT опции в ответ поиска в сообщениях на этапе 405 и 406, как показано на фиг.4. Таким образом, если установлена STUNT опция, показывающая, что HR/FR и MN являются STUNT совместимыми, и клиент является STUNT совместимым, вместо отправки сообщения инициируются передача STUNT сигналов и процесс отслеживания. Для специалиста должно быть очевидно, что могут быть использованы другие механизмы и способы NAT отслеживания, например упомянутые в структуре ICE, вместо или дополнительно к вышеуказанному STUNT решению.

Следует заметить, что в одном примере осуществления MN может поддерживать одно или несколько активных соединений с одним или несколькими узлами HR/FR одновременно. Для увеличения общей пропускной способности может быть установлено и использоваться параллельно множество соединений. Не все из установленных соединений могут быть активными, но поддерживаются из соображений избыточности, используются в качестве резервных или альтернативных путей, т.е. возможны оба типа резервных соединений, «горячий» и «холодный», в зависимости от эксплуатационных требований. Возможно, но не обязательно, что приложения, включающие MN, используют отдельные соединения. Однако также возможно для одного или нескольких таких приложений передавать данные через параллельные соединения, таким образом вовлекая множество узлов HR/FR во время передачи данных. В этом случае прикладные данные могут передаваться параллельно как избыточные, дублированные данные или передача данных может быть разделенной через параллельные соединения. Разные соединения могут использовать разные технологии однонаправленного канала, известные специалисту из уровня техники, например WCDMA, HSPA, EDGE, Wimax, WiFi, Ethernet, Bluetooth, USB. Кроме того, набор поддерживаемых соединений между MN и одним или несколькими из соединенных с ним узлов FR/HR, должен обеспечивать передачу прикладного сеанса и переключение передачи их данных между различными соединениями бесшовным и непрерывным способом, возможно под управлением другого FR/HR, и возможно по запросу, таким образом всегда выбирая лучший однонаправленный канал и соединение, причем понятие «лучший» может быть определено сочетанием разных критериев, таких как стоимость, надежность, качество обслуживания, ширина полосы пропускания и пропускная способность, энергопотребление, местоположение и пространственное местонахождение, или других. Подобные схемы переключения могут быть инициированы и управляемы с помощью схемы переключения, реализованной в MN и узлах HR/FR, соединенных с MN, например через заново установленное соединение, как будет объяснено в следующем параграфе, или через уже существующие соединения.

Следует отметить, что в одном примере осуществления MN может прямо или косвенно соединяться с узлами HR/FR, находящимися в той же самой локальной сети (LAN), и/или с узлами HR/FR внутри зоны действия техники ближней связи, такой как Bluetooth или USB. Подобные соединения могут быть использованы автономно или параллельно с другими вышеописанными технологиями однонаправленного канала, обеспечивающими бесшовную передачу данных, например от 3G к Bluetooth или WLAN, и наоборот. Путем расширения указанного решения формирования наложенной сети с указанной пропускной способностью локального соединения пользователь имеет возможность соединиться с локальным MN без использования инфраструктуры наложенной сети, формирования персональной сети (PAN) между MN и локальным узлом FR/HR. Если подобное локальное соединение является возможным, и, в свою очередь, локальный узел FR/HR соединен с наложенной инфраструктурой, MN может соединиться с инфраструктурой наложенной сети через локальный узел FR/HR, который предлагает лучшее решение для соединения. В последнем случае подсоединенный локальный узел FR/HR для MN и любого запрашивающего клиента является частью наложенной сети. Если локальный клиент, например клиент веб-браузера, постоянно находится на персональном компьютере, содержащем также локальный узел FR/HR, и клиент запрашивает содержимое от локального MN, ранее не соединенного с локальным узлом FR/HR, бесшовное переключение прикладного сеанса можно выполнить, устанавливая, по запросу, локальное соединение между MN и FR/HR и затем направляя запросы к FR/HR через сокет локального хоста. Процедура выполнения данного процесса, предполагающая использование Bluetooth для локального соединения, выглядит следующим образом.

1. Обнаружить и установить соединение через Bluetooth путем установки соединения MN и локального HR/FR.

2. Открыть сокет локального хоста и подождать входящий поток в MN и локальный узел HR/FR соответственно.

3. MN заказывает текущий оверлей HR/FR, чтобы ответить на любые входящие запросы от клиента перенаправленным ответом к сокету локального хоста.

4. Оверлей HR/FR возвращает перенаправленный ответ на сокет локального хоста персонального компьютера клиента.

5. Узел FR/HR персонального компьютера клиента передает входящий перенаправленный запрос к MN через Bluetooth.

6. MN принимает перенаправленный запрос, собирает ответ и затем отправляет ответ на узел FR/HR персонального компьютера клиента через Bluetooth.

7. Узел FR/HR персонального компьютера клиента передает ответ на сокетлокального хоста, и переключение завершается - браузер имеет все для просмотра веб-страницы.

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

На фиг.15 показана часть системы эффективного манипулирования и управления сигнализацией и обменом исходящими и входящими сообщениями между MN и его текущей точкой присоединения (реализована узлами HR/FR), согласно одному варианту осуществления изобретения. Данный способ является ключевым для манипулирования возможно недостаточными ресурсами в мобильном устройстве и в беспроводном доступе, потенциально небольшой емкости или ненадежном, между MN и его узлом привязки FR/HR. Некоторые примеры осуществления содержат следующие функциональные элементы:

предварительную обработку, прокси-функциональность и управление входящим и исходящим потоком, соответственно. Балансировка нагрузки исходящего потока и управление потоком проиллюстрированы на фиг.15. На чертеже показано, как потоки информационных данных к мобильным устройствам MN, расположенным справа, прибывают к общей точке присоединения (FR или HR) слева. FR направляет и при необходимости временно сохраняет входящий поток в своем внутреннем буфере. Каждое мобильное устройство MN логически представлено внутри узла привязки. Структура алгоритма планирования управляет доступом к общему каналу передачи данных. Внутри каждого такого представления устройства, каждое приложение, выполняемое на устройстве, представлено одним или несколькими буферами. Структура алгоритма планирования управляет доступом к общему каналу передачи данных. Для обеспечения надлежащего контроля, обратная связь текущего состояния пропускной способности канала (c(t)) и производительности приложения (b(t)) передается от каждого мобильного устройства MN обратно на узел привязки. Планировщики организованы в иерархическую структуру, и данные запланированы на общий транспортный канал (или заблокированы в случае перегрузки) в соответствии с текущей политикой планирования (конфигурируемой администратором узла). Подобная структура требуется также в направлении исходящего потока к узлу привязки, где каждое устройство управляет потоком данных от каждого приложения, работающего в устройстве.

Управление потоком между MN и его узлом привязки (HR/FR) также создает и функциональность разгрузки предварительной обработки и обработки. Это управляется посредством отдельного протокола передачи управляющих сигналов (предполагается передача «вне полосы» в настоящем изобретении, но также может использоваться внутриполосная передача сигналов), который определяет правила и политику в отношении предварительной обработки в узле привязки от имени текущих активных приложений устройства. Обычно устройство может передавать, в соответствии с хорошо описанной структурой управления, инструкции к узлу привязки. Подобные инструкции обычно инструктируют узел привязки, как и для каких прикладных данных должна быть выполнена проверка пакета данных и классифицикация, когда и каким образом любые результаты предварительной обработки нужно передать на устройство (обычно в письменном закодированном виде в соответствующих пакетах и в соответствующем поле данных). Очевидно, что с помощью данного способа может быть внедрена фильтрация пакетов, подобная функциональности обеспечения безопасности и контроля доступа.

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

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

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

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

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

Claims (24)

1. Способ формирования универсальной наложенной сети для эффективного поиска информации в сети связи, отличающийся тем, что он содержит следующие этапы:
получение (204) в доменном маршрутизаторе (103) от мобильного устройства (106) связи запроса на регистрацию, включающего идентификатор указанного мобильного устройства связи,
поиск (205) адреса маршрутизатора следующего перехода (104), связанного с указанным идентификатором,
передачу (206) указанного запроса к маршрутизатору следующего перехода (104),
получение (210) ответа от маршрутизатора следующего перехода (104), и если ответ содержит адрес домашнего маршрутизатора (104),
передачу (211) на мобильное устройство (106) связи ответа, включающего адрес домашнего маршрутизатора (104), причем указанный ответ инициирует создание соединения между мобильным устройством (106) связи и домашним маршрутизатором (104).

2. Способ по п.1, согласно которому этап поиска (205) дополнительно содержит этап идентификации сетевого адреса домашнего маршрутизатора (104) в сети связи.

3. Способ по п.1 или 2, согласно которому этап поиска (205) основан на близости сети или географическом положении, или измерении пропускной способности и трафика, или соглашениях о равноправном информационном обмене, установленных на основании сообществ или известных межличностных связей в случае домашнего маршрутизатора (104).

4. Способ по п.3, согласно которому близость сети определяется на основании количества интервалов связи и/или задержки проверки возможности установления соединения посредством запроса/отклика и контроля прохождения сигнала по сети и/или перекрывающихся маршрутов для домашнего маршрутизатора (104).

5. Способ по п.3, согласно которому географическое положение основывается на данных GPS мобильного устройства (106) связи.

6. Доменный маршрутизатор (103) для формирования универсальной наложенной сети для эффективного поиска информации в сети связи, отличающийся тем, что он содержит
ресивер (301), выполненный с возможностью принимать от мобильного устройства (106) связи запрос на регистрацию, включающий идентификатор указанного мобильного устройства связи,
контроллер (302), выполненный с возможностью поиска адреса маршрутизатора следующего перехода (104, 105), связанного с указанным идентификатором, и
передатчик (303), выполненный с возможностью пересылать запрос на регистрацию к маршрутизатору следующего перехода (104, 105),
причем ресивер (301) выполнен с возможностью принимать ответ от маршрутизатора следующего перехода (104, 105), контроллер (302) выполнен с возможностью определять, содержит ли ответ сетевой адрес домашнего маршрутизатора (104), а передатчик (303) выполнен с возможностью отправлять на мобильное устройство (106) связи ответное сообщение, включающее адрес домашнего маршрутизатора (104) и инициирующее создание соединения между мобильным устройством связи и домашним маршрутизатором.

7. Доменный маршрутизатор по п.6, в котором сетевой адрес является доменным именем, а доменный маршрутизатор (103) зарегистрирован в качестве агента для группы доменных имен, доступных для поиска в электронной сети связи.

8. Доменный маршрутизатор по п. 6 или 7, в котором ресивер (301) выполнен с возможностью принимать запрос на поиск логического идентификатора от одного или более клиентов (101), контроллер (302) выполнен с возможностью искать домашний маршрутизатор или чужой маршрутизатор, ассоциированный с логическим идентификатором, и управлять передатчиком, чтобы отправить запрос поиска к обнаруженному домашнему маршрутизатору, ресивер выполнен с возможностью принимать перенаправленный адрес узла переключения, ответственного за перемещение запроса от обнаруженного домашнего маршрутизатора, а передатчик выполнен с возможностью отвечать на запрос клиента перенаправленным адресом узла переключения.

9. Доменный маршрутизатор по п.6 или 7, содержащий маршрутную таблицу адресов домашних маршрутизаторов или чужих маршрутизаторов.

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

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

12. Доменный маршрутизатор по п.6 или 7, в котором контроллер выполнен с возможностью поддерживать соединения на транспортном уровне со всеми маршрутизаторами в маршрутной таблице.

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

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

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

16. Способ формирования универсальной наложенной сети для эффективного поиска информации в сети связи, отличающийся тем, что согласно этому способу получают (207) в домашнем маршрутизаторе (104) запрос на регистрацию мобильного устройства (106) связи от доменного маршрутизатора (103), включающий идентификатор указанного мобильного устройства связи, в ответ на указанный запрос генерируют (208) ответ, содержащий адрес домашнего маршрутизатора, и передают (209) этот ответ доменному маршрутизатору (103), чтобы инициировать пересылку на мобильное устройство (106) связи ответа, содержащего адрес домашнего маршрутизатора.

17. Способ по п.16, включающий:
получение запроса на регистрацию от мобильного устройства (214) связи и в ответ на указанный запрос установление (215, 216) соединения между мобильным устройством (106) связи и домашним маршрутизатором (104).

18. Способ по п.17, согласно которому в качестве указанного соединения используют соединение транспортного уровня.

19. Домашний маршрутизатор (104) для формирования универсальной наложенной сети для эффективного поиска информации в сети связи, отличающийся тем, что он содержит
ресивер (311), выполненный с возможностью принимать от доменного маршрутизатора (103) запрос на регистрацию мобильного устройства (106) связи, включающий идентификатор указанного мобильного устройства связи,
контролер (312), выполненный с возможностью в ответ на указанный запрос генерировать ответ, содержащий адрес домашнего маршрутизатора,
и передатчик (313), выполненный с возможностью направлять доменному маршрутизатору (103) ответ, содержащий адрес домашнего маршрутизатора, чтобы инициировать пересылку ответа на мобильное устройство (106) связи.

20. Домашний маршрутизатор по п.19, в котором ресивер (311) выполнен с возможностью принимать запрос на регистрацию от мобильного устройства (106) связи, а контроллер (312) выполнен с возможностью в ответ на указанный запрос от мобильного устройства (106) связи устанавливать соединение между домашним маршрутизатором (104) и мобильным устройством (106) связи.

21. Способ формирования универсальной наложенной сети для эффективного поиска информации в сети связи, отличающийся тем, что согласно этому способу:
запрашивают (201) соединение с домашним маршрутизатором (104) путем отправки запроса серверу доменных имен (102),
получают (202) адрес доменного маршрутизатора (103), соединенного с домашним маршрутизатором (104),
запрашивают (203) регистрацию на домашнем маршрутизаторе (104) полученного адреса путем отправки (203) запроса на регистрацию доменному маршрутизатору (103),
получают (212) регистрационный ответ от доменного маршрутизатора (103) со ссылкой на домашний маршрутизатор (104),
генерируют и отправляют (213) запрос на регистрацию непосредственно домашнему маршрутизатору (104),
и устанавливают (217) соединение между домашним маршрутизатором (104) и мобильным устройством (106) связи.

22. Читаемый компьютером носитель, содержащий компьютерную программу, содержащую средства компьютерного программного кода, выполненные с возможностью исполнения этапов способа по любому из п.1, 2, 4, 5, 16-18 и 21, когда указанная программа выполняется на компьютере.

23. Читаемый компьютером носитель, содержащий компьютерную программу, содержащую выполнимые компьютером инструкции для выполнения компьютером способов по п.1, 2, 4, 5, 16-18 и 21, при выполнении указанной программы на компьютере.

24. Читаемый компьютером носитель по п.23, который является носителем записи, компьютерной памятью, постоянным запоминающим устройством или носителем электрического сигнала.

Images