ТЕЛЕФОННЫЕ УСЛУГИ В СЕТЯХ МОБИЛЬНОЙ СВЯЗИ С ИНТЕРНЕТ-ПРОТОКОЛОМ Российский патент 2011 года по МПК H04W4/02 H04B7/26 

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

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

Услуги связи исторически предоставлялись по сетям с коммутацией каналов, таким как коммутируемая телефонная сеть общего пользования (КТСОП) (PSTN), но теперь они могут также предоставляться и по сетям с коммутацией пакетов, таким как Интернет. Эти сети с коммутацией пакетов обычно именуются сетями ИП, потому что Интернет-протокол является наиболее широко используемым основным протоколом. Многие сети с беспроводными модемами используют комбинацию телефонного оборудования (такого как традиционные сотовые телефоны) и оборудования коммутации пакетов (обычно оборудования, маршрутизирующего сетевой трафик), согласованного с одним или несколькими стандартами ИП телефонии, такими как, например, стандарт Н.323 Международного союза электросвязи (МСЭ) (ITU) или спецификации RFC 2543 протокола начала сеанса (ПНС) (SIP) комитета инженерной поддержки сети Интернет (КИПИ) (IETF).

Имеется несколько предложений для нового третьего поколения основанных на ИП мобильных сетей, в которых пользовательское оборудование, равно как и сетевое оборудование, совместимы с одним или несколькими стандартами ИП для сетей с коммутацией пакетов. Однако при предоставлении услуг речевых вызовов такие ИП телефонные сети мобильной связи ИПТМ (MIPT) имеют некоторые сложности, отсутствующие в сетях сотовой связи второго поколения. К примеру, хотя абоненты сотовой связи могут часто перемещаться между сетями сотовой связи второго поколения, для абонентов ИП телефонии (ИПТ) (ITP) в ИПТМ сетях бывает затруднительно получить с легкостью такие же услуги, доступные в их собственной сети, когда они попадают в другие сети.

Имеется, например, ИП протокол мобильной связи, разрешающий мобильность. В качестве примера возможно, что абонент ИПТ с доступом к общей услуге пакетной радиосвязи (ОУПР) (GPRS) в посещаемой сети (см. 3G TS 23.060, стадия 2, версия 3.3.0) использует услуги речевого вызова в своей собственной сети, так что этот абонент регистрируется в объекте управления вызовом (например с функцией управления состоянием вызова (ФУСВ) (CSCF)) в собственной сети. Однако для некоторых услуг, таких как экстренные вызовы 911, для успешного выполнения необходимо использовать услуги речевого вызова в посещаемой сети и предоставлять основанные на местоположении услуги. Поэтому имеется необходимость в способе, который позволяет перемещающимся абонентами ИПТ легко получать доступ к основанным на местоположении услугам, получать их и осуществлять экстренные вызовы в ИПТМ сетях.

В частности, когда в объекте управления вызовом сотовой сети второго поколения принимается запрос на установление экстренного вызова, он выбирает пункт безопасного ответа общего пользования (ПБООП) (PSAP), чтобы маршрутизировать к нему этот вызов на основании информации идентификатора сотовой ячейки или местоположения, предоставленной в процессе установления вызова. Однако этот способ не всегда можно выполнять в ИП сетях мобильной связи третьего поколения, основанных на стандарте универсальной системы мобильной связи (УСМС) (UMTS), поскольку информация идентификатора ячейки или местоположения может не всегда быть доступной для объекта управления вызовом из-за способа, которым устанавливается экстренный вызов. Поэтому необходим способ поддержки выбора ПБООП в ИП сетях мобильной связи третьего поколения, основанных на стандарте УСМС.

Настоящее изобретение направлено на обсуждавшиеся выше недостатки ИПТМ сетей. Оно в целом относится к системам и способам предоставления основанных на местоположении услуг и/или экстренных вызовов, их инициирования, обеспечения доступа к ним, их использования или управления ими в ИП телефонных сетях мобильной связи третьего поколения. Одно применение изобретения относится к услуге, в которой абонент, посещающий сети иные, нежели его собственная сеть, использует их мобильный терминал, чтобы делать экстренный вызов. Этот экстренный вызов соединяется с ФУСВ, который направляет этот экстренный вызов к ПБООП без аутентификации (проверка полномочий) на доступ или выписки счета, а примерное географическое положение этого абонента передается в ФУСВ или в ПБООП в то же самое время, как происходит соединение этого экстренного вызова.

Примеры осуществления изобретения предлагают выбор механизма, который предоставляет управляемый доступ к ФУСВ локальной сети, таким образом, что экстренный вызов может быть легко установлен. Когда этот экстренный вызов инициализируется, шлюзовой узел поддержки ОУПР (ШУПО) (GGSN) предоставляет адрес функции управления состоянием вызова (ФУСВ). Запрос на установление экстренного вызова посылается к функции управления состоянием вызова (ФУСВ). Этот запрос на установление экстренного вызова включает в себя идентификатор зоны обслуживания (ИЗО) (SAI) в ОУПР. ФУСВ выбирает пункт безопасного ответа общего пользования (ПБООП), чтобы маршрутизировать к нему вызов по меньшей мере частично на основании идентификатора зоны обслуживания (ИЗУ), и направляет экстренный вызов на выбранный ПБООП без аутентификации или выписки счета. Предпочтительно, примерное географическое положение абонента передается к ФУСВ или к ПБООП в то же самое время, когда осуществляется соединение экстренного вызова. Тем самым становится возможно делать экстренный вызов без модуля идентификации абонента (МИА) (SIM) и без каких-либо расходов. Сеть доступа в примерах осуществления способна управлять контекстами протокола пакетных данных (ППД) (PDP), которые используются для экстренных вызовов, так что их нельзя пропустить и они не подвержены подлогу.

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

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

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

