KR102532718B1 - 보상되지 않은 기압 정보의 전달 - Google Patents

보상되지 않은 기압 정보의 전달 Download PDF

Info

Publication number
KR102532718B1
KR102532718B1 KR1020177031779A KR20177031779A KR102532718B1 KR 102532718 B1 KR102532718 B1 KR 102532718B1 KR 1020177031779 A KR1020177031779 A KR 1020177031779A KR 20177031779 A KR20177031779 A KR 20177031779A KR 102532718 B1 KR102532718 B1 KR 102532718B1
Authority
KR
South Korea
Prior art keywords
location
ubp
protocol
gateway
psap
Prior art date
Application number
KR1020177031779A
Other languages
English (en)
Other versions
KR20180002649A (ko
Inventor
스티븐 윌리엄 엣지
Original Assignee
퀄컴 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 퀄컴 인코포레이티드 filed Critical 퀄컴 인코포레이티드
Publication of KR20180002649A publication Critical patent/KR20180002649A/ko
Application granted granted Critical
Publication of KR102532718B1 publication Critical patent/KR102532718B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/024Guidance services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/50Connection management for emergency connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/025Services making use of location information using location based information parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/52Network services specially adapted for the location of the user terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72418User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality for supporting emergency services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/50Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H04M3/5116Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing for emergency applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/10Scheduling measurement reports ; Arrangements for measurement reports
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/147Signalling methods or messages providing extensions to protocols defined by standardisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72448User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions
    • H04M1/72457User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions according to geographic location
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2242/00Special services or facilities
    • H04M2242/30Determination of the location of a subscriber
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2250/00Details of telephonic subscriber devices
    • H04M2250/12Details of telephonic subscriber devices including a sensor for measuring a physical value, e.g. temperature or motion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16Gateway arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Human Computer Interaction (AREA)
  • Marketing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Position Fixing By Use Of Radio Waves (AREA)

Abstract

UBP(uncompensated barometric pressure)를 PSAP(Public Safety Answering Point)에 제공하기 위한 기법들이 개시된다. UE(user equipment)와 PSAP 사이의 UBP를 제공하기 위한 장치의 예는 위치 서버 및 게이트웨이를 포함한다. 위치 서버는 UE로부터 UBP(uncompensated barometric pressure)를 수신하고, UBP를 포함하는 도시 또는 지리적 위치 기록을 생성하고, 그리고 UBP를 포함하는 도시 또는 지리적 위치 기록을 게이트웨이에 제공하도록 구성된다. 게이트웨이는 위치 서버로부터 UBP를 포함하는 도시 또는 지리적 위치 기록을 수신하고, UBP를 포함하는 도시 위치 기록을 PSAP로 전달하거나 또는 도시 또는 지리적 위치 기록으로부터 UBP를 추출하고, 그리고 UBP를 PSAP에 개별적으로 제공하도록 구성된다.

Description

보상되지 않은 기압 정보의 전달
[0001] 본 출원은, 둘 다가 "Transfer of Uncompensated Barometric Pressure Information"이라는 명칭으로, 2015년 5월 4일자로 출원된 미국 가출원 번호 제 62/156,845 호 및 2015년 9월 21일자로 출원된 미국 정규 특허 출원 번호 제 14/860,452 호에 대한 우선권을 주장하고, 상기 출원들은 본원의 양수인에게 양도되며, 상기 출원들의 내용들은 그 전체가 인용에 의해 본원에 포함된다.
[0002] 무선 통신 시스템들은 음성 및 데이터와 같은 다양한 타입들의 통신 컨텐츠를 제공하기 위해 폭넓게 전개된다. 통상적 무선 통신 시스템들은 이용가능한 시스템 자원들(예컨대, 대역폭, 송신 전력)을 공유함으로써 다수의 사용자들과의 통신을 지원할 수 있는 다중-액세스(multiple-access) 시스템들일 수 있다. 이러한 다중-액세스 시스템들의 예들은 CDMA(code-division multiple access) 시스템들, TDMA(time-division multiple access) 시스템들, FDMA(frequency-division multiple access) 시스템들, OFDMA(orthogonal frequency-division multiple access) 시스템들 등을 포함할 수 있다. 추가적으로, 시스템들은, 규격들, 이를테면, LTE(Long Term Evolution)에 대한 3GPP(Third Generation Partnership Project), LTE-A(LTE Advanced), UMTS(Universal Mobile Telecommunications System), GPRS(General Packet Radio Service), GSM(Global System for Mobile Communications) 등으로부터의 규격들에 따를 수 있다.
[0003] 통상적으로, 현대 무선 통신 시스템은 수신된 라디오 신호들(예컨대, 네비게이션 위성들, 기지국들, 액세스 포인트들로부터의 신호들) 및 가능하게는 다른 정보(예컨대, 공기 기압(barometric air pressure))에 대한 무선 단말들에 의한 측정들에 기초하여 무선 단말들을 로케이팅하기 위한 위치 지정 능력들을 포함한다. 응급 상황들 동안, 모바일 디바이스는, 이를테면, 911 또는 112로 다이얼링함으로써, PSAP(Public Safety Answering Point)와 연결시키기 위해 사용될 수 있다. 무선 통신 시스템은, PSAP가 적절한 자원들을 라우팅하고, 응급 호출에 응답하는 것을 보조하기 위해 모바일 디바이스에 대한 위치 관련 정보를 제공할 수 있다. 위치 관련 정보는 모바일 디바이스에 의해 수행되는 특정 측정들, 이를테면, 기압(barometric pressure)의 측정을 포함할 수 있다. 위치 관련 정보를 PSAP에 제공하기 위한 모바일 디바이스 또는 네트워크의 능력의 향상들은 응급 요원들에 대해 감소된 응답 시간들로 이어질 수 있다.
[0004] 본 개시물에 따라 보상되지 않은 기압 정보를 PSAP(Public Safety Answering Point)에 제공하기 위한 방법의 예는, 사용자 장비에 대한 디스패치가능한 도시 위치(dispatchable civic location)를 획득하는 단계, 사용자 장비로부터 UBP(uncompensated barometric pressure)를 획득하는 단계, UBP를 디스패치가능한 도시 위치와 조합하는 단계, 및 UBP 및 디스패치가능한 도시 위치를 PSAP에 전송하는 단계를 포함한다.
[0005] 이러한 방법의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. UBP 및 디스패치가능한 도시 위치는 위치 서버에 의해 획득될 수 있다. 위치 서버는, E-SMLC(Enhanced Serving Mobile Location Center), E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나일 수 있다. UBP는, OMA LPPe(LTE Positioning Protocol Extensions) 프로토콜, 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 중 적어도 하나를 통해 사용자 장비로부터 획득될 수 있다. 디스패치가능한 도시 위치는 PIDF-LO(Presence Information Data Format Location Object)를 포함할 수 있다. PIDF-LO는 NEAD(National Emergency Address Database)로부터 획득될 수 있다. UBP 및 디스패치가능한 도시 위치를 PSAP에 제공하는 것은, 3GPP Iupc, Iu-cs, Iu-ps, SLs, SLg, Lg, Lgd, 또는 L0 인터페이스 중 적어도 하나를 통해 UBP 및 디스패치가능한 도시 위치를 게이트웨이에 제공하는 것, 및 HELD(HTTP Enabled Location Delivery) 프로토콜, OMA MLP(Mobile Location Protocol), 또는 TIA/ATIS J-STD-036 E2 프로토콜 중 적어도 하나를 통해 게이트웨이로부터 PSAP로 적어도 UBP를 제공하는 것을 포함할 수 있다.
[0006] 본 개시물에 따라 UE(user equipment)와 PSAP(Public Safety Answering Point) 사이의 보상되지 않은 기압을 제공하기 위한 장치의 예는 위치 서버를 포함하고, 게이트웨이는 각각 적어도 하나의 프로세서 및 메모리를 포함한다. 위치 서버는, UE로부터 UBP(uncompensated barometric pressure)를 획득하고, UBP를 포함하는 도시 위치 기록을 생성하고, 그리고 UBP를 포함하는 도시 위치 기록을 게이트웨이에 제공하도록 구성된다. 게이트웨이는, 위치 서버로부터 UBP를 포함하는 도시 위치 기록을 획득하고, 도시 위치 기록으로부터 UBP를 추출하고, 그리고 UBP를 PSAP에 제공하도록 구성된다.
[0007] 이러한 장치의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. 위치 서버는, E-SMLC(Enhanced Serving Mobile Location Center), E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나일 수 있다. 위치 서버는, 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs 또는 Iu-ps 인터페이스 중 적어도 하나를 통해 게이트웨이를 제공하도록 구성될 수 있다. 위치 서버는, 엠티(empty) 도시 위치 기록을 생성하고, 엠티 도시 위치 기록과 UBP를 조합하고, 그리고 엠티 도시 위치 기록 및 UBP를 게이트웨이에 제공하도록 추가로 구성될 수 있다. UBP는, OMA LPPe(LTE Positioning Protocol Extensions), 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 중 적어도 하나를 통해 UE로부터 획득될 수 있다. 게이트웨이는, HELD(HTTP Enabled Location Delivery) 프로토콜, OMA MLP(Mobile Location Protocol) 또는 TIA/ATIS J-STD-036 E2 프로토콜 또는 이들의 조합을 통해 UBP를 PSAP에 제공하도록 구성될 수 있다. 게이트웨이는 도시 위치 기록을 PSAP에 제공하도록 추가로 구성될 수 있다.
[0008] 본 개시물에 따라 UE(user equipment)와 PSAP(Public Safety Answering Point) 사이의 UBP(uncompensated barometric pressure)를 제공하기 위한 장치의 예는, UE에 대한 위치 정보를 결정하기 위한 수단, UE로부터 UBP를 수신하기 위한 수단, UBP를 위치 정보와 조합하기 위한 수단, UBP 및 위치 정보를 게이트웨이에 제공하기 위한 수단, 위치 정보로부터 UBP를 추출하기 위한 수단, 및 UBP를 PSAP에 제공하기 위한 수단을 포함한다.
[0009] 이러한 장치의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. UE로부터 UBP를 수신하기 위한 수단은, OMA LPPe(LTE Positioning Protocol Extensions), 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 중 적어도 하나를 포함할 수 있다. UBP 및 위치 정보를 게이트웨이에 제공하기 위한 수단은, 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs 또는 Iu-ps 인터페이스 중 적어도 하나를 포함할 수 있다. UE에 대한 위치 정보를 결정하기 위한 수단은 SPS 수신기를 포함할 수 있다. UBP를 PSAP에 제공하기 위한 수단은 HELD, MLP 또는 E2 프로토콜 중 적어도 하나를 포함한다. UBP를 위치 정보와 조합하기 위한 수단은 UBP를 표현하는 2개의 추가적 옥텟들의 데이터 필드와 지리적 위치 스트링을 연접시키는 것을 포함할 수 있다.
[0010] 본 개시물에 따른 비-일시적 프로세서 판독가능한 저장 매체의 예는, 보상되지 않은 기압 정보를 PSAP(Public Safety Answering Point)에 제공하기 위한 명령들을 포함하고, 그 명령들은 사용자 장비로부터 UBP(uncompensated barometric pressure)를 수신하기 위한 코드, 사용자 장비에 대한 디스패치가능한 도시 위치를 수신하기 위한 코드, UBP를 디스패치가능한 도시 위치와 조합하기 위한 코드, 및 UBP 및 디스패치가능한 도시 위치를 PSAP에 전송하기 위한 코드를 포함한다.
[0011] 이러한 비-일시적 프로세서 판독가능한 저장 매체의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. 위치 서버에 의해 UBP 및 디스패치가능한 도시 위치를 수신하기 위한 코드. 위치 서버는, E-SMLC(Evolved Serving Mobile Location Center), E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나일 수 있다. 사용자 장비로부터 UBP를 수신하기 위한 코드는, OMA LPPe(LTE Positioning Protocol Extensions), 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 중 적어도 하나를 통해 UBP를 획득하도록 구성될 수 있다. 디스패치가능한 도시 위치는, PIDF-LO(Presence Information Data Format Location Object)를 포함할 수 있고, PIDF-LO는 NEAD(National Emergency Address Database)로부터 획득될 수 있다. UBP 및 디스패치가능한 도시 위치를 PSAP에 전송하기 위한 코드는, 3GPP Iupc, Iu-cs, Iu-ps, SLs, SLg, Lg, Lgd, 또는 L0 인터페이스 중 적어도 하나를 통해 UBP 및 디스패치가능한 도시 위치를 게이트웨이에 제공하기 위한 코드, 및 HELD, MLP 또는 E2 프로토콜 중 적어도 하나를 통해 게이트웨이로부터 PSAP로 적어도 UBP를 제공하기 위한 코드를 포함할 수 있다.
[0012] 본 개시물에 따라 UE(user equipment)와 PSAP(Public Safety Answering Point) 사이의 보상되지 않은 기압을 제공하기 위한 게이트웨이의 예는, UBP(uncompensated barometric pressure)를 포함하는 디스패치가능한 도시 위치 기록을 획득하도록 구성된 네트워크 인터페이스, 및 디스패치가능한 도시 위치 기록으로부터 UBP를 추출하도록 구성된 프로세서 및 메모리를 포함하고, 네트워크 인터페이스는 UBP를 PSAP에 제공하도록 추가로 구성된다.
[0013] 이러한 게이트웨이의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. 네트워크 인터페이스는, HELD(HTTP Enabled Location Delivery) 프로토콜, OMA MLP(Mobile Location Protocol) 또는 TIA/ATIS J-STD-036 E2 프로토콜 또는 이들의 조합을 통해 UBP를 PSAP에 제공하도록 구성될 수 있다. 네트워크 인터페이스는 디스패치가능한 도시 위치 기록을 PSAP에 제공하도록 추가로 구성될 수 있다.
[0014] 본 개시물에 따라 UE(user equipment)에 대한 보상되지 않은 기압을 게이트웨이에 제공하기 위한 위치 서버의 예는, UE로부터 UBP(uncompensated barometric pressure)를 획득하고, 그리고 UE에 대한 디스패치가능한 도시 위치를 획득하도록 구성된 네트워크 인터페이스, 및 UBP를 포함하는 디스패치가능한 도시 위치 기록을 생성하기 위해 UBP를 디스패치가능한 도시 위치와 조합하도록 구성된 프로세서 및 메모리를 포함하고, 네트워크 인터페이스는 UBP를 포함하는 디스패치가능한 도시 위치 기록을 게이트웨이에 제공하도록 추가로 구성된다.
[0015] 이러한 위치 서버의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. 위치 서버는, E-SMLC(Evolved Serving Mobile Location Center), E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나일 수 있다. 네트워크 인터페이스는, UBP를 포함하는 디스패치가능한 도시 위치 기록을 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs 또는 Iu-ps 인터페이스 중 적어도 하나를 통해 게이트웨이에 제공하도록 구성될 수 있다. 프로세서 및 메모리는, 엠티 도시 위치 기록을 생성하고, 그리고 엠티 도시 위치 기록과 UBP를 조합하도록 구성될 수 있고, 네트워크 인터페이스는 엠티 도시 위치 기록 및 UBP를 게이트웨이에 제공하도록 추가로 구성될 수 있다. UBP는, OMA LPPe(LTE Positioning Protocol Extensions) 프로토콜, 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 중 적어도 하나를 통해 UE로부터 획득될 수 있다.
[0016] 본 개시물에 따라 LTE(Long Term Evolution) 아키텍처 또는 UMTS(Universal Mobile Telecommunication System) 아키텍처에서 UE(user equipment)로부터 게이트웨이로 보상되지 않은 기압을 제공하기 위한 방법의 예는, UE로부터 UBP(uncompensated barometric pressure)를 획득하는 단계, UE에 대한 디스패치가능한 도시 위치를 획득하는 단계, UBP를 포함하는 디스패치가능한 도시 위치 기록을 생성하기 위해 UBP를 디스패치가능한 도시 위치와 조합하는 단계, 및 UBP를 포함하는 디스패치가능한 도시 위치 기록을 게이트웨이에 제공하는 단계를 포함한다.
[0017] 이러한 방법의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. UBP 및 디스패치가능한 도시 위치는, E-SMLC(Enhanced Serving Mobile Location Center), E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나를 통해 획득될 수 있다. UBP를 포함하는 디스패치가능한 도시 위치 기록을 게이트웨이에 제공하는 것은, 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs 또는 Iu-ps 인터페이스 중 적어도 하나를 통할 수 있다. 디스패치가능한 도시 위치를 획득하는 것은, 엠티 도시 위치 기록을 생성하는 것, 엠티 도시 위치 기록과 UBP를 조합하는 것, 및 UBP를 포함하는 엠티 도시 위치 기록을 게이트웨이에 제공하는 것을 포함할 수 있다. UBP는, OMA LPPe(LTE Positioning Protocol Extensions) 프로토콜, 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 중 적어도 하나를 통해 UE로부터 획득될 수 있다. UBP는, 디스패치가능한 도시 위치 기록으로부터 추출되고, PSAP(Public Safety Answering Point)에 제공될 수 있다. UBP는, HELD(HTTP Enabled Location Delivery) 프로토콜, OMA MLP(Mobile Location Protocol) 또는 TIA/ATIS J-STD-036 E2 프로토콜 또는 이들의 조합을 통해 PSAP에 제공될 수 있다. 디스패치가능한 도시 위치 기록은 PSAP에 제공될 수 있다.
[0018] 본원에서 설명되는 아이템들 및/또는 기법들은 다음의 능력들뿐만 아니라 언급되지 않은 다른 능력들 중 하나 또는 그 초과의 능력들을 제공할 수 있다. 모바일 디바이스(예컨대, UE(user equipment))는 UBP(uncompensated barometric pressure) 정보를 캡처할 수 있다. 모바일 디바이스 사용자는 응급 호출을 개시할 수 있다. UBP는 서빙 코어 네트워크에 제공된다. UE의 현재 위치에 기초하는 디스패치가능한 도시 위치 정보가 획득될 수 있다. UE의 현재 지리적 위치가 결정될 수 있다. 위치 서버는 UBP를 디스패치가능한 도시 위치 정보 및/또는 지리적 위치와 조합한다. UBP는 기존 인터페이스들 및 프로토콜들을 사용하여 통신 네트워크를 통해 전달된다. UBP는 PSAP(Public Safety Answering Point)에 제공된다. 연방 정부의 지시들은 기존 네트워크 인프라구조의 최소한의 재구성에 만족한다. 추가로, 기술된 수단 이외의 다른 수단에 의해 위에서 기술된 효과가 달성되는 것이 가능할 수 있고, 기술된 아이템/기법이 기술된 효과를 반드시 산출하는 것은 아닐 수 있다.
[0019] 도 1은 사용자 장비의 하나의 실시예의 컴포넌트들의 블록 다이어그램이다.
[0020] 도 2는 UBP(uncompensated barometric pressure) 정보를 전달하기 위한 예시적 무선 통신 시스템의 하이 레벨 아키텍처이다.
[0021] 도 3a는 3GPP LTE(long term evolution) 액세스로 UBP 정보를 전달하기 위한 아키텍처이다.
[0022] 도 3b는 UMTS(Universal Mobile Telecommunications System) 액세스로 UBP 정보를 전달하기 위한 아키텍처이다.
[0023] 도 4는 도시 위치 정보를 이용하는 예시적 UBP 전달 프로시저의 메시지 흐름 다이어그램이다.
[0024] 도 5는 지리적 위치 정보를 이용하는 다른 예시적 UBP 전달 프로시저의 메시지 호 흐름 다이어그램이다.
[0025] 도 6은 UBP 및 도시 위치 정보를 PSAP(Public Safety Answering Point)에 제공하는 프로세스의 블록 흐름 다이어그램이다.
[0026] 도 7a는 도시 정보 없이 UBP 정보를 PSAP에 제공하는 프로세스의 블록 흐름 다이어그램이다.
[0027] 도 7b는 게이트웨이를 이용하여 UBP 정보를 PSAP에 제공하는 프로세스의 블록 흐름 다이어그램이다.
[0028] 도 7c는 UBP를 포함하는 디스패치가능한 도시 위치 기록을 게이트웨이에 제공하는 프로세스의 블록 흐름 다이어그램이다.
[0029] 도 8은 UBP를 위치 정보 메시징을 통해 PSAP에 제공하기 위한 프로세스의 블록 흐름 다이어그램이다.
[0030] 도 9는 UBP 정보를 전달하는데 사용하기 위한 컴퓨터 시스템의 하나의 실시예의 컴포넌트들의 블록 다이어그램이다.
[0031] 상이한 도면들에서의 동일한 번호의 엔티티들은 대응하는 엔티티들 ― 예컨대, 동일한 엔티티들 ― 을 지칭한다.
[0032] 미국에서는, FCC(Federal Communications Commission)가, UBP를 측정할 수 있는 디바이스가 응급 911 호출을 수행할 때 네트워크 운영자들이 UBP(uncompensated barometric pressure)의 측정을 전달하도록 지시하고 있다. FCC는 또한, 응급 911 호출이 무선 디바이스로부터 걸려왔을 때 네트워크 운영자들이 응급 호출자에 대해 수평으로 50 미터까지 정확한 지리적 위치 또는 응급 호출자에 대한 디스패치가능한 도시 위치의 형태로 실내에서 이루어지는 응급 호출들에 대한 HALI(Heightened Accuracy Location Information)를 제공하도록 지시하고 있다. 공중 안전면에 대한 UBP의 유용성은 도시 위치 또는 지리적 위치의 유용성보다 적을 수 있는데, 그 이유는 UBP가 항상 실현가능하거나, 신뢰성있거나, 또는 정확하지 않을 수 있는 대응하는 고도(예컨대, 빌딩 층 레벨)로 변환될 필요가 있기 때문이다. 또한, UBP는 고도 좌표를 PSAP(Public Safety Answering Point)에 제공하는 운영자들에 의해 몇 년 후에 대체될 수 있다. 따라서, ― 예컨대, 무선 디바이스로부터 PSAP로의 개재 제어 플레인 및/또는 사용자 플레인 인터페이스들에 걸쳐 UBP 정보의 전달을 지원하기 위해 기존 프로토콜들을 수정함으로써 ― 네트워크 운영자들 측에서 UBP를 지원하는데 너무 많이 투자하는 것을 꺼리는 경우가 있을 수 있다. 예컨대, UBP 정보 전달의 지원은, LTE(Long Term Evolution)에 대한, UMTS(Universal Mobile Telecommunications Systems)에 대한, 그리고 국가 비상 전화 연합(National Emergency Number Association)(예컨대, NENA i3) 가능 PSAP들로 뿐만 아니라 레거시 PSAP들로의 액세스에 대한 기존 프로토콜들 및 인터페이스들에 대한 수정을 요구할 수 있다. 응급 911 호출들을 위해 UBP 정보를 포함하는 것에 대해 낮게 예상되는 유용성은 기존 프로토콜들 및 인터페이스들에 대한 높은 표준들 및 구현 영향들을 정당화하지 않을 수 있다.
[0033] UBP(uncompensated barometric pressure) 정보를 PSAP에 더 효율적으로 제공하기 위한 기법들이 본원에서 논의된다. UBP 정보는, 포지셔닝 프로토콜(예컨대, 3GPP에 의해 정의된 LPP(LTE Positioning Protocol) 또는 OMA(Open Mobile Alliance)에 의해 정의된 LPPe(LPP Extensions) 프로토콜)을 사용하여 모바일 디바이스(예컨대, UE(user equipment))에 의해 위치 서버(예컨대, E-SMLC(Enhanced Serving Mobile Location Center) 또는 E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform))에 제공될 수 있다. UBP는 파스칼(Pa), 밀리바(millibars) 또는 수은주 인치(inches of Mercury) 등의 단위들로 지원될 수 있다. 예컨대, LPPe에서, Pa의 단위들은, 일반적으로 임의의 가능성 있는 고도에서의 임의의 가능성 있는 실내 또는 실외 압력을 표현하기에 충분한 것으로 고려되는 30,000 내지 115,000 Pa의 범위에 사용된다. 이러한 UBP 정보를 PSAP에 제공하는 것이 가능할 수 있지만, 기존 서빙 네트워크들에 의해 지원되는 많은 인터페이스들 및 프로토콜들은 전달을 지원하는 것으로 확장될 필요가 있을 수 있다. UBP 정보를 전달하는 효율성을 향상시키는 한 가지 방식은, 네트워크에 걸쳐 이러한 변화들을 구현하는 것이라기 보다는, UBP를 일부 다른 HALI(heightened accuracy location information) 컨텐츠와 조합하는 것일 것이다. 예컨대, UBP는, 디스패치가능한 도시 위치(예컨대, 거리 주소 또는 빌딩 지정)와 조합되거나, 또는 수평 좌표들(예컨대, 위도 및 경도) 및 가능하게는, 고도, 불확정성(uncertainty) 및/또는 신뢰도 레벨을 포함할 수 있는 지리적 위치와 조합될 수 있다. 이 조합은 통신 네트워크 내에서의 각각의 영향을 받은 프로토콜 및 인터페이스에 대한 별개의 UBP 파라미터들을 표준화 및 구현하기 위한 필요성을 회피할 수 있다.
[0034] 도 1을 참조하면, 본원에서의 다양한 기법들이 활용될 수 있는 UE(user equipment)(100)가 예시된다. UE(100)는 일반적으로 모바일 디바이스이며, 다양한 모바일 통신 및/또는 컴퓨팅 디바이스들의 기능을 포함하거나 또는 구현할 수 있으며; 그 예들은 현재 존재하든 아니면 추후에 개발되든 간에, 셀폰들, PDA(personal digital assistant)들, 스마트폰들, 컴퓨팅 디바이스들, 이를테면, 랩탑들, 데스크탑들 또는 태블릿 컴퓨터들, 자동차 컴퓨팅 시스템들 등을 포함하지만, 이들로 제한되는 것은 아니다. UE(100)는 또한, 이동국, 모바일 디바이스, 단말, 무선 단말, 무선 디바이스, 액세스 단말, 가입자 유닛, 스테이션 또는 일부 다른 명칭으로 지칭될 수 있다.
[0035] UE(100)는 프로세서(111)(또는 프로세서 코어) 및 메모리(140)를 포함한다. UE(100)는 선택적으로, 공중 버스(101) 또는 사설 버스(도시되지 않음)에 의해 메모리(140)에 동작가능하게 연결되는 신뢰성 있는 환경을 포함할 수 있다. UE(100)는 또한, 무선 네트워크 상에서 무선 안테나(122)를 통해 무선 신호들(123)을 전송 및 획득하도록 구성된 통신 인터페이스(120) 및 무선 트랜시버(121)를 포함할 수 있다. 무선 트랜시버(121)는 통신 인터페이스(120)를 통해 버스(101)에 연결된다. 여기서, UE(100)는 단일 무선 트랜시버(121)를 가지는 것으로 예시된다. 그러나, UE(100)는 대안적으로, WiFi(예컨대, IEEE 802.11), CDMA, WCDMA(Wideband CDMA), LTE(Long Term Evolution), Bluetooth® 단거리 무선 통신 기술 등과 같은 다수의 통신 표준들을 지원하기 위해 다수의 무선 트랜시버들(121) 및/또는 다수의 무선 안테나들(122)을 가질 수 있다.
[0036] 통신 인터페이스(120) 및/또는 무선 트랜시버(121)는 다중 캐리어들(상이한 주파수들의 파형 신호들) 상의 동작을 지원할 수 있다. 다중-캐리어(multi-carrier) 송신기들은 다중 캐리어들 상에서 변조된 신호들을 동시에 송신할 수 있다. 각각의 변조된 신호는 CDMA(Code Division Multiple Access) 신호, TDMA(Time Division Multiple Access) 신호, OFDMA(Orthogonal Frequency Division Multiple Access) 신호, SC-FDMA(Single-Carrier Frequency Division Multiple Access) 신호 등일 수 있다. 각각의 변조된 신호는 상이한 캐리어 상에서 전송될 수 있으며, 파일럿, 오버헤드(overhead) 정보, 데이터 등을 반송(carry)할 수 있다.
[0037] UE(100)는 또한, 사용자 인터페이스(150)(예컨대, 디스플레이, 키보드, 터치스크린, 마이크로폰, 스피커), 및 (예컨대, SPS(satellite positioning system) 위성들로부터) SPS 안테나(158)(예컨대, 무선 안테나(122)와 동일하거나 또는 상이할 수 있음)를 통해 SPS 신호들(159)을 수신하는 SPS 수신기(155)를 포함할 수 있다. SPS 수신기(155)는 단일 GNSS(global navigation satellite system) 또는 다수의 이러한 시스템들과 통신할 수 있다. GNSS는 GPS(Global Positioning System), Galileo, Glonass, Beidou(Compass) 등을 포함할 수 있지만, 이들로 제한되는 것은 아니다. SPS 위성들은 또한, 위성들, SV(space vehicle)들 등으로 지칭된다. SPS 수신기(155)는, SPS 신호들(159)을 전체적으로 또는 부분적으로 프로세싱하며, 이러한 SPS 신호들(159)을 사용하여 UE(100)의 위치를 결정할 수 있거나, 또는 UE(100)가, 측정들로부터 UE(100)에 대한 위치를 컴퓨팅하는 위치 서버(예컨대, E-SMLC 또는 E-SLP)에 SPS 신호들의 측정들을 전달하는 것을 가능하게 할 수 있다. 프로세서(111), 메모리(140), DSP(Digital Signal Processor)(112) 및/또는 특수화된 프로세서(들)(도시되지 않음)는 또한, SPS 수신기(155)와 함께, SPS 신호들(159)을 전체적으로 또는 부분적으로 프로세싱하고 그리고/또는 UE(100)의 위치를 계산하기 위해 활용될 수 있다. SPS 신호들(159) 또는 다른 위치 신호들로부터의 정보의 저장은 메모리(140) 또는 레지스터들(도시되지 않음)을 사용하여 수행된다. 단지 하나의 프로세서(111), 하나의 DSP(112) 및 하나의 메모리(140)가 도 1에 도시되지만, 이 컴포넌트들 중 임의의 컴포넌트, 컴포넌트들의 쌍, 또는 그 전부 중 하나 초과의 컴포넌트들이 UE(100)에 의해 사용될 수 있다. UE(100)와 연관된 프로세서(111) 및 DSP(112)는 버스(101)에 연결된다.
[0038] 메모리(140)는 하나 또는 그 초과의 명령들 또는 코드로서 기능들을 저장하는 비-일시적 컴퓨터 판독가능한 저장 매체(또는 매체들)를 포함할 수 있다. 메모리(140)를 구성할 수 있는 매체들은 RAM, ROM, FLASH, 디스크 드라이브들 등을 포함하지만, 이들로 제한되는 것은 아니다. 일반적으로, 메모리(140)에 의해 저장된 기능들은 범용 프로세서(들)(111), 특수화된 프로세서들, 또는 DSP(들)(112)에 의해 실행된다. 따라서, 메모리(140)는, 프로세서(들)(111) 및/또는 DSP(들)(112)로 하여금 설명되는 기능들을 수행하게 하도록 구성된 소프트웨어(프로그래밍 코드, 명령들 등)를 저장하는 프로세서 판독가능한 메모리 및/또는 컴퓨터 판독가능한 메모리이다. 대안적으로, UE(100)의 하나 또는 그 초과의 기능들은 하드웨어로 전체적으로 또는 부분적으로 수행될 수 있다.
[0039] 위치, 포지션, 위치 추정치 및 포지션 추정치이라는 용어들이 지리적(또한 측지적(geodetic)으로 지칭됨) 또는 도시적일 수 있는 위치를 지칭하기 위해 본원에서 상호교환가능하게 사용된다. UE(100)에 대한 지리적 위치는, 위도, 경도 및 가능하게는 고도(예컨대, 평균 해수면 위 또는 아래, 또는 국부 지면 위 또는 아래)와 같은 좌표들, 또는 일부 인근 고정 지점과 관련하여 정의되는 국부 좌표들(예컨대, 국부 X,Y,Z Cartesian 좌표들)을 포함할 수 있다. UE(100)에 대한 도시 위치(또한 도시 주소로 지칭됨)는 우편 주소, 거리 주소, 잘 알려진 장소 또는 빌딩의 명칭, 빌딩 또는 구조의 일부에 대한 참조번호(예컨대, 층 레벨, 방 번호, 아파트 번호, 공항의 게이트 번호)를 포함할 수 있다. UE(100)에 대한 지리적 위치 및 도시 위치는 UE(100)에 대한 동일한 위치를 지칭할 수 있지만, 상이한 방식들로 표현될 수 있다. UE(100)로부터 PSAP로의 응급 호출의 경우, UE(100)에 대한 도시 위치는 디스패치가능한 도시 위치로 또는 디스패치가능한 위치로 지칭될 수 있으며, UE(100)의 위치에 대한 공중 보안 응답자들을 디스패치(dispatch)하기 위해 PSAP에 의해 사용될 수 있다.
[0040] UE(100)는 자신의 현재 포지션을 추정할 수 있거나, 또는 UE(100)에서 이용가능한 정보 및/또는 뷰(view) 내의 다른 통신 엔티티들에 기초하여, 다양한 기법들을 사용하여 UE(100)의 위치를 추정하기 위해 위치 서버(예컨대, E-SMLC 또는 E-SLP)와 같은 다른 엔티티에 의해 사용될 수 있는 정보를 획득할 수 있다. 예컨대, UE(100)는 자신의 포지션을 추정할 수 있거나, 또는 다른 엔티티가, 하나 또는 그 초과의 WLAN(wireless local area network)들, Bluetooth 또는 ZigBee® 등과 같은 단거리 무선 통신 기술을 활용하는 PAN(personal area network)들, GNSS(Global Navigation Satellite System) 또는 다른 SPS(Satellite Positioning System) 위성들과 연관된 인근 AP(access point)들로부터 획득된 정보, 및/또는 맵 서버로부터 획득된 맵 데이터를 사용하여 UE(100)의 포지션을 추정하는 것을 가능하게 할 수 있다. 일부 경우들에서, E-SMLC, E-SLP 또는 SAS(Standalone Serving Mobile Location Center)일 수 있는 위치 서버는, UE(100)가, 위치 관련 측정들(예컨대, WLAN AP들, 셀룰러 기지국들, GNSS 위성들의 측정들)을 수행하는 것을 가능하게 하거나 또는 보조하기 위해 보조 데이터를 UE(100)에 제공할 수 있다. 그 다음, UE(100)는 위치 추정치를 컴퓨팅하기 위해 측정들을 위치 서버에 제공할 수 있거나, 또는 측정들에 기초하여 그리고 가능하게는, 위치 서버에 의해 제공된 다른 보조 데이터(예컨대, 이를테면, GNSS 위성들에 대한 궤도 및 타이밍 데이터, 또는 WLAN AP들 및/또는 셀룰러 기지국들의 정확한 위치 좌표들)에 또한 기초하여, 위치 추정치 그 자체를 컴퓨팅할 수 있다.
[0041] 압력 센서(130)는 (예컨대, 내부적으로) UE(100) 내에 포함될 수 있거나, 또는 (예컨대, 외부적으로) 주변 디바이스로서 UE(100)에 동작가능하게 커플링될 수 있다. 압력 센서(130)는 기압 정보(예컨대, 10-1200 mbar)를 프로세서(들)(111)에 제공하도록 구성된다. 예시적 압력 센서들은 Measurement Specialties MS5607, Bosch BMP085 또는 BMP280, 및 STMicroelectronics LPS22HB 또는 LSP331AP를 포함할 수 있다. 이 예들은, 대기압(atmospheric pressure)을 검출하도록 구성된 다른 이러한 압전-저항성 압력 센서들이 사용될 수 있으므로 제한들이 아니다. 압력 센서(130)는 주변 기압을 검출하도록 구성되고, UE(100)는 이러한 UBP(uncompensated barometric pressure) 정보를 통신 시스템(예컨대, E-SMLC, E-SLP 또는 SAS와 같은 위치 서버)에 제공할 수 있다. 기압(barometric pressure), 공기 기압(barometric air pressure) 및 대기압(atmospheric pressure)이라는 용어들은 ― 예컨대, UE(100)의 위치에서의 ― 대기압을 지칭하기 위해 본원에서 상호교환가능하게 사용된다. UBP라는 용어는, 측정에서의 임의의 에러들을 보상하기 위해 압력 측정이 UE에 의해 반드시 조절되는 것이 아닌 UE에 의한(예컨대, 압력 센서(130)를 사용하는 UE(100)에 의한) 대기압의 측정을 지칭한다.
[0042] 도 1에 대한 추가적 참조와 함께, 도 2를 참조하면, UBP(uncompensated barometric pressure) 정보를 전달하기 위한 예시적 통신 시스템(200)이 도시된다. UE(100)는 통신 서비스들을 획득하기 위해 액세스 네트워크(202)와 통신할 수 있다. UE(100)는 액세스 네트워크(202)에서 하나 또는 그 초과의 기지국들 및/또는 하나 또는 그 초과의 액세스 포인트들과 통신할 수 있다. UE(100)는 또한, 미국의 GPS(Global Positioning System), 유럽의 Galileo 시스템, 러시아의 GLONASS 시스템 등의 일부일 수 있는 하나 또는 그 초과의 위성들(290)로부터 신호들을 수신할 수 있다. UE(100)는 액세스 네트워크(202)에서 기지국들 및/또는 AP들로부터의 신호들을 측정하고, 기지국들 및/또는 AP들에 대한 신호 타이밍, 신호 강도 및/또는 신호 품질의 측정들을 획득할 수 있다. UE(100)는 또한, 위성들(290)로부터의 신호들을 측정하고, 위성들에 대한 의사-거리(또는 코드 위상 또는 캐리어 위상) 측정들을 획득할 수 있다. 의사-거리 측정들 및/또는 타이밍 측정들은 UE(100)에 의해 또는 위치 서버(206)에 의해 UE(100)에 대한 포지션 추정치를 유추하기 위해 사용될 수 있다. UE(100)는 또한, (예컨대, 압력 센서(130)에 의해 측정된) UBP(uncompensated barometric pressure) 정보를 위치 서버(206)에 제공하도록 구성된다.
[0043] 액세스 네트워크(202)는 자신의 커버리지 영역 내에 로케이팅된 UE들에 라디오 통신을 제공한다. 액세스 네트워크(202)는 또한, 라디오 네트워크, RAN(radio access network) 등으로 지칭될 수 있다. 액세스 네트워크(202)는 아래에서 설명되는 바와 같이, 기지국들, 액세스 포인트들, 네트워크 제어기들 및/또는 다른 엔티티들을 포함할 수 있다. 코어 네트워크 또는 EPC(evolved packet core)로 지칭될 수 있는 서빙 코어 네트워크(204)는 다양한 통신 서비스들을 지원할 수 있는 네트워크 엔티티들을 포함할 수 있다. 위치 서버(206)는 서빙 코어 네트워크(204)와 통신하는 UE들(예컨대, 서빙 코어 네트워크(204)로 로밍하는 UE들을 포함함)에 대한 위치 서비스들을 지원할 수 있으며, UE들이 위치 서버(206)에 대한 임의의 이전 관계 또는 임의의 서비스 가입을 가지도록 요구할 수 있거나 또는 요구하지 않을 수 있다. 서빙 코어 네트워크(204)는 또한, 레거시 ESN(Emergency Services Network)/PSAP(210a) 및 i3 ESInet(Emergency Services IP network)/PSAP(210b)와 같은 PSAP들과의 메시징을 지원하도록 구성된 게이트웨이(208)를 포함할 수 있다.
[0044] 위치 서버(206)는 E-SMLC, E-SLP 또는 SAS에 대응할 수 있으며, (예컨대, 위치 서버(206)가 E-SMLC 또는 SAS인 경우) 제어 플레인 위치 솔루션 또는 (예컨대, 위치 서버(206)가 E-SLP인 경우) OMA(Open Mobile Alliance) SUPL 솔루션과 같은 사용자 플레인 위치 솔루션을 지원할 수 있다. 위치 서버(206)는 (i) UE(100)가 위치 관련 측정들을 수행하는 것 및/또는 이러한 측정들로부터의 위치 추정치를 컴퓨팅하는 것을 보조하기 위하여 보조 데이터를 UE(100)에 전달하고, (ii) UE(100)로부터 위치 관련 측정들 및/또는 위치 추정치를 요청하고 그리고/또는 (iii) UE(100)로부터 위치 관련 측정들 및/또는 위치 추정치를 수신하기 위해 UE(100)와 상호작용할 수 있다. 위치 서버(206)는 UE(100)로부터 수신된 위치 관련 측정들로부터 UE(100)에 대한 위치 추정치(예컨대, 위도, 경도 및 가능하게는 고도)를 컴퓨팅할 수 있다. 위치 서버(206)는 (i) 3GPP에 의해 정의된 LPP(LTE Positioning Protocol), (ii) OMA에 의해 정의된 LPPe(LPP Extensions) 프로토콜, (iii) 3GPP에 의해 정의된 UMTS에 대한 PCAP(Positioning Calculation Application Part) 플러스 RRC(Radio Resource Control) 프로토콜들, (iv) OMA에 의해 정의된 SUPL ULP(UserPlane Location Protocol), 및 (v) 3GPP에 의해 정의된 LTE에 대한 LPPa(LTE Positioning Protocol A) 플러스 RRC 프로토콜을 포함하는 다수의 상이한 포지셔닝 프로토콜들 중 하나 또는 그 초과의 포지셔닝 프로토콜들을 사용하여 UE(100)와 상호작용할 수 있다. 예컨대, UE(100) 및 위치 서버(206)는 위치 서버가 E-SMLC 또는 E-SLP인 경우 LPPe와 조합된 LPP를 사용하여 상호작용할 수 있다. LPPe와 조합된 LPP의 사용은, LPP/LPPe로 지칭될 수 있으며, ― 예컨대, 3GPP TS 36.355에서 LPP에 대해 정의된 바와 같이 ― 각각의 LPP 메시지가 단일 LPPe 메시지를 임베딩하는 LPP 메시지들을 전달하는 것을 포함할 수 있다.
[0045] 게이트웨이(208)는 (예컨대, 3GPP TS(Technical Specification)들 23.167 및 23.271에서) 3GPP에 의해 정의된 LRF(Location Retrieval Function) 또는 GMLC(Gateway Mobile Location Center)에 대응할 수 있으며, ― 예컨대, 게이트웨이(208)가 레거시 ESN/PSAP(210a) 또는 i3 ESInet/PSAP(210b)로부터 UE(100)에 대한 위치 요청을 수신하는 경우 ― 위치 서버(206)를 통해 UE(100)의 포지셔닝을 실시하게 할 수 있다. 그 다음, 게이트웨이(208)는 위치 서버(206)로부터 서빙 코어 네트워크에서 하나 또는 그 초과의 중간 엔티티들을 통해 또는 위치 서버(206)로부터 직접적으로 UE(100)에 대한 위치 정보(예컨대, 디스패치가능한 도시 위치 및/또는 지리적 위치를 포함할 수 있는 HALI)를 수신할 수 있으며, 위치 정보를 레거시 ESN/PSAP(210a) 또는 i3 ESInet/PSAP(210b)에 전송할 수 있다.
[0046] 서빙 코어 네트워크(204) 내의 위치 서버(206), 게이트웨이(208) 또는 일부 다른 엔티티는 UE(100)에 대한 도시 위치에 대해 NEAD(National Emergency Address Database)(212)에 질의할 수 있다. 예컨대, UE(100)는 UE(100)에 가시적인 하나 또는 그 초과의 WLAN AP들 및/또는 Bluetooth 비컨들의 아이덴티티들(예컨대, MAC 어드레스들)을 위치 서버(206)에 제공할 수 있고, 서빙 코어 네트워크(204) 내의 위치 서버(206) 또는 일부 다른 엔티티는 이러한 아이덴티티들을 NEAD(212)에 제공할 수 있다. 그 다음, NEAD(212)는, 대응하는 도시 위치 정보(예컨대, 거리 주소 및/또는 빌딩 지정, 층 레벨 및 가능하게는 방 또는 아파트 번호)가 사전에 구성된, 알려진 WLAN AP들 및/또는 Bluetooth 비컨들의 데이터베이스를 탐색할 수 있으며, 식별된 AP들 및/또는 비컨들 중 하나 또는 그 초과의 것 각각에 대한 도시 위치를 리턴할 수 있다. 그 다음, 위치 서버(206)는 ― 예컨대, 식별된 WLAN AP들 및/또는 Bluetooth 비컨들로부터의 신호들의 UE(100)에 의한 (예컨대, RSSI 또는 RTT에 대한) 측정들로부터 추론된 UE(100)의 위치와 가장 가까운 것으로 나타나는, WLAN AP 또는 Bluetooth 비컨에 대해 NEAD(212)에 의해 리턴된 도시 위치를 선택함으로써 ― NEAD(212)에 의해 리턴된 하나 또는 그 초과의 도시 위치들을 디스패치가능한 도시 위치로 변환할 수 있다. 그 다음, 이러한 디스패치가능한 도시 위치 정보는, 예컨대, UE(100)에 대한 HALI의 일부로서 게이트웨이(208)에 전달될 수 있다.
[0047] NEAD(212)는 NEAM(National Emergency Address Manager)(214)로부터 운영들, 관리, 유지 및 프로비저닝 기능들을 수신할 수 있다. NEAM(214)은 하나 또는 그 초과의 외부 데이터 소스들(216)로부터 도시 위치 정보를 수신할 수 있다. 외부 데이터 소스(216)는 하나 또는 그 초과의 액세스 네트워크들을 형성할 수 있는 하나 또는 그 초과의 기준 점들(예컨대, WLAN AP들 및/또는 Bluetooth 비컨들)을 소유하거나 또는 운영하는 운영자, 사용자 또는 조직에 대응할 수 있다. 제공되는 도시 위치 정보는 소유되거나 또는 운영되는 기준 점들에 대한 도시 위치 정보에 대응할 수 있다. 하나의 예에서, 외부 데이터 소스들(216)은 NEAM(214)에 의해 인증될 수 있는 고유한 아이덴티티들을 가질 수 있으며, 도시 위치 정보를 제공하기 위한 허가를 수신하기 위해 일부 최소 신뢰 레벨을 설정할 수 있다. NEAM(214)은 외부 데이터 소스들의 식별 및 인증, 수신된 도시 위치 정보의 검증, 및 NEAD(212)에서의 도시 위치 정보의 프로비저닝을 지원하도록 구성될 수 있다.
[0048] 동작 시, UE(100)는 (예컨대, 사용자가 "911"로 다이얼링할 때) UE(100)의 사용자로부터의 응급 호출 요청을 검출한 이후에 응급 호출 요청을 개시한다. 서빙 코어 네트워크(204)는 UE(100)로부터 레거시 또는 NENA(National Emergency Number Association) i3-가능 응급 서비스 네트워크 및 그것의 PSAP들(예컨대, 210a, 210b)로 응급 호출의 설정을 지원하도록 구성된다. 서빙 코어 네트워크(204)에 의해 지원되는 기능들은 응급 호출 검출, 호 라우팅 및 디스패치가능한 위치의 프로비전을 포함할 수 있다. 하나의 예에서, 유효한 가입을 한 UE(100)에 대해, 서빙 코어 네트워크(204)는 또한 PSAP로부터의 콜백을 지원할 수 있다. 레거시 ESN/PSAP(210a)는, TIA(Telecommunications Industry Association) 및 ATIS(Alliance for Telecommunications Industry Solutions) 조인트 표준 J-STD-036에서 정의된 바와 같이, 서빙 코어 네트워크(204)로부터(예컨대, 게이트웨이(208)로부터) 응급 호출들 및 연관된 디스패치가능한 위치 정보를 수신하도록 구성된다. i3 ESInet/PSAP(210b)는 (예컨대, NENA i3에서 정의된 바와 같은) 차세대 수단을 사용하여 서빙 코어 네트워크(204)로부터(예컨대, 게이트웨이(208)로부터) 응급 호출들 및 디스패치가능한 위치 정보를 수신하도록 구성된다.
[0049] 도 1 및 도 2에 대한 추가적 참조와 함께, 도 3a를 참조하면, 3GPP LTE 액세스로 UBP 정보를 전달하기 위한 LTE(long term evolution) 아키텍처(300)가 도시된다. UE(100)는 통신 서비스들을 획득하기 위해 RAN(radio access network) 내의 서빙 eNB(evolved Node B)(302)와 통신할 수 있다. RAN은 도 2의 액세스 네트워크(202)에 대응할 수 있고, 간략함을 위해 도 3a에 도시되지 않은 다른 네트워크 엔티티들을 포함할 수 있으며, E-UTRAN(Evolved Universal Terrestrial Radio Access Network)으로 지칭될 수 있다. eNB(302)는 Node B, 기지국, 액세스 포인트 등으로 지칭될 수 있다. UE(100)는 인근 eNB들(예컨대, eNB(302))로부터의 신호들을 측정하고, eNB들의 아이덴티티들, (예컨대, TOA(time of arrival), OTDOA(observed time difference of arrival)에 대한) 타이밍 측정들, 신호 강도 측정들 및/또는 eNB들에 대한(예컨대, ECID(Enhanced Cell ID)에 대한) 신호 품질 측정들을 획득할 수 있다. UE(100)는 또한 또는 대신에, SPS 위성들(290)에 대한 의사-범위들을 측정할 수 있다. eNB 아이덴티티들, eNB 타이밍 측정들, eNB 신호 강도 측정들, eNB 신호 품질 측정들 및/또는 SPS 의사-범위 측정들은 (예컨대, UE(100)에 의해 또는 E-SMLC(308) 또는 E-SLP(332)와 같은 위치 서버에 의해) UE(100)에 대한 위치 추정치를 유추하기 위해 사용될 수 있다. UE(100)는 또한 또는 대신에, WLAN(390) 내의 인근 AP들로부터 신호들을 수신하여 선택적으로 측정할 수 있으며, 이는 신호들이 UE(100)에 의해 수신될 수 있는 WLAN(390) 내의 WiFi 또는 Bluetooth(BT) AP들(이들은 또한 비컨들로 지칭될 수 있음)에 대한 아이덴티티들(예컨대, MAC 어드레스들)을 획득하는 것 및 가능하게는, RSSI(Received Signal Strength Indication) 또는 RTT(Round Trip signal propagation Time)와 같은 이러한 수신된 신호들의 특성들을 측정하는 것을 포함할 수 있다. WLAN AP 아이덴티티들 및 측정들은 ― 예컨대, UE(100)에 의해 또는 E-SMLC(308) 또는 E-SLP(332)와 같은 위치 서버에 의해 ― UE(100)에 대한 위치를 획득하기 위해 사용될 수 있다. eNB 및/또는 WLAN AP 아이덴티티들은 사전에 설명된 바와 같이, UE(100)에 대한 도시 위치에 대해 (예컨대, E-SMLC(308) 또는 E-SLP(332)와 같은 위치 서버에 의해) NEAD(212)에 질의하기 위해 사용될 수 있다. 단지 하나의 WLAN(390)이 도 3a에 도시되지만, UE(100)에 가시적인 WiFi 및/또는 BT AP들을 포함하는 다른 WLAN들(도 3a에 도시되지 않음)이 존재할 수 있고; 따라서, WLAN(390)에 대한 본원에서의 참조는 가능하게는 하나 초과의 WLAN에 대해 참조하는 것으로 고려될 것이다.
[0050] eNB(302)는, 이동성 관리, 게이트웨이 선택, 인증, 베어러 관리 등과 같은 다양한 제어 기능들을 수행할 수 있는, UE(100)에 대한 서빙 MME(304)와 통신할 수 있다. MME(304)는 E-SMLC(Enhanced Serving Mobile Location Center)(308) 및 GMLC(Gateway Mobile Location Center)(306)와 통신할 수 있다. E-SMLC(308)는 UE(100)에 대한 UE-기반, UE-보조, 네트워크-기반 및/또는 네트워크-보조 포지셔닝 방법들을 지원할 수 있으며, 하나 또는 그 초과의 MME들(예컨대, MME(304))을 지원할 수 있다. E-SMLC(308)는 또한, LS(location server), SAS(Stand Alone SMLC) 등으로 지칭될 수 있다. E-SMLC(308)는 위치 서비스들을 지원하기 위해 NEAD(212)와 통신할 수 있다. E-SMLC(308)는 도 2의 위치 서버(206)에 대응할 수 있다. GMLC(306)는 위치 서비스들을 지원하고, 외부 클라이언트들(예컨대, NEAD(212))과 인터페이싱하고, 가입자 프라이버시, 허가, 인증, 빌링 등과 같은 서비스들을 제공하기 위해 다양한 기능들을 수행할 수 있다. LRF(Location Retrieval Function)(330)는 GMLC(306)와 통신할 수 있으며, IP-기반 응급 호출들을 i3 ESInet(342) 및 i3 PSAP(344)와 같은 PSAP(Public Safety Answering Point)들뿐만 아니라, 레거시 ES 네트워크(346) 및 레거시 PSAP(348)와 같은 레거시 시스템들로 라우팅할 수 있거나 또는 그 라우팅을 도울 수 있다. SPC(SUPL Positioning Center)(334) 및 SLC(SUPL Location Center)(336)를 포함하는 E-SLP(Emergency SUPL Location Platform)(332)는 또한, LRF(330)와 위치 정보를 통신하도록 구성된다. E-SLP(332)는 위치 서버(206)의 예이고, LRF(330)는 서빙 코어 네트워크(204) 내의 게이트웨이(208)의 예이다. 일부 네트워크들에서, E-SLP(332)는 배치될 수 있지만 E-SMLC(308)는 배치될 수 없으며, 또는 그 반대가 될 수 있다.
[0051] 서빙 게이트웨이(316)는 UE들에 대한 IP 데이터 전달과 관련된 다양한 기능들, 이를테면, 데이터 라우팅 및 포워딩, 이동성 앵커링(anchoring) 등을 수행할 수 있다. PDN(Packet Data Network) 게이트웨이(318)는 UE들에 대한 데이터 연결성의 유지, IP 어드레스 할당 등과 같은 다양한 기능들을 수행할 수 있다. IMS(IP Multimedia Subsystem) 네트워크는 IMS 서비스들, 이를테면, VoIP(Voice-over-IP) 호출들을 지원하기 위한 다양한 네트워크 엔티티들을 포함할 수 있다. IMS 네트워크는, LRF(330), P-CSCF(Proxy Call Session Control Function)(320), S-CSCF(Serving Call Session Control Function)(322), E-CSCF(Emergency Call Session Control Function)(324), BGCF(Breakout Gateway Control Function)(340), MGCF(media gateway control function)(338), IBCF(Interconnection Border Control Function)(326), 및 RDF(Routing Determination Function)(328)를 포함할 수 있다.
[0052] 동작 시, LTE 아키텍처(300)는 제어 플레인 위치에 대한 LTE 인터페이스들 및 프로토콜들을 활용할 수 있다. OMA LPPe 프로토콜과 조합된 3GPP TS 36.355에서 정의된 LPP 프로토콜은 E-SMLC(308)에 의한 UE(100)의 포지셔닝을 위해 UE(100)와 eNB(302) 사이의 Uu 인터페이스 상에서 사용될 수 있다. LPP/LPPe 메시지들은, 3GPP TS들 23.271 및 36.305에서 설명된 바와 같이, UE(100)에 대한 eNB(302) 및 MME(304)를 통해 UE(100)와 E-SMLC(308) 사이에서 전달될 수 있다. HALI(heightened accuracy location information)를 지원하기 위해, E-SMLC(308)는 (예컨대, LPP/LPPe 요청 위치 정보 메시지를 UE(100)에 전송함으로써) 요청하도록 구성될 수 있고, UE(100)는 (예컨대, LPP/LPPe 제공 위치 정보 메시지를 E-SMLC(308)에 전송함으로써) 가시적 WLAN AP들의 아이덴티티들, 가시적 WLAN AP들의 신호 측정들(예컨대, RSSI, RTT), 및 UE(100)에 의해 지원되는 경우 UBP(uncompensated barometric pressure)를 제공하도록 구성될 수 있다. 이러한 정보는 OMA LPPe 버전 1.0, 버전 1.1 및 버전 2.0 프로토콜들에서 지원된다.
[0053] 대안적 실시예에서, (i) LPPe 없이 LPP 프로토콜만이 또는 (ii) 3GPP 36.331에서 정의된 LTE에 대한 RRC(Radio Resource Control) 프로토콜이 E-SMLC(308)에 의한 UE(100)의 포지셔닝을 위해 UE(100)와 서빙 eNB(302) 사이의 Uu 인터페이스 상에서 사용될 수 있다. LPP의 경우(대안 (i)), LPP 메시지들은, 3GPP TS들 23.271 및 36.305에서 설명된 바와 같이, UE(100)에 대한 서빙 eNB(302) 및 MME(304)를 통해 UE(100)와 E-SMLC(308) 사이에서 전달될 수 있다. RRC의 경우(대안 (ii)), RRC 메시지들은 UE(100)와 서빙 eNB(302) 사이에서 전달될 수 있고, LPPa(LTE Positioning Protocol A) 메시지들은 3GPP TS들 23.271 및 36.305에서 설명된 바와 같이, UE(100)에 대한 MME(304)를 통해 eNB(302)와 E-SMLC(308) 사이에서 전달될 수 있다. HALI(heightened accuracy location information)를 지원하기 위해, E-SMLC(308)는 (예컨대, LPP 요청 위치 정보 메시지를 UE(100)에 전송하거나, eNB(302)로 하여금 RRC 요청 메시지를 UE(100)에 전송하게 할 수 있는 LPPa 요청 메시지를 eNB(302)에 전송함으로써) 요청하도록 구성될 수 있고, UE(100)는 (예컨대, LPP 제공 위치 정보 메시지를 E-SMLC(308)에 전송하거나, 또는 eNB(302)로 하여금 LPPa 응답을 E-SMLC(308)에 전송하게 하는 RRC 응답을 eNB(302)에 전송함으로써) 가시적 WLAN AP들의 아이덴티티들, 가시적 WLAN AP들의 신호 측정들(예컨대, RSSI, RTT), 및 UE(100)에 의해 지원되는 경우 UBP(uncompensated barometric pressure)를 제공하도록 구성될 수 있다.
[0054] 3GPP TS 29.171에서 정의된 LCS-AP(LCS(Location Services) Application Protocol)는, MME(304)가, 3GPP 제어 플레인 솔루션을 사용하여 E-SMLC(308)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 MME(304)와 E-SMLC(308) 사이의 SL 인터페이스 상에서 사용될 수 있다. HALI 교환들을 지원하기 위해, LCS-AP 프로토콜은, E-SMLC(308)가, HALI를 MME(304)로 리턴하는 것을 가능하게 할 수 있다. 3GPP TS 29.172에서 정의된 ELP(EPC(Evolved Packet Core) LCS Protocol)는, GMLC(306)가, 3GPP 제어 플레인 솔루션을 사용하여 UE(100)에 대한 위치 정보를 요청 및 획득하는 것을 가능하게 하기 위해 MME(304)와 GMLC(306) 사이의 SLg 인터페이스 상에서 사용될 수 있다. HALI를 지원하기 위해, ELP 프로토콜은, MME(304)가, HALI를 GMLC(306)로 리턴하는 것을 가능하게 할 수 있다. L0 인터페이스는, UE(100)가 PSAP(예컨대, i3 PSAP(344) 또는 레거시 PSAP(348))로의 IMS 응급 호출을 설정하고 있거나 또는 설정하였을 경우, LRF(330)가, 제어 플레인 솔루션을 사용하여 GMLC(306)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 LRF(330)와 GMLC(306) 사이에서 사용될 수 있다. HALI를 지원하기 위해, L0 인터페이스는, GMLC(306)가, HALI를 LRF(330)로 리턴하는 것을 가능하게 할 수 있다. L0 인터페이스에 대해 정의된 가능한 프로토콜들은, OMA에 의해 정의된 MLP(Mobile Location Protocol), IETF(Internet Engineering Task Force)에 의해 정의된 HELD(HTTP(Hypertext Transfer Protocol) Enabled Location Delivery) 프로토콜, 및 TIA/ANSI 조인트 표준 J-STD-036에서 정의된 E2 인터페이스 프로토콜을 포함할 수 있다. Le E2 인터페이스는, UE(100)가 레거시 PSAP(348)로의 응급 호출을 설정하는 경우, 레거시 ES 네트워크(346)가, LRF(330)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 레거시 ES(emergency services) 네트워크(346) 내의 엔티티(예컨대, ALI(Automatic Location Identification) 엔티티)와 LRF(330) 사이에서 사용될 수 있다. Le E2 인터페이스는, TIA/ANSI 조인트 표준 J-STD-036에서 그리고 NENA로부터의 NENA-05-001 표준에서 정의된 E2 프로토콜 또는 OMA에 의해 정의된 MLP(Mobile Location Protocol)을 사용할 수 있다. Le i3 인터페이스는, UE가 i3 ESInet(342)로의 응급 호출을 설정하거나 또는 설정하였을 경우, ESInet(342)(예컨대, ESRP(Emergency Services Routing Proxy) 또는 i3 PSAP(344))과 연결된 또는 ESInet(342) 내의 엔티티가, LRF(330)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 LRF(330)와 ESInet(emergency services i3 network)(342) 사이에서 사용될 수 있다. 하나의 예에서, Le i3 인터페이스는, HELD, MLP, 또는 IETF SIP(Session Initiation Protocol) SUBSCRIBE/NOTIFY 프로토콜을 사용할 수 있다.
[0055] LTE 아키텍처(300)는 또한 또는 대신에, SUPL 사용자 플레인 위치에 대한 프로토콜들 및 인터페이스들을 활용할 수 있다. OMA TS OMA-AD-SUPL-V2_0에서 정의된 Lup 인터페이스는, OMA SUPL 사용자 플레인 솔루션을 사용하여 UE(100)의 포지셔닝을 지원하기 위해 UE(100)(SET(SUPL Enabled Terminal)로 지칭됨)와 E-SLP(332) 사이에서 사용될 수 있다. 응급 호출과 연관된 위치의 경우, E-SLP(332)는 UE(100)에 대한 서빙 코어 네트워크에서 사용되도록 구성될 수 있다. Lup 인터페이스는 UE(100)와 E-SLP(332) 사이에서, OMA-TS-ULP-V2_0_3에서 정의된 ULP 메시지들의 교환을 가능하게 한다. E-SLP(332)는 SLC(336) 및 SPC(334)로 논리적으로 또는 물리적으로 분할될 수 있다. SLC(336)는 UE(100)와의 SUPL 세션을 설정 및 제어하도록 구성된다. SPC(334)는 UE(100)의 위치를 획득하도록 구성된다. 그 다음, 임의의 ULP 메시지에 대한 엔드포인트는, ULP 메시지가 제어 및 서비스 프로비전을 위해 또는 포지셔닝을 위해 사용되는지 여부에 따라 각각 SLC(336)이거나 또는 SPC(334)이다. (예컨대, LTE 액세스를 이용하는) UE(100)의 경우, 포지셔닝을 위해 사용되는 ULP 메시지들은 통상적으로, 하나 또는 그 초과의 LPP 메시지들을 캡슐화한다. 각각의 캡슐화된 LPP 메시지는 하나의 LPPe 메시지를 추가로 캡슐화할 수 있다. 강화된 정확성 위치(heightened accuracy location)를 지원하기 위해, LPP/LPPe는, SPC(334)가, 요청하는 것을 가능하게 하고, UE(100)가, LPP, LPP/LPPe 또는 RRC/LPPa를 사용하여 위의 제어 플레인 위치에 대해 설명된 것과 동일한 정보를 리턴하는 것을 가능하게 하기 위해 사용될 수 있다.
[0056] OMA TS OMA-TS-ILP-V2_0_3에서 정의된 ILP(Internal Location Protocol)는, SLC(336)가, SPC(334)를 사용하여 UE(100)의 포지셔닝을 실시하게 하는 것과 SPC(334)로부터 UE(100)에 대한 위치 정보를 획득하는 것을 가능하게 하기 위해 SLC(336)와 SPC(334) 사이의 Llp 인터페이스 상에서 사용될 수 있다. 강화된 정확성 위치를 지원하기 위해, ILP 프로토콜은, SPC(334)가, HALI를 SLC(336)로 리턴하는 것을 가능하게 할 수 있다. L0 인터페이스는, UE(100)가 PSAP(예컨대, 레거시 PSAP(348) 또는 i3 PSAP(344))로의 IMS 응급 호출을 설정하거나 또는 설정하였을 경우, LRF(330)가, SUPL 솔루션을 사용하여 E-SLP(332)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 LRF(330)와 E-SLP(332) 사이에서 사용될 수 있다. 강화된 정확성 위치를 지원하기 위해, L0 인터페이스는, E-SLP(332)가, 강화된 정확성 위치 정보를 LRF(330)로 리턴하는 것을 가능하게 한다. L0 인터페이스에 대해 정의된 가능한 프로토콜들은, MLP, HELD 및 TIA/ATIS 조인트 표준 J-STD-036에서 정의된 E2 인터페이스 프로토콜을 포함할 수 있다. 사용자 플레인에서의 Le E2 및 Le i3 인터페이스들은 위의 제어 플레인 위치에 대해 설명된 인터페이스들과 동일할 수 있다.
[0057] 도 1-도 3a에 대한 추가적 참조와 함께, 도 3b를 참조하면, UMTS(Universal Mobile Telecommunications System) 액세스로 UBP 정보를 전달하기 위한 UMTS 아키텍처(350)가 도시된다. UMTS 아키텍처(350)는, 도 3a에 도시되고 도 3b에 또한 존재하는 사전에 설명된 엘리먼트들에 추가하여, Node B(352), RNC(radio network controller)(356), SAS(stand-alone SMLC)(354), MSC(mobile switching center) 서버(358), GMLC(306), SGSN(serving GPRS support node)(360), GGSN(gateway GPRS support node)(362)을 가지는 캐리어 네트워크를 포함한다. UMTS 아키텍처에서, SAS(354)는 서빙 코어 네트워크(204) 내의 위치 서버(206)의 예이다.
[0058] 3GPP TS 25.331에서 정의된 UMTS에 대한 RRC 프로토콜은, CS(Circuit Switched) 액세스하는 제어 플레인 위치의 경우 RNC(356)에 의한 UE(100)의 포지셔닝을 위해 Uu 인터페이스 상에서 사용될 수 있다. 강화된 정확성 위치를 지원하기 위해, RNC(356)는 요청하도록 구성되고, UE(100)는 가시적 WLAN AP들(예컨대, WLAN(390) 내의 AP들)의 아이덴티티들, 및 UE(100)에 의해 지원되는 경우에는 UBP(uncompensated barometric pressure)를 제공하도록 구성된다. 3GPP TS 25.453에서 정의된 PCAP(Positioning Calculation Application Part)는, RNC(356)가, 3GPP 제어 플레인 솔루션을 사용하여 SAS(354)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 UE(100)에 대한 RNC(356)와 SAS(354) 사이의 Iupc 인터페이스 상에서 사용될 수 있다. RNC(356) 및 SAS(354)는, SAS(354)가 상이한 포지션 방법들의 사용 및 UE(100)와의 RNC(356) 상호작용을 제어하는 SAS 중심 모드에서, 또는 RNC(356)가 상이한 포지션 방법들의 사용 및 UE(100)와의 모든 상호작용을 제어하고, UE(100)에 대한 보조 데이터를 제공하도록 또는 UE(100)에 의해 RNC(356)로 제공된 위치 관련 측정들로부터 위치를 컴퓨팅하도록 단지 SAS(354)만을 인보크(invoke)하는 RNC 중심 모드에서, PCAP를 사용하여 상호작용할 수 있다. 강화된 정확성 위치를 지원하기 위해, PCAP 프로토콜은, RNC(356)가, UE(100)에 의해 RRC를 사용하여 제공된 추가적 위치 정보(예컨대, WLAN(390) 및/또는 UBP의 측정들)를 전달하는 것을 가능하게 할 수 있다. 3GPP TS 25.413에서 정의된 RANAP(Radio Access Network Application Part) 프로토콜은, MSC 서버(358)가, 3GPP 제어 플레인 솔루션을 사용하여 RNC(356)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 UE(100)에 대한 MSC 서버(358)와 RNC(356) 사이의 Iu-cs 인터페이스 상에서 사용될 수 있다. 3GPP TS 29.002에서 정의된 MAP(Mobile Application Part) 프로토콜은, GMLC(306)가, 3GPP 제어 플레인 솔루션을 사용하여 UE(100)에 대한 위치 정보를 요청 및 획득하는 것을 가능하게 하기 위해 UE(100)에 대한 MSC 서버(358)와 GMLC(306) 사이의 Lg 인터페이스 상에서 사용될 수 있다. Le E2 인터페이스는, UE(100)가 CS 도메인을 사용하여 레거시 PSAP(348)로의 응급 호출을 설정하였을 경우, 레거시 ES 네트워크(346)가, GMLC(306)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 레거시 ES 네트워크(346) 내의 엔티티(예컨대, ALI)와 GMLC(306) 사이에서 사용될 수 있다. Le E2 인터페이스는 TIA/ATIS 조인트 표준 J-STD-036에서 그리고 (NENA로부터의) NENA-05-001 표준에서 정의된다.
[0059] UMTS 아키텍처(350)는 또한, PS(Packet Switched) 액세스 및 제어 플레인 위치의 경우 강화된 정확성 위치를 지원하기 위해 서빙 UMTS 네트워크 내에서의 그리고 서빙 UMTS 네트워크로의 인터페이스들 및 프로토콜들을 지원한다. 3GPP TS 25.331에서 정의된 RRC 프로토콜은, PS 액세스하는 제어 플레인 위치의 경우 RNC(356)에 의한 UE(100)의 포지셔닝을 위해 Uu 인터페이스 상에서 사용될 수 있다. 3GPP TS 25.453에서 정의된 PCAP 프로토콜은, RNC(356)가, 3GPP 제어 플레인 솔루션을 사용하여 SAS(354)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 UE(100)에 대한 RNC(356)와 SAS(354) 사이의 Iupc 인터페이스 상에서 사용될 수 있다. 3GPP TS 25.413에서 정의된 RANAP 프로토콜은, SGSN(360)이, 3GPP 제어 플레인 솔루션을 사용하여 RNC(356)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 UE(100)에 대한 SGSN(360)과 RNC(356) 사이의 Iu-ps 인터페이스 상에서 사용될 수 있다. 3GPP TS 29.002에서 정의된 MAP 프로토콜은, GMLC(306)가, 3GPP 제어 플레인 솔루션을 사용하여 UE(100)에 대한 위치 정보를 요청 및 획득하는 것을 가능하게 하기 위해 UE(100)에 대한 SGSN(360)과 GMLC(306) 사이의 Lg 인터페이스 상에서 사용될 수 있다. 3GPP TS 29.172에서 정의된 ELP 프로토콜은, GMLC(306)가, 3GPP 제어 플레인 솔루션을 사용하여 UE(100)에 대한 위치 정보를 요청 및 획득하는 것을 가능하게 하기 위해 UE(100)에 대한 SGSN(360)과 GMLC(306) 사이의 Lgd 인터페이스 상에서 사용될 수 있다. Lgd 인터페이스는 3GPP EPS(Evolved Packet System) 기반 인터페이스들 및 프로토콜들을 지원하는 SGSN에 적용가능하다. L0 인터페이스는, UE(100)가 PS 액세스를 사용하여 PSAP(예컨대, 레거시 PSAP(348) 또는 i3 PSAP(344))로의 응급 호출을 설정하고 있거나 또는 설정하였을 경우, LRF(330)가, 3GPP 제어 플레인 솔루션을 사용하여 GMLC(306)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 LRF(330)와 GMLC(306) 사이에서 사용될 수 있다. 강화된 정확성 위치를 지원하기 위해, L0 인터페이스는, GMLC(306)가, 강화된 정확성 위치 정보를 LRF(330)로 리턴하는 것을 가능하게 할 수 있다. L0 인터페이스에 대해 정의된 가능한 프로토콜들은, MLP, HELD 및 J-STD-036에서 정의된 E2 인터페이스 프로토콜을 포함한다. Le E2 인터페이스는, UE(100)가 PS 액세스를 사용하여 레거시 PSAP(348)로의 응급 호출을 설정하였을 경우, 레거시 ES 네트워크(346)가, LRF(330)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 레거시 응급 서비스 네트워크 내의 레거시 ES 네트워크(346)와 LRF(330) 사이에서 사용될 수 있다. Le E2 인터페이스는 TIA/ATIS 조인트 표준 J-STD-036에서 그리고 NENA-05-001 또는 OMA MLP 프로토콜에서 정의된 E2 프로토콜을 사용할 수 있다. Le i3 인터페이스는, UE(100)가 PS 액세스를 사용하여 ESInet(342)로의 응급 호출을 설정하고 있거나 또는 설정하였을 경우, ESInet(예컨대, ESRP 또는 i3 PSAP(344))와 연결된 또는 ESInet 내의 엔티티가, LRF(330)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 LRF(330)와 ESInet(emergency services i3 network)(342) 사이에서 사용될 수 있다. Le i3 인터페이스는 HELD, MLP 또는 SIP SUBSCRIBE/NOTIFY를 사용할 수 있다.
[0060] UMTS 아키텍처(350)는 또한 또는 대신에, 사용자 플레인 위치의 경우 강화된 정확성 위치를 지원하기 위해 UMTS PS 액세스 내에서의 인터페이스들 및 프로토콜들을 지원한다. OMA 규격 OMA-AD-SUPL-V2_0에서 정의된 Lup 인터페이스는, OMA SUPL 사용자 플레인 솔루션을 사용하여 UE(100)의 포지셔닝을 지원하기 위해 UE(100)와 E-SLP(332) 사이에서 사용될 수 있다. Lup 인터페이스는, 포지셔닝되는 UE(100)와 E-SLP(332) 사이의, OMA TS OMA-TS-ULP-V2_0_3에서 정의된 SUPL ULP 메시지들의 교환을 가능하게 한다. E-SLP(332)는 SLC(336) 및 SPC(334)로 분할되고, SLC(336)는 UE(100)와 E-SLP(332) 사이의 SUPL 세션을 설정 및 제어하기 위해 사용되고, SPC(334)는 UE(100)의 위치를 획득하기 위해 사용된다. 임의의 SUPL ULP 메시지에 대한 엔드포인트는, ULP 메시지가 (엔드포인트가 SLC(336)일 때) 제어 및 서비스 프로비전을 위해 사용되는지 또는 (엔드포인트가 SPC(334)일 때) 포지셔닝을 위해 사용되는지에 따라 SLC(336) 또는 SPC(334)이다. UMTS 액세스를 이용하는 UE(100)의 경우, 포지셔닝을 위해 사용되는 ULP 메시지들은, 3GPP TS 25.331에서 정의된 RRC 프로토콜에 대해 하나 또는 그 초과의 LPP 메시지들 또는 하나 또는 그 초과의 RRC 메시지들을 캡슐화할 수 있다. LPP 메시지들의 경우, 각각의 캡슐화된 LPP 메시지는 하나의 LPPe 메시지를 추가로 캡슐화할 수 있다. 강화된 정확성 위치를 지원하기 위해, LPP, LPP/LPPe 또는 RRC는, SPC(334)가, 요청하는 것을 가능하게 하고, UE(100)가, 제어 플레인 위치에 대해 설명된 것과 동일한 정보(예컨대, WLAN(390) 및/또는 UBP에 대한 측정들)를 리턴하는 것을 가능하게 하기 위해 사용될 수 있다. OMA TS OMA-TS-ILP-V2_0_3에서 정의된 ILP 프로토콜은, SLC(336)가, SPC(334)를 사용하여 UE(100)의 포지셔닝을 실시하게 하는 것과 SPC(334)로부터 UE(100)에 대한 위치 정보를 획득하는 것을 가능하게 하기 위해 SLC(336)와 SPC(334) 사이의 Llp 인터페이스 상에서 사용될 수 있다. L0 인터페이스는, UE(100)가 PSAP(예컨대, 레거시 PSAP(348) 또는 i3 PSAP(344))로의 IMS 응급 호출을 설정하고 있거나 또는 설정하였을 경우, LRF(330)가, E-SLP(332)로부터 UE(100)에 대한 위치 정보를 요청하는 것을 가능하게 하기 위해 LRF(330)와 E-SLP(332) 사이에서 사용될 수 있다. L0 인터페이스에 대해 정의된 가능한 프로토콜들은, MLP, HELD 및 J-STD-036에서 정의된 E2 인터페이스 프로토콜을 포함할 수 있다. Le E2 및 Le i3 인터페이스에 대한 영향들은 사전에 설명된 UMTS 제어 플레인 위치에 대한 영향들과 동일하다.
[0061] 도 1-도 3b에 대한 추가적 참조와 함께, 도 4를 참조하면, 도시 위치 정보를 이용하는 예시적 UBP 전달 프로시저의 메시지 흐름 다이어그램(400)이 도시된다. 메시지 흐름에서의 노드들은 UE(402), 서빙 네트워크(404) 및 PSAP(406)를 포함한다. UE(402)는 도 1-도 3b의 UE(100)에 대응할 수 있다. 서빙 네트워크(404)는 도 2의 서빙 코어 네트워크(204), 및/또는 도 3a 및 도 3b에 도시되는 LTE 및 UMTS 아키텍처들(300, 350)의 하나 또는 그 초과의 엘리먼트들을 포함할 수 있다. PSAP(406)는 레거시 PSAP(348) 또는 i3 PSAP(344)에 대응할 수 있다. 예컨대, UBP(uncompensated barometric pressure)는, 서빙 네트워크(404) 내의 위치 서버(예컨대, 위치 서버(206), E-SMLC(308), E-SLP(332) 또는 SAS(354)) 및 서빙 네트워크(404) 내의 게이트웨이(예컨대, 게이트웨이(208), GMLC(306) 또는 LRF(330))를 통해 UE(402)로부터 PSAP(406)(예컨대, i3 PSAP(344), 레거시 PSAP(348))로 전달될 수 있다. UE(402) 내의 압력 센서(130)는 UBP를 측정하도록 구성될 수 있고, 프로세서(111) 및 무선 트랜시버(121)는 제 1 메시지(408)를 통해 UBP를 서빙 코어 네트워크(404)에 제공하도록 구성될 수 있다. 하나의 예에서, 제 1 메시지(408)는, LPPe를 사용하여 UE(402)에 의해 위치 서버(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))에 제공될 수 있으며, 여기서, LPPe는 LPP와 조합하여(즉, LPP/LPPe로서) 사용될 수 있다. LPPe에서 지원되는 UBP는, 하나의 실시예에서, 30,000 내지 115,000 Pa의 범위를 가지는 파스칼(Pa)의 단위들일 수 있다. 다른 측정 유닛들(예컨대, 밀리바) 및 범위들은 또한 UBP를 위해 사용될 수 있다. 일반적으로, UBP 범위는 UE(402)에 대한 임의의 가능성 있는 고도에서 가능한 실내 또는 실외 대기압들을 표현하기에 충분해야 한다. 다른 예에서, 제 1 메시지(408)는, (i) LPP, (ii) (예컨대, UE(402)와 eNB(302)와 같은 서빙 eNB 사이의) LTE에 대한 RRC 플러스 (예컨대, 서빙 eNB와 E-SMLC(308) 사이의) LPPa, 또는 (iii) (예컨대, UE(402)와 RNC(356)와 같은 서빙 RNC 사이의) UMTS에 대한 RRC 플러스 (예컨대, 서빙 RNC와 SAS(354) 사이의) PCAP를 사용하여, UE(402)에 의해 위치 서버(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))에 제공될 수 있다.
[0062] 스테이지(410)에서, 서빙 네트워크(404)(예컨대, 서빙 네트워크(404) 내의 위치 서버(206), 이를테면, E-SMLC(308), E-SLP(332), SPC(334) 또는 SAS(354))는 제 1 메시지(408)를 통해 수신된 UBP를 UE(402)에 대한 도시 위치 정보와 조합하도록 구성된다. 도시 위치 정보는 사전에 설명된 NEAD(212)와 같은 NEAD에 의해 제공될 수 있다. 기존 인터넷 표준들(예컨대, IETF RFC 6848)은, DHCP(Dynamic Host Configuration Protocol)에 의해 또는 PIDF-LO(Presence Information Data Format Location Object) 문서들에 사용되는 바와 같은 도시 위치에 대한 IANA(Internet Assigned Numbers Authority) 확장 타입들을 정의하고 이들에 등록하기 위한 메커니즘을 제공한다. 이러한 메커니즘에 기초하는 도시 주소 타입은 숫자(예컨대, 파스칼 또는 밀리바 단위들의 10진수 또는 2진수)로서 UBP를 전달하도록 등록될 수 있다. UE(402)에 대한 디스패치가능한 도시 위치가 (예컨대, 도 2와 연관하여 사전에 설명된 바와 같은) NEAD(212)로부터 수신된 UE(402)에 대한 하나 또는 그 초과의 도시 위치들을 사용하여 위치 서버(예컨대, 위치 서버(206), E-SMLC(308), SAS(354), SPC(334) 또는 E-SLP(332))에서 결정되는 경우, 그리고, UBP가 또한 UE(402)로부터 위치 서버에서 수신되는 경우, 스테이지(410)에서, 서빙 네트워크(404) 내의 위치 서버는 UBP를 전달하기 위해 IANA에 등록되었던 도시 주소 타입을 사용하여 UBP를 도시 위치로 조합할 수 있다. 조합된 디스패치가능한 도시 위치 및 UBP 파라미터(412)를 포함하는 메시지는 중간 엔티티들(예컨대, MME(304), GMLC(306), SLC(336), RNC(356), MSC 서버(358), SGSN(360) 중 하나 또는 그 초과의 것)을 통해 그리고 PSAP에 대한 게이트웨이(예컨대, GMLC(306) 또는 LRF(330))까지 투명하게 전달 및 프로세싱될 수 있다. 하나의 예에서, 조합된 디스패치가능한 도시 위치 및 UBP 파라미터(412)는 IETF HELD 프로토콜, OMA MLP 또는 J-STD-036 E2 프로토콜을 사용하여 PSAP(406)에 전달되고, PSAP(406)는 디스패치가능한 도시 위치 및 UBP 측정 둘 다를 PSAP(406) 운영자(도 4에 도시되지 않음)에게 제시한다. 다른 예에서, 서빙 네트워크(404) 내의 게이트웨이(예컨대, GMLC(306) 또는 LRF(330))는, 수신된 디스패치가능한 도시 위치 및 UBP 파라미터(412)로부터 UBP를 추출하고, (예컨대, HELD, MLP 또는 E2 프로토콜에 대한 새로운 파라미터를 사용하여) UBP를 PSAP(406)에 개별적으로 전달할 수 있다. 디스패치가능한 도시 위치가 NEAD(212)로부터 서빙 네트워크(404) 내의 위치 서버에 의해 획득되지 않은 경우, 서빙 네트워크(404) 내의 위치 서버는 단지 UBP만을 포함하는 엠티 디스패치가능한 도시 위치 파라미터(412)를 구성하도록 구성될 수 있다. 이러한 엠티 디스패치가능한 도시 위치(예컨대, 단지 UBP)는 사전에 설명된 바와 같은 조합된 디스패치가능한 도시 위치 및 UBP 파라미터(412)에 대해 동일한 방식으로 전달될 수 있다.
[0063] 흐름 다이어그램(400)은 진화 데이터 포맷들, 인터페이스들 및 프로토콜들에 기초하여 수정될 수 있다. 예컨대, 새로운 CA(civic address) 타입은, 구체적으로, 위에서 설명된 바와 같은 UBP를 반송하기 위해 IANA에 등록될 수 있다. 대안적으로, 새로운 도시 주소 타입은, UE의 위치에 대한 환경적 데이터, 이를테면, 온도, 습도뿐만 아니라 UBP를 반송하기 위해 IANA에 등록될 수 있다. 대안적으로 또한, 새로운 다양한 종류의(miscellaneous) 도시 주소 타입이, 도시 위치 내의 다른 곳에 적합하지 않고 그 컨텐츠가 IANA에 의해 제약되거나 또는 정의되지 않는 다양한 종류의 정보를 반송하기 위해 IANA에 등록될 수 있다. 이러한 새로운 다양한 종류의 도시 주소 타입은 문자 스트링을 포함할 수 있으며, UBP를 전달하기 위해 특정 문자 스트링, 이를테면, "UncompensatedBaroPressure=nnnnnnPa"(예컨대, 여기서, nnnnnn은 10진수로 표현되는 UBP의 값을 표현하는 10진수 디짓들의 시퀀스임)를 전달하기 위해 사용될 수 있다. IANA에 이미 등록된 기존 도시 주소 타입은 또한 UBP를 전달하기 위해 사용될 수 있다. 예컨대, UBP를 전달하기 위해 사용될 수 있는 PIDF-LO에 대한 2가지 기존 도시 주소 타입들이 존재한다. 구체적으로, 도시 주소 타입 22(LOC로 지칭됨)는 추가적(즉, 특정되지 않은) 위치 정보를 포함하고, 도시 주소 타입 32(ADDCODE로 지칭됨)는 추가적 숫자 코드를 허용한다. 타입 22 및 타입 32의 도시 주소 타입들은 UBP를 전달하기 위해 문자 스트링, 이를테면, "UncompensatedBaroPressure=nnnnnnPa"(예컨대, 여기서, nnnnnn은 10진수로 UBP 값을 표현하는 10진수 디짓들의 시퀀스임)를 포함하는 것으로 예상될 수 있다.
[0064] 도 1-도 3b에 대한 추가적 참조와 함께, 도 5를 참조하면, 메시지 호 흐름 다이어그램(500)은 지리적 위치 정보를 이용하는 UBP 전달 프로시저의 다른 예를 도시한다. 메시지 호 흐름에서의 노드들은 UE(502), 위치 서버(504), 게이트웨이(506) 및 PSAP(508)를 포함한다. UE(502)는 도 1-도 3b의 UE(100)에 대응할 수 있다. 위치 서버(504) 및 게이트웨이(506)는, 도 2, 도 3a 및 도 3b에 도시된 바와 같은 통신 시스템(200) 및/또는 LTE 및 UMTS 아키텍처들(300, 350)의 하나 또는 그 초과의 엘리먼트들에 대응할 수 있다. 예컨대, 위치 서버(504)는 위치 서버(206), E-SMLC(308), E-SLP(332), SPC(334) 또는 SAS(354)에 대응할 수 있다. 게이트웨이(506)는 게이트웨이(208), LRF(330) 또는 GMLC(306)에 대응할 수 있다. PSAP(508)는 레거시 PSAP(348) 또는 i3 PSAP(344)에 대응할 수 있다. 예컨대, UBP(uncompensated barometric pressure)는, 위치 서버(504)(예컨대, 위치 서버(206), E-SMLC(308), SAS(354) 또는 E-SLP(332)) 및 게이트웨이(506)(예컨대, 게이트웨이(208), GMLC(306) 또는 LRF(330))를 통해 UE(502)로부터 PSAP(508)(예컨대, i3 PSAP(344), 레거시 PSAP(348))로 전달될 수 있다. UE(502) 내의 압력 센서(130)는 UBP를 측정하도록 구성될 수 있고, 프로세서(111) 및 무선 트랜시버(121)는 제 1 메시지(510)를 통해 UBP를 위치 서버(504)에 제공하도록 구성될 수 있다. 하나의 예에서, 제 1 메시지(510)는 LPPe를 사용하여 UE(502)에 의해 위치 서버(504)(예컨대, E-SMLC(308), SAS(354) 또는 E-SLP(332))에 제공되며, 여기서, LPPe는 LPP와 조합하여(예컨대, LPP/LPPe로서) 사용될 수 있다. 다른 예에서, 제 1 메시지(510)는, (i) LPP, (ii) (예컨대, UE(502)와 eNB(302)와 같은 서빙 eNB 사이의) LTE에 대한 RRC 플러스 (예컨대, 서빙 eNB와 E-SMLC(308) 사이의) LPPa, 또는 (iii) (예컨대, UE(502)와 RNC(356)와 같은 서빙 RNC 사이의) UMTS에 대한 RRC 플러스 (예컨대, 서빙 RNC와 SAS(354) 사이의) PCAP를 사용하여, UE(502)에 의해 위치 서버(504)(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))에 제공될 수 있다. UE(502)의 지리적 위치는 위치 서버(504)에 의해 결정될 수 있거나, 또는 UE(502)로부터 위치 서버(504)에서 수신될 수 있다. 스테이지(512)에서, 위치 서버(504)는 (예컨대, 제 1 메시지(510)에서 UE(502)로부터 수신된 바와 같은) UBP와 지리적 위치를 조합하도록 구성된다. 그 다음, 조합된 지리적 위치 및 UBP 파라미터(514)는 게이트웨이(506)(예컨대, GMLC(306) 또는 LRF(330))에 전달될 수 있다. 조합된 지리적 위치 및 UBP 파라미터의 전달은 서빙 네트워크 내의 중간 엔티티들에 대해 투명할 수 있다(예컨대, MME(304), GMLC(306), SLC(336), RNC(356), MSC 서버(358), SGSN(360) 중 하나 또는 그 초과의 것에 대해 투명할 수 있음). 조합된 지리적 위치 및 UBP 파라미터(514)는 추가로, 도 3a 및 도 3b와 연관하여 사전에 설명되었던 3GPP 제어 플레인 위치 솔루션 또는 SUPL 사용자 플레인 위치 솔루션에 대한 기존 인터페이스들 및 프로토콜들을 사용하여 위치 서버(504)로부터 게이트웨이(506)로 투명하게 전달될 수 있다. 이러한 인터페이스들은 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs 및 Iu-ps 인터페이스들 중 하나 또는 그 초과의 것을 포함할 수 있다. 하나의 예에서, 지리적 위치가 위치 서버(504)에 의해 UE(502)로부터 수신되지 않거나, 또는 위치 서버(504)에 의해 결정되지 않은 경우, 임의의 엠티(Null) 지리적 위치는, UBP를 PSAP(508)에 대한 게이트웨이(506)(예컨대, GMLC(306) 또는 LRF(330))까지 전달하기 위해 위치 서버(504)에 의해 생성될 수 있다. 스테이지(516)에서, 게이트웨이(506)(예컨대, GMLC(306) 또는 LRF(330))는, 조합된 지리적 위치 및 UBP 파라미터(514)를 파싱하고 지리적 위치로부터 (또는 지리적 위치가 엠티인 경우에는 Null 지리적 위치로부터) UBP를 제거하도록 구성된다. 제거된 UBP는 별개의 파라미터로서 PSAP(508)에 전송될 수 있다. 예컨대, 게이트웨이(506)는 메시지(518)에서 제거된 UBP를 PSAP(508)에 파라미터로서 전송할 수 있다.
[0065] 통상적으로, 지리적 위치는 3GPP TS 23.032에서 정의된 옥텟 스트링들에 의해 3GPP 프로토콜들에서 표현될 수 있다. UBP를 3GPP 지리적 위치로 조합하기 위해, 위치 서버(504)는 UBP를 전달하기 위해 작은 고정 수(예컨대, 2개 또는 3개)의 추가적 옥텟들을 지리적 위치 옥텟 스트링과 연접시키도록 구성될 수 있다. 하나의 예에서, UBP는 지리적 위치 스트링에 추가된 3개의 추가적 옥텟들을 사용하여 Pa 단위들로 2 진 값으로서 인코딩될 수 있다. 추가적 옥텟들은 지리적 위치 스트링의 끝에서 연접될 수 있으며, 조합된 지리적 위치 스트링 및 UBP의 길이가 UBP를 인코딩하기 위해 사용되는 알려진 고정 수의 옥텟들에 의해 (예컨대, 지리적 위치 스트링에서 제 1 옥텟에 의해 표시되는 바와 같이) 지리적 위치의 타입에 대해 정의된 길이를 초과함을 결정함으로써 (예컨대, 게이트웨이(506)에 의해) 검출될 수 있다. 그 다음, 게이트웨이(506)는 조합된 지리적 위치 및 UBP 파라미터로부터 추가적 UBP 옥텟들을 파싱하도록 구성될 수 있다.
[0066] 하나의 예에서, UBP는 지리적 위치의 고도 좌표에서 위치 서버(504)에 의해 포함될 수 있다. 3GPP 네트워크들의 경우, (예컨대, TS 23.032에서 표준화된 바와 같은) 고도를 포함하는 2가지 타입들의 지리적 위치 형상들이 존재한다. 2개의 지리적 위치 형상들은 고도를 가지는 타원체 점(ellipsoid point), 및 고도와 불확정성 타원체를 가지는 타원체 점을 포함한다. 지리적 위치 형상들 둘 다의 경우, 고도 좌표는 UBP를 Pa의 단위들로 2개의 Pa의 정밀도로 포함하는 것을 지원할 2개의 옥텟들이다. 하나의 실시예에서, UBP는, 스테이지(512)에서 위치 서버(504)(예컨대, E-SMLC(308), SAS(354) 또는 E-SLP(332))에 의해 알려진 알고리즘을 사용하여 일부 고정 기준 해수면 압력(임의의 현재 해수면 압력과 관련되지 않음)에 대한 동등한 고도(또는 깊이)로 변환되고, 게이트웨이(506)(예컨대, GMLC(306) 또는 LRF(330))에 의해 스테이지(516)에서 UBP로 다시 변환될 수 있다. 서빙 네트워크들은 지리적 위치의 고도 좌표가 UBP 정보 또는 실제 고도를 표현하는지 여부를 결정하도록 구성될 수 있다. 하나의 예에서, 네트워크는 단지, 모든 UE들에 대해 하나의 타입의 고도 좌표 ― 예컨대, UBP를 인코딩하는 고도 또는 실제 고도 중 하나 ― 만을 지원할 수 있다. 다른 예에서, UBP를 반송하는 고도 좌표를 실제 고도를 표현하는 고도 좌표로부터 구별하기 위해 변환이 네트워크에서 사용될 수 있다. 이러한 변환은, 서빙 네트워크가, 실제 고도 및 UBP를 인코딩하는 고도 둘 다를 지원하게 허용할 것이다. 제한이 아니라 예로서, 실제 고도를 UBP를 인코딩하는 고도 값으로부터 구별하기 위한 하나의 가능한 변환은, 고도 및 불확정성 타원체를 가지는 타원체 점의 경우 7 비트 불확정성 고도를 사용하는 것을 포함할 수 있다(예컨대, UBP를 표시하기 위해 불확정성의 값을 정상적으로 에러가 없음을 의미하는 0으로 세팅함). 고도를 가지는 타원체 점 및 고도와 불확정성 타원체를 가지는 타원체 점 둘 다에 적용가능한 다른 예시적 변환은, UBP를 인코딩하기 위해 정상적으로 발생하지 않을 고도 값들의 범위를 예비하는 것을 포함한다. 예컨대, -2**14 내지 -2**15 미터의 범위의 깊이는 UBP를 인코딩하기 위해 재할당될 수 있는데, 이는 UBP를 인코딩하기 위해 14 비트를 할당하는 것을 실질적으로 의미할 수 있으며, 약 8 Pa의 정밀도를 허용할 수 있다. 하나의 실시예에서, MLP(Mobile Location Protocol) 데이터 구조들은 UBP 파라미터를 정의하기 위해 사용될 수 있다. 예컨대, MLP에서, 지리적 위치 형상들은 XML를 사용하여 문자 스트링들로서 정의될 수 있다. 기존 또는 새로운 XML 태그들은 UBP 파라미터를 정의하기 위해 사용될 수 있다.
[0067] 하나의 실시예에서, 위치 서버(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))는, (예컨대, 도 2와 연관하여 사전에 설명된 바와 같이) NEAD(212)로부터 수신된 UE에 대한 하나 또는 그 초과의 도시 위치들을 사용하여 UE(예컨대, UE(100))에 대한 디스패치가능한 도시 위치를 결정할 수 있다. 그 다음, 위치 서버는 (예컨대, RFC들 5139 및 6848에서 정의된 바와 같이) PIDF-LO 위치 오브젝트 내에서 결정된 디스패치가능한 도시 위치를 전달할 수 있고, 이는 게이트웨이(예컨대, GMLC(306) 또는 LRF(330))에 전달될 수 있고, 그 다음, 변경 없이 PSAP에(예컨대, HELD, MLP 또는 J-STD-036의 E2 프로토콜을 사용하여 i3 PSAP(344) 또는 레거시 PSAP(348)에) 전달되거나 또는 (예컨대, HELD, MLP 또는 J-STD-036 E2 프로토콜에 의해 지원되는 프리 포맷 도시 위치를 사용하여) PSAP에 전달될 수 있는 디스패치가능한 도시 위치 부분을 추출하기 위해 사용될 수 있다. PIDF-LO 위치 오브젝트는, 도시 위치, 지리적 위치 또는 도시 위치 플러스 지리적 위치뿐만 아니라 다수의 다른 위치 관련 파라미터들, 이를테면, 날짜/시간스탬프 및 프라이버시 요건들을 포함할 수 있다. 서빙 네트워크에서 위치 서버로부터 게이트웨이로의 지리적 위치 전달이 3GPP 제어 플레인 위치 솔루션 및 OMA SUPL 사용자 플레인 위치 솔루션에 대해 적용가능한 3GPP 및 OMA 프로토콜들에서 다른 기존 파라미터들에 의해 지원될 수 있으므로, PIDF-LO의 지리적 위치 컴포넌트가 사용될 필요가 없을 수 있다. 위치 서버(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))는 UBP의 포함을 지원하기 위해 PIDF-LO 내의 새로운 또는 기존 파라미터, 새로운 또는 기존 필드 또는 다른 새로운 또는 기존 값을 사용하여 (예컨대, UE(100) 또는 UE(502)로부터 수신된) UBP를 PIDF-LO로 조합할 수 있다. 그 다음, UBP를 포함하는 PIDF-LO는 게이트웨이(예컨대, 게이트웨이(208), LRF(330) 또는 GMLC(306))를 통해 PSAP에 전달될 수 있거나, 또는 게이트웨이까지 전달될 수 있고, 여기서, UBP는 PIDF-LO로부터 추출되어 PSAP에 개별적으로 전달된다.
[0068] 도 1-도 5에 대한 추가적 참조와 함께, 도 6을 참조하면, UBP 및 도시 위치 정보를 PSAP에 제공하기 위한 프로세스(600)는 도시되는 스테이지들을 포함한다. 그러나, 프로세스(600)는 제한이 아니라 단지 예이다. 프로세스(600)는, 예컨대, 스테이지들을 추가, 제거, 재배열, 조합, 및/또는 동시 수행함으로써 변경될 수 있다. 예컨대, UBP 정보는, 도시 위치 정보를 획득하기 이전에 서빙 네트워크에 의해 획득될 수 있다. UBP 및 도시 위치 정보는 하나 또는 그 초과의 메시지들에서 PSAP에 제공될 수 있다. 하나의 실시예에서, 프로세스(600)는 도 9에 도시되는 바와 같은 하나 또는 그 초과의 컴퓨터 시스템들 상에서 실행될 수 있다.
[0069] 스테이지(602)에서, 서빙 코어 네트워크(204)는 UE(user equipment)(100)에 대한 디스패치가능한 도시 위치를 획득하도록 구성된다. 서빙 코어 네트워크(204)는 (예컨대, 도 2와 연관하여 사전에 설명된 바와 같이) NEAD(212)로부터 UE(100)에 대한 도시 위치 정보(예컨대, 하나 또는 그 초과의 도시 위치들을 포함함)를 획득하고, 이러한 도시 위치 정보로부터 디스패치가능한 도시 위치를 획득하기 위한 수단으로서 위치 서버(206), 이를테면, E-SMLC(308), E-SLP(332), 및/또는 SAS(354)를 포함할 수 있다. 도시 위치 정보는 (i) 하나 또는 그 초과의 MAC(Media Access Control) 어드레스들 및/또는 UE(100)에 가시적인 하나 또는 그 초과의 WiFi 및/또는 BT AP들과 연관된 다른 어드레스들, (ii) UE(100)에 가시적인 기지국 ID들(예컨대, eNB 또는 홈 eNB 셀 ID(identity)들), 또는 (iii) 다른 지리적 정보, 이를테면, UE(100)의 현재 위치에 기초하여 NEAD(212)에 의해 획득될 수 있다. NEAD(212)로의 액세스는 Nq 인터페이스에 의해 지원될 수 있다. Nq 인터페이스는, 현재 위치와 같은 위치 정보와 연관된 도시 위치 정보 또는 (응급 호출을 발신하였던) UE(100)에 가시적인 하나 또는 그 초과의 기준 점들에 대한, 서빙 코어 네트워크(204)에 의한 질의를 지원할 수 있다.
[0070] 스테이지(604)에서, 서빙 코어 네트워크(204)는 UE(100)로부터 UBP(uncompensated barometric pressure)를 획득하도록 구성된다. UE(100) 내의 압력 센서(130)는 기압을 검출하기 위한 수단이고, 프로세서(111) 및 무선 트랜시버(121)는 UBP를 서빙 코어 네트워크(204)에 제공하기 위한 수단이다. 하나의 예에서, UBP 정보는, UE(100)와 (i) E-SLP(332) 또는 (ii) E-SMLC(308) (예컨대, E-SMLC(308)의 경우에는 MME(304) 및 eNB(302)를 통해) 사이에서 (예컨대, LPP/LPPe 조합된 프로토콜을 사용하여) 전달되는 LPPe 메시지에 포함될 수 있다. 다른 예에서, UBP 정보는 (i) LPP (예컨대, LPP 메시지는 UE(100)와 E-SLP(332) 또는 E-SMLC(308) 사이에서 그리고 E-SMLC(308)의 경우에는 MME(304) 및 eNB(302)를 통해 전달됨), (ii) LTE에 대한 RRC(예컨대, RRC 메시지가 UE(100)와 eNB(302)와 같은 서빙 eNB 사이에서 전달되고, 서빙 eNB는 그 다음, LPPa 메시지를 사용하여 UBP 정보를 E-SMLC(308)와 같은 E-SMLC에 전달함) 또는 (iii) UMTS에 대한 RRC(예컨대, RRC 메시지는 UE(100)와 RNC(356)와 같은 서빙 RNC 사이에서 전달되고, 서빙 RNC는 그 다음, PCAP 메시지를 사용하여 UBP 정보를 SAS(354)와 같은 SAS에 전달함)에 대한 메시지에 포함될 수 있다.
[0071] 스테이지(606)에서, 서빙 코어 네트워크(204) 내의 위치 서버(206)는 UBP를 디스패치가능한 도시 위치와 조합하도록 구성된다. E-SMLC(308), E-SLP(332), 및/또는 SAS(354)는 UBP를 디스패치가능한 도시 위치와 조합하기 위한 수단이다. 하나의 예에서, UBP는 새로운 CA 타입(예컨대, UBP에 대해 정의된 CA 타입 또는 환경적 데이터로서 또는 다양한 종류의 데이터로서 정의된 CA 타입)을 사용하여 (예컨대, PIDF-LO 오브젝트의 일부일 수 있는) CA(civic address)에 포함되거나, 또는 기존 CA 타입(예컨대, 타입 22 LOC, 또는 타입 32 ADDCODE)에 포함될 수 있다. UBP를 포함하는 도시 위치 또는 (예컨대, UBP를 포함하는 도시 위치가 PIDF-LO에 포함될 때) PIDF-LO는 중간 엔티티들을 통해 그리고 PSAP에 대한 게이트웨이(208)(예컨대, GMLC(306) 또는 LRF(330))까지 투명하게 전달 및 프로세싱될 수 있다.
[0072] 스테이지(608)에서, 서빙 코어 네트워크(204) 내의 게이트웨이(208)는 조합된 UBP 및 디스패치가능한 도시 위치를 PSAP에 제공하도록 구성된다. GMLC(306) 또는 LRF(330)는 UBP 및 디스패치가능한 도시 위치를 PSAP에 제공하기 위한 수단이다. 하나의 예에서, 도시 위치 및 UBP(예컨대, 이들 둘 모두는 PIDF-LO에 포함될 수 있음)는 HELD, MLP 또는 J-STD-036 E2 프로토콜을 사용하여 PSAP(예컨대, i3 PSAP(344) 또는 레거시 PSAP(348))에 전달된다. 대안적 실시예에서, 서빙 코어 네트워크(204) 내의 게이트웨이(208)는 디스패치가능한 도시 위치로부터 UBP를 추출하고, UBP를 PSAP에 개별적으로 제공하도록 구성된다. 하나의 예에서, 추출된 UBP는 HELD, MLP 또는 J-STD-036 E2 프로토콜 중 하나를 사용하여 PSAP에 전달된다.
[0073] 도 1-도 6에 대한 추가적 참조와 함께, 도 7a를 참조하면, 도시 위치 정보 없이 UBP를 PSAP에 제공하기 위한 프로세스(700)는 도시되는 스테이지들을 포함한다. 그러나, 프로세스(700)는 제한이 아니라 단지 예이다. 프로세스(700)는, 예컨대, 스테이지들을 추가, 제거, 재배열, 조합, 및/또는 동시 수행함으로써 변경될 수 있다. 예컨대, UBP 정보는, 도시 위치 정보를 획득하기 이전에 서빙 네트워크에 의해 획득될 수 있다. 하나의 실시예에서, 프로세스(700)는 도 9에 도시되는 바와 같은 하나 또는 그 초과의 컴퓨터 시스템들 상에서 실행될 수 있다.
[0074] 스테이지(702)에서, 서빙 코어 네트워크(204)는 UE(100)로부터 UBP(uncompensated barometric pressure)를 획득하도록 구성된다. UE(100) 내의 압력 센서(130)는 기압을 검출하기 위한 수단이고, 프로세서(111) 및 무선 트랜시버(121)는 UBP를 서빙 코어 네트워크(204)에 제공하기 위한 수단이다. 하나의 예에서, UBP 정보는, UE(100)와 (i) E-SLP(332) 또는 (ii) E-SMLC(308) (예컨대, E-SMLC(308)의 경우에는 MME(304) 및 eNB(302)를 통해) 사이에서 (예컨대, LPP/LPPe를 사용하여) 전달되는 LPPe 메시지에 포함될 수 있다. 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332), 및/또는 SAS(354))는 UE(100)로부터 UBP를 획득하기 위한 수단이다. 다른 예에서, UBP 정보는 (i) LPP (예컨대, LPP 메시지는 UE(100)와 E-SLP(332) 또는 E-SMLC(308) 사이에서 그리고 E-SMLC(308)의 경우에는 MME(304) 및 eNB(302)를 통해 전달됨), (ii) LTE에 대한 RRC(예컨대, RRC 메시지가 UE(100)와 eNB(302)와 같은 서빙 eNB 사이에서 전달되고, 서빙 eNB는 그 다음, LPPa 메시지를 사용하여 UBP 정보를 E-SMLC(308)와 같은 E-SMLC에 전달함) 또는 (iii) UMTS에 대한 RRC(예컨대, RRC 메시지는 UE(100)와 RNC(356)와 같은 서빙 RNC 사이에서 전달되고, 서빙 RNC는 그 다음, PCAP 메시지를 사용하여 UBP 정보를 SAS(354)와 같은 SAS에 전달함)에 대한 메시지에 포함될 수 있다.
[0075] 스테이지(704)에서, 서빙 코어 네트워크(204)는 UBP를 포함하는 도시 위치 기록을 생성하도록 구성된다. 하나의 예에서, 서빙 코어 네트워크(204)는, 사전에 설명된 바와 같이 NEAD(212)로부터 UE(100)에 대한 도시 위치 정보(예컨대, 하나 또는 그 초과의 도시 위치들)를 수신하기 위한 수단으로서 위치 서버(206), 이를테면, E-SMLC(308), E-SLP(332) 또는 SAS(354)를 포함하고, 이 도시 위치 정보로부터 UE(100)에 대한 디스패치가능한 도시 위치를 획득할 수 있다. UBP는 새로운 CA 타입에 필드로서 (예컨대, 환경적 데이터로서, 다양한 종류의 데이터로서 또는 구체적으로 UBP로서) 포함되거나, 또는 기존 도시 주소 타입(예컨대, 타입 22 LOC, 또는 타입 32 ADDCODE)에 포함될 수 있다. 일부 실시예들에서, UBP를 포함하는 디스패치가능한 도시 위치는 PIDF-LO 오브젝트에 포함될 수 있다. 다른 예에서, 디스패치가능한 도시 위치가 획득되지 않은 경우, 위치 서버(206)는 단지 UBP만을 포함하는 엠티 도시 위치 기록을 구성하도록 구성될 수 있다.
[0076] 스테이지(706)에서, 위치 서버(206)는 UBP를 포함하는 도시 위치 기록을 게이트웨이(208)에 제공하도록 구성된다. 하나의 실시예에서, (UBP를 포함하는) 도시 위치 기록은 PIDF-LO의 일부일 수 있다. 하나의 예에서, 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332) 및/또는 SAS(354))는, 기존 인터페이스들 및 이들의 연관된 기존 프로토콜들(예컨대, 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs, Iu-ps 인터페이스들 중 하나 또는 그 초과의 것)을 활용하여 UBP(또는 PIDF-LO)를 포함하는 도시 위치 기록을 게이트웨이(208)(예컨대, GMLC(306) 또는 LRF(330))에 제공할 수 있다. UBP 정보가 도시 위치 기록(이는 PIDF-LO에 추가로 임베딩될 수 있음)에 임베딩될 수 있기 때문에, UBP는 중간 엔티티들을 통해 투명하게 전달 및 프로세싱될 수 있다.
[0077] 스테이지(708)에서, 서빙 코어 네트워크(204) 내의 게이트웨이(208)는 도시 위치 기록으로부터 UBP를 추출하도록 구성된다. GMLC(306) 및/또는 LRF(330)는 도시 위치 기록으로부터 UBP를 추출하기 위한 예시적 수단이다. UBP를 추출하는 것은 스테이지(704)에서 설명된 바와 같은 프로세스의 반대일 수 있다. 예컨대, UBP를 포함하는 새로운 CA 타입 또는 UBP를 포함하는 기존 도시 주소 타입은 이러한 CA 타입으로부터 게이트웨이(208)에 의해 추출되는 UBP에 따라 결정될 수 있다. 디스패치가능한 도시 위치가 704의 일부로서 획득되지 않았을 경우, 게이트웨이(208)는 엠티 도시 위치 기록(즉, UBP 데이터 이외에는 엠티)으로부터 UBP를 추출하도록 구성될 수 있다.
[0078] 스테이지(710)에서, 서빙 코어 네트워크(204) 내의 게이트웨이(208)는 UBP 위치를 PSAP(예컨대, 레거시 PSAP(348) 또는 i3 PSAP(344))에 제공하도록 구성된다. GMLC(306) 또는 LRF(330)는 UBP를 PSAP에 제공하기 위한 수단이다. 서빙 코어 네트워크(204) 내의 게이트웨이(208)(예컨대, GMLC(306) 또는 LRF(330))는 (예컨대, HELD, MLP 또는 J-STD-036 E2 프로토콜에 대한 새로운 파라미터를 사용하여) 수신된 도시 위치 기록으로부터의 UBP를 PSAP에 제공한다. 도시 위치 정보는 UBP와 동일한 메시지로 또는 하나 또는 그 초과의 별개의 메시지들로 제공될 수 있다.
[0079] 도 1-도 7a에 대한 추가적 참조와 함께, 도 7b를 참조하면, UBP를 게이트웨이(208)를 통해 PSAP에 제공하기 위한 프로세스(720)는 도시되는 스테이지들을 포함한다. 그러나, 프로세스(720)는 제한이 아니라 단지 예이다. 프로세스(720)는, 예컨대, 스테이지들을 추가, 제거, 재배열, 조합, 및/또는 동시 수행함으로써 변경될 수 있다. 하나의 실시예에서, 프로세스(720)는 도 9에 도시되는 바와 같은 컴퓨터 시스템 상에서 실행될 수 있다.
[0080] 스테이지(722)에서, 게이트웨이(208)는 UBP(uncompensated barometric pressure)를 포함하는 디스패치가능한 도시 위치 기록을 수신하도록 구성된다. 하나의 예에서, 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332) 및/또는 SAS(354))는, 기존 인터페이스들 및 이들의 연관된 기존 프로토콜들(예컨대, 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs, Iu-ps 인터페이스들 중 하나 또는 그 초과의 것)을 활용하여 UBP를 포함하는 도시 위치 기록을 게이트웨이(208)(예컨대, GMLC(306) 또는 LRF(330))에 제공할 수 있다. 도시 위치 기록은 PIDF-LO의 일부일 수 있다. 임베딩된 UBP 정보는 중간 엔티티들을 통해 투명하게 전달 및 프로세싱될 수 있다.
[0081] 스테이지(724)에서, 게이트웨이(208)는 디스패치가능한 도시 위치 기록으로부터 UBP를 추출하도록 구성된다. GMLC(306) 및/또는 LRF(330)는 디스패치가능한 도시 위치 기록으로부터 UBP를 추출하기 위한 예시적 수단이다. UBP를 추출하는 것은, 예컨대, 새로운 CA 타입을 식별하는 것 또는 기존 도시 주소 타입을 식별하는 것, 및 이러한 CA 타입에 대한 정보로부터 UBP를 추출하는 것을 포함할 수 있다. 게이트웨이(208)는 엠티 도시 위치 기록(즉, UBP 데이터 이외에는 엠티)으로부터 UBP를 추출하도록 구성될 수 있다.
[0082] 스테이지(726)에서, 게이트웨이(208)는 UBP를 PSAP(예컨대, 레거시 PSAP(348) 또는 i3 PSAP(344))에 제공하도록 구성된다. GMLC(306) 또는 LRF(330)는 UBP를 PSAP에 제공하기 위한 수단이다. 서빙 코어 네트워크(204) 내의 게이트웨이(208)(예컨대, GMLC(306) 또는 LRF(330))는 (예컨대, HELD, MLP 또는 J-SRD-036 E2 프로토콜에 대한 새로운 파라미터를 사용하여) 수신된 도시 위치 기록(즉, 도시 위치 정보가 없음)으로부터의 UBP를 PSAP에 제공한다. 도시 위치 정보는 UBP와 동일한 메시지로 또는 하나 또는 그 초과의 별개의 메시지들로 제공될 수 있다.
[0083] 하나의 실시예에서, 게이트웨이(208)는 스테이지(724)에서 디스패치가능한 도시 위치 기록으로부터 UBP를 추출하지 않지만, 대신에, 스테이지(726)에서 도시 위치 기록에 여전히 포함된 UBP를 PSAP에 전달한다.
[0084] 도 1-도 6에 대한 추가적 참조와 함께, 도 7c를 참조하면, UBP를 포함하는 디스패치가능한 도시 위치 기록을 게이트웨이에 제공하기 위한 프로세스(730)는 도시되는 스테이지들을 포함한다. 그러나, 프로세스(730)는 제한이 아니라 단지 예이다. 프로세스(730)는, 예컨대, 스테이지들을 추가, 제거, 재배열, 조합, 및/또는 동시 수행함으로써 변경될 수 있다. 하나의 실시예에서, 프로세스(730)는 도 9에 도시되는 바와 같은 컴퓨터 시스템 상에서 실행될 수 있다.
[0085] 스테이지(732)에서, 서빙 코어 네트워크(204) 내의 위치 서버(206)는 UE(100)로부터 UBP(uncompensated barometric pressure) 및 위치 정보를 획득하도록 구성된다. UE(100) 내의 압력 센서(130)는 기압을 검출하기 위한 수단이고, 프로세서(111) 및 무선 트랜시버(121)는 UBP 및 위치 정보를 서빙 코어 네트워크(204)에 제공하기 위한 수단이다. 위치 정보는 UE(100)에 가시적인 하나 또는 그 초과의 WiFi 및/또는 BT AP들 각각에 대한 하나 또는 그 초과의 MAC 어드레스들을 포함할 수 있다. 하나의 예에서, UBP 및 위치 정보는, UE(100)와 E-SLP(332) 또는 E-SMLC(308) (예컨대, E-SMLC(308)의 경우에는 MME(304) 및 eNB(302)를 통해) 사이에서 (예컨대, LPP/LPPe를 사용하여) 전달되는 하나 또는 그 초과의 LPPe 메시지들에 포함될 수 있다. 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332), 및/또는 SAS(354))는 UE(100)로부터 UBP 및 위치 정보를 획득하기 위한 수단이다. 다른 예에서, UBP 및 위치 정보는 (i) LPP (예컨대, LPP 메시지는 UE(100)와 E-SLP(332) 또는 E-SMLC(308) 사이에서 그리고 E-SMLC(308)의 경우에는 MME(304) 및 eNB(302)를 통해 전달됨), (ii) LTE에 대한 RRC(예컨대, RRC 메시지가 UE(100)와 eNB(302)와 같은 서빙 eNB 사이에서 전달되고, 서빙 eNB는 그 다음, LPPa 메시지를 사용하여 UBP 및 위치 정보를 E-SMLC(308)와 같은 E-SMLC에 전달함) 또는 (iii) UMTS에 대한 RRC(예컨대, RRC 메시지는 UE(100)와 RNC(356)와 같은 서빙 RNC 사이에서 전달되고, 서빙 RNC는 그 다음, PCAP 메시지를 사용하여 UBP 및 위치 정보를 SAS(354)와 같은 SAS에 전달함)에 대한 메시지에 포함될 수 있다.
[0086] 스테이지(734)에서, 위치 서버(206)는 스테이지(732)에서 획득된 위치 정보에 기초하여 UE에 대한 디스패치가능한 도시 위치를 획득하도록 구성된다. 예컨대, 스테이지(732)에서 획득된 위치 정보는, UE(100)에 가시적인, WLAN(390) 내의 하나 또는 그 초과의 WiFi 및/또는 BT AP들의 아이덴티티들(예컨대, MAC 어드레스들)을 포함할 수 있다. 위치 서버(206)는 AP 아이덴티티들(예컨대, MAC 어드레스들)을 NEAD(212)에 제공할 수 있다. 그 다음, NEAD(212)는, 대응하는 도시 위치 정보(예컨대, 시, 거리 주소 및/또는 빌딩 지정, 층 레벨 및 가능하게는 방 또는 아파트 번호)가 (예컨대, 외부 데이터 소스들(216) 및 NEAM(214)을 통해) 사전에 구성된, 알려진 WLAN AP들의 데이터베이스를 탐색할 수 있으며, 제공된 AP 아이덴티티들 중 하나 또는 그 초과의 AP 아이덴티티들 각각에 대응하는 하나 또는 그 초과의 도시 위치들을 위치 서버(206)로 리턴할 수 있다. 그 다음, 위치 서버(206)는 도 2와 연관하여 사전에 설명된 바와 같이, (예컨대, NEAD(212)에 의해 리턴된 도시 위치들 중 하나의 도시 위치를 사용하여) 디스패치가능한 도시 위치를 획득할 수 있다. 하나의 예에서, 위치 서버(206), 이를테면, E-SMLC(308), E-SLP(332), 및/또는 SAS(354)는 디스패치가능한 도시 위치를 획득하기 위한 수단이다.
[0087] 스테이지(736)에서, 위치 서버(206)는 UBP를 포함하는 디스패치가능한 도시 위치 기록을 생성하기 위해 UBP를 스테이지(734)에서 획득된 디스패치가능한 도시 위치와 조합하도록 구성된다. UBP는 새로운 CA 타입에 필드로서 (예컨대, 환경적 데이터로서, 다양한 종류의 데이터로서 또는 구체적으로 UBP로서) 포함되거나, 또는 기존 도시 주소 타입(예컨대, 타입 22 LOC, 또는 타입 32 ADDCODE)에 포함될 수 있다. 다른 예에서, 스테이지(734)에서 디스패치가능한 도시 위치가 획득되지 않은 경우, 스테이지(736)에서 위치 서버(206)는 단지 UBP만을 포함하는 엠티 도시 위치 기록을 구성하도록 구성될 수 있다. 하나의 실시예에서, (UBP를 포함하는) 디스패치가능한 도시 위치 기록은 PIDF-LO의 일부로서 포함될 수 있다.
[0088] 스테이지(738)에서, 위치 서버(206)는 UBP를 포함하는 도시 위치 기록을 게이트웨이(208)에 제공하도록 구성된다. 하나의 실시예에서, (UBP를 포함하는) 도시 위치 기록은 PIDF-LO의 일부로서 제공될 수 있다. 하나의 예에서, 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332) 및/또는 SAS(354))는, 기존 인터페이스들 및 연관된 기존 프로토콜들(예컨대, 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs, Iu-ps 인터페이스들 중 하나 또는 그 초과의 것)을 활용하여 UBP를 포함하는 도시 위치 기록을 게이트웨이(208)(예컨대, GMLC(306) 또는 LRF(330))에 제공할 수 있다. UBP 정보가 도시 위치 기록(이는 PDIF-LO에 추가로 임베딩될 수 있음)에 임베딩될 수 있기 때문에, UBP는 중간 엔티티들을 통해 투명하게 전달 및 프로세싱될 수 있다.
[0089] 이전에 설명된 바와 같이, UBP는 PIDF-LO에 대한 새로운 또는 기존 파라미터 또는 필드를 사용하여 PIDF-LO에 포함될 수 있다. 이러한 경우, UBP는 PIDF-LO에 포함될 수 있지만, 디스패치가능한 도시 위치에 포함되거나 또는 임베딩되지 않을 수 있다. 대신에, PIDF-LO는 (예컨대, PIDF-LO에 대한 새로운 또는 기존 파라미터, 또는 새로운 또는 기존 필드를 사용하여) UBP를 포함할 수 있으며, 또한 일부 경우들에서, UE(100)에 대한 디스패치가능한 도시 위치 및/또는 지리적 위치를 포함할 수 있지만, UBP는 PIDF-LO의 일부이지만 디스패치가능한 도시 위치 및/또는 지리적 위치와는 별개이다. 이러한 경우, 사전에 설명된 프로세스들(600, 700, 720 및 730)은 UBP를 PSAP, 이를테면, 특정 변경들을 가지는 i3 PSAP(344) 또는 레거시 PSAP(348)에 제공하기 위해 서빙 코어 네트워크(204)에 의해 사용될 수 있다. 프로세스들(600, 700, 720 및 730)에 대한 이러한 변경들은, 사전에 설명된 바와 같이 사용되는, 변경되는 것으로 표시되지 않은 프로세스 스테이지들과 함께 다음에 설명된다. 프로세스(600)의 경우, (i) 스테이지(602)가 단지 옵션으로서 수행되고; (ii) (예컨대, 위치 서버(206)에 의해) 스테이지(604)에서 획득된 UBP가 (예컨대, 위치 서버(206)에 의해) 스테이지(606)에서 PIDF-LO와 조합되고 ― PIDF-LO는 또한, 스테이지(602)가 발생한다면, 스테이지(602)에서 획득된 임의의 디스패치가능한 도시 위치를 포함함 ― ; 그리고 (iii) UBP 및 PIDF-LO가 (예컨대, 게이트웨이(208)에 의해) 스테이지(608)에서 PSAP에 제공된다. 프로세스(700)의 경우, (i) 도시 위치 기록에 추가하여 또는 그 대신에 PIDF-LO가 (예컨대, 위치 서버(206)에 의해) 스테이지(704)에서 생성되고 ― PIDF-LO는 UBP (및 생성되었던 임의의 도시 위치 기록)을 포함함 ― ; (ii) 스테이지(704)에서 생성된 PIDF-LO가 (예컨대, 위치 서버(206)에 의해) 스테이지(706)에서 게이트웨이(208)에 제공되고; 그리고 (iii) 게이트웨이(208)가 스테이지(708)에서 PIDF-LO로부터 UBP를 추출한다. 프로세스(720)의 경우, (i) UBP를 포함하는 PIDF-LO가 게이트웨이(208)에 의해 스테이지(722)에서 수신되고; 그리고 (ii) UBP가 게이트웨이(208)에 의해 스테이지(724)에서 PIDF-LO로부터 추출된다. 프로세스(730)의 경우, (i) 스테이지(734)가 선택적이며, 항상 발생하지 않을 수 있고; (ii) 스테이지(736)에서, 스테이지(732)에서 획득된 UBP가 (예컨대, 위치 서버(206)에 의해) PIDF-LO(이는 또한, 스테이지(734)가 발생한다면, 스테이지(734)에서 획득된 임의의 디스패치가능한 도시 위치를 포함할 수 있음)와 조합되고; 그리고 (iii) 스테이지(738)에서, UBP를 포함하는 PIDF-LO가 (예컨대, 위치 서버(206)에 의해) 게이트웨이(예컨대, 게이트웨이(208))에 제공된다.
[0090] 도 1-도 5에 대한 추가적 참조와 함께, 도 8을 참조하면, UBP를 위치 정보 메시징을 통해 PSAP에 제공하기 위한 프로세스(800)는 도시되는 스테이지들을 포함한다. 그러나, 프로세스(800)는 제한이 아니라 단지 예이다. 프로세스(800)는, 예컨대, 스테이지들을 추가, 제거, 재배열, 조합, 및/또는 동시 수행함으로써 변경될 수 있다. 예컨대, UBP 정보는 UE에 대한 위치 정보를 결정 또는 수신하기 이전에, 그와 동시에, 또는 그 이후에 서빙 네트워크에 의해 수신될 수 있다. 하나의 실시예에서, 프로세스(800)는 도 9에 도시되는 바와 같은 하나 또는 그 초과의 컴퓨터 시스템들 상에서 실행될 수 있다.
[0091] 스테이지(802)에서, 서빙 코어 네트워크(204) 내의 위치 서버(206) 및/또는 UE(100)는 UE(100)에 대한 위치 정보를 결정하도록 구성된다. 하나의 예에서, UE(100) 상의 SPS 수신기(155)는 SPS 신호들(159)을 전체적으로 또는 부분적으로 프로세싱하고 이 SPS 신호들(159)을 사용하여 UE(100)의 위치를 결정한다. 프로세서(111), 메모리(140), DSP(112) 및/또는 특수화된 프로세서(들)(도시되지 않음)는 또한, SPS 수신기(155)와 함께, SPS 신호들(159)을 전체적으로 또는 부분적으로 프로세싱하고 그리고/또는 UE(100)의 위치를 계산하기 위해 활용될 수 있다. 위치 서버(206)는 위치 계산의 적어도 일부를 수행하기 위해 사용될 수 있다. UE(100)는 또한, 뷰 내에서의 다른 통신 엔티티들 및/또는 UE(100)에서 이용가능한 정보에 기초하여, 다양한 기법들을 사용하여 연관된 시스템 내에서 자신의 현재 포지션을 추정할 수 있다. UE(100)는 하나 또는 그 초과의 WLAN(wireless local area network)들, Bluetooth 또는 ZigBee® 등과 같은 단거리 무선 통신 기술을 활용하는 PAN(personal area network)들과 연관된 AP(access point)들로부터 획득된 정보, 및/또는 위치 서버(206)로부터 획득된 맵 제약 데이터를 사용하여 자신의 포지션을 추정할 수 있다.
[0092] 스테이지(804)에서, 서빙 코어 네트워크(204)(예컨대, 위치 서버(206))는 UE(100)로부터 UBP(uncompensated barometric pressure)를 수신하도록 구성된다. UE(100) 내의 압력 센서(130)는 기압을 검출하기 위한 수단이고, 프로세서(111) 및 무선 트랜시버(121)는 UBP를 서빙 코어 네트워크(204)에 제공하기 위한 수단이다. 하나의 예에서, UBP 정보는, (E-SMLC(308)의 경우에는 MME(304) 및 eNB(302)를 통해) UE(100)와 E-SLP(332) 또는 E-SMLC(308) 사이에서 (예컨대, LPP/LPPe를 사용하여) 전달되는 LPPe 메시지에 포함될 수 있다. 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332), 및/또는 SAS(354))는 UE(100)로부터 UBP를 수신하기 위한 수단이다. 다른 예에서, UBP 정보는 (i) LPP (예컨대, LPP 메시지는 (E-SMLC(308)의 경우에는 MME(304) 및 eNB(302)를 통해) UE(100)와 E-SLP(332) 또는 E-SMLC(308) 사이에서 전달됨), (ii) LTE에 대한 RRC(예컨대, RRC 메시지가 UE(100)와 eNB(302)와 같은 서빙 eNB 사이에서 전달되고, 서빙 eNB는 그 다음, LPPa 메시지를 사용하여 UBP 정보를 E-SMLC(308)와 같은 E-SMLC에 전달함) 또는 (iii) UMTS에 대한 RRC(예컨대, RRC 메시지는 UE(100)와 RNC(356)와 같은 서빙 RNC 사이에서 전달되고, 서빙 RNC는 그 다음, PCAP 메시지를 사용하여 UBP 정보를 SAS(354)와 같은 SAS에 전달함)에 대한 메시지에 포함될 수 있다.
[0093] 스테이지(806)에서, 위치 서버(206)는 UBP를 위치 정보와 조합하도록 구성된다. E-SMLC(308), E-SLP(332), 및/또는 SAS(354)는 UBP를 위치 정보와 조합하기 위한 예시적 수단이다. 하나의 예에서, 위치 정보는 지리적 위치를 포함할 수 있으며, 3GPP TS 23.032에서 정의된 옥텟 스트링에 의해 표현될 수 있다. UBP를 3GPP 위치 정보로 조합하기 위해, 위치 서버(206)는 UBP를 전달하기 위해 위치 정보 옥텟 스트링의 (예컨대, 끝에서) 몇몇(예컨대, 2개 또는 3개의) 추가적 옥텟들을 연접시키거나 또는 그렇지 않으면 조합하도록 구성될 수 있다. UBP를 기존 위치 정보 포맷들과 조합하기 위한 다른 방법들이 또한 사용될 수 있다. 하나의 예에서, (예컨대, 3GPP TS 23.032에서 정의된 바와 같은) 표준 지리적 형상들과 연관된 파라미터들은 UBP 정보(예컨대, 위에서 설명된 바와 같은 타원체 점들, 고도 파라미터들, 및 XML 포맷들)를 수용하도록 수정될 수 있다.
[0094] 스테이지(808)에서, 위치 서버(206)는 UBP 및 위치 정보를 게이트웨이(208)에 제공하도록 구성된다. 하나의 예에서, 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332) 및/또는 SAS(354))는, 기존 인터페이스들 및 연관된 기존 프로토콜들(예컨대, 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs, Iu-ps 인터페이스들 중 하나 또는 그 초과의 것)을 활용하여 UBP 및 위치 정보를 게이트웨이(208)(예컨대, GMLC(306) 또는 LRF(330))에 제공할 수 있다. UBP 정보가 위치 정보에 임베딩되기 때문에, UBP는 중간 엔티티들을 통해 투명하게 프로세싱될 수 있다.
[0095] 스테이지(810)에서, 서빙 코어 네트워크(204) 내의 게이트웨이(208)는 위치 정보로부터 UBP를 추출하도록 구성된다. GMLC(306) 및/또는 LRF(330)는 위치 정보로부터 UBP를 추출하기 위한 예시적 수단이다. UBP를 추출하는 것은 스테이지(806)에서 설명된 바와 같은 프로세스의 반대일 수 있다. 예컨대, 게이트웨이(208)는 지리적 위치 스트링으로부터 추가적(예컨대, 2개 또는 3개의) 옥텟들을 파싱하거나, 또는 위에서 설명된 오브젝트 포맷들로부터 UBP 정보(예컨대, 타원체 점들, 고도 파라미터들, 및 XML 태그들)를 추출하도록 구성될 수 있다.
[0096] 스테이지(812)에서, 서빙 코어 네트워크(204) 내의 게이트웨이(208)는 UBP 위치를 PSAP(예컨대, 레거시 PSAP(348) 또는 i3 PSAP(344))에 제공하도록 구성된다. GMLC(306) 또는 LRF(330)는 UBP를 PSAP에 제공하기 위한 수단이다. 서빙 코어 네트워크(204) 내의 게이트웨이(208)(예컨대, GMLC(306) 또는 LRF(330))는 (예컨대, HELD, MLP 또는 J-STD-036 E2 프로토콜에 대한 새로운 파라미터를 사용하여) 위치 정보로부터 추출된 UBP를 PSAP에 제공한다. 위치 정보는 동일한 메시지로 또는 하나 또는 그 초과의 별개의 메시지들로 제공될 수 있다.
[0097] (예컨대, 도 2, 도 3a, 도 3b, 도 4, 도 6, 도 7a, 도 7b, 도 7c와 연관된 바와 같이) 이전 설명에서 위치 서버(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))에 의해 UBP가 조합될 수 있는 디스패치가능한 도시 위치의 결정을 참조할 때, NEAD(예컨대, NEAD(212))의 사용은 위치 서버에서 도시 위치 및 디스패치가능한 도시 위치를 획득하기 위한 수단으로서 설명되었다는 것이 주목되어야 한다. 그러나, 다른 실시예에서, 위치 서버(206)는 포지셔닝 관련 프로토콜, 이를테면, SUPL ULP, LPP/LPPe, UMTS에 대한 RRC, LTE에 대한 RRC 또는 PCAP를 사용하여 UE(예컨대, UE(100))로부터 직접적으로 디스패치가능한 도시 위치를 획득할 수 있다. 추가적 실시예에서, 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))는 액세스 네트워크(예컨대, 액세스 네트워크 내의 eNB(302) 또는 RNC(356))로부터 또는 WLAN으로부터(예컨대, WLAN(390) 내의 제어기 또는 액세스 포인트로부터) 디스패치가능한 도시 위치를 획득할 수 있다. 다른 실시예에서, 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))는, NEAD(212)로부터, UE(100)로부터, 또는 액세스 네트워크 또는 액세스 네트워크 내의 엘리먼트(예컨대, eNB(302), Node B(352), 또는 RNC(356)) 또는 WLAN(예컨대, WLAN(390))으로부터 디스패치가능한 도시 위치를 차례로 획득할 수 있는 다른 위치 서버로부터 UE(100)에 대한 디스패치가능한 도시 위치를 획득할 수 있다. 다른 실시예에서, 위치 서버(206)(예컨대, E-SMLC(308), E-SLP(332) 또는 SAS(354))는 (예컨대, 위치 서버에서 구성된 데이터를 사용하여) 그리고 가능하게는, UE(100)로부터, UE(100)에 대한 액세스 네트워크로부터, 또는 UE(100)로부터 신호들을 수신하는 UE(100) 인근의 AP들을 포함하는 WLAN(예컨대, WLAN(390))으로부터 수신된 UE(100)에 대한 위치 관련 정보(예컨대, 위치 관련 측정들 및/또는 위치 추정치)에 기초하여 UE(100)에 대한 디스패치가능한 도시 위치 그 자체를 결정할 수 있다. 이러한 실시예들 전부에 대해 그리고 도 2, 도 3a, 도 3b, 도 4, 도 6, 도 7a, 도 7b 및 도 7c와 연관하여 설명된 바와 같이, 위치 서버(206)는, UE(100)로부터 수신된 UBP 측정을 UE(100)에 대한 디스패치가능한 도시 위치와 조합하고, PSAP로의 제 3 자 전달(onward transfer)을 위해 또는 게이트웨이가 UBP를 추출하여 UBP를 PSAP에 개별적으로 전송하기 위해, 조합된 디스패치가능한 도시 위치 및 UBP를 게이트웨이(208)에 전달할 수 있다.
[0098] 도 1-도 8에 대한 추가적 참조와 함께, 도 9를 참조하면, 컴퓨터 시스템(900)은 도 3a 및 도 3b의 엘리먼트들의 기능을 적어도 부분적으로 구현함으로써 UBP 정보를 전송하기 위해 활용될 수 있다. 도 9는, 본원에서 설명되는 바와 같이, 다양한 다른 실시예들에 의해 제공되는(예컨대, 도 2-도 8과 연관하여 설명되는 바와 같은) 방법들을 수행할 수 있고 그리고/또는 모바일 디바이스(예컨대, UE(100)) 또는 다른 컴퓨터 시스템으로서 기능할 수 있는 컴퓨터 시스템(900)의 하나의 실시예의 개략적 예시를 제공한다. 서빙 코어 네트워크(204)는 하나 또는 그 초과의 컴퓨터 시스템들(900), 이를테면, 위치 서버(206) 및 게이트웨이(208)를 포함할 수 있다. 예컨대, eNB(302), MME(304), GMLC(306), E-SMLC(308), E-SLP(332)(SPC(334) 및 SLC(336)를 포함함), SAS(354), LRF(330) 및 도 3a 및 도 3b의 다른 엔티티들은 하나 또는 그 초과의 컴퓨터 시스템들(900)로 구성될 수 있다. 도 9는 다양한 컴포넌트들의 일반화된 예시를 제공하며, 다양한 컴포넌트들 중 임의의 컴포넌트 또는 그 전부는 적절하게 활용될 수 있다. 그러므로, 도 9는 개별 시스템 엘리먼트들이 비교적 분리된 또는 비교적 더 통합된 방식으로 어떻게 구현될 수 있는지를 광범위하게 예시한다.
[0099] 컴퓨터 시스템(900)은 버스(905)를 통해 전기적으로 커플링될 수 있는(또는 그렇지 않으면 적절하게 통신할 수 있는) 하드웨어 엘리먼트들을 포함하는 것으로 도시된다. 하드웨어 엘리먼트들은, (제한없이, 하나 또는 그 초과의 범용 프로세서들, 및/또는 하나 또는 그 초과의 특수 목적 프로세서들(이를테면, 디지털 신호 프로세싱 칩들, 그래픽 가속 프로세서들 등)을 포함하는) 하나 또는 그 초과의 프로세서들(910); (제한없이, 마우스, 키보드 등을 포함할 수 있는) 하나 또는 그 초과의 입력 디바이스들(915); 및 (제한없이, 디스플레이 디바이스, 프린터 등을 포함할 수 있는) 하나 또는 그 초과의 출력 디바이스들(920)을 포함할 수 있다. 프로세서(들)(910)는, 예컨대, 지능형 하드웨어 디바이스들, 예컨대, Intel® Corporation 또는 AMD®에 의해 제조된 것들과 같은 CPU(central processing unit), 마이크로제어기, ASIC 등을 포함할 수 있다. 다른 프로세서 타입들이 또한 활용될 수 있다.
[00100] 컴퓨터 시스템(900)은, (제한없이, 로컬 및/또는 네트워크 액세스가능한 저장소를 포함할 수 있고 그리고/또는 제한없이, 프로그래밍가능하고, 플래시-업데이트 가능한 식일 수 있는 디스크 드라이브, 드라이브 어레이, 광학 저장 디바이스, 고체-상태 저장 디바이스, 이를테면, "RAM"(random access memory) 및/또는 "ROM"(read-only memory)을 포함할 수 있는) 하나 또는 그 초과의 비-일시적 저장 디바이스들(925)을 더 포함할 수 있다(그리고/또는 이들과 통신할 수 있다). 이러한 저장 디바이스들은, 제한없이 다양한 파일 시스템들, 데이터베이스 구조들 등을 포함하는 임의의 적절한 데이터 저장소들을 구현하도록 구성될 수 있다.
[00101] 컴퓨터 시스템(900)은 또한, 제한없이, 모뎀, 네트워크 카드(무선 또는 유선), 적외선 통신 디바이스, 무선 통신 디바이스, 및/또는 칩셋(이를테면, Bluetooth™ 단거리 무선 통신 기술 트랜시버/디바이스, 802.11 디바이스, WiFi 디바이스, WiMax 디바이스, 셀룰러 통신 설비들 등) 등을 포함할 수 있는 통신 서브시스템(930) 및 네트워크 인터페이스(950)를 포함할 수 있다. 네트워크 인터페이스(950)는 데이터가 네트워크(이를테면, 하나의 예만 들자면, 본원에서 설명되는 LTE 네트워크), 다른 컴퓨터 시스템들, 및/또는 본원에서 설명되는 임의의 다른 디바이스들과 교환되게 허용할 수 있다. 많은 실시예들에서, 컴퓨터 시스템(900)은, 여기에서와 같이, 위에서 설명된 바와 같은, RAM 또는 ROM 디바이스를 포함할 수 있는 작업 메모리(935)를 더 포함할 것이다.
[00102] 컴퓨터 시스템(900)은 또한, 운영 시스템(940), 디바이스 드라이버들, 실행가능한 라이브러리들 및/또는 다른 코드, 이를테면, 본원에서 설명되는 바와 같이, 다양한 실시예들에 의해 제공되는 컴퓨터 프로그램들을 포함할 수 있고, 그리고/또는 다른 실시예들에 의해 제공되는 방법들을 구현하고 그리고/또는 시스템들을 구성하도록 설계될 수 있는 하나 또는 그 초과의 애플리케이션 프로그램들(945)을 포함하는 작업 메모리(935) 내에 현재 로케이팅되어 있는 것으로 도시되는 소프트웨어 엘리먼트들을 포함할 수 있다. 단지 예로서, 본원에서 설명되는 하나 또는 그 초과의 프로세스들은 컴퓨터(및/또는 컴퓨터 내의 프로세서)에 의해 실행가능한 코드 및/또는 명령들로 구현될 수 있다. 이러한 코드 및/또는 명령들은 설명되는 방법들에 따라 하나 또는 그 초과의 동작들을 수행하도록 범용 컴퓨터 (또는 다른 디바이스)를 구성 및/또는 적응시키기 위해 사용될 수 있다.
[00103] 이 명령들 및/또는 코드의 세트는, 컴퓨터 판독가능한 저장 매체, 이를테면, 위에서 설명된 저장 디바이스(들)(925) 상에 저장될 수 있다. 일부 경우들에서, 저장 매체는 컴퓨터 시스템, 이를테면, 컴퓨터 시스템(900) 내에 포함될 수 있다. 다른 실시예들에서, 저장 매체는 컴퓨터 시스템과 별개일 수 있고(예컨대, 탈착가능한(removable) 매체, 이를테면, 컴팩트 디스크), 그리고/또는 저장 매체가 저장 매체 상에 저장된 명령들/코드로 범용 컴퓨터를 프로그래밍하고, 구성하고 그리고/또는 적응시키기 위해 사용될 수 있도록 설치 패키지로 제공될 수 있다. 이 명령들은 컴퓨터 시스템(900)에 의해 실행가능한 실행가능 코드의 형태를 취할 수 있고 그리고/또는 소스 및/또는 설치가능한 코드의 형태를 취할 수 있으며, 이러한 소스 및/또는 설치가능한 코드는, (예컨대, 다양한 일반적으로 이용가능한 컴파일러들, 설치 프로그램들, 압축/압축해제 유틸리티들 등 중 임의의 것을 사용하여) 컴퓨터 시스템(900) 상에 컴파일(compilation) 및/또는 설치(installation)하게 되면, 실행가능한 코드의 형태를 취한다.
[00104] 특정 요건들에 따라 상당한 변형들이 이루어질 수 있다. 예컨대, 커스터마이징된 하드웨어가 또한 사용될 수 있고 그리고/또는 특정 엘리먼트들이 하드웨어, 소프트웨어(휴대용 소프트웨어, 이를테면, 애플릿들 등을 포함함) 또는 둘 다로 구현될 수 있다. 추가로, 네트워크 입력/출력 디바이스들과 같은 다른 컴퓨팅 디바이스들로의 연결이 이용될 수 있다.
[00105] 컴퓨터 시스템(900)은 본 개시물에 따라 방법들을 수행하기 위해 사용될 수 있다. 이러한 방법들의 프로시저들 중 일부 또는 그 전부는, 프로세서(910)가 작업 메모리(935)에 포함되는 하나 또는 그 초과의 명령들(운영 시스템(940) 및/또는 다른 코드, 이를테면, 애플리케이션 프로그램들(945)로 통합될 수 있음)의 하나 또는 그 초과의 시퀀스들을 실행하는 것에 대한 응답으로, 컴퓨터 시스템(900)에 의해 수행될 수 있다. 이러한 명령들은 다른 컴퓨터 판독가능한 매체, 이를테면, 저장 디바이스(들)(925) 중 하나 또는 그 초과의 저장 디바이스(들)로부터 작업 메모리(935)로 판독될 수 있다. 단지 예로서, 작업 메모리(935)에 포함되는 명령들의 시퀀스들의 실행은, 프로세서(들)(910)로 하여금 본원에서 설명되는 방법들의 하나 또는 그 초과의 프로시저들을 수행하게 할 수 있다.
[00106] 본원에서 사용되는 바와 같은 "기계 판독가능한 매체" 및 "컴퓨터 판독가능한 매체"라는 용어들은, 기계로 하여금 특정 방식으로 동작하게 하는 데이터를 제공하는데 참여하는 임의의 매체를 지칭한다. UE(100) 및/또는 컴퓨터 시스템(900)을 사용하여 구현되는 실시예에서, 다양한 컴퓨터 판독가능한 매체들이, 실행을 위한 명령들/코드를 프로세서(들)(111, 910)에 제공하는데 수반될 수 있고, 그리고/또는 (예컨대, 신호들과 같은) 이러한 명령들/코드를 저장 및/또는 전달하기 위해 사용될 수 있다. 많은 구현들에서, 컴퓨터 판독가능한 매체는 물리적 그리고/또는 유형의 저장 매체이다. 이러한 매체는 비-휘발성 매체들, 휘발성 매체들 및 송신 매체들을 포함하는(그러나, 이로 제한되는 것은 아님) 많은 형태들을 취할 수 있다. 비-휘발성 매체들은, 예컨대, 광학 그리고/또는 자기 디스크들, 이를테면, 저장 디바이스(들)(140, 925)를 포함한다. 휘발성 매체들은, 제한없이, 동적 메모리, 이를테면, 작업 메모리(140, 935)를 포함한다. 송신 매체들은, 제한없이, 버스(101, 905)뿐만 아니라 통신 서브시스템(930)의 다양한 컴포넌트들(및/또는 통신 서브시스템(930)이 다른 디바이스들과의 통신을 제공하게 하는 매체들)을 포함하는 와이어들을 포함하는 동축 케이블들, 구리 와이어 및 광섬유들을 포함한다. 따라서, 송신 매체들은 또한, (제한없이, 라디오파(radio-wave) 및 적외선 데이터 통신들 동안 생성되는 것들과 같은 라디오파, 음향파 및/또는 광파를 포함하는) 파동들의 형태를 취할 수 있다.
[00107] 물리적 그리고/또는 유형의 컴퓨터 판독가능한 매체들의 일반적 형태들은, 예컨대, 플로피 디스크, 플렉서블 디스크, 하드 디스크, 자기 테이프 또는 임의의 다른 자기 매체, CD-ROM, Blu-Ray 디스크, 임의의 다른 광학 매체, 펀치 카드(punch card)들, 페이퍼 테이프(paper tape), 홀들의 패턴들을 가지는 임의의 다른 물리적 매체, RAM, PROM, EPROM, FLASH-EPROM, 임의의 다른 메모리 칩 또는 카트리지, 이하에서 설명되는 바와 같은 반송파, 또는 컴퓨터가 명령들 및/또는 코드를 판독할 수 있는 임의의 다른 매체를 포함한다.
[00108] 다양한 형태들의 컴퓨터 판독가능한 매체들은 실행을 위한 하나 또는 그 초과의 명령들의 하나 또는 그 초과의 시퀀스들을 프로세서(들)(111, 910)에 전달하는데 수반될 수 있다. 단지 예로서, 명령들은 초기에, 원격 컴퓨터의 자기 디스크 및/또는 광학 디스크 상에서 전달될 수 있다. 원격 컴퓨터는 그것의 동적 메모리에 명령들을 로딩하고, UE(100) 및/또는 컴퓨터 시스템(900)에 의해 수신 및/또는 실행되도록 송신 매체 상에서 신호들로서 명령들을 전송할 수 있다. 전자기 신호들, 음향 신호들, 광학 신호들 등의 형태일 수 있는 이러한 신호들은 모두 다양한 실시예들에 따라, 명령들이 인코딩될 수 있는 반송파들의 예들이다.
[00109] 본 개시물에 따른 비-일시적 프로세서 판독가능한 저장 매체의 예는, 보상되지 않은 기압 정보를 PSAP에 제공하기 위한 명령들을 포함하고, 그 명령들은 사용자 장비로부터 UBP(uncompensated barometric pressure)를 획득하기 위한 코드, 사용자 장비에 대한 디스패치가능한 도시 위치를 획득하기 위한 코드, UBP를 디스패치가능한 도시 위치와 조합하기 위한 코드, 및 UBP 및 디스패치가능한 도시 위치를 PSAP에 전송하기 위한 코드를 포함한다.
[00110] 이러한 비-일시적 프로세서 판독가능한 저장 매체의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. 위치 서버에 의해 UBP 및 디스패치가능한 도시 위치를 획득하기 위한 코드. 위치 서버는 E-SMLC(Enhanced Serving Mobile Location Center), E-SLP(Emergency SUPL Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나일 수 있다. 사용자 장비로부터 UBP를 획득하기 위한 코드는 OMA LPPe(LTE Positioning Protocol Extensions) 프로토콜, 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 중 적어도 하나를 통해 UBP를 획득하도록 구성될 수 있다. 디스패치가능한 도시 위치는 PIDF-LO(Presence Information Data Format Location Object)를 포함할 수 있고, PIDF-LO는 NEAD(National Emergency Address Database)로부터 수신될 수 있다. UBP 및 디스패치가능한 도시 위치를 PSAP에 전송하기 위한 코드는 3GPP Iupc, Iu-cs, Iu-ps, SLs, SLg, Lg, Lgd, 또는 L0 인터페이스 중 적어도 하나를 통해 UBP 및 디스패치가능한 도시 위치를 게이트웨이에 제공하기 위한 코드, 및 HELD, MLP 또는 J-STD-036 E2 프로토콜 중 적어도 하나를 통해 게이트웨이로부터 PSAP로 적어도 UBP를 제공하기 위한 코드를 포함할 수 있다.
[00111] 위에서 논의된 방법들, 시스템들 및 디바이스들은 예들이다. 다양한 대안적 구성들은 다양한 프로시저들 또는 컴포넌트들을 적절하게 생략, 치환 또는 추가할 수 있다. 예컨대, 대안적 방법들에서, 단계들은 위의 논의와 상이한 순서들로 수행될 수 있고, 다양한 단계들이 추가, 생략 또는 조합될 수 있다. 또한, 특정 구성들에 대해 설명되는 특징들은 다양한 다른 구성들에서 조합될 수 있다. 구성들의 상이한 양상들 및 엘리먼트들은 유사한 방식으로 조합될 수 있다. 또한, 기술은 진화하고, 따라서, 엘리먼트들 중 다수가 예들이며, 본 개시물 또는 청구항들의 범위를 제한하지 않는다.
[00112] 본 개시물에 따라 UE(user equipment)와 PSAP 사이의 UBP(uncompensated barometric pressure)를 제공하기 위한 장치의 예는 UE에 대한 위치 정보를 결정하기 위한 수단, UE로부터 UBP를 수신하기 위한 수단, UBP를 위치 정보와 조합하기 위한 수단, UBP 및 위치 정보를 게이트웨이에 제공하기 위한 수단, 위치 정보로부터 UBP를 추출하기 위한 수단, 및 UBP를 PSAP에 제공하기 위한 수단을 포함한다.
[00113] 이러한 장치의 구현들은 다음의 특징들 중 하나 또는 그 초과의 특징들을 포함할 수 있다. UE로부터 UBP를 수신하기 위한 수단은 OMA LPPe(LTE Positioning Protocol Extensions) 프로토콜, 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 중 적어도 하나를 포함할 수 있다. UBP 및 위치 정보를 게이트웨이에 제공하기 위한 수단은 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs 또는 Iu-ps 인터페이스 중 적어도 하나를 포함할 수 있다. UE에 대한 위치 정보를 결정하기 위한 수단은 SPS 수신기를 포함할 수 있다. UBP를 PSAP에 제공하기 위한 수단은 HELD, MLP 또는 J-STD-036 E2 프로토콜 중 적어도 하나를 포함한다. UBP를 위치 정보와 조합하기 위한 수단은 UBP를 표현하는 몇몇(예컨대, 2개 또는 3개의) 추가적 옥텟들의 데이터 필드와 지리적 위치 스트링을 연접시키는 것을 포함할 수 있다.
[00114] 특정 세부사항들이 예시적 구성들(구현들을 포함함)의 완전한 이해를 제공하기 위해 설명에 주어진다. 그러나, 구성들은 이러한 특정 세부사항들 없이도 실시될 수 있다. 예컨대, 잘-알려져 있는 회로들, 프로세스들, 알고리즘들, 구조들 및 기법들은 구성들을 모호하게 하는 것을 회피하기 위해 불필요한 세부사항 없이 나타내었다. 이러한 설명은 단지 예시적 구성들만을 제공하며, 청구항들의 범위, 적용가능성 또는 구성을 제한하지 않는다. 오히려, 구성들의 위의 설명은 설명되는 기법들을 구현하기 위한 가능한 설명을 당업자들에게 제공할 것이다. 본 개시물의 사상 또는 범위로부터 이탈하지 않으면서 엘리먼트들의 기능 및 어레인지먼트(arrangement)에서 다양한 변화들이 이루어질 수 있다.
[00115] 흐름 다이어그램 또는 블록 다이어그램으로서 도시되는 프로세스로서 구성들이 설명될 수 있다. 각각은 순차적 프로세스로서 동작들을 설명할 수 있지만, 동작들 중 다수는 병렬로 또는 동시에 수행될 수 있다. 또한, 동작들의 순서가 재배열될 수 있다. 프로세스는 도면에 포함되지 않는 추가적 단계들을 가질 수 있다. 게다가, 방법들의 예들은 하드웨어, 소프트웨어, 펌웨어, 미들웨어, 마이크로코드, 하드웨어 설명 언어들 또는 이들의 임의의 조합에 의해 구현될 수 있다. 소프트웨어, 펌웨어, 미들웨어 또는 마이크로코드로 구현되는 경우, 필요한 태스크들을 수행하기 위한 프로그램 코드 또는 코드 세그먼트들은 저장 매체와 같은 비-일시적 컴퓨터 판독가능한 매체에 저장될 수 있다. 프로세서들은 설명되는 태스크들을 수행할 수 있다.
[00116] 청구항들을 포함하는 본원에서 사용되는 바와 같이, "~ 중 적어도 하나"로 서문이 쓰여진 아이템들의 리스트에서 사용되는 바와 같은 "또는"은 예컨대, "A, B, 또는 C 중 적어도 하나"의 리스트가 A 또는 B 또는 C 또는 AB 또는 AC 또는 BC 또는 ABC(즉, A 및 B 및 C) 또는 하나 초과의 피처와의 조합들(예컨대, AA, AAB, ABBC 등)을 의미하도록 택일적 리스트를 표시한다. 본원에서 사용되는 바와 같이, A, B 및/또는 C와 같은 아이템들의 리스트에서 사용되는 "및/또는"이라는 용어는 A 또는 B 또는 C 또는 이들의 조합들과 동등하다.
[00117] 청구항들을 포함하는 본원에서 사용되는 바와 같이, 달리 서술되지 않으면, 기능 또는 동작이 아이템 또는 조건"에 기초한다"는 서술문은 기능 또는 동작이 서술된 아이템 또는 조건에 기초하고, 서술된 아이템 또는 조건에 추가하여 하나 또는 그 초과의 아이템들 및/또는 조건들에 기초할 수 있다는 것을 의미한다.
[00118] 몇몇 예시적 구성들을 설명하였지만, 다양한 수정들, 대안적 구조들 및 등가물들이 본 개시물의 사상으로부터 이탈하지 않으면서 사용될 수 있다. 예컨대, 위의 엘리먼트들은 더 큰 시스템의 컴포넌트들일 수 있고, 여기서 다른 규정들은 다양한 실시예들의 애플리케이션보다 우선권을 얻거나, 또는 그렇지 않으면 다양한 실시예들의 애플리케이션을 수정할 수 있다. 또한, 다수의 단계들이 위의 엘리먼트들이 고려되기 이전에, 그 동안 또는 그 이후에 착수될 수 있다. 따라서, 위의 설명은 본 청구항들의 범위를 제한하지 않는다.

Claims (24)

  1. 보상되지 않은 기압 정보를 PSAP(Public Safety Answering Point)에 제공하기 위한 방법으로서,
    사용자 장비에 대한 디스패치가능한 도시 위치(dispatchable civic location)를 획득하는 단계 ― 상기 디스패치가능한 도시 위치는 PIDF-LO(Presence Information Data Format Location Object)를 포함하고, 그리고 상기 PIDF-LO를 획득하는 것은 도시 위치들의 데이터베이스에 질의하는 것을 포함함 ―;
    상기 사용자 장비로부터 UBP(uncompensated barometric pressure)를 획득하는 단계;
    상기 UBP를 포함하는 디스패치가능한 도시 위치 기록을 생성하기 위해 상기 UBP를 상기 디스패치가능한 도시 위치와 조합하는 단계 ― 상기 UBP를 상기 디스패치가능한 도시 위치와 조합하는 것은, 상기 UBP를 표현하기 위해 상기 PIDF-LO의 일부인 도시 주소 타입을 사용하는 것을 포함함 ―;
    상기 UBP를 포함하는 상기 디스패치가능한 도시 위치 기록을 게이트웨이에 제공하는 단계; 및
    적어도 상기 UBP를 상기 게이트웨이로부터 상기 PSAP에 제공하는 단계를 포함하는, 보상되지 않은 기압 정보를 PSAP에 제공하기 위한 방법.
  2. 제 1 항에 있어서,
    상기 UBP 및 상기 디스패치가능한 도시 위치는 위치 서버에 의해 획득되는, 보상되지 않은 기압 정보를 PSAP에 제공하기 위한 방법.
  3. 제 2 항에 있어서,
    상기 위치 서버는, E-SMLC(Enhanced Serving Mobile Location Center), E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나인, 보상되지 않은 기압 정보를 PSAP에 제공하기 위한 방법.
  4. 제 3 항에 있어서,
    상기 UBP는, OMA LPPe(LTE Positioning Protocol Extensions) 프로토콜, 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 또는 이들의 조합을 통해 상기 사용자 장비로부터 획득되는, 보상되지 않은 기압 정보를 PSAP에 제공하기 위한 방법.
  5. 제 1 항에 있어서,
    상기 PIDF-LO는 NEAD(National Emergency Address Database)로부터 획득되는, 보상되지 않은 기압 정보를 PSAP에 제공하기 위한 방법.
  6. 제 1 항에 있어서,
    상기 UBP를 포함하는 상기 디스패치가능한 도시 위치 기록을 상기 게이트웨이에 제공하는 것은, 3GPP Iupc, Iu-cs, Iu-ps, SLs, SLg, Lg, Lgd, 또는 L0 인터페이스 또는 이들의 조합을 사용하는 것을 포함하고; 그리고
    적어도 상기 UBP를 상기 게이트웨이로부터 상기 PSAP에 제공하는 것은, HELD(HTTP Enabled Location Delivery) 프로토콜, OMA MLP(Mobile Location Protocol) 또는 TIA/ATIS J-STD-036 E2 프로토콜 또는 이들의 조합을 사용하는 것을 포함하는, 보상되지 않은 기압 정보를 PSAP에 제공하기 위한 방법.
  7. 삭제
  8. 사용자 장비(UE)와 PSAP(Public Safety Answering Point) 사이의 보상되지 않은 기압을 제공하기 위한 게이트웨이로서,
    디스패치가능한 도시 위치와 조합된 UBP(uncompensated barometric pressure)를 포함하는 디스패치가능한 도시 위치 기록을 수신하도록 구성된 네트워크 인터페이스 ― 상기 디스패치가능한 도시 위치는 도시 위치들의 데이터베이스로부터 획득되는 PIDF-LO(Presence Information Data Format Location Object)를 포함하고, 그리고 상기 UBP를 상기 디스패치가능한 도시 위치와 조합하는 것은, 상기 UBP를 표현하기 위해 상기 PIDF-LO의 일부인 도시 주소 타입을 사용하는 것을 포함함 ―; 및
    상기 디스패치가능한 도시 위치 기록으로부터 상기 UBP를 추출하도록 구성된 프로세서 및 메모리를 포함하고,
    상기 네트워크 인터페이스는 상기 UBP를 상기 PSAP에 제공하도록 추가로 구성되는, UE와 PSAP 사이의 보상되지 않은 기압을 제공하기 위한 게이트웨이.
  9. 제 8 항에 있어서,
    상기 네트워크 인터페이스는 HELD(HTTP Enabled Location Delivery) 프로토콜, OMA MLP(Mobile Location Protocol) 또는 TIA/ATIS J-STD-036 E2 프로토콜 또는 이들의 조합을 통해 상기 UBP를 상기 PSAP에 제공하도록 구성되는, UE와 PSAP 사이의 보상되지 않은 기압을 제공하기 위한 게이트웨이.
  10. 제 8 항에 있어서,
    상기 네트워크 인터페이스는 상기 디스패치가능한 도시 위치 기록을 상기 PSAP에 제공하도록 추가로 구성되는, UE와 PSAP 사이의 보상되지 않은 기압을 제공하기 위한 게이트웨이.
  11. 사용자 장비(UE)에 대한 보상되지 않은 기압을 게이트웨이에 제공하기 위한 위치 서버로서,
    네트워크 인터페이스 ― 상기 네트워크 인터페이스는:
    상기 UE로부터 UBP(uncompensated barometric pressure)를 획득하고;
    상기 UE에 대한 디스패치가능한 도시 위치를 획득하도록 구성되고,
    상기 디스패치가능한 도시 위치는 PIDF-LO(Presence Information Data Format Location Object)를 포함하고, 그리고 상기 네트워크 인터페이스는 도시 위치들의 데이터베이스에 질의함으로써 상기 PIDF-LO를 획득하도록 구성됨 ―; 및
    상기 UBP를 포함하는 디스패치가능한 도시 위치 기록을 생성하기 위해 상기 UBP를 상기 디스패치가능한 도시 위치와 조합하도록 구성된 프로세서 및 메모리를 포함하고,
    상기 UBP를 상기 디스패치가능한 도시 위치와 조합하는 것은, 상기 UBP를 표현하기 위해 상기 PIDF-LO의 일부인 도시 주소 타입을 사용하는 것을 포함하고; 그리고
    상기 네트워크 인터페이스는 상기 UBP를 포함하는 상기 디스패치가능한 도시 위치 기록을 상기 게이트웨이에 제공하도록 추가로 구성되는, UE에 대한 보상되지 않은 기압을 게이트웨이에 제공하기 위한 위치 서버.
  12. 제 11 항에 있어서,
    E-SMLC(Enhanced Serving Mobile Location Center), E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나를 포함하는, UE에 대한 보상되지 않은 기압을 게이트웨이에 제공하기 위한 위치 서버.
  13. 제 11 항에 있어서,
    상기 네트워크 인터페이스는 상기 UBP를 포함하는 상기 디스패치가능한 도시 위치 기록을 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs 또는 Iu-ps 인터페이스 또는 이들의 조합을 통해 상기 게이트웨이에 제공하도록 구성되는, UE에 대한 보상되지 않은 기압을 게이트웨이에 제공하기 위한 위치 서버.
  14. 제 11 항에 있어서,
    상기 UBP는, OMA LPPe(LTE Positioning Protocol Extensions) 프로토콜, 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜, 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 또는 이들의 조합을 통해 상기 UE로부터 획득되는, UE에 대한 보상되지 않은 기압을 게이트웨이에 제공하기 위한 위치 서버.
  15. LTE(Long Term Evolution) 아키텍처 또는 UMTS(Universal Mobile Telecommunication System) 아키텍처에서 사용자 장비(UE)로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법으로서,
    상기 UE로부터 UBP(uncompensated barometric pressure) 및 위치 정보를 획득하는 단계;
    상기 위치 정보에 기초하여 상기 UE에 대한 디스패치가능한 도시 위치를 획득하는 단계 ― 상기 디스패치가능한 도시 위치는 PIDF-LO(Presence Information Data Format Location Object)를 포함하고, 그리고 상기 PIDF-LO를 획득하는 것은 도시 위치들의 데이터베이스에 질의하는 것을 포함함 ―;
    상기 UBP를 포함하는 디스패치가능한 도시 위치 기록을 생성하기 위해 상기 UBP를 상기 디스패치가능한 도시 위치와 조합하는 단계 ― 상기 UBP를 상기 디스패치가능한 도시 위치와 조합하는 것은, 상기 UBP를 표현하기 위해 상기 PIDF-LO의 일부인 도시 주소 타입을 사용하는 것을 포함함 ―; 및
    상기 UBP를 포함하는 상기 디스패치가능한 도시 위치 기록을 상기 게이트웨이에 제공하는 단계를 포함하는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  16. 제 15 항에 있어서,
    상기 UBP 및 상기 디스패치가능한 도시 위치는, E-SMLC(Enhanced Serving Mobile Location Center), E-SLP(Emergency SUPL(Secure User Plane Location) Location Platform), 또는 SAS(Standalone Serving Mobile Location Center) 중 하나에서 획득되는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  17. 제 15 항에 있어서,
    상기 UBP를 포함하는 상기 디스패치가능한 도시 위치 기록을 상기 게이트웨이에 제공하는 단계는:
    상기 UBP를 포함하는 상기 디스패치가능한 도시 위치 기록을 3GPP SLs, SLg, L0, Lg, Lgd, Iupc, Iu-cs 또는 Iu-ps 인터페이스 또는 이들의 조합을 통해 제공하는 단계를 포함하는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  18. 제 15 항에 있어서,
    상기 디스패치가능한 도시 위치를 획득하는 단계는 엠티 도시 위치 기록을 생성하는 단계를 포함하는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  19. 제 18 항에 있어서,
    상기 엠티 도시 위치 기록과 상기 UBP를 조합하는 단계; 및
    상기 UBP를 포함하는 상기 엠티 도시 위치 기록을 상기 게이트웨이에 제공하는 단계를 더 포함하는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  20. 제 15 항에 있어서,
    상기 UBP 및 상기 위치 정보는, OMA LPPe(LTE Positioning Protocol Extensions) 프로토콜, 3GPP LPP(LTE Positioning Protocol), LTE에 대한 3GPP RRC(Radio Resource Control) 프로토콜, UMTS에 대한 3GPP RRC 프로토콜, 3GPP LPPa(LTE Positioning Protocol A) 프로토콜 또는 3GPP PCAP(Positioning Calculation Application Part) 프로토콜 또는 이들의 조합을 통해 상기 UE로부터 획득되는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  21. 제 15 항에 있어서,
    상기 게이트웨이는,
    상기 UBP를 포함하는 상기 디스패치가능한 도시 위치 기록을 수신하고,
    상기 디스패치가능한 도시 위치 기록으로부터 상기 UBP를 추출하고, 그리고
    상기 UBP를 PSAP(Public Safety Answering Point)에 제공하는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  22. 제 21 항에 있어서,
    상기 게이트웨이는 HELD(HTTP Enabled Location Delivery) 프로토콜, OMA MLP(Mobile Location Protocol) 또는 TIA/ATIS J-STD-036 E2 프로토콜 또는 이들의 조합을 통해 상기 UBP를 상기 PSAP에 제공하는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  23. 제 21 항에 있어서,
    상기 게이트웨이는 상기 디스패치가능한 도시 위치 기록을 상기 PSAP에 제공하는, LTE 아키텍처 또는 UMTS 아키텍처에서 UE로부터 게이트웨이에 보상되지 않은 기압을 제공하기 위한 방법.
  24. 삭제
KR1020177031779A 2015-05-04 2016-04-04 보상되지 않은 기압 정보의 전달 KR102532718B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562156845P 2015-05-04 2015-05-04
US62/156,845 2015-05-04
US14/860,452 US10051684B2 (en) 2015-05-04 2015-09-21 Transfer of uncompensated barometric pressure information
US14/860,452 2015-09-21
PCT/US2016/025814 WO2016178762A1 (en) 2015-05-04 2016-04-04 Transfer of uncompensated barometric pressure information

Publications (2)

Publication Number Publication Date
KR20180002649A KR20180002649A (ko) 2018-01-08
KR102532718B1 true KR102532718B1 (ko) 2023-05-12

Family

ID=55809191

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177031779A KR102532718B1 (ko) 2015-05-04 2016-04-04 보상되지 않은 기압 정보의 전달

Country Status (6)

Country Link
US (1) US10051684B2 (ko)
EP (1) EP3292704B1 (ko)
JP (1) JP6736582B2 (ko)
KR (1) KR102532718B1 (ko)
CN (1) CN108476375B (ko)
WO (1) WO2016178762A1 (ko)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9838858B2 (en) 2014-07-08 2017-12-05 Rapidsos, Inc. System and method for call management
WO2017079354A1 (en) 2015-11-02 2017-05-11 Rapidsos, Inc. Method and system for situational awareness for emergency response
CN108702409A (zh) 2015-12-17 2018-10-23 快速求救公司 用于有效紧急呼叫的设备和方法
US20170180966A1 (en) * 2015-12-17 2017-06-22 Rave Wireless, Inc. Notification of emergencies based on wireless signal recognition
US9986404B2 (en) 2016-02-26 2018-05-29 Rapidsos, Inc. Systems and methods for emergency communications amongst groups of devices based on shared data
JP6919978B2 (ja) 2016-04-26 2021-08-18 ラピッドエスオーエス,インク. 緊急通信用のシステムおよび方法
MX2018013813A (es) * 2016-05-09 2019-09-10 Rapidsos Inc Sistemas y metodos para comunicaciones de emergencia.
US9661127B1 (en) * 2016-08-02 2017-05-23 Sanjeev Kumar Singh Locking-out a driver handheld mobile device during driving of a vehicle for texting and browsing
US10861320B2 (en) 2016-08-22 2020-12-08 Rapidsos, Inc. Predictive analytics for emergency detection and response management
EP3651433A1 (en) 2016-08-26 2020-05-13 Intrinsic Value, LLC Systems, devices, and methods for emergency responses and safety
US10506413B2 (en) 2017-08-28 2019-12-10 Intrinsic Value, Llc Systems, devices, and methods for emergency responses and safety
US11259165B2 (en) 2016-08-26 2022-02-22 Intrinsic Value, Llc Systems, devices, and methods for emergency responses and safety
US9992761B2 (en) * 2016-09-16 2018-06-05 Nextnav, Llc Systems and methods for transmitting information used to estimate a position of a mobile device
US20180206182A1 (en) 2017-01-18 2018-07-19 Corning Optical Communications Wireless Ltd Location access units (laus) in a wireless communications system (wcs) for transmitting information to a wireless client device in the wcs for determining location of the client device, and related systems and methods
US10187756B1 (en) 2017-10-19 2019-01-22 3305978 Nova Scotia Limited Emergency location informer system
EP3721402A4 (en) 2017-12-05 2021-08-04 Rapidsos Inc. EMERGENCY MANAGEMENT SOCIAL MEDIA CONTENT
US10820181B2 (en) 2018-02-09 2020-10-27 Rapidsos, Inc. Emergency location analysis system
US10805786B2 (en) 2018-06-11 2020-10-13 Rapidsos, Inc. Systems and user interfaces for emergency data integration
US11917514B2 (en) 2018-08-14 2024-02-27 Rapidsos, Inc. Systems and methods for intelligently managing multimedia for emergency response
US10977927B2 (en) 2018-10-24 2021-04-13 Rapidsos, Inc. Emergency communication flow management and notification system
US11218584B2 (en) 2019-02-22 2022-01-04 Rapidsos, Inc. Systems and methods for automated emergency response
CA3135274C (en) 2019-03-29 2024-01-16 Rapidsos, Inc. Systems and methods for emergency data integration
US11146680B2 (en) 2019-03-29 2021-10-12 Rapidsos, Inc. Systems and methods for emergency data integration
US11228891B2 (en) 2019-07-03 2022-01-18 Rapidsos, Inc. Systems and methods for emergency medical communications
US11109214B1 (en) * 2020-08-31 2021-08-31 Motorola Solutions, Inc. Device, system and method for serving interfaces to client access devices based on assigned roles
US11330664B1 (en) 2020-12-31 2022-05-10 Rapidsos, Inc. Apparatus and method for obtaining emergency data and providing a map view

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8442481B2 (en) * 2006-05-16 2013-05-14 RedSky Technologies, Inc. Emergency location information gateway for public safety answering points (PSAPs) and method of use
WO2008069712A1 (en) 2006-12-04 2008-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for enhanced cell identification and cell positioning
US8254877B2 (en) 2008-01-04 2012-08-28 Qualcomm Incorporated Method and apparatus for extended call establishment for IMS emergency calls
US9693184B2 (en) 2008-08-18 2017-06-27 Qualcomm Incorporated Control plane location solution to support wireless access
US8990043B1 (en) 2011-03-01 2015-03-24 Cellco Partnership Determining building floor level of wireless mobile communication device
WO2013025555A1 (en) 2011-08-12 2013-02-21 Qualcomm Incorporated Emergency messaging between citizens and authorities
US8787944B2 (en) * 2011-08-18 2014-07-22 Rivada Research, Llc Method and system for providing enhanced location based information for wireless handsets
US8831556B2 (en) * 2011-09-30 2014-09-09 Telecommunication Systems, Inc. Unique global identifier header for minimizing prank emergency 911 calls
WO2013184701A1 (en) 2012-06-05 2013-12-12 Arun Raghupathy Systems and methods for location positioning of user device
US20140162693A1 (en) 2012-06-15 2014-06-12 Qualcomm Incorporated Methods and systems for providing location based services in a venue
US9439041B2 (en) * 2012-06-29 2016-09-06 Lighthouse Signal Systems, Llc Systems and methods for calibration based indoor geolocation
US9417313B2 (en) * 2012-07-18 2016-08-16 Unify Gmbh & Co Kg Method of conveying a location information representing a physical location of a communication device, a computer program product for executing the method, and the communication device for conveying the location information
US9161196B2 (en) * 2012-08-07 2015-10-13 Google Technology Holdings LLC Apparatus and method for secure private location information transfer
US9078102B2 (en) 2012-11-12 2015-07-07 Qualcomm Incorporated Techniques for generating environment and reference data reports for particular environments on behalf of mobile devices
US9612114B2 (en) 2013-01-13 2017-04-04 Qualcomm Incorporated Access network node based barometric reference pressure network
CN103208165A (zh) * 2013-03-29 2013-07-17 龚南彬 一种安全防护装置和系统
US9998872B2 (en) * 2014-02-12 2018-06-12 Qualcomm Incorporated Methods and systems for returning an early positioning fix
WO2016025895A1 (en) * 2014-08-15 2016-02-18 Qualcomm Incorporated Mobile-assisted determination of the altitude of a mobile device
CN104318763B (zh) * 2014-10-21 2016-07-13 南京感动科技有限公司 多功能感知交通平台系统及其方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
3GPP R1-151335*
Detailed Functional and Interface Standards for the NENA i3 Solution, NENA 08-003 v1, June 14, 2011*
Wireless E911 Location Accuracy Requirements(Released: February 3, 2015)*

Also Published As

Publication number Publication date
CN108476375A (zh) 2018-08-31
JP2018519712A (ja) 2018-07-19
KR20180002649A (ko) 2018-01-08
US10051684B2 (en) 2018-08-14
US20160330769A1 (en) 2016-11-10
WO2016178762A1 (en) 2016-11-10
CN108476375B (zh) 2022-03-01
EP3292704A1 (en) 2018-03-14
EP3292704B1 (en) 2021-05-19
JP6736582B2 (ja) 2020-08-05

Similar Documents

Publication Publication Date Title
KR102532718B1 (ko) 보상되지 않은 기압 정보의 전달
US10285016B2 (en) Methods and systems for returning an early positioning fix
US9733337B2 (en) Support of downlink positioning using coherent and non-coherent signal acquisition
JP2018522226A (ja) 不明確セルを使用するotdoa測位のサポート
US11812301B2 (en) Methods and systems for segmentation of positioning protocol messages
US20200252781A1 (en) Systems and methods for supporting location based routing of emergency services calls
KR20160003156A (ko) 액세스 포인트들 및 펨토셀들의 로케이션들을 난독처리
US20170134128A1 (en) Support of otdoa positioning using mixed transmission port antenna configurations
KR20230159415A (ko) 포지셔닝 측정 보고 압축
CN115885527A (zh) 使用用于4G和5G的城市位置的增强WiFi定位的方法和装置
KR20230172467A (ko) 감소된 시그널링 오버헤드를 위한 포지셔닝 보조 데이터 전달

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant