ПОДДЕРЖКА ЭКСТРЕННЫХ ВЫЗОВОВ В РЕЖИМЕ КОММУТАЦИИ КАНАЛОВ Российский патент 2010 года по МПК H04W64/00 

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

Настоящее изобретение, в общем, относится к связи, а более конкретно к методикам поддержки экстренных вызовов.

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

Сети беспроводной связи широко развертываются, чтобы предоставлять различные услуги связи, например речь, видео, передачи пакетных данных, обмен сообщениями, широковещательную передачу и т.п. Эти беспроводные сети могут быть сетями с множественным доступом, допускающими поддержку связи с несколькими пользователями посредством совместного использования доступных сетевых ресурсов. Примеры таких сетей с множественным доступом включают в себя сети с множественным доступом с кодовым разделением каналов (CDMA), сети с множественным доступом с временным разделением каналов (TDMA), сети с множественным доступом с частотным разделением каналов (FDMA) и сети с ортогональным FDMA (OFDMA).

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

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

Следовательно, в данной области техники имеется потребность в том, чтобы поддерживать экстренные вызовы.

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

В данном документе описаны методики для поддержки экстренных вызовов в режиме коммутации каналов. Методики могут быть использованы для различных сетей 3GPP и 3GPP2, различных архитектур определения местоположения и абонентских устройств (UE) с подпиской на услуги или без нее.

В варианте осуществления UE устанавливает вызов в режиме коммутации каналов с беспроводной сетью для экстренных служб. UE взаимодействует с сервером определения местоположения, указанным беспроводной сетью. UE выполняет определение местоположения в пользовательской плоскости с помощью сервера определения местоположения в течение вызова в режиме коммутации каналов для получения оценки местоположения (позиции) UE. Определение местоположения в пользовательской плоскости означает процесс для определения местоположения целевого UE, при котором передача сигналов между UE и сервером определения местоположения осуществляется с помощью возможностей передачи данных, предоставляемых посредством обслуживающей беспроводной сети и/или посредством других сетей. Определение местоположения в пользовательской плоскости может быть основано на решении/архитектуре пользовательской плоскости, такой как OMA надежное определение местоположения в пользовательской плоскости (SUPL) или 3GPP2 X.S0024. Передача сигналов для определения местоположения в пользовательской плоскости может быть осуществлена посредством связи в режиме с коммутацией пакетов. UE устанавливает экстренный вызов в режиме коммутации каналов с PSAP, которая может быть выбрана на основе оценки местоположения UE. UE может осуществлять позиционирование с помощью сервера определения местоположения для получения обновленной оценки местоположения (позиции) UE, например, каждый раз, когда запрошено посредством PSAP.

Далее подробно описаны различные аспекты и варианты осуществления изобретения.

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

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

Фиг.2 иллюстрирует архитектуру сетей 3GPP и 3GPP2.

Фиг.3 иллюстрирует сетевую архитектуру для определения местоположения SUPL.

Фиг.4, 5 и 6 иллюстрируют несколько потоков сообщений для экстренного вызова в режиме коммутации каналов с помощью определения местоположения SUPL.

Фиг.7 иллюстрирует сетевую архитектуру для определения местоположения X.S0024.

Фиг.8 иллюстрирует поток сообщений для экстренного вызова в режиме коммутации каналов с помощью определения местоположения X.S0024.

Фиг.9 иллюстрирует протоколы связи между различными объектами.

Фиг.10 иллюстрирует блок-схему различных объектов на фиг.2.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

В данном документе описаны методики поддержки экстренных вызовов в режиме коммутации каналов. Вызов в режиме коммутации каналов - это вызов, при котором выделенные ресурсы (к примеру, радиоканалы трафика) выделяются для вызова. Вызов в режиме коммутации каналов также упоминается как вызов с коммутацией каналов и отличается от вызова с коммутацией пакетов, при котором данные отправляются в пакетах с помощью совместно используемых ресурсов. Экстренный вызов в режиме коммутации каналов - это вызов в режиме коммутации каналов экстренных служб. Экстренный вызов в режиме коммутации каналов может быть идентифицирован как таковой и может быть отличен от обычного вызова в режиме коммутации каналов несколькими способами, как описано ниже. Экстренный вызов в режиме коммутации каналов может быть ассоциативно связан с различными характеристиками, которые отличаются от обычного вызова в режиме коммутации каналов, такого как, к примеру, получение соответствующей оценки местоположения пользователя, маршрутизация экстренного вызова в режиме коммутации каналов на соответствующую PSAP, поддержка пользователя даже без подписки на услуги и т.д. В данном описании термин "определение местоположения" в типичном варианте относится к процессу для получения и предоставления географического местоположения целевого UE. Термин "позиционирование" в типичном варианте означает процесс для измерения/вычисления оценки географического положения (позиции) целевого UE. Определение местоположения может влечь или не влечь за собой позиционирование, в зависимости от того, доступна ли уже соответствующая оценка местоположения. Оценка позиции также упоминается как оценка местоположения, фиксация позиции и т.п.

Фиг.1 иллюстрирует развертывание 100, которое поддерживает экстренные вызовы в режиме коммутации каналов. Абонентское устройство (UE) 110 обменивается данными с сетью радиодоступа (RAN) 120 для того, чтобы получать услуги связи. UE 110 может быть стационарным или мобильным и также может называться мобильной станцией (MS), терминалом, абонентским модулем, станцией или каким-либо другим термином. UE 110 может быть сотовым телефоном, персональным цифровым устройством (PDA), беспроводным устройством, дорожным компьютером, телеметрическим устройством, устройством слежения и т.п. UE 110 может обмениваться данными с одной или более базовых станций в RAN 120. UE 110 также может принимать сигналы от одного или более спутников 190, которые могут быть частью глобальной системы позиционирования (GPS) США, европейской системы Galileo, российской системы GLONASS или какой-либо другой спутниковой системы позиционирования (SPS). UE 110 может измерять сигналы от базовых станций в RAN 120 и/или сигналы от спутников 190. UE 110 может получать измерения псевдодальности для спутников и/или измерения синхронизации для базовых станций. Измерения псевдодальности и/или измерения временной синхронизации могут быть использованы для того, чтобы извлекать оценку местоположения UE 110 с помощью одного или более способов позиционирования, например с помощью GPS (A-GPS), автономного GPS, усовершенствованной трилатерации прямой линии связи (A-FLT), усовершенствованной отслеживаемой разности времен (E-OTD), отслеживаемой разности времен поступления (OTDOA), усовершенствованного идентификатора соты и т.п.

RAN 120 предоставляет радиосвязь для UE, размещенных в зоне покрытия RAN. RAN 120 ассоциативно связана с гостевой сетью 130, которая является сетью, в данный момент обслуживающей UE 110. Гостевая сеть также может также называться гостевой наземной сетью мобильной связи общего пользования (V-PLMN). Домашняя сеть 150, которая также может быть названа PLMN (H-PLMN), - это сеть, на услуги которой UE 110 имеет подписку. Гостевая сеть 130 и домашняя сеть 150 могут быть одной и той же или различными сетями, и, если они являются различными сетями, могут иметь или не иметь соглашение о роуминге.

Сеть 160 может включать в себя коммутируемую телефонную сеть общего пользования (PSTN) и/или другие сети передачи речи и данных. PSTN поддерживает связь для традиционных простых старых телефонных служб (POTS). PSAP 180 - это объект, ответственный за ответы на экстренные вызовы (к примеру, в полицию, пожарную и медицинскую службу), и он также может упоминаться как центр экстренных вызовов (EC). Экстренный вызов может быть инициирован, когда пользователь набирает фиксированный хорошо известный номер, такой как 911 в Северной Америке или 112 в Европе. PSAP 180 в типичном варианте управляется и принадлежит государственному органу, к примеру округу или городу. PSAP 180 поддерживает связь с PSTN 160.

Методики, описанные в данном документе, могут быть использованы для экстренных вызовов в режиме коммутации каналов различных сетей беспроводной связи, таких как сети CDMA, TDMA, FDMA и OFDMA, беспроводные локальные вычислительные сети (WLAN) и/или другие сети. CDMA-сеть может реализовывать одну или более технологий радиосвязи, например широкополосный CDMA (W-CDMA), cdma2000 и т.д. Cdma2000 охватывает стандарты IS-2000, IS-856 и IS-95. TDMA-сеть может реализовывать одну или более технологий радиосвязи, например глобальная система мобильной связи (GSM), цифровая усовершенствованная система мобильных телефонов (D-AMPS) и т.п. D-AMPS охватывает IS-248 и IS-54. W-CDMA и GSM описываются в документах организации, называемой Партнерским проектом третьего поколения (3GPP). Cdma2000 описывается в документах организации, называемой Партнерским проектом третьего поколения 2 (3GPP2). Документы 3GPP и 3GPP2 являются общедоступными. Эти различные технологии и стандарты радиосвязи известны в данной области техники. Обобщенная сеть доступа (GAN) 3GPP может использовать WLAN для того, чтобы предоставлять доступ в режиме коммутации каналов, как описано в 3GPP TS 43.318.

Фиг.2 иллюстрирует архитектуру сетей 3GPP и 3GPP2. UE 110 может получать радиодоступ посредством 3GPP RAN 120a, которой может быть сеть радиодоступа GSM EDGE (GERAN), универсальная наземная сеть радиодоступа (UTRAN), развитая UTRAN (E-UTRAN), WLAN или какая-либо другая сеть доступа. 3GPP RAN 120a включает в себя базовые станции 220a, контроллеры радиосети/контроллеры базовой станции (RNC/BSC) 222a и другие объекты, не показанные на фиг.2. Базовая станция также может обозначаться узлом B, усовершенствованным узлом B (e-узлом B), базовой приемо-передающей станцией (BTS), точкой доступа (AP) или каким-либо другим термином.

3GPP V-PLMN 130a - это один вариант осуществления гостевой сети 130 на фиг.1, и она может включать в себя центр коммутации мобильной связи (MSC) 230a, шлюзовой центр определения местоположения мобильной связи (GMLC) 232a, платформы определения местоположения SUPL для экстренных служб (E-SLP) 234a и гостевой SLP (V-SLP) 236a. GMLC 232a, E-SLP 234a и V-SLP 236a предоставляют услуги определения местоположения для UE, обменивающихся данными с V-PLMN 130a. GMLC 232a поддерживает некоторые функции традиционного GMLC (к примеру, заданные в 3GPP TS 23.271 и J-STD-036) и некоторые функции, связанные с использованием SUPL для определения местоположения и маршрутизации экстренных вызовов. E-SLP 234a и V-SLP 236a поддерживают SUPL из Открытого альянса мобильной связи (OMA). E-SLP 234a заменяет домашнюю SLP (H-SLP) в случае определения местоположения экстренных вызовов и может быть комбинирована с GMLC 232a. V-SLP 236a может находиться в рамках или вне V-PLMN 130a и может быть географически ближе к UE 110.

UE 110 также может получать радиодоступ посредством 3GPP2 RAN 120b, которой может быть сеть CDMA2000 1X или какая-либо другая сеть доступа. 3GPP2 RAN 120b включает в себя базовые станции 220b, BSC 222b и другие объекты, не показанные на фиг.2.

3GPP2 V-PLMN 130b - это другой вариант осуществления гостевой сети 130 на фиг.1, и она может включать в себя MSC 230b, мобильный центр позиционирования (MPC) 232b, E-SLP 234b и V-SLP 236b. MPC 232b, E-SLP 234b и V-SLP 236b предоставляют услуги определения местоположения UE, обменивающихся данными с V-PLMN 130b. MPC 232b поддерживает некоторые функции традиционного MPC (к примеру, заданные в 3GPP2 X.S0002, TIA-881 и J-STD-036) и некоторые функции, связанные с применением SUPL для определения местоположения и маршрутизации экстренных вызовов. E-SLP 234b и V-SLP 236b поддерживают SUPL от OMA. E-SLP 234b может быть комбинирована с MPC 232b. Альтернативно или помимо этого V-PLMN 130b может включать в себя сервер позиционирования экстренных служб (E-PS) 238 и гостевой PS (V-PS) 240. E-PS 238 и V-PS 240 являются серверами определения местоположения, которые поддерживают определение местоположения X.S0024 для сетей cdma2000 и аналогичны E-SLP 234b и V-SLP 236b для SUPL. V-SLP 236b и V-PS 240 могут быть размещены в пределах или вне V-PLMN 130b и могут быть географически ближе к UE 110. V-PLMN 130b также может включать в себя объект определения местоположения (PDE) и/или другие объекты.

3GPP H-PLMN 150a - это один вариант осуществления домашней сети 150 на фиг.1, и она может включать в себя H-SLP 252a и/или другие сетевые объекты. 3GPP2 H-PLMN 150b - это другой вариант осуществления домашней сети 150 на фиг.1, и она может включать в себя H-SLP 252b и H-PS 254 и/или другие сетевые объекты. Объекты в SUPL описаны в OMA-AD-SUPL-V2_0-20060823-D, озаглавленном "Secure User Plane Location Architecture", черновая версия 2.0, 23 августа 2006 года, и в OMA-TS-ULP-V2_0-20060907-D, озаглавленном "User Plane Location Protocol", черновая версия 22.0, 7 сентября 2006 года. Объекты в определении местоположения X.S0024 описаны в 3GPP2 X.S0024, озаглавленном "IP-Based Location Services", версия 1.0, октябрь 2005 года. Эти документы являются общедоступными.

Для простоты фиг.2 показывает только некоторые из объектов в 3GPP и 3GPP2, которые упоминаются в нижеприведенном описании. Сети 3GPP и 3GPP2 могут включать в себя другие объекты, заданные посредством 3GPP и 3GPP2 соответственно.

Беспроводная сеть может поддерживать услуги определения местоположения (LCS) с помощью решения плоскости управления (CP) и/или решения пользовательской плоскости (UP). Плоскость управления (которая также называется плоскостью передачи сигналов) - это механизм переноса сигналов для приложений более высокого уровня, и она в типичном варианте реализуется с помощью конкретных для сети протоколов, интерфейсов и сигнальных сообщений. Пользовательская плоскость - это механизм переноса сигналов для приложений более высокого уровня, и она использует однонаправленный канал пользовательской плоскости, который в типичном варианте реализуется с помощью таких протоколов, как протокол передачи дейтаграмм пользователя (UDP), протокол управления передачей (TCP) и Интернет-протокол (IP). Сообщения, поддерживающие услуги определения местоположения и позиционирования, переносятся как часть сигналов в архитектуре плоскости управления и как часть данных (с точки зрения сети) в архитектуре пользовательской плоскости. Тем не менее, содержимое сообщений может быть одинаковым или аналогичным в обеих архитектурах. Плоскость управления 3GPP описана в 3GPP TS 23.271, TS 43.059 и TS 25.305. Плоскость управления 3GPP2 описана в IS-881 и 3GPP2 X.S0002. SUPL и пред-SUPL описаны в документах от OMA.

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

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

Методики поддерживают зарегистрированные UE, а также незарегистрированные UE. Зарегистрированный UE - это UE, который зарегистрирован в домашней сети и может быть аутентифицирован посредством домашней сети. Незарегистрированный UE - это UE, который не зарегистрирован ни в одной сети и не аутентифицирован. 3GPP UE может быть оснащен универсальной интегрированной схемной платой (UICC) или модулем идентификации абонента (SIM). 3GPP2 UE может быть оснащен модулем идентификации пользователя (UIM). UICC, SM или UIM в типичном варианте являются конкретными для одного абонента и могут хранить персональную информацию, информацию подписки и/или другую информацию. UE без UICC - это UE с отсутствующими UICC или SIM. UE без UIM - это UE с отсутствующим UIM. UE без UICC/UIM не зарегистрирован ни в одной сети и имеет подписки, домашней сети и учетных данных аутентификации (к примеру, секретного ключа), чтобы проверять заявляемые идентификационные данные, что делает услуги определения местоположения в большей степени подверженными риску.

Фиг.3 иллюстрирует вариант осуществления сетевой архитектуры 300 для экстренного вызова в режиме коммутации каналов с определением местоположения SUPL. Сетевая архитектура 300 применима для сетей 3GPP и 3GPP2. Для простоты, фиг.3 показывает только объекты и интерфейсы, важные для того, чтобы поддерживать экстренный вызов в режиме коммутации каналов с помощью SUPL. В общем, сетевая архитектура 300 может включать в себя другие объекты, чтобы поддерживать вызов и/или определение местоположения в режиме коммутации каналов.

UE 110 упоминается как терминал с поддержкой SUPL (SET) в SUPL. RAN 120 может быть 3GPP RAN 120a, 3GPP2 RAN 120b или какой-либо другой сетью доступа. E-SLP 234 может включать в себя центр определения местоположения SUPL (E-SLC) 312, который выполняет различные функции для услуг определения местоположения, и центр позиционирования SUPL (E-SPC) 314, который поддерживает позиционирование для UE. V-SLP 236 аналогично может включать в себя V-SLC 322 и V-SPC 324. E-SLP 234 ассоциативно связан с MPC/GMLC 232 и заменяет H-SLP 252 в H-PLMN 150 в случае определения местоположения экстренных вызовов. V-SLP 236 может быть ближе и/или в большей степени иметь возможность находить UE 110. В большинстве случае достаточно только E-SLP 234, и V-SLP 236 не требуется.

SUPL поддерживает два режима связи между SET и SLP для позиционирования с помощью SPC. В прокси-режиме SPC не имеет прямой связи с SET, и SLP выступает в качестве прокси между SET и SPC. В режиме без прокси SPC имеет прямую связь с SET.

PSTN 160 может включать в себя выборочный маршрутизатор (S/R) 260 и/или другие тандемы, используемые для того, чтобы устанавливать экстренный вызов в режиме коммутации каналов от MSC 230 в PSAP 180. S/R 260 может принадлежать PSAP 180 или может быть совместно использованным и подключенным к набору PSAP. UE 110 может обмениваться данными с PSAP 180 посредством MSC 230 и S/R 260.

Фиг.3 также показывает интерфейсы между различными объектами. Связанные с вызовами интерфейсы между UE 110 и RAN 120 и между RAN 120 и MSC 230 являются конкретными для сети. Связанным с вызовами интерфейсом между MSC 230, S/R 260 и PSAP 180 может быть многочастотный/ISDN абонентский узел/ISDN (MF/ISUP/ISDN).

Связанным с определением местоположения интерфейсом между UE 110 и E-SLP 234 и V-SLP 236 может быть протокол определения местоположения в пользовательской плоскости (ULP) SUPL. Интерфейсом между E-SLP 234 и V-SLP 236 может быть протокол определения местоположения при роуминге (RLP). Интерфейсом между MSC 230 и GMLC/MPC 232 может быть узел мобильных приложений (MAP). Интерфейс между MPC/GMLC 232 и E-SLP 234 напоминает и Le/L1-интерфейс между SUPL-агентом, и H-SLP и Lr/LCS-z-интерфейс между парой SLP в SUPL 1.0. Таким образом, интерфейс между MPC/GMLC 232 и E-SLP 234 может поддерживаться с помощью протокола определения местоположения мобильного терминала (MLP), RLP, усовершенствованной версии MLP или RLP либо какого-либо другого интерфейса. Для RLP поддержка GMLC уже задана в отношении инициирования RLP-транзакций. Для MLP GMLC обычно выступает в качестве получателя транзакции. Интерфейсом между E-SLP 234 и PSAP 180 может быть E2-интерфейс, заданный в J-STD-036 редакция B, MLP, HTTP-интерфейс или какой-либо другой интерфейс.

Несколько примерных потоков сообщений для экстренного вызова в режиме коммутации каналов в 3GPP и 3GPP2 с определением местоположения SUPL описаны ниже. Для простоты объекты, которые менее релевантны (к примеру, RAN 120 и S/R 260), опущены из этих потоков сообщений, но включены в описания. Эти потоки сообщений предполагают, что UE 110 имеет UICC или UIM и, что есть соглашение по роумингу между V-PLMN 130 и H-PLMN 150. Потоки сообщений также предполагают, что UE 110 поддерживают параллельную связь и в режиме коммутации каналов (для экстренного вызова), и в режиме коммутации пакетов (к примеру, для определения местоположения). Эта возможность в настоящее время разрешена для зарегистрированных пользователей посредством 3GPP в UMTS и GSM/GPRS и посредством 3GPP2 в cdma2000.

1. Экстренный вызов в режиме коммутации каналов в 3GPP с определением местоположения SUPL

Фиг.4 иллюстрирует вариант осуществления потока 400 сообщений для экстренного вызова в режиме коммутации каналов в 3GPP, использующем SUPL с определением местоположения, инициированным до установления вызова. На этапе 1 UE 110 отправляет запрос на вызов экстренных служб (к примеру, E911 в Северной Америке или E112 в Европе) в MSC 230a в 3GPP V-PLMN 130a. Этот запрос упоминается как инициирование вызова экстренных служб (ESC).

На этапе 2 MSC 230a может допустить или определить то, что UE 110 поддерживает позиционирование SUPL, к примеру на основе информации подписки UE или информации характеристик UE, принимаемой от UE, или в качестве политики V-PLMN 130a. MSC 230a затем отправляет сообщение отчета определения местоположения абонента (SLR) MAP в GMLC 232a, которая находится в сети, которая имеет ассоциативную связь (к примеру, содержит или подключена) с E-SLP 234a. MAP SLR используется для того, чтобы создавать запись экстренного вызова в GMLC 232a (и ассоциативную связь с MSC 230a), а также получать информацию маршрутизации PSAP от GMLC. MAP SLR может содержать идентификационные данные UE, идентификационные данные обслуживающей соты (ED) и/или другую информацию. Идентификационными данными UE может быть международный идентификатор абонента мобильной связи (IMSI), ISDN-номер абонента мобильной связи (MSISDN), международный идентификатор мобильного устройства (IMEI) и/или какие-либо другие идентификационные данные. Другая информация может включать в себя измерения от UE или сети, которые могут быть использованы для того, чтобы вычислять оценку местоположения для UE. Для вызовов в Северной Америке MSC 230a может назначать ключ маршрутизации экстренных служб (ESRK) или код маршрутизации экстренных служб (ESRD) и в таком случае должен включать его в MAP SLR. ESRD - это ненабираемый абонентский номер, который идентифицирует PSAP. ESRK - это ненабираемый абонентский номер, который может быть использован для того, чтобы выполнять маршрутизацию к PSAP. Каждая PSAP может быть ассоциативно связана с одним ESRD и пулом нескольких ESRK. Для экстренного вызова посредством UE в эту PSAP один ESRK из пула может быть назначен для UE на время экстренного вызова и может быть использован для того, чтобы идентифицировать PSAP, GMLC и /или MSC и UE.

На этапе 3 GMLC 232a создает запись для вызова. GMLC 232a может определять оценку промежуточной позиции UE 110 на основе информации определения местоположения, принятой на этапе 2. Информация определения местоположения может содержать идентификатор соты, измерения, оценку позиции и т.д. Оценка промежуточной позиции в типичном варианте означает примерную позицию, используемую для маршрутизации вызова. GMLC 232a также может инициировать этапы 8-13 заранее, чтобы получить оценку промежуточной позиции для UE 110. GMLC 232a может выбирать PSAP на основе оценки промежуточной позиции (если получена) или идентификатора обслуживающей соты, принятого на этапе 2. Это обеспечивает то, что выбранная PSAP охватывает экстренные вызовы из географической области, где находится UE 110. Для вызовов в Северной Америке GMLC 232a может назначать ESRD или ESRK, чтобы указать выбранную PSAP. В последующем описании PSAP 180 - это выбранная PSAP. GMLC 232a также может инициировать этапы 8-13 заранее, чтобы получить точную оценку начальной позиции, которая может быть использована в дальнейшем для запроса на определение местоположения от PSAP. Оценка начальной позиции в типичном варианте относится к первой точной оценке позиции. На этапе 4 GMLC 232a возвращает подтверждение приема MAP SLR в MSC 230a. Для вызовов в Северной Америке это подтверждение приема может включать в себя любой ESRD или ESRK, назначенный посредством GMLC 232a на этапе 3.

На этапе 5 MSC 230a отправляет экстренный вызов в режиме коммутации каналов в PSAP 180. Для вызовов в Северной Америке, если ESRK или ESRD возвращен на этапе 4, то PSAP 180 выбрана посредством GMLC 232a на этапе 3. В противном случае MSC 230a может определять PSAP, к примеру на основе текущей или начальной обслуживающей соты для UE 110. Для вызовов в Северной Америке сообщение или индикация установления вызова, отправленная посредством MSC 230a в PSAP 180, включает в себя любой из ESRD или ESRK, возвращенный посредством GMLC 232a на этапе 4 или назначенный посредством MSC 230a на этапе 2 или 5. Сообщение установления вызова может включать в себя номер обратного вызова для UE 110 (к примеру, MSISDN).

На этапе 6 вызов устанавливается между UE 110 и PSAP 180 посредством MSC 230a. На этапе 7 PSAP 180 отправляет запрос позиции от экстренных служб в GMLC 232a, чтобы запросить точную оценку начальной позиции UE 110. Для вызовов в Северной Америке PSAP 180 может идентифицировать GMLC 232a с помощью ESRK или ESRD, принятого на этапе 5. В этом случае запрос позиции от экстренных служб включает в себя ESRK и/или ESRD и номер обратного вызова. PSAP 180 не обязательно должна знать о том, что SUPL используется для определения местоположения.

На этапе 8 GMLC 232a идентифицирует запись вызова, созданную на этапе 3, с помощью (a) ESRK или номера обратного вызова, принятого на этапе 7 для вызовов в Северной Америке, или (b) другую информацию вызывающего абонента (к примеру, MSISDN или IMSI) для вызовов в других регионах. Если GMLC 232a получил точную оценку позиции на этапе 3 (к примеру, посредством выполнения этапов 8-13 заранее), то GMLC 232a может возвращать эту оценку позиции сразу в PSAP 180 на этапе 14 и пропустить этапы 8-13. В противном случае GMLC 232a отправляет в E-SLP 234a запрос позиции от экстренных служб, который может содержать идентификационные данные UE (к примеру, MSISDN и/или IMSI), идентификатор соты (если известен), требуемое качество позиционирования (QoP) и/или другую информацию. QoP переносит требования для оценки позиции, к примеру точность и срок оценки позиции. QoP также упоминается как QoS.

На этапе 9 E-SLP 234a определяет то, должно ли позиционирование поддерживаться посредством V-SLP, более близкой и/или имеющей лучшую возможность поддерживать позиционирование UE 110, к примеру, на основе идентификатора соты (если имеется), принятого на этапе 8. Если так, то E-SLP 234a обменивается сигналами с V-SLP (не показано на фиг.4). В противном случае E-SLP 234a побуждает инициированную сетью процедуру определения местоположения SUPL, причем E-SLP заменяет H-SLP. E-SLP 234a сначала отправляет SUPL INIT в UE 110, чтобы начать процедуру определения местоположения SUPL. SUPL INIT может быть отправлен, к примеру, с помощью проталкивания протокола беспроводных приложений (WAP), триггера службы коротких сообщений (SMS) или UDP/IP, если E-SLP 234a знает либо может получить IP-адрес UE 110. SUPL INIT может включать в себя IP-адрес E-SLP 234a, к примеру, если UE 110 не находится в домашней сети, если E-SLP 234a не является H-SLP для UE или если E-SLP 234a выбирает не работать в режиме H-SLP (к примеру, для того чтобы упростить реализацию). SUPL INIT также может включать в себя индикатор экстренных вызовов, к примеру в параметре оповещения SUPL INIT. Если используется режим без прокси, то SUPL INIT также может содержать IP-адрес SPC, который ассоциативно связан с E-SLP 234a либо с отдельной V-SLP. UE 110 в таком случае должен взаимодействовать с SPC, чтобы выполнять позиционирование.

На этапе 10 UE 110 устанавливает надежное (безопасное) IP-соединение со своей H-SLP, если E-SLP 234a является H-SLP (и выбирает работу в режиме H-SLP) для UE. Тем не менее, если E-SLP 234a не является H-SLP для UE 110 и/или если E-SLP 234a включает свой IP-адрес в SUPL INIT на этапе 9, то UE 110 устанавливает IP-соединение или безопасное IP-соединение с E-SLP 234a вместо H-SLP. Для режима без прокси связанные с аутентификацией SUPL-сообщения далее могут передаваться между UE 110 и E-SLP 234a и между E-SLP 234a и любой V-SLP, выбранной на этапе 9 (не показана на фиг.4), и UE 110 далее устанавливает IP-соединение или безопасное IP-соединение с SPC, указанным посредством SUPL INIT на этапе 9. Для прокси-режима UE 110 возвращает SUPL POS INIT в E-SLP 234a. Для режима без прокси UE 110 отправляет SUPL POS INIT в SPC (не показано на фиг.4). SUPL POS INIT может включать в себя способы позиционирования и протоколы позиционирования, поддерживаемые посредством UE 110, идентификатор обслуживающей соты, сетевые измерения, чтобы помочь в вычислениях местоположения, запрос на вспомогательные данные (к примеру, для A-GPS), если UE 110 требуются вспомогательные данные, оценку позиции, если UE 110 уже имеет ее, и/или другую информацию. Если E-SLP 234a или SPC может получить оценку позиции с требуемой точностью из информации, принятой в SUPL POS INIT, то E-SLP или SPC может перейти непосредственно к этапу 12.

На этапе 11 UE 110 продолжает процедуру определения местоположения SUPL с E-SLP 234a для прокси-режима или с SPC для режима без прокси. UE 110 может обмениваться одним или более сообщениями SUPL POS с E-SLP 234a (для прокси-режима) или SPC (для режима без прокси). Каждое сообщение SUPL POS может содержать сообщение позиционирования согласно протоколу LCS радиоресурсов (RRLP) 3GPP, управлению радиоресурсами (RRC) 3GPP или какому-либо другому протоколу позиционирования. E-SLP 234a или SPC может предоставлять вспомогательные данные в UE 110 в этих сообщениях, и UE 110 впоследствии может возвращать связанные с определением местоположения измерения или оценку позиции.

На этапе 12 E-SLP 234a или SPC получает оценку позиции либо посредством вычисления ее из измерений, принятых от UE 110 на этапе 11, либо посредством проверки оценки позиции, принятой от UE на этапе 11. E-SLP 234a или SPC затем отправляет SUPL END в UE 110, чтобы завершить процедуру определения местоположения SUPL. На этапе 13 E-SLP 234a возвращает оценку позиции (которая, возможно, перенаправлена из выбранного V-SLP, не показано на фиг.4) в GMLC 232a в ответе позиции для экстренных служб. На этапе 14 GMLC 232a возвращает оценку позиции в PSAP 180 в ответе на запрос позиции от экстренных служб.

На этапе 15 через некоторое время PSAP 180 может отправить еще один запрос позиции от экстренных служб в GMLC 232a, чтобы получить обновленную оценку позиции для UE 110. В этом случае GMLC 232a может повторить этапы 8-13 для того, чтобы получить новую оценку позиции с помощью SUPL и вернуть ее в PSAP 180 в ответе на запрос позиции от экстренных служб. При запросе оценки позиции из E-SLP 234a в повторении этапа 8 GMLC 232a может передавать последнюю полученную оценку позиции в E-SLP 234a, чтобы помочь ей в определении V-SLP, если данный вариант поддерживается.

На этапе 16 через некоторое время вызов между UE 110 и PSAP 180 завершается. На этапе 17 MSC 230a отправляет в GMLC 232a отчет определения местоположения абонента MAP, идентифицирующий UE 110 (к примеру, посредством MSI или MSISDN) и указывающий то, что вызов завершен. На этапе 18 GMLC 232a может удалить запись вызова, созданную на этапе 3, и вернуть подтверждение приема отчета определения местоположения абонента MAP в MSC 230a.

Фиг.5 иллюстрирует вариант осуществления потока 500 сообщений для экстренного вызова в режиме коммутации каналов в 3GPP, использующем SUPL с определением местоположения, инициированным после установления вызова. На этапе 1 UE 110 отправляет запрос на вызов экстренных служб в MSC 230a. На этапе 2 применяется процедура экстренного вызова. MSC 230a определяет соответствующую PSAP (или клиента экстренных вызовов) на основе идентификатора обслуживающей соты. В последующем описании PSAP 180 - это выбранная PSAP. MSC 230a, RAN 120a и UE 110 продолжают обычную процедуру инициирования экстренного вызова к PSAP 180. Информация установления вызова, отправленная в PSAP 180 (к примеру, посредством PSTN 160), может включать в себя определение местоположения UE (если уже получено), информацию, которая даст возможность поставщику экстренных служб запросить определение местоположения UE позднее (к примеру, сообщение ISUP/BICC IAM с параметром номера местоположения, заданным номеру MSC, и параметром вызывающей стороны, равным MSISDN в Европе), и/или другую информацию.

На этапе 3 MSC 230a может допустить или определить то, что UE 110 поддерживает определение местоположения SUPL. MSC 230a затем отправляет MAP SLR в GMLC 232a, который ассоциативно связан с E-SLP 234a и PSAP 180, в которую экстренный вызов был или будет отправлен на этапе 3. MAP SLR может содержать идентификационные данные UE, идентификатор обслуживающей соты, идентификатор зоны обслуживания (SAI) UE и/или другую информацию. В случае экстренного вызова без SIM или экстренного вызова с незарегистрированной (U)SIM IMEI всегда может быть отправлен, и MSISDN может быть заполнен номером обратного вызова без набора. В Европе MSC 230a может предоставлять идентификационные данные PSAP 180, с которой соединен экстренный вызов.

На этапе 4 GMLC 232a создает запись для вызова. На этапе 5 GMLC 232a возвращает подтверждение приема MAP SLR в MSC 230a. На этапе 6 GMLC 232a отправляет в E-SLP 234a запрос позиции от экстренных служб, который может содержать идентификационные данные UE (к примеру, MSISDN и/или IMSI), идентификатор соты или SAI (если известен), требуемое QoP и/или другую информацию.

На этапах 7-10 E-SLP 234a и UE 110 включаются в процедуру определения местоположения SUPL, как описано выше для этапов 9-12 на фиг.4. Потребность в V-SLP может быть определена из идентификатора соты или SAI (если имеется), принятого на этапе 6. На этапе 10 E-SLP 234a (для прокси-режима) или SPC, ассоциативно связанный с E-SLP 234a или выбранной V-SLP (для режима без прокси), получает оценку позиции UE 110. E-SLP 234a или SPC затем отправляет SUPL END в UE 110, чтобы завершить процедуру обнаружения местоположения SUPL. На этапе 11 E-SLP 234a возвращает оценку позиции (которая, возможно, перенаправлена из выбранного V-SLP, не показано на фиг.5) в GMLC 232a. На этапе 12 GMLC 232a может перенаправить информацию обнаружения местоположения, принятую на этапе 11, информацию об используемом способе позиционирования и/или другую информацию в PSAP 180. В противном случае PSAP 180, как ожидается, получает информацию определения местоположения посредством запрашивания ее от GMLC 232a.

На этапе 13, через некоторое время вызов между UE 110 и PSAP 180 завершается. На этапе 14 MSC 230a отправляет в GMLC 232a отчет определения местоположения абонента MAP, идентифицирующий UE 110 и указывающий то, что вызов завершен. На этапе 15 GMLC 232a может удалить запись вызова, созданную на этапе 4, и вернуть подтверждение приема отчета определения местоположения абонента MAP в MSC 230a.

2. Экстренный вызов в режиме коммутации каналов в 3GPP2 с определением местоположения SUPL

Фиг.6 иллюстрирует вариант осуществления сетевой архитектуры 600 для экстренного вызова в режиме коммутации каналов в 3GPP2 с помощью SUPL. На этапе 1 UE 110 отправляет запрос на вызов экстренных служб в MSC 230b в 3GPP2 PLMN 130b. На этапе 2 MSC 230b может допустить или определить то, что UE 110 поддерживает позиционирование SUPL, к примеру на основе информации подписки UE или информации характеристик UE, принимаемой от UE или политики PLMN 130b. MSC 230b затем отправляет запрос инициирования ANSI-41 MAP в MPC 232b, которая находится в сети, которая имеет ассоциативную связь (к примеру, содержит или подключена) с E-SLP 234b. Запрос инициирования может содержать идентификационные данные UE (к примеру, IMSI и/или MIN), идентификатор обслуживающей соты и/или другую информацию (к примеру, измерения от UE или сети, которая может быть использована для того, чтобы определять оценку позиции).

На этапе 3 MPC 232b создает запись для вызова. MPC 232b может определить оценку промежуточной позиции UE 110 на основе идентификатора соты и всех измерений, принятых на этапе 2. MPC 232b также может инициировать этапы 8-13 заранее, чтобы получить оценку промежуточной позиции для UE 110. MPC 232b может выбирать PSAP на основе оценки промежуточной позиции (если получена) или идентификатора обслуживающей соты, принятого на этапе 2. Если так, MPC 232b может назначить ESRD или ESRK, чтобы указать выбранную PSAP. В последующем описании PSAP 180 - это выбранная PSAP. На этапе 4 MPC 232b возвращает в MSC 230b подтверждение приема запроса инициирования ANSI-41 MAP, содержащего любой ESRD или ESRK, назначенный на этапе 3.

На этапе 5 MSC 230b отправляет вызов экстренных служб в PSAP 180. Если ESRK или ESRD возвращен на этапе 4, то PSAP 180 выбирается посредством MPC 232b на этапе 3. В противном случае MSC 230b может определять PSAP (к примеру, на основе текущей или начальной обслуживающей соты UE 110) и может назначать ESRD и/или ESRK. Сообщение установления вызова, отправляемое посредством MSC 230b в PSAP 180, может включать в себя любой ESRD или ESRK, возвращенный на этапе 4 или назначенный на этапе 5, и номер обратного вызова для UE 110 (к примеру, MSISDN).

На этапе 6 между UE 110 и PSAP 180 устанавливается вызов посредством MSC 230b. На этапе 7 PSAP 180 отправляет запрос позиции от экстренных служб в MPC 232b, чтобы запросить точную оценку начальной позиции UE 110. PSAP 180 может идентифицировать MPC 232b с помощью ESRK или ESRD, принятого на этапе 5. В этом случае запрос позиции от экстренных служб включает в себя ESRK и/или ESRD и номер обратного вызова. На этапе 8 MPC 232b идентифицирует запись вызова, созданную на этапе 3, используя ESRK или номер обратного вызова, принятый на этапе 7. Если MPC 232b получил точную оценку позиции на этапе 3 (к примеру, посредством выполнения этапов 8-13 заранее), то MPC 232b может возвращать ее сразу в PSAP 180 на этапе 14 и пропустить этапы 8-13. В противном случае MPC 232b отправляет в E-SLP 234b запрос позиции от экстренных служб, который может содержать идентификационные данные UE (к примеру, MIN и/или IMSI), идентификатор соты (если известен), требуемое QoP и/или другую информацию.

На этапах 9-12 E-SLP 234b и UE 110 включаются в процедуру определения местоположения SUPL, как описано выше для этапов 9-12 на фиг.4. Если E-SLP 234b (для прокси-режима) или SPC (для режима без прокси) может получать оценку позиции с требуемой точностью из информации, принимаемой в SUPL POS INIT на этапе 10, то E-SLP или SPC может перейти непосредственно к этапу 12. В противном случае UE 110 может обмениваться одним или более сообщениями SUPL POS с E-SLP 234b (для прокси-режима) или SPC (для режима без прокси) на этапе 11. Каждое сообщение SUPL POS может содержать сообщение позиционирования согласно 3GPP2 C.S0022, TIA-801, 3GPP RRLP, RRC или каким-либо другим протоколам позиционирования. E-SLP 234b или SPC может предоставлять вспомогательные данные в UE в этих сообщениях, и UE впоследствии может возвращать связанные с определением местоположения измерения или оценку позиции. На этапе 12 E-SLP 234b или SPC получает оценку позиции и отправляет SUPL END в UE 110, чтобы завершить процедуру определения местоположения SUPL.

На этапе 13 E-SLP 234b возвращает оценку позиции (которая, возможно, перенаправлена из выбранного V-SLP, не показано на фиг.6) в MPG 232b. На этапе 14 MPC 232b возвращает оценку позиции в PSAP 180 в сообщении ответа на запрос позиции от экстренных служб. На этапе 15 через некоторое время PSAP 180 может отправить еще один запрос позиции от экстренных служб в MPC 232b, чтобы получить обновленную оценку позиции для UE 110. В этом случае MPC 232b может повторить этапы 8-13 для того, чтобы получить новую оценку позиции с помощью SUPL и вернуть ее в PSAP 180 в ответе на запрос позиции от экстренных служб. При запросе оценки позиции из E-SLP 234b в повторении этапа 8 MPC 232b может передавать последнюю полученную оценку позиции в E-SLP 234b, чтобы помочь ей в определении V-SLP, если данный вариант поддерживается.

На этапе 16 через некоторое время вызов между UE 110 и PSAP 180 завершается. На этапе 17 MSC 230b отправляет в MPC 232b сообщение отчета завершения вызова ANSI-41 MAP, идентифицирующее UE 110 (к примеру, посредством IMSI или MSISDN) и указывающее то, что вызов завершен. На этапе 18 MPC 232b может удалить запись вызова, созданную на этапе 3, и вернуть подтверждение приема отчета завершения вызова ANSI-41 MAP в MSC 230b.

