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

Настоящее изобретение относится к способу определения сервера, отвечающего на запрос обслуживания. Технический результат изобретения заключается в возможности выбора наиболее близкого сервера, что повышает качество соединения. Способ выбора сервера, отвечающего на запрос обслуживания из мобильного устройства, включает: формирование DNS-запроса, включающего идентификатор URI, служащий для идентификации службы, запрошенной мобильным устройством, и, в дополнение к идентификатору URI запрошенной службы, указание на местоположение мобильного устройства; ввод в DNS-запрос ключевого слова, указывающего, что DNS-запрос относится к службе, для которой возможен перенос служб; направление указанного DNS-запроса в DNS-сервер; определение наиболее подходящего сервера для ответа на указанный запрос обслуживания, выполняемое DNS-сервером, причем данное определение основано на местоположении мобильного устройства, указанного посредством указания на местоположение, добавленного к URI; возврат адреса сервера, определенного на основании местоположения, в мобильное устройство. 4 н. и 9 з.п. ф-лы, 7 ил.

.

 

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

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

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

Когда мобильное устройство пользователя выполняет подключение к какой-либо службе, оно в первую очередь должно определить адрес узла, предоставляющего данную службу. Для служб, доступ к которым предоставляется через Интернет, такое определение осуществляется путем использования DNS (Domain Name System, система доменных имен), которая преобразует имена доменов, имеющие смысл для человека, в числовые идентификаторы, привязанные к сетевому оборудованию или к службам, давая возможность находить оборудование и службы независимо от географического расположения и обращаться к ним. Операция нахождения числового адреса (IP-адреса) элемента сети, соответствующего DNS- запросу, называется разрешением имени посредством DNS (разрешением DNS). Нахождение адресов серверов посредством DNS часто используется и в технологии IMS (IP Multimedia Subsystem, подсистема передачи мультимедийных данных с использованием протокола IP).

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

Если служба может работать из нескольких местоположений, то необходим способ определения адреса службы, наиболее подходящего для конкретного пользователя. Наиболее подходящий адрес определяется такими факторами, как местоположение пользователя и нагрузка на серверы. Поэтому при использовании DNS для предоставления адреса сервера, к которому должен быть направлен пользователь, для DNS потребуется информация о местоположении пользователя. Если сделать возможным сообщение в DNS-сервер информации о местоположении, то DNS-сервер можно усовершенствовать, добавив операции определения наилучшего сервера и предоставления адреса этого сервера. Строго говоря, это был бы не обычный DNS-сервер, а, скорее, отдельное приложение системы DDDS (Dynamic Delegation Discovery System, система поиска адреса при динамическом делегировании), поскольку обычный DNS-сервер не имеет интеллектуальных средств выбора наилучшего сервера на основании местоположения пользователя.

В стандартах 3GPP на ЕРС (Evolved Packet Core, усовершенствованное ядро пакетной передачи данных) механизмы выбора для S-GW и P-GW основаны на использовании DNS (см. 3GPP Technical Specification 29.303, Domain Name System Procedures, Stage 3 (Release 9)). Стандарты предусматривают наличие в ММЕ (Mobility Management Entity, устройство управления мобильностью) DNS-сервера, использующего при DNS-запросе информацию о местоположении мобильного устройства UE, к примеру, идентификатор TAI или идентификатор соты. Упомянутые механизмы основаны на использовании системы DDDS (см. M.Mealling, Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS, IETF RFC 3401, October 2002), которая дает возможность использовать в DNS технологию позднего связывания (lazy binding). Однако использование информации о местоположении ограничено выбором специализированных серверов и требует реализации упомянутых механизмов в ММЕ. Было бы желательно сделать возможным использование DNS для направления запроса к любой службе, поддерживающей технологию SPM (service program mobility, мобильность программ, реализующих службы), в произвольный сервер, в том числе и в расположенный за пределами сети мобильной связи. Более того, было бы желательно, чтобы от гостевой сети при этом не требовалось никакой специальной поддержки, что облегчило бы внедрение SPM.

Сети доставки контента, например Akamai, используют DNS для направления пользователя к наиболее выгодно расположенному серверу, который определяется на основании местоположения пользователя (см. Mukaddim Pathan and Rajkumar Buyya, "A Taxonomy of CDNs", Content Delivery Networks, R.Buyya, M.Pathan, and A.Vakali (Eds.), Springer-Verlag, Germany, 2008). Однако система Akamai основана на использовании большого числа DNS-серверов и определении местоположения пользователя по задержкам между пользователем и разными серверами. Представляется желательной разработка более простого и удобного в реализации способа.

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

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

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

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

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

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

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

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

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

