Результат интеллектуальной деятельности: ПОЛУЧЕНИЕ ИДЕНТИФИКАТОРА СЕРВЕРА НА ОСНОВЕ МЕСТОПОЛОЖЕНИЯ УСТРОЙСТВА

ОБЛАСТЬ ТЕХНИКИ

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

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

Местоположение устройства является полезной информацией для многих приложений. Устройство может рассчитывать на свою сеть доступа для предоставления информации местоположения. Эта служба может быть обеспечена сервером конфигурации местоположения (LCS). При этом устройство может запросить, чтобы сервер LCS предоставил ссылку на местоположение в форме унифицированного идентификатора ресурса (Uniform Resource Indicator, URI) или набора идентификаторов URI, что позволяет устройству распространять свою информацию местоположения. Сервер LCS может быть доступен посредством протокола, например, HELD (HTTP Enabled Location Discovery, определение местоположения с поддержкой HTTP), который позволяет извлекать информацию местоположения.

Документ Schuizrinne, H., "Location-to-URL Mapping Architecture and Framework", Дек. 2006, описывает архитектуру сервера отображения, с клиентом отображения (средство поиска или распознаватель) и сервером отображения (распознаватель или другие серверы) для выяснения адресов сервера. Сообщение запроса содержит информацию местоположения и идентификатор службы, кодированный как унифицированное имя ресурса (Uniform Resource Name, URN) (см. для сравнения Schulzrinne, H., "A Uniform Resource Name (URN) for Services", Авг. 2006) от клиента LoST (Location-to Server Translation, преобразование «местоположение-сервер») к серверу LoST. Сервер LoST использует свою базу данных для отображения входных значений в один или более унифицированных идентификаторов ресурсов (URI) и возвращает эти идентификаторы URI вместе с дополнительной информацией, такой как, например, указания на границы службы, в ответном сообщении клиенту LoST. Если сервер не может обслужить запрос сам, он может, в свою очередь, запросить другой сервер или возвратить адрес другого сервера LoST.

Если URL LoST содержит имя хоста вместо адреса IP (Internet Protocol, Интернет-протокол), клиентам необходимо использовать указатель владельца имени (например, U-NAPTR, описанный, например, в документе Daigle, L., "Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)," Окт. 2006).

Архитектура для экстренных вызовов делает возможным применение концепции серверов LoST и серверов HELD. Сервер LoST ответственен за преобразование информации местоположения в идентификаторы URI ближайших узлов PSAP (Public Safety Answering Point, узел ответа службы общественной безопасности), а сервер HELD ответственен за предоставление информации местоположения пользователя. Спецификация протокола «местоположение-LoST» описывает протокол на базе языка XML для отображения идентификаторов службы и географической или городской информации местоположения в идентификаторы URI контакта со службой. В частности, это может быть использовано для определения соответствующих по местоположению PSAP для экстренных служб.

Стандартная проблема в задаче определения местоположения в экстренных IP-вызовах касается выяснения того, какой сервер LoST или HELD следует использовать. Это вызвано тем, что службы LoST или HELD имеют границы действия. Например, типичный сервер LoST может определять принадлежность «местоположение-PSAP» к государственной территории, которой принадлежат PSAP. Или, в больших странах, региональный сетевой оператор может предоставлять сервер LoST, который может определять те местоположения, где этот оператор имеет зону покрытия. Подобные ситуации могут быть также применимы к серверам HELD.

Географические ограничения серверов LoST и HELD ведут к другой проблеме: как может устройство, например оконечное устройство, найти идентификатор URI или IP-адрес сервера LoST или HELD, который может предоставить оконечному устройству информацию местоположения?

Текущее решение состоит в использовании протокола динамической конфигурации хоста (Dynamic Host Configuration Protocol, DHCP) для извлечения адреса идентификатора URI или IP-адреса сервера LoST, как определено в Интернет-проекте "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure" (см. для сравнения http://tools.ietf.org/id/draft-ietf-ecrit-dhc-lost-discovery-02.txt). Однако, в то время как это решение технически пригодно для стационарных оконечных устройств, которые обычно получают IP-адрес с DHCP, такое решение непригодно в беспроводных сетях (например, в подсистеме IP-мультимедиа (IP Multimedia Subsystem, IMS)).

Мобильные устройства (например, мобильные терминалы или мобильные узлы) обычно не используют DHCP для получения IP-адреса при использовании сетей доступа к службам общей пакетной радиопередачи (General Packet Radio Services, GPRS) с IP-соединением. Вместо этого такие устройства используют процедуры GPRS (например, активацию контекста протокола пакетных данных (Packet Data Protocol, PDP)) для получения IP-адресов.

С другой стороны, поскольку мобильное устройство может перемещаться, оно может пройти границу действия PSAP. Поэтому это мобильное устройство может нуждаться в определении своего местного сервера LoST/HELD в момент выполнения экстренного вызова, но не ранее.

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

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

Эта цель достигается способом, содержащим:

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

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

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

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

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

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

Соответственно, устройство способно найти адрес своего локального прокси с минимальной конфигурацией. В частности, адрес локальных серверов, зависящий от местоположения (например, локальные серверы LoST и HELD) не нуждается в предварительной конфигурации, а может быть найден. Как альтернатива, устройство может сконструировать или установить адрес (адреса) сервера по умолчанию, на основе уникального идентификатора. Затем устройство может выполнить обычный запрос к серверу или запрос с применением адресов серверов по умолчанию с самообеспечением, для получения адреса локальных серверов, зависящего от местоположения. Базе данных могут быть предоставлены адреса по умолчанию для возврата требуемых адресов серверов. Устройство может затем связаться с локальными серверами, используя возвращенные адреса серверов. Поскольку адрес сервера по умолчанию может доходить до уровня доступа узла, в базе данных может быть представлено любое число локальных серверов, с целью выравнивания нагрузки.

В соответствии с первым аспектом, сеть может быть беспроводной (мобильной) сетью, а устройство может быть беспроводным (мобильным) устройством.

В соответствии со вторым аспектом, уникальный идентификатор может содержать идентификатор соты сотовой системы передачи.

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

В соответствии с четвертым аспектом, уникальный идентификатор может содержать идентификатор линии терминала.

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

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

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

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

Кроме того, информация, зависящая от местоположения, может содержать идентификатор (например, адрес) по меньшей мере одного сервера или, альтернативно, идентификатор по меньшей мере одного сервера из сервера преобразования (translation server) и сервера определения местоположения. В определенном примере сервер преобразования может содержать сервер преобразования «местоположение-сервер» (например, сервер LoST), а сервер определения местоположения может содержать сервер определения местоположения с протоколом гипертекстовой передачи (например, сервер HELD). Адрес сервера может быть также для платформы местоположения (SUPL Location Platform, SLP) защищенного определения местоположения уровня пользователя (Secure User Plane Location, SUPL), улучшенной платформы местоположения SUPL (E-SLP) и центра позиционирования SUPL.

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

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

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

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

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

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

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

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

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

на фиг.5 изображена схематическая структура глобального идентификатора соты;

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

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

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

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

ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

На фиг.1 показано схематическое представление основной архитектуры сети, в которой может быть реализовано настоящее изобретение. Сотовая сеть 300 радиодоступа, например сеть наземного радиодоступа (UMTS Terrestrial Access Network, UTRAN) универсальной мобильной телекоммуникационной системы (Universal Mobile Telecommunication System, UMTS), в соответствии с технологией долгосрочного развития (Long Term Evolution, LTE) или проектом партнерства третьего поколения (3^rd Generation Partnership Project, 3GPP) 8-й редакции, соединена с мобильным терминалом (например, оборудованием 10 пользователя (UE)) посредством устройства 20 доступа, например узла радиосети в виде базовой станции (улучшенный Узел В (eNode В) или Узел В (Node В)). Сеть 300 радиодоступа обеспечивает доступ к определенным серверам IP-сети, например, сети Интернет. Эти определенные серверы содержат сервер 32 DNS, назначенный сервер 34 LoST, назначенный сервер 36 HELD, сервер 35 SLP (платформа защищенного определения местоположения уровня пользователя (SUPL)) и PSAP 38, в который направляются экстренные вызовы.

В соответствии с различными вариантами осуществления, оборудование 10 UE передает запрос 40 серверу доменных имен (DNS) для запроса идентификатора (например, адреса сервера и т.п.) по меньшей мере одного сервера 36 HELD, сервера 34 LoST и сервера 35 SLP.

В сотовых сетях, например, сети 300 радиодоступа, оборудование 10 UE способно определять идентификатор соты, к которой оно подключено. Как правило, идентификатор соты (CI) или глобальный идентификатор соты (Cell Global Identity, CGI) передается широковещательно и используется в радиосигнализации между оборудованием 10 UE и сетью 300 радиодоступа. Поэтому оборудование 10 UE постоянно знает CI или CGI радиосоты. В дополнение, проект партнерства третьего поколения (3GPP) определяет, что мобильное устройство, например оборудование 10 UE, должно включать используемый CI или CGI при сигнализации по протоколу установления сеанса (Session Initiation Protocol, SIP).

В вариантах осуществления, описанных далее, представлена база 32 данных, которая принимает CI или CGI, а также соответствующие идентификаторы соты 3G и LTE как входные данные запросов и возвращает различную информацию, включая, но не ограничиваясь этим, идентификатор URI сервера 34 LoST и сервера 36 HELD, обслуживающих географическую область, в которой физически расположена сота.

В альтернативной реализации (не показано) оборудование 10 UE может также использовать адрес управления доступом к среде (MAC) беспроводной базовой станции (например, точки доступа беспроводной локальной сети (WLAN) или сети WIMAX), к которой таким же образом подключено оборудование 10 UE, для определения соответствующих серверов HELD и LoST, обслуживающих область данной базовой станции.

В примере на фиг.1 база 32 данных реализована как сервер DNS, который может быть также назван службой динамического обнаружения (DDDS), или, подобным образом, как представление нового сервера DNS, назначенного для определения серверов LoST и HELD.

В первом варианте осуществления идентификатор(ы) CI и CGI используются как новые типы входных данных в запросе DNS, a функциональные возможности DNS выполнены с возможностью определять соответствующие серверы HELD и LoST на основе радиосоты, в которой в текущее время находится оборудование 10 UE. В других вариантах осуществления идентификатор(ы) CI и CGI используются как входные данные в запросе DNS, а функциональные возможности DNS выполнены с возможностью определять идентификаторы URI любой телекоммуникационной службы, доступной терминалу в области, соответствующей идентификатору(ам) CI и CGI. Как конкретный пример реализации может быть использован тип запроса к U-NAPTR, представленный как пример в спецификации RFC 4848, раздел 3 инженерной группы по развитию Интернета (IETF). Соответствующие выходные данные запроса DNS используют существующие элементы протокола, описанные в RFC 4848, раздел 4, или основаны на таковых элементах.

Когда оператор доступа соответствующим образом конфигурирует свою систему доменных имен (DNS), любое оконечное устройство (например, оборудование 10 UE) может сделать запрос к DNS для поиска соответствующего сервера LoST, HELD или идентификатора(ов) URI любой соответствующей телекоммуникационной службы.

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

Оборудование 10 UE находит адрес своего сервера 32 DNS согласно стандартной процедуре (например, с предварительной конфигурацией, посредством DHCP или контекстной активации PDP). Оборудование 10 UE также определяет свой CI. Далее оборудование 10 UE должно найти свой назначенный сервер 34 LoST и сервер 36 HELD, но оно не знает адреса серверов, сконфигурированных оператором доступа.

На шаге 101 оборудование 10 UE посылает запрос DNS NAPTR, который содержит текущий идентификатор CI или CGI и запрашиваемый протокол (например, LoST или HELD). В случае идентификатора CGI он форматируется иерархическим образом, при котором различные поля, составляющие CGI, отделяются точкой. Затем на шаге 102 сервер 32 DNS посылает ответ DNS, содержащий адрес локального сервера LoST или HELD (или обоих), который может быть извлечен из конфигурации сервера. Затем оборудование 10 UE может на шаге 103 инициировать стандартный запрос HELD (например, "HTTP GET") для получения детальной информации местоположения, которая на шаге 104 отсылается в ответе HELD (например, "HTTP 200" (OK)). С данной детальной информацией оборудование 10 UE может осуществить запрос LoST (например, "HTTP POST") на шаге 105, для выяснения адреса протокола установления сеанса (SIP) локального PSAP 38, который возвращается на шаге 106 в ответе LoST (например, "HTTP 200" (OK)).

Окончательно, оборудование 10 UE может осуществить экстренный вызов на шаге 107 и адресовать его локальному (и ближайшему) PSAP 38.

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

На фиг.3 показан пример конфигурации записи ресурса NAPTR в DDDS, которая может быть использована в первом варианте осуществления. Во-первых, определяются два новых приложения для U-NAPTR, называемые «идентификатор соты» (CI) и «глобальный идентификатор соты» (CGI), которые затем ассоциируются с протоколами LoST и HELD.

На фиг.5 показано соотношение между CI и CGI. CGI содержит идентификацию локальной области и CI. Идентификация локальной области содержит мобильный код страны (МСС), мобильный код сети (MNC) и код области местоположения (LAC).

На фиг.4 показана схематическая сигнальная диаграмма улучшенной системы, в соответствии со вторым вариантом осуществления, где объединены вместе три узла или сервера, то есть сервер 32 DNS, сервер 34 LoST и сервер 36 HELD. Во втором варианте осуществления оборудование 10 UE осуществляет запрос DNS NAPTR на шаге 201 и принимает ответ на шаге 202. Ответ содержит локальный адрес PSAP (или любой другой локальный адрес запрашиваемой службы). Затем на шаге 203 оборудование 10 UE может осуществить экстренный вызов или обратиться к любой другой локализованной службе, например, с помощью генерирования сообщения SIP INVITE.

На фиг.6 показана схематическая сигнальная диаграмма в соответствии с третьим вариантом осуществления настоящего изобретения, который не требует никаких изменений в DNS. Предлагаемая процедура получения обеспечивает самообеспечение оборудования 10 UE адресами серверов LoST и/или HELD (например, в виде идентификаторов URI) на основе CGI, или для защищенного определения местоположения уровня пользователя (SUPL) при самообеспечении адресом E-SLP (Enhanced SUPL Location Platform, улучшенной платформы местоположения SUPL). Оборудование 10 UE может затем использовать предоставленные им самим URI в запросе DNS, для получения IP-адреса серверов LoST, HELD и E-SLP, соответственно.

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

Подобный процесс конструирования может быть применен при конструировании адреса SLP или E-SLP, когда сессия инициации SUPL терминала(ов) с возможностью SUPL (SUPL Enabled Terminal, SET) инициируется по направлению к серверу E-SLP. SUPL использует носители данных уровня пользователя для передачи информации местоположения (например, для поддержки системы глобального позиционирования (Global Positioning System, GPS)) и для поддержки технологически-зависимых протоколов позиционирования между терминалом SET и сетью. SUPL обеспечивает эффективный способ передачи информации местоположения, требующейся для вычисления местоположения терминала SET. Дальнейшие подробности, касающиеся SUPL, могут быть получены из спецификаций открытого мобильного альянса (Open Mobile Alliance, ОМА).

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

На фиг.7 показан пример блок-схемы процедуры конфигурации, в соответствии со вторым и третьим вариантом осуществления. Эта процедура или механизм могут быть использованы, например, для конфигурации адреса по умолчанию сервера LoST/HELD/E-SLP.

На шаге 301 извлекаются первые 5 или 6 цифр CGI (в зависимости от того, используется двух- или трехзначный MNC). Затем, на шаге 302, эти цифры разделяются на МСС и MNC. Если MNC является двухзначным, то в начале может быть добавлен нуль.

На шаге 303 извлеченные МСС, MNC (полученные на шаге 301 и 302) и LAI используются для создания имени домена по умолчанию, согласно следующему выражению (нижеприведенное выражение основано на Приложении Е спецификации TS 23.003 стандарта 3GPP):

"mnc<MNC>. mcc<MCC>. lai<LAI>.pub.3gppnetwork.org".

Окончательно, на шаге 304, в начале сконфигурированного имени домена по умолчанию добавляется метка "held.", "lost." или "e-slp.".

В качестве примера, если используемый CGI равен "234150999999999", а МСС=234, MNC=15 и LAI (LAC+CI)=0999999999, следующие сконфигурированные имена доменов по умолчанию могут быть получены для различных типов серверов:

Сервер LoST: "lost.mnc015.mcc234.lai0999999999. pub.3gppnetwork.org",

Сервер HELD: "held.mnc015.mcc234.lai0999999999.pub.3gppnetwork.org",

Сервер E-SLP: "e-slp.mnc015.mcc234.lai0999999999.pub.3gppnetwork.org".

Так, если оборудование 10 UE не получило идентификатор URI сервера HELD/LoST/E-SLP, то оборудование 10 UE конструирует идентификаторы URI в соответствии с вышеприведенной схемой. Затем оборудование 10 UE осуществляет стандартный запрос DNS, используя идентификаторы URI, сконструированные по умолчанию, для получения IP-адреса серверов HELD/LoST/E-SLP. Сервер 32 DNS может быть снабжен адресами по умолчанию для возврата IP-адресов при обычном запросе DNS. Затем оборудование 10 UE может осуществить соединение с серверами HELD/LoST/E-SLP, используя полученные IP-адреса, после чего процесс вызова продолжается как обычно. Поскольку полностью определенное имя домена по умолчанию (Fully Qualified Domain Name, FQDN) доходит до уровня соты, в сервере DNS может быть представлено любое число серверов HELD/LoST/E-SLP с целью выравнивания нагрузки.

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

Оборудование 10 UE содержит радиочастотный (RF) блок 21 для передачи и приема радиосигналов к/от сети 300 радиодоступа. Если экстренный триггер (Emergency Trigger, ET) активирован (например, нажатием кнопки экстренного вызова и т.п.), функция генерации адреса (или блок 23) определяет уникальный идентификатор, как описано в вышеуказанных вариантах осуществления, и отправляет этот уникальный идентификатор функции генерации сообщения (или блоку 22), которая генерирует запрос DNS с определенным уникальным идентификатором, передаваемым серверу 32 DNS.

Сервер 32 DNS содержит средства или блок управления доступом (Access Control, AC) 14, который обеспечивает доступ к базе данных. База данных содержит секцию 12-1 указателей и ассоциированную секцию 12-2 адресов. В секции 12-1 указателей хранятся идентификаторы ID1-Idn, которые могут соответствовать вышеуказанным идентификаторам CI, адресам MAC, адресам по умолчанию, как примерам уникальных идентификаторов устройства 20 доступа. Секция 12-2 адресов хранит адреса серверов (например, адреса серверов LoST, HELD или E-SLP), ассоциированных с идентификаторами в секции 12-1 указателей.

Когда запрос DNS с уникальным идентификатором принимается посредством сети 300 радиодоступа от оборудования 10 UE, блок 14 управления доступа обращается к секции 12-1 указателей базы данных (используя уникальный идентификатор как указатель) и принимает из секции 12-2 адресов ассоциированный адрес (адреса) сервера. Извлеченный адрес (адреса) затем пересылается в оборудование 10 UE в соответствующем ответе DNS и может быть использован для доступа к PSAP 38 с целью инициации обработки экстренного вызова.

На фиг.9 показана блок-схема альтернативной программной реализации, в соответствии с четвертым вариантом осуществления. Требуемые функциональные средства могут быть реализованы в любом мобильном устройстве 400 с блоком обработки 410, который может быть любым процессором или вычислительным устройством с блоком управления, выполняющим управление на основе программных процедур управляющей программы, хранящейся в памяти 412. Управляющая программа может также храниться отдельно, на читаемом компьютером носителе. Инструкции программного кода извлекаются из памяти 412 и загружаются в блок управления блока 410 обработки, для выполнения программных шагов вышеуказанных функциональных средств, показанных на фиг.7 и фиг.8, которые могут быть реализованы как вышеуказанные программные процедуры. Программные шаги могут выполняться на базе входных данных DI и могут генерировать выходные данные DO. Входные данные DI могут соответствовать адресу CGI, MAC или другому уникальному идентификатору рассматриваемого устройства радиодоступа, а выходные данные DO могут соответствовать запросу сервера, пересылаемому серверу 32 DNS или любому другому прокси-серверу, используемому для извлечения требуемого идентификатора.

В результате вышеуказанные варианты осуществления могут быть реализованы как компьютерный программный продукт, содержащий кодовое средство для генерации каждого индивидуального этапа процедуры сигнализации и выполняемый на компьютерном устройстве или процессоре данных принимающего устройства (например, Узла В 20) или передающего устройства (например, оборудования 10 UE), соответственно.

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

Ясно, что данное изобретение может быть легко расширено на любую службу и сетевое окружение (стационарное и беспроводное), где для доступа к серверу, предлагающему запрашиваемую службу, требуется информация, зависящая от местоположения. Сервер может обеспечивать любые телекоммуникационные службы и не ограничен типами серверов, упомянутыми в предпочтительных вариантах осуществления. Более конкретно, настоящее изобретение не ограничено вышеуказанным сетевым окружением данных вариантов осуществления. Данное изобретение может быть реализовано в любом сетевом окружении (например, изобретение может быть использовано в проводных сетях, где стационарное устройство, например компьютер или стационарный телефон, подключены к сети). Более того, любой тип уникального идентификатора любого типа узла может быть использован для запроса к серверу. В качестве примера может быть использован идентификатор линии (ID линии), в дополнение или как альтернатива к вышеуказанным адресам CI и MAC. Более того, идентификатор линии может быть сохранен в узле (который охватывает сетевые устройства и оконечные устройства), к которому подключено устройство, являясь, таким образом, уникальным идентификатором для каждой линии и подключенного устройства. Поэтому термин «уникальный идентификатор» предназначен для обозначения любого типа идентификатора линии, включая конкретный идентификатор терминала (устройства). Более того, возможно существование более чем одного уникального идентификатора узла, при этом узел может иметь несколько устройств, подключенных посредством нескольких линий, где каждая линия имеет уникальный идентификатор линии. Поскольку идентификатор линии в этом случае уникален для каждой линии, он также уникален для каждого подключенного устройства. Уникальный идентификатор(ы) линии может сохраняться и присваиваться в узле, к которому подключено устройство.

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