3. Экстренный вызов в режиме коммутации каналов в 3GPP2 с определением местоположения X.S0024

Фиг.7 иллюстрирует вариант осуществления сетевой архитектуры 700 для экстренного вызова в режиме коммутации каналов с определением местоположения X.S0024. Для 3GPP2 решение определения местоположения в пользовательской плоскости, заданное в 3GPP2 X.S0024, может быть использовано вместо SUPL. Сетевая архитектура 700, таким образом, применима к сетям 3GPP2. RAN 120 может быть 3GPP2 RAN 120b или какой-либо другой сетью доступа. V-PLMN 130b может включать в себя MSC 230b, MPC 232b, E-PS 238 и V-PS 240. MPC 232b может активировать E-PS 238 и использовать X.S0024 для того, чтобы определять местоположение совершающего экстренный вызов UE.

Связанные с определением местоположения интерфейсы между UE 110, E-PS 238 и V-PS 240 могут быть LCS-x, LCS-y и LCS-z, как показано на фиг.7, которые описаны в 3GPP2 X.S0024. Интерфейсом между MSC 230b и MPC 232b может быть ANSI-41 MAP. Интерфейсом между MPC 232b и E-PS 238 может быть MLP, RLP или какой-либо другой интерфейс.

Фиг.8 иллюстрирует вариант осуществления сетевой архитектуры 800 для экстренного вызова в режиме коммутации каналов в 3GPP2 с помощью X.S0024. На этапе 1 UE 110 отправляет запрос на вызов экстренных служб к MSC 230b в 3GPP2 PLMN 130b. На этапе 2 MSC 230b может допустить или определить то, что UE 110 поддерживает позиционирование X.S0024, к примеру на основе информации подписки UE или информации характеристик UE, принимаемой от UE или политики PLMN 130b. MSC 230b далее отправляет сообщение запроса инициирования ANSI-41 MAP в MPC 232b. Запрос инициирования может содержать идентификационные данные UE (к примеру, IMSI и/или MIN), идентификатор обслуживающей соты и/или другую информацию (к примеру, измерения от UE или сети, которая может быть использована для того, чтобы определять оценку позиции).

На этапе 3 MPC 232b создает запись для вызова. MPC 232b может определить оценку промежуточной позиции UE 110 на основе идентификатора соты и всех измерений, принятых на этапе 2. MPC 232b также может инициировать этапы 8-15 заранее и получить оценку промежуточной позиции для UE 110. MPC 232b может выбирать PSAP на основе оценки промежуточной позиции (если получена) или идентификатора обслуживающей соты, принятого на этапе 2. Если так, MPC 232b может назначить ESRD или ESRK, чтобы указать выбранную PSAP. В последующем описании PSAP 180 - это выбранная PSAP. На этапе 4 MPC 232b возвращает в MSC 230b подтверждение приема запроса инициирования ANSL41 MAP, содержащее любой ESRD или ESRK, назначенный на этапе 3. На этапе 5 MSC 230b отправляет вызов экстренных служб в PSAP 180. Если ESRK или ESRD возвращен на этапе 4, то PSAP 180 выбирается посредством MPC 232b на этапе 3. В противном случае MSC 230b может определять PSAP (к примеру, на основе текущей или начальной обслуживающей соты UE 110) и может выделять ESRD и/или ESRK. Сообщение установления вызова, отправляемое посредством MSC 230b в PSAP 180, может включать в себя любой ESRD или ESRK, возвращенный на этапе 4 или назначенный на этапе 5, и номер обратного вызова для UE 110 (к примеру, мобильный абонентский номер, MDN). MSC 230b может отправлять вызов в PSAP 180 до этапа 2, чтобы не допустить задержки вызова. На этапе 6 вызов устанавливается между UE 110 и PSAP 180 посредством MSC 230b. На этапе 7 PSAP 180 отправляет запрос позиции от экстренных служб в MPC 232b, чтобы запросить точную оценку начальной позиции UE 110. PSAP 180 может идентифицировать MPC 232b с помощью ESRK или ESRD, принятого на этапе 5. В этом случае запрос позиции от экстренных служб включает в себя ESRK и/или ESRD и номер обратного вызова. На этапе 8 MPC 232b идентифицирует запись вызова, созданную на этапе 3, используя ESRK или номер обратного вызова, принятый на этапе 7. Если MPC 232b получил точную оценку позиции на этапе 3, то MPC 232b может возвращать ее сразу в PSAP 180 на этапе 16 и пропустить этапы 8-15. В противном случае MPC 232b отправляет в E-PS 238 запрос позиции от экстренных служб, который может содержать идентификационные данные UE (к примеру, MIN и/или IMSI), идентификатор соты (если известен), требуемое QoP и/или другую информацию.

На этапе 9 E-PS 238 побуждает процедуру определения местоположения X.S0024 и отправляет X.S0024 SUPL_INIT в UE 110 с помощью SMS, WAP Push или UDP/IP, если E-PS 238 знает либо может получить IP-адрес UE 110. SUPL_INIT может включать в себя требуемое QoP, поддерживаемые способы позиционирования, IP-адрес E-PS 238, к примеру, если UE 110 не находится в своей домашней сети, если E-PS 238 не является H-PS для UE или если E-PS 238 выбирает не работать в режиме H-PS. SUPL_INIT также может включать в себя индикатор экстренных вызовов, к примеру в параметре оповещения SUPL_INIT. Запрос позиции от экстренных служб на этапе 8 может быть отправлен сразу после этапа 4 без ожидания запроса позиции от экстренных служб от PSAP 180 на этапе 7. В этом случае этапы 8-15 могут быть выполнены до того, как MPG 232b принимает запрос позиции от экстренных служб от PSAP 180 на этапе 7, и MPG 232b может перейти непосредственно от этапа 7 к этапу 16.

На этапе 10 UE 110 устанавливает безопасное IP-соединение с E-PS 238, если он является H-PS для UE. Тем не менее, если E-PS 238 не является H-PS для UE 110 и/или если E-PS 238 включает свой IP-адрес в SUPL_INIT на этапе 9, то UE 110 устанавливает IP-соединение или безопасное IP-соединение с E-PS 238 вместо H-PS. UE 110 затем отправляет в E-PS 238 SUPL_START, которое может включать в себя способы и характеристики позиционирования, поддерживаемые посредством UE 110, идентификатор обслуживающей соты, измерения, оценку позиции, запрос вспомогательных данных и/или другую информацию.

На этапе 11 E-PS 238 может расширить процедуру позиционирования до выбранного PDE, которым может быть PDE, ассоциативно связанный с E-PS 238 или V-PS. Выбранный PDE в таком случае должен управлять процедурой позиционирования и помогать в вычислении позиции. Расширение может использовать либо (a) прокси-режим, в котором UE 110 обменивается данными с выбранным PDE посредством E-PS 238 (как показано на фиг.8), либо (b) режим без прокси, в котором UE 110 обменивается данными непосредственно с выбранным PDE (не показан на фиг.8).

На этапе 12 E-PS 238 отправляет SUPL_RESPONSE в UE 110. Для прокси-режима на этапе 13 UE 110 отправляет в E-PS 238 SUPL_POS, которое может переносить информацию обслуживающей соты, встроенное сообщение позиционирования (к примеру, с помощью 3GPP2 C.S0022 или протокола TIA-801) и/или другую информацию. E-PS 238 после этого перенаправляет SUPL_POS в выбранный PDE (не показан на фиг.8). Для режима без прокси SUPL_RESPONSE на этапе 12 переносит адрес выбранного PDE, и UE 110 устанавливает безопасное IP-соединение с выбранным PDE и отправляет SUPL_POS непосредственно в этот PDE на этапе 13.

На этапе 14 UE 110 может обмениваться дополнительными сообщениями SUPL_POS с E-PS 238 (для прокси-режима) или PDE (для режима без прокси). E-PS 238 или PDE может предоставлять вспомогательные данные в UE 110 в этих сообщениях, и UE может предоставлять измерения для определения местоположения (к примеру, измерения A-GPS и/или A-FLT) либо оценку позиции в E-PS или PDE. На этапе 15 выбранный PDE получает оценку позиции либо посредством вычисления ее из измерений, принятых от UE 110 на этапах 13 и 14, либо посредством проверки оценки позиции, принятой от UE. PDE далее возвращает оценку позиции в E-PS 238 либо непосредственно, если PDE ассоциативно связан с E-PS 238, либо косвенно (не показано на фиг.8), если PDE ассоциативно связан с V-PS. Далее E-PS 238 перенаправляет оценку позиции в MPC 232b в ответе позиции экстренных служб. На этапе 16 MPC 232b возвращает оценку позиции в PSAP 180 в сообщении ответа на запрос позиции от экстренных служб.

На этапе 17 через некоторое время PSAP 180 может отправить еще один запрос позиции от экстренных служб в MPC 232b, чтобы получить обновленную оценку позиции для UE 110. В этом случае MPC 232b может повторить этапы 8-15 для того, чтобы получить новую оценку позиции с помощью X.S0024 и вернуть ее в PSAP 180 в ответе на запрос позиции от экстренных служб. На этапе 18 через некоторое время вызов между UE 110 и PSAP 180 завершается. На этапе 19 MSC 230b отправляет в MPC 232b сообщение отчета завершения вызова ANSI-41 MAP, идентифицирующее UE 110 (к примеру, посредством IMSI или MIN) и указывающее то, что вызов завершен. На этапе 20 MPC 232b может удалить запись вызова, созданную на этапе 3, и вернуть подтверждение приема отчета завершения вызова ANSI-41 MAP в MSC 230b.

4. Использование SUPL 1.0 или X.S0024 версии 1.0

V-PLMN 130 может не использовать либо может вообще не использовать E-SLP или E-PS для того, чтобы поддерживать определение местоположения SUPL или X.S0024 от имени экстренных вызовов в режиме коммутации каналов. Вместо этого V-PLMN 130 может использовать предыдущую версию OMA SUPL (к примеру, SUPL 1.0) или предыдущую версию X.S0024, обе из которых не имеют специальной поддержки определения местоположения для экстренных вызовов. Это может быть преимущественным для сетевого оператора, который еще не развернул версию SUPL или X.S0024, содержащую специальную поддержку определения местоположения для экстренных вызовов, которая предоставляет использование E-SLP или E-PS, как описано выше. Также может быть преимущественным, если сетевой оператор хочет поддерживать экстренные вызовы в режиме коммутации каналов для UE, которые поддерживают только предыдущую версию SUPL или X.S0024 (к примеру, даже если сетевой оператор может поддерживать последнюю версию SUPL или X.S0024).

