ЭФФЕКТИВНАЯ ПЕРИОДИЧЕСКАЯ ПЕРЕДАЧА ОТЧЕТОВ О МЕСТОПОЛОЖЕНИИ В СЕТИ РАДИОДОСТУПА

Настоящая заявка на патент испрашивает приоритет предварительной заявки на патент США с порядковым номером №60/693003, озаглавленной "METHOD AND APPARATUS FOR PROVIDING LOCATION SERVICES WITH SHORT-CIRCUITED MESSAGE FLOWS" (Способ и устройство обеспечения услуг определения местоположения в сети радиодоступа), поданной 21 июня 2005; заявки на патент США с порядковым номером № 60/711801, озаглавленной "EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK" (Способ и устройство периодической передачи отчетов о местоположении в сети радиодоступа), поданной 25 августа 2005; заявки на патент США с порядковым номером № 60/718112 озаглавленной "EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK", поданной 16 сентября 2005; заявки на патент США с порядковым номером № 60/771180, озаглавленной "EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK", поданной 6 февраля 2006; заявки на патент США с порядковым номером № 60/771217, озаглавленной "CLARIFICATION AND CORRECTION OF PERIODIC LOCATION PROCEDURE" (Уточнение и поправка процедуры периодического определения местоположения), поданной 7 февраля 2006; заявки на патент США с порядковым номером № 60/771706, озаглавленной "ADDITION OF PERIODIC LOCATION PROCEDURES" (Дополнение процедур периодического определения местоположения), поданной 8 февраля 2006, все переданные правопреемнику по данному изобретению, и тем самым полностью включены путем ссылки.

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

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

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

Поток сообщений (который также может называться потоком вызовов или процедурой) обычно исполняется, чтобы получить оценку местоположения для устройства беспроводной связи и послать эту оценку местоположения на клиентский объект (например, Web-сервер). Различные сообщения обычно обмениваются между одним или несколькими сетевыми объектами, беспроводным устройством и клиентским объектом. Эти сообщения обеспечивают, что каждому объекту предоставлена относящаяся к делу информация, или он может получить эту информацию от другого объекта, чтобы выполнять позиционирование относительно устройства беспроводной связи и/или доставлять оценку местоположения на клиентский объект. Однако эти сообщения добавляют трафик между различными сетевыми объектами. Дополнительный трафик может быть особенно значительным для периодической передачи отчетов о местоположении, которая периодически поставляет оценку местоположения относительно устройства беспроводной связи на клиентский объект. Сообщения могут также увеличивать длительность времени ответа для посылки оценки местоположения на клиентский объект, возможно на недопустимую величину.

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

КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

В настоящем документе описываются способы эффективного обеспечения услуг (ЭОУ, LCS) определения местоположения с использованием возможностей периодических LCS в сети радиодоступа (RAN). Эти способы применяют основывающуюся на RAN периодическую передачу отчетов, чтобы периодически сообщать местоположение устройства беспроводной связи на LCS клиент. Основывающаяся на RAN периодическая передача отчетов о местоположении может быть использована для процедур «завершаемого на мобильном устройстве» запроса (MT-LR) местоположения, «побужденного из сети» запроса (NI-LR) местоположения и «инициированного с терминала» запроса (MO-LR) определения местоположения.

В варианте осуществления периодической передачи отчетов местоположения по запросам MO-LR, беспроводное устройство, взаимодействующее с RAN, посылает на сетевой объект (1) запрос периодической передачи отчетов о местоположении UE на клиентский объект и (2) информацию периодического определения местоположения. Беспроводное устройство связи называется также пользовательским оборудованием (UE), сетевой объект может быть центром коммутации мобильной связи (ЦКМС, MSC) или узлом поддержки (SGSN) обобщенных услуг (GPRS) пакетной радиопередачи, и клиентский объект также называется LCS клиентом. Информация периодического определения местоположения может указывать план сообщаемых событий и/или набор заранее заданных событий, которые запускают (инициируют) передачу отчетов о местоположении. После того как запрос одобрен, MSC/SGSN посылает на RAN сигнализацию, чтобы инициировать периодическую передачу отчетов о местоположении для UE. RAN может запрашивать центр позиционирования (который может быть также назван автономным обслуживающим центром (SAS) определения местоположения мобильного устройства) для посылки на UE данных помощи (в установлении соединения). RAN может координировать и управлять периодической передачей отчетов о местоположении или может передавать управление этим SAS. В любом случае для каждого отчета о местоположении, определенного посредством информации периодического определения местоположения, UE посылает на RAN информацию местоположения. Эта информация местоположения может содержать (1) измерения, выполненные посредством UE для базовых станций и/или спутников или (2) оценку местоположения для UE. Если RAN принимает измерения от UE, то RAN может посылать измерения на SAS, который может вычислить оценку местоположения для UE и вернуть оценку местоположения на RAN. RAN затем посылает оценку местоположения для UE на MSC/SGSN, который пересылает оценку местоположения на LCS клиент. Основывающаяся на RAN периодическая передача отчетов о местоположении сокращает сигнализацию для периодической посылки на LCS клиент оценки местоположения UE, а также обеспечивает более высокое быстродействие при ответе.

Ниже описываются различные потоки сообщений для основывающейся на RAN периодической передачи отчетов о местоположении. Различные аспекты и варианты осуществления изобретения также описаны ниже с дополнительными подробностями.

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

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

Фиг.1A показывает сеть связи на основе 3GPP (Проект партнерства систем связи 3-го поколения).

Фиг.1B показывает развертывание системы на основе 3GPP, которая включает в состав многие сети.

Фиг.2A показывает поток сообщений для периодической передачи отчетов о местоположении для MT-LR.

Фиг.2B показывает поток сообщений для периодической передачи отчетов о местоположении для NI-LR.

Фиг.3 показывает поток сообщений для периодической передачи отчетов о местоположении для MO-LR.

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

Фиг.5 и 6 показывают потоки сообщений для основывающейся на RAN периодической передачи отчетов в режиме «с центральным RNC» (контроллер радиосети) и режиме «с центральным SAS» соответственно.

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

Фиг.8 показывает поток сообщений для основывающейся на RAN периодического автоопределения местоположения для MO-LR.

Фиг.9 и 10 показывают потоки сообщений для основывающейся на RAN периодической передачи отчетов для GERAN в режиме с коммутацией пакетов и режиме с коммутацией каналов соответственно.

Фиг.11 показывает другое развертывание сети связи.

Фиг.12 показывает блок-схемы различных сетевых объектов по фиг.1.

ПОДРОБНОЕ ОПИСАНИЕ

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

Способы периодической передачи отчетов о местоположении, описанные в документе, могут использоваться для различных сетей беспроводной связи, таких как сеть множественного доступа с кодовым разделением каналов (МДКР, CDMA), сеть множественного доступа с временным разделением каналов (МДВР, TDMA), сеть множественного доступа с частотным разделением (МДЧР, FDMA), сеть множественного доступа с ортогональным частотным разделением (МДОЧР, OFDMA), сеть, поддерживающая комбинацию вышеупомянутых технологий, сеть с зоной обслуживания глобальной сети, а также зоной обслуживания локальной сети (БЛВС, WLAN) беспроводной связи и так далее. Сеть CDMA может реализовывать одну или несколько CDMA-технологий радиосвязи, такие как широкополосный CDMA (Ш-МДКР, W-CDMA), cdma2000 и так далее; cdma2000 охватывает стандарты IS-2000, IS-856, и IS-95. Сеть TDMA может реализовывать одну или несколько TDMA-технологий радиосвязи, такие как глобальная система мобильной связи (ГСМС, GSM), цифровая усовершенствованная мобильная телефонная связь (Ц-УМТС, D-AMPS) и так далее. D-AMPS охватывает стандарты IS-36 и IS-54. Данные различные технологии и стандарты радиосвязи являются известными в области техники. W-CDMA и GSM описаны в документах организации, именуемой "Проект партнерства систем связи 3-го поколения" (3GPP); cdma2000 описана в документах организации, именуемой названной "Проект 2 партнерства систем связи 3-го поколения" (GPP2). Документы 3GPP и 3GPP2 являются доступными публично. Для ясности ниже описаны способы для сети на основе 3GPP, которая использует одну или несколько технологий радиосвязи и один или несколько сетевых протоколов, опубликованных 3GPP. Например, сеть на основе 3GPP может быть сетью универсальной системы мобильной связи (УСМС, UMTS), которая использует W-CDMA в качестве технологии радиосвязи для взаимодействия по радиоканалу и прикладную подсистему (MAP) мобильной связи в качестве сетевого протокола для функциональности базовой сети.

На фиг.1A показана сеть 100 на основе 3GPP, которая обеспечивает услуги связи и определения местоположения для устройств беспроводной связи, называемых пользовательским оборудованием (UE) (терминология 3GPP) в нижеследующем описании. Для простоты, только одно устройство UE 120 показано на фиг.1A. UE 120 может быть стационарным или мобильным и может также называться мобильной станцией, терминалом, абонентским устройством или некоторой другой терминологией. UE 120 может также быть телефоном сотовой связи, портативной ЭВМ, персональным цифровым ассистентом (ПЦА, PDA), телеметрическим устройством, устройством слежения и так далее. UE 120 может взаимодействовать с одной или несколькими базовыми станциями в сети (RAN) радиодоступа 130. UE 120 также может принимать сигналы от одного или нескольких спутников 190, которые могут быть частью глобальной системы определения местоположения (GPS), европейской системы Galileo или российской системы Glonass. UE 120 может измерять сигналы от базовых станций в RAN 130 и/или сигналы от спутников 190 и может получать измерения псевдодальности для этих базовых станций и спутников. Эти измерения псевдодальности могут использоваться, чтобы вычислять (выводить) оценку местоположения для UE.

RAN 130 обеспечивает беспроводную связь для устройств UE, расположенных по всей области обслуживания RAN. RAN 130 взаимодействует с центром (MSC) коммутации мобильной связи и/или обслуживающим узлом (SGSN) поддержки GPRS (MSC/SGSN) 140 и взаимодействует также с обслуживающим центром (SMLC) определения местоположения мобильных устройств и/или автономным SMLC (SAS) (SMLC/SAS) 132. MSC 140 выполняет функции коммутации для вызовов с коммутацией каналов (например, установки, маршрутизации и возможного (конечного) разъединения коммутируемых речевых вызовов и запросов данных) для устройств UE в пределах своей области обслуживания. SGSN 140 выполняет функции переключения и маршрутизации для вызовов с коммутацией пакетов и соединений с коммутацией пакетов. SMLC/SAS 132 обеспечивает услуги позиционирования и может поддерживать режимы позиционирования «на основе UE» «с помощью UE» и «на основе сети». Позиционирование относится к функциональности, которая обнаруживает или определяет географическое местоположение целевого UE. SAS может иметь в составе несколько связанных устройств измерения местоположения (LMU) (не показано на фиг.1A), чтобы содействовать некоторым способам позиционирования, например способу позиционирования на основе разности времен поступления сигналов восходящей линии связи (U-TDOA). SMLC может быть физической и/или логической подсистемой RAN или он может быть физически и логически отдельным в случае автономного SMLC (SAS). В любом случае в нижеследующем описании SMLC/SAS 132 рассматривается как отдельный объект, является ли он физически и/или логически частью RAN или отдельным от RAN.

Межсетевой центр (GMLC) 150 определения местоположения мобильного устройства выполняет различные функции, чтобы поддерживать услуги определения местоположения, является интерфейсом с внешними LCS клиентами и обеспечивает услуги такие, как конфиденциальность абонента, авторизация доступа, аутентификация, выписка счетов абонентских услуг и так далее. Регистр (HLR) домашнего местоположения собственных абонентов/сервер (HSS) собственных абонентов 160 хранит регистрационную информацию для устройств UE (например, UE 120), которые являются абонентами сети 100. LCS клиент 170 является функцией или объектом, который запрашивает и/или принимает информацию местоположения относительно LCS-адресатов. LCS-адресат является UE, местоположение которого является искомым. В общем, LCS клиент может постоянно находиться в сетевом объекте или UE или может быть внешним по отношению и к сети, и к UE. LCS клиент 170 взаимодействует с GLMC 150.