В одном из вариантов осуществления DNS-сервер сети, с которой напрямую соединено мобильное устройство, получает указанную информацию о местоположении путем обращения к элементу сети, обладающему такой информацией, предпочтительно к устройству управления мобильностью (ММЕ) и/или к серверу абонентских данных (HSS) сети 3GPP SAE либо к соответствующим элементам сетей других стандартов, например, к домашнему регистру местоположения (HLR) и/или к гостевому регистру местоположения (VLR).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Указанным образом может быть осуществлено устройство (или система), осуществляющее вариант осуществления настоящего изобретения.

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

Указанным образом может быть осуществлено мобильное устройство в соответствии с вариантом осуществления настоящего изобретения.

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

Указанным образом может быть осуществлен DNS-сервер в соответствии с вариантом осуществления настоящего изобретения.

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

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

Фиг.1 схематично иллюстрирует способ перенаправления в соответствии с вариантом осуществления настоящего изобретения.

Фиг.2 схематично иллюстрирует способ перенаправления в соответствии с еще одним вариантом осуществления настоящего изобретения.

Фиг.3 схематично иллюстрирует часть способа перенаправления в соответствии с еще одним вариантом осуществления настоящего изобретения.

Фиг.4 схематично иллюстрирует серверную базу данных в соответствии с еще одним вариантом осуществления настоящего изобретения.

Фиг.5 схематично иллюстрирует способ перенаправления в соответствии с еще одним вариантом осуществления настоящего изобретения.

Фиг.6 схематично иллюстрирует способ перенаправления в соответствии с еще одним вариантом осуществления настоящего изобретения.

Фиг.7 схематично иллюстрирует часть способа перенаправления в соответствии с еще одним вариантом осуществления настоящего изобретения.

Осуществление изобретения

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

CSCF - Call Session Control Function (функциональный модуль управления сеансами вызова)

DDDS - Dynamic Delegation Discovery System (система поиска адреса при динамическом делегировании)

DNS - Domain Name System (система доменных имен)

HLR - Home Location Register (домашний регистр местоположения)

IMS - IP Multimedia System (система передачи мультимедийных данных с использованием протокола IP)

NAPTR - Name Authority Pointer (указатель на источник имени, запись в базе DNS)

P-CSCF - CSCF-посредник S-CSCF - обслуживающий CSCF

SPM - Service Program Mobility (мобильность программ, реализующих службы)

UE - User Equipment (мобильное устройство (терминал пользователя))

VLR - Visitor Location Register (гостевой регистр местоположения)

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

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

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

Для DNS-сервера наиболее простым способом определения местоположения пользователя является использование IP-адреса, с которого приходит запрос. Данный способ, однако, имеет недостатки. Если DNS-запрос поступает от промежуточного DNS-сервера (посредника), то адресом, с которого принят запрос, будет видимый адрес данного промежуточного сервера.

Одним из преимуществ вариантов осуществления настоящего изобретения в сравнении с использованием IP-адреса является независимость от конфигурации IP-адресов в гостевой сети. Указанная независимость может достигаться путем добавления указания на местоположение мобильного устройства, формируемого, к примеру, на основании кодов сети мобильной связи. Коды сетей мобильной связи меняются реже, чем IP-адреса, благодаря чему снижаются необходимые операционные издержки. Второе преимущество состоит в том, что предлагаемый в одном варианте осуществления способ дает DNS-серверу возможность поддержки не только прямых запросов из гостевой сети, но и запросов, приходящих другими маршрутами. Это преимущество, в частности, полезно для IMS, где запросы могут приходить из модуля S-CSCF домашней сети.

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

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

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