Фиг.3 является упрощенной блок-схемой, отображающей пример объектов услуг местоположения и компонентов ИП телефонной сети мобильной связи третьего поколения согласно примерам осуществления изобретения.

Фиг.4 представляет собой общую схему сигнализации для примерного осуществления изобретения, в котором делается экстренный вызов абонентом с модулем идентификации абонента (МИА).

Фиг.5 представляет собой общую схему сигнализации для примерного осуществления изобретения, в котором делается экстренный вызов абонентом без модуля идентификации абонента (МИА).

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

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

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

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

Фиг.10 представляет собой схему сигнализации для примерного осуществления изобретения, в котором служебный узел поддержки ОУПР (SGSN) (СУПО) знает текущий идентификатор зоны обслуживания, когда он принимает запрос активировать контекст ППД.

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

Наилучшие примеры осуществления изобретения

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

Фиг.1 представляет собой блок-схему типичной ИП телефонной сети мобильной связи третьего поколения, базирующейся на стандарте УСМС. Подробные технические описания для сети УСМС опубликованы Проектом сотрудничества третьего поколения в Выпуске 1999 года (www.3gpp.org). Блоки на фиг.1 представляют различные функции и необязательно соответствуют различным дискретным сетевым элементам или оборудованию.

Услуги местоположения поддерживаются элементами по всей сети. Некоторые услуги выполняются в традиционных сетевых элементах, таких как (контроллер радиосети (КРС) (RNC)), центр коммутации услуг мобильной связи (ЦКУМ) (MSSC) и сервисный узел поддержки ОУПР (СУПО) (SGSN). Кроме того, для поддержания услуг местоположения предлагаются некоторые новые сетевые элементы и интерфейсы.

Одним новым функциональным элементом в сети является блок измерения местоположения (БИМ) (LMU), который может быть, а может и не быть включен (БИМ не показан на фиг.1, но включен как элемент 301 на фиг.3) в каждой из подсистем базовой станции (ПБС) (BSS) в узлах с В 101-1 по В 101-n, предпочтительно без технических ограничений, по меньшей мере когда используется способ определения местоположения прямой линии связи с интервалом времени ожидания - по разности времен прихода (ПЛИО-РВП) (ISFL-TDOA) или способ определения местоположения по наблюдаемой разности времен прихода - нисходящей линии связи с периодом ожидания (НРВП-НЛПО) (OTDOA-IPDL). БИМ 301 прежде всего измеряет действительную разность времен (ДРВ) (RTD), абсолютную разность времен (АРВ) (ATD) или любой иной вид радиоинтерфейсной синхронизации сигналов, переданных базовыми станциями. Эти вспомогательные измерения, полученные БИМом 301, являются основной информацией статуса и могут использоваться более чем одним способом определения местоположения. Эти измерения могут состоять из измерений местоположения, специфичных для одного мобильного терминала, используемого для вычисления местоположения этого мобильного терминала, или вспомогательных измерений, специфичных для всех мобильных терминалов в некоторой географической зоне.

Все местоположения, разности синхронизации и вспомогательные измерения, полученные БИМом 301, подаются на конкретный обслуживающий контроллер 102 радиосвязи (ОКРС) (SRNC), связанный с базовой станцией, имеющей функцию БИМ 301. Команды, касающиеся синхронизации, природы и любой периодичности этих измерений, либо предоставляются от ОКРС 102, либо заранее вводятся в базовую станцию.

В услугах определения местоположения GSM (глобальной системы мобильной связи - ГСМ) БИМ является отдельным от сети GSM элементом. Связь между сетью GSM и БИМом осуществляется через эфирный интерфейс GSM. В услугах определения местоположения УСМС функция БИМ встроена в базовую станцию, предпочтительно без технических ограничений, по меньшей мере когда используется способ определения местоположения прямой линии связи с интервалом времени ожидания - по разности времен прихода (ПЛИО-РВП) (ISFL-TDOA) или способ определения местоположения по наблюдаемой разности времен прихода - нисходящей линии связи с периодом ожидания (НРВП-НЛПО) (OTDOA-IPDL).

Мобильный терминал (МТ) 100 может быть включен в различные уровни в процедурах определения местоположения в зависимости от применяемого способа определения местоположения. В дополнение к этому, роль МТ 100 тесно связана с подходом определения местоположения, используемым в системе. К примеру, функции МТ 100 могут охватывать, а могут и не охватывать вычисления местоположения. Предпочтительно, они могут инициировать услугу определения местоположения путем запроса в сеть для определения местоположения (определение местоположения с помощью сети). Если они поддерживают использование наборов нисходящих линий связи с интервалом времени ожидания (НЛ-ИО) (IS-DL), то они выполняют также следующие функции:

1) измеряют и сохраняют сигнал во время периодов ожидания;

2) сравнивают с различными кодами БЧХ (Бозе-Чоудхури-Хоквингема) (ВСН) между периодами ожидания;

3) определяют время прихода первого обнаруживаемого канала как для обслуживающей подсистемы базовой станции (ПБС), так и для других ПБС, которые они обнаруживают;

4) определяют, когда появляется период ожидания; и

5) сообщают результаты обратно в сеть.

Каждый узел В способен закрыть передачу на время периода ожидания. Эта функция может быть заранее определена в узле В или может управляться соответствующим КРС 102. Каждый узел В может также управлять функциями БИМ 301, в том числе функцией измерения сигнала позиционирования (ФИСП) (PSMF) и функцией работы системы определения местоположения (ФРСОМ) (LSOF). Таким образом, он реагирует на собирание измерений радиосигналов восходящей линии связи - нисходящей линии связи для вычисления положения мобильного терминала. Он также вовлечен в общую работу услуг определения местоположения в сети.