Для простоты на фиг.1A показаны сетевые объекты, которые являются подходящими для услуг определения местоположения. Эти сетевые объекты описаны в технических условиях 3GPP TS 23.271, озаглавленных "Functional stage 2 description of Location Services (LCS) (Release 6)" (Функциональное описание стадии 2 услуг (LCS) определения местоположения (Версия 6)), в технических условиях 3GPP TS 25.305, озаглавленных "Stage 2 functional specification of User Equipment (UE) positioning in UTRAN (Release 6)" (Функциональное описание стадии 2 позиционирования пользовательского оборудования (UE) в UTRAN (Версия 6)" и в технических условиях 3GPP TS 43.059, озаглавленных "Functional stage 2 description of Location Services (LCS) in GERAN (Release 6)" (Функциональное описание стадии 2 услуг (LCS) определения местоположения в GERAN (Версия 6)), все из которых являются доступными публично.

На фиг.1A показан случай, в котором UE 120 взаимодействует с единственной сетью (например, опорной (домашней) сетью). Все сетевые объекты в этой сети взаимодействуют через базовую сеть связи и/или другие сети передачи данных (не показано на фиг.1A). UE 120 может быть перемещающимся и может взаимодействовать с различными посещаемыми сетями.

На фиг.1B показано развертывание 101 системы на основе 3GPP, которая включает в состав посещаемую/обслуживающую сеть 102, домашнюю сеть 104 и запрашивающую сеть 106. Посещаемая сеть 102 является сетью, которая в настоящее время является обслуживающей UE 120. Домашняя (опорная) сеть 104 является сетью, с которой UE 120 имеет абонентскую подписку. Запрашивающая сеть 106 является сетью, через которую LCS клиент 170 может создавать запрос о местоположении UE 120 и/или принимать местоположение UE 120. Домашняя сеть 104 может быть одинаковой с посещаемой сетью 102 или отличной от нее и может быть одинаковой с запрашивающей сетью 106 или отличной от нее. Запрашивающая сеть 106 может также быть одинаковой с посещаемой сетью 102 или отличной от нее. Каждая сеть может называться наземной сетью (PLMN) мобильной связи общего пользования.

Для показанного на фиг.1B варианта осуществления посещаемая сеть 102 включает в состав соответствующую второму поколению (2G) сеть 130a (GERAN) радиодоступа с возможностями EDGE GSM (система беспроводной связи с передачей данных в сетях GSM) и универсальную наземную сеть 130b (UTRAN) радиодоступа третьего поколения (3G). GERAN 130a взаимодействует с 2G-SGSN 140a и/или 2G-MSC 140b. GERAN 130a также может взаимодействовать с 3G-SGSN 140c и/или 3G-MSC 140d. UTRAN 130b взаимодействует с 3G-SGSN 140c и/или 3G-MSC 140d. Каждый MSC может действовать в качестве посещаемого MSC (VMSC) и 3G-MSC 140d может быть сервером MSC. Посещаемый GMLC (V-GMLC) 150a поддерживает услуги определения местоположения для посещаемой сети 102 и взаимодействует с несколькими MSC 140b и 140d и SGSN 140a и 140c. SMLC/SAS 132 обеспечивает услуги позиционирования и может взаимодействовать с GERAN 130a, UTRAN 130b, 2G-MSC 140a и так далее.

Домашняя сеть 104 включает в себя GMLC (H-GMLC) 150b и HLR/HSS 160 собственных абонентов. H-GMLC 150b поддерживает услуги определения местоположения для домашней сети 104. HLR/HSS 160 хранит регистрационную информацию для устройств UE, которые являются абонентами домашней сети 104. Запрашивающая сеть 106 включает в состав запрашивающий (R-GLMC) 150c, который поддерживает услуги определения местоположения для запрашивающей сети 106. Хотя не показано на фиг.1B, R-GLMC 150c и/или H-GLMC 150b могут взаимодействовать непосредственно с SGSN 140a, MSC 140b, SGSN 140c и/или MSC 140d в посещаемой сети 102 через соответствующие интерфейсы.

Сетевые объекты на фиг.1A и 1B могут также обозначаться другими именами в других сетях и других архитектурах определения местоположения. Например, в архитектуре защищенного определения местоположения (SUPL) плоскости пользователя, опубликованной Открытым союзом (OMA) по мобильной связи, LCS клиент иногда именуется агентом SUPL, GLMC называется центром SUPL-определения местоположения (SLC), UE, который поддерживает SUPL, называется терминалом (SET) с поддержкой SUPL и SLMC называется центром SUPL-позиционирования (SPC). Функции и сигнализация, выполняемая этими SUPL-именованными объектами, не являются точно такими же, как таковые, выполняемые соответствующими 3GPP-именованными объектами, но в общих чертах сходны и допускают совместимые услуги и возможности. GLMC может также называться центром определения местоположения, LCS-сервером, сервером определения местоположения, центром (MPC) позиционирования мобильных устройств и так далее. SMLC может также называться объектом позиционирования, центром позиционирования, объектом (PDE) определения позиции и так далее. В целом, каждая сеть может включать в себя любую совокупность сетевых объектов, которые могут обеспечивать любой объем услуг. Для ясности многое из нижеследующего описания предназначено для сети 100 на основе 3GPP по фиг.1A.

Местоположение UE 120 может запрашиваться посредством (1) приложений (Apps), исполняющихся в UE, что имеет следствием инициированный мобильным устройством запрос (MO-LR) местоположения, (2) приложений, исполняющихся в LCS-клиенте 170, что имеет следствием завершаемый на мобильном устройстве запрос (MT-LR) местоположения, и (3) приложений, исполняющихся в рамках любого из PLMN-объектов, обслуживающих целевое UE (например, 2G-SGSN 140a, 2G-MSC 140b, 3G-SGSN 140c или 3G-MSC 140d на фиг.1B), что имеет следствием побужденный из сети запрос местоположения (NI-LR). Местоположение UE 120 может запрашиваться один раз, что имеет следствием однократный или немедленный отчет о местоположении, или многократный с помощью одиночного запроса, что имеет следствием периодическую передачу отчетов о местоположении. Периодическая передача отчетов о местоположении может выполняться с помощью периодического потока сообщений для MT-LR, периодического потока сообщений для NI-LR или периодического потока сообщений для MO-LR. Периодическая передача отчетов о местоположении поставляет оценку местоположения относительно целевого UE на LCS

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

Оценка местоположения для UE 120 может быть получена с использованием режимов позиционирования «на основе UE», «с помощью UE» или «на основе сети». Для режима «на основе UE» местоположение UE определяется посредством UE, возможно вместе с данными помощи от SMLC, GERAN или UTRAN. Для режима «с помощью UE» местоположение UE определяется посредством SMLC с помощью (например, измерений) от UE. Для режима «на основе сети» местоположение UE определяется на основании информации, полученной посредством сети или уже известной ей без какие-либо специальной помощи от UE. Для режима «на основе сети» местоположение UE может быть определено посредством измерений в восходящей линии связи, выполненных на одном или нескольких LMU или базовых станций.

Режимы «на основе UE» и «с помощью UE» могут использовать различные способы определения местоположения, такие как GPS, «с содействующей GPS» (A-GPS), гибридный, расширенная трилатерация по прямому каналу связи (A-FLT), усовершенствованный способ наблюдаемой разности времен поступления сигналов (E-OTD), наблюдаемая разность времен поступления сигналов (Observed Time Difference Of Arrival based on Idle Period DownLink, OTDOA) и так далее. Режим «на основе сети» может использовать различные способы определения местоположения, такие как по времени поступления сигналов по восходящей линии связи (U-TOA), разность времен поступления сигналов в восходящей линии связи (U-TDOA), cell-ID (идентификация сотовой ячейки), усовершенствованный способ cell-ID и так далее. Ряд способов определения местоположения для одного или несколько режимов позиционирования также могут использоваться в комбинации. Способы GPS и A-GPS вычисляют оценку местоположения для UE на основании только спутниковых измерений и имеют высокую точность. Гибридный способ вычисляет оценку местоположения на основании и спутниковых измерений и измерений базовой станции и имеет высокую точность и высокую надежность. Способы A-FLT, E-OTD и OTDOA выводят оценку местоположения на основании выполненных посредством UE измерений временной диаграммы базовой станции и имеют в большей степени промежуточную точность. Способы U-TOA и U-TDOA вычисляют оценку местоположения на основании измерений временной диаграммы UE, выполненных сетью, и имеют в большей степени промежуточную точность. Способы cell-ID и усовершенствованный cell-ID вычисляют оценку местоположения на основании сотовой сети и имеют более грубую точность. Эти различные способы определения местоположения являются известными в области техники.

Различные потоки сообщений для поддержки периодической передачи отчетов о местоположении UE на LCS клиент 170 описаны ниже для сети 100 на основе 3GPP по фиг.1A. Эти потоки сообщений дают возможность базовой сети (например, MSC/SGSN 140) вызывать на исполнение и использовать возможности периодических услуг LCS в RAN 130, чтобы эффективно обеспечивать основывающуюся на RAN периодическую передачу отчетов о местоположении. Основывающаяся на RAN периодическая передача отчетов о местоположении относится к периодической передаче отчетов о местоположении, которая координируется и управляется посредством RAN, в отличие от MSC/SGSN, UE или GMLC.

На фиг.2A показан вариант осуществления потока 200 сообщений для MT-LR периодической передачи отчетов о местоположении. Для потока 200 сообщений LCS клиент 170 посылает на GMLC 150 сообщение LCS Service Request (Запрос услуги LCS), которое содержит (1) запрос периодической передачи отчетов о местоположении целевого UE 120 на LCS-клиент 170 (то есть периодический запрос местоположения) и (2) информацию периодического определения местоположения ("periodic loc info") (этап 1). GMLC 150 может проверять идентификационную информацию LCS клиента 170, может аутентифицировать LCS клиента и может определять, авторизован ли LCS клиент для запрошенной услуги определения местоположения. Если LCS-клиент 170 авторизован, то GMLC 150 (1) определяет идентификатор UE 120 и качество обслуживания (QoS) услуги LCS на основании данных подписки для LCS клиента 170, данных подписки для абонента UE 120 и/или данных, предоставленных LCS клиентом 170, (2) выполняют проверку конфиденциальности на основании профиля конфиденциальности для абонента UE и (3) назначает опорный идентификатор (ID), который используется, чтобы связывать последующие отчеты о местоположении с исходным запросом периодического определения местоположения. Для проверки конфиденциальности GMLC 150 проверяет, разрешено ли LCS клиенту 170 или LCS клиенту данного типа запрашивать периодическую передачу отчетов о местоположении UE 120 и требуется ли уведомлять UE об этом запросе и разрешать принятие или отклонение запроса.

Если GMLC 150 не известен текущий обслуживающий MSC или SGSN для UE 120, то GMLC 150 посылает на HLR/HSS 160 сообщение Send Routing Info for LCS (Послать информацию маршрутизации для LCS), чтобы запросить информацию маршрутизации относительно UE (этап 2). HLR/HSS 160 затем возвращает сообщение Send Routing Info for LCS Acknowledgment (Подтверждение приема запроса посылки информации маршрутизации для LCS), которое содержит адрес MSC/SGSN 140 (этап 3). Этапы 2 и 3 могут быть пропущены, если GMLC 150 уже известен адрес MSC/SGSN 140. GMLC 150 затем посылает на MSC/SGSN 140 сообщение Provide Subscriber Location (Предоставить местоположение абонента), которое содержит запрос периодического определения местоположения, идентификатор UE, информацию периодического определения местоположения, и/или другую соответствующую информацию (этап 4).

MSC/SGSN 140 может аутентифицировать, что запрос периодического определения местоположения разрешен (также этап 4). Если запрос периодического определения местоположения разрешен, то MSC/SGSN 140 может потребовать, чтобы RAN 130 выполнила поисковый радиовызов и аутентификацию UE 120, например, если UE 120 был в неактивном режиме (этап 5). Если необходимы уведомление или проверка конфиденциальности, то MSC/SGSN 140 уведомляет UE 120 для того, чтобы уведомить пользователя беспроводного устройства о периодическом запросе местоположения и запросить пользователя о предоставлении или отклонении разрешения (также этап 5). UE 120 может представить свои возможности на RAN 130 и/или MSC/SGSN 140, например поддерживает ли UE режимы «на основе UE» и «с помощью UE» (также этап 5). MSC/SGSN 140 затем посылает на UE 120 сообщение LCS Periodic Location Invoke (Запуск услуги LCS периодического определения местоположения), которое содержит соответствующую информацию для запроса периодического местоположения (например, информацию периодического определения местоположения, QoS услуги LCS, опорный ID и так далее) (этап 6). Сообщение LCS Periodic Location Invoke может также включать в себя (1) перечень PLMN, в которых допускается периодическая передача отчетов о местоположении (например, могут инициироваться запросы MO-LR) и (2) указание для каждой PLMN о том, поддерживает ли PLMN основывающуюся на RAN периодическую передачу отчетов о местоположении. Если перечень PLMN в состав не включен, то последующие MO-LR-запросы могут ограничиваться текущей обслуживающей PLMN.

UE 120 затем посылает на MSC/SGSN 140 сообщение LCS Periodic Location Invoke Acknowledgment (Подтверждение приема запроса запуска услуги LCS периодического определения местоположения), которое указывает, принимается ли запрос периодического определения местоположения и может ли активно поддерживаться посредством последующих MO-LR-запросов. Результат проверки конфиденциальности не будет необходимым в этом сообщении, поскольку он уже включен на этапе 5. Если запрос периодического определения местоположения не принимается, но некоторая проверка конфиденциальности на этапе 5 проходит, то UE 120 будет указывать готовность допускать периодическую передачу отчетов о местоположении, но невозможность или нежелание активно поддерживать ее последующими MO-LR-запросами. В этом случае MSC/SGSN 140 может по-прежнему вызывать на исполнение периодическую передачу отчетов о местоположении через RAN 130, как описано ниже. В противном случае посредством MSC/SGSN 140 создается ответ об ошибке и возвращается на GMLC 150. В любом случае MSC/SGSN 140 посылает на GMLC 150 сообщение Provide Subscriber Location Acknowledgment, которое указывает, принимается ли запрос периодического определения местоположения (этап 8). Это сообщение может содержать другую соответствующую информацию, такую как перечень PLMN, посланный на UE 120. GMLC 150 затем посылает на LCS клиент 170 сообщение LCS Service Response (Ответ на запрос услуги LCS), которое содержит соответствующую информацию (например, принимается ли запрос периодического определения местоположения) (этап 9). После этого выполняется периодическая передача отчетов о местоположении UE на LCS клиент 170 с использованием возможностей периодических услуг LCS в RAN 130, как описано ниже (этап 10).

На фиг.2B показан вариант осуществления потока 210 сообщений для периодической передачи отчетов о местоположении для NI-LR. Поток 210 сообщений может использоваться, если LCS клиент 170 либо постоянно находится в пределах MSC/SGSN 140, либо постоянно находится в пределах той же PLMN и непосредственно связан с MSC/SGSN 140. Этапы 1, 5, 6, 7, 9 и 10 для потока 210 сообщений соответствуют этапам 1, 5, 6, 7, 9 и 10 соответственно потока 200 сообщений по фиг.2A. Для потока 210 сообщений LCS клиент 170 посылает непосредственно на MSC/SGSN 140 сообщение LCS Service Request, которое содержит запрос периодического определения местоположения и информацию о периодическом определении местоположения (этап 1). MSC/SGSN 140 может аутентифицировать, что запрос периодического определения местоположения разрешен и, если запрос разрешен, может потребовать, чтобы RAN 130 выполнила радиовызов и аутентификацию UE 120 (этап 5). Обычно на этапе 5 не выполняются уведомление или проверка конфиденциальности. Этапы 6 и 7 для потока 210 сообщений являются такими, как описаны выше для потока 200 сообщений. MSC/SGSN 140 затем посылает непосредственно на LCS клиент 170 сообщение LCS Service Response, которое указывает, принимается ли запрос периодического определения местоположения (этап 9). После этого выполняется периодическая передача на LCS клиент 170 отчетов о местоположении UE с использованием возможностей периодических LCS в RAN 130 для периодических LCS, как описано ниже (этап 10).

На фиг.3 показан вариант осуществления потока 300 сообщений периодической передачи отчетов о местоположении для MO-LR. Если UE 120 находится в неактивном режиме, то UE запрашивает установку соединения радиосвязи и посылает на RAN 130 сообщение Connection Management (CM) Service Request (Запрос услуги управления (CM)

соединением), указывающее запрос вызова независимой дополнительной услуги (этап 1). Если UE 120 находится в выделенном режиме, то UE посылает CM Service Request (Запрос услуги CM) на уже установленном соединении радиосвязи (также этап 1). RAN 130 пересылает сообщение Service Request на MSC/SGSN 140 (этап 2). MSC/SGSN 140 побуждает аутентификацию и шифрование, если UE 120 находится в неактивном режиме, или возвращает сообщение Direct Transfer CM Service Accept (Принятие услуги CM прямой передачи (переноса)), если UE 120 находится в выделенном режиме (этап 3). UE 120 может представить свои возможности на RAN 130 и/или MSC/SGSN 140, например, поддерживает ли UE режимы «на основе UE» и «с помощью UE» (также этап 3). Для ясности этапы 1-3 установки соединения по фиг.3 предполагают использование домена с коммутацией каналов (CS) и сигнализация посылается на MSC (а не SGSN). Этапы установки соединения для домена с коммутацией пакетов (PS) являются отличающимися и сигнализация посылается на SGSN через RAN 130. Установка соединения для доменов CS и PS описана в технических условиях 3GPP TS 23.271, которые являются доступными публично.

UE 120 затем посылает на MSC/SGSN 140 сообщение LCS MO-LR Location Services Invoke (Запуск услуги LCS определения местоположения для MO-LR), которое содержит (1) запрос периодической передачи на LCS клиент 170 отчетов о местоположении UE 120 (то есть запрос периодического определения местоположения) и (2) соответствующую информацию для периодической передачи отчетов о местоположении (этап 4). Соответствующая информация может включать в себя любую комбинацию из нижеследующего:

1) план (расписание) передачи отчетов о местоположении ("periodic loc info"),

2) конкретные события, используемые для запуска (инициирования) передачи отчетов о местоположении на LCS клиент 170 (также " periodic loc info "),

3) идентификационную информацию LCS клиента 170 ("lcs-client-addr") (адрес LCS клиента),

4) идентификационную информацию GMLC 150, через который можно осуществить доступ к LCS клиенту 170,

5) QoS услуги LCS, например точность и время ответа,

6) предпочтительный способ периодической передачи отчетов о местоположении, например MT-LR или MO-LR,

7) максимально допустимый срок любой оценки местоположения,