В одном варианте осуществления рассматриваемая система включает два главных новых компонента: программный компонент в мобильном устройстве UE, который перед разрешением DNS принимает транслируемую информацию из радиоинтерфейса сети мобильной связи (такую, например, как используемый для мобильной связи код МСС страны, и/или код MNC сети мобильной связи данной сети, и/или идентификатор соты), а затем добавляет принятую информацию к URI; и модифицированный DNS-сервер (или DDDS-сервер), который на основании местоположения пользователя определяет, адрес какого сервера должен быть передан в ответ на запрос. В конкретных вариантах осуществления настоящего изобретения DNS-сервер также может использовать дополнительную информацию, например, о возможности получения доступа к программным компонентам на серверах, о текущей нагрузке на разные серверы, которые могут быть использованы, и результаты согласований, выполняемых со сторонними поставщиками услуг. В одном из вариантов осуществления, где учитывается нагрузка на доступные серверы, в случае, если, например, нагрузка наиболее предпочтительного с точки зрения местоположения сервера превосходит определенное пороговое значение, может выбираться следующий по предпочтительности относительно местоположения сервер, если его нагрузка является приемлемой.

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

Данный способ по сравнению с использованием для определения местоположения пользователя лишь IP-адреса запрашивающего клиента или DNS-сервера имеет следующие преимущества:

- возможность оптимизации размещения в домашней сети благодаря более точной информации о местоположении;

- невосприимчивость к использованию других DNS-серверов (к примеру, DNS-сервера Google 8.8.8.8).

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

DNS широко используется для определения адресов серверов в Интернете. Эта технология также используется как средство оптимизации маршрутов доступа к службам, например, в сетях доставки контента. Операторы сетей мобильной связи обычно предоставляют свои собственные DNS-серверы, которые могут использоваться для направления клиента к наиболее подходящему серверу. Данный может использоваться различным образом там, где для нахождения службы применяется DNS. Например, S-CSCF может использовать DNS для запроса местоположения определенного компонента службы. Однако для того, чтобы DNS-сервер мог давать индивидуальный ответ для клиента, данному серверу должна быть предоставлена достаточная информация. Поскольку стандартный DNS-запрос содержит только IP-адрес запрашивающего клиента или посредника (прокси-сервера), дополнительную информацию необходимо предоставлять в самом запросе, в противном случае ответ будет дан на основании местоположения сервера. Кроме того, коды МСС и MNC очень редко меняются, тогда как IP-адреса могут переназначаться, поэтому соотнесение IP-адреса с определенной сетью или местоположением требует больших операционных издержек, чем использование для этой цели МСС или MNC.

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

Когда клиент запрашивает новую службу напрямую с сервера, перенаправление может выполняться системой DNS (или ответственным DNS-сервером). В данном разделе под DNS-сервером понимается усовершенствованный сервер, служащий функциональным модулем перенаправления или реализующий функцию перенаправления. Во-первых, рассматривается случай, когда DNS-запрос включает информацию о местоположении мобильного устройства UE, добавляемую к имени домена. В данном случае DNS-сервер с помощью функций DDDS может непосредственно использовать информацию о местоположении для выбора сервера, к которому должен быть направлен пользователь, пользуясь при этом дополнительной информацией из серверной базы данных. В результате DNS-сервер выдает надлежащий IP-адрес, используя который, клиент может соединиться с сервером. Фиг.1 иллюстрирует данный способ. Далее кратко поясняется операция, показанная на фиг.1.

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

При запуске приложения мобильное устройство UE соединено с гостевой сетью. На шаге 1) с использованием API операционной системы (Symbian, Androd и т.п.) мобильного телефона определяется идентификатор PLMN-ID, состоящий из компонента MCC (mobile country code, мобильный код страны) и компонента MNC (mobile network code, код сети мобильной связи). Указанный идентификатор является указанием на местоположение мобильного устройства и используется для формирования модифицированного DNS-запроса, имеющего формат . Здесь служба «ServiceName» предоставляется в домене оператора мобильной связи Docomo (поэтому домен «ServiceName» является поддоменом домена «Docomo»), идентификаторы MNC и МСС, образующие признак местоположения мобильного устройства, представлены двумя поддоменами, а поддомен SPM (самого нижнего уровня) указывает на то, что данный запрос к службе рассчитан на возможность обслуживания сетью с поддержкой SPM (хотя в данном варианте осуществления сеть технологию SPM не поддерживает).

На шаге 2) выполняется разрешение DNS и запрос пересылается из гостевой сети в DNS-сервер домашней сети (Docomo).