В варианте осуществления V-PLMN 130 может использовать запрашивающую SLP (R-SLP) вместо E-SLP, которая ассоциативно связана или комбинирована с GMLC 232a или MPC 232b. В этом случае поддержка экстренных вызовов в режиме коммутации каналов по-прежнему может осуществляться так, как описано выше на фиг.4, 5 и 6, но со следующими отличиями. Во-первых, R-SLP должна заменить E-SLP 234a или E-SLP 234b на каждом чертеже. Во-вторых, R-SLP должна принимать запросы позиций от GMLC 232a или MPC 232b на этапе 8 на фиг.4 и 6 и на этапе 6 на фиг.5. R-SLP затем должна возвращать полученную позицию UE в GMLC 232a или MPC 232b на этапе 13 на фиг.4 и 6 и на этапе 11 на фиг.5. В-третьих, процедура определения местоположения SUPL, описанная для этапов 9-12 на фиг.4 и 6 и для этапов 7-10 на фиг.5, должна быть заменена посредством альтернативной процедуры определения местоположения SUPL, при которой R-SLP сначала запрашивает определение местоположения от H-SLP для UE 110. H-SLP должна затем взаимодействовать с UE 110 с помощью SUPL, чтобы получить определение местоположения UE, и должна вернуть определение местоположения UE в R-SLP. Эта альтернативная процедура определения местоположения SUPL задана в OMA-AD-SUPL-V1_0-20060906-C, озаглавленном "Secure User Plane Location Architecture Candidate Version 1.0", 6 сентября 2006 года, который является общедоступным.

Если V-PLMN 130 является H-PLMN 150 для UE 110, то R-SLP может быть H-SLP для UE 110, и модифицированная процедура, описанная выше, может быть использована без необходимости в каком-либо запросе и ответе по определению местоположения между R-SLP и H-SLP, поскольку они теперь являются одним и тем же объектом.

В случае X.S0024 этот вариант осуществления может быть использован аналогичным образом, но с запрашивающей PS (R-PS), заменяющей E-PS 238, ассоциативно связанную или комбинированную с MPC 232b в V-PLMN 130b. В этом случае процедура определения местоположения, описанная на этапах 9-14 на фиг.8, должна быть заменена посредством процедуры, при которой R-PS запрашивает определение местоположения UE 110 из H-PS для UE 110, а H-PS затем взаимодействует с UE 110 для того, чтобы получить определение местоположения (и возвращает его в R-PS), как описано в X.S0024, "IP Based Location Services", версия 1.0, редакция 0, октябрь 2005 года. Как и в случае SUPL, если UE 110 не находится в своей H-PLMN, то R-PS может быть H-PS.

5. Поддержка незарегистрированных UE, UE без UICC, SIM и UIM

Чтобы инициировать определение местоположения SUPL (к примеру, на этапе 9 фиг.4 и 6 и этапе 7 фиг.5), E-SLP отправляет SUPL INIT в UE с помощью WAP Push, SMS, UDP/IP или какого-либо другого средства. Чтобы инициировать определение местоположения X.S0024 (к примеру, на этапе 9 фиг.8), E-PS отправляет SUPL_INIT в UE с помощью WAP Push, SMS, UDP/IP или какого-либо другого средства. Отправка SUPL INIT в некоторых случаях (к примеру, с помощью WAP Push или SMS) может быть затруднительной и отнимающей много времени, если UE перемещается из своей H-PLMN, а также может быть ненадежной вследствие межсетевого взаимодействия с H-PLMN. В варианте осуществления E-SLP или E-PS отправляет SMS-сообщение непосредственно в обслуживающий MSC и эмулирует SMS-шлюз MSC в 3GPP или центр SMS-сообщений в 3GPP2.

В другом варианте осуществления E-SLP или E-PS отправляет SMS-сообщение посредством GMLC или MPC в обслуживающий MSC, чтобы уменьшить влияние на E-SLP или E-PS. Эти варианты осуществления также могут быть использованы для незарегистрированного UE, UE без UICC в 3GPP, UE без SIM в GSM и UE без UIM в 3GPP2. В этом случае MSC может предоставлять GMLC или MPC с временным идентификатором UE, чтобы заменить обычный IMSI, MSISDN или MIN. Временный идентификатор UE может быть включен в отчет по определению местоположения абонента MAP, отправляемый на этапе 2 по фиг.4 и этапе 3 по фиг.5 для 3GPP, и запрос инициирования ANSI-41, отправляемый на этапе 2 по фиг.6 и 8 для 3GPP2. После того как UE принимает SUPL INIT, оно может установить IP-соединение или безопасное IP-соединение с E-SLP или E-PS. Незарегистрированный UE, UE без UICC, UE без SIM или UE без UIM может устанавливать IP-соединения с ограниченным доступом для экстренного вызова, что должно предоставить IP-соединение с E-SLP или E-PS в той же сети. IP-соединения могут устанавливаться, к примеру, с помощью процедур, описанных для "VoIP Emergency Call Support" в 3GPP SA2 статья S2-051950, которая является общедоступной. В этом случае отдельная V-SLP может не использоваться.

Большая часть вышеприведенного описания предполагает, что UE поддерживает одновременный вызов в режиме коммутации каналов (для речи) и передачу данных в режиме коммутации пакетов (для определения местоположения). Если UE или сеть не поддерживают одновременную связь в режиме коммутации каналов и режиме коммутации пакетов, то обмен сигналами между UE и E-SLP или E-PS может поддерживаться другими способами.

Фиг.9 иллюстрирует несколько вариантов осуществления связи между различными объектами. В варианте осуществления SMS используются для всей связи SUPL. С помощью SMS служебные сигналы и информация по определению местоположения (к примеру, SUPL-сообщения) отправляются в рамках SMS-сообщений, которые передаются между MPC/GMLC и MSC и между MSC и UE с помощью существующих транспортных протоколов SMS "точка-точка" (к примеру, сообщений SMS MAP) в 3GPP и 3GPP2. Обмен сигналами через SMS может отправляться непосредственно между MSC и GMLC или MPC. Между E-SLP и GMLC или MPG, SUPL-сообщения могут передаваться с помощью TCP/IP, к примеру по тому же TCP/IP-соединению, что используется для обмена запросом и ответом по позиции от экстренных служб, либо по другому соединению.

В варианте осуществления, который обозначен (a) на фиг.9, SUPL ULP (но не TCP или IP) используется в сквозном режиме между UE и E-SLP или E-PS. В другом варианте осуществления, который обозначен (b) на фиг.9, SUPL ULP передается с помощью сквозного TCP-соединения. В еще одном другом варианте осуществления, который обозначен (c) на фиг.9, SUPL ULP передается с помощью сквозного TCP/IP с некоторым дублированием протоколов на маршруте. Эта возможность может поддерживаться посредством специальной обработки SMS в MSC для SMS-сообщений, отправляемых от UE. Например, MSC может предполагать то, что любое SMS-сообщение, отправленное посредством UE в ходе экстренного вызова, в котором используется SUPL, предназначено для SUPL, и затем должен отправить SMS-сообщение в GMLC или MPC.

6. Безопасность

Для SUPL процедуры обеспечения безопасности могут быть установлены для того, чтобы поддерживать E-SLP в гостевой сети, заменяющей H-SLP, для определения местоположения сценариев с роумингом и без роуминга, а также для прокси-режима или режима без прокси. Существующие процедуры обеспечения безопасности SUPL, в общем, основаны на совместно используемых ключах в UE и H-SLP и/или основаны на другой информации, подготавливаемой в UE, касающейся H-SLP (к примеру, полное доменное имя, корневой сертификат открытого ключа X.509 и т.д.). Эта информация может быть недоступной для E-SLP до тех пор, пока UE не окажется в домашней сети. Для E-SLP аутентификация в режимах с прокси и без прокси может поддерживаться так, как описано ниже.

Для X.S0024 процедуры обеспечения безопасности также могут быть установлены для того, чтобы поддерживать E-PS, заменяющую H-PS для определения местоположения. Существующие процедуры обеспечения безопасности X.S0024 описаны в 3GPP2 X.S0024-0 и 3GPP2 S.P0110-0. Эти процедуры используют общий корневой ключ, предоставляемый и в H-PS пользователя, и в пользовательской UIM. Дополнительные ключи могут быть извлечены из предоставленного корневого ключа следующим образом:

(a) ключ для того, чтобы поддерживать безопасное хранение и прямую инкапсуляцию (S-SAFE), при которой SUPL EMIT отправляется в UE с помощью SMS или WAP Push и аутентифицируется (как следует из H-PS), и необязательно шифруется.

(b) ключ для того, чтобы поддерживать безопасное IP-соединение между UE и H-PS, при котором сообщения X.S0024 отправляются между UE и H-PS с шифрованием и аутентификацией.

(c) ключ для того, чтобы поддерживать безопасное IP-соединение между UE и PDE для режима без прокси, при котором сообщения X.S0024 отправляются между UE и PDE с шифрованием и аутентификацией.

Каждый из этих трех ключей, описанных выше, является фиксированным в том смысле, что есть детерминированное значение для любого значения корневого ключа. Тем не менее, из каждого из этих фиксированных ключей для шифрования и аутентификации могут быть извлечены дополнительные ключи, значения которых зависят от случайных чисел, предоставляемых для конкретного сеанса позиционирования посредством UE и H-PS или PDE. Это извлечение ключей и прилагаемые процедуры обеспечения безопасности используют процедуру безопасности транспортного уровня (TLS), описанную в IETF RFC 2246, и ее вариант PSK-TLS, описанный в черновой версии IETF "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)". Если X.S0024 используется для позиционирования при экстренном вызове в режиме коммутации каналов и E-PS не является H-PS, то более невозможно полагаться на общий заранее сконфигурированный корневой ключ в UE и E-PS для взаимной аутентификации и шифрования.

Для SUPL UE может аутентифицировать E-SLP для того, чтобы избежать неавторизованного доступа к определению местоположения UE даже в ходе экстренного вызова. Для X.S0024 UE и E-PS могут выполнять взаимную аутентификацию. Таблица 1 перечисляет пять способов аутентификации, обозначенных как способы A, B, C, D и E, и характеристики каждого способа.