8) должен ли UE 120 быть идентифицирован на LCS клиенте 170 с использованием фактической идентификационной информации или фактического адреса UE или с использованием псевдонима, и

9) другую уместную информацию.

MSC/SGSN 140 проверяет, что UE 120 авторизован для запрошенной услуги определения местоположения, на основании профиля подписки для UE (также этап 4). Если запрос периодического определения местоположения авторизован, то MSC/SGSN 140 посылает на GMLC 150 сообщение MAP Subscriber Location Report (Отчет MAP о местоположении абонента), которое содержит запрос периодического определения местоположения и соответствующую информацию (например, информацию о периодическом определении местоположения) (этап 5). GMLC 150 затем пересылает запрос периодического определения местоположения и соответствующую информацию на LCS клиент 170 (этап 6). LCS клиент 170 посылает на GMLC 150 ответ на запрос UE (этап 7). В варианте осуществления любой объект из числа MSC/SGSN 140, GMLC 150 и LCS клиента 170 может отказываться или принимать запрос периодического определения местоположения. Если запрос принимается (например, не отклоняется каким-либо объектом), то GMLC 150 назначает запросу опорный ID. GMLC 150 затем посылает на MSC/SGSN 140 сообщение MAP Subscriber Location Report Acknowledgment (Подтверждение приема запроса отчета MAP о местоположении абонента) (этап 8). MSC/SGSN 140 может принимать любую комбинацию из нижеследующей информации:

1) опорный ID, назначенный посредством GMLC 150,

2) модифицированный план передачи отчетов о местоположении ("periodic loc info"),

3) модифицированные конкретные события, используемые для инициирования передачи отчетов о местоположении на LCS клиент 170 (также " periodic loc info"),

4) адрес GMLC 150, и

5) другую уместную информацию.

MSC/SGSN 140 посылает на UE 120 сообщение LCS MO-LR Return Result (Возвращаемый результат услуги LCS для MO-LR), которое содержит информацию, полученную от GMLC 150 (этап 9). Сообщение LCS MO-LR Return Result может дополнительно включать в себя (1) перечень PLMN, в которых допускается периодическая передача отчетов о местоположении и (2) указание для каждой PLMN, поддерживает ли PLMN основывающуюся на RAN периодическую передачу отчетов о местоположении. Это применяется, если UE 120 будет играть активную роль в последующей периодической передаче отчетов о местоположении посредством запросов MO-LR. Если перечень PLMN не представлен, то любые последующие запросы MO-LR могут ограничиваться текущей обслуживающей PLMN. После этого может выполняться периодическая передача отчетов о местоположении UE на LCS клиент 170 с использованием возможности периодических LCS в RAN 130, как описано ниже (этап 10).

В целом, любой объект (например, UE 120) может вызывать основывающуюся на RAN периодическую передачу отчетов относительно местоположения UE на LCS клиент 170. Чтобы поддерживать вызов посредством UE 120 периодической передачи отчетов в RAN 130, UE 120 может быть информирован, имеет ли каждая PLMN возможности периодических LCS в RAN. Эта информация может быть включена в перечень PLMN, посылаемый на UE 120 на этапе 6 потока 200 сообщений или на этапе 9 потока 300 сообщений. Эта информация может также широковещательно передаваться несколькими RAN.

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

1) истекла продолжительность передачи отчетов или достигнуто полное число сообщений,

2) периодическая передача отчетов о местоположении отменена посредством LCS клиента 170 или GMLC 150, или

3) UE 120 завершает периодическую передачу отчетов о местоположении.

На фиг.4 показана реализация потока 400 сообщений для основывающейся на RAN периодической передачи отчетов о местоположении, которое может использоваться для этапа 10 потока 200 сообщений по фиг.2A, этапа 10 потока 210 сообщений по фиг.2B и этапа 10 потока 300 сообщений по фиг.3. Этапы 1-3 потока 400 сообщений являются такими же, как этапы 1-3 потока 300 сообщений. UE 120 затем посылает на MSC/SGSN 140 сообщение LCS MO-LR Location Services Invoke, чтобы запустить периодическую передачу отчетов о местоположении (этап 4). Сообщение LCS MO-LR Location Services Invoke, посланное на этапе 4 потока 300 сообщений, "запрашивает" периодическую передачу отчетов о местоположении, принимая во внимание, что сообщение LCS MO-LR Location Services Invoke, посланное на этапе 4 потока 400 сообщений, "запускает" периодическую передачу отчетов о местоположении после того, как был авторизован запрос периодического определения местоположения. Сообщение LCS MO-LR Location Services Invoke, посланное в потоке 400 сообщений, содержит соответствующую информацию, такую как, например, информация о периодическом определении местоположения, QoS услуги LCS, идентификационная информация LCS клиента 170, указание, что запрос был авторизован для периодического определения местоположения и так далее. Указанием авторизации может быть, например, опорный ID, назначенный посредством GMLC 150. Присутствие (на фиг.4) или отсутствие (на фиг.3) указания авторизации в сообщении LCS MO-LR Location Services Invoke информирует MSC/SGSN 140, исполнять ли поток 400 сообщений или поток 300 сообщений соответственно. Присутствие информации периодического определения местоположения или другой эквивалентной информации в LCS MO-LR Location Services Invoke информирует MSC/SGSN 140, что предпочтительнее запрашивается основывающаяся на RAN периодическая передача отчетов о местоположении на LCS клиент 170, чем таковой однократный отчет о местоположении. В случае однократного отчета о местоположении UE 120 будет отвечать за повторную выдачу на этапе 4 сообщения LCS MO-LR Location Services Invoke (например, повторяя этапы 1-4) для каждой плановой или инициированной передачи отчетов о местоположении, которые будут посланы на LCS клиент 170. При запросе основывающейся на RAN периодической передачи отчетов о местоположении UE не требуется повторно выдавать другое LCS MO-LR Location Services Invoke, пока не будет завершено планирование и/или запуск передачи отчетов о местоположении посредством RAN, как описано ниже.

MSC/SGSN 140 проверяет, что UE 120 авторизован для запрошенной услуги определения местоположения, и затем посылает на RAN 130 сообщение Location Request, которое инициирует основывающиеся на RAN периодические передачи отчетов о местоположении (этап 5). Это сообщение также может содержать информацию периодического определения местоположения, QoS услуги LCS и так далее. RAN 130 выбирает соответствующий способ определения местоположения на основании запроса местоположения, требуемой точности, и возможностей UE.

Затем RAN 130 инициирует соответствующий поток сообщений, чтобы получить и вернуть первую оценку местоположения для UE 120 (этап 6a). Этот поток сообщений может зависеть от различных факторов, таких как возможности UE (например, «на основе UE» или «с помощью UE»), выбранный способ определения местоположения (например, A-GPS, A-FLT, E-OTD, OTDOA и так далее), будут ли UE 120, RAN 130, или SAS 132 вычислять оценку местоположения и так далее. Несколько вариантов осуществления потока сообщений для этапа 6a описаны ниже. RAN 130 получает оценку местоположения для UE 120 исходя из потока сообщений на этапе 6a и посылает на MSC/SGSN 140 сообщение Location Report, которое содержит эту оценку местоположения и другую соответствующую информацию (например, опорный ID) (этап 7a). MSC/SGSN 140 затем посылает сообщение MAP Subscriber Location Report, содержащее оценку местоположения и соответствующую информацию на GMLC 150 (этап 8a), который посылает оценку местоположения и соответствующую информацию на LCS клиент 170 (этап 9a). LCS клиент 170 отвечает посредством посылки подтверждения приема информации местоположения на GMLC 150 (этап 10a), который посылает на MSC/SGSN 140 сообщение MAP Subscriber Location Report Acknowledgment, которое указывает, была ли оценка местоположения успешно послана на LCS клиент 170 (этап 11a).

Для каждого последующего события i передачи отчета о местоположении для i=b...n, как определено посредством информации периодического определения местоположения, выполняется поток сообщений, чтобы получить оценку местоположения для UE 120 (этап 6i), и оценка местоположения посылается на MSC/SGSN 140 (этап 7i). MSC/SGSN 140 затем передает оценку местоположения на LCS клиент 170 (этапы 8i-11i). После того, как события передачи отчета о местоположении завершены, MSC/SGSN 140 посылает на UE 120 сообщение LCS MO-LR Return Result, чтобы подтвердить, что оценки местоположения были посланы на LCS клиент 170, и указать завершение периодической передачи отчетов о местоположении (этап 12). MSC/SGSN 140 может побуждать отсоединение от UE 120 соединений служб Управления соединением (CM), управления мобильностью (ММ) или управления мобильностью GPRS (GMM), и управления ресурсами радиосвязи (RR/RRC), если UE был предварительно неактивным (этап 13). Этап 13 может быть опущен, если UE 120 требуется оставаться в выделенном режиме, чтобы взаимодействовать с RAN 130, например, для поддержки других продолжающихся услуг.

Основывающаяся на RAN периодическая передача отчетов в случае UMTS (например, W-CDMA) может осуществляться с помощью режима «с центральным RNC» и режима «с центральным SAS». Для режима «с центральным RNC» контроллер обслуживающий радиосети (SRNC) в пределах обслуживающей RAN координирует и управляет периодическую передачу отчетов для UE. Для режима «с центральным SAS» SRNC передает управление на SAS, который координирует и управляет периодической передачей отчетов о местоположении. Для обоих режимов и «с центральным RNC», и «с центральным SAS» SRNC хранит информацию состояния, чтобы содействовать взаимодействию с UE, SAS, и MSC/SGSN для периодической передачи отчетов о местоположении. UE не нуждается в осведомлении, используется ли режим «с центральным RNC» или «с центральным SAS» для периодической передачи отчетов о местоположении. Режимы «с центральным RNC» и «с центральным SAS» могут использоваться для режимов «с помощью UE», «на основе UE» и «на основе сети».

На фиг.5 показан вариант осуществления потока 500 сообщений для основывающейся на RAN периодической передачи отчетов в режиме «с центральным RNC». Поток 500 сообщений является одним вариантом осуществления потока 400 сообщений по фиг.4 и может использоваться для этапа 10 потоков сообщений 200, 210 и 300 по фиг.2A, 2B и 3 соответственно.

Поток сообщений (который может включать в себя этапы 1-4 потока 400 сообщений по фиг.4) выполняют первоначально, чтобы запустить периодическую передачу отчетов о местоположении на LCS клиент 170 (этап 1). MSC/SGSN 140 затем посылает на SRNC, находящийся в пределах RAN 130 (или просто на RAN/SRNC 130), сообщение Radio Access Network Application Part (RANAP) Location Reporting Control (Управление отчетом о местоположении прикладной подсистемы сети радиодоступа), которое инициирует периодическую передачу отчетов о местоположении (этап 2). Это сообщение может также содержать информацию периодического определения местоположения, QoS услуги LCS и так далее. В варианте осуществления сообщение RANAP Location Reporting Control (Управление отчетом о местоположении подсистемы RANAP) включает в себя информационный элемент (ИЭ, IE) Periodical Reporting Criteria (Критерии периодичности выдачи) с наличием нижеследующих полей:

1) количество отчетов - 1, 2, 4, 8, 16, 32, 64, неограниченное, и

2) интервал выдачи отчета - 250, 500, 1000, 2000, 3000, 4000, 6000, 8000, 12000, 16000, 20000, 24000, 28000, 32000, 64000 миллисекунд (мс).

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

Поля информационного элемента Periodical Reporting Criteria могут быть заданы, чтобы были одинаковыми с полями для информационного элемента RRC Periodical Reporting Criteria в сообщении RRC Measurement Control (Управление измерением), которое будет послано посредством RAN/SRNC 130 на UE 120 на этапе 5 потока 500 сообщений. Кроме того, может использоваться одинаковый набор значений для соответствующих полей в информационном элементе Periodical Reporting Criteria и информационном элементе RRC Periodical Reporting Criteria. Это затем позволит RAN/SRNC 130 просто извлекать значения в информационном элементе Periodical Reporting Criteria, принятом от MSC/SGSN 140, и отображать эти значения непосредственно на информационный элемент RRC Periodical Reporting Criteria, посланный на UE 120. MSC/SGSN 140 будет преобразовывать периодическую информацию местоположения (например, время начала, время останова и интервал между отчетами) в наиболее подходящие значения для полей Amount of Reports (Объем отчетов) и Reporting Interval (Интервал передачи отчетов) в информационном элементе Periodical Reporting Criteria. MSC/SGSN 140 может использовать значение "неограниченное" в качестве заданного по умолчанию для поля Amount of Reports и может посылать команду "stop reporting" (остановить передачу отчетов)" на RAN/SRNC 130, когда более не требуются отчеты о местоположении. RAN/SRNC 130 затем пошлет команду останова на UE 120. Обычно, если соответствующие поля в различных сообщениях не являются одинаковыми, то MSC/SGSN 140 преобразовывает периодическую информацию местоположения, принятую от UE 120 (или принятую от любого другого объекта в PLMN, такого как, например, MSC/SGSN 140 или LCS клиент 170), в наиболее подходящие значения для сообщения RANAP Location Reporting Control на этапе 2 (если необходимо), и RAN/SRNC 130 преобразовывает эти значения в наиболее подходящие значения для сообщения RRC Measurement Control на этапе 5 (если необходимо).

В другом варианте осуществления информационный элемент Periodical Reporting Criteria в сообщении RANAP Location Reporting Control может включать в себя любое значение для интервала передачи отчетов (например, любое целое число, кратное секундам) или любое значение для числа отчетов. RAN/SRNC 130 или SAS 132 могут использовать эту информацию, чтобы решить, вызывать на исполнение ли периодическую передачу отчетов RRC или периодически повторять последовательность сообщения RRC Measurement Control/Measurement Report, как используется для единственного запроса. Например, периодическая передача отчетов RRC может быть запущена, когда значения для информационного элемента Periodical Reporting Criteria в принятом сообщении RANAP Location Reporting Control RANAP совместимы с соответствующими значениями в информационном элементе RRC Periodical Reporting Criteria.

RAN/SRNC 130 выбирает соответствующий способ определения местоположения на основании запроса местоположения, требуемой точности, и возможностей UE (также этапы 2). Если SAS 132 является доступным, и выбранным способом определения местоположения является A-GPS, то RAN/SRNC 130 может посылать на SAS 132 сообщение Positioning Calculation Application Part (PCAP) Information Exchange Initiation Request (Запрос инициирования обмена с прикладной подсистемой PCAP вычисления позиционирования), чтобы запросить данные помощи GPS (этап 3). SAS 132 затем возвращает на RAN/SRNC 130 сообщение PCAP Information Exchange Initiation Response (Ответная информация PCAP на инициирование обмена), которое содержит требуемые данные помощи GPS (этап 4). Этапы 3 и 4 могут быть опущены для других способов определения местоположения или если данные помощи GPS не являются необходимыми или если RAN/SRNC уже обладает данными помощи GPS (например, из предыдущего запроса на SAS 132). RAN/SRNC 130 затем посылает на UE 120 сообщение RRC Measurement Control, которое содержит информацию периодического определения местоположения (например, информационный элемент RRC Periodical Reporting Criteria) и данные помощи GPS (этап 5). Этапы 3, 4 и 5 являются частью сообщений для позиционирования 1 для первого события передачи отчета о местоположении.