ОКРС 102 в универсальной наземной сети радиодоступа (УНСРД) (UTRAN) 103 содержит функции, требуемые для поддержания услуг и процедур по определению местоположения между БИМ 310 и объектами услуг определения местоположения в одной наземной сети мобильной связи общего пользования (НСМО) (PLMN). Он предпочтительно управляет процедурами НЛ-ПО РВН периодически или согласно заранее заданным параметрам, управляет периодом снижения мощности каждого узла В и выполняет объекты функции работы системы определения местоположения (ФРСОМ), функции координации радиосвязи определения местоположения (ФКРОМ) (PRCF), функции вычислений местоположения (ФВМ) (PCF) и функции управления радиоресурсами при определении местоположения (ФУРОМ) (PRRM). Это включает в себя предоставление данных, способности определения местоположения, работу услуг определения местоположения, вычисление местоположения, сбор измерений радиосигналов восходящей линии связи или нисходящей линии связи для вычисления положения мобильной станции, управления позиционированием мобильного терминала путем всеобщего координирования, резервирования и планирования ресурсов (в том числе канал прямого доступа - канал случайного доступа (КПД/КСД) (FACH/RACH) или выделенный канал (ВК) (DCH)), требуемого для выполнения измерений по определению местоположения мобильного терминала 100, и управления услугами радиодоступа для определения местоположения. ОКРС 102 вычисляет также конечные оценку и точность местоположения.

ОКРС 102 управляет каждым БИМом 301 из нескольких БИМов для целей получения измерений радиоинтерфейса, чтобы определить местоположение или помочь в определении местоположения МТ 100 в зоне, которую он обслуживает. В ОКРС 102 вводятся возможности и виды измерений, производимых каждым из его БИМов. Измерения местоположения, возвращенные БИМом 301 в ОКРС 102, имеют родовой статус и могут использоваться для более чем одного способа определения местоположения (в том числе время прихода).

Сигнализация между ОКРС 102 и каждым БИМом 301 передается через интерфейс Iub, а в некоторые конкретные периоды через интерфейс Iur. Интерфейс Iur поддерживает мягкие передачи обслуживания между КРС, включая и услуги местоположения. Когда бы ни произошла мягкая передача обслуживания между КРС, Iur поддерживает функции определяющих местоположение объектов в КРСах, в том числе ФВМ, ФУРОМ, функцию измерения сигналов для определения местоположения (ФИСОМ) (PSMF) и ФРСОМ. В случае изменения местоположения ОКРС Iur поддерживает механизмы изменения местоположения для передачи функций ФВМ, ФУРОМ, ФИСОМ и ФРСОМ от ОКРС к КРС дрейфа (КРСД) для того чтобы КРСД были способны управлять способностью ОКРСов отвечать в процессах услуг местоположения.

УНСРД 103 вовлечен в управление различными процедурами определения местоположения и общее управление уровнями СРД (сети радиодоступа) услуг местоположения. Она управляет способом нисходящей линии связи с интервалами времени ожидания (НЛ-ИО) и задает общую координацию и планирование ресурсов, требуемых для определения местоположения мобильного терминала. В сети, основанной на подходе определения местоположения, УНСРД 103 вычисляет конечные оценку и точность местоположения и управляет числом узлов от В 101-1 до 101-n для целей получения радиоинтерфейсных измерений для определения местоположения и помощи в определении местоположения мобильного терминала 100 в зоне обслуживания.

В общем случае, УНСРД 103 предоставляет идентификатор сотовой ячейки и относящиеся к синхронизации данные в центр 104 коммутации мобильной связи третьего поколения (ЦКМС-3П) (3G-MSC). Согласно примерному выполнению изобретения, описанному ниже, она вместо этого может предоставлять в ЦКМС-3П) 104 код идентификации зоны обслуживания (ИЗО) (SAI). ЦКМС-3П 104 аналогичен ЦКМС в сети GSM, но функции обслуживающего центра мобильного местоположения местоположения мобильного терминала (ОЦММ) (SMLC) (элемент 302 на фиг.3) могут интегрироваться в ОКРС 102. Функциями ЦКМС-3П являются выписка счетов, координация, запросы местоположения, удостоверение подлинности мобильных терминалов и управление связанными с вызовами и не связанными с вызовами запросами на определение местоположения и работой услуг местоположения.

Поскольку ЦКМС-3П 104 имеет независимое управление мобильностью, УНСРД 103 вместо этого в общем случае предоставляет идентификатор сотовой ячейки в СУПО 105. В примерном выполнении изобретения, описанном ниже, УНСРД 103 может вместо этого предоставлять ИЗО в СУПО 105. Параметры услуг местоположения включаются в интерфейс Iu между КРСами 102 и ЦКМС-3П 104 и СУПО-3П 105. СУПО-3П 105 аналогичен ЦКМС 104. Функциями СУПО 105 являются начисление платы, координация, удостоверение подлинности мобильных терминалов и управление запросами на определение местоположения и работами услуг местоположения, если рассматриваются доступы пакетной коммутации. Если мобильные терминалы 100 поддерживают как основанное на сети, так и основанное на мобильных терминалах определение местоположения, каждый КРС 102 вычисляет положение каждого мобильного терминала 100, когда применяется основанное на мобильных станциях определение местоположения путем сбора радиосигнальных измерений восходящей линии связи - нисходящей линии связи вниз (ВЛ-НЛ) (UL/DL). Затем КРС 102 посылает информацию местоположения на пользовательское оборудование или СУПО. Если СУПО 105 принимает информацию местоположения, он посылает эту информацию местоположения на ФУСВ (элемент 304 на фиг.3), на ПБООП (элемент 305 на фиг.3) или на ШЦММ 106.

Интерфейс Iu преобразует оценки координат мобильного терминала 100 по протоколу прикладной части сети с радиодоступом (ПЧСРД) (RANAP) от каждого КРМС 102 к ЦКМС-3П 104 и СУПО 105, а относящиеся к определению местоположения мобильного терминала 100 сообщения поддержки сетевых приложений (NAS), в том числе сообщения пейджинга, аутентификации и т.п. - по протоколу RANAP. Этот интерфейс также отображает атрибуты качества услуги (QoS) для услуги местоположения и управляет информацией состояний между УНСРД 103 и ЦКМС-3П 104.

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