На шаге 3) на основании MCC/MNC и имени службы (ServiceName) выполняется разрешение DNS. С этой целью возможно обращение к серверной базе данных, хранящей список подходящих (внешних) серверов, определяемых местоположением мобильного устройства UE. Если путем поиска в базе данных найден подходящий внешний (по отношению к домашней сети) сервер и если найденный сервер обладает необходимыми для запрошенной службы техническими возможностями, то на шаге 4) обратно отправляется ответ DNS, содержащий адрес данного сервера. Указанным образом может определяться и возвращаться в мобильное устройство UE адрес внешнего сервера, расположенного ближе к мобильному устройству UE, чем сервер домашней сети (в рассмотренном случае сети Docomo), и/или который не делает роуминг необходимым.

Затем на шаге 5) мобильное устройство UE может через Интернет устанавливать соединение с данным внешним сервером.

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

Другая особенность, которую необходимо учитывать при перенаправлении с использованием DNS, состоит в том, кто управляет авторитетным DNS-сервером для данного имени домена. Обычно это поставщик услуг, который может быть, а может и не быть оператором домашней сети. Наиболее важен случай, когда оператор домашней сети также является поставщиком услуг. Если должны поддерживаться и те ориентированные на SPM службы, которые оператор домашней сети (хотя бы в качестве посредника) не предоставляет, то запрос разрешения DNS может направляться в DNS-сервер оператора домашней сети.

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

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

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

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

Далее кратко поясняется операция, показанная на фиг.2, с основным вниманием к отличиям от операции, показанной на фиг.1.

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

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

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

На шаге 4) адрес сервера возвращается в виде ответа DNS, а на шаге 5) устанавливается соединение между мобильным устройством UE и данным сервером (сервером гостевой сети).

Усовершенствованный DNS-сервер выполнен с возможностью поиска, соответствующего строке (URI), содержащейся в DNS-запросе. Данную операцию иллюстрирует фиг.3. DNS-сервер, обнаружив, что запрошена служба, ориентированная на SPM (обнаружение может выполняться, например, по ключевому слову «spm» в строке DNS-запроса, как показано в первом ветвлении на фиг.3), на основании запрошенной службы и идентификаторов MCC/MNC сужает список серверов, которые могут быть выбраны. Порядок применения двух указанных критериев отбора зависит от выбранного плана внедрения. В принципе было бы удобно на первом шаге сузить список серверов до минимума. То есть, если серверы, как правило, имеют возможность обслуживать лишь небольшое подмножество служб, то предпочтительно сначала сделать выбор на основании запрошенной службы, что и показано на фиг.3. Такая ситуация может иметь место, например, когда должны быть выбраны средства реализации службы конкретного поставщика. Если же большая часть серверов имеет возможность обслуживать большую часть служб, то, напротив, предпочтительно сначала сузить список серверов, которые могут быть выбраны, используя MCC/MNC.

На фиг.3 также показано, что DNS-сервер взаимодействует с серверной базой данных. Предлагаемая структура этой базы данных показана (не полностью) на фиг.4. Первоначально технические возможности сервера можно указывать в форме битовой маски с длиной, соответствующей набору служб, предоставляемых сетью, где каждый бит обозначает одну службу. По мере роста количества служб, предлагаемых в сети, более удобным может оказаться указание технических возможностей сервера не в форме возможности поддержки той или иной службы, а, например, в форме указания поддерживаемых API и аппаратных ресурсов. Соответственно, база данных может быть расширена с целью включения полей для обоих способов указания технических возможностей. Поле MCC/MNC содержит информацию о местоположении и сервере запрошенной службы, который может быть использован для данного местоположения. Если оператор сервера решил использовать разные серверы в разных частях сети, то для некоторых серверов может указываться идентификатор соты или информация о местоположении. Кроме того, в базу данных включено указание на структуру, управляющую сервером (здесь также должна быть информация о способе связи с управляющей организацией для согласования использования сервера). Также включен адрес сервера, хотя если сервером управляет другая организация, то адрес может предоставляться при согласовании. Это, в принципе, дает оператору гостевой сети дополнительную возможность предоставления частного IP-адреса, поскольку ему известно местоположение UE.

В одном из вариантов осуществления предусматривается, что если местоположение UE не сообщено в DNS-запросе, то данное местоположение все равно может быть определено с использованием информации из сети, то есть из устройства управления мобильностью (Mobility Management Entity, ММЕ) или из сервера абонентских данных (Home Subscriber Server, HSS). Если указанная информация добавляется в DNS-запрос в первом DNS-сервере (в сети, к которой присоединено мобильное устройство), то указанный запрос будет выглядеть так же, как если бы он поступил из мобильного устройства вместе с информацией о местоположении, и поэтому можно использовать ту же операцию разрешения DNS в домашней сети, которая описана в вышеприведенных вариантах осуществления изобретения. Кроме того, указанная информация может добавляться DNS-сервером домашней сети с использованием полученной из HSS информации о том, к какой сети присоединено мобильное устройство UE.