Для каждого события i передачи отчета о местоположении, для i=a... n, как определено информацией о периодическом определении местоположения, UE 120 посылает на RAN/SRNC 130 сообщение RRC Measurement Report, которое содержит информацию местоположения (этап 6i). Эта информация местоположения может включать в себя измерения, выполненные UE 120 относительно базовых станций и/или спутников, наблюдаемых посредством UE (для режима «с помощью UE»), оценку местоположения UE 120 (для режима «на основе UE») или указание ошибки, если не являются доступными измерения или оценка местоположения. Измерениями могут быть, например, псевдодальности для A-GPS, SFN-SFN (системный номер кадра - системный номер кадра), наблюдаемые разности времен для OTDOA или некоторый другой тип измерений. Если интервал передачи отчетов является коротким (например, 2 секунды) и выбранным способом определения местоположения является A-GPS, то несколько первых сообщений RRC Measurement Report могут содержать сообщения об ошибках, пока GPS-приемник в UE 120 не обнаружит спутники и не будет находиться в режиме сопровождения. После этого сообщения RRC Measurement Report должны обеспечивать хорошие измерения и/или оценки местоположения в интервале передач отчетов.

Если RAN/SRNC 130 принимает измерения от UE 120 (для режима «с помощью UE») и SAS 132 доступен, то RAN/SRNC 130 посылает на SAS 132 сообщение PCAP Position Calculation Request (Запрос PCAP вычисления позиции), которое содержит измерения UE

и возможно другую информацию, например, для дополнительного определения местоположения «на основе сети» (этап 7i).

Сообщение PCAP Position Calculation Request, посланное на этапах 7i, может также содержать информацию периодического определения местоположения, например интервал передачи отчетов и количество неподтвержденных запросов для полной процедуры периодического определения местоположения. Информация периодического определения местоположения позволяет SAS 132 поддерживать информацию о состоянии между отдельными запросами к PCAP для вычисления позиции, чтобы лучше выполнять будущие такие запросы. SAS 132 вычисляет оценку местоположения для UE 120 на основании измерений и любой другой информации и посылает на RAN/SRNC 130 сообщение PCAP Position Calculation Response (Ответ PCAP на запрос вычисления позиции), которое содержит оценку местоположения (этап 8i). Если RAN/SRNC 130 принимает оценку местоположения от UE 120 (для режима «на основе UE»), то этапы 7i и 8i можно пропустить. Если RAN/SRNC 130 решает использовать только позиционирование «на основе сети» (например, усовершенствованный способ идентификации сотовой ячейки, U-TDOA), то этапы 3, 4, 5 и 6i (для i=a... n) пропускаются, и RAN/SRNC 130 посылает на SAS 132 на этапе 7i сообщение PCAP Position Calculation Request, содержащее информацию для выбранных способов определения позиции «на основе сети». SAS 132 затем возвращает на этапе 8i сообщение PCAP Position Calculation Response (Ответ PCAP на запрос вычисления позиции), содержащее оценку местоположения, являющуюся результатом применения SAS 132 способов «на основе сети». В любом случае RAN/SRNC 130 посылает сообщение RANAP Location Report (Отчет RANAP о местоположении), содержащее оценку местоположения, на MSC/SGSN 140 (этап 9i), который передает оценку местоположения на LCS клиент 170 (этап 10i). Этап 10i может включать в себя этапы 8i-11i потока 400 сообщений по фиг.4.

Как показано на фиг.5, каждое событие передачи отчета о местоположении включает в себя сообщения, предназначенные для определения местоположения, передачи оценки местоположения от RAN/SRNC 130 на MSC/SGSN 140 (этап 9i) и передачи оценки местоположения от MSC/SGSN 140 на LCS клиент 170 (этап 10i). Сообщения для позиционирования 1 для первого события передачи отчета о местоположении включают в себя этапы 3-8a, и сообщения для определения местоположения i для каждого последующего события передачи отчета о местоположении включают в себя этапы 6i-8i. Сообщения для определения местоположения 1 для первого события передачи отчета о местоположении могут включать в себя дополнительные этапы 3, 4 и 5, чтобы запрашивать и впоследствии получить от SAS 132 помощь GPS (этапы 3 и 4) и передавать эти данные помощи на UE 120, чтобы вызвать периодическую посылку от UE 120 информации местоположения (этап 5). UE 120 может также запрашивать новые данные помощи на этапе 6i, вместо или в дополнение к посылке измерений местоположения на RAN/SRNC 130. Это может быть в обстоятельствах, например, если число сообщений, первоначально запрошенных (например, на этапе 5), является большим, и запрошенным способом определения местоположения является A-GPS. Если UE 120 запрашивает новые данные помощи, то этапы 3, 4 и 5 повторяются, и новые или обновленные данные помощи посылаются на UE 120 в сообщении Measurement Control или в сообщении Assistance Data Delivery (Доставка данных помощи) вместе с другой уместной информацией. Запрос новых данных помощи на этапе 6i и их предоставление путем повторения этапов 3, 4 и 5 может происходить многократно в потоке 500 сообщений. После того, как события передачи отчета о местоположении выполнены, выполняется поток сообщений (который может включать в себя этапы 12 и 13 потока 400 сообщений по фиг.4), чтобы закончить периодическую передачу отчетов о местоположении на LCS клиент 170 (этап 11).

RAN/SRNC 130 может решить на этапе 5 не запрашивать периодическую передачу отчетов UE, например опустить информационный элемент RRC Periodical Reporting Criteria из сообщения RRC Measurement Control, или включить этот информационный элемент со значением единица для числа сообщений. Как упомянуто выше, это может иметь место в обстоятельствах, если информация о периодическом определении местоположения, принятая в сообщении RANAP Location Reporting Control, не является совместимой с соответствующим доступным диапазоном значений в сообщении RRC Measurement Control. RAN/SRNC 130 может затем повторяют посылку этапа 5 в желательном интервале периодической передачи отчета. Сообщения для определения местоположения i для каждого события передачи отчета о местоположении будут тогда в дополнение к этапам 6i-8i включать в себя этап 5.

На фиг.6 показан вариант осуществления потока 600 сообщений для основывающейся на RAN периодической передачи отчетов в режиме «с центральным SAS». Поток 600 сообщений является другим вариантом осуществления потока 400 сообщений по фиг.4 и может также использоваться для этапа 10 потоков сообщений 200, 210 и 300 на фиг.2A, 2B и 3 соответственно.

Этапы 1 и 2 потока 600 сообщений сходны с (например, одинаковые с) этапами 1 и 2 потока 500 сообщений по фиг.5. RAN/SRNC 130 принимает от MSC/SGSN 140 сообщение RANAP Location Reporting Control, которое содержит информацию периодического определения местоположения, QoS услуги LCS, и так далее (этап 2). RAN/SRNC 130 затем посылает на SAS 132 сообщение PCAP Position Initiation Request (Запрос инициирования позиционирования), которое содержит информацию, принятую от MSC/SGSN 140, и возможно другую информацию, такую как ID сотовой ячейки и возможности UE по позиционированию (например, информация относительно способа или способов определения местоположения, которые целевой UE 120 поддерживает) (этап 3). Это сообщение также передает управление периодической передачей отчетов на SAS 132. SAS 132 выбирает соответствующий способ определения местоположения на основании требуемой точности и возможностях UE и определяет соответствующие данные помощи (если имеются) для посылки на UE 120. SAS 132 затем посылает RAN/SRNC 130 сообщение PCAP Position Activation Request (Запрос активации позиционирования), которое содержит информацию периодического определения местоположения (например, информационный элемент Periodical Reporting Criteria) и данные помощи (этап 4). SAS 132 на этапе 4 может преобразовывать информацию периодического определения местоположения, принятую от RAN/SRNC 130 на этапе 3, в наиболее подходящие значения для сообщения PCAP Position Activation Request, если необходимо. RAN/SRNC 130 затем посылает на UE 120 RRC сообщение Measurement Control, которое содержит информацию периодического определения местоположения и данные помощи (этап 5). Этапы 3, 4 и 5 являются частью сообщений для определения местоположения 1 для первого события передачи отчета о местоположении.

Для каждого события i передачи отчета о местоположении, для i=a...n, как определено информацией о периодическом определении местоположения, UE 120 посылает на RAN/SRNC 130 сообщение RRC Measurement Report (Отчет RRC об измерении), которое содержит информацию местоположения (этап 6i). Эта информация местоположения может включать в себя измерения, выполненные посредством UE 120 для базовых станций и/или спутников (для режима «с помощью UE»), оценку местоположения для UE 120 (для режима «на основе UE») или указание ошибки, если не являются доступными измерения или оценка местоположения. RAN/SRNC 130 посылает на SAS 132 сообщение PCAP Position Periodic Request (Запрос периодического позиционирования), которое содержит информацию местоположения, принятую от UE 120 (этап 7i). Для режима «с помощью UE» SAS 132 принимает измерения от UE 120 и вычисляет оценку местоположения для UE на основании измерений и, возможно, другой информации (например, информации, полученной определением местоположения «на основе сети»). Для режима «на основе UE» SAS 132 принимает от UE 120 оценку местоположения и может проверять оценку местоположения и/или модифицировать ее (например, на основании информации, полученной определением местоположения на основе сети). Для обоих режимов и «на основе UE» и «с помощью UE» SAS 132 посылает на RAN/SRNC 130 сообщение PCAP Position Periodic Response (Ответ на запрос периодического позиционирования), которое содержит оценку местоположения для UE 120 (этап 8i). RAN/SRNC 130 затем посылает сообщение RANAP Location Report, содержащее оценку местоположения, на MSC/SGSN 140 (этап 9i), который передает оценку местоположения на LCS клиент 170 (этап 10i). Этап 10i может включать в себя этапы 8i-11i потока 400 сообщений по фиг.4.

Вслед за приемом заключительного сообщения RRC Measurement Report от UE 120 (этап 6 n) RAN/SRNC 130 может посылать на SAS 132 на этапе 7 n сообщение PCAP Position Activation Response (Ответ на запрос активации позиционирования), несущее тот же тип информации (например, измерения или оценки местоположения), как и сообщение PCAP Position Periodic Request в предыдущих этапах 7i (для i=a... n-1). SAS 132 может затем возвратить сообщение PCAP Position Initiation Response (Ответ на запрос инициирования позиционирования) на этапе 8n, несущий такой же тип информации (например, вычисленная оценка местоположения), как сообщение PCAP Position Periodic Response в предыдущих этапах 8i (для i=a... n-1). Это различие может содействовать соответствию с существующими соглашениями для 3GPP (определенными в 3GPP TS 25.453), что на любое сообщение запроса PCAP, посланное или от RNC на SAS, или от SAS на RNC, следует отвечать самое большее одним отличным ответным сообщением PCAP. В этом случае сообщение PCAP Position Initiation Response, посланное на этапе 8n, является ответом на сообщение PCAP Position Initiation Request (PCAP-запрос Инициирования Позиции), посланное на этапе 3; сообщение PCAP Position Activation Response, посланное на этапе 7n - ответ на сообщение PCAP Position Activation Request, посланное на этапе 4; и PCAP Position Periodic Response, посланное на этапе 8i (для i=a...n-1), является ответом на сообщение PCAP Position Periodic Request, посланное на этапе 7i. Эти подборы в пары соответствуют конкретно элементарной процедуре класса 1 в документе 3GPP TS 25.453. Кроме того, первые две пары (этапы 3 и 8n, и этапы 4 и 7n) являются применимыми к однократным запросам определения местоположения (например, если каждое образование пары происходит только однажды), предоставляя более высокую совместимость между однократным и периодическими запросами местоположения и, возможно, более простую реализацию в RAN/SRNC 130 и SAS 132, чтобы поддерживать оба типа запросов местоположения. Чтобы дать возможность большей совместимости с действием «с центральным RNC», сообщения запроса PCAP для периодического позиционирования и ответа на него, на этапах 7i и 8i могут быть заменены на сообщения PCAP Position Calculation Request/Response (Запрос/ответ вычисления позиции), используемыми в режиме «с центральным RNC» и показанными на фиг.5. В этом случае сообщения PCAP Position Calculation Request/Response могут быть слегка модифицированы, чтобы также давать возможность доставки оценки местоположения, принятой от UE на SAS, но новые процедуры не требуются.

В альтернативном варианте осуществления потока 600 сообщений после приема заключительного сообщения RRC Measurement Report от UE 120 на этапе 6n, RAN/SRNC

может посылать сообщение PCAP Position Periodic Request на SAS 132 на этапе 7n, и SAS 132 может возвращать сообщение PCAP Position Periodic Response на этапе 8n так же, как и на предыдущих этапах 7i и 8i. В этом случае после этапа 8n и не показано на фиг.6 RAN/SRNC 130 может посылать на SAS 132 сообщение PCAP Position Activation Response, которое не содержит каких-либо измерений или оценку местоположения и SAS 132 может возвращать сообщение PCAP Position Initiation Response, не содержит оценку местоположения, чтобы ответить на более ранние сообщения этапов 3 и 4 и завершить транзакции, связанные с ними в SAS 132 и RAN/SRNC 130.

В другом альтернативном варианте осуществления потока 600 сообщений элементарная процедура PCAP класса 1, содержащая сообщения PCAP Position Periodic Request и PCAP Position Periodic Response на этапах 7i и 8i, может быть заменена элементарными процедурами PCAP класса 2, которые определены в 3GPP TS 25.453. Элементарные процедуры класса 2 являются процедурами без сообщения ответа. В этом варианте осуществления сообщение PCAP Position Activation Response на этапе 7n потока 600 сообщений может быть послано либо немедленно после сообщения PCAP Position Activation Request на этапе 4, либо после того, как было принято первое сообщение RRC Measurement Report, что происходит после этапа 6a. В первом случае сообщение PCAP Position Activation Response будет содержать подтверждение запрошенного действия. В последнем случае сообщение PCAP Position Activation Response будет дополнительно содержать информацию отчета о первом измерении. Сообщение PCAP Position Activation Request может содержать некоторые рекомендуемые команды определения местоположения, которые RAN/SRNC 130 может пересылать на UE 120 в сообщении RRC Measurement Control на этапе 5. Если RAN/SRNC 130 не может соответствовать запросу для некоторых команд определения местоположения, то RAN/SRNC 130 может информировать SAS 132 в сообщении PCAP Position Activation Response о командах определения местоположения, используемых взамен в сообщении RRC Measurement Control, посланном на UE 120 на этапе 5. Примером таких команд определения местоположения может быть информация относительно того, в каком состоянии RRC запрошенные измерения являются действительными. Последующая информация отчета об измерении, полученная в RAN/SRNC 130 от UE 120, будет затем передаваться на SAS 132 в сообщениях PCAP класса 2 Position Periodic Report (Отчет периодического позиционирования), которые будут посланы на этапах 7i вместо сообщений PCAP Position Periodic Request, показанных в потоке 600 сообщений. SAS 132, в свою очередь, будет предоставлять на RAN/SRNC 132 отчет об оценках местоположения в сообщениях PCAP класса 2 Position Periodic Result (Результат запроса периодического позиционирования), которые будут посылаться на этапах 8i вместо сообщений PCAP Position Periodic Response, показанных в потоке 600 сообщений. Если SAS 132 решает отменить продолжающуюся периодическую процедуру RRC, то SAS 132 может послать на RAN/SRNC 132 сообщение PCAP Position Periodic Result, содержащее запрос завершения периодической процедуры. В качестве альтернативы SAS 132 может посылать сообщение PCAP класса 2 Position Periodic Termination (Завершение периодического позиционирования) на RAN/SRNC 130, чтобы отменить продолжающуюся периодическую процедуру. Этот поток сообщений может быть более совместимым с процедурами периодического определения местоположения, которые не требуют сигнализации RRC, например позиционирование cell-ID или U-TDOA на основе сети.