Внешний сервер может запрашивать ШУПО (элемент 303 на фиг.3), чтобы он обеспечил идентичность после данного динамического ИП адреса. ШУПО 303 может отображать динамический ИП адрес в номер ЦКМС-3П, который используется внешним сервером, чтобы определить местоположение мобильного терминала 100 посредством обычных способов определения местоположения. Альтернативно, можно резервировать номер ИП порта для использования запроса размещения в мобильном терминале 100. Внешнее приложение может затем использовать динамический ИП адрес и известный (стандартизованный) номер порта для доставки запроса на определение местоположения в мобильный терминал 100. Мобильный терминал 100 затем запрашивает свое собственное положение через процедуры обычного определения местоположения и доставляет результат во внешний терминал.

Другим полностью новым функциональным блоком является шлюзовой центр мобильного местоположения (ШЦММ) (GMLC) 106, который действует как шлюз между клиентами услуги местоположения (УМП) (LCS), такой как ПБООП 305, и остальной сетью. ШЦММ 106 принимает и обрабатывает запросы услуги на информацию местоположения для указанного мобильного терминала 100 от внешних клиентов УМП, активирует системы определения местоположения, если это необходимо, и возвращает результат клиенту УМП. ШЦММ 106 может запросить маршрутизацию информации от РСМ 107 или СУПО 105. После выполнения проверки подлинности регистрации он посылает запрос на определение местоположения и принимает конечные оценки местоположения от ЦКМС-3П 104 и СУПО 105.