Информация о местоположении может запрашиваться из сети усовершенствованным DNS-сервером на этапе подготовки перед началом операции, иллюстрируемой фиг.3. В роуминге получение информации о местоположении из ММЕ может иметь преимущество, поскольку авторитетному DNS-серверу будет предоставлена вся необходимая информация даже в том случае, когда указанный сервер работает не под управлением домашней сети (т.е. управляется сторонним поставщиком услуг). Как вариант, информацию о местоположении может запрашивать контроллер размещения. Причина, по которой функция запроса информации о местоположении передается контроллеру размещения, состоит в том, что данная информация требуется именно этому функциональному модулю.

На фиг.5 показан такой вариант осуществления без приложения, поддерживающего SPM, в котором информация о местоположении добавляется в DNS-сервере.

На шаге 1) формируется запрос обслуживания без информации о местоположении. Затем в DNS-сервере выполняется проверка возможности использования SPM для данной службы. На шаге 2' из ММЕ и/или HSS получают информацию о местоположении UE.

Затем запрос местонахождения службы направляется в контроллер размещения (шаг 3), который выдает соответствующий ответ (шаг 4). Данному ответу соответствует адрес сервера / адрес службы, который на шаге 5) возвращается DNS-сервером. Затем на шаге 6) устанавливается соединение с сервером, адрес которого был возвращен.

Далее рассматривается применимость перенаправления с использованием DNS в случае использования IMS. В IMS при передаче запроса обслуживания из UE функциональный модуль P-CSCF обращается к функциональному модулю S-CSCF (обслуживающему CSCF) домашней сети пользователя. Указанный модуль S-CSCF затем направляет сессию в сервер приложений (application server, AS). Для нахождения указанного сервера S-CSCF может использовать DNS, то есть перенаправление с использованием DNS применимо и для данного случая. Однако при этом необходимо включать информацию о местоположении UE в DNS-запрос, поскольку в противном случае выбор оптимального сервера будет осуществляться на основании IP-адреса S-CSCF. Вызывающий терминал может при подготовке вызова включать в сигнализацию IMS указание технологии доступа к сети и идентификатор соты. Данная информация может быть использована при DNS-поиске путем добавления МСС, MNC и идентификатора соты к URI с целью получения ответа, зависящего от местоположения. Соответственно, данная модификация DNS-сервера может использоваться и системой IMS.

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

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

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

Шаг 1 аналогичен описанному в связи с предыдущими вариантами осуществления изобретения. На шаге 2) DNS-запрос перехватывается DNS-сервером гостевой сети. Операция, выполняемая DNS-сервером гостевой сети, показана на фиг.7. Перехват может запускаться, например, когда первым элементом запроса является «spm», как показано на фиг.7. Таким образом DNS-сервер распознает, что вместо пересылки запроса в домашнюю сеть он должен перехватить данный запрос. Затем на шаге 3) изучается возможность запуска службы в гостевой сети, что может выполняться, например, путем обращения к серверной базе данных, как показано на фиг.7, либо путем использования контроллера размещения, как показано на фиг.6, при этом возможно обращение к базе данных.

Если указанная возможность отсутствует, то запрос пересылается в домашнюю сеть (см. фиг.7). Если же возможность запуска службы в гостевой сети имеется, то выполняется согласование условий (например, стоимости) с домашней сетью (например, между двумя контроллерами размещения сетей), как показано на шаге 3' на фиг.6 и на фиг.7.

Если согласование завершилось успешно, то передается ответ DNS, содержащий адрес сервера в гостевой сети, на котором должна быть запущена служба (шаг 4)), а затем на шаге 5) устанавливается соединение. Если же согласование завершилось неуспешно, то запрос направляется в домашнюю сеть.