Вариант осуществления класса 2, описанный выше, позволяет SAS 132 решать, запускать ли периодическую RRC передачу отчета об измерении или периодически повторять одиночные запросы (например, в случае, если информация периодической передачи отчета, принятая в SAS 132 в сообщении PCAP Position Initiation Request на этапе 3, не является совместимой с диапазоном доступных значений в информационном элементе RRC Periodical Reporting Criteria). SAS 132 может затем повторять посылку сообщения PCAP Position Activation Request на RAN/SRNC 132 в запрошенном интервале периодической передачи отчета. RAN/SRNC 130 будет повторять пару сообщений RRC Measurement Control/Report и передает информацию измерения на SAS 132 в сообщении PCAP Position Activation Response. SAS 132 может затем посылать индивидуальные оценки местоположения на RAN/SRNC 130 в сообщении PCAP Position Periodic Result.

Вариант осуществления класса 2 может использоваться, например, чтобы поддерживать периодическое позиционирование на основе cell-ID. В этом случае SAS 132 может периодически посылать сообщение PCAP Position Activation Request RAN/SRNC 130 (не показано на фиг.6). RAN/SRNC 130 может затем возвращать сообщение PCAP Position Activation Response, содержащее соотнесенные с сотовой ячейкой измерения для UE 120, полученные посредством RAN/SRNC 130. SAS 132 может затем посылать на RAN/SRNC 130 сообщение PCAP Position Periodic Result, содержащее оценку местоположения, полученную исходя из этих измерений.

Вариант осуществления для класса 2 может также использоваться, чтобы поддерживать периодическое позиционирование на основе U-TDOA. В этом случае RAN/SRNC 130 может возвращать на SAS 132 сообщение PCAP Position Activation Response, содержащее соотнесенную с каналом информацию для UE 120 после приема сообщения PCAP Position Activation Request на этапе 3 по фиг.6. SAS 132 может затем задать конфигурацию устройств LMU, чтобы получать периодические измерения U-TDOA для UE 120, и может возвращать периодические результаты оценки местоположения на RAN/SRNC 130 в виде последовательности сообщений PCAP Position Periodic Result. В этом варианте осуществления U-TDOA может не являться необходимым, чтобы RAN/SRNC 130 посылала последующие сообщения на SAS 132, экономя, таким образом, ресурсы передачи и обработки и уменьшая задержку.

Исполнение класса 2 может быть расширено, чтобы поддерживать периодическое позиционирование на основе U-TDOA параллельно с периодическим A-GPS и/или периодическим OTDOA позиционированием. В этом случае периодическое U-TDOA позиционирование может вызываться, как описано выше. Периодическое A-GPS или OTDOA позиционирование могут затем вызываться с использованием осуществления элементарной процедуры PCAP класса 2, также описанной выше. SAS 132 может получать периодические оценки местоположения для UE 120 с использованием периодических U-TDOA измерений, полученных посредством устройств LMU, и периодических измерений GPS, поставляемых на SAS 132 в сообщении PCAP Position Periodic Report. SAS 132 может затем возвратить каждую оценку местоположения на RAN/SRNC 130 в сообщении PCAP Position Periodic Result.

Как показано на фиг.6, каждое событие передачи отчета о местоположении включает в себя сообщения для определения местоположения, передачи оценки местоположения от RAN/SRNC 130 на MSC/SGSN 140 (этап 9i) и передачи оценки местоположения от MSC/SGSN 140 на LCS клиент 170 (этап 10i). Сообщения для позиционирования 1 для первого события передачи отчета о местоположении включают в себя этапы 3-8a, и сообщения для позиционирования i для каждого последующего события передачи отчета о местоположении включают в себя этапы 6i-8i. После того, как события передачи отчета о местоположении завершены, выполняется поток сообщений (который может включать в себя этапы 12 и 13 потока 400 сообщений по фиг.4), чтобы закончить периодическую передачу отчетов о местоположении на LCS клиент 170 (этап 11).

UE 120 может в некоторой точке запрашивать новые или обновленные данные помощи на этапе 6i, вместо посылки или в дополнение к посылке измерений местоположения на RAN/SRNC 130. Это может иметь место в обстоятельствах, например, если число сообщений, первоначально запрошенных (например, на этапе 5), было большим, и запрошенным способом определения местоположения был A-GPS. В варианте осуществления запрос дополнительных данных помощи может передаваться от RAN/SRNC 130 на SAS 132 либо в рамках сообщения PCAP Position Periodic Request, либо сообщения PCAP Position Periodic Report (не показано на фиг.6), посылаемого на этапе 7i, и запрошенные данные помощи могут быть возвращены посредством SAS 132

на RAN/SRNC 130 либо в сообщении PCAP Position Periodic Response, либо в сообщении PCAP Position Periodic Result (не показано на фиг.6), посылаемом на этапе 8i. RAN/SRNC 130 может затем передать данные помощи на UE 120 либо в сообщении RRC Measurement Control, либо сообщении RRC Assistance Data Delivery (не показано на фиг.6). Этот вариант осуществления избегает необходимости, чтобы SAS 132 и RAN/SRNC 130 повторно запускали A-GPS-поддержку позиционирования. В другом варианте осуществления после приема запроса дополнительных данных помощи на этапе 6i RAN/SRNC 130 может передавать этот запрос на SAS 132 в сообщении PCAP Position Activation Response (не показано на фиг.6). SAS 132 затем подготавливает новые запрошенные данные помощи и посылает их, возможно, вместе с новой информацией о периодическом определении местоположения, в новом сообщении PCAP Position Activation Request на RAN/SRNC 130 (не показано на фиг.6), которое начинает новую транзакцию. RAN/SRNC 130 затем посылает новое сообщение RRC Measurement Control на UE 120, указывающее, что предварительно инициированное измерение (на этапе 5) теперь модифицировано с помощью новых данных помощи (и, возможно, новых команд передачи отчетов). Это вариант осуществления имеет эффект повторного запуска A-GPS-поддержки позиционирования в SAS 132 и RAN/SRNC 130 и, возможно, в изменении команд периодической передачи отчетов в UE 120.

В другом варианте осуществления RAN/SRNC 130 может вызывать на исполнение процедуру PCAP Information Exchange Procedure (Процедура PCAP обмена информацией), как определено в 3GPP TS 25.453, чтобы запрашивать данные помощи от SAS 132, который в настоящее время используется только для режима «с центральным RNC». В этом варианте осуществления, RAN/SRNC 130 может запрашивать данные помощи от SAS 132 путем воспроизведения этапов 3, 4 и 5 по фиг.5 (не показано на фиг.6). При использовании этой процедуры также в режиме «с центральным SAS» SAS 132 осведомлена, что эта процедура принадлежит событию позиционирования для UE 120, например, путем использования параметра идентификатора (ID) сеанса, который связывает все PCAP-сообщения с одним и тем же событием позиционирования, или путем использования имеющегося соединения сигнализации, выделенного для этого конкретного события позиционирования для UE 120.

В любом случае после приема данных помощи UE 120 продолжает представлять отчеты об измерениях в RRC сообщении Measurement Report на RAN/SRNC 130, которая в свою очередь продолжает парой сообщений PCAP Position Periodic Request и PCAP Position Periodic Response или в качестве альтернативы сообщений PCAP Position Periodic Report и PCAP Position Periodic Result, как описано выше. Запрос новых данных помощи посредством UE 120 на этапе 6i и их предоставление посредством одного из описанных выше вариантов осуществления также может происходить несколько раз в потоке 600 сообщений.

В течение потока 600 сообщений по фиг.6 могут возникать случайным образом некие исключительные ситуации, которые требуют некоторого дополнительного действия. Если UE 120 изменяет обслуживающую сотовую ячейку, но остается в пределах зоны обслуживания RAN/SRNC 130, то RAN/SRNC 130 может уведомлять SAS 132 о новой сотовой ячейке путем посылки на SAS 132 сообщения PCAP Position Parameter Modification (Модификация параметров позиционирования), содержащего идентификационную информацию новой сотовой ячейки. Это сообщение может быть таким же, как таковое, разрешенное в настоящее время (например, в 3GPP TS 25.305) для изменения сотовой ячейки внутри-RNC с помощью одиночного однократного позиционирования в режиме «с центральным SAS». RAN/SRNC 130 может также посылать сообщение PCAP Position Parameter Modification на SAS 132, если имеется изменение состояния RRC в течение продолжающейся RRC-процедуры измерения. В случае некоторых других исключительных ситуаций, например жесткой передачи обслуживания на другой RNC, UE 120 и/или RAN/SRNC 130 могут прерывать процедуру периодического определения местоположения, и MSC/SGSN 140 может повторно вызывать на исполнение процедуру (например, путем сигнализации на новый RAN/SRNC).

Основывающиеся на RAN потоки сообщений периодической передачи отчетов о местоположении, показанные на фиг.4, 5 и 6 с весьма небольшими изменениями, описанными ниже, могут использоваться для периодической передачи отчетов о местоположении для (запросов) MT-LR (фиг.2A) и для периодической передачи отчетов о местоположении для (запросов) NI-LR (фиг.2B), например, если UE 120 или MSC/SGSN 140 не могут поддерживать или не дают согласие на поддержку процедуры периодического определения местоположения посредством запросов MO-LR, которые фиг.4, 5 и 6 теперь показывают или предполагают. Основывающаяся на RAN периодическая передача отчетов о местоположении может использоваться, если абонент UE не отклоняет запрос определения местоположения в случае MT-LR, где на этапе 5 согласно фиг.2A используются уведомление и проверка конфиденциальности. Изменениями для потоков сообщений на фиг.4, 5 и 6 являются изложенные ниже.

На фиг.4 этапы 1-4 удалены. Вместо них MSC/SGSN 140 выполняет поисковый радиовызов и аутентификацию (например, как описано для этапе 5 на фиг.2A), если UE 120 возвратился в неактивный режим. Однако не должно быть какого-либо уведомления и проверки конфиденциальности (показано на этапе 5 на фиг.2A), поскольку это было сделано ранее в качестве части потока 200 сообщений по фиг.2A или (если необходимо) потока 210 сообщений по фиг.2B. Если UE 120 не находится в неактивном режиме, то поисковый радиовызов и аутентификация не требуются. Этап 12 также удален, но этап 13 остается действительным.

На фиг.5 и 6 этап 1 теперь должен включать в себя только поисковый радиовызов и аутентификацию, если UE 120 находится в неактивном режиме, как описано выше для изменений к фиг.4. Этап 11 теперь соответствует только этапу 13 (а не обоим этапам 12 и 13) на фиг.4.

Для потока 400 сообщений, показанного на фиг.4, относительно длинная транзакция (запроса) MO-LR может происходить от этапа 4 до этапа 12. В течение этого времени UE 120 может не иметь сведений об успехе или неудаче каждой передачи (данных) местоположения и информируется относительно результатов периодического отчета о местоположении после завершения передачи отчетов. Однако открытая транзакция MO-LR может быть полезной, чтобы поддерживать соединение CM и MM/GMM с UE 120 и предотвращать UE 120 от возврата в неактивный режим. Может быть желательным поддерживать UE 120 информированным относительно хода периодической передачи отчетов о местоположении, используя услуги LCS для обновления.

На фиг.7 показан вариант осуществления потока сообщений 700 для основывающейся на RAN периодической передачи отчетов с уведомлением. Поток сообщений 700 может также использоваться для этапа 10 потоков сообщений 200, 210 и 300 по фиг.2A, 2B и 3 соответственно. Этапы 1-4 потока сообщений 700 являются такими же, как этапы 1-4 потока 400 сообщений по фиг.4. UE 120 посылает на MSC/SGSN 140 сообщение LCS MO-LR Location Services Invoke, чтобы запустить периодическую передачу отчетов о местоположении (этап 4). MSC/SGSN 140 посылает сообщение LCS MO-LR Return Result на UE 120, чтобы подтвердить вызов (процедуры) (этап 5), обеспечивая таким образом немедленную обратную связь на UE 120, что запрос MO-LR будет поддержан. MSC/SGSN 140 также посылает на RAN 130 сообщение Location Request, которое содержит информацию о периодическом определении местоположения и QoS услуги LCS (этап 6).

Затем выполняется поток сообщений, чтобы получить первую оценку местоположения для UE 120 и передать оценку местоположения на LCS клиент 170 (этап 7a). Этап 7a может включать в себя этапы 6a-11a потока 400 сообщений по фиг.4, этапы 3-10a потока 500 сообщений по фиг.5 или этапы 3-10a потока 600 сообщений по фиг.6. MSC/SGSN 140 затем посылает на UE 120 сообщение LCS Location Update Invoke, чтобы указать, что первая оценка местоположения была успешно передана на LCS клиент 170 (этап 8a). Это сообщение может также использоваться, чтобы уведомлять UE 120, что будет передаваться вторая оценка местоположения в следующее событие передачи отчета о местоположении, например, после следующего интервала периодической передачи. UE 120 посылает LCS сообщение Location Update Return Result (Возврат результата обновления местоположения) на MSC/SGSN 140, чтобы подтвердить получение уведомления (этап 9a). Это сообщение может включать в себя отказ от следующей передачи отчета о местоположении, если UE 120 желает отменить процедуру периодического определения местоположения в этот момент времени.

Для каждого последующего события i передачи отчета о местоположении для i=b...n выполняется поток сообщений, чтобы получить и передать оценку местоположения для UE 120 на LCS клиент 170 (этап 7i), сообщение LCS Location Update Invoke посылается на MSC/SGSN 140, чтобы уведомить UE 120 относительно результатов передачи местоположения (этап 8i), и LCS сообщение Location Update Return Result посылается на UE 120, чтобы подтвердить уведомление (этап 9i). После того, как все события передачи отчета о местоположении выполнены, MSC/SGSN 140 может побуждать разъединение CM, ММ или GMM и RR/RRC соединений с UE 120 (этап 10).

В другом варианте осуществления сообщение LCS запроса MO-LR Return Result не посылают на этапе 5 на фиг.7, а посылают вместо этого после этапа 9n аналогично потоку 400 сообщений по фиг.4. В этом случае посылка сообщений LCS Location Update Invoke от MSC/SGSN 140 на UE 120 на этапах 8a... 8n по фиг.7, обеспечивает обратную связь на UE 120, что запрос MO-LR будет поддержан, а также результат каждой передачи местоположения на UE 120.

В альтернативном варианте осуществления сообщение LCS Location Update Invoke (Запуск обновления местоположения) на каждом этапе 8i и сообщение LCS Location Update Return Result на каждом этапе 9i заменены на сообщение LCS Notification Invoke (Запуск уведомления) и LCS Notification Return Result (Возврат результата уведомления) соответственно, которые являются существующими сообщениями 3GPP, определенными в 3GPP TS 24.080. Использование существующего сообщения 3GPP может уменьшать влияния реализации на MSC/SGSN 140 и UE 120.