Регистр 107 собственного местоположения (РСМ) (HLR) содержит абонентские данные об услугах местоположения и информацию маршрутизации, касающуюся абонентских вызовов. Доступ к РСМ 107 может осуществляться от ШЦММ 106 через интерфейс подсистемы (мобильной связи (ПМС) (МАР).

ПБООП 305 является предпочтительно традиционным ПБООП и может соединяться с ШЦММ 106 через КТСОП. Внешние клиенты 108 УМП могут быть любым типом приложения услуги, предлагаемого сервисным провайдером или контентным провайдером. Клиент 108 УМП тесно связан с разнообразными доступными услугами. Иногда мобильный терминал 100 или сервисное приложение мобильного терминала 100 является клиентом. Кроме того, для изменений в основных интерфейсах (например, Uu, Iub, Iur или Iu) сети имеются также несколько интерфейсов, определенных для поддержки услуг местоположения. Интерфейс Le обеспечивает опорную точку для преобразования информации, переданной между ШЦММ 106 и ПБООП 305 и другими внешними клиентами 108 УМП. Эта информация включает в себя запрос на определение местоположения и конечный результат процесса определения местоположения.

Интерфейс Lh пропускает информацию маршрутизации от РСМ 107 к ШЦММ 106 и поддерживает любую связанную с управлением мобильностью базу данных в РСМ 107. Его также можно использовать ШЦММом 106 для запрашивания адреса посещаемого ЦКМС или СУПО для конкретного мобильного терминала 100, местоположение которого запрошено. Это предпочтительно интерфейс типа ПМС и он может воплощаться по сети сигнализации SS7 или, возможно, по ИП протоколу (ПМС по ИП). Интерфейс Lg позволяет ЦКМС-3П 105 обращаться к ШЦММ 106 (собственная НСМО или посещаемая НСМО). Этот интерфейс преобразует абонентскую информацию, необходимую, к примеру, для проверки прав доступа и маршрутизации доступа на определение местоположения. Он может использоваться ШЦММом 106, чтобы направить запрос местоположения в ЦКМС или СУПО, обслуживающие в данный момент конкретный мобильный терминал 100, местоположение которого запрашивалось, или ЦКМСом или СУПОм для возвращения результатов определения местоположения в ШЦММ 106. Это предпочтительно интерфейс типа ПМС и он может воплощаться по сети сигнализации SS7 или, возможно, по ИП протоколу (ПМС по ИП).

Интерфейс Lg' позволяет СУПО 105 обращаться к ШЦММ 106 (собственная НСМО или посещаемая НСМО). Он может быть идентичным интерфейсу Lg, но он помечен иначе на фиг.1, чтобы показать, что он также может и отличаться. Этот интерфейс преобразует абонентскую информацию, необходимую, к примеру, для проверки прав доступа и маршрутизации доступа на определение местоположения. Это предпочтительно интерфейс типа ПМС и он может воплощаться по сети сигнализации SS7 или, возможно, по ИП протоколу (ПМС по ИП). Предпочтительно, интерфейсы ПМС, насколько это возможно, аналогичны интерфейсам ПМС, определенным для услуг местоположения в сети GSM. Вследствие того, что в УСМС нет обслуживающего ЦММ (ОЦММ), интерфейс ПМС между ОЦММ и посещаемым ПЦММ не нужен. Услуги местоположения для GSM все же не включают в себя ОУПР, так что часть ОУПР сети УСМС добавляется к сигнализации ПМС. Пригодно использовать тот же самый интерфейс МПЧ между ШЦММ 106 и СУПО-3П 105, и между ШЦММ 106 и ЦКМС-3П 104.

Фиг.2 является дополнительной блок-схемой, показывающей соединения с другими сетями и, в частности, шлюзовой узел поддержки ОУПР (ШУПО) 108 и функцию 109 управления состояниями вызова (ФУСВ).

Фиг.3 представляет собой упрощенную блок-схему, показывающую соединения между функциями сетевых элементов и, в частности, шлюзовым узлом 303 поддержки ОУПР (ШУПО) и функцией 304 управления состояниями вызова (ФУСВ). На фиг.3 показан также пункт 305 безопасного ответа общего пользования (ОПБО), с которым соединяются экстренные вызовы через ФУСВ 304 согласно примерам осуществления способа, описанным ниже.

ШУПО 303 и ФУСВ 304 представляют собой инструменты в воплощении примерных механизмов, проиллюстрированных на фиг.4-11, для надежной передачи экстренных вызовов к соответствующему ПБООП без неверного использования или подлога. В нижеследующем описании примерных вариантов выполнения ШУПО 303 и ФУСВ 304 являются элементами, расположенными в сети, которую посещает абонент. Они используют контекст ППД сигнализации в сетях ИПТМ третьего поколения. Хотя это и не показано на фиг.1-3, ради ясности следует понимать, что может быть множество различных ФУСВ и соединенных ПБООП. Предпочтительно, каждая ФУСВ 304 поддерживает базу данных соединенных ПБООП (или эквивалентную способность), которая включает в себя соответствие между ПБООП для каждого кода идентификации зоны обслуживания (ИЗО), который она может принимать для экстренных вызовов, таких как в одном из примерных вариантов выполнения способа, описанных ниже. Когда ФУСВ принимает код ИЗО в запросе на установление экстренного вызова, она соединяет этот экстренный вызов с ПБООП на основании, по меньшей мере частично, соответствия между эти кодом ИЗО и ПБООП, запомненными в базе данных. Выбор подходящего ПБООП посредством ФУСВ может в конечном счете определяться и иными факторами в дополнение к коду ИЗО. К примеру, баланс нагрузки или другие процедуры могут воздействовать на выбор ПБООП для того, чтобы попытаться гарантировать, что на экстренный вызов может быть должным образом отвечено на ПБООП, с которым он соединяется.

Спецификации для сети УСМС реализованы проектом партнерства третьего поколения (www.3gpp.org). Выпуск 1999 года предусматривает, что сетевой абонент может иметь один или несколько адресов протокола пакетных данных (ППД) (PDP). Описание общей услуги пакетной радиосвязи (ОУПР), стадия 2, 3G TS 23.060, версия 3.3.0, включено сюда поэтому в качестве ссылки. Каждый адрес ППД описывается одним или более контекстами ППД в мобильном терминале (МТ) 100, СУПО 105 и ШУПО 303. Каждый контекст ППД может иметь информацию передачи и отображения для направления передачи данных к связанному адресу ППД и от него, и шаблон потока трафика (ШПТ) (TFT) для фильтрации переданных данных.

Каждый контекст ППД можно выборочно и независимо активировать, модифицировать и деактивировать. Состояние активации контекста ППД указывает, разрешен ли перенос данных для соответствующего адреса ППД и ШПТ. Если контексты ППД, связанные с одним и тем же адресом ППД, активируются или деактивируются, то перенос всех данных для такого адреса ППД запрещен. Все контексты ППД абонента связываются с одним и тем же контекстом управления мобильностью (УМ) (ММ) для международного идентификационного номера оборудования мобильного абонента (МИНОМА) (IMSI) этого абонента.

Хотя выше описана сетевая поддержка для услуг местоположения, изобретение не зависит от какого-либо конкретного способа определения местоположения и может использоваться как родовое с любым стандартизованным или частным способом определения местоположения. Предпочтительно, способы определения местоположения и способности сетевых услуг местоположения, использованные в примерных вариантах осуществления изобретения для поддержки и маршрутизации экстренного вызова к ПБООП, являются теми же самыми способами определения местоположения и способностями сетевых услуг местоположения, использованных для других клиентов услуг местоположения. Число различных вариантов осуществления способа, отличающихся в первую очередь в процессе определения местоположения, описываются ниже со ссылкой на архитектуру сети, показанную на фиг.1 и 3. Эти варианты осуществления способа представляют собой просто неограничивающие иллюстративные примеры, а сеть является просто неограничивающим иллюстративным примером сети, в которой могут реализоваться варианты осуществления способа. Разумеется, могут быть и иные варианты осуществления способа и иные сети, в которых могут осуществляться эти способы.

Фиг.4 показывает применение процедуры активации контекстов ППД сети УСМС в примере осуществления изобретения, где абонент имеет модуль идентификации абонента (МИА). Во-первых, мобильный терминал 100 инициирует активацию контекстов ППД. Например, абонент может набирать номер 9-1-1. Сообщение "Активировать запрос контекстов ППД", посланное в СУПО 105 при операции 1, включает в себя несколько параметров. Эти параметры включают в себя адрес ППД и наименование пункта доступа (НПД) (APN). Адрес ППД используется, чтобы указать, требуется ли статический или динамический адрес ППД. НПД традиционно представляет собой логическое имя, ссылающееся на подлежащий использованию ШУПО. Этот ШУПО является шлюзом к подсоединенным внешним сетям. В данном примере осуществления изобретения НПД используется вместо этого для указания того, что требуемой услугой является экстренный вызов.

При операции 2 СУПО 105 выбирает подходящий ШУПО 103 согласно НПД и посылает сообщение "Создать запрос контекстов ППД" на выбранный ШУПО 303. ШУПО 303 решает, принять или отклонить этот запрос. Если он принимает запрос, ШУПО 303 устанавливает шаблон потока трафика (ШПТ), чтобы разрешить передавать в контексте ППД только относящийся к трафику экстренный вызов. Например, для нормальных вызовов и для экстренных вызовов можно использовать отдельный ИП адрес или номер порта, и ШУПО 303 может установить ШПТ согласно информации на ИП адресе или номере порта.

Если ШУПО 303 принимает запрос, он модифицирует свою таблицу контекстов ППД и при операции 3 возвращает на СУПО 105 сообщение "Создать ответ контекста ППД". Оно включает в себя адрес подходящей ФУСВ 304 в сообщении "Создать ответ контекста ППД". Предпочтительно, адрес ФУСВ 304 посылается в параметре опций конфигурации протокола, но может также быть послан в другом параметре или в качестве нового параметра.

Если адрес ФУСВ 304 присутствует в сообщении "Создать ответ контекста ППД", СУПО 105 копирует его в сообщение "Активировать прием контекста ППД", направляемое к МТ 100 при операции 4. МТ 100 должен соединиться с ФУСВ 304, определенной при операции 4. МТ 100 может послать информацию местоположения к ФУСВ 304 при операции 5. Если по какой-то причине адрес ФУСВ 304 не посылается в МТ 100, ШУПО 303 может потребоваться изменить назначение ИП адреса в сообщении на установление вызова для того, чтобы использовать локальную ФУСВ для экстренного вызова. Это показано как операция 5 на фиг.4. Для реального речевого трафика может потребоваться вторичный контекст ППД с соответственно отличным качеством услуги (QoS). Если нужно, МТ 100 инициирует активацию вторичного контекста ППД.

Предпочтительно, запрос установления вызова, посланный при операции 5 на фиг.4, включает в себя идентификатор зоны обслуживания (ИЗО) для МТ 100. Этот идентификатор зоны обслуживания используется, чтобы уникальным образом идентифицировать зону, состоящую из одной или нескольких сотовых ячеек, принадлежащих одной и той же зоне местоположения, и чтобы указать это местоположение МТ 100. Код зоны обслуживания (КЗО) (SAC) вместе с идентификацией НСМО и LAC составляет идентификацию зоны обслуживания: ИЗО = МСС + MNC + LAC + SAC. См. описание услуг общей услуги пакетной радиосвязи (ОУПР), стадия 2, 3G TS 23.060, версия 3.3.0, секция 14.10. ФУСВ 304 использует код ИЗО, по меньшей мере частично, чтобы выбрать подходящий ПБООП, к которому подсоединяется экстренный вызов.

Пример осуществления по фиг.5 по существу тот же самый, что и изложенный выше в отношении фиг.4, за исключением того, что он выполняется для абонента без модуля идентификации абонента (МИА). В этом случае пользовательское оборудование посылает сообщение "Активировать запрос контекста ППД с анонимным доступом (АД) (АА). Остальная часть этой процедуры показана на фиг.4.

Другой пример осуществления, в котором вычисление местоположения запускается экстренным вызовом, иллюстрируется на фиг.6. Как и другие примерные варианты осуществления, выполнение по фиг.6 получает преимущество от контекста ППД, доступного в сетях УСМС. В частности, он может использовать параметр НПД сообщения "Активировать запрос контекста ППД", чтобы указать, что вызов должен обслуживаться как экстренный вызов, как указано при операции 2. Однако, в отличие от других примерных вариантов осуществления, МТ 100 посылает сообщение "Установить режим запроса услуги" перед посылкой сообщения "Активировать запрос контекста ППД", как указано при операции 1. Сообщение "Установить режим запроса услуги" посылается, чтобы установить надежное соединение сигнализации.

Основное свойство примерного варианта осуществления по фиг.6 состоит в том, что СУПО 303 посылает сообщение "Управление извещением о местоположении" в КРС 102 в ответ на экстренный вызов. Конкретно, СУПО 303 может инициировать процедуру извещения о местоположении при операции 3 сразу по получении сообщения "Установить режим запроса услуги", где параметр "Тип услуги" указывает на экстренный вызов, или запрос для активации контекста ППД ("Активировать запрос контекста ППД", "Активировать вторичный запрос контекста ППД" или "Активировать запрос контекста ППД с АД"), где параметр НПД указывает на экстренный вызов. Это свойство имеет преимущество в том, что услуги местоположения быстро выполняются для экстренных вызовов, но не являются излишне выполняемыми для других типов вызовов.

КРС 102 реагирует для вычисления информации местоположения для МТ 100 при операции 4. Местоположение МТ 100 сообщается СУПО 303 при операции 5 и передается к ШЦММ 106 при операции 6. Подтверждение извещения о местоположении посылается назад к СУПО 105 при операции 7, а затем информация местоположения при операции 8 передается к ПБООП, выбранному ФУСВ 304 либо по запросу, либо независимо.

Фиг.7 иллюстрирует примерный вариант осуществления способа, аналогичный варианту осуществления по фиг.6, за исключением того, что мобильный терминал 100 (названный "ПО" - пользовательское оборудование - на фиг.7-11) не посылает сообщения "Установить режим запроса контекста" до посылки сообщения "Активировать запрос контекста ППД" при операции 1. СУПО 303 посылает сообщение управления извещением о местоположении (операция 2), как только он принимает процедуру активации контекста ППД (операция 1), чтобы запросить идентификатор зоны обслуживания от сети с радиодоступом (УНСРД в примерной сети по фиг.1 и 2) и начать процедуру определения местоположения (операция 4'). Это можно, но не требуется, сделать путем посылки двух отдельных сообщений управления извещением о местоположении, чтобы запросить идентификатор зоны обслуживания и начать определение местоположения согласно нынешнему описанию RANAP (3G TS 25.413). Для экстренного вызова может быть выделен временный идентификатор домена коммутации пакетов (ИДКП) (PSDI). Такой идентификатор может быть, к примеру, ИП адресом службы управления, PTMSI или международным номером цифровой сети с интегрированными услугами для мобильной станции (MSISDN). СУПО 303 назначает также идентификатор домена коммутации пакетов экстренному вызову, который используется для идентификации (например, маршрутизации к нему) как провайдера экстренных услуг, так и коммутатора в VPLNIN, обслуживающем в данный момент абонента, делающего экстренный вызов, а, возможно, и абонента, делающего экстренный вызов, на длительность этого вызова.

Выполняя определение местоположения, СРД 103 возвращает идентификатор зоны обслуживания к СУПО 303 (операция 3). СУПО 105 посылает сообщение "Создать запрос контекста ППД" на ШУПО 303, как описано выше в отношении фиг.3 (операция 4). ШУПО 303 принимает запрос, модифицирует свою таблицу контекстов ППД и возвращает сообщение "Создать запрос контекста ППД" (включая и адрес подходящей ФУСВ) к СУПО 105 (операция 5). СУПО копирует адрес ФУСВ в сообщение "Активировать прием контекста ППД", направляемом на МТ 100 вместе с идентификатором зоны услуги и телефонным номером ИДКП, назначенным для экстренного вызова (фиг.6).

Когда определение местоположения завершено, СРД 103 возвращает оценку местоположения в сообщении извещения о местоположении к СУПО 105 (операция 6'). СУПО 105 передает извещение о местоположении абонента (которое включает в себя оценку местоположения, идентификатор (МИНОМА или ИП адрес) и ИДКП) к ШЦММ 106 (операция 7'). Предпочтительно, оценка местоположения связывается с временной меткой, которые вместе помечают "начальное местоположение" МТ 100. После того, как был активирован контекст ППД, МТ 100 посылает сообщение приглашения (содержащее идентификатор зоны обслуживания, идентификатор и PSSDI) к ФУСВ 304 (операция 7). На основании, по меньшей мере частично, идентификатора зоны обслуживания ФУСВ 304 выбирает подходящий ПБООП (предпочтительно с помощью базы данных ПБООП и их соответствия идентификаторам зоны обслуживания) и посылает сообщение на установление (содержащее ИДКП) к ПБООП 305 (фиг.7-11 называют ПБООП как ЭЦ (экстренный центр), а не ПБООП) (операции 8 и 9).

Как только экстренный вызов соединяется, выбранный ПБООП посылает запрос услуг УМП на ШЦММ 106, чтобы получить начальное местоположение, и ШЦММ 106 посылает запрос услуг УМП, содержащий начальное местоположение (операции 10 и 11). Экстренный вызов идентифицируется в этом запросе и в ответе его ИДКП. Аналогично, в течение всей длительности экстренного вызова выбранный ПБООП может запрашивать и принимать обновления на текущее местоположение мобильного терминала 100 с помощью обычных запросов конечного местоположения мобильного терминала (MT-LR), определенных в 3G TS 23.171, версия 3.0.0 (выпуск 1999 года). Фиг.8 иллюстрирует способ, аналогичный способу на фиг.7, за исключением того, что процедура определения местоположения заканчивается и получают оценку местоположения до приема активации контекста ППД. Операции 1-4 те же самые, что и для способа по фиг.7. Однако СУПО 105 принимает извещение о местоположении (операция 5'), содержащее оценку местоположения, от СРД 103 до того, как ШУПО 303 возвратит сообщение "Создать запрос контекста ППД" к СУПО 105 (операция 6).

Вместо того, чтобы направить оценку местоположения к ШЦММ 106 в извещении местоположения абонента (операция 7' на фиг.6), СУПО 105 включает оценку местоположения в сообщение "Активировать прием контекста ППД", направляемое к МТ 100 вместе с идентификатором зоны обслуживания, ИДКП и адресом ФУСВ (операция 7). МТ 100, в свою очередь, включает оценку местоположения (вместе с идентификатором зоны обслуживания, идентификатором и ИДКП) в сообщение приглашения, посланное к ФУСВ 304 (операция 8). После выбора ПБООП (операция 9) ФУСВ 304 включает оценку местоположения в сообщение на установление, посланное на ПБООП 305 (вместо ИДКП). Это исключает необходимость в двух операциях для ПБООП 305 на запрос и прием начального местоположения от ШЦММ 106 (операции 10 и 11 на фиг.7), когда соединяется экстренный вызов. Разумеется, выбранный ПБООП может продолжать запрашивать и принимать обновления на текущее местоположение МТ 100 таким же образом, как и в примерном варианте осуществления по фиг.7 (операции 11-13).

Фиг.9 иллюстрирует выполнение способа, аналогичное выполнению по фиг.7 и 8, за исключением того, что СРД 103 предоставляет оценку местоположения на МТ 100 вместо того, чтобы делать запрос местоположения на СУПО 105. Операции 1-6 в выполнении по фиг.9 такие же, как и операции 1-6 в выполнении по фиг.7. МТ 100 должен принимать оценку местоположения от 103 таким же образом, возможно, но не необходимо, с помощью сообщений управления радиоресурсами. Способ, которым оценка местоположения сообщается от СРД 103 (согласно либо выполнению по фиг.7, либо выполнению по фиг.9) может быть задан заранее или он может управляться, к примеру, в сообщении извещения о местоположении, посланном СУПО 105 к СРД 103 при операции 2.

В примерном варианте осуществления по фиг.9 процедура определения местоположения должна заканчиваться до того, как сообщение "Активировать прием контекста ППД" принимается на МТ 100 при операции 6. Если это не так, то МТ 100 задерживает сообщение приглашения до тех пор, пока не будет принята оценка местоположения от СРД 103. Когда оценка местоположения принимается, МТ 100 посылает сообщение приглашения (содержащее идентификатор зоны обслуживания, оценку местоположения и идентификатор) к ФУСВ 304 (операция 7). Остальные операции в примерном варианте осуществления по фиг.9 (операции 8-12) такие же, как операции 9-13 по фиг.7.

Фиг.10 иллюстрирует примерный вариант осуществления, аналогичный варианту по фиг.7, за исключением того, что СУПО 105 всегда знает текущий идентификатор зоны обслуживания, когда принимает сообщение "Активировать запрос контекста ППД" при операции 1. В таком выполнении СУПО 105 не нуждается в запрашивании идентификатора зоны обслуживания от СРД 103, а СРД 103 не требуется возвращать идентификатор зоны обслуживания, как при операциях 2 и 3 по фиг.4. Остальные операции в варианте осуществления по фиг.10 такие же, как и остальные операции на фиг.7.

Примерный вариант осуществления, проиллюстрированный на фиг.11, существенно отличается от других примерных вариантов осуществления постольку, поскольку МТ 100 сам начинает способ определения местоположения (операция 2'), как только получает от СУПО 105 сообщение "Активировать запрос контекста ППД" (операция 1). Он может либо выполнять свое основанное на МТ вычисление местоположения, либо запросить, чтобы способ определения местоположения выполнялся с помощью процедур запросов местоположения, начинаемых мобильным терминалом (MO-LR). Примерный вариант осуществления по фиг.11 тем самым избегает необходимости в сообщении управления извещением о местоположении от СУПО 105 или в извещении местоположения от СРД 103. Это также упрощает сообщение "Активировать прием контекста ППД", посланный от СУПО 105, поскольку оно нужно только, чтобы содержать адрес ФУСВ (операция 4). Аналогично, сообщение приглашения, посланное от МТ 100 к ФУСВ 304, нужно только, чтобы содержать оценку местоположения и идентификатор зоны обслуживания (операция 6). Зоны обслуживания должны быть скоординированы между МТ 100 и СУПО 105 для того, чтобы гарантировать, что идентификатор зоны обслуживания, предоставленный МТ 100, соответствует идентификатору зоны обслуживания, ожидаемому СУПО 105 и ФУСВ 304. Остальные операции в примерном варианте осуществления по фиг.11 (операции 7-11) такие же, как операции 9-13 на фиг.9.

Примерные варианты осуществления по фиг.7-11 показывают разные способы, каждый со своими преимуществами и недостатками. Например, в примерных вариантах осуществления по фиг.7 и 10 экстренный вызов может быть соединен, не обращая внимания на задержки в процедурах определения местоположения, потому что начальное местоположение доставляется от ШЦММ 106 по запросу от ПБООП 305 после того, как экстренный вызов соединяется. В примерном варианте осуществления по фиг.10 МТ 100 должен иметь модуль идентификации абонента (МИА), чтобы взаимодействовать с ФУСВ 304.

Хотя выше описано то, что рассматривается как примерные варианты осуществления изобретения, понятно, что в нем можно сделать различные модификации и что изобретение можно воплотить в различных формах и вариантах осуществления, и что его можно применить к многочисленным приложениям, и лишь некоторые из них описаны здесь. К примеру, ИЗО можно сделать доступным непосредственно для мобильного терминала самой СРД 103 вместо - или в дополнение к - СУПО в сообщении принятия контекста ППД. Например, КРС 102 может делать ИЗО непосредственно доступным для сообщений, передаваемых по радио, и/или RRC от пункта к пункту. Последующая формула изобретения предназначена для того, чтобы охватить все такие модификации и варианты.

Изобретение относится к телефонной связи. Экстренный телефонный вызов поддерживается и маршрутизируется к пункту безопасного ответа общего пользования (ПБООП) в основанной на Интернет-протоколе (ИП) беспроводной сети связи с коммутацией пакетов. Сообщение «Активировать запрос контекста протокола пакетных данных (ППД)» посылается от пользовательского оборудования в сеть. Параметр в сообщении «Активировать запрос контекста ППД» указывает, что этот контекст ППД будет использоваться для передачи экстренного вызова. Сообщение «Активировать принятие контекста ППД» возвращается от узла поддержки к пользовательскому оборудованию. Сообщение «Активировать принятие контекста ППД» подтверждает прием сообщения «активировать запрос контекста ППД» и предоставляет адрес функции управления состояниями вызова. Запрос на установление вызова, переданный к функции управления состояниями вызова, включает в себя идентификатор зоны обслуживания (ИЗО). Функция управления состояниями вызова выбирает ПБООП на основании, по меньшей мере частично, этого ИЗО, включенного в запрос на установление вызова, и направляет экстренный вызов к выбранному ПБООП. Техническим результатом является поддержка выбора ПБООП в ИП сетях мобильной связи третьего поколения, основанных на стандарте универсальной системы мобильной связи. 5 н. и 22 з.п. ф-лы. 11 ил.

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

2. Способ по п.1, дополнительно включающий:
определение идентификатора объекта в указанном втором сетевом элементе и
передачу указанного идентификатора пользовательскому оборудованию.

3. Способ по п.2, дополнительно включающий:
возвращение сообщения о принятии от указанного первого сетевого элемента к указанному пользовательскому оборудованию, причем упомянутое сообщение о принятии подтверждает прием упомянутого первого запроса, и
предоставление адреса объекта пользовательскому оборудованию.

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

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

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

7. Способ по п.1, отличающийся тем, что указанный второй сетевой элемент представляет собой шлюзовой узел поддержки (GGSN) общей услуги пакетной радиосвязи (GPRS).

8. Способ по п.1, отличающийся тем, что указанный первый сетевой элемент представляет собой сервисный узел поддержки (SGSN) общей услуги пакетной радиосвязи (GPRS).

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

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

11. Способ по п.10, отличающийся тем, что упомянутый параметр представляет собой упомянутое указание.

12. Способ по п.10, отличающийся тем, что упомянутый параметр в упомянутом первом запросе представляет собой наименование пункта доступа (APN).

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

14. Способ по п.13, отличающийся тем, что информация местоположения представляет собой идентификатор зоны обслуживания (SAI), идентификатор зоны маршрутизации (RAI), идентификатор сотовой ячейки, координатную информацию или их комбинацию.

15. Способ по п.2, отличающийся тем, что упомянутый объект включает объект, управляющий экстренными вызовами.

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

17. Способ по п.5, отличающийся тем, что упомянутый объект вычисления местоположения представляет собой контроллер радиосети (RNC).

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

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

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

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

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

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

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

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

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

27. Способ по п.23, отличающийся тем, что определение местоположения выполняют в первом сетевом элементе.