Таблица 1 Способы аутентификации Характеристика Способ A Способ B Способ C Способ D Способ E Аутентификация E-SLP или E-PS Нет Да Да Да Да Аутентификация UE Нет Ограничено Да Да Да Поддержка роуминга Да Да Да Да Нет Влияние H-PLMN Нет Нет Нет Да Да Безопасное соединение UE с V-PLMN требуется Нет Нет Да Нет Нет Поддержка без UICC/UIM Да Да
(прим. 1) Ограничено Нет Нет Примечание 1. Предполагается, что корневые сертификаты открытых ключей предоставлены в мобильном устройстве (ME).

Способ A предоставляет минимальную аутентификацию. UE предоставляет возможность инициированного сетью определения местоположения SUPL или X.S0024 из неаутентифицированного E-SLP или E-PS, если SUPL INIT указывает определение местоположения для экстренного сеанса и UE в настоящее время участвует в экстренном сеансе. Ограничение на экстренный сеанс предоставляет определенную защиту. Помимо этого перенос SUPL INIT посредством SMS или WAP Push может предоставлять дополнительную уверенность в подлинности UE, поскольку перенос SMS или WAP основывается на поддержке и проверке от V-PLMN и/или H-PLMN. UE может выбирать способ A посредством активации процедур обеспечения безопасности с помощью E-SLP или E-PS. В этом случае, для SUPL, E-SLP может проверять UE в ограниченной степени посредством кода хэширования SUPL INIT, содержащегося в SUPL POS INIT.

Способ B служит для аутентификации открытым ключом TLS. UE и E-SLP или E-PS поддерживают аутентификацию с открытым ключом с помощью TLS, как описано в IETF RFC 2246, а также описано для альтернативного механизма аутентификации клиентов в OMA SUPL 1.0, озаглавленного "Secure User Plane Location Architecture". Этот механизм поддерживает аутентификацию E-SLP или E-PS посредством UE, использующего TLS с сертификатами открытых ключей ITU X.509, отправляемыми посредством E-SLP или E-PS в UE в ходе фазы TLS подтверждения связи. Сертификаты открытых ключей предоставляют цепочку цифровых подписей, причем каждая подпись аутентифицирует следующую, так что UE может аутентифицировать открытый ключ E-SLP или E-PS, при условии, что UE предоставляется открытый ключ, по меньшей мере, одного корневого центра сертификации. Процедура TLS аутентификации с открытым ключом поддерживает перенос симметричных ключей для использования в последующем шифровании и аутентификации сигналов, к примеру для дальнейших сообщений SUPL или X.S0024. Аутентификация и шифрование между UE и SPC или PDE в режиме без прокси также может поддерживаться с помощью этих ключей или посредством извлечения дополнительных ключей из этих ключей.

Способ B базируется на сертификации E-SLP или сертификате открытого ключа E-посредством одного или более корневых центров сертификации (к примеру, заданных посредством OMA) и предоставлении сертификата в UE, поддерживающие SUPL или X.S0024 для экстренных вызовов. UE распознает имя E-SLP или E-PS в этом сертификате, к примеру с помощью полного доменного имени для E-SLP или E-PS либо идентификации MCC-MNC, которую UE может сопоставить с информацией, уже известной из обслуживающей сети. Это обеспечивает аутентификацию E-SLP или E-PS посредством UE и, для SUPL, ограниченную аутентификацию UE посредством E-SLP с помощью 64-битного хэширования SUPL INIT, включенного в SUPL POS INIT и отправленного посредством UE в E-SLP.

Для способа B UE (к примеру, UICC или UIM) может быть снабжен одним или более сертификатами открытого ключа, позволяющих UE проверять открытый ключ(и) E-SLP или E-PS. UE и E-SLP или E-PS могут установить совместно используемый ключ шифрования и ключ кода аутентификации сообщений (MAC) с помощью процедур TLS, описанных в RFC 2246, и одной или более процедур передачи защищенного открытого ключа, к примеру RSA, DSS или Diffie-Hellman. Шифрование и аутентификация сообщений SUPL или X.S0024 может выполняться после установления безопасного TLS-соединения. Для режима без прокси способ, заданный для режима без прокси 3GPP2 в SUPL 1.0, может быть использован для того, чтобы формировать совместно используемый ключ для аутентификации и шифрования, согласно IETF PSK-TLS, между UE и SPC в SUPL или между UE и PDE в X.S0024.

Способ C служит для аутентификации PSK-TLS. UE и E-SLP или E-PS поддерживают PSK-TLS (к примеру, как описано в SUPL 1.0 для 3GPP2 SET или 3GPP2 X.S0024-0 и S.P0110-0) согласно черновику IETF "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)". Предварительно совместно используемый ключ (PSK) может быть сформирован из (a) информации (к примеру, произвольной информации), предоставляемой посредством UE, сети (к примеру, MSC или HLR) и/или E-SLP либо E-PS, (b) информации (к примеру, параметров), отправляемой посредством или в UE в ходе установления экстренного вызова, (c) информации обеспечения безопасности (к примеру, ключа шифрования), уже присутствующей в MSC и UE, чтобы поддерживать безопасный доступ в режиме коммутации каналов от UE, и/или (d) другой информации. Информация обеспечения безопасности в (c) может быть доступна, если UE регистрируется в V-PLMN.

PSK или информация, используемая для того, чтобы извлекать его, может быть сделана доступной для UE и E-SLP (либо MPC или GMLC) или E-PS (или MPC) в ходе установления экстренного вызова. Доверительные отношения, устанавливаемые в ходе установления вызова между этими объектами, используются для того, чтобы получать защищенный PSK или общую информацию, из которой может быть извлечен защищенный ключ. UE и E-SLP далее могут использовать PSK-TLS для определения местоположения SUPL с помощью полученных PSK. PSK могут быть использованы для того, чтобы получать дополнительный PSK для аутентификации в режиме без прокси. Для SUPL взаимная аутентификация UE и E-SLP может поддерживаться с помощью PSK-TLS, когда UE устанавливает IP-(PSK-TLS)-соединение с E-SLP после передачи SUPL INIT от E-SLP в UE. Для X.S0024 защищенный PSK может быть использован в качестве корневого ключа, из которого оставшаяся информация обеспечения безопасности может быть извлечена, как описано в 3GPP2 X.S0024-0 и S.P0110-0.

Способ C базируется на надежном (защищенном) соединении между UE и V-PLMN в ходе установления экстренного вызова, что подразумевает регистрацию UE в V-PLMN и взаимную аутентификацию UE и V-PLMN. Если UE не имеет UICC/UIM или если нет соглашения о роуминге между V-PLMN и H-PLMN, взаимная аутентификация и надежная (защищенная) передача между V-PLMN и UE может не достигаться в ходе установления экстренного вызова, и любой сформированный PSK должен предоставлять более ограниченную защиту.

Способ D служит для аутентификации с помощью общей архитектуры самозагрузки (GBA), описанной в 3GPP TS 33.220 или 3GPP2 TSG-S версия S.P0109. UE и E-SLP или E-PS поддерживают GBA. Это позволяет UE и E-SLP или E-PS получать защищенный общий ключ от H-PLMN. Для SUPL этот ключ может быть использован для того, чтобы поддерживать взаимную аутентификацию PSK-TLS между UE и E-SLP, как описано в 3GPP TS 33.222 или 3GPP2 TSG-S версия S.P0114. Этот способ используется в SUPL 1.0 для того, чтобы поддерживать прокси-режим 3GPP. Ключ также может быть использован для того, чтобы поддерживать TLS с аутентификацией HTTP Digest (к примеру, как описано в 3GPP TS 33.222), только аутентификацией HTTP Digest между UE и E-SLP (к примеру, как описано в 3GPP2 TSG-S версия S.P0114) или другими формами аутентификации. Для X.S0024 этот ключ может быть использован в качестве корневого ключа, из которого может быть извлечена вся оставшаяся информация обеспечения безопасности.

Способ D базируется на поддержке GBA в H-PLMN и V-PLMN и соглашении о роуминге между H-PLMN и V-PLMN, чтобы обеспечить передачу информации ключей из инициализирующей обслуживающей функции (BSF) в H-PLMN в функцию сетевых приложений (NAF) E-SLP в V-PLMN. Способ E служит для аутентификации SUPL 1.0 или X.S0024. Для SUPL, если UE находится в H-PLMN, то E-SLP может быть H-SLP, и могут быть использованы существующие механизмы аутентификации, заданные в SUPL 1.0. Для X.S0024, если UE находится в H-PLMN, то E-PS может быть H-PS, и могут быть использованы существующие механизмы аутентификации, заданные в X.S0024.

Фиг.10 иллюстрирует блок-схему варианта осуществления UE 110, RAN 120, MSC 230, центра 242 определения местоположения и сервера 244 определения местоположения. Центром 242 определения местоположения может быть GMLC 232a, MPC 232b и/или какой-либо другой объект. Сервером 244 определения местоположения может быть E-SLP 234a, E-SLP 234b, E-PS 238 и/или какой-либо другой объект. Для простоты фиг.10 иллюстрирует только один процессор 1010, одно запоминающее устройство 1012 и одно приемо-передающее устройство 1014 для UE 110, только один процессор 1020, одно запоминающее устройство 1022, одно приемо-передающее устройство 1024 и один блок 1026 связи для RAN 120, только один процессор 1030, одно запоминающее устройство 1032 и один блок 1034 связи для MSC 230, только один процессор 1040, одно запоминающее устройство 1042 и один блок 1044 связи для центра 242 определения местоположения и только один процессор 1050, одно запоминающее устройство 1052 и один блок 1054 связи для сервера 244 определения местоположения. В общем, каждый объект может включать в себя любое число процессоров, запоминающих устройств, приемо-передающих устройств, блоков связи, контроллеров и т.п.

В нисходящей линии связи базовые станции в RAN 120 передают данные трафика, служебные сигналы и контрольные сигналы в UE в своей зоне покрытия. Эти различные типы данных обрабатываются посредством процессора 1020 и приводятся к требуемым параметрам посредством приемо-передающего устройства 1024, чтобы сформировать сигнал нисходящей линии связи, который передается посредством антенны. В UE 110 сигналы нисходящей линии связи от базовых станций принимаются посредством антенны, приводятся к требуемым параметрам посредством приемо-передающего устройства 1014 и обрабатываются посредством процессора 1010, чтобы получать различные типы информации для вызова, определения местоположения и других услуг в режиме коммутации каналов. Например, процессор 1010 может выполнять обработку для UE 110 в потоке сообщений, описанном выше. Запоминающие устройства 1012 и 1022 сохраняют программные коды и данные для UE 110 и RAN 120 соответственно. В восходящей линии связи UE 110 может передавать данные трафика, служебные сигналы и контрольные сигналы в базовые стации в RAN 120. Эти различные типы данных обрабатываются посредством процессора 1010 и приводятся к требуемым параметрам посредством приемо-передающего устройства 1014, чтобы сформировать сигнал восходящей линии связи, который передается посредством антенны UE. В RAN 120 сигналы восходящей линии связи от UE 110 и других UE принимаются и приводятся к требуемым параметрам посредством приемо-передающего устройства 1024 и дополнительно обрабатываются посредством процессора 1020, чтобы получить различные типы информации (к примеру, данные, служебные сигналы, отчеты и т.д.). RAN 120 обменивается данными с MSC 230 и другими объектами посредством блока 1026 связи.