В следующем варианте осуществления обмениваются либо парой из сообщения LCS Location Update Invoke и сообщения LCS Location Update Return Result, либо парой из сообщения LCS Notification Invoke и сообщения LCS Notification Return Result прежде каждого события передачи отчета о местоположении (не показано на фиг.7) вместо обмена после события (как показано на фиг.7). Для этого варианта осуществления сообщение LCS Location Update Invoke или сообщение LCS Notification Invoke информирует UE 120, что оценка местоположения будет получена и передана на LCS клиент 170 в следующем событии передачи отчета о местоположении. UE-пользователю затем может быть дана возможность отклонить передачу или отменить периодическую передачу отчетов о местоположении. Сообщение может также информировать UE 120 относительно результатов предыдущей передачи (например, была ли передача успешной или неудачной, если не была получена оценка местоположения). В очередном варианте осуществления посылаются либо пара из сообщения LCS Location Update Invoke и сообщения LCS Location Update Return Result, либо пара из сообщения LCS Notification Invoke и сообщения LCS Notification Return Result прежде каждого события передачи отчета о местоположении, и заключительная пара этих сообщений посылается после последнего события передачи отчета о местоположении. Пара сообщений прежде каждого события передачи отчета о местоположении передает на UE 120 результат предыдущей передачи местоположения (если имеется), позволяет UE 120 отклонять передачу или отменять процедуру и информирует UE 120 относительно следующей передачи. Пара сообщений после последнего события передачи отчета о местоположении информирует UE 120 относительно завершения периодической передачи отчетов о местоположении и результатов передач местоположений.

Для UE 120 может быть желательным выполнять периодическое автоопределение местоположения, чтобы периодически определить свое собственное местоположение для своего собственного использования или от имени некоторого внешнего приложения (например, доступного через Internet), с которым UE 120 находится во взаимодействии. Если UE 120 поддерживает режим «на основе UE», то UE 120 может вычислять оценки местоположения само о себе всякий раз, когда необходимо, возможно без какой-либо сигнализации с помощью RAN 130. Однако, если UE 120 только поддерживает режим «с помощью UE» или не имеет возможности определения местоположения, то будут понесены непроизводительные издержки, чтобы периодически устанавливать и разрывать каждую транзакцию определения местоположения в RAN 130 для каждого запроса MO-LR автоопределения местоположения, если каждый такой запрос побуждает только одиночный однократный запрос местоположения. Эти непроизводительные издержки могут быть снижены или их можно избежать, используя возможности периодических LCS в RAN 130 для периодического автоопределения местоположения.

На фиг.8 показан вариант осуществления потока сообщений 800 для основывающегося на RAN запроса MO-LR периодического автоопределения местоположения. Периодическое автоопределение местоположения может рассматриваться в качестве особого случая периодической передачи отчета о местоположении, где LCS клиентом является UE 120 вместо внешнего LCS клиента 170.

Этапы 1-3 потока сообщений 800 являются такими те же, как этапы 1-3 потока 400 сообщений по фиг.4. Затем UE 120 посылает на MSC/SGSN 140 сообщение LCS MO-LR Location Services Invoke, чтобы запрашивать периодическое автоопределение местоположения (этап 4). Это сообщение содержит соответствующую информацию, такую как, например, информация о периодическом определении местоположения (например, время начала, интервал передачи отчетов, и один параметр из времени останова, продолжительности передачи отчетов или заранее заданного числа отчетов), QoS услуги LCS и так далее. Сообщение также указывает, что периодические оценки местоположения должны быть посланы на UE 120. MSC/SGSN 140 проверяет, что UE 120 авторизован для запрошенной услуги определения местоположения, на основании профиля подписки для UE (также этап 4). Если запрос местоположения авторизован, то MSC/SGSN 140 посылает на UE 120 сообщение LCS MO-LR Return Result, чтобы указать принятие запроса периодического автоопределения местоположения (этап 5). MSC/SGSN 140 также посылает на RAN 130 сообщение Location Request, которое содержит запрос периодического автоопределения местоположения, информацию о периодическом определении местоположения, возможности UE, и QoS услуги LCS (этап 6).

Затем выполняется поток сообщений, чтобы получить первую оценку местоположения для UE 120 (этап 7a). Этап 7a может включать в себя этапы 3-8a потока 500 сообщений по фиг.5 или этапы 3-8a потока 600 сообщений по фиг.6. RAN 130 принимает оценку местоположения для UE 120 от потока сообщений на этапе 7a и посылает на MSC/SGSN 140 сообщение Location Report, которое содержит эту оценку местоположения и другую соответствующую информацию (этап 8a). MSC/SGSN 140 затем посылает на UE 120 сообщение LCS Location Update, содержащее первую оценку местоположения и соответствующую информацию (этап 9a). UE 120 возвращает сообщение LCS Location Update Acknowledgment, которое подтверждает прием первой оценки местоположения (этап 10a). Это сообщение может также включать в себя указание отменить периодическое автоопределение местоположения, если такое желательно для UE 120. Для каждого последующего события i автоопределения местоположения, для i=b...n, выполняется поток сообщений, чтобы получить оценку местоположения для UE 120 (этап 7i) и послать оценку местоположения на MSC/SGSN 140 (этап 8i). MSC/SGSN 140 затем возвращает оценку местоположения на UE 120 (этапы 9i и 10i). После того, как события передачи отчета о местоположении выполнены, MSC/SGSN 140 может побуждать разъединение CM, ММ или GMM, и RR/RRC соединений с UE 120.

В другом варианте осуществления сообщение LCS MO-LR Return Result не посылают на этапе 5 по фиг.8, а посылают вместо этого после этапа 10n аналогично потоку 400 сообщений по фиг.4. В следующем варианте осуществления сообщение LCS Location Update в каждом этапе 9i и LCS LCS Location Update Acknowledgment в каждом этапе 10i заменено на сообщение LCS Notification Invoke и сообщение LCS Location Update Acknowledgment соответственно, которые являются существующими 3GPP-сообщениями. Опять использование существующих 3GPP-сообщений может уменьшить влияние реализации на MSC/SGSN 140 и UE 120.

Основывающаяся на RAN периодическая передача отчетов о местоположении также может использоваться для мобильных станций (MS), взаимодействующих с GERAN. Периодическая процедура передачи отчетов о местоположении режима с коммутацией пакетов может использоваться для периодического запроса местоположения, принимаемого посредством 2G-SGSN 140a по фиг.1B. Процедура периодической передачи отчетов о местоположении режима с коммутацией каналов может использоваться для периодического запроса местоположения, принимаемого посредством 2G-MSC 140b. Для периодической GERAN-передачи отчета о местоположении в режиме с коммутацией каналов MS может действовать в выделенном режиме и может быть назначен канал сигнализации (например, индивидуальный канал управления, SDCCH) на полную продолжительность передачи периодического отчета о местоположении, поскольку подсистема базовой станции (BSS) в GSM не имеет возможности динамически разъединять и впоследствии повторно назначать выделенный канал сигнализации в течение интервалов периодического определения местоположения. Для периодической GERAN-передачи отчета о местоположении в режиме с коммутацией пакетов MS может быть динамически назначен канал сигнализации, когда необходимо передавать сообщение между MS и BSS. В нижеследующем описании UE 120 (терминология UMTS) именуется MS 120 (терминология GSM). MS 120 взаимодействует с BSS в GERAN 130a.

На фиг.9 показан вариант осуществления потока 900 сообщений для основывающейся на RAN периодической передачи отчетов для GERAN в режиме с коммутацией пакетов. LCS клиент 170 или MS 120 могут инициировать запрос, чтобы периодически посылать оценки местоположения для MS 120 на LCS клиент 170 (этап 1). Периодическое определение местоположения может вызываться запросами MT-LR, NI-LR или MO-LR, например, как описано выше для фиг.2A, 2B или 3 соответственно. Запрос периодического определения местоположения может передаваться на SGSN 140a через один или несколько GMLC для MT-LR, инициированного посредством LCS клиента 170, или через BSS для MO-LR, инициированного посредством MS 120. Запрос может включать в себя информацию о периодическом определении местоположения, устанавливающую план или условия (например, события) для посылки оценок местоположения. Запрос может быть согласован участвующими объектами, например несколькими GMLC 150, SGSN 140a, MS 120, и LCS клиентом 170. Периодическая доставка местоположения после этого может быть начата либо посредством MO-LR от MS 120, либо посредством SGSN 140a, который может выполнять поисковый радиовызов и аутентификацию, если MS 120 вернулась к неактивному режиму.

SGSN 140a посылает сообщение BSSGP Perform Location Request (Запрос выполнения определения местоположения) на BSS, в настоящее время обслуживающую MS 120 (этап 2). Это сообщение содержит запрос периодического определения местоположения и дополнительно включает в себя информацию о периодическом определения местоположения, QoS, и/или другую соответствующую информацию. BSS принимает сообщение и идентифицирует, что запрос предназначен предпочтительнее для периодического определения местоположения, чем для одиночного разового определения местоположения. BSS затем посылает запрос периодического определения местоположения и информацию о периодическом определении местоположения в сообщении BSSMAP-LE Perform Location Request на SMLC 132 (этап 3).

SMLC 132 принимает сообщение от BSS, оценивает запрос периодического определения местоположения и выбирает способ определения местоположения. Если выбраны A-GPS и/или E-OTD, то SMLC 132 посылает на BSS сообщение BSSMAP-LE Connection Oriented Information (Ориентированная на соединение информация), которое содержит сообщение BSSLAP MS Position Command, которое дополнительно содержит сообщение RRLP Measure Position Request (этап 4). Сообщение BSSLAP MS Position Command (Команда позиционирования) может нести указание, что запрашивается периодическое определение местоположения, и BSS может записать эту информацию. Сообщение RRLP Measure Position Request (Запрос измерения позиции) может содержать информацию о периодическом определении местоположения, поднабор этой информации или преобразованный набор или поднабор этой информации. Сообщение RRLP Measure Position Request может также содержать данные помощи, чтобы содействовать MS 120 выполнять измерения A-GPS и/или E-OTD и, если выбрано позиционирование на основе MS, то помогать MS 120 вычислять оценку местоположения. Если данные помощи не помещаются ни в одно сообщение RRLP Measure Position Request, то SMLC 132 может посылать некоторые или все данным помощи и другую информации, включая информацию о периодическом определении местоположения, на MS 132 в одном или нескольких сообщениях RRLP Assistance Data (Данные помощи) (не показано на фиг.9) перед посылкой сообщения RRLP Measure Position Request. MS 120 затем будет подтверждать каждое сообщение RRLP Assistance Data с помощью сообщения RRLP Assistance Data Acknowledgment (Подтверждение запроса данных помощи).

BSS посылает на SGSN 140a сообщение BSSGP Position Command, содержащее сообщение RRLP Measure Position Request, полученное от SMLC 132 (этап 5). SGSN 140a затем посылает на MS 120 сообщение Frame Unconfirmed Information (UI) (кадр неподтвержденной информации, НИ) управления логическим соединением (LLC), содержащее сообщение TOM, которое несет сообщение RRLP Measure Position Request, принятое от SMLC 132 (этап 6). MS 120 принимает сообщение от SGSN 140a и опознает запрос периодического определения местоположения на основании информации о периодическом определении местоположения, включенной в сообщение RRLP Measure Position Request (или в предшествующее сообщение RRLP Assistance Data). Если выбран способ A-GPS, то MS 120 может получать (сопровождать) и измерять сигналы от спутников GPS с использованием данных помощи (если имеются) после приема сообщения RRLP Measure Position Request или предшествующего сообщения Assistance Data. Если выбран способ E-OTD, то MS 120 может начинать получать и измерять сигналы от близлежащих базовых станций. MS 120 может также получать и измерять сигналы и от спутников GPS, и от базовых станций, если выбраны оба E-OTD и A-GPS.

Когда первая плановая оценка местоположения является результатом или когда имеет место первый набор условий (например, событие), для которого оценка местоположения является необходимой, MS 120 исполняет измерения (по способу) A-GPS и/или E-OTD. Если было выбрано позиционирование на основе MS, то MS 120 дополнительно получает оценку местоположения на основании измерений. MS 120 затем посылает измерения или оценку местоположения в сообщении RRLP Measure Position Response (Ответ на запрос измерения позиции) на SGSN 140a (этап 7a). Сообщение RRLP Measure Position Response передается в сообщении TOM, которое в свою очередь передается в сообщении LLC UI Frame. Заголовок сообщения TOM включает в себя флажок указания, что сообщение RRLP Measure Position Response не является последним. Сообщение RRLP Measure Position Response может также нести указание, что впоследствии будут обеспечиваться несколько периодических оценок местоположения. MS 120 может посылать несколько сообщений RRLP Measure Position Response, если измерения или оценка местоположения не помещаются в одиночное сообщение (не показано на фиг.9).

SGSN 140a принимает сообщение LLC UI Frame от MS 120 и передает сообщение RRLP Measure Position Response в сообщении BSSGP Position Response (Ответ на запрос позиции) на BSS (этап 8a). Заголовок сообщения BSSGP Position Response включает в себя флажок, указывающий, что это не последнее сообщение RRLP Measure Position Response. BSS принимает сообщение BSSGP Position Response от SGSN 140a и передает сообщение Measure Position Response RRLP в сообщении BSSLAP MS Position Response, которое содержится в сообщении BSSMAP-LE Connection Oriented Information, на SMLC 132 (этап 9a). Заголовок сообщения BSSLAP MS Position Response включает в себя флажок, указывающий, что это не последнее сообщение RRLP Measure Position Response. BSS осведомлена о запросе периодического определения местоположения (из этапа 2 и, возможно, из этапа 4) и также из установки флажка. BSS таким образом ожидает дополнительные сообщения RRLP Measure Position Response от MS 120 и не прерывает периодическое определение местоположения прежде, чем все измерения или оценки местоположения (во внутренней части сообщений RRLP Measure Position Response) не будут переданы от MS 120.

SMLC 132 вычисляет оценку местоположения на основании измерений, предоставленных посредством MS 120, или проверяет какую-либо оценку местоположения, предоставленную посредством MS. SMLC 132 затем посылает вычисленную или проверенную оценку местоположения в сообщении BSSMAP-LE Perform Location Report (Выполнить отчет о местоположении) на BSS (этап 10a). Это сообщение информирует BSS, что периодическое определение местоположения еще не выполнено и что дополнительные оценки местоположения будут обеспечиваться впоследствии посредством SMLC 132. BSS принимает оценку местоположения от SMLC 132 и посылает эту оценку местоположения в сообщении BSSGP Perform Location Report на SGSN 140a (этап 11а). Это сообщение информирует SGSN 140a, что периодическое определение местоположения еще не закончено и что впоследствии будут обеспечиваться дополнительные оценки местоположения. SGSN 140a затем передает оценку местоположения на LCS клиент 170, например, через GMLC с использованием этапов 8a-11a на фиг.4 или через BSS.