Специалисту очевидно, что способы, элементы, модули и устройства, описанные в связи с вариантами осуществления настоящего изобретения, могут быть осуществлены аппаратно, программно или сочетанием указанных способов. В частности, понятно, что варианты осуществления настоящего изобретения и элементы модулей, описанных в связи с указанными вариантами, могут быть осуществлены компьютерной программой или компьютерными программами, работающими на компьютере или исполняемыми микропроцессором. Любое устройство, осуществляющее настоящее изобретение, может, в частности, представлять собой элемент сети, например, маршрутизатор, сервер (в частности, DNS-сервер), модуль, работающий в сети, либо мобильное устройство, например, мобильный телефон, смартфон, карманный персональный компьютер (Personal Digital Assistant, PDA), мобильный терминал и т.п.

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

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

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

4. Способ по п.1, отличающийся тем, что
указание на местоположение мобильного устройства получает и вводит в DNS-запрос мобильное устройство, или
указание на местоположение мобильного устройства получает элемент сети или получают из элемента сети, которому известно указание на местоположение мобильного устройства.

5. Способ по п.4, отличающийся тем, что DNS-сервер сети, с которой напрямую соединено мобильное устройство, получает указанную информацию о местоположении путем обращения к элементу сети, обладающему такой информацией, предпочтительно к устройству управления мобильностью (ММЕ) и/или к серверу абонентских данных (HSS) или к домашнему регистру местоположения (HLR) и/или к гостевому регистру местоположения (VLR) указанной сети.

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

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

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

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

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

11. Устройство связи, включающее мобильное устройство, взаимодействующее с устройством по п.10, содержащее:
модуль для определения указания на местоположение мобильного устройства, предпочтительно на основании информации, транслируемой сетью, с которой соединено мобильное устройство;
модуль для формирования DNS-запроса, включающего идентификатор URI, служащий для идентификации службы, запрашиваемой мобильным устройством, и, в дополнение к идентификатору URI запрашиваемой службы, указание на местоположение мобильного устройства.

12. Устройство связи, включающее DNS-сервер в сети, взаимодействующее с устройством по п.10, содержащее:
модуль для приема из мобильного устройства DNS-запроса, включающего идентификатор URI службы, служащий для идентификации службы, запрашиваемой мобильным устройством, и, в дополнение к идентификатору URI запрашиваемой службы, указание на местоположение мобильного устройства;
модуль для определения сервера на основании местоположения мобильного устройства; и
модуль для возврата адреса сервера, определенного на основании указанного местоположения, в мобильное устройство.

13. Устройство по одному из пп.10-12, отличающееся тем, что дополнительно содержит модуль для выполнения шагов или реализации признаков, предусмотренных одним из пп.2-9.



 

Похожие патенты:

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

Изобретение относится к вычислительным сетям, а именно к системам и способам обеспечения безопасности компьютерных сетей. .

Изобретение относится к электросвязи, в частности к способам оценки информационной эффективности систем связи. .

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

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

Изобретение относится к области управления цифровыми правами (DRM) в сетях беспроводной связи. .

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

Изобретение относится к системе активной подвески для транспортного средства. .

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

Изобретение относится к способам информационного взаимодействия бортовых электронно-вычислительных машин с периферийными устройствами, в частности с навигационными приборами и устройствами. Техническим результатом является повышение эффективности и надежности работы информационной системы за счет определения достоверных навигационных параметров: широты места, долготы места и высоты места объекта, истинных значений курса, крена и тангажа объекта. Способ информационного взаимодействия автономной аппаратуры топопривязки и навигации и бортовой ЭВМ включает в себя преобразование, передачу, прием измерительных и управляющих сигналов по проводным и беспроводным линиям связи согласно протоколу информационного взаимодействия, который обеспечивает работу автономной аппаратуры топопривязки и навигации в следующих режимах: «ОЖИДАНИЕ», «ПОДГОТОВКА К РАБОТЕ», «ВЫСТАВКА», «НАВИГАЦИЯ», «ТЕСТ-КОНТРОЛЬ», причем информационное взаимодействие осуществляется в соответствии с заданными перечнями параметров, для каждого из которых определен соответствующий тип данных. 7 ил., 2 табл.

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

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

Изобретение относится к устройству и способу для приема сигналов. Технический результат состоит в возможности вычисления среднего значения принятых сигналов для каждой сигнальной точки. Для этого устройство имеет: блок идентификации радиуса, выполненный с возможностью идентификации радиуса, представляющего собой расстояние от начала координат на плоскости IQ сигнальных точек, каждая из которых соответствует символу, полученному из принятого сигнала, модулированного с использованием способа модуляции АФМн (амплитудно-фазовой манипуляции); и блок вывода параметров, выполненный с возможностью вывода параметра управления, который относится к демодуляции или к процессу декодирования принятого сигнала на основании идентифицированного радиуса. 6 н. и 8 з.п. ф-лы, 12 ил.