В MSC 230 процессор 1030 выполняет обработку для MSC, запоминающее устройство 1032 сохраняет программные коды и данные для MSC, а блок 1034 связи позволяет MSC обмениваться данными с другими объектами. Процессор 1030 может выполнять обработку для MSC 230 в потоках сообщений, описанных выше.

В центре 242 определения местоположения процессор 1040 поддерживает определение местоположения для UE, запоминающее устройство 1042 сохраняет программные коды и данные для центра определения местоположения, а блок 1044 связи позволяет центру определения местоположения обмениваться данными с другими объектами. Процессор 1040 может выполнять обработку для GMLC 232a и/или MPG 232b в потоках сообщений, описанных выше.

В сервере 244 определения местоположения процессор 1050 выполняет обработку определения местоположения и/или позиционирования для UE, запоминающее устройство 1052 сохраняет программные коды и данные сервера центра определения местоположения, а блок 1054 связи позволяет серверу определения местоположения обмениваться данными с другими объектами. Процессор 1050 может выполнять обработку для E-SLP 234a, E-SLP 234b и/или E-PS 238 в потоках сообщений, описанных выше.

Описанные в данном документе методики могут быть реализованы различными средствами. Например, эти методики могут быть реализованы в аппаратных средствах, микропрограммном обеспечении, программном обеспечении или их сочетании. При реализации в аппаратных средствах блоки обработки, используемые для того, чтобы выполнять данные методики, могут быть реализованы в одной или нескольких специализированных интегральных схемах (ASIC), процессорах цифровых сигналов (DSP), устройствах цифровой обработки сигналов (DSPD), программируемых логических устройствах (PLD), программируемых пользователем матричных БИС (FPGA), процессорах, контроллерах, микроконтроллерах, микропроцессорах, электронных устройствах, других электронных блоках, предназначенных для того, чтобы выполнять описанные в данном документе функции, или в их сочетаниях.

При реализации в микропрограммном обеспечении и/или программном обеспечении методики могут быть реализованы с помощью модулей (к примеру, процедур, функций и т.п.), которые выполняют описанные в данном документе функции. Коды микропрограммного обеспечения и/или программного обеспечения могут быть сохранены в запоминающем устройстве (к примеру, запоминающем устройстве 1012, 1022, 1032, 1042 и/или 1052 на фиг.10) и выполнены посредством процессора (к примеру, процессора 1010, 1020, 1030, 1040 и/или 1050). Запоминающее устройство может быть реализовано в процессоре или внешне по отношению к процессору.

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

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

Описаны методики для поддержки экстренных вызовов в режиме коммутации каналов. Технический результат заключается в совершенствовании маршрутизации экстренных вызовов. Методики могут быть использованы для различных сетей 3GPP и 3GPP2, различных архитектур определения местоположения и различных типов абонентских устройств (UE). UE устанавливает вызов в режиме коммутации каналов с помощью беспроводной сети для экстренных служб. UE взаимодействует с сервером определения местоположения, указанным беспроводной сетью. UE выполняет определение местоположения в пользовательской плоскости с помощью сервера определения местоположения в течение вызова в режиме коммутации каналов для получения оценки позиции UE. UE обменивается данными с PSAP, которая может быть выбрана на основе оценки позиции, для экстренного вызова в режиме коммутации каналов. UE может осуществлять позиционирование с помощью сервера определения местоположения для получения обновленной оценки позиции UE, например, каждый раз, когда запрошено посредством PSAP. 9 н. и 42 з.п. ф-лы, 1 табл., 10 ил.

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

2. UE по п.1, в котором PSAP выбрана на основе оценки позиции.

3. UE по п.1, дополнительно выполненное с возможностью осуществления определения местоположения в пользовательской плоскости с помощью сервера определения местоположения после выполнения установления вызова с отвечающей точкой общественной безопасности (PSAP).

4. UE по п.1, дополнительно выполненное с возможностью осуществления определения местоположения в пользовательской плоскости с помощью платформы определения местоположения SUPL (SLP) в соответствии с надежным определением местоположения в пользовательской плоскости (SUPL) для получения оценки позиции, при этом SLP является сервером определения местоположения, указанным беспроводной сетью.

5. UE по п.1, дополнительно выполненное с возможностью осуществления определения местоположения в пользовательской плоскости с помощью сервера позиционирования (PS) в соответствии с X.S0024 для получения оценки позиции, при этом сервер позиционирования является сервером определения местоположения, указанным беспроводной сетью.

6. UE по п.1, дополнительно выполненное с возможностью приема от сервера определения местоположения сообщения для инициирования определения местоположения в пользовательской плоскости, включающее в себя адрес Интернет-протокола (IP) сервера определения местоположения и обмена данными с сервером определения местоположения с помощью IP-адреса.

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

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

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

10. UE по п.1, дополнительно выполненное с возможностью отправки возможностей по определению местоположения UE в беспроводную сеть, при этом сервер определения местоположения выбирается на основе возможностей UE по определению местоположения.

11. UE по п.1, дополнительно выполненное с возможностью отправки информации определения местоположения в беспроводную сеть, при этом сервер определения местоположения выбирается на основе информации определения местоположения.

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

13. UE по п.1, дополнительно выполненное с возможностью обмена сообщениями для определения местоположения в пользовательской плоскости с помощью службы коротких сообщений (SMS).

14. UE по п.1, дополнительно выполненное с возможностью обмена сообщениями для определения местоположения в пользовательской плоскости с помощью протокола управления передачей (TCP) или обоих TCP и Интернет-протокола (IP).

15. UE по п.1, причем беспроводная сеть является 3GРР-сетью и при этом UE выполнено с возможностью установления экстренного вызова в режиме коммутации каналов с 3GРР-сетью для экстренных служб.

16. UE по п.1, причем беспроводная сеть является 3GРР2-сетью и при этом UE выполнено с возможностью установления экстренного вызова в режиме коммутации каналов с 3GРР2-сетью для экстренных служб.

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

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

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

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

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

22. Устройство по п.21, в котором средство осуществления определения местоположения в пользовательской плоскости содержит средство осуществления определения местоположения в пользовательской плоскости с помощью платформы определения местоположения SUPL (SLP) в соответствии с надежным определением местоположения в пользовательской плоскости (SUPL) для получения оценки позиции, при этом SLP является сервером определения местоположения, указанным беспроводной сетью.

23. Устройство по п.21, в котором средство осуществления определения местоположения в пользовательской плоскости содержит средство приема от сервера определения местоположения сообщения для инициирования определения местоположения в пользовательской плоскости, включающего в себя адрес Интернет-протокола (IP) сервера определения местоположения, и средство обмена данными с сервером определения местоположения с помощью IP-адреса.

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

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

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

27. Центр определения местоположения по п.25, дополнительно выполненный с возможностью использования оценки позиции для предоставления информации в первый объект.

28. Центр определения местоположения по п.25, в котором информация, предоставляемая в первый объект, содержит ключ маршрутизации экстренных служб (ESRK) или код маршрутизации экстренных служб (ESRD) для отвечающей точки общественной безопасности (PSAP).

29. Центр определения местоположения по п.25, выполненный с возможностью получения оценки позиции от платформы определения местоположения SUPL (SLP), поддерживающей надежное определение местоположения в пользовательской плоскости (SUPL), при этом SLP является сервером определения местоположения, поддерживающим определение местоположения в пользовательской плоскости.

30. Центр определения местоположения по п.25, выполненный с возможностью получения оценки позиции от запрашивающей платформы определения местоположения SUPL (R-SLP), причем R-SLP получает оценку позиции из домашней SLP (H-SLP), действующей в качестве сервера определения местоположения, поддерживающего определение местоположения в пользовательской плоскости.

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

32. Центр определения местоположения по п.25, выполненный с возможностью получения оценки позиции от запрашивающего сервера позиционирования SUPL (R-PS), причем R-PS получает оценку позиции из домашнего PS (H-PS), действующего в качестве сервера определения местоположения, поддерживающего определение местоположения в пользовательской плоскости.

33. Центр определения местоположения по п.25, соответствующий шлюзовому центру определения местоположения мобильной связи (GMLC) в 3GРР-сети.

34. Центр определения местоположения по п.25, соответствующий центру позиционирования мобильной связи (МРС) в 3GРР2-сети.

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

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

37. Сервер определения местоположения по п.36, выполненный с возможностью осуществления определения местоположения в пользовательской плоскости с помощью UE в соответствии с надежным определением местоположения в пользовательской плоскости (SUPL) для получения оценки позиции.

38. Сервер определения местоположения по п.36, выполненный с возможностью осуществления определения местоположения в пользовательской плоскости с помощью UE в соответствии с X.S0024 для получения оценки позиции.

39. Сервер определения местоположения по п.36, выполненный с возможностью отправки сообщения для инициирования определения местоположения в пользовательской плоскости с UE, причем сообщение включает в себя адрес Интернет-протокола (IP) сервера определения местоположения и используется UE для обмена данными с сервером определения местоположения для определения местоположения в пользовательской плоскости.

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

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

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

43. Способ по п.42, в котором осуществление определения местоположения в пользовательской плоскости содержит этап, на котором отправляют сообщение для инициирования определения местоположения в пользовательской плоскости с помощью UE, причем сообщение включает в себя адрес Интернет-протокола (IP) сервера определения местоположения и используется UE для обмена данными с сервером определения местоположения для определения местоположения в пользовательской плоскости.

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

45. UE по п.44, дополнительно выполненное с возможностью выполнения взаимной аутентификации с сервером определения местоположения.

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

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

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

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

50. UE по п.44, дополнительно выполненное с возможностью выполнения аутентификации в соответствии с надежным определением местоположения в пользовательской плоскости (SUPL) или X.S0024.

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