Этапы 7a-11a предназначены для одного события передачи отчета о местоположении. Эти этапы могут быть повторены для каждой дополнительной оценки местоположения, которая запланирована или запущена. Если MS 120 неспособна получить измерения или оценку местоположения, поскольку доступные данные помощи более не являются действительными, то MS 120 может включать запрос большего количества данных помощи в сообщении RRLP Measure Position Response, посылаемом на последующем этапе 7. Этот запрос данных может посылаться вместо или в дополнение к измерениям или оценке местоположения. Приняв этот запрос на этапе 9, SMLC 132 пошлет запрошенные данные помощи на MS 120 с использованием одного или нескольких сообщений RRLP Assistance Data. В одном варианте осуществления и SMLC 132 и MS 120 обрабатывают передачу данных помощи в качестве дополнительной RRLP-транзакции, происходящей параллельно с задержанной RRLP-транзакцией для периодического определения местоположения (например, начатой на этапах 4, 5 и 6). MS 120 продолжает посылать периодические измерения или оценки местоположения на SMLC 132, повторяя этапы 7-11а. В другом варианте осуществления MS 120 может закончить передачу периодических измерений или оценок местоположения на SMLC 132 при посылке запроса большего количества данных помощи. Например, MS 120 может указать завершение периодической передачи отчета о местоположении путем включения указания ошибки в сообщение RRLP Measure Position Response, содержащем в себе запрос большего количества данных помощи. В этом случае заголовок сообщения TOM, посылаемый в последующем этапе 7, может включать в себя флажок, указывающий, что оно является последним сообщением RRLP Measure Position Response. Когда BSS принимает этот флажок от SGSN 140a в последующем этапе 8, BSS пересылает это последнее сообщение RRLP Measure Position Response на SMLC 132 и не ожидает более сообщения RRLP Measure Position Response от MS 120. SMLC 132 может повторно запустить передачу периодических измерений или оценок местоположения от MS 120 путем повторения этапов 4-11. SMLC 132 может посылать запрошенные данные помощи на MS 120 в сообщении RRLP Measure Position Request и/или одном или нескольких сообщениях RRLP Assistance Data.

MS 120 посылает заключительные измерения или оценку местоположения для периодического определения местоположения на SGSN 140a (этап 7n). Измерения или оценка местоположения посылаются в сообщении RRLP Measure Position Response, которое передают в сообщении TOM, которое далее передают в сообщении LLC UI Frame. Эти сообщения являются такими же, как таковые, используемые на этапе 7a, за исключением того, что заголовок сообщения TOM включает в себя флажок, указывающий, что оно является последним сообщением RRLP Measure Position Response. Сообщение RRLP Measure Position Response может содержать параметры, указывающие, что оно представляет последние периодические измерения или оценку местоположения. Этапы 8n-n сходны с этапами 8a-11a. Однако флажок, указывающий, что посылается последнее сообщение RRLP Measure Position Response, может быть включен в сообщение BSSGP Position Response, посылаемое на SGSN 140a на этапе 8n, а также в сообщение BSSLAP MS Position Response, посылаемое на BSS на этапе 9n. SMLC 132 может посылать сообщение BSSMAP-LE Perform Location Report на этапе 10n вместо сообщения BSSMAP-LE Perform Location Report на этапе 10a, чтобы информировать BSS, что процедура периодического определения местоположения завершилась. BSS может посылать сообщение BSSGP Perform Location Response на этапе 11n вместо сообщения BSSGP Perform Location Report на этапе 11a, чтобы информировать SGSN 140a, что процедура периодического определения местоположения завершилась. BSS более не ожидает сообщения RRLP Measure Position Response от MS 120, если SMLC 132 не побуждает новую процедуру определения местоположения. SMLC 132 может побуждать несколько периодических передач отчетов о местоположении путем повторения этапов 4-9n. SGSN 140a может продолжать периодическую передачу отчетов о местоположении, повторяя этапы 2-11n. В противном случае SGSN 140a может указать LCS клиенту 170, что периодическая передача отчетов о местоположении теперь является выполненной.

Могут возникать некие исключительные ситуации в течение потока 900 сообщений по фиг.9, которые требуют дополнительного действия. Если MS 120 меняет обслуживающую сотовую ячейку, но остается в пределах зоны обслуживания той же BSS, то BSS может уведомить SMLC 132 о новой сотовой ячейке путем посылки на SMLC сообщения BSSMAP-LE Perform Location Information (Представить информацию о местоположении), содержащего идентификационную информацию о новой сотовой ячейке. Для некоторых других исключительных ситуаций, таких как переключение сотовой ячейки на новую BSS, обновление области маршрутизации GPRS внутри-SGSN, или повторного распределения P-TMSI, MS 120 и/или BSS могут прерывать процедуру периодического определения местоположения и SGSN 140a может повторного вызывать на исполнение процедуру, например, посредством сигнализации на новую BSS.

На фиг.10 показан вариант осуществления потока 1000 сообщений для основывающейся на RAN периодической передаче отчетов для GERAN в режиме с коммутацией каналов. Поток 1000 сообщений для режима с коммутацией каналов подобен потоку 900 сообщений для режима с коммутацией пакетов. Различия таковы, что SGSN 140a заменен на 2G-MSC 140b, сообщения BSSGP между SGSN 140a и BSS заменены на соответствующие сообщения BSSMAP и передача сообщений RRLP между BSS и MS 120 является более непосредственной.

LCS клиент 170 или MS 120 могут инициировать запрос, чтобы периодически посылать оценки местоположения для MS 120 на LCS клиент 170 (этап 1). Запрос может передаваться на 2G-MSC 140b через один или несколько GMLC или через BSS. Запрос может включать в себя информацию о периодическом определении местоположения и может быть согласован участвующими объектами, например, несколькими GMLC 150, 2G-MSC 140b, MS 120 и LCS клиентом 170. Периодическая доставка местоположения после этого может быть начата или согласно запросу MO-LR от MS 120 или посредством 2G-MSC 140b, который может выполнять поисковый радиовызов и аутентификацию, если MS 120 вернулась в неактивный режим.

2G-MSC 140b посылает сообщение BSSMAP Perform Location Request на BSS, в текущее время обслуживающую MS 120 (этап 2). Это сообщение содержит запрос периодического определения местоположения и дополнительно включает в себя информацию о периодическом определении местоположения, QoS, и другую соответствующую информацию. BSS посылает запрос периодического определения местоположения в сообщении BSSMAP-LE Perform Location Request на SMLC 132 (этап 3). SMLC 132 принимает сообщение, оценивает запрос периодического определения местоположения и выбирает способ определения местоположения. Если выбраны A-GPS и/или E-OTD, то SMLC 132 посылает на BSS сообщение BSSMAP-LE Connection Oriented Information, которое содержит сообщение BSSLAP MS Position Command, которое дополнительно содержит сообщение RRLP Measure Position Request (этап 4).

BSS посылает на MS 120 сообщение RR Application Information (Информация приложения), содержащее сообщение RRLP Measure Position Request, принятое от SMLC 132 (этап 5). MS 120 принимает сообщение от BSS и опознает запрос периодического определения местоположения на основании информации периодического определения местоположения, включенной в сообщение RRLP Measure Position Request (или в предшествующее сообщение RRLP Assistance Data). MS 120 может получать и измерять сигналы от спутников GPS (для A-GPS) и/или соседней базовой станции (для E-OTD).

Когда первая плановая оценка местоположения является результатом, или когда происходит первый набор условий (например, событие), для которого оценка местоположения является необходимой, MS 120 выполняет измерения A-GPS и/или E-OTD и дополнительно получает оценку местоположения, если было выбрано позиционирование на основе MS. MS 120 затем посылает измерения или оценку местоположения в сообщении RRLP Measure Position Response, которое передается в сообщении RR Application Information на BSS (этап 6a). Заголовок сообщения RR Application Information включает в состав флажок, указывающий, что оно не является последним сообщением RRLP Measure Position Response. Сообщение RRLP Measure Position Response может также содержать в себе указание, что впоследствии будут обеспечиваться большее количество периодических оценок местоположения.

BSS принимает сообщение RR Application Information от MS 120 и передает сообщение RRLP Measure Position Response в сообщении BSSLAP MS Position Response, которое передают на SMLC 132 в сообщении BSSMAP-LE Connection Oriented Information (этап 7a). Заголовок сообщения BSSLAP MS Position Response включает в себя флажок, указывающий, что оно не является последним сообщением RRLP Measure Position Response. SMLC 132 вычисляет оценку местоположения исходя из измерений, обеспеченную посредством MS 120, или проверяет какую-либо оценку местоположения, обеспеченную посредством MS. SMLC 132 затем посылает на BSS вычисленную или проверенную оценку местоположения в сообщении BSSMAP-LE Perform Location Report (этап 8a). BSS принимает оценку местоположения от SMLC 132 и посылает эту оценку местоположения в сообщении BSSMAP Perform Location Report на 2G-MSC 140b (этап 9a). 2G-MSC 140b затем передает оценку местоположения на LCS клиент 170, например, через GMLC или BSS.

Этапы 6a-9a предназначены для одного события передачи отчета о местоположении. Эти этапы могут быть повторены для каждой дополнительной оценки местоположения, которая запланирована или инициирована. MS 120 может получать большее количество данных помощи путем посылки запроса в сообщение RRLP Measure Position Response на последующем этапе 6. SMLC 132 и MS 120

рассматривают передачу данных помощи в качестве дополнительной RRLP-транзакции, происходящей параллельно с задержанной RRLP-транзакции для периодического определения местоположения. В качестве альтернативы MS 120 может завершить передачу периодических измерений или оценок местоположения, например, путем включения флажка в заголовок сообщения RR Application Information, чтобы указать, что оно является последним сообщением RRLP Measure Position Response. SMLC 132 может затем повторно вызывать на исполнение передачу периодических измерений или оценок местоположения от MS 120, повторяя этапы 4-9.

MS 120 посылает на BSS заключительные измерения или оценку местоположения для периодического определения местоположения (этап 6n). Измерения или оценка местоположения посылаются в сообщении RRLP Measure Position Response, которое передают в сообщении RR Application Information. Эти сообщения являются такими же, как таковые используемые на этапе 6a, за исключением того, что заголовок сообщения RR Application Information включает в себя флажок, указывающий, что оно является заключительным сообщением RRLP Measure Position Response. Сообщение RRLP Measure Position Response может содержать параметры, указывающие, что это является последними периодическими измерениями или оценкой местоположения. Этапы 7n-9n сходны с этапами 7a-9a. Однако сообщение BSSLAP MS Position Response, посылаемое посредством BSS на этапе 7n, включает в себя флажок, указывающий, что послано заключительное сообщение RRLP Measure Position Response. SMLC 132 может посылать сообщение BSSMAP-LE Perform Location Response (Ответ на выполнение отчета о местоположении) на этапе 8n, и BSS может посылать сообщение BSSMAP Perform Location Response на этапе 9n, чтобы указать, что процедура периодического определения местоположения завершилась. SMLC 132 может побуждать несколько периодических передач отчетов о местоположении, повторяя этапы 4-7n. 2G-MSC 140b может продолжать периодическую передачу отчетов о местоположении, повторяя этапы 2-9n. В противном случае 2G-MSC 140b может указывать LCS клиенту 170, что периодическая передача отчетов о местоположении теперь является выполненной.

В течение потока 1000 сообщений по фиг.10 могут возникать некоторые исключительные ситуации, которые требуют дополнительного действия. Если MS 120 меняет обслуживающую сотовую ячейку, но остается в пределах зоны обслуживания той же BSS или если между BSS и MS 120 проводится некоторая другая RR процедура управления, которая по-прежнему оставляет между BSS и MS 120 канал сигнализации радиосвязи режима с коммутацией каналов, то MS 120 может прерывать позиционирование, и SMLC 132 может повторно вызывать на исполнение позиционирование в MS 120 для или одиночного однократного или периодического определения местоположения. В качестве альтернативы, BSS может информировать SMLC 132 о любом изменении сотовой ячейки (например, путем посылки сообщения BSSMAP-LE Perform Location Information), и MS 120, BSS и SMLC 132 могут продолжать периодическое позиционирование. Для некоторых других исключительных ситуаций, таких как передача обслуживания на новую BSS, MS 120 и/или BSS могут прерывать процедуру периодического определения местоположения, и 2G-MSC 140b может повторного вызывать на исполнение процедуру, например, путем сигнализации на новую BSS.

Многие из сообщений по фиг.9 и 10 описаны в документе 3GPP TS 43.059 и используются для однократного определения местоположения MS. Эти сообщения могут использоваться для периодического определения местоположения, когда только возможно, для того, чтобы упростить реализацию периодического определения местоположения. Другие сообщения также могут использоваться для фиг.9 и 10.

На фиг.4-10 показаны примерные потоки сообщений, которые могут использоваться для основывающейся на RAN периодической передаче отчетов о местоположении. Потоки сообщений на фиг.4-7, 9 и 10 могут использоваться в качестве части периодических процедур для MT-LR и MO-LR, показанных на фиг.2A и 3 соответственно после того, как запрос периодического определения местоположения был авторизован. Эти потоки сообщений также могут использоваться в качестве автономных процедур и, следовательно, не ограничены, чтобы являться частью периодических процедур для MT-LR и MO-LR. Другие потоки сообщений для основывающейся на RAN периодической передаче отчетов о местоположении также могут быть реализованы для использования с периодическими процедурами для MT-LR и MO-LR.

UE 120 может первоначально взаимодействовать с RAN (например, GERAN), которая не имеет возможностей периодических услуг LCS и не поддерживает потоки сообщений согласно фиг.4-10. Периодическая передача отчетов о местоположении может тогда достигаться другим образом, например с помощью UE 120 или сетевого объекта (например, GMLC 150), периодически инициирующих поток сообщений, чтобы получать и передавать одиночную оценку местоположения для UE 120 на LCS клиент 170. Если UE, который 120 впоследствии перемещается в пределы зоны обслуживания RAN (например, UTRAN), которая имеет возможности периодических услуг LCS, то UE 120 может переключаться на новую RAN, и возможности периодических услуг LCS этой новой RAN могут использоваться, чтобы эффективно обеспечивать периодическую передачу отчетов о местоположении.

Для простоты, описание выше для основывающейся на RAN периодической передачи отчетов о местоположении предполагает развертывание системы с наличием одного GMLC (например, как показано на фиг.1A) и позиционирования, выполняемого для каждой оценки местоположения. Основывающаяся на RAN периодическая передача отчетов о местоположении может также использоваться для развертывания с наличием многих GMLC (например, как показано на фиг.1B). Повышенную эффективность можно достичь посредством применения (1) «короткой» схемы GLMC для развертывания с многими GMLC и (2) «короткой» схемы MO-LR для развертывания с одним или многими GMLC. Короткая схема GLMC относится к обмену сообщениями непосредственно между R-GMLC 150c и MSC/SGSN 140 по фиг.1B, таким образом обходя или замыкая «накоротко» V-GMLC 150a и H-GMLC 150b. Короткая схема для MO-LR относится к обходу позиционирования для каждого события передачи отчета о местоположении, если соответствующая оценка местоположения является доступной для UE 120, и разрешено использование короткой схемы MO-LR. Короткая схема GMLC, короткая схема MO-LR или оба типа коротких схем могут использоваться, чтобы экономить ресурсы системы и обеспечивать более быстрый ответ для передачи местоположения на LCS клиент 170. И короткая схема MO-LR, и основывающаяся на RAN периодическая передача отчетов могут использоваться для определения местоположения «на основе UE». Однако, если UE не поддерживает короткую схему MO-LR, или LCS клиент или любая из включенных в состав PLMN отклоняют использование короткой схемы MO-LR, то только основывающееся на RAN периодическое позиционирование может быть соответствующим для определения местоположения «на основе UE». Напротив, если RAN (например, GERAN) не поддерживает основывающуюся на RAN периодическую передачу отчета, то только короткая схема MO-LR может быть соответствующей (если разрешена и поддержана). Для определения местоположения «с помощью UE» или определения местоположения «на основе сети» (например, для UE, которое поддерживает позиционирование только «с помощью UE»), короткая схема MO-LR не используется и только основывающееся на RAN позиционирование может быть подходящим. Следовательно, короткая схема MO-LR и основывающаяся на RAN периодическая передача отчетов может быть применимой при различных обстоятельствах.