Изобретение относится к беспроводной связи. Технический результат состоит в разрешении проблемы растущих требований по ширине полосы, необходимой для систем беспроводной связи. Для этого раскрыты способы (и соответствующие устройства) для беспроводной связи, содержащие формирование преамбулы, по меньшей мере, с одним полем сигнала (SIG) в части преамбулы, ассоциированной с первой технологией радиодоступа, причем поля SIG содержат биты параметров, указывающие управляющую информацию, общую для множества устройств, работающих в соответствии со второй технологией радиодоступа; и передачу преамбулы в пределах кадра во множество устройств. 10 н. и 12 з.п. ф-лы, 8 ил.

Изобретение относится к радиотехнике и может быть использовано для оценки информационных возможностей телекоммуникационных сетей (ТКС) связи, в частности для оценки информационных возможностей узла ТКС. Технический результат изобретения - повышение достоверности оценки возможностей узла ТКС при прохождении разноприоритетных информационных сообщений. Для этого при определении производительности узла ТКС за выбранный интервал времени, в ходе которого измеряют количество находящейся в узле ТКС информации в статическом и динамическом состоянии, определяют общее количество находящейся в узле ТКС информации в очереди приоритетов как сумму сообщений первого и второго порядка, после чего находят кибернетическую мощность узла ТКС в соответствии с выражением , где KWП - кибернетическая мощность узла ТКС; N1 и N2 - число сообщений соответственно первого и второго порядка приоритета; G - производительность узла телекоммуникационной сети; T - временной интервал усреднения. 2 ил.

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

Изобретение относится к способу и устройству управления вызовом. Технический результат заключается в уменьшении времени на маршрутизацию. Способ управления вызовом, в котором способ содержит этапы, на которых: принимают с помощью устройства управления вызовом запрос на сеанс, переданный вызывающей стороной, где запрос на сеанс включает в себя идентификационную метку вызываемой стороны; и если возникает ошибка при соединении между устройством управления вызовом и обслуживающим объектом функции управления сеансом вызова S-CSCF, проверяют в соответствии с идентификационной меткой вызываемой стороны, является ли вызываемая сторона пользователем, принадлежащим устройству управления вызовом, и если это так, непосредственно передают запрос на сеанс вызываемой стороне для соединения вызова. 2 н. и 6 з.п. ф-лы, 8 ил.

Изобретение относится к области передачи данных в цифровых сетях передачи данных по протоколу TCP/IP через HTTP. Техническим результатом является повышение скорости передачи данных между клиентом и сервером. Способ передачи данных в цифровых сетях передачи данных по протоколу TCP/IP через HTTP реализуется с помощью системы, включающей сетевые модули, встроенные в компьютер-клиент и компьютер-сервер и обеспечивающие формирование соединения между компьютером-клиентом и компьютером-сервером; прием и передачу сетевых пакетов в соединении между клиентом и сервером; шифрование сетевых пакетов для установленного соединения: туннелирование сетевых пакетов; причем между клиентом и сервером имеется, по крайней мере, два прокси-сервера, связанных с клиентом и сервером, способ заключается в том, что формируют с помощью сетевых модулей соединение между клиентом и сервером, причем соединение устанавливается, по крайней мере, через два прокси-сервера; создают туннельное сообщение в сетевом модуле клиента; передают туннельное сообщение серверу; подбирают величину задержки T по признаку максимальной скорости передачи туннельного сообщения между клиентом и сервером, выполняя следующие действия: устанавливают интервал изменения времени T и шаг по времени; выполняют измерение скорости передачи туннельного сообщения для каждого значения T в интервале; выбирают значение T, соответствующее максимальной скорости передачи; определяют объем пакета с фиктивными данными Q; отправляют из клиента пакет с фиктивными данными объемом Q через T секунд с момента последней передачи нефиктивных данных через НТТР-туннель, принимают на сервере туннельное сообщение; отключают алгоритм Нэйгла для TCP соединения в сетевых модулях клиента и сервера; отключают алгоритм TCP delayed acknowledgment в сетевых модулях клиента и сервера.
Наверх