СПОСОБ И УСТРОЙСТВО ДЛЯ ОПРЕДЕЛЕНИЯ СЕРВЕРА, ОТВЕЧАЮЩЕГО НА ЗАПРОС ОБСЛУЖИВАНИЯ ИЗ МОБИЛЬНОГО УСТРОЙСТВА, И УСТРОЙСТВО, ВКЛЮЧАЮЩЕЕ МОБИЛЬНОЕ УСТРОЙСТВО ИЛИ СЕРВЕР DNS Российский патент 2013 года по МПК H04L29/00 

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

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

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

Когда мобильное устройство пользователя выполняет подключение к какой-либо службе, оно в первую очередь должно определить адрес узла, предоставляющего данную службу. Для служб, доступ к которым предоставляется через Интернет, такое определение осуществляется путем использования 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), мобильный терминал и т.п.

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

.

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.