Использование короткой схемы MO-LR может быть управляемым по различным причинам, таким как, например, чтобы рассматривать недостаточность доверия в точности и надежности UE, или целостности UE (например, при попытке несанкционированного доступа) для вопросов составления счетов и подписки и так далее. Например, использование короткой схемы MO-LR может быть разрешено, если UE 120 является доверенным, чтобы поставлять оценки местоположения непосредственно на MSC/SGSN 140 без проверки посредством RAN 130. Использование короткой схемы GLMC может также быть управляемым по причинам, касающимся составления счетов, подписки и так далее.

В варианте осуществления один объект (например, UE 120, MSC/SGSN 140, или R-GMLC 150c) может запросить разрешение для использования короткой схемы GMLC и/или короткой схемы MO-LR для последующего события передачи отчета о местоположении. Любой другой объект (например, MSC/SGSN 140, V-GMLC 150a, H-GMLC 150b, R-GMLC 150c, UE 120 и LCS клиент 170) может принимать или отклонять запрос о каждом типе короткой схемы. В другом варианте осуществления один объект (например, UE 120, MSC/SGSN 140, или R-GMLC 150c) может указывать готовность или возможность поддерживать короткую схему GMLC и/или короткую схему MO-LR без осуществления специально запроса на использование этих коротких схем. Любой объект из числа V-GMLC 150a, H-GMLC 150b, R-GMLC 150c, UE 120 и LCS клиента 170 может затем принимать или отклонять готовность или возможность поддерживать каждый тип короткой схемы. Один объект (например, H-GMLC 152) может решать, использовать ли каждый тип короткой схемы, если все объекты указывают готовность и возможность для этой короткой схемы. Для всех вариантов осуществления запрос на использование “короткой” схемы GMLC и запрос на использование “короткой” схемы MO-LR могут рассматриваться как независимые запросы. Кроме того, любое соглашение по использованию короткой схем GMLC и/или короткой схемы MO-LR могут быть применимыми для всех PLMN в перечне, посланном посредством MSC/SGSN 140 на UE 120.

В следующем варианте осуществления любой объект из числа UE 120, MSC/SGSN 140, V-GMLC 150a, H-GMLC 150b, и R-GMLC 150c может автономно решать, использовать ли короткую схему GLMC и использовать ли короткую схему MO-LR.

Для MT-LR потока 200 сообщений по фиг.2A, R-GMLC 150c может посылать сообщение LCS Service Request (Запрос услуги LCS) на H-GMLC 150b, который может посылать сообщение LCS Service Request на V-GMLC 150a, который может посылать сообщение Provide Subscriber Location (Предоставить местоположение абонента) на MSC/SGSN 140, чтобы запросить периодическую передачу отчетов о местоположении. Сообщение, посылаемое каждым объектом, может содержать (1) адрес R-GMLC 150c, если предпочтительна короткая схема GMLC, и (2) указание относительно того, разрешена ли или предпочтительна короткая схема MO-LR. В варианте осуществления R-GMLC 150c, H-GMLC 150b, V-GMLC 150a и MSC/SGSN 140 могут каждый принять или отклонить использование короткой схемы GMLC, и каждый может принять или отклонить использование короткой схемы MO-LR.

Для MO-LR-потока 300 сообщений по фиг.3 UE 120 может включать в себя (1) запрос на использование короткой схемы GMLC и/или (2) запрос на использование короткой схемы MO-LR (например, если UE 120 поддерживает режим «на основе UE») в сообщении LCS MO-LR Location Services Invoke, посылаемом на MSC/SGSN 140 на этапе 4 потока 300 сообщений. В другом варианте осуществления MSC/SGSN 140 может принимать решение одного или обоих запросов самостоятельно без указания от UE 120. В любом случае запрос(ы) “короткий” схемы могут пересылаться на V-GMLC 150a, затем на H-GMLC 150b, затем на R-GMLC 150c и затем на LCS клиент 170. LCS клиент 170 посылает ответ на запрос(ы) UE на R-GMLC 150c, который посылает свой ответ на H-GMLC 150b, который посылает его ответ на V-GMLC 150a, который посылает свой ответ на MSC/SGSN 140. Посылаемый каждым объектом ответ включает в себя ответ, принятый от предшествующего объекта (если имеется), и указывает принятие или отклонение запроса периодического определения местоположения и принятие или отклонение каждого запроса короткой схемы (если послан).

Для обоих и MT-LR-потока 200 сообщений, и MO-LR-потока 300 сообщений, MSC/SGSN 140 может принимать нижеследующую информацию (в виде дополнительной к информации, приведенной выше):

1) указание короткий схемы MO-LR, которое указывает, разрешается ли или ожидается, что UE 120 поставляет оценки местоположения непосредственно на MSC/SGSN 140 без проверки в RAN 130,

2) указание короткой схемы GMLC, которое указывает, могут ли или будут ли оценки местоположения посланы непосредственно на R-GMLC 150c,

3) адрес H-GMLC 150b, подлежащий использованию, чтобы посылать информацию местоположения на H-GMLC 150b, например, если короткая схема GMLC не запрошена или отклонена, и

4) адрес R-GMLC 150c, подлежащий использованию, чтобы посылать информацию местоположения непосредственно от MSC/SGSN 140 на R-GMLC 150c, например, если короткая схема GMLC принята.

Если короткая схема MO-LR разрешена, то UE 120 может включать в себя доступную в UE оценку местоположения в сообщение LCS MO-LR Location Services Invoke, посылаемое на MSC/SGSN 140. RAN 130, или SAS 132 не будут нуждаться в вычислении оценки местоположения для UE 120.

Если короткая схема GMLC принята, то MSC/SGSN 140 может хранить адрес R-GMLC 150c, или UE 120 может посылать адрес R-GMLC в каждом событии передачи отчета о местоположении. MSC/SGSN 140 может затем посылать каждую оценку местоположения непосредственно на R-GMLC 150c с использованием адреса R-GMLC и может обходить V-GMLC 150a и H-GMLC 150b.

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

Также для ясности, для потоков сообщений согласно фиг.2-10 показаны конкретные сообщения, используемые согласно (или применимые для) 3GPP. Другие сети и другие структуры определения местоположения обычно используют сообщения, которые отличаются от сообщений, описанных выше. В целом, может использоваться любая сигнализация, чтобы обмениваться соответствующей информацией между различными объектами, чтобы осуществить описанную выше функциональность для передачи отчетов о местоположении. Сигнализация может содержать сообщения, пакеты, указания, флажки или данные, посылаемые в некоторой другой форме.

Для ясности вышеуказанные способы были конкретно описаны для сетей на основе 3GPP, использующих плоскость управления, чтобы поддерживать услуги определения местоположения. Способы также могут использоваться для других сетей и другой архитектуры определения местоположения, такой как архитектура SUPL и архитектура pre-SUPL, опубликованная Открытым союзом (OMA) по мобильной связи, архитектура плоскости управления 3GPP2, описанная в IS-881 и 3GPP2 X.S0002, 3GPP2 архитектура плоскости пользователя, описанная в X.S0024, и так далее. Плоскость управления (которая также обычно называется плоскостью сигнализации) является механизмом для переноса сигнализации для приложений более высокого уровня и может быть осуществлена с помощью конкретно определенных для сети протоколов и сообщений сигнализации. Плоскость пользователя является механизмом переноса данных для приложений более высокого уровня и применяет носитель плоскости пользователя, который обычно реализуется с помощью протоколов, таких как протокол пользовательских дейтаграмм (UDP), протокол управления передачей (TCP) и Internet-протокол (IP), все из которых являются известными в области техники. Сообщения, поддерживающие услуги определения местоположения и позиционирования, являются переносимыми (передаются) в виде части сигнализации в архитектуре плоскости управления и в виде части данных в архитектуре плоскости пользователя. Содержимое сообщений может, однако, быть сходным или даже идентичным в обеих архитектурах. Способы короткой схемы также могут использоваться для режимов на основе коммутации каналов (CS) и для режимов на основе коммутации пакетов (PS), хотя сообщения могут быть различными.

На фиг.11 показано развертывание 1100 системы SUPL, которая включает в себя посещаемую/обслуживающую сеть 1102, домашнюю сеть 1104 и запрашивающую сеть 1106. Посещаемая сеть 1102 включает в себя сеть 1130 беспроводной связи и SUPL-платформу (V-SLP) определения местоположения посещений 1150a. Сеть 1130 беспроводной связи обеспечивает беспроводную связь для устройств беспроводной связи, расположенных в пределах зоны обслуживания сети беспроводной связи. Беспроводное устройство также называют терминалом (SET) с возможностью SUPL. V-SLP 1150a включает в себя центр (SLC) 1180 SUPL-определения местоположения и может включать в себя центр (SPC) 1182 SUPL-позиционирования. SLC 1180 сходен с V-GMLC 150a и выполняет различные функции для услуг определения местоположения. SPC 1182 сходен с SMLC/SAS 132 и поддерживает позиционирование для беспроводных устройств. Домашняя сеть 1104 включает в себя домашний SLP (H-SLP) 1150b, который поддерживает услуги определения местоположения и позиционирования для домашней сети 1104. Запрашивающая сеть 1106 включает в себя запрашивающий SLP (R-SLP) 1150c, который поддерживает услуги определения местоположения и позиционирование для LCS клиентов.

Способы, описанные в документе, могут использоваться в развертывании 1100 SUPL. Для основывающейся на RAN периодической передачи отчетов о местоположении V-SLP 1150a или H-SLP 1150b могут координировать и управлять периодической передачей отчетов для устройства беспроводной связи 1120, например, как описано выше. В этом случае RAN не будет конкретно участвовать, и роль RAN исполняется посредством V-SLP 1150a и/или H-SLP 1150b, и/или посредством SPC в пределах любого из них (например, посредством SPC 1182). Взаимодействие сообщений (например, передача сообщения RRC Measurement Control и сообщения RRC Measurement Report) между UE 1120 и V-SLP 1150a или H-SLP 1150b будет тогда сходной с обменом этими сообщениями между UE 120 и RAN/SRNC 130 по фиг.5 и 6 за исключением того, что сообщения (например, сообщения RRC) будут передаваться иначе, например, с использованием TCP/IP и протокола SUPL-позиционирования, определенного OMA, вместо использования сигнализации плоскости управления 3GPP. Для короткой схемы GMLC в неуполномоченном режиме беспроводное устройство 1120 или V-SLP 1150a может посылать оценку местоположения непосредственно на R-SLP 1150c, который затем пересылает оценку местоположения на LCS клиент 1170 и обходит H-SLP 1150b и, возможно, V-SLP 1150a. Для “короткой” схемы в уполномоченном режиме беспроводное устройство 1120 может посылать оценку местоположения на H-SLP 1150b, который затем пересылает оценку местоположения на R-SLP 1150c, который дополнительно пересылает оценку местоположения на LCS клиент 1170 и обходит взаимодействие с V-SLP 1150a.

На фиг.12 показана блок-схема различных сетевых объектов и UE 120 в сети 100 на основе 3GPP по фиг.1. RAN 130 обеспечивает беспроводную связь для сети 100 и обычно включает в себя по меньшей мере один RNC и несколько базовых станций или узлы B. Для простоты только один процессор 1230, одно запоминающее устройство 1232, один приемопередатчик 1234 и один блок связи 1236 показаны для RAN 130. Каждый RNC и каждая базовая станция обычно включают в себя один или несколько процессоров, запоминающих устройств, блоков связи и так далее, и каждая базовая станция обычно включает в себя приемопередатчик 1234. Также для простоты, только один процессор 1220, одно запоминающее устройство 1222 и один приемопередатчик 1224 показаны для UE 120. UE 120 может поддерживать беспроводную связь и может обрабатывать сигналы GPS с помощью одного или нескольких приемников, одной или нескольких антенн, одного или нескольких процессоров и так далее.

На нисходящей линии связи базовые станции в RAN 130 передают данные трафика, сигнализацию и пилот-сигналы на устройства UE в пределах их зоны обслуживания. Эти различные типы данных обрабатываются посредством процессора 1230 и приводятся в нужное состояние приемопередатчиком 1234, чтобы сгенерировать сигнал нисходящей линии связи, который передается через антенну. В UE 120 сигналы нисходящей линии связи от одной или нескольких базовых станций принимаются через антенну, приводятся в нужное состояние приемопередатчиком 1224 и обрабатываются процессором 1220, чтобы получить различные типы информации для услуг определения местоположения. Например, процессор 1220 может получить время прихода сигнала принятых сигналов (которое может использоваться для определения местоположения), декодированные сообщения, используемые для потоков сообщений, описанных выше, и так далее. Запоминающие устройства 1222 и 1232 хранят коды программ и данные для процессоров 1220 и 1230 соответственно в UE 120 и RAN 130. По восходящей линии связи UE 120 может передавать данные трафика, сигнализацию, и пилот-сигналы на одну или несколько базовых станций в RAN 130. Эти различные типы данных обрабатываются процессором 1220 и приводятся в нужное состояние приемопередатчиком 1224, чтобы сгенерировать сигнал восходящей линии связи, который передается через антенну UE. В RAN 130 сигнал восходящей линии связи от UE 120 и других UE принимается и приводится в нужное состояние приемопередатчиком 1234 и дополнительно обрабатывается процессором 1230, чтобы получить различные типы информации (например, данные, сигнализацию, сообщения и так далее). Блок 1236 связи (Comm) дает возможность RAN 130 для взаимодействия с SMLC/SAS 132 и MSC/SGSN 140.

MSC/SGSN 140 включает в себя процессор 1240, который выполняет обработку для MSC/SGSN 140, запоминающее устройство 1242, которое хранит коды программы и данные для процессора 1240, и блок 1244 связи, который дает возможность MSC/SGSN 140 взаимодействовать с RAN 130, SMLC/SAS 132 и другими сетевыми объектами через сети 1202 данных/базовые. SMLC/SAS 132 включает в себя процессор 1250, который выполняет обработку для SMLC/SAS 132, запоминающее устройство 1252, которое хранит коды программы и данные для процессора 1250, и блок 1254 связи, который дает возможность SMLC/SAS 132 взаимодействовать с RAN 130 и MSC/SGSN 140. В целом каждый сетевой объект может включать в себя один или несколько процессоров, запоминающих устройств, блоков связи, контроллеров и так далее. Сети 1202 данных/базовые могут включать в себя базовую сеть и/или другие частные/общедоступные сети передачи данных.

Способы, описанные в документе, могут быть осуществлены различными средствами. Например, способы могут быть осуществлены в виде аппаратных средств, микропрограммного обеспечения, программного обеспечения, или их комбинации. Для аппаратной реализации блоки, используемые, чтобы выполнять обработку в каждом объекте, могут быть реализованы в рамках одной или нескольких проблемно-ориентированных интегральных микросхем (ASIC), цифровых процессоров (ЦПС, DSP) сигналов, цифровых устройств обработки сигналов (DSPD), программируемых логических устройств (ПЛУ, PLD), программируемых вентильных матриц (FPGA), процессоров, контроллеров, микроконтроллеров, микропроцессоров, электронных устройств, других электронных устройств, разработанных, чтобы выполнять описанные в документе функции, или комбинации таковых.

Для программной реализации способы могут быть осуществлены с помощью модулей (например, процедур, функций и так далее), которые выполняют функции, описанные в документе. Программные коды могут храниться в запоминающем устройстве (например, запоминающем устройстве 1222, 1232, 1242 или 1252 по фиг.12) и исполняться посредством процессора (например, процессора 1220, 1230, 1240, или 1250). Запоминающее устройство может быть реализовано в процессоре или являться внешним по отношению к процессору.

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