KR20170091598A - Ott(over-the-top) 긴급 호에 대한 레퍼런스에 의한 로케이션 - Google Patents

Ott(over-the-top) 긴급 호에 대한 레퍼런스에 의한 로케이션 Download PDF

Info

Publication number
KR20170091598A
KR20170091598A KR1020177013693A KR20177013693A KR20170091598A KR 20170091598 A KR20170091598 A KR 20170091598A KR 1020177013693 A KR1020177013693 A KR 1020177013693A KR 20177013693 A KR20177013693 A KR 20177013693A KR 20170091598 A KR20170091598 A KR 20170091598A
Authority
KR
South Korea
Prior art keywords
location
ott
request
access network
network node
Prior art date
Application number
KR1020177013693A
Other languages
English (en)
Other versions
KR102409866B1 (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 KR20170091598A publication Critical patent/KR20170091598A/ko
Application granted granted Critical
Publication of KR102409866B1 publication Critical patent/KR102409866B1/ko

Links

Images

Classifications

    • H04W4/22
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4588Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • 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
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/53Network services using third party service providers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • 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/023Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • 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
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/02Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration by periodical registration
    • H04W76/007
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/50Connection management for emergency connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/12Reselecting a serving backbone network switching or routing node
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/18Selecting a network or a communication service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/04Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Emergency Management (AREA)
  • Public Health (AREA)
  • Environmental & Geological Engineering (AREA)
  • Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

OTT(over-the-top) SP(service provider)에 대한 로케이션 및 긴급 호들을 위한 지원을 제공하기 위한 방법들 및 장치들이 개시된다. 액세스 네트워크 노드는 UE로부터 제 1 메시지를 수신하고, UE에 대한 로케이션 레퍼런스를 결정하며, 그리고 로케이션 레퍼런스를 포함하는 제 2 메시지를 UE에 전송한다. 액세스 네트워크 노드는 로케이션 서버를 대신하여 로케이션 레퍼런스 자체를 결정할 수 있거나, 또는 로케이션 레퍼런스를 할당 및 리턴하도록 로케이션 서버에 요청할 수 있다. 액세스 네트워크 노드는 프록시로서 기능하고, 그리고 UE와 로케이션 서버 간의 상호작용을 회피할 수 있다. 로케이션 서버는 나중에 네트워크 엔티티로부터 UE에 대한 로케이션 요청을 수신할 수 있고, 여기서 로케이션 요청은 로케이션 레퍼런스를 포함한다. 로케이션 서버는 로케이션 레퍼런스를 사용하여 UE를 로케이팅하고, 그리고 UE 로케이션를 네트워크 엔티티에 리턴할 수 있다.

Description

OTT(OVER-THE-TOP) 긴급 호에 대한 레퍼런스에 의한 로케이션{LOCATION BY REFERENCE FOR AN OVER-THE-TOP EMERGENCY CALL}
[0001] 본 특허 출원은 "LOCATION BY REFERENCE FOR AN OVER-THE-TOP EMERGENCY CALL"란 명칭으로 2014년 11월 24일에 출원된 미국 가출원 번호 제 62/083,768호 및 "LOCATION TRANSFER ALTERNATIVES TO AN OVER-THE-TOP SERVICE PROVIDER"란 명칭으로 2015년 1월 9일에 출원된 미국 가출원 번호 제 62/101,974호를 우선권으로 주장하며, 이 출원들은 본 발명의 양수인에게 양도되었고 그 전체가 인용에 의해 본원에 명백하게 통합된다.
[0002] 개시내용의 실시예들은 OTT(over-the-top) 긴급 호에 대한 레퍼런스(reference)에 의한 로케이션(location)을 제공하는 것에 관한 것이다.
[0003] 무선 통신 시스템들은 1세대(1G) 아날로그 무선 폰 서비스, 2세대(2G) 디지털 무선 폰 서비스(과도 2.5G 네트워크들을 포함함), 및 3세대(3G) 및 4세대(4G) 고속 데이터/인터넷-가능 무선 서비스들을 포함하는 다양한 세대들을 거쳐 개발되어 왔다.
[0004] 4G 진화의 부분으로서, 모바일 폰들 및 다른 데이터 단말들에 대한 고속 데이터 무선 통신을 위한 라디오 액세스 네트워크 기술로서 LTE(Long Term Evolution)가 3GPP(3rd Generation Partnership Project)에 의해 개발되어 왔다. LTE는 GSM(Global System for Mobile Communications) 및 GSM의 파생물들, 이를테면 EDGE(Enhanced Data rates for GSM Evolution), UMTS(Universal Mobile Telecommunications System), 및 HSPA(High-Speed Packet Access)로부터 진화되어 왔다.
[0005] 북미에서는 공중 네트워크 오퍼레이터(public network operator)들에 의해 사용되는, GSM, UMTS 및 LTE를 지원하는 것들과 같은 무선 통신 시스템들이 적절한 공중 자원들과 긴급 호출자들을 링크시키는 강화된 911, 즉 E911을 위한 솔루션을 사용한다. 솔루션은 호출자, 즉 호출자의 사용자 장비(UE)와 특정 로케이션, 이를테면 물리적 어드레스 또는 지리적 좌표들을 자동적으로 연관시키는 것을 시도한다. 호출자를 높은 정확도로 (예컨대, 50 미터 미만의 거리 에러로) 자동적으로 로케이팅하고 그 로케이션을 PSAP(Public Safety Answering Point)에 제공하면, 긴급상황들 동안, 특히 호출자가 자신의 로케이션을 통신할 수 없을 수 있거나 또는 자신의 로케이션을 알지 못하는 경우에 공중 안전측이 응답할 수 있는 속도를 증가시킬 수 있다. 부가적으로, 긴급 호출자(예컨대, 호출자의 디바이스가 액세스 중인 특정 네트워크 셀)의 대략의 로케이션을 아는 것은 호출자의 로케이션에 대한 정확한 PSAP에 긴급 호를 라우팅하는데 필요할 수 있다.
[0006] OTT(Over The Top) SP(service provider)들로 알려진 소정의 다른 제공자들은 또한, 반드시 공중 무선 네트워크를 소유하거나 또는 동작시킬 필요없이 또는 MVNO(Mobile Virtual Network Operator)로서 작용할 필요없이 무선 디바이스들의 사용자들에게 음성 및 데이터 관련 서비스들을 제공할 수 있다. 이후, 무선 디바이스를 가진 사용자는 일부 다른 무선 네트워크 SP, 예컨대 UMTS 또는 LTE 네트워크를 가진 SP를 통해 그리고 가능한 경우에 인터넷을 통해서도 OTT SP 자원들(예컨대, 하나 또는 그 초과의 서버들)에 액세스할 수 있다. 액세스는 통상적으로 (홈 무선 네트워크 또는 MVNO에 대한 액세스와 다르게) 서빙 무선 네트워크 SP에게 투명(transparent)하고 통상적으로 네트워크 및 IP 프로토콜 레벨들 위에서 발생할 수 있는데, 이는 OTT(Over The Top)란 명칭을 초래한다. 이 경우에, OTT SP는 음성 및 데이터 호들(또는 세션들)을 수행할 능력을 사용자에게 제공할 수 있으며, 일부 경우들에서는 긴급 호를 수행할 능력을 사용자에게 제공할 수 있다.
[0007] 그러나, 이후, OTT SP는 로케이션 관련 정보에 대한 제약된 액세스와 로케이션 가능 자원들의 결핍으로 인해 긴급 호출자에 대한 정확하고 신뢰적인 로케이션을 획득하는데 있어서 공중 무선 네트워크 오퍼레이터에 비해 더 곤란할 수 있다. 예컨대, 서빙 무선 네트워크는 무선 호출자에 대한 셀 관련 정보(예컨대, 무선 호출자에 대한 서빙 셀 ID)에 대해 액세스할 수 있고 무선 호출자에 대한 정확한 로케이션을 획득하기 위하여 사용될 수 있는 네트워크 인프라구조(예컨대, 무선 호출자의 디바이스로부터의 신호들을 측정할 수 있거나 또는 이러한 측정들을 로케이션 추정으로 변환시키기 위하여 무선 호출자의 디바이스 및 로케이션 서버에 의해 신호들이 측정될 수 있는 기지국들)를 가질 수 있는 반면에, OTT SP는 이러한 인프라구조 또는 정보를 거의 갖지 않거나 또는 이러한 인프라구조 또는 정보를 갖지 못할 수 있다. 이는 OTT SP가 긴급 호를 무선 호출자로부터 정확한 PSAP로 라우팅하지 못하게 하고 그리고/또는 무선 호출자의 정확한 로케이션을 PSAP에 제공하지 못하게 할 수 있는데, 이는 OTT SP가 신뢰적인 긴급 서비스들을 제공하지 못하게 할 수 있다. 따라서, OTT SP를 통해 수행되는 긴급 호들에 대한 로케이션의 지원을 개선하면 이익들을 얻을 수 있다.
[0008] 하기는 OTT(Over The Top) 긴급 호에 대한 레퍼런스에 의해 로케이션을 제공하기 위하여 본원에서 개시된 메커니즘들과 연관된 하나 또는 그 초과의 양상들 및/또는 실시예들에 관한 간략화된 요약을 제시한다. 따라서, 하기의 요약은 모든 고찰된 양상들 및/또는 실시예들에 관한 광범위한 개요인 것으로 고려되지 않아야 하며, 또한 하기의 요약은 모든 고찰된 양상들 및/또는 실시예들에 관한 핵심적인 또는 중요한 엘리먼트들을 식별하거나 임의의 특정 양상 및/또는 실시예와 연관된 범위를 열거하는 것으로 간주되지 않아야 한다. 따라서, 하기의 요약은 이하에서 제시된 상세한 설명에 앞서 간략화된 형태로, 본원에 개시된 메커니즘들에 관한 하나 또는 그 초과의 양상들 및/또는 실시예들에 관한 소정의 개념들을 제시하는데 그 유일한 목적을 가진다.
[0009] OTT SP(service provider)에게 로케이션 및 긴급 호들에 대한 지원을 제공하기 위한 방법들 및 장치들이 개시된다. UE(user equipment)를 서빙하는 액세스 네트워크 노드에 의해서 수행되는, UE를 로케이팅(locating)하는 방법은 액세스 네트워크 노드가 UE로부터 제 1 메시지를 수신하는 단계, UE에 대한 로케이션 레퍼런스(location reference)를 결정하는 단계 ― 로케이션 레퍼런스는 액세스 네트워크 노드에 대한 오퍼레이터(operator)에 속하는 로케이션 서버에 대한 것이고, 그리고 로케이션 레퍼런스는 UE가 로케이팅되게 할 수 있음 ―, 및 UE에 제 2 메시지를 전송하는 단계를 포함하고, 제 2 메시지는 로케이션 레퍼런스를 포함한다.
[0010] 로케이션 서버에서 수행되는, UE를 로케이팅하는 방법은 UE를 서빙하는 액세스 네트워크 노드로부터 UE에 대한 로케이션 레퍼런스에 대한 요청을 수신하는 단계, 액세스 네트워크 노드에 UE에 대한 로케이션 레퍼런스를 전송하는 단계, 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신하는 단계 ― 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함함 ―, UE에 대한 로케이션 추정을 결정하는 단계, 및 네트워크 엔티티에 UE에 대한 로케이션 추정을 전송하는 단계를 포함한다.
[0011] 로케이션 서버에서 수행되는, UE를 로케이팅하는 방법은 UE를 서빙하는 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신하는 단계 ― 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함하고, 로케이션 레퍼런스는 UE에 대한 UE 레퍼런스를 포함함 ―, UE에 대한 로케이션 레퍼런스를 인증하는 단계, UE에 대한 로케이션 레퍼런스의 UE 레퍼런스에 기반하여 UE에 대한 로케이션 추정을 결정하는 단계 및 다른 네트워크 엔티티에 UE에 대한 로케이션 추정을 전송하는 단계를 포함한다.
[0012] UE에 의해서 호가 수행되게 하는, UE를 로케이팅하는 방법은 UE를 서빙하는 액세스 네트워크 노드에 제 1 메시지를 전송하는 단계, UE에 대한 로케이션 레퍼런스를 포함하는 제 2 메시지를 액세스 네트워크 노드로부터 수신하는 단계 ― 로케이션 레퍼런스는 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 로케이션 서버에 대한 것이며, 그리고 로케이션 레퍼런스는 UE가 호를 위해 로케이팅되게 할 수 있음 ―, UE의 사용자로부터 호에 대한 요청을 수신하는 단계, 및 호에 대한 요청을 OTT(over-the-top) SP(service provider)에 전송하는 단계를 포함하고, 호에 대한 요청은 UE에 대한 로케이션 레퍼런스를 포함한다.
[0013] UE를 서빙하는 액세스 네트워크 노드에 의해서 수행되는, UE를 로케이팅하기 위한 장치는 적어도 하나의 프로세서 및 그 적어도 하나의 프로세서에 커플링된 트랜시버를 포함하며, 적어도 하나의 프로세서 및 트랜시버는 UE로부터 제 1 메시지를 수신하며, UE에 대한 로케이션 레퍼런스를 결정하며 ― 로케이션 레퍼런스는 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 로케이션 서버에 대한 것이고, 그리고 로케이션 레퍼런스는 UE가 로케이팅되게 할 수 있음 ―, 그리고 UE에 제 2 메시지를 전송하도록 구성되며, 제 2 메시지는 로케이션 레퍼런스를 포함한다.
[0014] 로케이션 서버에서 수행되는, UE를 로케이팅하기 위한 장치는 적어도 하나의 프로세서 및 그 적어도 하나의 프로세서에 커플링된 트랜시버를 포함하며, 적어도 하나의 프로세서 및 트랜시버는 UE를 서빙하는 액세스 네트워크 노드로부터 UE에 대한 로케이션 레퍼런스에 대한 요청을 수신하며, 액세스 네트워크 노드에 UE에 대한 로케이션 레퍼런스를 전송하며, 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신하며 ― 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함함 ―, UE에 대한 로케이션 추정을 결정하며, 그리고 네트워크 엔티티에 UE에 대한 로케이션 추정을 전송하도록 구성된다.
[0015] 로케이션 서버에서 수행되는, UE를 로케이팅하기 위한 장치는 적어도 하나의 프로세서 및 그 적어도 하나의 프로세서에 커플링된 트랜시버를 포함하며, 적어도 하나의 프로세서 및 트랜시버는 UE를 서빙하는 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신하며 ― 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함하고, 로케이션 레퍼런스는 UE에 대한 UE 레퍼런스를 포함함 ―, UE에 대한 로케이션 레퍼런스를 인증하며, UE에 대한 로케이션 레퍼런스의 UE 레퍼런스에 기반하여 UE에 대한 로케이션 추정을 결정하며, 그리고 다른 네트워크 엔티티에 UE에 대한 로케이션 추정을 전송하도록 구성된다.
[0016] UE에 의해서 호가 수행되게 하는, UE를 로케이팅하기 위한 장치는 적어도 하나의 프로세서 및 그 적어도 하나의 프로세서에 커플링된 트랜시버를 포함하며, 적어도 하나의 프로세서 및 트랜시버는 UE를 서빙하는 액세스 네트워크 노드에 제 1 메시지를 전송하며, UE에 대한 로케이션 레퍼런스를 포함하는 제 2 메시지를 액세스 네트워크 노드로부터 수신하며 ― 로케이션 레퍼런스는 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 로케이션 서버에 대한 것이며, 그리고 로케이션 레퍼런스는 UE가 호를 위해 로케이팅되게 할 수 있음 ―, UE의 사용자로부터 호에 대한 요청을 수신하며, 그리고 호에 대한 요청을 OTT SP에 전송하도록 구성되며, 호에 대한 요청은 UE에 대한 로케이션 레퍼런스를 포함한다.
[0017] UE를 서빙하는 액세스 네트워크 노드에 의해서 수행되는, UE를 로케이팅하기 위한 장치는 UE로부터 제 1 메시지를 수신하기 위한 수단, UE에 대한 로케이션 레퍼런스를 결정하기 위한 수단 ― 로케이션 레퍼런스는 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 로케이션 서버에 대한 것이고, 그리고 로케이션 레퍼런스는 UE가 로케이팅되게 할 수 있음 ―, 및 UE에 제 2 메시지를 전송하기 위한 수단을 포함하고, 제 2 메시지는 로케이션 레퍼런스를 포함한다.
[0018] 로케이션 서버에서 수행되는, UE를 로케이팅하기 위한 장치는 UE를 서빙하는 액세스 네트워크 노드로부터 UE에 대한 로케이션 레퍼런스에 대한 요청을 수신하기 위한 수단, 액세스 네트워크 노드에 UE에 대한 로케이션 레퍼런스를 전송하기 위한 수단, 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신하기 위한 수단 ― 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함함 ―, UE에 대한 로케이션 추정을 결정하기 위한 수단, 및 네트워크 엔티티에 UE에 대한 로케이션 추정을 전송하기 위한 수단을 포함한다.
[0019] 로케이션 서버에서 수행되는, UE를 로케이팅하기 위한 장치는 UE를 서빙하는 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신하기 위한 수단 ― 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함하고, 그리고 로케이션 레퍼런스는 UE에 대한 UE 레퍼런스를 포함함 ―, UE에 대한 로케이션 레퍼런스를 인증하기 위한 수단, UE에 대한 로케이션 레퍼런스의 UE 레퍼런스에 기반하여 UE에 대한 로케이션 추정을 결정하기 위한 수단, 및 다른 네트워크 엔티티에 UE에 대한 로케이션 추정을 전송하기 위한 수단을 포함한다.
[0020] UE에 의해서 호가 수행되게 하는, UE를 로케이팅하기 위한 장치는 UE를 서빙하는 액세스 네트워크 노드에 제 1 메시지를 전송하기 위한 수단, UE에 대한 로케이션 레퍼런스를 포함하는 제 2 메시지를 액세스 네트워크 노드로부터 수신하기 위한 수단 ― 로케이션 레퍼런스는 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 로케이션 서버에 대한 것이고, 그리고 로케이션 레퍼런스는 UE가 호를 위해 로케이팅되게 할 수 있음 ―, UE의 사용자로부터 호에 대한 요청을 수신하기 위한 수단, 및 호에 대한 요청을 OTT SP에 전송하기 위한 수단을 포함하고, 호에 대한 요청은 UE에 대한 로케이션 레퍼런스를 포함한다.
[0021] UE를 서빙하는 액세스 네트워크 노드에 의해서 수행되는, UE를 로케이팅하기 위한 비-일시적 컴퓨터-판독가능 매체는 UE로부터 제 1 메시지를 수신하기 위한 적어도 하나의 명령, UE에 대한 로케이션 레퍼런스를 결정하기 위한 적어도 하나의 명령 ― 로케이션 레퍼런스는 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 로케이션 서버에 대한 것이고, 그리고 로케이션 레퍼런스는 UE가 로케이팅되게 할 수 있음 ―, 및 UE에 제 2 메시지를 전송하기 위한 적어도 하나의 명령을 포함하고, 제 2 메시지는 로케이션 레퍼런스를 포함한다.
[0022] 로케이션 서버에서 수행되는, UE를 로케이팅하기 위한 비-일시적 컴퓨터-판독가능 매체는 UE를 서빙하는 액세스 네트워크 노드로부터 UE에 대한 로케이션 레퍼런스에 대한 요청을 수신하기 위한 적어도 하나의 명령, 액세스 네트워크 노드에 UE에 대한 로케이션 레퍼런스를 전송하기 위한 적어도 하나의 명령, 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신하기 위한 적어도 하나의 명령 ― 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함함 ―, UE에 대한 로케이션 추정을 결정하기 위한 적어도 하나의 명령, 및 네트워크 엔티티에 UE에 대한 로케이션 추정을 전송하기 위한 적어도 하나의 명령을 포함한다.
[0023] 로케이션 서버에서 수행되는, UE를 로케이팅하기 위한 비-일시적 컴퓨터-판독가능 매체는 UE를 서빙하는 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신하기 위한 적어도 하나의 명령 ― 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함하고, 그리고 로케이션 레퍼런스는 UE에 대한 UE 레퍼런스를 포함함 ―, UE에 대한 로케이션 레퍼런스를 인증하기 위한 적어도 하나의 명령, UE에 대한 로케이션 레퍼런스의 UE 레퍼런스에 기반하여 UE에 대한 로케이션 추정을 결정하기 위한 적어도 하나의 명령, 및 다른 네트워크 엔티티에 UE에 대한 로케이션 추정을 전송하기 위한 적어도 하나의 명령을 포함한다.
[0024] UE에 의해서 호가 수행되게 하는, UE를 로케이팅하기 위한 비-일시적 컴퓨터-판독가능 매체는 UE를 서빙하는 액세스 네트워크 노드에 제 1 메시지를 전송하기 위한 적어도 하나의 명령, UE에 대한 로케이션 레퍼런스를 포함하는 제 2 메시지를 액세스 네트워크 노드로부터 수신하기 위한 적어도 하나의 명령 ― 로케이션 레퍼런스는 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 로케이션 서버에 대한 것이고, 그리고 로케이션 레퍼런스는 UE가 호를 위해 로케이팅되게 할 수 있음 ―, UE의 사용자로부터 호에 대한 요청을 수신하기 위한 적어도 하나의 명령, 및 호에 대한 요청을 OTT SP에 전송하기 위한 적어도 하나의 명령을 포함하고, 호에 대한 요청은 UE에 대한 로케이션 레퍼런스를 포함한다.
[0025] 본원에서 개시되는 메커니즘들과 연관된 다른 목적들 및 장점들이 첨부 도면들 및 상세한 설명에 기반하여 당업자에게 자명해질 것이다.
[0026] 본 개시내용의 실시예들 및 그에 수반되는 많은 장점들의 보다 완전한 이해는, 이들이 본 개시내용의 제한이 아니라 단지 예시를 위해 제시되는 첨부 도면들과 함께 고려될 때 하기의 상세한 설명을 참조하여 더 잘 이해될 수 있으므로 쉽게 얻어질 것이다.
[0027] 도 1a는 본 개시내용의 적어도 하나의 양상에 따른, 무선 통신 시스템의 고-레벨 시스템 아키텍처를 예시한다.
[0028] 도 1b는 본 개시내용의 적어도 하나의 양상에 따른, LTE(Long-Term Evolution) 무선 액세스를 위한 도 1a의 시스템 아키텍처의 예시적인 구성을 예시한다.
[0029] 도 2a는 본 개시내용의 적어도 하나의 양상에 따른, 레퍼런스에 의한 로케이션을 제공하기 위한, 도 1a에 예시된 네트워크 엔티티들의 특정 상호작용들을 예시한다.
[0030] 도 2b는 본 개시내용의 적어도 하나의 양상에 따른, 레퍼런스에 의한 로케이션을 제공하기 위한, 도 1b에 예시된 네트워크 엔티티들의 특정 상호작용들을 예시한다.
[0031] 도 3은 본 개시내용의 적어도 하나의 양상에 따른, 긴급 서비스들을 제공하기 위한 예시적인 아키텍처를 예시한다.
[0032] 도 4는 본 개시내용의 적어도 하나의 양상에 따른, 레퍼런스에 의한 로케이션 지원을 위한 예시적인 아키텍처를 예시한다.
[0033] 도 5는 본 개시내용의 적어도 하나의 양상에 따른, 긴급 서비스들을 위한 IP(Internet Protocol) IMS(Multimedia Subsystem) 지원에 대한 예시적인 아키텍처를 예시한다.
[0034] 도 6은 본 개시내용의 적어도 하나의 양상에 따른, 긴급 서비스들을 위한 IMS 지원에 대한 다른 예시적인 아키텍처를 예시한다.
[0035] 도 7은 본 개시내용의 적어도 하나의 양상에 따른, 값에 의한 로케이션 및 레퍼런스에 의한 로케이션에 대한 예시적인 호 흐름을 예시한다.
[0036] 도 8은 본 개시내용의 적어도 하나의 양상에 따른, 긴급 호의 IMS 지원에 대한 추가의 예시적인 호 흐름을 예시한다.
[0037] 도 9는 본 개시내용의 적어도 하나의 양상에 따른, 긴급 호의 IMS 지원에 대한 다른 예시적인 호 흐름을 예시한다.
[0038] 도 10은 본원에서 교시되는 바와 같이 통신을 지원하도록 구성되는 컴포넌트들의 몇몇 샘플 양상들의 단순화된 블록 다이어그램이다.
[0039] 도 11은 본 개시내용의 적어도 하나의 양상에 따른 UE(user equipment)의 예를 예시한다.
[0040] 도 12는 본원에서 설명되는 기능성을 수행하기 위한 구조적 컴포넌트들을 포함하는 통신 디바이스를 예시한다.
[0041] 도 13은 본 개시내용의 실시예에 따른 서버를 예시한다.
[0042] 도 14-20은 본 개시내용의 다양한 양상들에 따른, UE를 로케이팅하기 위한 예시적인 흐름들을 예시한다.
[0043] 도 21-27은 본원에서 교시되는 바와 같이 통신을 지원하도록 구성되는 장치들의 몇몇 샘플 양상들의 다른 단순화된 블록 다이어그램들이다.
[0044] 도 2a, 2b, 7, 8 및 9에 도시된 메시지 및 호 흐름들에 있어서, 개별적인 메시지들 및 액션들은 상세한 설명에서 종종 동작들, 블록들 또는 단계들로서 지칭되는 수치 라벨들에 의해 표시됨을 주목한다.
[0045] OTT(over-the-top) SP(service provider)에 대한 로케이션 및 긴급 호들을 위한 지원을 제공하기 위한 방법들 및 장치들이 개시된다. 액세스 네트워크 노드는 UE로부터 제 1 메시지를 수신하고, UE에 대한 로케이션 레퍼런스를 결정하며, 그리고 로케이션 레퍼런스를 포함하는 제 2 메시지를 UE에 전송한다. 액세스 네트워크 노드는 로케이션 서버를 대신하여 로케이션 레퍼런스 자체를 결정할 수 있거나, 또는 로케이션 레퍼런스를 할당 및 리턴하도록 로케이션 서버에 요청할 수 있다. 액세스 네트워크 노드는 프록시로서 기능하고, 그리고 UE와 로케이션 서버 간의 상호작용을 회피할 수 있다. 로케이션 서버는 나중에 네트워크 엔티티로부터 UE에 대한 로케이션 요청을 수신할 수 있고, 여기서 로케이션 요청은 로케이션 레퍼런스를 포함한다. 로케이션 서버는 로케이션 레퍼런스를 사용하여 UE를 로케이팅하고, 그리고 UE 로케이션을 네트워크 엔티티에 리턴할 수 있다. 네트워크 엔티티는 OTT SP일 수 있고, 그리고 UE의 로케이션은 UE로부터 OTT SP로 전송되는 긴급 호를 지원하기 위한 것일 수 있다.
[0046] 본 개시내용의 이러한 그리고 다른 양상들은 본 개시내용의 특정 실시예들에 관련된 하기의 설명 및 관련 도면들에서 개시된다. 대안적인 실시예들이 본 개시내용의 범위를 벗어나지 않으면서 안출될 수 있다. 부가적으로, 본 개시내용의 잘-알려진 엘리먼트들은 본 개시내용의 관련 세부사항들을 모호하게 하지 않도록 하기 위해 생략되거나 또는 상세히 설명되지 않을 것이다.
[0047] 용어들 "예시적인" 및/또는 "예"는, "예, 예증 또는 예시로서 기능하는 것"을 의미하도록 본원에서 사용된다. "예시적인" 및/또는 "예"로서 본원에서 설명되는 임의의 실시예가 반드시 다른 실시예들에 비해 바람직하거나 유리한 것으로 해석되는 것은 아니다. 마찬가지로, 용어 "본 개시내용의 실시예들"은, 본 개시내용의 모든 실시예들이 논의되는 특징, 장점 또는 동작 모드를 포함할 것을 요구하지 않는다.
[0048] 또한, 많은 실시예들은 예컨대 컴퓨팅 디바이스의 엘리먼트들에 의해 수행될 액션들의 시퀀스들과 관련하여 설명된다. 본원에서 설명되는 다양한 액션들은 특정 회로들(예컨대, ASIC들(application specific integrated circuits))에 의해, 하나 또는 그 초과의 프로세서들에 의해 실행되는 프로그램 명령들에 의해, 또는 이 둘의 조합에 의해 수행될 수 있음이 인지될 것이다. 부가적으로, 본원에서 설명되는 이러한 액션들의 시퀀스들은, 실행시 관련 프로세서로 하여금 본원에서 설명되는 기능성을 수행하게 하는 컴퓨터 명령들의 대응하는 세트를 내부에 저장하고 있는 임의의 형태의 컴퓨터 판독가능 저장 매체 내에 완전히 구현되는 것으로 고려될 수 있다. 따라서, 본 개시내용의 다양한 양상들은 다수의 상이한 형태들로 구현될 수 있으며, 이들 모두는 청구되는 청구대상의 범위 내에 있는 것으로 고려된다. 부가적으로, 본원에서 설명되는 실시예들 각각에 대해, 임의의 그러한 실시예들의 대응하는 형태는 본원에서, 예컨대, 설명되는 액션을 수행"하도록 구성된 로직"으로서 설명될 수 있다.
[0049] 표 1은 본 개시내용에 사용되는 용어들 및 약어들의 해설을 제공한다.
Figure pct00001
Figure pct00002
Figure pct00003
표 1 - 용어 및 약어 해설
[0050] 본원에서, UE(user equipment)로 지칭되는 클라이언트 디바이스는 이동식이거나 고정식일 수 있으며, RAN(radio access network)과 통신할 수 있다. 본원에서 사용되는 바와 같이, "UE"라는 용어는 "액세스 단말" 또는 "AT", "무선 디바이스", "무선 단말", "가입자 디바이스", "가입자 단말", "가입자 스테이션", "사용자 단말" 또는 "UT", "모바일 단말", "모바일 스테이션", "단말", "디바이스", "사용자 디바이스" 및 이들의 변형들로 상호 교환가능하게 지칭될 수 있다. 일반적으로, UE들은 RAN을 통해 코어 네트워크와 통신할 수 있고, 코어 네트워크를 통해 UE들은 인터넷과 같은 외부 네트워크들과 연결될 수 있다. 물론, 이를테면 유선 액세스 네트워크들, WiFi 네트워크들(예컨대, IEEE 802.11 등에 기반함) 등을 통해, 코어 네트워크 및/또는 인터넷에 연결하는 다른 메커니즘들이 UE들에 대해 또한 가능하다. UE들은 PC 카드들, 컴팩트 플래시 디바이스들, 외부 또는 내부 모뎀들, 무선 또는 유선 전화들, 스마트폰들, 태블릿 컴퓨터들, 랩톱 컴퓨터들 등(그러나 이들로 제한되지 않음)을 포함하는 다수 타입들의 디바이스들 중 임의의 디바이스에 의해 구현될 수 있다. UE들이 RAN에 신호들을 전송할 수 있게 하는 통신 링크는 업 링크 채널(예컨대, 역방향 트래픽 채널, 역방향 제어 채널, 액세스 채널 등)로 불린다. RAN이 UE들에 신호들을 전송할 수 있게 하는 통신 링크는 다운 링크 또는 순방향 링크 채널(예컨대, 페이징 채널, 제어 채널, 브로드캐스트 채널, 순방향 트래픽 채널 등)로 불린다. 본원에서 사용된 바와 같이, TCH(traffic channel)이라는 용어는 업링크/역방향 또는 다운링크/순방향 트래픽 채널로 지칭될 수 있다.
[0051] 도 1a는 본 개시내용의 실시예에 따른 무선 통신 시스템(100A)의 고-레벨 시스템 아키텍처를 도시한다. 무선 통신 시스템(100A)은 1...N으로 라벨링된 다수(N)의 UE들을 포함한다. UE들(UE 1...UE N)은 셀룰러 텔레폰들, 개인 휴대 정보 단말(PDA들), 페이저들, 랩톱 컴퓨터, 데스크톱 컴퓨터 등을 포함할 수 있다. 예컨대, 도 1a에서, UE 1...2는 셀룰러 호출 폰들로 예시되며, UE 3...5는 셀룰러 터치 스크린 폰들 또는 스마트폰들로 예시되며, UE N은 데스크톱 컴퓨터 또는 PC로 예시된다.
[0052] 도 1a를 참조하면, UE 1...N은, 에어 인터페이스들(104, 106, 108) 및/또는 직접 유선 연결(102)로서 도 1a에 도시되는 물리적 통신 인터페이스 또는 계층을 통해 액세스 네트워크(예컨대, RAN(120), 액세스 포인트(125) 등)와 통신하도록 구성된다. 에어 인터페이스들(104 및 106)은 주어진 셀룰러 통신 프로토콜(예컨대, CDMA(Code Division Multiple Access), EVDO(Evolution-Data Optimized), eHRPD(Enhanced High Rate Packet Data), GSM(Global System for Mobile Communications), EDGE(Enhanced Data Rates for GSM Evolution), WCDMA(Wideband CDMA), LTE(Long-Term Evolution) 등)을 준수할 수 있는 한편, 에어 인터페이스(108)는 WLAN(wireless local area network) 프로토콜(예컨대, IEEE 802.11, Bluetooth® 등)을 준수할 수 있다. 추가로 이하에서 설명되듯이, RAN(120)은 에어 인터페이스, 이를테면 에어 인터페이스(104, 106)들을 통해 UE들을 서빙하는 복수의 액세스 포인트들을 포함한다. RAN(120)에서의 액세스 포인트들은 AN(access node)들, AP(access point)들, BS(base station)들, Node B들, eNode B(evolved NodeB)들 등으로 지칭될 수 있다. 이 액세스 포인트들은 지상 액세스 포인트들(또는 지상국들) 또는 위성 액세스 포인트들일 수 있다. RAN(120)은, RAN(120)에 의해 서빙되는 UE들과 RAN(120) 또는 상이한 RAN 또는 완전히 상이한 (비-RAN) 네트워크에 의해 서빙되는 다른 UE들 또는 다른 비-UE 엔티티들 사이에서 CS(circuit switched) 호들을 라우팅 및 연결하는 것을 포함하는 다양한 기능들을 수행할 수 있고, 또한 외부 네트워크들, 이를테면 인터넷(175)을 통해 다른 엔티티들과의 PS(packet-switched) 데이터의 교환을 중재할 수 있는, PCN(Packet Core Network) 또는 EPC(Evolved Packet Core)로도 지칭될 수 있는 CN(core network)(140)에 연결되도록 구성된다. RAN(120) 및 CN(140)은 UE 1 내지 UE N 중 하나 또는 그 초과에 대해 서빙 무선 네트워크로서 역할을 할 수 있다. 본원에서 무선 네트워크라는 용어는 무선 네트워크와 무선 네트워크 내의 인프라구조(예컨대, RAN(120) 및 CN(140))를 지칭하기 위해 MNO(mobile network operator)라는 용어와 상호교환적으로 사용된다.
[0053] 인터넷(175)은 다수의 라우팅 에이전트들 및 프로세싱 에이전트들(편의상 도 1a에 도시되지 않음)을 포함한다. 도 1a에서, UE N은 인터넷(175)에 직접 연결된 것으로 도시된다(즉, 이를테면 DSL 또는 패킷 케이블 SP를 통해 별개로 코어 네트워크(140)로부터 그리고 일 예에서(예컨대, WiFi 라우터의 경우) 액세스 포인트(125) 자체를 통해서). 그로 인해, 인터넷(175)은 (예컨대, 코어 네트워크(140)를 통해) UE N과, 인터넷(175)에 액세스하는 다른 UE들 사이에 패킷 교환 데이터 통신들을 라우팅하도록 기능할 수 있다.
[0054] 또한 도 1a에는, RAN(120)과 분리된 액세스 포인트(125)가 도시된다. 액세스 포인트(125)는 CN(Core Network)(140)과 독립적으로 (예컨대, FiOS, 케이블 모뎀 등과 같은 광 통신 시스템을 통해) 인터넷(175)에 연결될 수 있다. 무선 인터페이스(108)는 일 예에서 IEEE 802.11 또는 Bluetooth와 같은 로컬 무선 연결을 통해 UE 4 또는 UE 5를 서빙할 수 있다.
[0055] 도 1a를 참조하면, 로케이션 서버(170)는 인터넷(175), CN(140) 또는 둘 모두에 연결된 것으로 도시된다. 로케이션 서버(170)는 구조적으로 분리된 복수의 서버들로서 구현될 수 있거나, 대안적으로 단일 서버에 대응할 수 있다. 이하에서 더욱 상세하게 설명된 바와 같이, 로케이션 서버(170)는 CN(140)을 통해 그리고/또는 인터넷(175)을 통해 로케이션 서버(170)에 연결될 수 있는 UE들에 대한 하나 또는 그 초과의 로케이션 서비스들(예컨대, 포지셔닝 서비스들, 레퍼런스에 의한 포지션 서비스들 등)을 지원하도록 구성된다.
[0056] 도 1a는 OTT(Over-the-Top) SP(Service Provider)(150)를 추가로 예시한다. OTT SP는 인터넷(175), RAN(120) 및 CN(140)에 부분적으로 또는 완전하게 투명한 방식으로 인터넷(175)을 통해 그리고 가능하게는 RAN(120) 및 CN(140)을 통해, UE 1 내지 UE N 중 하나 또는 그 초과로 그리고/또는 그로부터 오디오, 비디오 및/또는 다른 미디어 콘텐츠를 전달할 수 있다. OTT SP는 전형적으로 제 3자 제공자, 이를테면 Skype™, Hulu, Netflix, Google 등을 지칭한다. OTT SP(150)는 인터넷(175), CN(140), RAN(120) 및/또는 액세스 포인트(125)를 통해 UE 1...N과 통신할 수 있다. 단일 OTT SP(150)만이 도 1a에 도시되었지만, 명백하게, 인터넷(175)에 연결된 임의의 수의 OTT SP들(150)이 존재할 수 있으며, 이들 각각은 상이한 OTT SP에 대응한다. OTT SP(150)는 OTT SP(150)에 대해 본원에 설명된 다양한 기능들을 수행할 수 있는 하나 또는 그 초과의 서버들, 라우팅 프록시들 및/또는 다른 엔티티들(도 1a에 미도시)을 가질 수 있다. 이후에 본원에서 언급되는 다른 OTT SP들, 이를테면 OTT SP(350, 450, 550, 650, 750, 850 및 950)의 경우도 마찬가지 일 수 있다.
[0057] 도 1a에는 또한 ESInet(Emergency Services IP Network) 및/또는 SR(Selective Router)(160)이 도시된다. ESInet(160)는 UE 1 내지 UE N 중 임의의 UE에 의해 이루어지고 인터넷(175), CN(140) 또는 OTT SP(150)를 통해 수신되는 IP 기반 긴급 호들을 적절한 PSAP(Public Safety Answering Point), 이를테면 PSAP(180)로 라우팅할 수 있다. 유사하게, SR(160)은 UE 1 내지 UE N 중 임의의 UE에 의해 이루어지고 CN(140)을 통해 수신되는 CS(Circuit Switched) 긴급 호를 PSAP, 이를테면 PSAP(180)로 라우팅할 수 있다. 일부 실시예들에서, UE 1 내지 UE N 중 임의의 UE가 IP 기반 긴급 호를 발신할 수 있으며, 이는 CN(140) 또는 OTT SP(150)에 의해 CS 긴급 호로 변환되어 CS 가능 PSAP(180)에 라우팅하기 위해 (예컨대, 도 1에 미도시된 공중 전화 교환 네트워크를 통해) SR(160)로 전송될 수 있다. 이는, SR(160)이 있지만 ESInet(160)가 없는 경우 그리고/또는 PSAP(180)가 CS 긴급 호들을 지원하지만 IP 기반 긴급 호들을 지원하지 않는 경우, 발생할 수 있다. 이후에 본원에서의 OTT SP(150)를 통한 긴급 호 설정의 설명들에서, 긴급 호는 UE(예컨대, UE 1 내지 UE N 중 임의의 UE)로부터 IP 기반 긴급 호로서 시작할 수 있지만, OTT SP(150)에 의해 CS 긴급 호로 전환되어 ESInet(160)를 통해서가 아니라 SR(160)을 통해 PSAP(180)로 라우팅될 수 있다는 것이 이해되어야 한다.
[0058] 도 1a에서 UE 1...N은 인터넷(175)을 통해 음성, 텍스트, 비디오 또는 다른 데이터 긴급 호들을 수행할 수 있다. 예컨대, UE 1...N은, 이하에서 추가로 설명된 바와 같이, OTT SP(150)를 통해 이러한 긴급 호를 수행할 수 있다. ESInet/SR(160)은 이러한 음성, 텍스트, 비디오 및 데이터 긴급 호들을, 예컨대 긴급 호 센터일 수 있는 PSAP(180)로 전달할 수 있다. 이러한 긴급 호들을 전달하기 위해 사용되는 프로토콜은 IETF(Internet Engineering Task Force)에 의해 정의된 SIP(Session Initiation Protocol)일 수 있다. 부가적으로, SIP 기반 긴급 호들은, SIP의 사용을 지원하는, 3GPP에 의해 정의된 IMS(IP Multimedia Subsystem)를 이용하여 전달될 수 있고, CN(140)에 의해 지원될 수 있다.
[0059] RAN(120) 및 CN(140)에 대한 프로토콜-특정 구현의 예가, RAN(120)에 의한 LTE 액세스의 지원의 경우 더욱 상세하게 무선 통신 시스템(100A)을 설명하는 것을 돕기 위해, 도 1b와 관련하여 이하에 제공된다. 특히, RAN(120) 및 CN(140)의 컴포넌트들은 PS(packet-switched) 통신들을 지원하는 것과 관련된 컴포넌트들에 대응하며, 이로 인해 레거시 CS(circuit-switched) 컴포넌트들이 또한 이러한 네트워크에 존재할 수 있지만, 도 1b에서 명시적으로 도시되지는 않는다.
[0060] 구체적으로, 도 1b는 본 개시내용의 실시예에 따라, LTE 무선 액세스를 지원하는 EPS(Evolved Packet System)에 기반하여 RAN(120)과 CN(140)의 예시적 구성(100B)을 예시한다. 도 1b의 예에서, EPS/LTE 네트워크에서 RAN(120)은 복수의 이벌브드 Node B들(eNodeB들 또는 eNB들)(122, 124 및 126)로 구성된다. CN(140)은 복수의 MME(Mobility Management Entity)들(142 및 144), E-SMLC(Enhanced Serving Mobile Location Center)(172), S-GW(Serving Gateway)(146), 및 PDG(Packet Data Network Gateway)(148)를 포함한다. 도 1b의 예에서, 로케이션 서버(170)는 OMA(Open Mobile Alliance)에 의해 정의되는 LET 제어 평면 로케이션 솔루션을 지원하는 GMLC(Gateway Mobile Location Center) 또는 SUPL 로케이션 솔루션을 지원하는 SLP(SUPL(Secure User Plane Location) Location Platform)(170)이다. 일부 실시예들에서, 로케이션 서버(170)는 GMLC 및/또는 SLP에 연결 또는 상기 GMLC 및/또는 SLP와 연관을 가지는 LRF(Location Retrieval Function)일 수 있다. 이들 컴포넌트들, RAN(120) 및 인터넷(175) 간의 네트워크 인터페이스들은 도 1b에 예시되고 표 2에서 정의된다.
Figure pct00004
표 2
[0061] 도 1b의 RAN(120) 및 CN(140)에 도시된 컴포넌트들의 고-레벨 설명이 이제 설명될 것이다. 그러나, 이들 컴포넌트들 중 일부는 다양한 3GPP 기술 규격(TS)들로부터 기술 분야에서 잘 알려져 있고, 그리고 본원에 포함된 설명은 이들 컴포넌트들에 의해 수행되는 모든 기능성들을 총망라한 설명인 것으로 의도되지 않는다.
[0062] 도 1b를 참조하면, MME들(142 및 144)은 EPS 베어러들에 대한 제어 평면 시그널링을 관리하고 CN(140)에 액세스하는 UE들에 대한 이동성을 지원하도록 구성된다. MME 기능들은 NAS(Non-Access Stratum) 시그널링, NAS 시그널링 보안, 인터- 및 인트라-기술 핸드오버들에 대한 이동성 관리, PDG 및 S-GW 선택, 및 MME 변화로 인한 UE 핸드오버들을 위한 MME 선택을 포함한다.
[0063] S-GW(146)는 사용자 평면 시그널링을 위해 RAN(120)으로의 인터페이스를 종결하는 게이트웨이이다. EPS-기반 시스템에 대하여 CN(140)에 어태치되는 각각의 UE에 대해, 주어진 시점에서, 단일 S-GW가 존재한다. PMIP(Proxy Mobile IPv6)-기반 S5/S8에 대한 S-GW(146)의 기능들은 이동성 앵커 포인트, 패킷 라우팅 및 포워딩, 및 연관된 EPS 베어러의 QCI(QoS Class Identifier)에 기반하여 DSCP(DiffServ Code Point) 세팅을 포함한다.
[0064] 도 1b를 참조하면, PDG(148)는 PDN(Packet Data Network), 예컨대 인터넷(175) 쪽으로의 SGi 인터페이스를 종결하는 게이트웨이이다. UE가 다수의 PDN들에 액세스하고 있으면, 그 UE에 대해 하나보다 많은 PDG가 있을 수 있다. PDG(148) 기능들은 패킷 필터링(심층 패킷 검사에 의해), UE IP 어드레스 배정, 연관된 EPS 베어러의 QCI에 기반하여 DSCP 세팅, 인터 오퍼레이터 과금 청구, 3GPP TS 23.203에서 정의된 바와 같이 업링크(UL) 및 다운링크(DL) 베어러 바인딩, 및 3GPP TS 23.203에서 정의된 바와 같은 UL 베어러 바인딩 검증을 포함한다. PDG(148)는 E UTRAN, GERAN, 또는 UTRAN 중 임의의 것일 수 있는 RAN(120)을 사용하여 GERAN(GSM/EDGE Radio Access Network)/UTRAN 전용 UE들 및 LTE 가능 UE들 모두로의 PDN 연결성을 제공한다. PDG(148)는 S5/S8 인터페이스를 통해 도 1b에 도시된 바와 같은 eNB들을 포함하는 RAN(E UTRAN으로서 지칭됨)(120)을 사용하여 LTE 가능 UE들로의 PDN 연결성을 제공한다.
[0065] 도 1b를 참조하면, GMLC/SLP(170)는 MME(142), CN(140)의 PDG(148) 및/또는 인터넷(175)에 연결된 것으로 도시된다. GMLC/SLP(170)는 GMLC 또는 SLP일 수 있거나, GMLC 또는 SLP로의 연결 또는 상기 GMLC 또는 SLP와의 연관을 가지는 LRF일 수 있다. GMLC(170)(또는 연관된 또는 연결된 GMLC를 가지는 LRF(170))는 LTE 제어 평면 로케이션 솔루션을 지원하는 반면, SLP(170)(또는 연관된 또는 연결된 SLP를 가지는 LRF(170))는 SUPL 로케이션 솔루션을 지원한다. GMLC/SLP(170)가 SLP가 아닌 GMLC인 경우에, GMLC/SLP(170)는 MME(142)와, PDG(148) 및 인터넷(175) 중 하나 또는 둘 모두에 연결될 수 있다. GMLC/SLP(170)가 GMLC가 아닌 SLP인 경우에, GMLC/SLP(170)는 MME(142)에 연결될 수 있거나 혹은 연결될 수 없고 그리고 PDG(148) 및 인터넷(175) 중 하나 또는 둘 모두에 연결될 수 있다. GMLC/SLP(170)는 외부 엔티티, 이를테면 OTT SP(150), ESInet(160), 또는 PSAP(180)로 하여금 로케이션 요청을 도 1a의 UE들(1 내지 N) 중 임의의 UE에 대한 GMLC/SLP(170)에 전송하게 할 수 있고, GMLC의 경우에는 3GPP 제어 평면 로케이션 솔루션을 사용하여 또는 SLP의 경우에는 SUPL을 사용하여 이 UE에 대한 로케이션 결정을 조정할 수 있고, 그리고 결정된 로케이션을 요청하는 외부 엔티티에 리턴할 수 있다. 도 1b에 예시된 E-SMLC(172)는 MME(142)에 연결되고, LTE 제어 평면 로케이션 솔루션을 사용하여 UE 로케이션 추정을 획득하기 위하여 사용되는 다른 로케이션 서버이다.
[0066] 제어 평면 로케이션 솔루션에서, 로케이션 서버(예컨대, 도 1a의 로케이션 서버(170) 또는 도 1b의 GMLC/SLP(170))는 네트워크의 기존 시그널링 인터페이스들을 통해 UE들을 비롯한 다른 엘리먼트들에 의해 액세스된다. UE의 로케이션에 관련된 모든 시그널링은 모든 인터페이스들 상에서 시그널링으로서 명확하게 전송된다. LTE 액세스의 경우에, 제어 평면 위치 솔루션은 3GPP TS들 23.271 및 36.305에서 정의된다.
[0067] 사용자 평면 로케이션 솔루션, 이를테면 SUPL 솔루션에서, 도 1b의 GMLC/SLP(170)와 같은 로케이션 서버 및 UE는 이를테면 IP 또는 TCP/IP를 통해서 네트워크의 측면에서 데이터를 교환함으로써 통신한다. SUPL 솔루션의 경우에, GMLC/SLP(170)는 SLP일 것이고, E-SMLC(172)를 사용하기보다 오히려 로케이션을 획득하기 위하여 사용될 것이다. 일부 경우들에서, 네트워크는 제어 평면 로케이션 솔루션 및 사용자 평면 로케이션 솔루션 둘 모두, 이를테면 SUPL을 이용할 수 있다. 그 경우에, E-SMLC(172)가 존재할 수 있고, GMLC/SLP(170)는 GMLC 및 SLP 둘 모두를 포함할 수 있다. GMLC/SLP(170)에 대한 GMLC 및 SLP는 또한 (예컨대, 동일한 물리적 엔티티에서) 조합될 수 있거나 또는 둘 모두의 솔루션들이 UE를 로케이팅하기 위하여 사용되도록 하기 위해 서로 연결될 수 있다. 이미 언급된 바와 같이, GMLC/SLP(170)는 또한 GMLC 및/또는 SLP와의 연관 또는 상기 GMLC 및/또는 SLP로의 연결을 가지는 LRF를 포함할 수 있다. GMLC에 연결되고 연관된 LRF(170)는 유사하게 GMLC에 제어 평면 로케이션을 지원할 수 있는 반면, SLP에 연결되거나 그것에 연관되는 LRF(170)는 유사하게 SLP에 SUPL 사용자 평면 로케이션을 지원할 수 있다.
[0068] ATIS(Alliance for Telecommunications Industry Solutions)는 OTT 서비스 제공자, 예컨대 Skype™를 통해 UE에 의해 설정된 차세대 9-1-1(NG911) 호들을 지원하기 위한 조사 방식들이다. 하나의 주된 문제는 OTT SP에 의해 정확한 PSAP로 또는 그 쪽으로 NG911의 라우팅을 가능하게 하고 그리고 PSAP에 의해 호출 사용자의 로케이션에 공중 안전 지원의 디스패치를 가능하게 하기 위한 911 호출자의 정확하고 신뢰적인 로케이션을 획득 및 제공하는 것이다. OTT SP, 이를테면 OTT SP(150)가 종종 호출 UE에 의해 사용되는 액세스 네트워크에 관한 정보가 작거나 없을 것이기 때문에, OTT SP가 호출 UE를 직접 로케이팅하기 위하여 지상 기반 포지셔닝 방법들(이를테면 WiFi, E-CID(Enhanced Cell ID), 및 OTDOA(observed time difference of arrival))을 이용하는 것이 어려울 수 있다. 게다가, 호출 UE가 실내에 있을 때, SPS(Satellite Positioning System), 이를테면 GPS(Global Positioning System), 일부 다른 GNSS(Global Navigation Satellite System)를 사용하여 또는 OTT SP에 의한 A-GPS(Assisted GPS) 또는 A-GNSS(assisted GNSS)를 통해 UE의 로케이션은 또한 실내의 SPS 로케이션을 사용하는데 내재적인 난관으로 인해 및/또는 SPS 로케이션의 사용을 제어 및/또는 돕기 위한 OTT SP에 의한 능력의 결핍으로 인해 비신뢰적일 수 있다.
[0069] OTT SP(150)를 통해 긴급 호를 착수한 UE의 로케이션을 획득하기 위하여 OTT SP(150)에 의해 사용될 수 있는 하나의 솔루션은, OTT SP(150)에 이 로케이션 서버의 어드레스가 제공될 수 있거나 상기 OTT SP(150)가 상기 어드레스를 추론할 수 있다면, 호출 UE의 로케이션을 획득하기 위하여 OTT SP(150)가 액세스 네트워크(이를테면 도 1a의 로케이션 서버(170) 또는 도 1b의 GMLC/SLP(170))의 로케이션 서버에 질의하는 것을 수반한다. 다른 솔루션에서, 긴급 호를 착수하는 UE는 자신의 로케이션을 직접 OTT SP(150)에 (예컨대, NG911 호를 설정하기 위하여 사용되는 SIP INVITE를 통해) 제공할 수 있다. UE가 자신의 로케이션을 OTT SP(150)에 직접 제공하는 것은, (a) 표준들(예컨대, 3GPP 표준들)에 대한 새로운 영향들이 제한될 수 있고, (b) MNO(mobile network operator) RAN 및 CN 네트워크들에 대한 구현 영향들이 작거나 없을 수 있고, (c) UE들이 통상적으로 어쨌든 독립형 로케이션 성능(예컨대, UE 오퍼레이팅 시스템 벤더 또는 UE 칩 벤더에 의해 도움을 받는 솔루션)을 지원하고, 그리고 (d) 솔루션이 긴급 호를 착수하기 위하여 전송된 SIP INVITE를 통한 UE 위치의 UE 제공을 허용하는 기존 NG911 표준들과 잘 맞기 때문에, 매력적인 솔루션일 수 있다.
[0070] UE-제공 로케이션(예컨대, SIP INVITE에 포함됨)은 가치가 있을 수 있거나(예컨대, UE는 자신의 위도/경도 좌표들을 직접 제공함) 또는 참조될 수 있다. 레퍼런스에 의한 로케이션을 위해, UE는 로케이션 서버의 이름 또는 어드레스, 로케이션 서버에 의해 할당될 수 있는 UE에 대한 고유 레퍼런스, 및 로케이션 서버로부터 UE 로케이션을 획득하기 위하여 사용할 프로토콜의 표시를 포함하는 URI(Uniform Resource Identifier)(UE에 의해 본래 로케이션 서버로부터 획득되고 본원에서 "로케이션 URI"로서 지칭됨)를 제공한다. "로케이션 URI"는 본원에서 "로케이션 레퍼런스"로서 그리고 "레퍼런스에 의한 로케이션"으로서 상호교환가능하게 지칭된다. 로케이션 URI는 RFC(Request For Comment)들(3986 및 5808)에서 IETF에 의해 정의된 바와 같을 수 있고 방식 이름 또는 프로토콜 이름, 이를테면 SIP 또는 HTTP의 식별 및 로케이션 서버의 식별(예컨대, 인터넷 경로 이름 또는 어드레스) 및 UE의 식별을 포함할 수 있는 자원의 식별을 인코딩하는 RFC 3986의 규칙들에 따르는 문자열을 포함할 수 있다.
[0071] 또한 본원에서 "UE 레퍼런스", "로컬 UE 레퍼런스", 또는 "로컬 레퍼런스"로서 지칭되는 UE의 식별은 UE를 로케이션 서버에 식별시키지만 다른 엔티티들에게는 UE의 정확한 아이덴티티를 숨기는 문자들을 포함할 수 있고 그리고 로케이션 서버에 의해 로컬적으로 할당될 수 있다. UE는 로케이션 구성 프로토콜, 이를테면 IETF RFC 5985에서 정의된 HELD(HTTP-Enabled Location Delivery) 프로토콜을 사용하여 로케이션 서버로부터 로케이션 URI를 요청 및 획득할 수 있다. UE는 로케이션 전달 프로토콜, 이를테면 IETF RFC 6442에서 정의된 바와 같은 SIP를 사용하여 도 1a 및 도 1b의 다른 엔티티, 이를테면 OTT SP(150), ESInet(160) 또는 PSAP(180)에 로케이션 URI를 전달할 수 있다. UE에 대한 로케이션 URI를 수신하는 엔티티(예컨대, 도 1a 및 도 1b의 OTT SP(150), ESInet(160), 또는 PSAP(180))는 로케이션 역참조 프로토콜, 이를테면 SIP, HTTP 또는 HELD를 사용하여, 로케이션 서버로부터 UE의 로케이션(예컨대, 위도 및 경도(어쩌면 고도)를 포함할 수 있는 지리적인 좌표들 또는 우편 주소 또는 거리 주소(및 어쩌면 층 번호, 방 번호, 스위트(suite) 번호 등)를 포함할 수 있는 도시 로케이션)을 요청 및 수신할 수 있다. 로케이션 역참조에 의해, 로케이션을 요청하는 엔티티는 로케이션 URI를 로케이션 서버에 제공하고, 로케이션 서버는 UE로부터 로케이션 URI를 식별하고, UE에 대한 로케이션을 획득하고, 그리고 요청한 엔티티에 로케이션을 리턴한다.
[0072] 레퍼런스 솔루션에 의한 로케이션은 값 솔루션에 의한 로케이션보다 더 매력적인데, 그 이유는 UE 또는 로케이션 서버가 UE에 대한 로케이션을 획득하는데 더 많은 시간을 허용하고 그리고 상이한 시간들에서 UE에 대한 하나보다 많은 로케이션을 획득하기 위하여 사용될 수 있기 때문이다. 예컨대, 레퍼런스 솔루션에 의한 로케이션은 처음에 라우팅을 돕기 위해 근사 UE 로케이션을 획득하고 나중 시간에 PSAP 디스패치를 위해 더 정확한 UE 로케이션을 획득하기 위하여 OTT SP(150)에 의해 사용될 수 있다.
[0073] 레퍼런스 솔루션에 의한 로케이션는 UE 및 로케이션 서버에 대해 상당한 영향들을 미칠 수 있는데, UE 및 로케이션 서버 둘 모두는, (a) UE가 로케이션 URI를 요청할 수 있게 하고 로케이션 서버가 로케이션 URI를 제공할 수 있게 하는 로케이션 구성 프로토콜, 이를테면 HELD, 및 (b) 로케이션 서버가 (a)에서 질의/응답이 발생할 때 UE의 아이덴티티를 인증하기 위한 수단을 지원할 필요가 있을 수 있다. 클라이언트(예컨대, OTT SP(150) 또는 PSAP(180))가 로케이션 서버에 로케이션 URI를 질의함으로써 UE의 로케이션를 요청하는 어떤 나중의 시점에 (예컨대, 다른 어떤 UE는 로케이팅하지 않고) 정확한 UE를 로케이팅하기 위해 로케이션 URI가 할당될 때 로케이션 서버가 UE를 신뢰성 있게 식별할 필요가 있을 수 있기 때문에 (b)에서의 영향이 요구될 수 있다. 로케이션 URI가 제공되는 UE의 IP 어드레스는 (a)가 발생할 때는 UE로부터 로케이션 서버에 이용가능할 수 있고 로케이션 URI가 (예컨대, HELD를 사용하여) OTT SP(150), ESInet(160) 또는 PSAP(180)에 의해 나중에 역참조될 때는 나중에 UE를 식별하고 로케이팅하기에 충분히 신뢰성 있는 것으로 간주될 수 있기 때문에 HELD와 같은 일부 로케이션 구성 프로토콜들이 (b)에서의 인증을 통상적으로 요구하거나 지원하지 않을 수 있다.
[0074] 그러나 IP 어드레스는 위조될 수 있다. 예컨대, UE가 아니라 UE로의 그리고 UE로부터의 IP 통신을 가로막을 수 있는 엔티티는 UE에 대한 IP 어드레스를 포함하는 로케이션 요청을 로케이션 서버에 전송함으로써 로케이션 구성 프로토콜을 사용하여 UE에 대한 로케이션 URI를 획득할 수 있다. 그 다음, 엔티티는 (i) 획득된 로케이션 URI를 포함하는 역참조 요청을 로케이션 서버에 전송함으로써 OTT SP로 가장하여 UE에 대한 로케이션를 획득하거나 (ii) UE가 긴급 호를 수행하지 않았더라도 긴급 호를 착수하고 OTT SP(150)에 로케이션 URI를 제공하여 UE의 로케이션에 대한 공중 안전 디스패치를 야기할 수 있다.
[0075] 추가로, UE에 대한 IP 어드레스가 정확한 경우에도 그리고 UE 로케이션를 요청하는 엔티티가 적법한 경우, 로케이션 서버는 UE의 로케이션를 획득하기 위해 그리고/또는 나중에 UE를 정확히 식별하기 위해 UE에 대한 상이한 아이덴티티를 필요로 할 수 있다. 예컨대, 로케이션 서버가 제어 평면 로케이션 솔루션을 이용하여 UE의 로케이션(예컨대, LTE에 대한 3GPP 제어 평면 로케이션 솔루션)를 획득한다면, 로케이션 서버는 UE의 IP 어드레스보다는 UE에 대한 무선 연관 아이덴티티, 이를테면 IMSI(International Mobile Subscriber Number) 또는 TMSI(Temporary Mobile Subscriber Number)를 필요로 할 수 있다. 추가로, 로케이팅된 UE가 요금 부과 또는 과금 목적들로 나중에 식별될 필요가 있거나(예컨대, 로케이션 서버에 대한 SP가 OTT SP(150)에 과금할 수 있도록) 획득된 로케이션가 오류가 있거나 통계 및 회계 목적이었던 경우에 후속 조치를 취할 필요가 있다면, IP 어드레스가 아닌, UE에 대한 어떤 영구적인 글로벌 아이덴티티가 요구될 수 있다. 로케이션 서버가 UE에 대한 정확한 아이덴티티를 갖고 있어서 로케이션 URI가 UE로 가장하는 엔티티가 아니라 정확한 UE에 제공되는 것을 보장하기 위해, 상기 (b)에서의 인증 영향이 요구될 수 있다. (a)와 (b)의 이중 영향들은 (예컨대, 본원에서 앞서 언급된 IETF RFC들에 의해 정의된 바와 같은) 레퍼런스 솔루션에 의한 로케이션를 UE 벤더들과 MNO들 또는 이들의 로케이션 서버 벤더들 모두에 대해 복잡하게 만들 수 있다.
[0076] 레퍼런스에 의한 로케이션를 사용하기 위한, 위에서 설명된 문제점에 대한 솔루션은, UE(및 그의 아이덴티티)가 액세스 네트워크에 의해 인증된 이후에, 로케이션 서버보다는 서빙 액세스 네트워크가 UE에 레퍼런스에 의한 로케이션를 제공하는 것일 것이다. 액세스 네트워크에 의한 UE의 인증은 많은 타입들의 무선 네트워크들(예컨대, GSM, UMTS, LTE, IEEE 802.11)에 대해 지원되거나 지원될 수 있는 무선 네트워크 동작의 일반적인 부분이며, 그러므로 UE 또는 액세스 네트워크에 어떠한 새로운 영향들도 부가하지 않을 수 있다. 액세스 네트워크에 의해 UE로 레퍼런스에 의한 로케이션를 제공하는 것은, (i) UE가 액세스 네트워크에 성공적으로 어태치하여 인증된 직후에, (ii) (예컨대, 레퍼런스에 의한 이전 로케이션이 상이한 로케이션 서버 및/또는 상이한 로컬 UE 레퍼런스에 기반하여 교체될 수 있게 하기 위해) UE가 액세스 네트워크에 어태치된 동안 주기적으로, 및/또는 (iii) UE가 액세스 네트워크에 어태치된 동안 UE에 의한 요청시, 발생할 수 있다.
[0077] 일 실시예에서, 액세스 네트워크는 UE에 대한 레퍼런스에 의한 로케이션를 획득하기 위해 로케이션 서버와 통신할 수 있다. 이 실시예에서, 액세스 네트워크는 프록시로서 작용하여 UE 대신 로케이션 서버로부터 레퍼런스에 의한 로케이션를 획득할 수 있다. 다음에, UE 및 로케이션 서버는 UE가 로케이션 서버로부터 로케이션 URI를 획득할 수 있도록 로케이션 구성 프로토콜을 지원할 필요가 없을 것이다. 대신, UE는 액세스 네트워크로부터 로케이션 URI를 획득할 것이고, 액세스 네트워크는 로케이션 서버로부터 로케이션 URI를 획득할 것이다. 이 실시예는 새로운 액세스 네트워크-로케이션 서버 인터페이스를 추가할 수 있지만, 이는 UE와 로케이션 서버 모두에 의해 로케이션 구성 프로토콜 및 UE의 인증을 지원할 필요성을 회피할 수 있으며, 따라서 종래의 로케이션 구성 프로토콜을 사용하여 UE가 직접 로케이션 서버에 질의하게 하는 것보다 더 간단한 솔루션일 수 있다.
[0078] 다른 실시예에서, 액세스 네트워크는 레퍼런스에 의한 로케이션를 로케이션 서버의 수반 없이 UE 자체에 할당할 수 있다. 예컨대, 액세스 네트워크(예컨대, MME(142))는 타겟 로케이션 서버(예컨대, 도 1a의 로케이션 서버(170) 또는 도 1b의 GMLC/SLP(170))의 알려진 어드레스 또는 알려진 아이덴티티(예컨대, 알려진 인터넷 경로 이름)를 포함하는 로케이션 URI, 클라이언트로부터 로케이션 서버에 질의하는데 사용될 방식 또는 프로토콜, 및 (로케이션 서버의 어드레스 또는 아이덴티티에 대한 확장으로서) UE를 식별하는 UE 레퍼런스를 생성할 수 있다. 정상 로케이션 URI에서, UE 레퍼런스는 로케이션 URI를 생성하는 로케이션 서버에 의해 로컬적으로 할당될 수 있다. 여기서 설명되는 실시예에서, UE 레퍼런스는 액세스 네트워크에 의해 할당될 수 있으며, 글로벌 UE 식별, 이를테면 UE의 IP 어드레스, UE에 대한 IMSI, 및/또는 액세스 네트워크에 알려진 UE에 대한 아이덴티티, 이를테면 TMSI, 액세스 네트워크 노드에 의해 할당된 UE에 대한 로컬 어드레스(예컨대, MME 또는 SGSN) 및/또는 액세스 네트워크 노드의 어드레스, 또는 이것들의 임의의 결합을 포함할 수 있다. UE 레퍼런스는 할당의 날짜 및/또는 시간을 더 포함할 수 있으며 그리고/또는 사용자 프라이버시를 보호하기 위해 암호화될 수 있다(예컨대, 여기서 암호 키들은 액세스 네트워크와 로케이션 서버에 알려지지만 다른 측들에는 알려지지 않는다). UE 레퍼런스가 TMSI 또는 IP 어드레스를 포함하는 경우, UE의 정확한 아이덴티티(예컨대, UE의 IMSI)는 UE 레퍼런스에 포함되지 않고 따라서 다른 측들에 이용가능하지 않을 수 있기 때문에 암호화는 필요하지 않을 수 있다. 로케이션 URI는 또한, 로케이션 URI를 질의받은 로케이션 서버가 액세스 네트워크에 의해 로케이션 URI가 할당되었음을 알 수 있도록 액세스 네트워크에 의해 디지털로 서명될 수 있다(예컨대, 디지털 시그니처를 포함할 수 있다). 일부 경우들에, 로케이션 URI는 예컨대, CCM(Cipher Block Chaining-Message Authentication Code)을 이용한 NIST(United States National Institute of Standards and Technology) 카운터 방법을 사용하여 암호화되면서 디지털로 서명될 수 있다.
[0079] 위의 실시예들의 사용은 단지 액세스 네트워크 및 로케이션 서버에 영향을 줄 수 있다. 그러므로 MNO는 로케이션 서버의 수반 없이 액세스 네트워크가 로케이션 URI를 할당하는 제 2 실시예로부터, (예컨대, UE들을 비롯한) 다른 엔티티들에 영향을 주지 않으면서 액세스 네트워크가 로케이션 서버에 대한 프록시로서 작용하는 제 1 실시예로 전환할 수 있다. 일부 경우들에, MNO 전환은 제 1 실시예에서 제 2 실시예로일 수 있다. 액세스 네트워크가 LTE를 지원하고 셀룰러 MNO에 속하는 경우에, UE에 대한 레퍼런스에 의한 로케이션는 UE에 대한 서빙 MME, 이를테면 도 1b의 MME(142)에 의해 할당될 수 있다. 할당은 UE에 의한 LTE 네트워크 어태치먼트의 일부로서 그리고/또는 UE에 의한 추적 영역 업데이트의 일부로서 발생할 수 있다. 이러한 할당은 할당된 로케이션 URI를 포함하는 하나의 새로운 파라미터를 LTE 지원을 위해 사용되는 몇 개의 NAS(Non-Access Stratum) 메시지들에 부가할 수 있으며, UE와 액세스 네트워크(예컨대, MME) 모두에 대해 작은 영향을 가질 수 있다. MNO들 및 UE 벤더들에 대한 이러한 솔루션의 이득은 솔루션을 지원하는데 대한 영향들이 제한될 수 있고 기존 표준들에 맞는 플렉시블한 로케이션 솔루션이 OTT SP들에 제공될 수 있다는 점일 수 있다.
[0080] 다시 도 1a 및 도 1b를 참조하면, 도 2a는 본원에서 설명되는 실시예들에 따라 OTT 긴급 호에 대한 레퍼런스에 의한 로케이션를 제공하기 위해서 도 1a에 및 LTE 액세스의 경우에는 도 1b에 예시된 네트워크 엔티티들의 특정 상호작용들을 예시한다. 도 2a를 참조하면, "액세스 네트워크"라는 용어는 RAN(120) 및 CN(140)을 지칭한다. 액세스 네트워크 노드(240)는 액세스 네트워크 내의 어떤 엔티티, 이를테면 액세스 노드, 액세스 포인트, 기지국, eNodeB(예컨대, eNB(122, 124 또는 126)), 펨토셀, MME(예컨대, MME(142)) 등일 수 있다. 액세스 네트워크 노드는 RAN(120) 내에 또는 CN(140) 내에 있을 수 있다.
[0081] 202A에서, (예컨대, 도 1a의 UE들 1 내지 N 중 임의의 UE에 대응할 수 있는) UE(200)는 액세스 네트워크 노드(240)를 통해 액세스 네트워크에 어태치한다. 204A에서, UE(200)의 사용자가 UE(200) 상에 설치된 OTT 애플리케이션, 예컨대 Skype를 통해 긴급 호를 수행한다. 206A에서, UE(200)는 액세스 네트워크 노드(240)에 로케이션 레퍼런스에 대한 요청을 전송한다. 일부 실시예들에서, 블록(206A)은 OTT 애플리케이션에 의해 착수될 수 있는데, OTT 애플리케이션은 블록(204A)에서의 긴급 호 요청을 인식할 수 있고 로케이션 레퍼런스를 획득하도록 (예컨대, UE(200) 상의 모뎀에 대한 API(Application Programming Interface)를 사용하여) UE(200)에 요청할 수 있다.
[0082] 208A에서, 액세스 네트워크 노드(240)는 선택적으로, UE(200)에 대한 로케이션 레퍼런스를 위해 로케이션 서버(170)(예컨대, GMLC/SLP(170) 또는 E-SMLC(172))에 로케이션 레퍼런스 요청을 전송하고 212A에서 로케이션 레퍼런스를 포함하는 로케이션 서버(170)로부터의 응답을 다시 수신할 수 있다. 이 경우, 액세스 네트워크 노드(240)는 블록(208A)에서 UE(200) 대신 로케이션 서버(170)로부터 로케이션 레퍼런스를 획득하기 위한 프록시로서 작용한다. 블록(208A)에서의 요청/응답은 로케이션 서버(170)와 액세스 네트워크 노드(240) 사이의 보안 연결을 사용할 수 있는데, 이는 오퍼레이터가 로케이션 서버(170)에 대한 것과 동일할 수 있는 액세스 네트워크 노드가 로케이션 레퍼런스를 요청하고 있음을 로케이션 서버(170)가 인지할 수 있게 한다. 로케이션 서버(170)와 액세스 네트워크 노드(240) 사이의 보안 연결은 로케이션 서버(170)와 액세스 네트워크 노드(240) 사이의 신뢰할 수 있는 관계, 예컨대 동일한 SP 또는 동일한 네트워크 오퍼레이터에 속하는 액세스 네트워크 노드(240) 및 로케이션 서버(170)를 기반으로 한 관계를 이용할 수 있으며 - 그리고 각각의 엔티티 내의 미리 구성된 보안 크리덴셜들을 이용하여 보안 연결의 설정을 가능하게 할 수 있다. 그 다음, 로케이션 서버(170)는 나중에 설명되는 바와 같이 로케이션 서버(170)로부터 UE(200)에 대한 로케이션를 획득하기 위해 (예컨대, OTT SP(150)에 의해) 나중에 사용될 수 있는 (예컨대, 로케이션 서버(170)에 로컬인 UE 레퍼런스를 포함할 수 있는) 로케이션 레퍼런스를 블록(208A)에서 할당하여 리턴할 수 있다.
[0083] 블록(208A)은 액세스 네트워크 노드(240)와 로케이션 서버(170) 사이에 새로운 인터페이스를 부가하지만, 이는 로케이션 서버(170)가 UE(200)와 상호작용하여 이를 인증할 필요성을 회피한다. 일부 실시예들에서, 액세스 네트워크 노드(240) 및 로케이션 서버(170)는 SIP, HELD, 또는 OMA(Open Mobile Alliance)에 의해 정의된 MLP(Mobile Location Protocol) 중 하나를 사용하여 208A에서 로케이션 레퍼런스를 요청하고 리턴할 수 있다. 212A에서, 액세스 네트워크 노드(240)는 로케이션 서버(170)로부터 획득된 로케이션 레퍼런스를 UE(200)에 전송한다. 일부 실시예들에서, UE(200)(예컨대, UE(200) 상의 모뎀)는 OTT 애플리케이션에 로케이션 레퍼런스를 제공할 수 있다.
[0084] 일부 실시예들에서는, UE(200)의 로케이션 레퍼런스에 대해 로케이션 서버(170)에 질의하기보다는, 본원에서 이전에 설명된 바와 같이 액세스 네트워크 노드(240)가 로케이션 서버(170)의 수반 없이 로케이션 레퍼런스 자체를 할당할 수 있다. 액세스 네트워크 노드(240)는 본원에서 또한 설명되는 바와 같이 로케이션 레퍼런스의 UE 레퍼런스 부분을 암호화하고 그리고/또는 로케이션 레퍼런스를 디지털로 서명할 수 있다. 이 경우, 임의의 암호/복호 키들 및/또는 디지털 시그니처에 대한 키들이 액세스 네트워크 노드(240)와 로케이션 서버(170) 모두에 알려질 수 있지만, 다른 측들에는 알려지지 않을 수 있다.
[0085] 206A, 208A 및 212A에서의 메시지들은 도 2a에 예시된 특정 시점들에 발생할 필요가 없기 때문에 이들은 도 2a에서 (파선들로 표시된) 선택적인 것으로 예시된다. 그보다는, 일예로, 206A 및 212A(그리고 선택적으로는 208A)는 202A에서의 어태치먼트 동안 그리고 어쩌면 204A에서 사용자가 긴급 호를 수행하기 전에, 이를테면 UE(200)가 액세스 네트워크 노드(240)에 성공적으로 어태치했고 인증된 직후에, 또는 UE(200)와 액세스 네트워크 노드(240) 사이의 어태치먼트 및/또는 인증 메시지 교환의 일부로서 수행될 수 있다. 예컨대, UE(200)는 액세스 네트워크 노드(240)에 전송된 메시지에 로케이션 레퍼런스에 대한 요청을 포함시켜, UE(200)의 어태치먼트 또는 UE의 인증(200)을 요청하거나 그에 응답하거나 이를 확인할 수 있다. 마찬가지로, 액세스 네트워크 노드(240)는 UE(200)에 전송된 메시지에 할당된 로케이션 레퍼런스에 대한 요청을 포함시켜, UE(200)의 어태치먼트 또는 UE의 인증(200)을 요청하거나 그에 응답하거나 이를 확인할 수 있다.
[0086] 다른 예로서, 206A 및 212A(그리고 선택적으로 208A)는 UE(200)가 액세스 네트워크 노드(240)에 어태치된 동안에는 주기적으로 수행될 수 있으며, 사용자가 긴급 호를 수행하는 것에 대한 응답으로는 수행되지 않을 수 있다. 예컨대, 206A, 212A 그리고 어쩌면 208A는 UE(200)와 액세스 네트워크 노드(240)가 UE(200)에 대한 이동성을 지원하기 위해 상호작용할 필요가 있을 때마다 수행될 수 있다. 다른 예에서, 206A, 212A 그리고 어쩌면 208A는 UE(200)가 새로운 액세스 네트워크 노드로 변경(예컨대, 이전 액세스 네트워크 노드에서 액세스 네트워크 노드(240)로 또는 액세스 네트워크 노드(240)에서 새로운 액세스 네트워크 노드로 변경)할 때마다 수행될 수 있다. 또 다른 예로서, 206A 및 212A는 UE(200)와 액세스 네트워크 노드(240) 사이의 다른 어떤 기존의 상호작용, 이를테면 LTE에 대한 추적 영역 업데이트 또는 GPRS 및/또는 UMTS에 대한 라우팅 영역 업데이트에 대응할 수 있다. 대안적으로, 도 2a에 예시된 바와 같이, 206A 및 212A는 로케이션 레퍼런스를 얻기 위해서만 사용되는 새로운 메시지들을 포함할 수 있다.
[0087] 일부 실시예들에서, 212A에서 UE(200)에 로케이션 레퍼런스를 전송하기 이전에, 액세스 네트워크 노드(240)는 UE(200)의 아이덴티티를 인증할 수 있다(도 2a에 도시되지 않음). 이러한 인증은 로케이션 레퍼런스가 212A에서 정확한 UE(200)에 리턴되는 것을 보장할 수 있다. 추가로, UE(200)의 이러한 인증은 액세스 네트워크 노드(240)에 의해 제공되는 서비스들(예컨대, 이를테면 UE(200)에 대한 네트워크 어태치먼트 및 이동성의 지원)에 대한 UE(200)에 의한 액세스를 지원하는 것의 통상적 부분을 형성할 수 있고, 단지 212A에서 로케이션 레퍼런스를 리턴하는 목적으로 UE(200) 또는 액세스 네트워크 노드(240)에 부가적인 영향들을 부가하지 않을 수 있다.
[0088] 214A에서, UE(200)는 UE(200)의 로케이션 레퍼런스를 포함하는 긴급 호 요청을 OTT SP(150)에 전송한다. 일부 실시예들에서, 긴급 호 요청은 UE(200)에 의해 액세스 네트워크 노드(240)를 통해 및/또는 액세스 네트워크 노드(240)에 대한 액세스 네트워크를 통해 OTT SP(150)에 전달될 수 있다. 도 2a에는 예시되지 않았지만, UE(200)는 제 1 네트워크 오퍼레이터(또한 로케이션 서버(170)를 소유할 수 있음)에 속하는 및/또는 제 1 RAT(radio access technology)를 준수하는 제 1 액세스 네트워크에 대한 액세스 네트워크 노드(240)로부터 로케이션 레퍼런스를 획득할 수 있고, 제 2 네트워크 오퍼레이터에 속하는 및/또는 제 2 RAT를 준수하는 제 2 액세스 네트워크를 통해 OTT SP(150)에 로케이션 레퍼런스를 포함하는 긴급 호 요청을 전송할 수 있다. 이러한 방식으로, 로케이션 레퍼런스는 다수의 액세스 네트워크들, 다수의 RAT들 및/또는 다수의 네트워크 오퍼레이터들간에 공유될 수 있고 그리고/또는 이들에 대해 유효할 수 있고, 새로운 RAT로의 또는 새로운 네트워크로의 핸드오프 이후 및/또는 몇몇 네트워크들 또는 몇몇 RAT들에 동시에 액세스하는 경우 UE(200)가 동일한 로케이션 레퍼런스를 사용하게 할 수 있다. 예컨대, UE(200)는 네트워크 오퍼레이터 A에 속하는 셀룰러 액세스 네트워크에 속하는 기지국 또는 다른 서빙 노드(예컨대, MME)로부터 로케이션 레퍼런스를 획득할 수 있고, 로케이션 레퍼런스를 포함하는 긴급 호 요청을, 네트워크 오퍼레이터 B에 속하는 WLAN 액세스 네트워크의 WiFi 액세스 포인트에 전송할 수 있고(여기서 오퍼레이터 A는 오퍼레이터 B와 동일할 수 있거나 동일하지 않을 수 있음), WiFi 액세스 포인트는 OTT SP(150)에 긴급 호 요청을 포워딩할 것이다.
[0089] 216A에서, OTT SP(150)는 214A에서 액세스 네트워크 노드(240)로부터 수신된 로케이션 레퍼런스를 포함하는 로케이션 요청(또는 로케이션 역참조 요청)을 로케이션 서버(170)에 전송한다. OTT SP(150)는 214A에서 수신된 로케이션 레퍼런스의 콘텐츠로부터 로케이션 서버(170)를 식별할 수 있다(예컨대, 로케이션 서버(170)에 대한 어드레스 또는 경로 이름을 식별할 수 있다). 로케이션 서버(170)는, 로케이션 레퍼런스가 로케이션 서버(170)에 의해 사전에 할당된(예컨대, 블록(208A)이 발생하는 경우 블록(208A)의 일부로서 할당된) 로케이션 레퍼런스에 대응하는 것을 검증함으로써, 216A에서 수신된 로케이션 레퍼런스가 유효한 것을 검증할 수 있다. 예컨대, 로케이션 서버(170)는 로케이션 레퍼런스의 UE 레퍼런스가 UE(200)를 식별하기 위해 로케이션 서버(170)에 의해 사전에 할당된 것을 검증할 수 있다. 대안적으로, 만약 (이를테면 블록(208A)이 존재하지 않은 경우 발생하는) 216A에서 수신된 로케이션 레퍼런스가 로케이션 서버(170)가 아닌 액세스 네트워크 노드(240)에 의해 할당되었다면, 로케이션 서버(170)는, 로케이션 레퍼런스에 존재하는 경우 임의의 디지털 서명을 검증함으로써 및/또는 로케이션 레퍼런스의 UE 레퍼런스 부분을 복호하고 복호된 UE 레퍼런스 부분이 유효한 UE 레퍼런스에 대한 임의의 포맷팅 또는 인코딩 규칙들을 정확하게 준수함을 검증함으로써, 액세스 네트워크 노드(240)가 로케이션 레퍼런스를 할당했음을 검증할 수 있다.
[0090] 218A에서, 로케이션 서버(170)(또는 로케이션 서버(170)가 LRF인 경우 로케이션 서버(170)와 연관되거나 그에 연결된 GMLC)는 UE(200)의 로케이션에 대한 로케이션 요청을 액세스 네트워크 노드(240)에 전송할 수 있고, (i) 208A가 발생하고 로케이션 서버(170)가 216A에서 수신된 로케이션 레퍼런스를 할당한 경우 208A에서 더 앞서 수신된 UE(200)에 대한 식별, 또는 (ii) 로케이션 서버(170)가 아닌 액세스 네트워크 노드(240)가 로케이션 레퍼런스를 할당한 경우 216A에서 로케이션 레퍼런스의 일부로서 수신된 복호된 UE 레퍼런스 또는 UE 레퍼런스의 일부 또는 전부일 수 있는 로케이션 요청에서 UE(200)에 대한 식별을 포함할 수 있다. 그 다음, 액세스 네트워크 노드(240)는 다른 엔티티(도 2a에는 미도시)로부터 (218A에서 로케이션 서버(170)에 의해 식별되는 바와 같은) UE(200)에 대한 로케이션 추정을 획득할 수 있다. 예컨대, 액세스 네트워크 노드(240)는 다른 로케이션 서버(예컨대, E-SMLC(172)) 또는 다른 로케이션 가능 엔티티(예컨대, RAN(120))로부터 또는 UE(200)를 서빙하는 기지국 또는 AP로부터 로케이션 추정을 요청할 수 있다. 대안적으로, 액세스 네트워크 노드(240)는 (예컨대, 액세스 네트워크 노드(240)가 UE(200)를 서빙하는 기지국 또는 WiFi AP인 경우) UE(200) 자체에 대한 로케이션 정보를 이미 가질 수 있다. 그 다음, 액세스 네트워크 노드(240)는 218A의 일부로서 UE(200)에 대한 로케이션 추정을 로케이션 서버(170)(또는 로케이션 서버(170)가 LRF인 경우 로케이션 서버(170)와 연관된 또는 그에 연결된 GMLC)에 리턴할 수 있다. 일부 실시예들에서, 블록(218A)은 로케이션 서버(170)가 UE(200)의 로케이션을 획득하기 위해 제어 평면 로케이션 솔루션을 이용하는 경우 발생할 수 있다.
[0091] 218A에서 UE(200)의 로케이션에 대해 액세스 네트워크 노드(240)에 질의하는 것 대신에 또는 그에 부가하여, 로케이션 서버(170)는 222A에서 직접 UE(200)에 질의할 수 있다. 예컨대, 222A는 로케이션 서버(170)가 SUPL SLP 또는 SLP에 연결되거나 그와 연관된 LRF인 경우 발생할 수 있고, 여기서 SLP는, 로케이션 서버(170)가 UE(200)에 대한 로케이션을 결정하기 위해 사용할 수 있는 UE(200)로부터의 로케이션 관련 측정들(예컨대, GPS 또는 GNSS 위성들의 측정들 및/또는 UE(200)에 대한 액세스 네트워크의 기지국들 및/또는 AP들의 측정들)을 획득하기 위해 222A에서 UE(200)과의 SUPL 사용자 평면 로케이션 세션을 착수한다. 예컨대, UE(200)는 GPS 및 OTDOA(Observed Time Difference Of Arrival) 측정들을 로케이션 서버(170)에 제공할 수 있다. OTDOA는, UE(200)가 기지국들의 쌍들로부터의 특정 신호들간의 시간차를 측정하고, 측정된 시간차들을 로케이션 서버(170)에 보고하고, 그 다음 로케이션 서버(170)가 UE(200)의 로케이션을 컴퓨팅하는 다변측량 방법이다. 대안적으로, 로케이션 서버(170)(또는 로케이션 서버(170)가 LRF인 경우 로케이션 서버(170)와 연관되거나 그에 연결된 SLP)는 UE(200)로부터 UE(200)의 로케이션을 획득하기 위해 222A에서 UE(200)와의 SUPL 세션을 착수할 수 있고, 여기서 UE(200)는 로케이션 관련 측정들, 이를테면 GPS, GNSS 및/또는 OTDOA 측정들로부터 로케이션을 획득한다. 224A에서, 로케이션 서버(170)는 218A 및/또는 222A에서 획득된 바와 같은 UE(200)의 로케이션을 OTT SP(150)에 전송한다. 일부 실시예들에서, OTT SP(150) 및 로케이션 서버(170)는 UE(200)의 로케이션을 요청 및 리턴하기 위해 216A 및 224A에서 SIP, HELD 또는 MLP 중 하나를 이용할 수 있다. SIP 또는 HELD가 사용되는 이러한 실시예들 중 일부에서, SIP 또는 HELD의 사용은 로케이션 레퍼런스의 일부로서 정의될 수 있다.
[0092] 216A 내지 224A에서의 메시지 흐름들은, OTT SP(150)가 (예컨대, UE(200)의 로케이션을 포함하는 긴급 서비스 커버리지를 갖는 PSAP(180)를 결정함으로써) 긴급 호의 라우팅을 보조하기 위해 UE(200)의 로케이션을 획득하도록 및/또는 UE(200)의 로케이션을 ESInet(160) 또는 PSAP(180)에 제공하도록 하기 위해 도 2a에 예시된 시간들에 발생할 수 있다. 216A 내지 224A에서의 메시지 흐름들은 선택적인데, 이는, 이들이 대안적으로 또는 부가적으로, UE(200)의 현재 로케이션을 획득 및 리턴하기 위해(도 2a에는 미도시) OTT SP(150)가 PSAP(180)로부터 UE(200)에 대한 로케이션 요청을 수신하고 로케이션 서버(170)에 질의할 필요가 있는 경우, 204A에서 개시된 긴급 호가 셋업된 후(즉, 228A 후) 발생할 수 있기 때문이다. 또한, 216A 내지 224A와 유사한 메시지 흐름들은 ESInet(160) 또는 PSAP(180)가 (216A 내지 224A에서의 메시지 흐름들 대신에 또는 그에 부가적으로) 로케이션 서버(170)로부터 UE(200)의 로케이션을 직접 요청할 수 있게 하기 위해 발생할 수 있다. 이러한 유사한 메시지 흐름들은, 216A에서 로케이션 요청을 전송하고 224A에서 로케이션 응답을 수신하는 측면에서 ESInet(160) 또는 PSAP(180)가 메시지 흐름들의 OTT SP(150)를 대체할 수 있다는 점을 제외하고는 216A 내지 224A와 동일하거나 거의 동일할 수 있다.
[0093] 도 2a에 도시된 긴급 서비스 호를 다시 참조하면, 226A에서, OTT SP(150)는 긴급 호를 적합한 ESInet(160)에, 또는 어쩌면, OTT SP가 호를 CS 긴급 호로 변환한 경우에는 SR(160)에 라우팅한다. ESInet(160)(또는 SR(160))는 긴급 호를 적합한 PSAP(180)에 라우팅한다. 226A에서 전송된 긴급 호 요청들은 214A에서 획득된 UE(200)의 로케이션 레퍼런스를 포함할 수 있다. OTT SP(150)는 204A에서 개시된 긴급 호를 적합한 ESInet(160)(또는 SR(160))에 라우팅하기 위해, 수행된다면, 224A에서 획득된 UE(200)의 로케이션을 사용할 수 있다. ESInet(160)는 이미 설명된 바와 같이, 216A 내지 224A와 유사한 단계들을 수행함으로써 로케이션 서버(170)로부터 UE(200)에 대한 로케이션을 획득하기 위해, 긴급 호 요청에서 수신된 UE(200)의 로케이션 레퍼런스를 사용할 수 있다. 그 다음, ESInet(160)는 긴급 호를 적합한 PSAP(180)에 라우팅하기 위해 이러한 획득된 로케이션을 사용할 수 있다.
[0094] 228A에서, 다양한 네트워크 엔티티들(예컨대, UE(200), OTT SP(150), ESInet(160) 및 PSAP(180))은 긴급 호 설정의 나머지를 수행한다. 232A에서, PSAP(180)는 226A에서 수신된 로케이션 레퍼런스를 포함하는 로케이션 요청을 로케이션 서버(170)에 전송한다. 로케이션 서버(170)는 UE(200)의 로케이션을 룩업(예컨대, 218A 및/또는 222A에서 사전에 획득된 로케이션을 룩업)하기 위해 로케이션 레퍼런스를 사용하고, UE(200)의 로케이션으로 응답한다. 대안적으로, 로케이션 서버(170)는 218A 및/또는 222A에 예시된 것과 동일한 단계들(도 2a에는 미도시)을 수행함으로써 UE(200)의 로케이션을 획득할 수 있다.
[0095] 도 1b를 다시 참조하면, 도 2b는 본원에 설명된 실시예들에 따른 OTT 긴급 호에 대한 레퍼런스에 의해 로케이션을 제공하기 위한 도 1b에 예시된 엔티티들의 특정 상호작용들을 예시한다. 도 2b의 상호작용들은 도 2a에 대해 설명된 것과 유사하지만, 구체적으로 LTE 액세스를 갖는 UE(200)를 참조한다. 대조적으로, 도 2a와 연관하여 설명된 상호작용들은 LTE 액세스를 포함하지만 이에 한정되는 것은 아닌 임의의 타입의 무선 또는 유선 액세스를 갖는 UE(200)에 적용될 수 있다.
[0096] 202B에서, UE(200)는 LTE 가능 서빙 네트워크에 어태치하고, 어태치먼트 절차의 일부로서 서빙 MME(142)에 NAS 어태치 요청을 전송한다. NAS 어태치 요청은 일부 실시예들에서 로케이션 레퍼런스에 대한 요청을 포함한다. 204B에서, MME(142)는 선택적으로, 로케이션 레퍼런스 요청을 GMLC/SLP(170)에 전송할 수 있다. GMLC/SLP(170)는 UE(200)의 로케이션이 제어 평면 로케이션 솔루션을 사용하여 획득될 경우 GMLC일 수 있거나, UE(200)의 로케이션이 SUPL을 사용하여 획득될 경우 SLP일 수 있거나, UE(200)에 대한 로케이션을 획득하기 위해 제어 평면 로케이션 및 SUPL 중 하나 또는 둘 모두가 사용될 경우 조합된 GMLC 및 SLP일 수 있거나, 또는 GMLC 및/또는 SLP에 연결된 또는 그와 연관된 LRF일 수 있다. 204B가 수행되는 경우, MME(142)는 UE(200)를 대신하여 GMLC/SLP(170)로부터 로케이션 레퍼런스를 획득하기 위한 프록시로서 작용한다. 이것은 MME(142)와 GMLC/SLP(170)간에 새로운 인터페이스를 부가하지만, UE(200)가 GMLC/SLP(170)로부터 로케이션 레퍼런스를 획득할 필요성을 회피하게 하고, GMLC/SLP(170)가 로케이션 레퍼런스를 획득하기 위해 UE(200)로부터의 요청의 일부로서 UE(200)를 인증할 필요성을 회피하게 한다.
[0097] 단계(204B)의 요청/응답은 GMLC/SLP(170)가 (예컨대, GMLC/SLP(170)에 관한 동일한 오퍼레이터 또는 SP에 속하는) MME가 로케이션 레퍼런스를 요청하고 있음을 인지할 수 있게 하는 GMLC/SLP(170)와 MME(142)간의 보안 연결을 사용할 수 있다. GMLC/SLP(170)와 MME(142)간의 보안 연결은 GMLC/SLP(170)와 MME(142)간의 신뢰 관계, 예컨대 동일한 SP 또는 동일한 네트워크 오퍼레이터에 속하는 MME(142) 및 GMLC/SLP(170)에 기반한 관계를 이용할 수 있고, 보안 연결의 설정을 가능하게 하기 위해 각각의 엔티티에서 미리 구성된 보안 크리덴셜들을 이용할 수 있다. 그 다음, GMLC/SLP(170)는, 추후에 예컨대, 아래에서 설명되는 블록들(214B 및 232B)에서 GMLC/SLP(170)가 UE(200)에 대한 로케이션을 다른 엔티티에 제공하도록 허용할 (예컨대, GMLC/SLP(170)에 로컬인 UE 레퍼런스를 포함할 수 있는) 로케이션 레퍼런스를 할당 및 리턴할 수 있다. 일부 실시예들에서, MME(142) 및 GMLC/SLP(170)는 204B에서 로케이션 레퍼런스를 요청 및 리턴하기 위해 OMA에 의해 정의되는 SIP, HELD 또는 MLP(Mobile Location Protocol) 중 하나를 사용할 수 있다.
[0098] 206B에서, MME(142)는 GMLC/SLP(170)로부터 획득된 로케이션 레퍼런스를 NAS 어태치 수용 메시지를 통해 UE(200)에 전송한다. 202B에서의 NAS 어태치 요청 및 206B에서의 NAS 어태치 수용은, NAS 어태치 요청의 로케이션 레퍼런스 요청 파라미터 및/또는 NAS 어태치 수용의 로케이션 레퍼런스 파라미터의 부가로, 3GPP TS 23.401 및 TS 24.301에서 정의된 바와 같을 수 있다. 일부 실시예들에서, 블록들(204B 및 206B)은 오직, 202B에서의 NAS 어태치 요청이 로케이션 레퍼런스에 대한 요청을 포함하는 경우 수행될 수 있다. 다른 실시예들에서, 블록들(204B 및 206B)은 202B에서의 NAS 접속 요청이 로케이션 레퍼런스에 대한 요청을 포함하지 않는 경우 수행될 수 있다.
[0099] 대안적으로, 204B에서 UE(200)의 로케이션 레퍼런스에 대해 GMLC/SLP(170)에 질의하기 보다는, MME(142)는 위에서 설명된 바와 같이 GMLC/SLP(170)의 수반없이 스스로 로케이션 레퍼런스를 할당할 수 있다. MME(142)는 로케이션 레퍼런스에서 GMLC/SLP(170)의 공지된 어드레스, 클라이언트로부터 GMLC/SLP(170)를 질의하기 위해 사용될 프로토콜에 대한 식별 및 UE(200)를 식별하기 위한 UE 레퍼런스(예컨대, UE(200)의 IP 어드레스, UE(200)의 IMSI, UE(200)의 TMSI, MME(142)에 의해 할당된 UE(200)에 대한 로컬 어드레스, MME(142)의 어드레스 또는 이들의 임의의 조합)를 포함할 수 있다. MME(142)는 사용자 프라이버시를 보호하기 위해 UE 레퍼런스를 암호화할 수 있다. 이러한 경우, 암호화 키들은 MME(142) 및 GMLC/SLP(170)에 공지될 것이지만, 다른 측들에게는 공지되지 않을 것이다. MME(142)는 또한 로케이션 레퍼런스를 디지털로 서명할 수 있어서, GMLC/SLP(170)는, 로케이션 레퍼런스가 MME(142)에 의해 할당된 것, 또는 적어도 GMLC/SLP(170)에 대한 오퍼레이터 또는 SP에 의해 관리되는 어떠한 엔티티에 의해 할당된 것을 알 것이다.
[00100] 206B에서 로케이션 레퍼런스를 획득하는 것에 부가적으로 또는 대신에, UE(200)는, 도 2a를 참조하여 위에서 논의된 바와 같이, UE(200)의 사용자가 긴급 호를 개시(208B)한 후에, 주기적으로 UE(200)가 MME(142)에 어태치된 동안에, 및/또는 UE(200)와 MME(142) 사이의 몇몇의 다른 상호작용 동안에 로케이션 레퍼런스를 획득할 수 있다.
[00101] 로케이션 레퍼런스를 획득하기 위해 202B에서 NAS 어태치 요청 및 206B에서 NAS 어태치 수용을 전송하는 것 대신에, UE(200)는 202B에서 NAS 추적 영역 업데이트 요청을 전송할 수 있고, 로케이션 레퍼런스를 (예컨대, 204B에서) 획득 또는 할당한 후에, MME(142)는 로케이션 레퍼런스를 포함하는 NAS 추적 영역 업데이트 수용을 206B에서 전송할 수 있다. 202B에서 NAS 추적 영역 업데이트 요청 및 206B에서 NAS 추적 영역 업데이트 수용은 NAS 추적 영역 업데이트 요청 내의 로케이션 레퍼런스 요청 및/또는 NAS 추적 영역 업데이트 수용 내의 로케이션 레퍼런스의 부가와 함께 3GPP TS 23.401 및 TS 24.301에 정의된 바와 같을 수 있다.
[00102] 일부 실시예들에서, 206B에서 NAS 어태치 수용 또는 NAS 추적 영역 업데이트 수용에서 로케이션 레퍼런스를 UE(200)로 전송하기 이전에, MME(142)는 UE(200)의 아이덴티티(도 2b에 도시되지 않음)를 인증할 수 있다. 그러한 인증은 로케이션 레퍼런스가 206B에서 정확한 UE(200)로 리턴되는 것을 보장할 수 있다. 또한, UE(200)의 그러한 인증은 UE(200) 및 MME(142)에 의한 UE(200) 어태치먼트 또는 UE(200) 추적 영역 업데이트를 지원하는 정상 부분을 형성할 수 있고, 어떠한 것도 206B에서 단지 로케이션 레퍼런스를 리턴할 목적으로 부가적인 영향들을 UE(200) 또는 MME(142)에 부가하지 않을 수 있다.
[00103] LTE 대신에 GSM 또는 UMTS를 지원하는 액세스 네트워크들에 대해, 도 2b의 절차는 LTE 네트워크에 대해 본원에 설명되지만 GSM 또는 UMTS RAN에 의해 대체된 E-SMLC(172) 및 SGSN(Serving GPRS Support Node)에 의해 대체된 MME(142)를 통해 OTT 긴급 호를 지원하는데 사용될 수 있다. 그 경우에, UE(200)는 로케이션 레퍼런스에 대한 요청을 포함할 수 있는 GPRS 어태치 요청 또는 GPRS 라우팅 영역 업데이트 요청 중 어느 하나를 202B에서 SGSN으로 전송할 것이고, SGSN은 206B에서 GPRS 어태치 수용 또는 GPRS 라우팅 영역 업데이트 수용 중 어느 하나로 각각 응답할 것이다. 이러한 경우에, 202B에서 GPRS 어태치 요청 또는 GPRS 라우팅 영역 업데이트 요청 및 206B에서 GPRS 어태치 수용 또는 GPRS 라우팅 영역 업데이트 수용은, GPRS 어태치 요청 또는 GPRS 라우팅 영역 업데이트 요청에서 로케이션 레퍼런스 요청 및/또는 GPRS 어태치 수용 또는 GPRS 라우팅 영역 업데이트 요청에서 로케이션 레퍼런스의 부가를 통해, 3GPP TS 24.008에 정의된 바와 같을 수 있다.
[00104] 208B에서, UE(200)의 사용자는 UE(200) 상에 설치된 OTT 애플리케이션, 이를테면, Skype™을 통해 긴급 호를 수행할 수 있다. 212B에서, UE(200)는 206B에서 획득된 로케이션 레퍼런스를 비롯하여 긴급 호 요청을 OTT SP(150)로 전송한다. 예컨대, UE(200)는 eNB(124), S-GW(146), PDG(148) 및 인터넷(175)을 통해 긴급 호 요청을 OTT SP(150)로 전송할 수 있다. 실시예에서, UE(200)는 위에서 설명된 바와 같이 MME(142)로부터 로케이션 레퍼런스를 획득하고, MME(142)를 포함하고 GMLC/SLP(170)와 연관된 액세스 네트워크와 상이한 액세스 네트워크를 통해 212B에서 로케이션 레퍼런스를 포함하는 긴급 호 요청을 OTT SP(150)로 전송할 수 있다. 예컨대, 상이한 액세스 네트워크는 LTE와 상이한 RAT(예컨대, WiFi)를 지원할 수 있다. 그러한 방식으로, 로케이션 레퍼런스는 상이한 액세스 네트워크들 사이에서 그리고 어쩌면 UE(200)에서 상이한 RAT들 사이에서 공유될 수 있다. 예컨대, UE(200)는 로케이션 레퍼런스를 비롯하여 긴급 호 요청을 WLAN 액세스 포인트를 통해 OTT SP(150)로 전송할 수 있다.
[00105] 214B에서, OTT SP(150)는, 212B에서 획득된 로케이션 레퍼런스를 비롯하여, 로케이션 요청을 GMLC/SLP(170)로 전송한다. OTT SP(150)는 212B에서 수신된 로케이션 레퍼런스의 콘텐츠로부터 GMLC/SLP(170)를 식별할 수 있다(예컨대, GMLC/SLP(170)에 대한 어드레스 또는 경로 이름을 식별함). GMLC/SLP(170)는, 로케이션 레퍼런스가 GMLC/SLP(170)에 의해 이전에 할당된(예컨대, 블록(204B)이 발생하면, 블록(204B)의 부분으로서 할당된) 로케이션 레퍼런스에 대응한다는 것을 검증함으로써, 214B에서 수신된 로케이션 레퍼런스가 유효하다고 검증할 수 있다. 예컨대, GMLC/SLP(170)는 로케이션 레퍼런스 내의 UE 레퍼런스가 UE(200)를 식별하기 위해 GMLC/SLP(170)에 의해 이전에 할당되었다는 것을 검증할 수 있다. 대안적으로, 214B에서 수신된 로케이션 레퍼런스가 GMLC/SLP(170)가 아닌 MME(142)에 의해 할당되었다면(예컨대, 이를테면 블록(204B)이 존재하지 않는다면 발생함), GMLC/SLP(170)는, (i) 로케이션 레퍼런스에 존재하는 경우 임의의 디지털 시그니처를 검증하고, (ii) 로케이션 레퍼런스의 UE 레퍼런스 부분을 복호화하고 복호화된 UE 레퍼런스 부분이 유효한 UE 레퍼런스에 대한 임의의 포맷팅 또는 인코딩 규칙들을 정확히 준수한다는 것을 검증하고, 그리고/또는 (iii) 로케이션 레퍼런스가 알려진 포맷팅 규칙들을 준수한다는 것(예컨대, 길이 및/또는 문자 콘텐츠가 알려진 규칙들을 준수하는 UE 레퍼런스를 포함함)을 검증함으로써, MME(142)가 로케이션 레퍼런스를 할당하였다는 것을 검증할 수 있다.
[00106] 제어 평면 로케이션 솔루션이 활용되면(GMLC/SLP(170)가 GMLC이거나 이를 포함하거나 또는 GMLC에 연결되거나 이와 연관된 LRF이라는 것을 의미함), (파선 박스에 의해 표시된 바와 같이) 216B에서 226B로의 메시지 흐름들이 수행된다. 상세하게, 216B에서, GMLC(170)는 UE(200)에 대한 로케이션 요청을 MME(142)로 전송한다. GMLC(170)는 (예컨대, MME(142) 또는 GMLC(170)가 MME(142) 어드레스 또는 아이덴티티를 로케이션 레퍼런스에 포함하였다면) 214B에서 수신된 로케이션 레퍼런스 내의 UE 레퍼런스의 콘텐츠로부터 216B에서 요청을 정확히 전송하기 위해 MME(142)의 어드레스 또는 아이덴티티를 결정할 수 있다. 대안적으로, GMLC(170)는 로케이션 레퍼런스의 UE 레퍼런스 부분을 통해 214B에서 수신된 UE(200)에 대한 식별자(예컨대, IMSI)를 사용하여 MME(142)의 어드레스(도 2b에 도시되지 않음)에 대해 UE(200)에 대한 HSS(Home Subscriber Server)에 질의할 수 있다. GMLC는, 214B에서 수신된 로케이션 레퍼런스의 UE 레퍼런스 부분에 포함되었거나 또는 GMLC(170)가 로케이션 레퍼런스를 할당하는 경우 204B에서 이전에 수신되어 GMLC(170)에 의해 저장된, 216B에서 전송된 로케이션 요청에 UE(200)에 대한 아이덴티티를 포함한다.
[00107] 218B에서, MME(142)는 UE(200)에 대한 로케이션 요청을 E-SMLC(172)로 전송하고, 216B에서 수신되거나 이미 MME(142)에 알려진 UE(200)에 대한 임의의 아이덴티티를 포함할 수 있다. 222B에서, E-SMLC(172)는 UE(200)와 3GPP LPP(LTE Positioning Protocol) 로케이션 세션을 착수하고, 이러한 세션의 부분으로서 로케이션 정보로 응답하는 UE(200)에 로케이션 요청을 전송할 수 있다. UE(200)에 의해 제공된 로케이션 정보는 GPS 로케이션 측정들, GNSS 로케이션 측정들, OTDOA 측정들, ECID(Enhanced Cell ID) 측정들, WiFi 로케이션 측정들, BT(Bluetooth) 로케이션 측정들 또는 이들의 임의의 조합을 포함할 수 있거나, UE(200)에 의해 획득된 UE(200)에 대한 로케이션 추정을 포함할 수 있다. 로케이션 정보가 로케이션 추정이 아닌 로케이션 측정들을 포함할 때, E-SMLC(172)는 이들 측정들로부터 UE(200)에 대한 로케이션 추정을 컴퓨팅할 수 있다. 222B 대신에 또는 부가적으로, E-SMLC(172)는, E-SMLC(172)가 UE(200)에 대한 로케이션 추정을 결정할 수 있는 로케이션 추정 또는 측정들을 획득하기 위해, 로케이션 요청(도 2b에 도시되지 않음)을 UE(200)에 대한 서빙 eNB(예컨대, 도 2b의 eNB(124))에 전송할 수 있다. 224B에서, E-SMLC(172)는, UE(200)의 로케이션을 비롯하여, 로케이션 응답을 MME(142)에 전송할 수 있다. 226B에서, MME(142)는, 224B에서 수신된 UE(200)의 로케이션을 비롯하여, 로케이션 응답을 GMLC(170)에 전송한다.
[00108] 대안적으로, SUPL 사용자 평면 로케이션 솔루션이 활용되면(GMLC/SLP(170)가 SLP이거나 이를 포함하거나 또는 SLP와 연관되거나 이에 연결된 LRF이라는 것을 의미함), 216B에서 226B로의 메시지 흐름들이 수행되지 않을 수 있고, 대신에(또는 어쩌면 부가적으로) SUPL 세션이 228B에서 SLP(170)와 UE(200) 사이에 설정된다. SLP(170)는 (예컨대, UE(200)에 의해 획득된 GPS, GNSS, OTDOA, ECID, WiFi 및/또는 BT 측정들로부터) SUPL 세션을 통해 UE(200)의 로케이션을 획득할 수 있다. 216B에서 228B로의 메시지 흐름들은 파선들로 예시되는데, 왜냐하면 일부 실시예들에서 216B에서 226B로의 메시지 흐름들이 수행되거나 228B에서의 메시지 흐름이 수행되지만 둘 모두가 수행되지는 않기 때문이다. 232B에서, GMLC/SLP(170)는 UE(200)의 로케이션 추정을 OTT SP(150)에 전송한다.
[00109] 214B에서 232B로의 메시지 흐름들(예컨대, (a) 214B 내지 226B 및 232B 또는 (b) 214B, 228B 및 232B 중 어느 하나)은 (예컨대, UE(200)의 로케이션을 포함하는 긴급 서비스 커버리지를 갖는 PSAP(180)를 결정함으로써) 긴급 호를 라우팅하는 것을 돕도록 OTT SP(150)가 UE(200)의 로케이션을 획득하고 그리고/또는 UE(200)의 로케이션을 ESInet(160) 또는 PSAP(180)에 제공하는 것을 가능하게 하기 위해 도 2b에 예시된 시간들에서 발생할 수 있다. 214B에서 232B로의 메시지 흐름들은, 대안적으로 또는 부가적으로, OTT SP(150)가 PSAP(180)로부터 UE(200)에 대한 로케이션 요청을 수신하고 UE(200)의 현재 로케이션(도 2b에 도시되지 않음)을 획득하고 이를 리턴하기 위해 GMLC/SLP(170)에 질의할 필요가 있다면, 208B에서 개시된 긴급 호가 셋업된 후에(즉, 236B 후에) 발생할 수 있다. 부가적으로, 214B 내지 232B와 유사한 메시지 흐름들은 ESInet(160) 또는 PSAP(180)가 GMLC/SLP(170)로부터 UE(200)의 로케이션을 직접적으로 요청하는 것을 가능하게 하기 위해 (214B에서 232B로의 메시지 흐름들 대신에 또는 부가적으로) 발생할 수 있다. 이들 유사한 메시지 흐름들은, ESInet(160) 또는 PSAP(180)가 214B에서 로케이션 요청을 전송하고 232B에서 로케이션 응답을 수신하는 측면에서 메시지 흐름들에서 OTT SP(150)를 대체할 수 있다는 것을 제외하면 214B 내지 232B와 동일하거나 거의 동일할 수 있다.
[00110] 도 2b에 도시된 긴급 서비스 호를 참조하면, 234B에서, OTT SP(150)는, OTT SP(150)가 호를 CS 긴급 호로 변환할 필요가 있다면, 긴급 호를 적합한 ESInet(160) 또는 가능하게는 SR(160)로 라우팅한다. 이어서, ESInet(160)(또는 SR(160))는 긴급 호를 적합한 PSAP(180)로 라우팅한다. 234B에서 전송된 이들 긴급 호 요청들은 212B에서 획득된 UE(200)의 로케이션 레퍼런스를 포함할 수 있다. OTT SP(150)는, 수행되면, 208B에서 개시된 긴급 호를 적합한 ESInet(160)(또는 SR(160))로 라우팅하기 위해, 232B에서 획득된 UE(200)의 로케이션을 사용할 수 있다. ESInet(160)는, 위에서 설명된 바와 같이 214B 내지 232B와 유사한 블록들을 수행함으로써 GMLC/SLP(170)로부터 UE(200)에 대한 로케이션을 획득하기 위해 긴급 호 요청으로 수신된 UE(200)의 로케이션 레퍼런스를 사용할 수 있다. 이어서, ESInet(160)는 긴급 호를 적합한 PSAP(180)로 라우팅하기 위해 이러한 획득된 로케이션을 사용할 수 있다.
[00111] 236B에서, 다양한 네트워크 엔티티들(예컨대, UE(200), OTT SP(150), ESInet(160) 및 PSAP(180))은 긴급 호 설정의 나머지를 수행한다. 238B에서, PSAP(180)는, 234B에서 수신된 로케이션 레퍼런스를 비롯하여, 로케이션 요청을 GMLC/SLP(170)에 전송한다. GMLC/SLP(170)는 UE(200)의 로케이션을 룩업(예컨대, 226B 및/또는 228B에서 이전에 획득된 로케이션을 룩업)하기 위해 로케이션 레퍼런스를 사용하고, UE(200)의 로케이션으로 응답한다. 대안적으로, GMLC/SLP(170)는 216B 내지 226B 및/또는 228B에 예시된 단계들과 동일한 단계들(도 2b에 도시되지 않음)을 수행함으로써 UE(200)의 로케이션을 획득할 수 있다.
[00112] 도 3은 본 개시내용의 적어도 하나의 양상에 따른, 대안적인 로케이션 솔루션들을 도시하는 OTT 서비스 제공자를 통해 긴급 서비스들을 제공하기 위한 예시적인 아키텍처를 예시한다. 도 3에 예시된 아키텍처는 UE(300)(UE(200)에 대응할 수 있음), 액세스 네트워크(320)(RAN(120)에 대응할 수 있음), 패킷 코어 네트워크(340)(코어 네트워크(140)에 대응할 수 있음), OTT SP(350)(OTT SP(150)에 대응할 수 있음), ESInet/SR(360)(ESInet/SR(160)에 대응할 수 있음), ELS(emergency location server)(370)(E-SMLC(172), GMLC/SLP(170) 또는 로케이션 서버(170)에 대응할 수 있음), IP 네트워크(375)(인터넷(175)에 대응할 수 있음), UE(300)에 대한 홈 네트워크일 수 있는 홈 네트워크(385) 및 PSAP(380)(PASP(180)에 대응할 수 있음)를 포함한다.
[00113] 도 3은 긴급 서비스(예컨대, 긴급 음성 호, 긴급 텍스트 메시지 세션)를 호출한 UE(300)의 로케이션을 OTT SP(350)로 또는 이로부터 전달하기 위한, S1, S2, S3, S3a, S3b, S4 및 S5로 라벨링된 다양한 대안적인 솔루션들을 도시한다. 각각의 솔루션에 대해, OTT SP는 긴급 서비스 호의 호출 및 긴급 서비스 네트워크로(예컨대, ESInet로 또는 직접적으로 PSAP로)의 라우팅을 담당할 수 있다.
[00114] 솔루션 S1에 대해, UE(300)는 OTT SP(350)로 라우팅(및 어쩌면 디스패치)하기에 적절한 로케이션을 푸시할 수 있다. 로케이션은 LbyV(location by value) 또는 LbyR(location by reference) 중 어느 하나일 수 있고, 로케이션 서버(예컨대, ELS(370))로부터 획득될 수 있거나, 값에 의한 로케이션의 경우에 UE(300)에 의해 단독으로 결정될 수 있다. 레퍼런스에 의한 로케이션 경우에, UE(300)는 로케이션 레퍼런스에 대한 요청을 로케이션 서버로 전송하고, 이어서 수신된 로케이션 레퍼런스(로케이션 URI 형태)를 OTT SP(350)에 전송할 수 있다. 이어서, OTT SP(350)는 로케이션 URI를 할당한 로케이션 서버(예컨대, ELS(370))로부터 로케이션 값을 요청함으로써 (예컨대, HELD를 사용하여) 역참조를 수행할 수 있다.
[00115] 솔루션 S2의 경우에, OTT SP(350)는, 예컨대, SIP INVITE 메시지를 통해 UE(300)로부터 긴급 서비스 호 호출을 수신한 후에, UE(300)의 로케이션에 대해 UE(300)에 질의할 수 있다. 질의는 인-서비스 시그널링(예컨대 SIP INFO 메시지를 통한 요청) 또는 아웃-오브-서비스 시그널링(예컨대, 별개의 데이터 또는 시그널링 경로를 통한 요청)을 사용할 수 있다. UE(300)는 요청과 유사한 수단, 예컨대, 요청이 통화중(in-call) 시그널링을 사용하였다면, 통화중 시그널링을 사용하여 로케이션을 OTT SP(350)로 리턴할 수 있다. 리턴되는 로케이션 정보는, 솔루션 S1에 대해, 예컨대, LByV 또는 LbyR 중 어느 하나와 동일할 수 있다.
[00116] 솔루션 S3의 경우에, (예컨대, SIP INVITE를 통해) UE(300)로부터 긴급 서비스 호 호출을 수신한 후에, OTT SP(350)는, 예컨대, 어떠한 것이 액세스 네트워크(320) 또는 PCN(340) 내에 있거나 이와 연관될 수 있는지를 ELS(370)에 질의할 수 있다. OTT SP(350)는, 일부 경우들에서, UE의 IP 어드레스 또는 UE(300)에 의해 OTT SP(350)에 제공된 PCN(340) 또는 액세스 네트워크(320)에 대한 식별자를 사용하여 액세스 네트워크(320), PCN(340) 및/또는 ELS(370)를 결정할 수 있다. 예컨대, IP 어드레스의 경우에, 알려진 범위들의 IP 어드레스들 또는 IP 어드레스 내의 특정 서브-필드들은 (예컨대, 호 서버에서) OTT SP(350)에 의해 구성되고, 특정 액세스 네트워크들 및 PCN들로 맵핑될 수 있다. 솔루션 S3의 변형들 S3a 및 S3b에서, OTT SP(350)는 로케이션 서버(예컨대, ELS(370))로의 온워드 포워딩을 위해 UE(300)에 대한 로케이션 요청을 액세스 네트워크(320) 및 PCN(340)으로 각각 전송할 수 있다.
[00117] 솔루션(S4)에서, UE(300)로부터 긴급 서비스 호 호출을 (예컨대, SIP INVITE를 통해) 수신한 후에, OTT SP(350)는 UE(300)에 대한 홈 네트워크(385)의 로케이션 서버 또는 로케이션 서비스에 질의할 수 있다. UE(300)는 글로벌 공중 아이덴티티(예컨대, SIP URI, MSISDN 등)를 사용하여 참조될 수 있다. OTT SP(350)는 글로벌 공중 아이덴티티를 사용하여 홈 네트워크(385) 및 홈 네트워크(385)의 로케이션 서버 또는 로케이션 서비스를 결정할 수 있다. 홈 네트워크(385)는 (예컨대, 로밍을 지원하기 위해 PCN(340)으로부터 수신된 정보로부터) UE(300)의 일반적인 로케이션을 알 수 있고 그리고/또는 UE(300)를 직접 (예컨대, SUPL을 사용하여) 로케이팅할 수 있다.
[00118] 솔루션(S5)에서, PSAP(380) 또는 ESInet/SR(360)은 라우팅 또는 디스패치에 필요한 UE(300)의 로케이션에 대해 OTT SP(350)에 질의할 수 있다. OTT SP(350)는 UE(300)에 대한 값에 의한 로케이션(예컨대, 지리적 로케이션 또는 도시 로케이션) 또는 UE(300)에 대한 레퍼런스에 의한 로케이션을 획득하도록 다른 솔루션 대안들(S1, S2, S3, S3a, S3b, S4) 중 하나를 사용하고, 그 후 PSAP(380) 또는 ESInet/SR(360)에 이를 리턴할 수 있다. 레퍼런스에 의한 로케이션이 리턴되면, PSAP(380) 또는 ESInet/SR(360)은 UE(300)의 로케이션을 획득하기 위해 액세스 네트워크(320) 또는 PCN(340)에서 레퍼런스에 의한 로케이션을 할당한 로케이션 서버(예컨대, ELS(370))에 질의할 필요가 있을 것이다.
[00119] 도 1a, 1b, 2a 및 2b와 연관하여 사전에 설명된 레퍼런스에 의한 로케이션 솔루션들은 도 3에 대해 사전에 설명된 솔루션들(S1, S2 및 S5)과 조합하여 이용될 수 있다. 이러한 레퍼런스에 의한 로케이션 솔루션들은 사전에 설명된 바와 같이 로케이션 레퍼런스를 획득하기 위해 로케이션 서버(170) 및 ELS(370)와 같은 로케이션 서버에 대한 그리고 UE(200) 및 UE(300)와 같은 UE에 대한 영향을 감소시킬 수 있다. 그러나, 솔루션들은, 긴급 호를 PSAP(예컨대, PSAP(180) 또는 PSAP(380))로 라우팅하고 PSAP가 PSAP 디스패치에 대해 사용될 수 있는 UE(200) 또는 UE(300)에 대한 로케이션을 요청 및 획득하게 할 수 있는 것과 같이 OTT SP(150) 또는 OTT SP(350)에 의한 긴급 호 지원의 다른 양상들을 다룰 수 없다. 긴급 호 지원의 이러한 다른 양상들에 다루기 위해, 도 1a-2b과 연관하여 설명된 로케이션 솔루션들로부터 일부 면들에서 상이할 수 있는 다른 로케이션 솔루션들이 다음으로 설명된다. 이러한 다른 로케이션 솔루션들은 사전에 설명된 솔루션들(S1 및 S2)에 대한 확장들을 제공할 수 있는데 - 이는 예컨대, LbyV 또는 LByR에 추가로 또는 그 대신, 로케이션 관련된 정보가 OTT SP(350)에 부가적으로 제공되는 것을 가능하게 할 수 있다. 도 3의 솔루션들(S1, S2)에 대해, 로케이션 서버(ELS)(370)는 UE(300)에 대한 값에 의한 로케이션 또는 레퍼런스에 의한 로케이션을 제공하는데 사용된다고 가정한다. ELS(370)는 상이한 네트워크 아키텍처의 몇몇 상이한 로케이션 서버들 중 하나에 대응할 수 있다(예컨대, ELS(370)는 E-SMLC(172), GMLC(170), SLP(170) 또는 LRF일 수 있음). ELS(370)를 LRF와 연관시키는 것은 특히 유용한데, 그 이유는 LRF가 (예컨대, 3GPP TS 23.167에서 그리고 ATIS 표준 ATIS-0700015에서) 로케이션 역참조를 위한 외부 인터페이스를 지원하도록 정의되고 제어 평면 로케이션 솔루션 및/또는 사용자 평면 로케이션 솔루션을 이용하여 AN(320) 및/또는 PCN(340) 내부의 로케이션 결정 성능에 대한 액세스를 가질 수 있기 때문이다.
[00120] 도 3의 솔루션들(S1 및 S2)은 서로 보완적인 것으로서 간주되며 둘 모두 지원될 수 있다. 예컨대, UE(300)가, 사용자가 긴급 호를 호출하고 있음을 검출하고 OTT SP(350)에 긴급 호 요청을 전송하기 이전에 어떤 로케이션 정보를 획득할 시간을 가질 때 솔루션(S1)이 사용될 수 있다. UE(300)가, 사용자가 긴급 호를 호출하고 있음을 검출하지 못하거나 OTT SP(350)에 긴급 서비스 요청을 전송하기 이전에 로케이션 정보를 획득할 충분한 시간을 갖지 않을 때 솔루션(S2)이 사용될 수 있다.
[00121] 도 3의 솔루션들(S1, S2)에 대한 향상들은, 초기에 UE(300)에 의해 OTT SP(350)로 전송된 긴급 호를 대신하여, 서빙 MNO에 의한 로케이션 및 라우팅을 지원할 때 여러 세트의 문제점들을 해결할 필요가 있을 수 있다. 이러한 다양한 세트의 문제점들은 다음에 설명되고 예시된다.
[00122] 문제점 세트 1 : 레거시 PSAP들
[00123] 레거시 PSAP(380)가 ESInet(360)에 의해 지원되지 않을 때(예컨대, 그러나 SR(360)에 의해 대신 지원될 수 있음), 레거시 PSAP(380)에 전송될 필요가 있는 긴급 호에 대한 로케이션 및 라우팅을 지원하는 것과 연관된 문제점들이 있을 수 있다. 하나의 문제점은, 레거시 PSAP(380)가 조인트 TIA 및 ATIS 표준 J-STD-036에 정의된 E2 인터페이스를 사용하여 OTT SP(350)로부터 UE(300)에 대한 로케이션을 리트리브할 수 없을 수도 있다는 것일 수 있는데, 이는 OTT SP(350)가 UE(300) 및 PSAP(380)와 상이한 나라에 있는 경우 또는 PSAP(380)가 OTT SP(350)와 통신 관계를 갖지 않는 경우 발생할 수 있다. E2 인터페이스는 긴급 호가 레거시 PSAP로 라우팅되는 미국의 공중 무선 네트워크를 통해 착수되는 긴급 호의 경우 레거시 PSAP에 의한 로케이션 리트리브를 위해 흔히 사용된다는 것에 주의한다. 제 2 문제점은, OTT SP(350)가 호 시그널링의 일부로서 레거시 PSAP(380)에 LbyV를 전송하는 것이 가능하지 않을 수 있다는 것일 수 있다(예컨대, UE(300)에 대한 긴급 호가 MF 트렁크를 사용하여 PSAP(380)에 도달하는 SR(360)을 통해 라우팅되는 경우). 제 3 문제점은 OTT SP(350)가 PSAP(380)에 LbyR 대신 LbyR을 제공하는 경우 레거시 PSAP(380)(또는 레거시 PSAP(380)와 연관된 ALI)가 LbyR의 역참조를 일반적으로 지원하지 않을 수 있다는 것일 수 있다.
[00124] 위의 3개의 문제점들은, OTT SP(350)에 대한 LbyV 또는 LbyR의 프로비전에만 기반한 솔루션들(S1 및 S2)의 임의의 향상이, 레거시 PSAP(380)가 ESInet(360)에 의해 지원되지 않을 때(예컨대, SR(360)에 의해서만 지원됨), 레거시 PSAP(380)에 대한 디스패치 가능한 로케이션의 프로비전을 지원하지 않을 수 있음을 의미할 수 있다.
[00125] 문제점 세트 2 : 서빙 MNO에서 제어 평면 로케이션
[00126] (예컨대, 3GPP TS 23.271, 25.305 및 36.305에 정의된 바와 같이) LTE 또는 HSPA 액세스를 위한 3GPP 제어 평면 로케이션 솔루션에 있어서, LTE 긴급 호를 걸고 있는 UE(300)에 대한 현재 서빙 MME 또는 서빙 SGSN의 아이덴티티는 UE(300) 로케이션에 대한 요청을 정확한 서빙 MME 또는 서빙 SGSN으로 라우팅하기 위해 LRF 또는 GMLC에 알려질 필요가 있다. (예컨대, ATIS-0700015에 설명된 바와 같이) OTT SP의 수반 없이 서빙 MNO에 의해 설정된 긴급 호들에 대해, 이 정보는 UE(300)가 (예컨대, 긴급 호를 설정하는 일부로서) 긴급 PDN 연결 또는 긴급 PDP 콘텍스트를 설정할 때 서빙 MME 또는 서빙 SGSN에 의해, 그리고 핸드오버가 발생할 때 새로운 또는 이전의 MME 또는 SGSN에 의해 (UE(300)를 긴급 호출하기 위한 로케이션을 지원하는데 사용되는) LRF 및 GMLC에서 업데이트된 채로 유지될 수 있다. 그러나 OTT SP(350)를 통해 설정된 긴급 호에 대해, 서빙 MNO는 긴급 호를 인지할 수 없을 수 있고, 이에 따라, LRF(및 GMLC)는 서빙 MME 또는 서빙 SGSN의 아이덴티티로 업데이트된 채로 유지되지 않을 수 있다. 이 정보가 없으면, GMLC는 로케이션 요청을 정확한 서빙 MME 또는 서빙 SGSN으로 라우팅할 수 없을 수 있다. 이는, OTT SP(350)로부터 UE(300)에 대한 로케이션 역참조 요청을 서비스할 때 - 어쩌면, ELS(370)가 HSS로부터 이 정보를 질의하기에 충분한 정보를 가질 때의 홈 가입자의 경우를 제외하고 - ELS(370)(예컨대, LRF)가 제어 평면 솔루션을 이용하여 UE(300)의 로케이션을 획득할 수 없다는 것을 의미한다.
[00127] 문제점 세트 3 : 서빙 MNO에서 사용자 평면 로케이션
[00128] UE(300)가 서빙 MNO(예컨대, PCN(340))와 OTT SP(350) 사이 중간에 있는 VPN을 통해 OTT SP(350)에 액세스할 때, OTT SP(350)에 의해 보여지는 UE(300)의 IP 어드레스는 VPN에 의해 할당되었을 수 있고, 이에 따라 서빙 MNO(예컨대, PCN(340))에 의해 UE에 할당된 임의의 IP 어드레스와 상이할 수 있다. 서빙 MNO(예컨대, ELS(370))의 SLP가 서빙 MNO에 알려지거나 그에 의해 할당된 IP 어드레스를 갖는 UE들을 대신하여 착신 로케이션 요청들만을 수락하는 경우, 이는, VPN 할당된 IP 어드레스가 OTT SP(350)에 의해 서빙 MNO에 전송된(예컨대, ELS(370)로 전송된) 로케이션 요청에 포함된 경우 서빙 MNO에 의한 SUPL 로케이션의 이용을 방지할 수 있다. 유사한 문제점은 (예컨대, LTE 액세스에 대한 PDN 게이트웨이가 홈 네트워크(385)에 있는 경우) 홈 네트워크(385)에 의해 IP 어드레스가 할당된 로밍 UE(300)에 대해 발생할 수 있다. 그러나 이 경우에, 서빙 MNO(예컨대, 서빙 MNO의 SLP)는 로밍 파트너들, 이를테면, 홈 네트워크(385)에 의해 할당된 IP 어드레스들(예컨대, 어드레스 범위들)을 갖도록 구성될 수 있으며, 이 경우, 사용자 평면(예컨대, SUPL) 로케이션의 사용은 여전히 가능할 수 있다.
[00129] 문제점 세트 4 : PSAP로의 긴급 호의 라우팅
[00130] PSAP(380)에 대한 정확한 어드레스 또는 아이덴티티가 알려지면(예컨대, SIP URL 또는 텔레폰 DN), OTT SP(350)가 (예컨대, IP 네트워크(375)를 통해 또는 PSTN을 통해) UE(300)로부터 PSAP(380)로 긴급 호를 라우팅할 수 있지만, 일부 OTT SP들(350)은 UE(300)에 대한 지리적 로케이션을, 서비스 영역이 UE(300) 어드레스의 로케이션을 포함하는 PSAP(380)의 어드레스 또는 아이덴티티에 맵핑하는 능력이 결핍될 수 있다. 예컨대, 이러한 능력의 결핍은, OTT SP(350)가 UE(300) 및 PSAP(380) 둘 모두와 상이한 나라에 있고, - 예컨대, IETF에 의해 정의된 LoST 프로토콜을 사용하여 - 다른 나라들에서 PSAP들에 대한 라우팅 정보를 획득할 능력을 갖지 않는 경우 발생할 수 있다. 일부 경우들에서, PSAP(380) 어드레스 또는 아이덴티티가 OTT SP(350)에 의해 알려지더라도, PSAP(380) 측에서 긴급 호 유입에 대한 제약들로 인해 OTT SP(350)가 UE(300)에 대한 긴급 호를 PSAP(380)로 포워딩하는 것이 가능하지 않을 수 있다 .
[00131] 위에서 설명되고 예시된 문제점 세트들(1 내지 4)은 다음으로 설명되는 바와 같이 사전에 참조되는 솔루션들(S1 및 S2)에 대한 특정 향상에 의해 해결될 수 있다.
[00132] 도 4는 개시내용의 적어도 일 양상에 따라 OTT 서비스 제공자를 통한 긴급 서비스들에 대한 레퍼런스 지원에 의한 로케이션에 대한 예시적인 아키텍처를 예시한다. 도 4에 예시된 아키텍처는, UE(400)(대응하는 UE(200) 또는 UE(300)에 대응할 수 있음), 액세스 네트워크(420)(RAN(120) 또는 AN(320)에 대응할 수 있음), IMS(440)(코어 네트워크(140)의 부분, PCN(340)의 부분에 대응할 수 있음), OTT SP(450)(OTT SP(150) 또는 OTT SP(350)에 대응할 수 있음), NENA i3 가능 ESInet(460)(ESInet(160) 또는 ESInet(360)에 대응할 수 있음), 레거시 ESN(462), 인터넷(475), PSTN(485) 및 서빙 MNO(490)(AN(120)과 조합됨 CN(140) 또는 AN(320)과 조합된 PCN(340)에 대응할 수 있음)을 포함한다. IMS(440)는 LRF(448)(로케이션 서버(170) 또는 ELS(370)에 대응할 수 있음), MGCF(441), P-CSCF(442), E-CSCF(443), IBCF(444) 및 S-CSCF(445)를 포함한다. LRF(448)는 RDF(446) 및 LS(470)(로케이션 서버(170), 또는 GMLC/SLP(170)에 대응할 수 있음)에 연결될 수 있다. i3 ESInet(460)는 BCF(464), ESRP(466), ECRF(468) 및 NENA i3 가능 PSAP(480)(PSAP(180) 또는 PSAP(380)에 대응할 수 있음)을 포함한다. 레거시 ESN(462)은 ALI(461), SR(463)(SR(160) 또는 SR(360)에 대응할 수 있음) 및 레거시 PSAP(482)(PSAP(180) 또는 PSAP(380)에 대응할 수 있음)를 포함한다. 도 4에 도시된 다양한 엔티티들은, 당 분야에서 잘 알려져 있고, 3GPP TS(예컨대, TS들 23.401, 23.167, 23.228)에서, ATIS 0700015 표준에서 그리고 NENA i3 표준에서 정의된다.
[00133] 솔루션(S1)에 대해 도 4에 도시된 정규 LbyR 지원에 있어서, UE(400)는 긴급 호 요청(401)을 LbyR을 포함하는 OTT SP(450)에 전송한다. OTT SP(450)는 그 후 긴급 호 요청(401)에서 수신된 LbyR에 의해 표시된 ELS(예컨대, 서빙 MNO(490)의 LRF(448))에 로케이션 질의(402)를 전송함으로써 LbyR을 역참조한다. (도 4에서 LRF(448)로서 도시된) ELS는 UE(400)에 대한 로케이션을 획득하고, 로케이션 및/또는 라우팅 정보를 OTT SP(450)로 리턴한다. OTT SP(450)는 그 후, 원래 수신된 LByR을 포함하고 LRF(448)로부터 수신된 라우팅 정보 또는 로케이션에 기반하여 PSAP에 긴급 호(메시지(403A)에서 레거시 PSAP(482) 또는 메시지(403B)에서 NENA I3 가능 PSAP(480))를 라우팅한다. PSAP(480/482)는 그 후, 수신된 LByR을 사용하여 디스패치가능한 로케이션에 대해 나중의 시간에 ELS(예컨대, LRF(448))로 질의(404A(PSAP(482)에 대해) 또는 404B(PSAP(480)에 대해))를 전송할 수 있다. 위의 문제점 세트 1에 대해 논의된 바와 같이, 로케이션 질의(404A)는 PSAP가 ESInet에 의해 지원되지 않는 한, 레거시 PSAP(482)에 대해 가능하지 않을 수 있다.
[00134] 도 4와 연관하여 위에서 설명된 기본 LbyR 솔루션은 문제점 세트들 2 및 3에 대해 위에서 설명된 문제점들을 극복하기 위해 도 3의 솔루션들(S1 및 S2)에 대해 향상될 수 있다. 구체적으로, UE(400)에 대한 LbyR로서 서빙 MNO(490)에 의해(예컨대, LRF(448)에 의해) 할당된 로케이션 URI는 다음의 정보를 포함하도록 포맷팅될 수 있다 :
a) 서빙 MNO(490)가 UE(400)를 로케이팅하기 위해 사용자 평면 로케이션을 이용하는 경우 그리고 로컬 IP 어드레스가 서빙 MNO(490)에 의해 UE(400)에 할당된 경우, UE(400)에 대한 로컬 IP 어드레스;
b) 서빙 MNO(490)가 UE(400)를 로케이팅하기 위해 제어 평면 로케이션을 사용할 경우, 서빙 MME(예컨대, MME(142)) 또는 서빙 SGSN의 로컬 아이덴티티; 및
c) 서빙 MNO(490)가 UE(400)를 로케이팅하기 위해 제어 평면 로케이션을 사용할 경우, UE(400)에 대한 아이덴티티(예컨대, MSISDN, IMSI, 또는 서빙 MME 또는 SGSN에 의해 할당된 로컬 ID).
[00135] (a), (b) 및 (c)에서 위의 정보는 UE(400)에 대한 로컬 레퍼런스로서 통상적으로 사용되는 LbyR의 일부로서 포함될 수 있고, (예컨대, 도 1a-2b와 관련하여 앞에서 설명된 바와 같이) LRF(448)와 같은 ELS에 의해서 보다는 서빙 MNO(490)의 PCN 또는 AN(420)에 의한 LbyR 할당을 허용할 것이며, 이는 구현을 단 순화할 수 있다. 이 정보의 포맷팅은 서빙 MNO(490)에 대해 특정된 것일 수 있다(예컨대, 표준화되지 않을 수 있다). OTT SP(450)로부터의 LbyR에 대해, 역참조 요청, 이를테면 요청(402)에서 이러한 로케이션 URI를 수신하고 LbyR에 대한 포맷팅 규칙들을 알고 있는 서빙 MNO(490)의 ELS(예컨대, LRF(448))는 UE(400)의 제어 평면 또는 사용자 평면 로케이션을 호출하기 위해 위의 (a)-(c)에서 정보를 추출하고 이를 사용할 수 있다. 부가되는 이점은, ELS가 UE(400)로부터의 긴급 호 또는 UE(400)에 대한 정보를 유지할 필요가 없고 각각의 이러한 요청에 포함된 정보에만 기반하여 각각의 역참조 요청(예컨대, 요청(402))에 응답할 수 있다는 것이다.
[00136] 도 4와 관련하여 설명된 바와 같이, 위의 향상은, 본원에서 "향상된 LbyR"로 지칭되고 부가적인 도면들을 이용하여 나중에 본원에 예시되지만, 위의 문제점 세트 2의 문제들 모두를 해결하지 못할 수 있다. 예컨대, UE(400)에 대한 LbyR이 UE(400)에 대한 현재 서빙 MME 또는 현재 서빙 SGSN의 아이덴티티를 포함할 수 있다 하더라도, UE(400)가 새로운 정보(예컨대, 새로운 LbyR)를 (예컨대, SIP INFO를 통해) OTT SP(450)에 전송하고 이어서 OTT SP(450)가 이를 PSAP(480 또는 482)에 포워딩하지 않는 한, UE(400)가 새로운 서빙 MME 또는 SGSN으로 핸드오프될 때는 그 정보는 쓸모없어질 수 있다.
[00137] IMS 지원은, 문제점 세트들 1, 2, 3 및 4에 대해 위에 설명된 문제점들 모두를 해결하기 위해 사용될 수 있는 도 3의 솔루션들(S1 및 S2)에 대한 다른 향상이다. IMS 지원에 의해, 서빙 MNO는 도 5와 관련하여 다음에 설명되는 바와 같이, LRF로서, 또는 도 6과 관련하여 나중에 설명되는 바와 같은 E-CSCF로서 지원을 제공할 수 있다.
[00138] 도 5는 본 개시내용의 적어도 하나의 양상에 따른 OTT 서비스 제공자를 통한 긴급 서비스들에 대한 IMS LRF 지원을 위한 예시적인 아키텍처를 도시한다. 도 4에 도시된 아키텍처와 유사하게, 도 5에 도시된 아키텍처는 UE(500)(UE(200), UE(300) 또는 UE(400)에 대응할 수 있음), 액세스 네트워크(520)(RAN (120), AN(320) 또는 AN(420)에 대응할 수 있음), IMS(540)(코어 네트워크(140)의 일부, PCN(340) 또는 IMS(440)의 일부에 대응할 수 있음), OTT SP(550)(OTT SP(150), OTT SP(350) 또는 OTT SP(450)에 대응할 수 있음), NENA i3 가능 ESInet(560)(ESInet(160), ESInet(360) 또는 ESInet(460)에 대응할 수 있음), 레거시 ESN(562), 인터넷(575), PSTN(585), 및 서빙 MNO(590)(AN(120)과 결합된 CN(140), AN(320)과 결합된 PCN(340), 또는 MNO(490)에 대응할 수 있음)을 포함한다. IMS(540)는 LRF(548)(로케이션 서버(170), ELS(370) 또는 LRF(448)에 대응할 수 있음), MGCF(541), P-CSCF(542), E-CSCF(543), IBCF(544) 및 S-CSCF(545)를 포함한다. LRF(548)는 RDF(546) 및 LS(570)(로케이션 서버(170), GMLC/SLP(170) 또는 LS(470)에 대응할 수 있음)에 연결될 수 있다. i3 ESInet(560)은 BCF(564), ESRP(566), ECRF(568) 및 NENA i3 가능 PSAP(580)(PSAP(180), PSAP(380) 또는 PSAP(480)에 대응할 수 있음)를 포함한다. 레거시 ESN(562)은 ALI(561), SR(563)(SR(160), SR(360) 또는 SR(463)에 대응할 수 있음), 및 레거시 PSAP(582)(PSAP(180), PSAP(380) 또는 레거시 PSAP(482)에 대응할 수 있음)를 포함한다. 도 4와 마찬가지로, 도 5에 도시된 다양한 엔티티들은 본 기술분야에 잘 알려져 있다.
[00139] 도 3의 솔루션(S1)에 대해 도 5에 도시된 LRF 지원을 통해서, UE(500)로부터 PSAP(580) 또는 PSAP(582)로의 긴급 호가 UE(400)로부터 도 4와 관련하여 설명된 PSAP(480) 또는 PSAP(482)로의 긴급 호와 유사하게 설정될 수 있으며, 도 4의 메시지들(401, 402, 403A, 403B, 404A 및 404B)이 도 5의 메시지들(501, 502A, 503A, 503B, 504A 및 504B)과 각각 대응한다. 그러나, 도 5에 도시된 LRF 지원의 경우, 질의(502A) 및 응답(502B)에서 OTT SP(550)와 LRF(548) 간의 상호작용이 도 4에서와 같이 로케이션 역참조를 사용하지 않고 대신 긴급 호의 로케이션 리트리벌 및 라우팅 둘 모두를 지원하기 위해 LRF 성능을 사용한다. OTT SP(550)는 긴급 호 요청(501)에서 UE(500)로부터 서빙 MNO(590)의 LRF(548)의 어드레스를 처음에 수신한다(이는 UE(500)가, 예컨대, 네트워크 어태치먼트 상에서, 서빙 MNO(590)의 PCN 또는 서빙 MNO AN(520)으로부터 획득할 수 있음). 그런 다음, OTT SP(550)는 E-CSCF(예컨대, ATIS-0700015 표준의 경우)와 유사하게 거동하고 SIP INVITE(502A)의 형태로 긴급 호 요청을 LRF(548)로 포워딩하며, 이는 Ml 인터페이스에 대한 ATIS-00700015의 LRF에 대해 설명된 것과 유사하게 로케이션 및 라우팅 정보를 획득한다. 그런 다음, LRF(548)는 로케이션 및 라우팅 정보를 (예컨대, ATIS-0700015의 Ml 인터페이스 상에서 발생함에 따라) SIP(300) 다중 선택들(502B)의 형태로 OTT SP(550)에 리턴한다. 그런 다음, OTT SP(550)는 라우팅 정보를 사용하고 응답(502B)을 통해 수신된 로케이션 정보를 포함하는 긴급 호 요청을 PSAP(요청(503A)의 레거시 PSAP(582) 또는 요청(503B)의 NENA i3 가능 PSAP(580))에 라우팅한다. 응답(502B)을 통해 수신된 로케이션 정보는, LbyV, LbyR, ESRK, 또는 ESRD 및 MSISDN을 포함할 수 있고, ATIS-0700015에 정의된 레퍼런스 식별자에 대응할 수 있다. 마지막의 3가지 대안들(즉, LbyR, ESRK, 또는 ESRD 및 MSISDN)의 경우, PSAP(580/582)는 통상적으로, 나중에 UE(500)에 대한 디스패치가능한 로케이션에 대해 질의(504A)(PSAP(582)의 경우) 또는 질의(504B)(PSAP(580)의 경우)를 LRF(548)에 전송할 것이다.
[00140] 도 5는 UE(500)로부터 OTT SP(550)로의 초기 긴급 호 요청 메시지(예컨대, SIP INVITE)(501)의 경로 및 방향, LRF(548)(포워딩된 SIP INVITE(502A)의 경우) 및 다시 OTT SP(550)(SIP300 다중 선정들(502B)의 경우)로의 경로, 및 포워딩된 긴급 호 요청(503A 및 503B)에 대한 OTT SP(550)로부터 PSAP(580/582)로의 경로 및 방향을 도시한다. 인터넷(575)은 서빙 MNO(590)로부터 OTT SP(550)로 초기 호 요청(501)을 전달하기 위해 그리고 포워딩된 호 요청(503B)을 OTT SP(550)로부터 ESInet(560)으로 전달하기 위해 사용될 수 있는 반면, 레거시 PSAP(582)에 도달하도록 CS 호 요청(503A)을 OTT SP(550)로부터 SR(563)로 전달하기 위해 PSTN(585)이 사용될 수 있다. 도 5는 또한, 각각 레거시 PSAP(582) 또는 NENA i3 PSAP(580)에 의해 LRF(548)에 전송된 UE(500)에 대한 로케이션 요청(504A 또는 504B)에 대한 경로 및 방향을 도시한다.
[00141] 도 6은 본 개시내용의 적어도 하나의 양상에 따른 OTT 서비스 제공자를 통한 긴급 서비스들에 대한 IMS E-CSCF 지원을 위한 예시적인 아키텍처를 도시한다. 도 4 및 도 5에 도시된 아키텍처와 유사하게, 도 6에 도시된 아키텍처는 UE(600)(UE(200), UE(300), UE(400) 또는 UE(500)에 대응할 수 있음), 액세스 네트워크(620)(RAN (120), AN(320), AN(420) 또는 AN(520)에 대응할 수 있음), IMS(640)(코어 네트워크(140)의 일부, PCN(340), IMS(440) 또는 IMS(540)의 일부에 대응할 수 있음), OTT SP(650)(OTT SP(150), OTT SP(350) 또는 OTT SP(450) 또는 OTT(550)에 대응할 수 있음), NENA i3 가능 ESInet(660)(ESInet(160), ESInet(360), ESInet(460) 또는 ESInet(560)에 대응할 수 있음), 레거시 ESN(662), 인터넷(675), PSTN(685), 및 서빙 MNO(690)(AN(120)과 결합된 CN(140), AN(320)과 결합된 PCN(340), MNO(490) 또는 MNO(590)에 대응할 수 있음)을 포함한다. IMS(640)는 LRF(648)(로케이션 서버(170), ELS(370), LRF(448) 또는 LRF(548)에 대응할 수 있음), MGCF(641), P-CSCF(642), E-CSCF(643), IBCF(644) 및 S-CSCF(645)를 포함한다. LRF(648)는 RDF(646) 및 LS(670)(로케이션 서버(170), GMLC/SLP(170), LS(470) 또는 LS(570)에 대응할 수 있음)에 연결될 수 있다. i3 ESInet(660)은 BCF(664), ESRP(666), ECRF(668) 및 NENA i3 가능 PSAP(680)(PSAP(180), PSAP(380), PSAP(480) 또는 PSAP(580)에 대응할 수 있음)를 포함한다. 레거시 ESN(662)은 ALI(661), SR(663)(SR(160), SR(360), SR(463) 또는 SR(563)에 대응할 수 있음), 및 레거시 PSAP(682)(PSAP(180), PSAP(380), 레거시 PSAP(482) 또는 레거시 PSAP(582)에 대응할 수 있음)를 포함한다. 도 4 및 5와 마찬가지로, 도 6에 도시된 다양한 엔티티들이 본 기술분야에 잘 알려져 있다.
[00142] 도 3의 솔루션 S1에 대해 도 6에 도시된 E-CSCF 지원에 의해, OTT SP(650)는 UE(600)로부터 전송된 긴급 호 요청(601)을 통해 서빙 MNO(690)에서 E-CSCF(643)의 어드레스를 수신한다(이는, UE(600)가 예컨대, 네트워크 어태치먼트 상에서 서빙 MNO(690) 내 PCN 또는 서빙 MNO AN(620)으로부터 획득할 수 있음). 그런 다음, OTT SP(650)는 S-CSCF와 유사하게 거동하고 표준 SIP INVITE(602)를 사용하여 긴급 서비스들 요청을 E-CSCF(643)에 포워딩하고, E-CSCF(643)는 그런 다음 포워딩을 수행하는데 필요한 응답(603B)을 통해 임의의 라우팅 및 로케이션 정보를 획득하기 위해 요청(603A)을 LRF(648)로 전송한 후, 호 요청(604A 또는 604B)을 각각 PSAP(680 또는 682)에 포워딩한다. 도 6에 예시된 E-CSCF 지원은, 서빙 MNO(690)에 의한 보다 큰 수반 비용을 감안하여 PSAP(680/682)에 대한 성공적인 호(또는 서비스) 전달의 가능성을 개선할 수 있다.
[00143] 도 5와 유사하게, 도 6은 UE(600)로부터 OTT SP(650)로의 초기 긴급 호 요청 메시지(예컨대, SIP INVITE)(601)의 경로 및 방향, E-CSCF(643)로 포워딩된 호 요청(602)의 경로, 및 포워딩된 호 요청(604A 또는 604B)의 PSAP(680 또는 682)로의 경로 및 방향을 각각 도시하며, 위치 및 라우팅 지원이 요청(603A)에서 E-CSCF(643)에 의해 요청되고 응답(603B)으로 LRF(648)에 의해 리턴된다. LRF(648)로의 요청(603A) 및 LRF(648)로부터의 응답(603B)은 ATIS-0700015의 솔루션에 대해 정의된 바와 같을 수 있으며, 예컨대, 요청(603A)은 SIP INVITE를 포함하고 응답(603B)은 SIP(300) 다중 선정 메시지를 포함한다. 도 6은 또한, 각각 레거시 PSAP(682) 또는 NENA i3 PSAP(680)에 의해 LRF(648)에 전송된 UE(600)에 대한 로케이션 요청(605A 또는 605B)에 대한 경로 및 방향을 도시한다.
[00144] 도 5 및 도 6과 연관하여 각각 설명된 LRF(648) 및 E-CSCF(643) 솔루션들 둘 모두는, 3GPP에 의해 그리고 ATIS-0700015에서 정의된 IMS 긴급 호 솔루션(예컨대, 3GPP TS 23.167)과 비교하여, 도 6의 E-CSCF 솔루션에 대한 E-CSCF에 대한 변화, 및 LRF 및 RDF에 대한 일부 변화들을 필요로 할 수 있지만, 이러한 표준 솔루션들로부터 기존 기능을 또한 재사용할 수 있다.
[00145] 도 5 및 도 6을 참조하여 위에 설명된 각각의 솔루션의 경우, UE(예컨대, UE(500) 또는 (600))는 (i) OTT SP로부터 서빙 MNO(LRF 또는 E-CSCF) 내의 정확한 엔티티로 긴급 호 라우팅을 가능하게 하고 그리고 (ii) OTT SP가 서빙 MNO에 충분한 정보를 제공하여 서빙 MNO로 하여금 UE 로케이션을 획득하고 호 라우팅을 지원하게 할 수 있거나 돕기 위해서 특정 정보를 OTT SP(예컨대, OTT SP(550 또는 650))에 제공할 것이다. UE에 의해 OTT SP에 제공되는 정보 중 일부는 UE에 일반적으로 알려진 것으로부터 비롯될 수 있는 반면, 예컨대, UE 어태치먼트에서, 새로운 MME로의 또는 SGSN으로의 핸드오버 시 그리고/또는 추적 영역 또는 라우팅 영역 업데이트가 새로운 MME 또는 SGSN에 대해 발생할 때마다, 서빙 MNO(예컨대, MNO(590 또는 690))의 AN(예컨대, AN(520 또는 620))에 의해 또는 PCN에 의해 UE로 다른 정보가 제공되어야 할 수 있다. UE에 대한 긴급 호 요청에서 UE에 의해 OTT SP로 제공될 수 있는 정보(열 1)가, 정보의 각각의 아이템의 가능성 있는 소스(열 2), UE에 대한 UP(user plane) 또는 CP(control plane) 로케이션에 대한 적용가능성(열 3), 및 UE와 OTT SP 사이에서 SIP가 사용될 경우 각각의 아이템을 OTT SP로 (따라서, 서빙 MNO로) 전달하기 위해 사용될 수 있는 가능한 SIP 헤더들(열 4)과 함께 표 3에 도시된다.
Figure pct00005
표 3
[00146] 서빙 MNO(590 또는 690) 내의 LRF(548) 또는 E-CSCF(643)는, E-CSCF(643)의 경우에 호를 유지하거나 LRF(548)의 경우에 PSAP(580/582) 또는 ESInet(560)으로부터 임의의 후속적인 로케이션 요청에 응답하기 위해서, 도 5 또는 도 6의 솔루션과 각각 관련하여, OTT SP(550 또는 650)로부터 초기 SIP INVITE(502A 또는 602)를 각각 수신한 후 상태 정보를 유지할 필요가 있을 수 있다. LRF(548)의 경우, 이는 긴급 호가 종료된 시기를 아는 것을 의미한다. 이외에도, UE(500 또는 600)에 대한 서빙 MME 또는 서빙 SGSN이 변할 수 있기 때문에, E-CSCF(643) 또는 LRF(548)는, 제어 평면 위치가 사용될 경우 새로운 서빙 MME 또는 SGSN 어드레스 (또는 ID)를 알 필요가 있을 수 있다. LRF(548)의 경우, 이러한 목적들은, LRF(548)가 호 종결에 대해 OTT SP(550)로부터의 이벤트 통지에 개별적으로 가입하는 경우, 그리고 제어 평면 로케이션이 서빙 MME 또는 SGSN의 변화에 대해 사용될 경우에 달성될 수 있다. E-CSCF(643)의 경우, 서빙 MME 또는 SGSN 어드레스에서의 변화의 통지는 OTT SP(650)로부터의 SIP INFO 업데이트에 의해 가능할 수 있다. UE(500 또는 600)는 (예컨대, OTT SP가 SIP를 사용할 경우) SIP INFO를 사용하거나 또는 일부 전유 OTT SP 메시지를 사용하여 임의의 새로운 서빙 MME 또는 SGSN 아이덴티티로 업데이트된 OTT SP(550 또는 650)를 각각 유지할 수 있다.
[00147] 도 5 및 도 6에 도시된 솔루션들 둘 모두는, UE(500 또는 600)에 의해 각각 OTT SP(550 또는 650)로 제공된 서빙 MNO의 어드레스가 도 5의 LRF 솔루션에 대한 LRF(548)에 대한 어드레스 및 도 6의 E-CSCF 솔루션에 대해 E-CSCF(643)에 대한 어드레스일 수 있다는 것을 제외하고, 표 3에 나타내어진 동일한 정보를 UE(500) 또는 UE(600)로부터 OTT SP(550) 또는 OTT SP(650)에 각각 전달할 수 있다. UE(500 또는 600)로부터 OTT SP(550 또는 650)로의 이러한 거의 동일한 정보 전달은, 각각, (도 5 및 도 6에 대한) 솔루션들 둘 모두로 하여금, UE들(500 및 600)에 의한 그리고 OTT SP들(550 및 650)에 의한 공통 솔루션의 부분으로서 지원될 수 있게 허용하며, 이는, 서빙 MNO(590 또는 690)로 하여금 2개의 솔루션들 중 어느 것을 사용할지를 결정할 수 있게 허용하고 UE들(500 및 600) 및 OTT SP들(550 및 650)에 의한 지원에 영향을 주지 않고 하나의 솔루션에서 다른 솔루션으로의 이동을 지원할 수 있다. 다음에 설명되는 도면들은, 도 5의 LRF 기반 솔루션 및 도 6의 E-CSCF 기반 솔루션을 보다 상세하게 예시한다.
[00148] 도 7은 본 개시내용의 적어도 하나의 양상에 따른, 값에 의한 로케이션 및 레퍼런스에 의한 향상된 로케이션 지원을 위한 예시적인 메시지 흐름을 예시한다. 도 7에 예시된 메시지 흐름은 도 3 및 4에 예시된 아키텍처들에서 수행될 수 있으며, 도 4와 연관하여 설명된 레퍼런스에 의한 로케이션의 지원을 위한 상호작용들에 대응하고 그들을 확장시킬 수 있다. 도 7의 메시지 흐름은 또한 또는 대신에 도 1a 및 1b에 예시된 아키텍처들에서 수행될 수 있으며, 레퍼런스에 의한 로케이션의 지원을 위해 도 2a 및 2b와 연관하여 설명된 상호작용들을 제공하고 확장시킬 수 있다. 그 결과, 도 7의 UE(700)는 도 1a의 UE들 1 내지 N, UE(200), UE(300) 또는 UE(400) 중 임의의 UE에 대응할 수 있다. 유사하게, OTT SP(750)는 OTT SP(150), OTT SP(350) 또는 OTT SP(450)에 대응할 수 있다. 유사하게, AN/PCN(792)은 MNO(490)의 AN(420) 및 PCN 부분, AN(320) 및 PCN(340) 또는 AN(120) 및 CN(140)에 대응할 수 있고, 액세스 네트워크 노드(240)를 포함할 수 있다. 유사하게, ELS(794)는 LRF(448), ELS(370), GMLC/SLP(170) 또는 로케이션 서버(170)에 대응할 수 있다. 유사하게, SR(763)은 SR(463), SR(360) 또는 SR(160)에 대응할 수 있다. 유사하게, ESInet(760)는 ESInet(460), ESInet(360) 또는 ESInet(160)에 대응할 수 있다. 유사하게, i3 PSAP(780)는 i3 PSAP(480), PSAP(380) 또는 PSAP(180)에 대응할 수 있다. 유사하게, 레거시 PSAP(782)는 레거시 PSAP(482), PSAP(380) 또는 PSAP(180)에 대응할 수 있다. 유사하게, 서빙 MNO(790)는 서빙 MNO(490)에 대응할 수 있다.
[00149] 도 7에 도시된 호 흐름은 도 3의 솔루션 S1에 직접 적용될 수 있으며, 예컨대, 솔루션 S1을 지원하는데 필요한 상호작용들의 더 많은 세부사항들을 제공할 수 있다. 도 3의 솔루션 S2에 대응하는 호 흐름은, 706의 긴급 호 요청이 (도 7에 대해 아래에서 설명되는 바와 같이) LbyV 또는 LbyR를 반송하지 않을 것이고 OTT SP(750)가 706에 후속하여 LbyV 또는 LbyR에 대해 UE(700)에 질의할 것이라는 점을 제외하고는 도 7에 도시된 호 흐름과 거의 동일할 수 있다. 부가적으로, 도 3의 솔루션 S2에 대해, UE(700)는 사용자가 706에서 긴급 호를 착수한다는 것을 검출하지 않을 수 있고(예컨대, 사용자가 긴급전화 번호, 이를테면 "911"을 다이얼링했다는 것을 인지할 수 없음), 706에서 긴급 호 요청이 아니라 통상적인 호 요청을 OTT SP(750)에 전송할 수 있다. 그 후, OTT SP(750)는 706에서 전송된 호 요청이 긴급 호에 대한 것임을 인지할 수 있고(예컨대, 다이얼링된 번호들이 긴급전화 번호, 이를테면 "911"에 대한 것임을 인지할 수 있음), 708으로 진행하기 전에 UE(700)로부터 LbyR 또는 LbyV를 요청할 수 있다. 그 후, 도 7에 도시된 다른 동작들은 도 3의 솔루션 S2가 사용되는 경우 아래에서 설명되는 바와 같이 발생할 수 있다.
[00150] 도 7에 도시된 상호작용들은, UE(700)가 서빙 MNO(790)에 액세스하고 있는(예컨대, 서빙 MNO(790)를 통해 OTT SP(750)에 액세스하고 있는) 환경들에서 OTT SP(750)를 통해 긴급 호를 착수하는 UE(700)에 적용된다. 도 7의 702에서, LbyR이 긴급 호를 지원하도록 UE(700)에 의해 사용될 것이라면, UE(700)는 서빙 AN 또는 PCN(792)으로부터 LbyR을 요청할 수 있다. 예컨대, 이것은, 사용자가 긴급 호를 착수하고 있다는 것을 UE(700)가 검출하는 경우에 발생할 수 있거나, UE(700)가 일부 다른 이유 때문에 (예컨대, UE(700) 이동성을 지원하기 위해) 서빙 MNO(790)에 어태치하거나 서빙 MNO에 액세스하는 경우에 발생할 수 있다.
[00151] 704에서, 702에 대한 응답으로 또는 소정의 조건들이 발생하는 경우(예컨대, UE(700)가 AN/PCN(792)에 어태치하거나, AN/PCN(792)에서 새로운 MME 또는 SGSN에 대한 추적 또는 라우팅 영역 업데이트를 수행하거나, 핸드오버가 새로운 MME 또는 SGSN에 대해 발생하는 경우), AN 또는 PCN(792)은 LbyR 또는 업데이트된 LbyR을 UE(700)에 전송한다. LbyR은 AN 또는 PCN(792)에 의해 결정되거나 ELS(794)(예컨대, LRF)로부터 획득될 수 있다. 일부 실시예들에서, 블록들(702 및 704)은 도 2a의 블록(202A) 또는 도 2b의 블록들(202B 및 206B) 각각에 대응할 수 있다. 이들 실시예들에서, AN/PCN(792) 그 자체는 704에서 UE(700)로 리턴되는 LbyR을 할당할 수 있거나, 도 2b의 블록(204B)과 유사하게 ELS(794)로부터 LbyR을 획득할 수 있다(도 7에 도시되지 않음).
[00152] 706에서, UE(700)의 사용자가 긴급 호를 착수했다는 것을 UE(700)가 검출하는 것에 대한 응답으로(예컨대, 사용자가 번호들 "911"을 다이얼링했다는 것을 UE(700)가 검출하면), UE(700)는 긴급 호 요청을 OTT SP(750)에 전송하고, 704에서 획득된 LbyV 또는 LByR을 포함한다. 긴급 호 요청은 SIP INVITE일 수 있거나 OTT SP(750)에 특정적인 일부 다른 프로토콜에 대한 메시지일 수 있다. 블록(706)은 도 2a의 블록(214A), 도 2b의 블록(212B) 또는 도 4의 긴급 호 요청의 전송(401)에 대응할 수 있다.
[00153] 708에서는, LbyR이 706에서 수신되면, OTT SP(750)가 로케이션 요청(예컨대, HELD가 LByR에서 참조되면 HELD 프로토콜에 따라 포맷된 로케이션 요청)을 ELS(794)에 전송함으로써 LbyR을 역참조하고 요청에 LbyR을 포함시킨다. OTT SP(750)는 706에서 수신된 LbyR 내의 정보로부터 ELS(794)를 결정(예컨대, ELS(794)에 대한 어드레스, FQDN 또는 URL을 결정)할 수 있다. 블록(708)은 도 2a의 블록(216A), 도 2b의 블록(214B) 또는 도 4의 로케이션 질의의 전송(402)에 대응할 수 있다.
[00154] 710에서, ELS(794)는, 예컨대 제어 평면 또는 사용자 평면 로케이션 솔루션을 사용하여 UE(700)의 현재의 로케이션을 획득하기 위해 708에서 수신된 LbyR에 포함되는 정보(예컨대, 로컬 또는 글로벌 UE 아이텐티티 및 제어 평면 로케이션에 대한 서빙 MME/SGSN ID 또는 사용자 평면 로케이션에 대한 로컬 UE IP 어드레스)를 사용한다. 블록(710)은 도 2a의 블록들(218A 및/또는 222A), 또는 도 2b의 블록들(216B 내지 226B) 또는 블록(228B) 중 어느 하나에 대응할 수 있다.
[00155] 712에서, ELS(794)는 현재의 UE(700) 로케이션을 OTT SP(750)로 리턴하고 그리고/또는 UE(700) 로케이션으로부터 결정된 UE(700)에 대한 라우팅 정보를 리턴한다. 블록(712)은 도 2a의 블록(224A) 또는 도 2b의 블록(232B)에 대응할 수 있다. 블록들(708-712)은 선택적인 것으로 도시되며, OTT SP(750)가 706에서 LbyV를 수신하면 수행되지 않을 수 있다.
[00156] 712에 후속하여, 로케이션이 712에서 UE(700)에 대해서만 리턴되었다면, OTT SP(750)는 UE 로케이션을 사용하여(예컨대, 도 7에 도시되지 않은 LoST 질의를 사용하여) 목적지 PSAP를 결정한다. 그렇지 않으면, OTT SP(750)는 PSAP를 결정하기 위해 712에서 리턴된 임의의 라우팅 정보를 사용할 수 있다. OTT SP(750)가 레거시 PSAP(782)를 결정하는 경우, OTT SP(750)는 PSAP(782)에 대한 SR(763)에 ISUP IAM 메시지를 전송함으로써 CS를 사용하여 호를 포워딩할 수 있다.
[00157] 716A에서, SR(763)은 호를 레거시 PSAP(782)에 포워딩한다.
[00158] 718A에서, 호 설정의 나머지가 수행된다. 그 후, 블록들(714B, 716B 및 718B)는 수행되지 않는다.
[00159] OTT SP(750)가 712에 후속하여 레거시 PSAP(782) 대신 i3 PSAP(780)를 결정하는 경우, 블록들(714A, 716A 및 718A)이 수행되지 않는다. 대신, OTT SP(750)는 706에서 수신된 LbyV 또는 LbyR을 포함하거나 어쩌면 712가 발생하면 712에서 수신된 UE(700)에 대한 임의의 로케이션을 포함하는 SIP INVITE를 전송함으로써 호를 ESInet(760)에 포워딩한다.
[00160] 714B에 후속하여 그리고 716B 이전에, LbyR이 714B에서 제공되면, ESInet(760)는 라우팅을 보조하기 위해 UE(700)의 현재(814t)의 로케이션에 대해 ELS(794)에게 질의할 수 있다(도 7에 도시되지 않음). 그 후, ESInet(760)는 (716B)에서 i3 PSAP(780)에 호를 포워딩한다.
[00161] 718B에서, 호 설정의 나머지가 수행된다. 블록들(714A 및 716A) 및 블록들(714B 및 716B)은 도 2a의 블록(226A), 도 2b의 블록(234B) 또는 도 4의 메시지들의 전송(403A 및 403B)의 각각에 대응할 수 있다. 블록(718A) 및 블록(718B) 각각은 도 2a의 블록(228A) 또는 도 2b의 블록(236B)에 대응할 수 있다.
[00162] 720에서, UE(700)에 대한 LbyR이 716B에서 수신되었다면, i3 PSAP(780)는 LbyR에서 표시된 ELS(794)에 로케이션 요청을 전송함으로써 LbyR을 역참조하고 요청에 LbyR을 포함시킨다. 블록(720)은 도 4의 질의의 전송(404B)에 대응할 수 있다.
[00163] 722에서, ELS(794)는, 예컨대 제어 평면 또는 사용자 평면 로케이션 솔루션을 사용하여 UE(700)의 현재의 로케이션을 획득하기 위해 (720)에서 수신된 LbyR에 포함되는 정보(예컨대, UE(700)에 대한 로컬 또는 글로벌 아이텐티티 및 제어 평면 로케이션에 대한 서빙 MME/SGSN ID 또는 사용자 평면 로케이션에 대한 로컬 UE IP 어드레스)를 사용한다. 블록(722)은 UE(700)에 대한 로케이션을 결정하는 측면에서 도 2a의 블록들(218A 및/또는 222A), 또는 도 2b의 블록들(216B 내지 226B) 또는 블록(228B) 중 어느 하나와 유사하거나 동일할 수 있다.
[00164] 724에서, ELS(794)는 UE(700)에 대한 현재의 로케이션을 i3 PSAP(780)로 리턴한다. 블록들(720 및 724)은 도 2a의 블록(232A) 또는 도 2b의 블록(238B)에 대응할 수 있다.
[00165] 도 8은 본 개시내용의 적어도 하나의 양상에 따라 도 5를 참조하여 위에서 설명된 바와 같이 OTT SP를 통한 긴급 호에 대한 IMS LRF 지원을 위한 예시적인 호 흐름을 예시하며, 도 5와 연관하여 사전에 설명된 IMS LRF 지원에 대한 상호작용들을 확장시킬 수 있다. 도 8에 예시된 호 흐름은 도 5, 도 3, 도 1b 또는 도 1a에 예시된 아키텍처를 사용하여 수행될 수 있다. 그 결과, 도 8의 UE(800)는 도 1a의 UE들 1 내지 N, UE(200), UE(300), 또는 UE(500) 중 임의의 UE에 대응할 수 있다. 유사하게, OTT SP(850)는 OTT SP(150), OTT SP(350) 또는 OTT SP(550)에 대응할 수 있다. 유사하게, AN/PCN(892)은 MNO(590)의 AN(520) 및 PCN 부분, AN(320) 및 PCN(340) 또는 AN(120) 및 CN(140)에 대응할 수 있고, 액세스 네트워크 노드(240)를 포함할 수 있다. 유사하게, IMS(894)는 IMS(540), PCN(340) 내의 IMS 또는 CN(140) 내의 IMS에 대응할 수 있다. 유사하게, 중간 CS 목적지(863)는 SR(563), SR(360) 또는 SR(160)에 대응할 수 있다. 유사하게, ESInet(860)는 ESInet(560), ESInet(360) 또는 ESInet(160)에 대응할 수 있다. 유사하게, i3 PSAP(880)는 i3 PSAP(580), PSAP(380) 또는 PSAP(180)에 대응할 수 있다. 유사하게, 레거시 PSAP(882)는 레거시 PSAP(582), PSAP(380) 또는 PSAP(180)에 대응할 수 있다. 유사하게, 서빙 MNO(890)는 서빙 MNO(590)에 대응할 수 있다.
[00166] 도 9는 본 개시내용의 적어도 하나의 양상에 따라 도 6을 참조하여 위에서 설명된 바와 같이 OTT SP를 통한 긴급 호에 대한 IMS E-CSCF 지원을 위한 예시적인 호 흐름을 예시하며, 도 6과 연관하여 앞서 설명된 IMS E-CSCF 지원에 대한 상호작용들을 확장시킬 수 있다. 도 9에 예시된 호 흐름은 도 6, 도 3, 도 1b 또는 도 1a에 예시된 아키텍처를 사용하여 수행될 수 있다. 그 결과, 도 9의 UE(900)는 도 1a의 UE들 1 내지 N, UE(200), UE(300), 또는 UE(600) 중 임의의 UE에 대응할 수 있다. 유사하게, OTT SP(950)는 OTT SP(150), OTT SP(350) 또는 OTT SP(650)에 대응할 수 있다. 유사하게, AN/PCN(992)은 MNO(690)의 AN(620) 및 PCN 부분, AN(320) 및 PCN(340) 또는 AN(120) 및 CN(140)에 대응할 수 있고, 액세스 네트워크 노드(240)를 포함할 수 있다. 유사하게, IMS(994)는 IMS(640), PCN(340) 내의 IMS 또는 CN(140) 내의 IMS에 대응할 수 있다. 유사하게, SR(963)은 SR(663), SR(360) 또는 SR(160)에 대응할 수 있다. 유사하게, ESInet(960)는 ESInet(660), ESInet(360) 또는 ESInet(160)에 대응할 수 있다. 유사하게, i3 PSAP(980)는 i3 PSAP(680), PSAP(380) 또는 PSAP(180)에 대응할 수 있다. 유사하게, 레거시 PSAP(982)는 레거시 PSAP(682), PSAP(380) 또는 PSAP(180)에 대응할 수 있다. 유사하게, 서빙 MNO(990)는 서빙 MNO(690)에 대응할 수 있다.
[00167] 도 8 및 도 9에 예시된 호 흐름들은 유사하며, IMS(894/994) 외부의 엔티티들(예컨대, UE(800/900) 및 OTT SP(850/950))의 측면에서 단일 공통 솔루션의 일부로서 관측될 수 있다. IMS(894/994)가 도 8 및 도 9의 호 흐름들에서 상이하게 거동하지만, 호 흐름들 둘 모두 내의 IMS(894/994)와 OTT SP(850/950) 간의 상호작용들은 (예컨대, IETF RFC 3261의) SIP의 IETF 정의를 준수할 수 있으며, 그에 따라서 SIP 프록시로 동작하는 OTT SP(850/950)에 의해 둘 모두 지원될 수 있다. 그 경우에서, OTT SP(850/950)는 서빙 MNO(890/990)(또는 서빙 MNO(890/990)의 IMS(894/994))가 도 8에서와 같이 IMS LRF 지원을 이용할 것인지 또는 도 9에서와 같이 IMS E-CSCF 지원을 이용할 것인지 여부를 사전에 알 필요가 없을 수 있다. 대신, OTT SP(850/950)는 IMS LRF 지원이 제공될지 또는 IMS E-CSCF 지원이 제공될지 여부에 의존하여 미리 구성된 SIP 법칙들에 따라 간단히 반응할 수 있다. 이것은, UE(800/900) 또는 OTT SP(850/950)로부터 지원하기 위한 변화들을 요구하지 않으면서 IMS LRF 지원으로부터 IMS E-CSCF 지원으로 또는 그 역으로 서빙 MNO(890/990)가 전환하게 할 수 있다. 그것은 또한, OTT(850/950)가 긴급 호들에 대해 하나 또는 그 초과의 MNO들(예컨대, MNO(890))로부터 도 8에 따른 IMS LRF 지원을 수신하고 하나 또는 그 초과의 다른 MNO들(예컨대, MNO(990))로부터 도 9에 따른 IMS E-CSCF 지원을 수신하게 할 수 있으며, 그 긴급 호들은 이들 MNO들 중 하나로부터 OTT SP(850/950)에 액세스하는 상이한 UE들(예컨대, UE(800) 및 UE(900))에 의해 발신될 수 있다.
[00168] 도 8 및 9의 호 흐름들은 도 3의 솔루션 S1에 적용된다. 도 3의 솔루션 S2에 대해, 호 흐름들은 각각의 호 흐름의 806/906에서 아래에 설명된 긴급 호 요청이 UE 데이터 및/또는 MNO 데이터 중 일부 또는 전부를 포함하지는 않을 것이라는 점을 제외하고는 거의 동일할 수 있다. 대신, OTT SP(850/950)는 (예컨대, 요청을 포함하는 SIP INFO를 UE(800/900)에 전송함으로써 그리고 UE(800/900)가 요청된 UE 데이터 및/또는 MNO 데이터를 SIP OK 또는 SIP INFO를 통해 리턴함으로써) 806/906에 후속하여 UE 데이터 및/또는 MNO 데이터에 대해 UE(800/900)에게 질의할 것이다. 솔루션 S2에 대해, OTT SP(850/950)는 또한, UE(800/900)가 도 8의 826 및 도 9의 920에서 전송하는 업데이트된 MNO 데이터에 대해 UE(800/900)에게 질의할 필요가 있을 수 있다. 그러나, 이러한 요청은 806/906에 후속하여 UE(800/900)로 초기에 전송된 UE 데이터 및 MNO 데이터에 대한 (위에서 언급된) 요청과 묵시적으로 또는 명시적으로 결합될 수 있다.
[00169] 부가하여, 도 3의 솔루션(S2)에 대해, UE(800/900)는 도 8 및 도 9의 806/906 이전에 사용자가 긴급 호를 착수했다는 것을 검출하지 않을 수 있으며(예컨대, 사용자가 "911"과 같은 긴급전화 번호를 다이얼링했다는 것을 인식하지 않을 수 있으며), 도 8 및 도 9의 806/906에서 OTT SP(850/950)에 정상 호 요청을 전송하고 긴급 호 요청은 전송하지 않을 수 있다. 이후, OTT SP(850/950)는 806/906에서 전송된 호 요청이 긴급 호에 대한 것임을 인식할 수 있으며(예컨대, 다이얼링된 번호들이 "911"과 같은 긴급전화 번호에 대한 것임을 검출할 수 있으며), 도 8 및 도 9에 도시된 808/908로 진행하기 이전에, UE(800/900)로부터의 MNO 데이터 및/또는 UE 데이터를 요청할 수 있다. 단지 도 3의 솔루션(S2)에 대해 설명된 바와 같이 수정되지 않은 도 8 및 도 9의 다른 동작들은 아래에서 설명되는 바와 같이 발생할 수 있다.
[00170] 도 8에 도시된 상호작용들은, UE(800)가 서빙 MNO(890)에 액세스하고 있는(예컨대, 서빙 MNO(890)를 통해 OTT SP(850)에 액세스하고 있는) 상황들에서, OTT SP(850)를 통해 긴급 호를 착수하는 UE(800)에 적용될 수 있다. 도 8의 802에서, UE(800)는, OTT SP(850)를 사용하는 긴급 호를 지원하기 위해, 서빙 MNO(890)의 AN 또는 PCN(892)으로부터의 데이터를 요청할 수 있다. 예컨대, 이는 사용자가 긴급 호를 착수하고 있다는 것을 UE(800)가 검출할 때 발생할 수 있다. 블록(802)은 선택적이며, 항상 발생하는 것은 아닐 수 있다.
[00171] 804에서, 802에 대한 응답으로, 또는 특정 조건들이 발생할 때(예컨대, UE(800)가 AN/PCN(892)에 어태치될 때, 새로운 MME 또는 SGSN에 대한 추적 영역 또는 라우팅 영역 업데이트를 수행할 때, 또는 새로운 MME 또는 SGSN으로의 핸드오버가 발생할 때), AN 또는 PCN(892)은 MNO 데이터를 UE(800)에 전송한다. MNO 데이터는 (i) 서빙 MNO(890)에 대한 IMS 어드레스(예컨대, IMS(894)의 LRF의 어드레스), (ⅱ) 제어 평면 로케이션이 사용될 수 있다면, UE(800)에 대한 현재 서빙 MME 또는 현재 서빙 SGSN에 대한 아이덴티티, (ⅲ) 사용자 평면 로케이션이 사용될 수 있다면, UE(800)에 대한 MNO 할당 IP 어드레스, 및/또는 (ⅳ) UE(800)에 대한 서빙 MME 또는 서빙 SGSN에 의해 할당된, UE(800)에 대한 로컬 아이덴티티 또는 UE(800)에 대한 글로벌 아이덴티티(예컨대, IMSI 또는 MSISDN)를 포함할 수 있다.
[00172] 806에서, UE(800)의 사용자가 긴급 호를 착수했다는 것을 UE(800)가 검출하는 것에 대한 응답으로(예컨대, 사용자가 "911"이란 번호들을 다이얼링했다는 것을 UE(800)가 검출하면), UE(800)는 긴급 호 요청을 OTT SP(850)에 전송하며, 804에서 획득된 MNO 데이터 및 어쩌면 UE(800)에 알려진 부가적인 UE 데이터를 포함시킨다. UE 데이터는, 804에서 수신되지 않았다면, UE(800)에 대한 글로벌 아이덴티티(예컨대, IMSI 또는 MSISDN) 및 어쩌면 UE(800)에 대한 MNO 할당 IP 어드레스를 포함할 수 있다. 806에서의 긴급 호 요청은 SIP INVITE일 수 있거나, 또는 OTT SP(850)에 특정한 어떤 다른 프로토콜에 대한 메시지일 수 있다. 블록(806)은 도 5의 긴급 호 요청(501)의 전송에 대응할 수 있다.
[00173] 808에서, 서빙 MNO(890)에서 IMS 어드레스의 806에서의 수신에 기반하여(예컨대, IMS 어드레스가 806에서 수신된 MNO 데이터의 일부일 수 있으며, 806에서 전송된 SIP INVITE의 루트 헤더에 포함된 LRF 어드레스일 수 있는 경우), OTT SP(850)는 서빙 MNO(890)의 IMS 어드레스에 의해 표시된 IMS(894)(예컨대, IMS(894)의 LRF)에 SIP INVITE를 전송한다. SIP INVITE는 806에서 수신된 MNO 데이터 및 임의의 UE 데이터를 포함하고, 긴급 호를 표시하며, OTT SP(850)의 아이덴티티 및 어쩌면 로케이션(예컨대, 나라)을 포함한다. SIP INVITE는 806에서 수신된 임의의 SIP INVITE의 부분적 또는 완전한 카피일 수 있다. 블록(808)은 도 5의 SIP INVITE(502A)의 전송에 대응할 수 있다.
[00174] 일부 경우들에서, 808에서 전송된 SIP INVITE는, IMS(894)의 LRF(도 8에 도시되지 않음)에 포워딩되기 이전에, 보안을 위해, 서빙 MNO IMS(894)의 경계 제어 기능(예컨대, IBCF)에 먼저 수신될 수 있다. IMS(894)(예컨대, IMS(894)의 LRF 또는 IBCF)는 먼저, 예컨대, 서빙 MNO(890)와 OTT SP(850) 간의 임의의 비즈니스 관계에 기반하는 미리 구성된 데이터를 사용하여, 그리고 어쩌면, 808에서 SIP INVITE를 전달하기 위한, OTT SP(850)와 서빙 MNO IMS(894) 간의 보안 IP 연결을 사용하여, 808에서 전송된 SIP INVITE가 유효한 OTT SP로부터 나온 것인지를 검증할 수 있다. 일부 경우들에서는, 810에서, IMS(894)(예컨대, IMS(894)의 LRF)는, 예컨대 제어 평면 또는 사용자 평면 로케이션 솔루션을 사용하여, UE(800)에 대한 로케이션을 획득하기 위해, 808에서 전송된 MNO 데이터 및 임의의 UE 데이터를 사용한다. 어떤 다른 경우들에서, 블록(810)은 발생하지 않으며, IMS(894)는 808에서 SIP INVITE를 통해 수신된 다른 데이터, 이를테면 UE(800)에 의해 806에서 전송된 긴급 호 요청에 포함되었고 808에서 OTT SP(850)에 의해 IMS(894)에 전달된 LbyV로부터 UE(800)에 대한 로케이션(예컨대, 근사 로케이션)을 결정할 수 있다.
[00175] 이후, IMS(894)(예컨대, IMS(894)의 RDF)는 UE(800)에 대한 로케이션에 대응하는 목적지 PSAP(880/882) 또는 목적지 PSAP(880/882)를 향한 루트를 결정하며, OTT SP(850)로부터 목적지 PSAP(880/882)로의, 또는 목적지 PSAP(880/882)를 향한 호 라우팅을 가능하게 하기 위해 라우팅 URI(루트 URI로 또한 지칭될 수 있음)를 도출한다. 라우팅 URI는 PSAP(880/882) 또는 중간 목적지(863)(예컨대, 레거시 PSAP(882)의 경우 SR, 또는 i3 가능 PSAP(880)의 경우 ESInet(860)으로의 진입점)의 어드레스 또는 아이덴티티를 포함할 수 있으며, OTT SP(850) 아이덴티티 및/또는 OTT SP(850) 로케이션(예컨대, 로케이션이 서빙 MNO(890)와 동일한 나라에 있든 또는 상이한 나라에 있든 간에)에 따라 좌우될 수 있다. IMS(894)(예컨대, IMS(894)의 LRF)는 또한, 나중의 시간에 ESInet(860)으로부터의 또는 PSAP(880/882)로부터의, UE(800)에 대한 후속 로케이션 요청을 가능하게 하기 위해 레퍼런스 ID(identifier)를 결정한다. 레퍼런스 ID는 레거시 PSAP(882)의 경우 (i) ESRK 또는 (ⅱ) ESRD + MSISDN일 수 있거나, 또는 i3 가능 PSAP(880)의 경우 (ⅲ) 로케이션 URI일 수 있다.
[00176] 812에서, IMS(894)(예컨대, IMS(894)의 LRF)는 SIP 300 다중 선정 메시지에서 라우팅 URI 및 레퍼런스 ID를 OTT SP(850)에 리턴한다. OTT SP(850)의 아이덴티티가 완전히 검증되지 않았다면, 또는 OTT SP(850)와의 비즈니스 관계가 단지 서빙 MNO(890)에 의한 라우팅 지원만을 허용한다면, IMS(894)가 로케이션(예컨대, LbyV)을 OTT SP(850)에 리턴하지 않을 수 있다는 것에 주목하라. 블록(812)은 도 5의 SIP 300 다중 선정들(502B)의 전송에 대응할 수 있다.
[00177] 814에서, IMS(894)(예컨대, IMS(894)의 LRF)가 제어 평면 로케이션을 사용할 필요가 있을 수 있다면, IMS(894)는 MNO 데이터의 변화들(예컨대, 서빙 MME 또는 서빙 SGSN 어드레스의 변화)에 대한 통지에 가입하기 위해 SIP SUBSCRIBE 메시지를 OTT SP(850)에 전송한다. IMS(894)는 또한, 호 종결의 통지(도 8에 도시되지 않음)에 가입하기 위해 별개의 SIP SUBSCRIBE 메시지를 OTT SP(850)에 전송할 수 있다.
[00178] 816에서는, 814가 발생하면, OTT SP(850)는 200 OK 메시지(도 8에 도시되지 않음)를 IMS(894)에 리턴하며, 이후, 814에서 MNO 데이터에 대한 가입의 경우 현재 MNO 데이터 및/또는 호 종결에 대한 가입의 경우 현재 호 상태를 반송하는, 수신된 각각의 SUBSCRIBE 메시지에 대한 NOTIFY 메시지를 리턴한다.
[00179] 812 이후에(그리고 어쩌면, 816이 발생하면, 816 이후에), OTT SP(850)는, 812에서 리턴된 라우팅 URI 또는 레퍼런스 ID의 콘텐츠로부터 목적지 PSAP가 레거시 PSAP(882)인지 또는 i3 가능 PSAP(880)인지의 여부를 결정한다. 레거시 PSAP(882)의 경우, OTT SP(850)는 PSAP(882)로의 또는 PSAP(882)를 향한 CS를 사용하여 호를 포워딩할 수 있다. 일 실시예에서, OTT SP(850)는 818A에서의 ISUP IAM 메시지를, 812에서 수신된 루트 URI에서 표시된 중간 CS 목적지(863)(예컨대, SR)에 전송한다. OTT SP(850)는 또한, 812에서 수신된 레퍼런스 ID의 임의의 ESRK 또는 ESRD + MSISDN을 ISUP IAM에 포함시킨다. 블록(818A)은 도 5의 요청(503A)의 전송에 대응할 수 있다.
[00180] 820A에서, 중간 CS 목적지(863)는 호를 레거시 PSAP(882)에 포워딩하며, 818A에서 수신된 ESRK 또는 ESRD + MSISDN을 포함시킨다.
[00181] 822A에서, 호 설정의 나머지가 수행된다. 이후, 블록들(818B, 820B 및 822B)은 수행되지 않는다.
[00182] OTT SP(850)가 812 이후에 레거시 PSAP(882) 대신에 i3 PSAP(880)를 결정할 때, 블록들(818A, 820A 및 822A)은 수행되지 않는다. 대신에, OTT SP(850)는 호를 PSAP(880)에 또는 PSAP(880)를 향해 포워딩한다. 일 실시예에서, OTT SP(850)는, 812에서 레퍼런스 ID에서 수신된 로케이션 URI를 포함하는 SIP INVITE를 전송함으로써, 818B에서의 호를, 812에서 수신된 라우팅 URI에 의해 표시된 ESInet(860)에 포워딩한다. 블록(818B)은 도 5의 요청(503B)의 전송에 대응할 수 있다.
[00183] 820B에서, ESInet(860)은 호를 i3 PSAP(880)에 포워딩하며, 818B에서 수신된 로케이션 URI를 포함시킨다.
[00184] 822B에서, 호 설정의 나머지가 수행된다.
[00185] 824에서, MNO 데이터의 변화가 있다면(예컨대, UE(800)가 새로운 SGSN 또는 MME로 핸드오버된다면), 그리고 서빙 MNO(890)가 UE(800)에 대한 제어 평면 로케이션을 사용할 수 있다면, AN 또는 PCN(892)은 새로운 MNO 데이터(예컨대, UE(800)에 대한 새로운 서빙 MME 또는 SGSN에 대한 아이덴티티, 그리고 새로운 서빙 MME 또는 SGSN에서의 UE(800)에 대한 새로운 로컬 아이덴티티)를 UE(800)에 전송한다. 824에서의 새로운 MNO 데이터의 전송은 MNO 데이터가 변할 때마다 자동일 수 있거나(예컨대, OTT SP(850)를 통해 UE(800)에 대한 긴급 호가 진행중이라는, 서빙 MNO(890)의 AN 또는 PCN(892)에 의한 어떠한 지식도 없이), 또는 802에서 MNO 데이터에 대한 요청을 앞서 전송했던 UE(800)에 의해 트리거링될 수 있다.
[00186] 826에서, UE(800)는, 예컨대, UE(800)와 OTT SP(850) 간에 SIP이 사용될 때 SIP INFO 메시지를 사용하여, 새로운 MNO 데이터를 OTT SP(850)에 포워딩한다.
[00187] 828에서, IMS(894)가, 814에서 MNO 데이터의 변화들에 대한 통지에 가입했다면, OTT SP(850)는 SIP NOTIFY 메시지에서 새로운 MNO 데이터를 IMS(894)(예컨대, IMS(894)의 LRF)에 전송한다. 새로운 MNO 데이터는 IMS(894)에 의한 미래의 사용을 위해 저장된다. 예컨대, 새로운 MNO 데이터는, UE(800)에 대한 로케이션을 획득하는 것을 돕기 위해 블록(832A) 또는 블록(832B)에서 나중에 사용될 수 있다.
[00188] 830A에서, 레거시 PSAP(882)의 경우, PSAP(882) 또는 PSAP(882)와 연관된 엔티티, 이를테면 ALI(예컨대, ALI(561))는 UE(800)의 로케이션을 요청하기 위해 E2 인터페이스 ESPOSREQ 메시지(예컨대, TIA/ATIS 조인트 표준 J-STD-036에서 정의됨)를, 820A에서 수신된 ESRK 또는 ESRD에 의해 표시된 IMS(894)(예컨대, LRF)에 전송할 수 있으며, 820A에서 수신된 ESRK 또는 ESRD + MSISDN을 포함시킨다. 블록(830A)은 도 5의 질의(504A)의 전송에 대응할 수 있다.
[00189] 832A에서, IMS(894)(예컨대, LRF)는, UE(800)를 식별하기 위해, 830A에서 수신된 ESRK 또는 MSISDN을 사용하며, 제어 평면 또는 사용자 평면 로케이션 솔루션을 사용하여 UE(800)에 대한 로케이션을 획득하기 위해, 808에서 수신된 임의의 UE 데이터, 및/또는 808 또는 828(828가 발생한다면)에서 수신된 MNO 데이터를 사용한다.
[00190] 834A에서, IMS(894)(예컨대, LRF)는 로케이션을 PSAP(882)(또는 PSAP(882)와 연관된 엔티티, 이를테면 ALI)에 리턴한다.
[00191] 830B에서, i3 가능 PSAP(880)의 경우, i3 PSAP(880)는, 로케이션 URI에서 표시된 IMS(894)(예컨대, IMS(894)의 LRF)에 로케이션 요청을 전송하고 로케이션 URI를 반송함으로써, 820B에서 수신된 로케이션 URI를 역참조한다. 블록(830B)은 도 5의 질의(504B)의 전송에 대응할 수 있다.
[00192] 832B에서, IMS(894)(예컨대, LRF)는, UE(800)를 식별하기 위해, 830B에서 수신된 로케이션 URI를 사용하며, 제어 평면 또는 사용자 평면 로케이션 솔루션을 사용하여 UE(800)에 대한 로케이션을 획득하기 위해, 808에서 수신된 임의의 UE 데이터, 및/또는 808 또는 828(828가 발생한다면)에서 수신된 MNO 데이터를 사용한다.
[00193] 834B에서, IMS(894)(예컨대, LRF)는 로케이션을 PSAP(880)에 리턴한다.
[00194] ESInet(860)로 하여금 IMS(894)로부터(예컨대, IMS(894)의 LRF로부터) UE(800)에 대한 로케이션을 획득하고, 이 로케이션에 기반하여, 820B에서의 긴급 호를 정확한 PSAP(880)에 라우팅하는 것을 가능하게 하기 위해, 830B, 832B 및 834B와 유사하거나 또는 동일한 블록들이 818B 이후에 발생할 수 있다. 그 경우, ESInet(860)(예컨대, ESInet(860)의 ESRP, 이를테면 ESRP(566))은 830B와 유사하거나 또는 동일한 블록에서 UE(800)에 대한 로케이션 요청을 IMS(894)에 전송할 수 있으며, 834B와 유사하거나 또는 동일한 블록에서 IMS(894)로부터 UE(800)에 대한 로케이션을 수신할 수 있다.
[00195] 도 9에 도시된 상호작용들은, UE(900)가 서빙 MNO(990)에 액세스하고 있는(예컨대, 서빙 MNO(990)를 통해 OTT SP(950)에 액세스하고 있는) 상황들에서, OTT SP(950)를 통해 긴급 호를 착수하는 UE(900)에 적용될 수 있다. 도 9의 902에서, UE(900)는, OTT SP(950)를 사용하는 긴급 호를 지원하기 위해, 서빙 MNO(990)의 AN 또는 PCN(992)으로부터의 데이터를 요청할 수 있다. 예컨대, 이는 사용자가 긴급 호를 착수하고 있다는 것을 UE(900)가 검출할 때 발생할 수 있다. 동작(902)은 선택적이며, 항상 발생하는 것은 아닐 수 있다.
[00196] 904에서, 902에 대한 응답으로, 또는 특정 조건들이 발생할 때(예컨대, UE(900)가 AN/PCN(992)에 어태치될 때, AN/PCN(992)의 새로운 MME 또는 SGSN에 대한 추적 영역 또는 라우팅 영역 업데이트를 수행할 때, 또는 새로운 MME 또는 SGSN으로의 핸드오버가 발생할 때), AN 또는 PCN(992)은 MNO 데이터를 UE(900)에 전송한다. MNO 데이터는 (i) 서빙 MNO(990)에 대한 IMS 어드레스(예컨대, IMS(994)의 E-CSCF의 어드레스), (ⅱ) 제어 평면 로케이션이 사용될 수 있다면, UE(900)에 대한 현재 서빙 MME 또는 현재 서빙 SGSN에 대한 아이덴티티, (ⅲ) 사용자 평면 로케이션이 사용될 수 있다면, UE(900)에 대한 MNO 할당 IP 어드레스, 및/또는 (ⅳ) UE(900)에 대한 서빙 MME 또는 서빙 SGSN에 의해 할당된, UE(900)에 대한 로컬 아이덴티티 또는 UE(900)에 대한 글로벌 아이덴티티(예컨대, IMSI 또는 MSISDN)를 포함할 수 있다.
[00197] 906에서, UE(900)의 사용자가 긴급 호를 착수했다는 것을 UE(900)가 검출하는 것에 대한 응답으로(예컨대, 사용자가 "911"이란 번호들을 다이얼링했다는 것을 UE(900)가 검출하면), UE(900)는 긴급 호 요청을 OTT SP(950)에 전송하며, 904에서 획득된 MNO 데이터 및 어쩌면 UE(900)에 알려진 부가적인 UE 데이터를 포함시킨다. UE 데이터는, 904에서 수신되지 않았다면, UE(900)에 대한 글로벌 아이덴티티(예컨대, IMSI 또는 MSISDN) 및 어쩌면 UE(900)에 대한 MNO 할당 IP 어드레스를 포함할 수 있다. 906에서의 긴급 호 요청은 SIP INVITE일 수 있거나, 또는 OTT SP(950)에 특정한 어떤 다른 프로토콜에 대한 메시지일 수 있다. 블록(906)은 도 6의 긴급 호 요청(601)의 전송에 대응할 수 있다.
[00198] 908에서, 906에서 수신된 MNO 데이터의 일부로서 IMS 어드레스의 수신에 기반하여(예컨대, 여기서, IMS 어드레스는 906에서 수신된 SIP INVITE의 루트 헤더 내의 E-CSCF 어드레스임), OTT SP(950)는 SIP INVITE를 서빙 MNO(990) 내의 IMS 어드레스에 의해 표시된 IMS(994)에(예컨대, IMS(994) 내의 E-CSCF에) 전송한다. 980에서 전송된 SIP INVITE는 906에서 수신된 MNO 데이터 및 임의의 UE 데이터를 포함하고, 긴급 호를 표시하며, 아이덴티티 및 가능하게는 OTT SP(950)의 로케이션(예컨대, 국가)을 포함한다. 908에서 전송된 SIP INVITE는 906에서 수신된 임의의 SIP INVITE의 부분적 또는 완전한 카피일 수 있다. 블록(908)은 도 6의 SIP INVITE(602)의 전송에 대응할 수 있다.
[00199] 일부 경우들에서, 908에서 전송된 SIP INVITE는 IMS(994) 내의 E-CSCF로 포워딩되기 전에(도 9에 미도시) 보안을 위해 서빙 MNO IMS(994) 내의 경계 제어 함수(예컨대, IBCF)에서 먼저 수신될 수 있다. IMS(994)(예컨대, IMS(994) 내의 E-CSCF 또는 IBCF)는, 예컨대, 서빙 MNO(990)와 OTT SP(950) 간의 일부 비즈니스 관계에 기반한 미리 구성된 데이터를 사용하여, 그리고 가능하게는, 908에서 SIP INVITE를 전달하기 위해 OTT SP(950)와 서빙 MNO IMS(994) 간의 보안 IP 연결을 사용하여, 908에서 전송된 SIP INVITE가 유효 OTT SP(950)로부터 나오는 것을 검증할 수 있다. 910에서의 일부 경우들에서, IMS(994)(예컨대, IMS(994) 내의 LRF)는, 예컨대, 제어 평면 또는 사용자 평면 로케이션 솔루션을 사용하여, UE(900)에 대한 로케이션을 획득하기 위해 908에서 수신된 MNO 데이터 및 임의의 UE 데이터를 사용할 수 있다. 일부 다른 경우에, 블록(910)은 발생하지 않으며, IMS(994)는 906에서 전송되어 908에서 IMS(994)에 OTT SP(950)에 의해 전달된 긴급 호 요청에 UE(900)에 의해서 포함된 LbyV와 같은 908에서 SIP INVITE를 통해 수신된 다른 데이터로부터의 UE(900)에 대한 로케이션(예컨대, 대략적 로케이션)을 결정할 수 있다.
[00200] 908 또는 910(910이 발생한다면)에 이어질 수 있는 911에서, IMS(994)(예컨대, IMS(994)의 RDF)는 목적지 PSAP(980/982), 또는 (예컨대, 910에서 획득된 바와 같은) UE(900) 로케이션에 대응하는 목적지 PSAP(980/982)를 향하는 루트를 결정하며, IMS(994)로부터 목적지 PSAP(980/982)로 또는 이를 향하는 호 라우팅을 가능하게 하기 위해 라우팅 URI(루트 URI로 또한 지칭됨)를 결정한다. 라우팅 URI는 (i) PSAP(980/982)의 어드레스 또는 아이덴티티 또는 (ii) 레거시 PSAP(982)의 경우 SR(963)과 같은 중간 목적지의 어드레스 또는 아이덴티티, 또는 i3 가능 PSAP(980)의 경우 ESInet(960)로의 진입 포인트를 표시할 수 있다. 911에서 목적지 PSAP(980/982) 또는 목적지 PSAP(980/982)를 향하는 루트를 결정하는 것의 일부로서, IMS(994)(예컨대, IMS(994) 내의 LRF)는 나중의 시간에 ESInet(960) 또는 PSAP(980/982)로부터의 UE(900)에 대한 후속적인 로케이션 요청을 가능하게 하기 위해 레퍼런스 식별자(ID)를 결정한다. 레퍼런스 ID는 (i) ESRK 또는 (ii) 레거시 PSAP(982)의 경우 ESRD 및 MSISDN, 또는 (iii) i3 가능 PSAP(980)의 경우 로케이션 URI일 수 있다. IMS(994)(예컨대, IMS(994) 내의 E-CSCF)는 또한, 911에서, 목적지 PSAP가 레거시 PSAP(982)인지 아니면 i3 가능 PSAP(980)인지를 결정한다(예컨대, 911에서 결정되었던 라우팅 URI 또는 레퍼런스 ID의 컨텐츠로부터).
[00201] 일부 구현들에서, 910(910이 발생한다면)에서의 UE(900)의 로케이션 및 911에서 라우팅 URI 및 레퍼런스 ID를 결정하는 것을 포함하는, 911에서의 목적지 PSAP 또는 목적지 PSAP를 향한 루트의 결정은 (예컨대, IMS(994)가 도 6에서 IMS(640)에 대응하면) IMS(994)에서 LRF(예컨대, LRF(648))에 의해 수행, 어쩌면 RDF(예컨대, RDF(646))에 의해 보조될 수 있다. 이 구현들에서, 908에서 전송된 SIP INVITE는 IMS(994)에서 E-CSCF(예컨대, E-CSCF(643))에 의해 수신될 수 있고, 그 다음, E-CSCF에 의해 IMS(994)에서 LRF(예컨대, LRF(648))로 포워딩될 수 있다. 그 다음, IMS(994)의 LRF(예컨대, LRF(648))는 910(910이 발생한다면)에서 UE(900)에 대한 로케이션을 획득하고, 라우팅 URI 및 레퍼런스 ID를 결정하는 것을 포함하여 911에서 목적지 PSAP를 결정하고, SIP(300)의 다중 선정 메시지에서 결정된 라우팅 URI 및 레퍼런스 ID를 다시 IMS(994)의 E-CSCF(예컨대, E-CSCF(643))에 리턴할 수 있다. 도 9에 도시되지는 않았지만, IMS(994) 내의 E-CSCF(예컨대, E-CSCF(643))와 LRF(예컨대, LRF(648)) 간의 상호작용은 도 6과 연관하여 설명되었던 E-CSCF(643)와 LRF(648) 간의 요청(603A) 및 응답(603B)을 전송하는 것에 대응할 수 있다.
[00202] 911에서 레거시 PSAP(982)를 결정하는 경우에, IMS(994)(예컨대, IMS(994) 내의 MGCF)는 912A에서 CS를 사용하여 호를 PSAP(982)로 또는 이를 향해 포워딩할 수 있다. 일 실시예에서, IMS(994)는 908 또는 910(910이 발생하면) 이후에 결정된 라우팅 URI에서 표시된 912A에서의 ISUP IAM 메시지를 SR(963)에 전송한다. IMS(994)는 또한, 911에서 결정된 레퍼런스 ID에서 표시된 임의의 ESRK 또는 ESRD 및 MSISDN을 ISUP IAM에 포함시킨다.
[00203] 914A에서, SR(963)은 호를 레거시 PSAP(982)로 포워딩하며, 912A에서 수신된 ESRK 또는 ESRD 및 MSISDN을 포함한다.
[00204] 916A에서, 호 설정의 나머지가 UE(900), OTT SP(950), IMS(994), SR(963) 및 레거시 PSAP(982) 간에 수행된다. 그 다음, 블록들(912B, 914B 및 916B)은 수행되지 않는다.
[00205] IMS(994)가 911에서 레거시 PSAP(982) 대신에 i3 PSAP(980)를 결정하는 경우, 블록들(912A, 914A 및 916A)은 수행되지 않는다. 대신에, 912B에서, IMS(994)(예컨대, IMS(994) 내의 E-CSCF)는 긴급 호를 PSAP(980)로 또는 이를 향해 포워딩한다. 일 실시예에서, IMS(994)는 911에서 결정된 레퍼런스 ID로부터의 로케이션 URI를 포함하는 SIP INVITE를 전송함으로써 911에서 결정된 라우팅 URI에 의해 표시된 긴급 호를 ESInet(960)으로 포워딩한다.
[00206] 914B에서, ESInet(960)는 긴급 호를 i3 PSAP(980)로 포워딩하며, 912B에서 수신된 로케이션 URI를 포함한다.
[00207] 916B에서, 호 설정의 나머지는 UE(900), OTT SP(950), IMS(994), ESInet(960) 및 i3 PSAP(980) 간에 수행된다.
[00208] 918에서, MNO 데이터의 변화가 존재하면(예컨대, UE(900)가 서빙 MNO(990)에서 새로운 SGSN 또는 MME로 핸드오버됨) 그리고 서빙 MNO(990)가 UE(900)에 대한 제어 평면 로케이션을 사용할 수 있으면, AN 또는 PCN(992)은 새로운 MNO 데이터(예컨대, UE(900)에 대한 새로운 서빙 MME 또는 새로운 SGSN에 대한 아이덴티티 및 새로운 서빙 MME 또는 SGSN에서의 UE(900)에 대한 로컬 아이덴티티)를 UE(900)에 제공한다. 이 새로운 MNO 데이터의 전송은 MNO 데이터가 변화할 때마다(예컨대, OTT SP(950)를 통해 UE(900)에 대한 긴급 호가 진행 중임을 서빙 MNO(990) 내의 AN 또는 PCN(992)에 의해 알지 못함) 자동적일 수 있거나, 또는 902에서 요청을 이전에 전송하였던 UE(900)에 의해 트리거될 수 있다.
[00209] 920에서, UE(900)는, 예컨대, SIP가 UE(900)와 OTT SP(950) 간에 사용되는 경우 SIP INFO 메시지를 사용하여, 새로운 MNO 데이터를 OTT SP(950)로 포워딩한다.
[00210] 922에서, OTT SP(950)는, 예컨대, SIP INFO 메시지를 사용하여, 새로운 MNO 데이터를 IMS(994)로(예컨대, IMS(994) 내의 E-CSCF로) 포워딩한다. MNO 데이터는 IMS(994)에 의한(예컨대, IMS(994) 내의 LRF에 의한) 향후 사용을 위해 저장된다.
[00211] 924A에서, 레거시 PSAP(982)의 경우, PSAP(982) 또는 PSAP(982)와 연관된 엔티티(예컨대, ALI, 이를테면, ALI(661))는 UE(900)의 로케이션을 요청하기 위해 914A에서 수신된 ESRK 또는 ESRD에 의해 표시된 바와 같은 E2 인터페이스 ESPOSREQ 메시지(예컨대, TIA/ATIS 표준 J-STD-036에서 정의된 바와 같음)를 IMS(994)(예컨대, , IMS(994) 내의 LRF)에 전송할 수 있으며, 914A에서 수신된 ESRK 또는 ESRD 및 MSISDN을 포함한다. 블록(924A)은 도 6의 로케이션 요청(605A)의 전송에 대응할 수 있다.
[00212] 926A에서, IMS(994)(예컨대, IMS(994) 내의 LRF)는 UE(900)를 식별하기 위해 924A에서 수신된 ESRK 또는 MSISDN을 사용하고, 제어 평면 또는 사용자 평면 로케이션 솔루션을 사용하여 UE(900)에 대한 로케이션을 획득하기 위해 908에서 수신된 임의의 UE 데이터 및/또는 908 또는 922(922가 발생한다면)에서 수신된 MNO 데이터를 사용한다.
[00213] 928A에서, IMS(994)(예컨대, IMS(994) 내의 LRF)는 UE(900)에 대한 로케이션을 레거시 PSAP(982)로(또는 PSAP(982)와 연관된 엔티티, 이를테면, ALI로) 리턴한다.
[00214] 924B에서, i3 가능 PSAP(980)의 경우, i3 PSAP(980)는 로케이션 URI에서 표시된 로케이션 요청을 IMS(994)(예컨대, IMS(994) 내의 LRF)에 전송하고, 로케이션 URI를 반송함으로써 914B에서 수신된 로케이션 URI를 역참조한다. 블록(924B)은 도 6의 로케이션 요청(605B)의 전송에 대응할 수 있다.
[00215] 926B에서, IMS(994)(예컨대, IMS(994) 내의 LRF)는 UE(900)를 식별하기 위해 924B에서 수신된 로케이션 URI를 사용하고, 제어 평면 또는 사용자 평면 로케이션 솔루션을 사용하여 UE(900)에 대한 로케이션을 획득하기 위해 908에서 수신된 임의의 UE 데이터 및/또는 908 또는 922(922가 발생한다면)에서 수신된 MNO 데이터를 사용한다.
[00216] 928B에서, IMS(994)(예컨대, IMS(994) 내의 LRF)는 UE(900)에 대한 로케이션을 i3 가능 PSAP(980)로 리턴한다.
[00217] 924B, 926B 및 928B과 유사하거나 또는 동일한 블록들은 ESInet(960)가 IMS(994)로부터의(예컨대, IMS(994) 내의 LRF로부터의) UE(900)에 대한 로케이션을 획득하는 것을 가능하게 하기 위해 912B 이후에 발생할 수 있으며, 로케이션에 기반하여 914B에서의 긴급 호를 정확한 PSAP(980)로 라우팅할 수 있다. 그 경우, ESInet(960)(예컨대, ESInet(860) 내의 ESRP, 이를테면, ESRP(666))는 924B와 유사하거나 또는 동일한 블록에서 UE(900)에 대한 로케이션 요청을 IMS(994)에 전송할 수 있으며, 928B와 유사하거나 또는 동일한 블록에서 IMS(994)로부터 UE(900)에 대한 로케이션을 수신할 수 있다.
[00218] 도 4-9와 연관하여 설명된 절차들 및 기법들은 긴급 호를 착수하였던 UE가 OTT SP가 PSAP로 또는 IMS 엔티티, 이를테면, LRF(예컨대, 도 8의 828에서와 같음) 또는 E-CSCF(예컨대, 도 9의 922에서와 같음)로 업데이트를 포워딩하는 것을 가능하게 하기 위해 (예컨대, 도 4 및 도 7에 대한) LbyR로의 임의의 업데이트들 또는 (예컨대, 도 8의 826에서 그리고 도 9의 920에서와 같은) MNO 데이터로의 임의의 업데이트들을 UE에 대한 OTT SP에 전송하는 것에 의존할 수 있다는 점이 주목되어야 한다. 그러나, 대안적인 실시예들에서, 업데이트된 LbyR 또는 업데이트된 MNO 데이터(예컨대, 긴급 호를 착수하였던 UE가 새로운 SGSN 또는 새로운 MME로 핸드오버된 이후 발생할 수 있음)는 UE에 의해서라기 보다는 서빙 MNO 내의 AN 또는 PCN에 의해(예컨대, AN 또는 PCN 내의 MME 또는 SGSN에 의해) 서빙 MNO 내의 PSAP로 또는 IMS 엔티티(이를테면, LRF 또는 E-CSCF)로 전송될 수 있다. 이것은, 예컨대, 긴급 호를 착수하였던 UE에 대한 서빙 MNO 내의 IMS 엔티티 또는 이것(예컨대, GMLC)과 연관된 엔티티가 UE가 긴급 호를 착수하고 있음을 검출한 이후에(예컨대, 각각, 도 7, 도 8 및 도 9 각각에서의 708, 808 및 908 이후) 임의의 업데이트된 LbyR 또는 업데이트된 MNO 데이터에 대한 요청을 서빙 MNO AN 또는 PCN 내의 엔티티로(예컨대, MME 또는 SGSN으로) 전송하는 경우, 발생할 수 있다. 이 대안적인 실시예들에 있어서, 업데이트된 LbyR 또는 업데이트된 MNO 데이터는 긴급 호를 착수하였던 UE에 의해 OTT SP에 그리고 OTT SP에 의해 PSAP에 또는 IMS 엔티티, 이를테면, LRF 또는 E-CSCF에 전송될 필요가 없을 수 있다.
[00219] 도 10은 본원에서 교시된 바와 같은 동작들을 지원하기 위해 장치(1002), 장치(1004), 및 장치(1006)(예컨대, 사용자 디바이스, 이를테면, UE(200, 300, 400, 500, 600, 700, 800 또는 900), 액세스 네트워크 노드, 이를테면, 액세스 네트워크 노드(240), 및 네트워크 엔티티, 이를테면, OTT SP(150), 로케이션 서버(170) 등에 각각 대응함)로 통합될 수 있는 몇몇 샘플 컴포넌트들(대응하는 블록들에 의해 표현됨)을 예시한다. 이 컴포넌트들이 상이한 구현들에서 상이한 타입들의 장치들로(예컨대, ASIC로, SoC로 등) 구현될 수 있다는 것이 인지될 것이다. 예시된 컴포넌트들은 또한 통신 시스템 내의 다른 장치들로 통합될 수 있다. 예컨대, 시스템 내의 다른 장치들은 유사한 기능을 제공하기 위해 설명된 컴포넌트들과 유사한 컴포넌트들을 포함할 수 있다. 또한, 주어진 장치는 컴포넌트들 중 하나 또는 그 초과의 컴포넌트들을 포함할 수 있다. 예컨대, 장치는 장치가 다수의 캐리어들 상에서 동작하고 그리고/또는 상이한 기술들을 통해 통신하는 것을 가능하게 하는 다수의 트랜시버 컴포넌트들을 포함할 수 있다.
[00220] 장치(1002) 및 장치(1004)는 각각, 적어도 하나의 지정된 RAT를 통해 다른 노드들과 통신하기 위한 적어도 하나의 무선 통신 디바이스(통신 디바이스들(1008 및 1014)(및 장치(1004)가 중계기라면 통신 디바이스(1020))에 의해 표현됨)를 포함한다. 각각의 통신 디바이스(1008)는 신호들(예컨대, 메시지들, 표시들, 정보 등)을 송신 및 인코딩하기 위한 적어도 하나의 송신기(송신기(1010)에 의해 표현됨) 및 신호들(예컨대, 메시지들, 표시들, 정보, 파일럿들 등)을 수신 및 디코딩하기 위한 적어도 하나의 수신기(수신기(1012)에 의해 표현됨)를 포함한다. 유사하게, 각각의 통신 디바이스(1014)는 신호들(예컨대, 메시지들, 표시들, 정보, 파일럿들 등)을 송신하기 위한 적어도 하나의 송신기(송신기(1016)에 의해 표현됨) 및 신호들(예컨대, 메시지들, 표시들, 정보 등)을 수신하기 위한 적어도 하나의 수신기(수신기(1018)에 의해 표현됨)를 포함한다. 장치(1004)가 중계국이라면, 각각의 통신 디바이스(1020)는 신호들(예컨대, 메시지들, 표시들, 정보, 파일럿들 등)을 송신하기 위한 적어도 하나의 송신기(송신기(1022)에 의해 표현됨) 및 신호들(예컨대, 메시지들, 표시들, 정보 등)을 수신하기 위한 적어도 하나의 수신기(수신기(1024)에 의해 표현됨)를 포함할 수 있다.
[00221] 송신기 및 수신기는, 일부 구현들에서 통합된 디바이스(예컨대, 단일 통신 디바이스의 송신기 회로 및 수신기 회로로서 구현됨)를 포함할 수 있거나, 일부 구현들에서 별개의 송신기 디바이스 및 별개의 수신기 디바이스를 포함할 수 있거나, 또는 다른 구현들에서 다른 방식들로 구현될 수 있다. 장치(1004)의 무선 통신 디바이스(예컨대, 다수의 무선 통신 디바이스들 중 하나)는 또한 다양한 측정들을 수행하기 위한 NLM(Network Listen Module) 등을 포함할 수 있다.
[00222] 장치(1006)(및 장치(1004)(중계 스테이션이 아닌 경우))는 다른 노드들과 통신하기 위해 적어도 하나의 통신 디바이스(통신 디바이스(1026, 및 선택적으로, 1020)에 의해 표현됨)를 포함한다. 예컨대, 통신 디바이스(1026)는 유선-기반 또는 무선 백홀을 통해 하나 또는 그 초과의 네트워크 엔티티들과 통신하도록 구성된 네트워크 인터페이스를 포함할 수 있다. 일부 양상들에서, 통신 디바이스(1026)는 유선-기반 또는 무선 신호 통신을 지원하도록 구성된 트랜시버로서 구현될 수 있다. 이러한 통신은, 예컨대, 메시지들, 파라미터들, 또는 다른 타입들의 정보를 전송하고 수신하는 것을 수반할 수 있다. 그에 따라서, 도 10의 예에서, 통신 디바이스(1026)는 송신기(1028) 및 수신기(1030)를 포함하는 것으로 도시된다. 유사하게, 장치(1004)가 중계 스테이션이 아닌 경우에, 통신 디바이스(1020)는 유선-기반 또는 무선 백홀을 통해 하나 또는 그 초과의 네트워크 엔티티들과 통신하도록 구성된 네트워크 인터페이스를 포함할 수 있다. 통신 디바이스(1026)와 같이, 통신 디바이스(1020)는 송신기(1022) 및 수신기(1024)를 포함하는 것으로 도시된다.
[00223] 장치들(1002, 1004, 및 1006)은 또한, 본원에서 교시되는 바와 같은 OTT SP 및 UE 로케이션 관련 동작들과 함께 사용될 수 있는 다른 컴포넌트들을 포함한다. 장치(1002)는, 예컨대, 본원에서 교시되는 바와 같은 OTT SP 및 UE 로케이션 관련 동작들을 지원하기 위한 사용자 디바이스 동작들에 관련된 기능성을 제공하기 위해, 그리고 다른 프로세싱 기능성을 제공하기 위해, 프로세싱 시스템(1032) 및 포지셔닝 모듈(1054)을 포함한다. 장치(1004)는, 예컨대, 본원에서 교시되는 바와 같은 OTT SP 및 UE 로케이션 관련 동작들을 지원하기 위한 액세스 네트워크 노드 동작들에 관련된 기능성을 제공하기 위해, 그리고 다른 프로세싱 기능성을 제공하기 위해, 프로세싱 시스템(1034) 및 포지셔닝 모듈(1056)을 포함한다. 장치(1006)는, 예컨대, 본원에서 교시되는 바와 같은 OTT SP 및 UE 로케이션 관련 동작들을 지원하기 위한 네트워크 동작들에 관련된 기능성을 제공하기 위해, 그리고 다른 프로세싱 기능성을 제공하기 위해, 프로세싱 시스템(1036) 및 포지셔닝 모듈(1058)을 포함한다.
[00224] 장치들(1002, 1004, 및 1006)은 정보(예컨대, 예비된 자원들, 임계치들, 파라미터들 등을 표시하는 정보)를 유지하기 위해, 각각, 메모리 컴포넌트들(1038, 1040, 및 1042)(예컨대, 각각 메모리 디바이스를 포함함)을 더 포함한다. 부가적으로, 장치들(1002, 1004, 및 1006)은 사용자에게 표시들(예컨대, 가청 및/또는 시각적 표시들)을 제공하기 위해, 그리고/또는 사용자 입력을 수신하기 위해(예컨대, 키패드, 터치 스크린, 마이크로폰 등과 같은 감지 디바이스의 사용자 실행 시), 각각, 사용자 인터페이스 디바이스들(1044, 1046, 및 1048)을 포함한다.
[00225] 편의를 위해, 장치들(1002, 1004, 및/또는 1006)은 본원에서 설명된 다양한 예들에 따라 구성될 수 있는 다양한 컴포넌트들을 포함하는 것으로 도 10에서 도시된다. 그러나, 예시된 블록들이 상이한 설계들에서 상이한 기능성을 가질 수 있다는 것이 인지될 것이다.
[00226] 도 10의 컴포넌트들은 다양한 방식들로 구현될 수 있다. 일부 구현들에서, 도 10의 컴포넌트들은, 예컨대, 하나 또는 그 초과의 프로세서들 및/또는 하나 또는 그 초과의 ASIC들(하나 또는 그 초과의 프로세서들을 포함할 수 있음)과 같은 하나 또는 그 초과의 회로들로 구현될 수 있다. 여기에서, 각각의 회로는 이러한 기능성을 제공하기 위해 회로에 의해 사용되는 정보 또는 실행가능한 코드를 저장하기 위해 적어도 하나의 메모리 컴포넌트를 사용할 수 있고 그리고/또는 통합할 수 있다. 예컨대, 블록들(1008, 1032, 1038, 1044, 및 1054)에 의해 표현된 기능성 중 일부 또는 전부는 장치(1002)의 프로세서 및 메모리 컴포넌트(들)에 의해 (예컨대, 프로세서 컴포넌트들의 적합한 구성에 의해 및/또는 적합한 코드의 실행에 의해) 구현될 수 있다. 유사하게, 블록들(1014, 1020, 1034, 1040, 1046, 및 1056)에 의해 표현된 기능성의 일부 또는 전부는 장치(1004)의 프로세서 및 메모리 컴포넌트(들)에 의해 (예컨대, 프로세서 컴포넌트들의 적합한 구성에 의해 및/또는 적합한 코드의 실행에 의해) 구현될 수 있다. 또한, 블록들(1026, 1036, 1042, 1048, 및 1058)에 의해 표현된 기능성의 일부 또는 전부는 장치(1006)의 프로세서 및 메모리 컴포넌트(들)에 의해 (예컨대, 프로세서 컴포넌트들의 적합한 구성에 의해 및/또는 적합한 코드의 실행에 의해) 구현될 수 있다. 예컨대, 포지셔닝 모듈들(1054, 1056, 및 1058)은 메모리에 저장된 실행가능한 모듈들일 수 있거나, 또는 프로세싱 시스템들(1032, 1034, 및 1036)에 커플링된 하드웨어/펌웨어 컴포넌트들일 수 있다.
[00227] 도 11은 개시내용의 적어도 하나의 양상에 따른 UE(1100)의 예시적인 컴포넌트들을 예시하는 블록 다이어그램이다. UE(1100)는 도 1a에서의 UE들(1 내지 N), UE(200), UE(300), UE(400), UE(500), UE(600), UE(700), UE(800), 또는 UE(900) 중 임의의 것에 대응할 수 있거나 또는 임의의 것을 표현할 수 있다. 도 11의 박스 다이어그램에서 예시된 다양한 특징들 및 기능들은 공통 버스(도 11에서는 도시되지 않음)를 사용하여 함께 연결될 수 있거나, 또는 프로세서(들)(1130)를 통해 (도 11에서 도시된 바와 같이) 연결될 수 있다. 당업자는 다른 연결들, 메커니즘들, 특징들, 기능들 등이 동작가능하게 커플링되고 실제 휴대가능 무선 디바이스를 구성하기 위해 필요에 따라 제공 및 적응될 수 있다는 것을 인지할 것이다. 추가로, 도 11의 예에서 예시된 특징들 또는 기능들 중 하나 또는 그 초과가 추가로 세분될 수 있거나, 또는 도 11에서 예시된 특징들 또는 기능들 중 2개 또는 그 초과가 조합될 수 있다는 것이 또한 인지된다.
[00228] UE(1100)는 하나 또는 그 초과의 안테나들(1112)에 연결될 수 있는 하나 또는 그 초과의 블루투스 트랜시버들(1114a)을 포함할 수 있다. 블루투스 트랜시버(1114a)는 블루투스 액세스 포인트(예컨대, 도 1a에서의 AP(125))와 통신하기 위해 그리고/또는 블루투스 액세스 포인트로의/로부터의 신호들을 검출하기 위해 적절한 디바이스들, 하드웨어, 및/또는 소프트웨어를 포함한다. 부가적으로 또는 대안적으로, UE(1100)는 하나 또는 그 초과의 안테나들(1112)에 연결될 수 있는 하나 또는 그 초과의 WAN(wide area network) 무선 트랜시버(들)(1114b)를 포함할 수 있다. WAN 트랜시버(들)(1114b)는 WAN-WAP(wireless access point)들과 통신하기 위해 그리고/또는 WAN-WAP(wireless access point)들로의/로부터의 신호들을 검출하기 위해, 그리고/또는 네트워크 내의 다른 무선 디바이스들(예컨대, 도 1a에서의 RAN(120)에서의 디바이스들)과 직접적으로 통신하기 위해 적절한 디바이스들, 하드웨어, 및/또는 소프트웨어를 포함한다. 일 양상에서, WAN 트랜시버(들)(1114b)는 LTE 시스템, WCDMA 시스템, CDMA2000 시스템, TDMA, GSM, 또는 임의의 다른 타입의 광역 무선 네트워킹 기술들과 통신하는데 적절할 수 있다. 부가적으로 또는 대안적으로, UE(1100)는 하나 또는 그 초과의 안테나들(1112)에 연결될 수 있는 하나 또는 그 초과의 WLAN 트랜시버들(1114c)을 포함할 수 있다. WLAN 트랜시버(들)(1114c)는 WLAN-WAP들과 통신하기 위해 그리고/또는 WLAN-WAP들로의/로부터의 신호들을 검출하기 위해, 그리고/또는 네트워크 내의 다른 무선 디바이스들(예컨대, 도 1a에서의 WiFi AP(125))과 직접적으로 통신하기 위해 적절한 디바이스들, 하드웨어, 및/또는 소프트웨어를 포함한다. 일 양상에서, WLAN 트랜시버(들)(1114c)는 하나 또는 그 초과의 무선 액세스 포인트들과 통신하는데 적절한 Wi-Fi(802.11x) 통신 시스템을 포함할 수 있고; 그러나, 다른 양상들에서, WLAN 트랜시버(1114c)는 다른 타입의 로컬 영역 네트워크 또는 개인 영역 네트워크를 포함할 수 있다. 부가적으로 또는 대안적으로, UE(1100)는 SPS 수신기(1114d)를 포함할 수 있다. SPS 수신기(1114d)는 (예컨대, GPS 또는 일부 다른 GNSS를 위한) 위성 신호들을 수신하기 위해 하나 또는 그 초과의 안테나들(1112)에 연결될 수 있다. SPS 수신기(1114d)는 SPS 신호들을 수신하고 프로세싱하기 위해 임의의 적절한 하드웨어 및/또는 소프트웨어를 포함할 수 있다. SPS 수신기(1114d)는 다른 시스템들로부터 적합하게 정보 및 동작들을 요청하고, 임의의 적절한 SPS 알고리즘에 의해 획득된 측정들을 사용하여 모바일 디바이스(1100)에 대한 포지션을 결정하는데 필요한 계산들을 수행한다. 부가적으로 또는 대안적으로, 예컨대, 울트라 와이드 밴드, 지그비, 무선 USB 등과 같은 임의의 다른 타입의 무선 네트워킹 기술들이 사용될 수 있다.
[00229] UE(1100)는 하나 또는 그 초과의 센서들(1120)을 포함할 수 있다. 하나 또는 그 초과의 센서들(1120)은 사용자의 포지션, 모션, 배향, 환경, 액티비티들, 또는 바이오메트릭들에 관한 데이터를 포함하는 사용자에 관한 데이터를 수집할 수 있다. 센서들은, 예컨대, 가상 센서들, 이를테면 보수계(1122a), 및 물리 센서들, 이를테면, 가속도계(1122b), 자이로스코프(1122c), 바이오메트릭 센서(1120d), 및/또는 임의의 수의 다양한 센서들(1122n)(예컨대, 온도계, 기압계, 습도계)을 포함할 수 있다.
[00230] UE(1100)는 하나 또는 그 초과의 프로세서들(1130)을 포함한다. 프로세서(들)(1130)는 블루투스 트랜시버(들)(1114a), WAN 트랜시버(들)(1114b), WLAN 트랜시버(들)(1114c), 및 SPS 수신기(1114d), 및 하나 또는 그 초과의 센서들(1120)에 연결될 수 있다. 프로세서(1130)는 다중-코어 프로세서일 수 있고, 단일 유닛으로서 예시되어 있지만, 프로세싱 기능들, 그리고 다른 계산 및 제어 기능성을 제공하는 하나 또는 그 초과의 마이크로프로세서들, 마이크로제어기들, 및/또는 디지털 신호 프로세서들을 포함할 수 있다.
[00231] 프로세서(들)(1130)는 UE(1100) 내에서 프로그램된 기능성을 실행하기 위한 데이터 및 소프트웨어 명령들을 저장하는 메모리(1140)에 커플링될 수 있다. 메모리(1140)는 프로세서(들)(1130)에 온-보드될 수 있고(예컨대, 동일한 집적 회로 패키지 내에 있을 수 있고), 그리고/또는 메모리(1140)는 프로세서(들)(1130)의 외부의 메모리일 수 있고, 데이터 버스를 통해 기능적으로 커플링될 수 있다. 메모리(1140)는 임의의 수의 네이티브 애플리케이션 모듈들(1142a...1142n) 및 오버-디-에어 업데이트 또는 임의의 다른 수단에 의한 다수의 외부에서 공급되는 모듈들, 및 임의의 수의 데이터 모듈들(1144a...1144n)을 포함할 수 있다. 도 11에서 도시된 바와 같은 메모리 콘텐츠의 조직은 단지 예시적인 것이고, 그에 따라, 데이터 구조들 및/또는 모듈들의 기능성이 UE(1100)의 구현에 따라 상이한 방식들로 조합, 분리, 및/또는 구조화될 수 있다는 것을 인지해야 한다. 메모리(1140)는 UE(1100)가 본원에서 설명된 다양한 절차들 및 기법들 중 일부 또는 전부를 수행할 수 있도록 프로세서(들)(1130) 상에서 실행할 수 있는 프로그램 코드를 (예컨대, 애플리케이션 모듈들(1142a 내지 1142n) 중 하나 또는 그 초과에) 저장할 수 있다.
[00232] UE(1100)는 또한, 본원에서 설명된 바와 같은 OTT SP 및 UE 관련 로케이션을 지원하기 위한 사용자 디바이스 동작들을 수행하도록 구성된 포지셔닝 모듈(1180)을 포함할 수 있다. 포지셔닝 모듈(1180)은 메모리(1140)에 저장되고 프로세서(들)(1130) 상에서 실행하는 실행가능한 모듈일 수 있거나, 또는 프로세서(들)(1130)에 커플링된 하드웨어 또는 펌웨어 컴포넌트일 수 있다.
[00233] 도 11에서 도시된 모듈들이 메모리(1140)에 포함된 것으로 예에서 예시되어 있지만, 소정의 구현들에서, 그러한 절차들이 다른 또는 부가적인 메커니즘들을 사용하여 제공될 수 있거나 또는 그렇지 않으면 동작가능하게 배열될 수 있다는 것이 인지된다. 예컨대, 애플리케이션 모듈들(1142a...1142n) 중 임의의 것이 펌웨어로 제공될 수 있다. 프로세서(들)(1130)는 적어도 본원에서 제공된 기법들을 수행하는데 적절한 임의의 형태의 로직을 포함할 수 있다. 예컨대, 프로세서(들)(1130)는 UE(1100)의 다른 부분들에서 사용하기 위한 모션 데이터를 활용하는 하나 또는 그 초과의 루틴들을 선택적으로 개시하도록 메모리(1140)에서의 명령들에 기반하여 동작가능하게 구성가능할 수 있다.
[00234] UE(1100)는 UE(1100)와의 사용자 상호작용을 허용하는, 마이크로폰/스피커(1152), 터치 패드(1153), 키패드(1154), 디스플레이(1156), 카메라(1158), 및 근접성 센서들(1159)과 같은 임의의 적절한 인터페이스 시스템들을 제공하는 사용자 인터페이스(1150)를 포함할 수 있다. 마이크로폰/스피커(1152)는 WAN 트랜시버(들)(1114b) 및/또는 WLAN 트랜시버(들)(1114c)를 사용하여 음성 인식 및/또는 음성 통신 서비스들을 제공한다. 키패드(1154)는 사용자 입력을 위한 임의의 적절한 버튼들을 포함한다. 디스플레이(1156)는, 예컨대, 백릿 LCD 디스플레이와 같은 임의의 적절한 디스플레이를 포함하고, 부가적인 사용자 입력 모드들을 위한 터치 스크린 디스플레이를 더 포함할 수 있다. 더욱이, 마이크로폰/스피커(1152), 카메라(1158), 또는 키패드(1154)에 의해 발휘되는 기능성과 같은 임의의 입력 기능성이 또한, 하나 또는 그 초과의 센서들(1120)의 입력들과 유사한 센서 입력으로 고려될 수 있다.
[00235] UE(1100)는 UE(1100)의 다양한 컴포넌트들에 전력을 공급하기 위해 전력 공급부(1160), 예컨대 배터리를 더 포함한다. 그러나, UE(1100)가 예시된 모든 엘리먼트들을 포함하지 않을 수 있고, 디바이스 및 설계 고려사항들의 요건들에 기반하여 엘리먼트들의 서브세트만을 포함하게 될 것이 가장 유력하다는 것이 인지될 것이다.
[00236] 위에서 주목된 바와 같이, 하나 또는 그 초과의 센서들(1120)은 사용자의 포지션, 배향, 모션, 환경, 액티비티들, 또는 바이오메트릭들에 관한 데이터를 포함하는 사용자에 관한 데이터를 수집할 수 있다. 센서들은, 예컨대, 보수계(1122a)(다른 센서들로부터의 데이터에 기반하는 기능적인 모듈 또는 이산 디바이스일 수 있음), 가속도계(1122b), 자이로스코프(1122c), 바이오메트릭 센서(1120d), 및/또는 임의의 수의 다양한 센서들(1122n)을 포함할 수 있다. 더욱이, 블루투스 트랜시버(들)(1114a), WAN 트랜시버(들)(1114b), WLAN 트랜시버(들)(1114c), 및/또는 SPS 수신기(1114d)는 이들이 사용자의 포지션, 모션, 환경, 및/또는 액티비티들에 관한 데이터를 생성하기 위해 사용될 수 있는 한 센서들로서 활용될 수 있다. 그에 따라서, 본 개시내용이 일반적으로 하나 또는 그 초과의 센서들(1120)을 언급하거나, 또는 센서 판독들 또는 센서 데이터를 언급하는 경우에, 블루투스 트랜시버(들)(1114a), WAN 트랜시버(들)(1114b), WLAN 트랜시버(들)(1114c), 및/또는 SPS 수신기(1114d)가 센서들로 간주될 수 있고, 그로부터 획득된 데이터가 센서 판독들 또는 센서 데이터로 간주될 수 있다는 것이 이해되어야 한다.
[00237] 실시예에서, 바이오메트릭 센서(1122d)는 사용자를 식별하기 위한 센서를 포함한다. 예컨대, 바이오메트릭 센서(1122d)는 음성 인식, 지문 인식, 장문 인식, 얼굴 인식, 또는 홍채 인식을 위한 센서일 수 있다. 바이오메트릭 센서(1122d)는 음성 인식, 지문 인식, 장문 인식, 얼굴 인식, 및/또는 홍채 인식을 위해 특별히 설계된 전용된 센서일 수 있다. 다른 가능한 시나리오에서, 마이크로폰/스피커(1152)가 음성 인식을 위한 센서로서 사용된다. 다른 가능한 시나리오에서, 키패드(1154)가 지문 인식 및/또는 장문 인식을 위한 센서로서 사용된다. 또 다른 가능한 시나리오에서, 카메라(1158)가 얼굴 인식 및/또는 홍채 인식을 위한 센서로서 사용된다.
[00238] 위에서 주목된 바와 같이, 프로세서(들)(1130)는 메모리(1140)에 커플링될 수 있으며, 메모리(1140)는 UE(1100) 내에서 프로그래밍된 기능성을 실행하기 위한 데이터 및 소프트웨어 명령들을 저장한다. 메모리(1140)는 임의의 수의 애플리케이션 모듈들(1142a...1142n) 및 임의의 수의 데이터 모듈들(1144a...1144n)을 포함할 수 있다. 실시예에서, 애플리케이션 모듈들(1142a...1142n) 중 하나 또는 그 초과, 예컨대 애플리케이션 모듈(1142a)은 보수계(1122a), 가속도계(1122b), 자이로스코프(1122c), 바이오메트릭 센서들(1120d), 및/또는 다양한 센서들(1122n) 중 하나 또는 그 초과로부터 수집되는 감지된 데이터를 활용한다. 감지된 데이터는 데이터 모듈들(1144a)...데이터 모듈(1144n) 중 하나 또는 그 초과, 예컨대 데이터 모듈(1144a)에 저장될 수 있다.
[00239] 따라서, 본 개시내용의 실시예는 본원에서 설명된 기능들을 수행할 능력을 포함하는 UE(예컨대, UE(1100))를 포함할 수 있다. 당업자들에 의해 인지될 바와 같이, 다양한 로직 엘리먼트들은 본원에서 개시된 기능성을 달성하기 위해 이산 엘리먼트들, 프로세서 상에서 실행되는 소프트웨어 모듈들, 또는 소프트웨어 및 하드웨어의 임의의 조합으로 구현될 수 있다. 예컨대, 프로세서(1130), 메모리(1140), 사용자 인터페이스(1150), 및 포지셔닝 모듈(1180) 모두는 본원에서 개시된 다양한 기능들을 로딩, 저장 및 실행하기 위해 협력하여 사용될 수 있으며, 따라서, 이러한 기능들을 수행하기 위한 로직은 다양한 엘리먼트들에 걸쳐 분산될 수 있다. 대안적으로, 기능성은 하나의 이산 컴포넌트에 통합될 수 있다. 그러므로, 도 11의 UE(1100)의 피처들은 단지 예시적인 것으로 고려되며, 본 개시내용은 예시된 피처들 또는 어레인지먼트로 제한되지 않는다.
[00240] UE(1100)와 RAN(120)/MME(142) 간의 무선 통신은 상이한 기술들, 이를테면, LTE, CDMA, WCDMA, TDMA(time division multiple access), FDMA(frequency division multiple access), OFDM(Orthogonal Frequency Division Multiplexing), GSM, 또는 무선 통신 네트워크 또는 데이터 통신 네트워크에서 사용될 수 있는 다른 프로토콜들에 기반할 수 있다. 전술한 내용에서 논의되고 당해 기술분야에 알려진 바와 같이, 음성 송신 및/또는 데이터는 다양한 네트워크들 및 구성들을 사용하여 RAN(120)으로부터 UE들(1100)로 송신될 수 있다. 따라서, 본원에서 제공된 예시들은 본 개시내용의 실시예들을 제한하도록 의도되는 것이 아니라, 단지 본 개시내용의 실시예들의 양상들의 설명을 돕기 위한 것이다.
[00241] 도 12는 기능성을 수행하기 위한 구조적 컴포넌트들을 포함하는 통신 디바이스(1200)를 예시한다. 통신 디바이스(1200)는, UE(1100), RAN(120)의 임의의 컴포넌트(예컨대, eNodeB들(122-126)), 코어 네트워크(140)의 임의의 컴포넌트(예컨대, MME(142 또는 144), E-SMLC(172), S-GW(146), PDG(148), ELS(370/794), E-CSCF(443/543/643), LRF(448/548/648)), 코어 네트워크(140) 및/또는 인터넷(175)과 커플링된 임의의 컴포넌트들(예컨대, 로케이션 서버(170), GMLC/SLP(170), ESInet(160), PSAP(180)) 등을 포함하는(그러나 이에 제한되지 않음) 위에서-주목된 통신 디바이스들 중 임의의 통신 디바이스에 대응할 수 있다. 따라서, 통신 디바이스(1200)는, 도 1a의 무선 통신 시스템(100A)을 통해 또는 도 1b의 특정 구성(100B)을 사용하여 하나 또는 그 초과의 다른 엔티티들과 통신하도록 (또는 하나 또는 그 초과의 다른 엔티티들과의 통신을 가능하게 하도록) 구성되는 임의의 전자 디바이스에 대응할 수 있다.
[00242] 도 12를 참조하면, 통신 디바이스(1200)는 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)를 포함한다. 예에서, 통신 디바이스(1200)가 무선 통신 디바이스(예컨대, UE(1100), eNB들(122-126) 중 하나 등)에 대응하는 경우, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)는 무선 통신 인터페이스(예컨대, 블루투스, WiFi, 2G, CDMA, WCDMA, 3G, 4G, LTE, 등), 이를테면, 무선 트랜시버 및 연관된 하드웨어(예컨대, RF 안테나, 모뎀, 변조기 및/또는 복조기 등)를 포함할 수 있다. 다른 예에서, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)는 유선 통신 인터페이스(예컨대, 직렬 연결, USB 또는 파이어와이어 연결, 이더넷 연결(이를 통해 인터넷(175)이 액세스될 수 있음) 등)에 대응할 수 있다. 따라서, 통신 디바이스(1200)가 일부 타입의 네트워크-기반 서버(예컨대, S-GW(146), PDG(148), MME(142/144), E-SMLC(172), 로케이션 서버(170), ELS(370/794), E-CSCF(443/543/643), LRF(448/548/648) 등)에 대응하는 경우, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)는 이더넷 카드에 대응할 수 있으며, 예에서, 이더넷 카드는 네트워크-기반 서버를 이더넷 프로토콜을 통해 다른 통신 엔티티들에 연결한다. 추가의 예에서, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)는 감지 또는 측정 하드웨어(예컨대, 가속도계, 온도 센서, 광 센서, 로컬 RF 신호들을 모니터링하기 위한 안테나 등)를 포함할 수 있으며, 감지 또는 측정 하드웨어에 의해 통신 디바이스(1200)는 자신의 로컬 환경을 모니터링할 수 있다. 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)는 또한 소프트웨어를 포함할 수 있으며, 소프트웨어는 실행될 때, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)의 연관된 하드웨어가 그것의 수신 및/또는 송신 기능(들)을 수행하도록 허용한다. 그러나, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)는 소프트웨어 단독에는 대응하지 않으며, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)는 자신의 기능성을 달성하기 위해 구조적 하드웨어에 적어도 부분적으로 의존한다.
[00243] 도 12를 참조하면, 통신 디바이스(1200)는 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)를 더 포함한다. 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)에 의해 수행될 수 있는 프로세싱의 유형의 예시적 구현들은, 결정들을 수행하는 것, 연결들을 설정하는 것, 상이한 정보 옵션들 간의 선택들을 하는 것, 데이터와 관련된 평가들을 수행하는 것, 측정 동작들을 수행하기 위해 통신 디바이스(1200)에 커플링된 센서들과 상호작용하는 것, 정보를 하나의 포맷으로부터 다른 포맷으로(예컨대, .wmv로부터 .avi로 등과 같이 상이한 프로토콜들 간에서) 변환하는 것 등(그러나 이에 제한되지 않음)을 포함한다. 예컨대, 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)는, 범용 프로세서, DSP, ASIC, FPGA(field programmable gate array) 또는 다른 프로그램가능 로직 디바이스, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들, 또는 본원에서 설명된 기능들을 수행하도록 설계된 이들의 임의의 조합을 포함할 수 있다. 범용 프로세서는 마이크로프로세서일 수 있지만, 대안적으로, 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(310)는 임의의 종래의 프로세서, 제어기, 마이크로제어기, 또는 상태 머신일 수 있다. 프로세서는 또한, 컴퓨팅 디바이스들의 조합(예컨대, DSP와 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 공조하는 하나 또는 그 초과의 마이크로프로세서들, 또는 임의의 다른 그러한 구성)으로서 구현될 수 있다. 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)는 또한 소프트웨어를 포함할 수 있으며, 소프트웨어는 실행될 때, 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)의 연관된 하드웨어가 그것의 프로세싱 기능(들)을 수행하도록 허용한다. 그러나, 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)는 소프트웨어 단독에는 대응하지 않으며, 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)는 자신의 기능성을 달성하기 위해 구조적 하드웨어에 적어도 부분적으로 의존한다.
[00244] 도 12를 참조하면, 통신 디바이스(1200)는 정보를 저장하도록 구성된 메모리(1215)를 더 포함한다. 예에서, 정보를 저장하도록 구성된 메모리(1215)는 적어도 비-일시적 메모리 및 연관된 하드웨어(예컨대, 메모리 제어기 등)를 포함할 수 있다. 예컨대, 정보를 저장하도록 구성된 메모리(1215)에 포함된 비-일시적 메모리는 RAM, 플래시 메모리, ROM(read-only memory), EPROM(erasable programmable ROM), EEPROM(electrically erasable programmable ROM), 레지스터들, 하드 디스크, 제거가능 디스크, CD-ROM, 또는 당해 기술분야에 알려진 임의의 다른 형태의 저장 매체에 대응할 수 있다. 정보를 저장하도록 구성된 메모리(1215)는 또한 소프트웨어를 포함할 수 있으며, 소프트웨어는 실행될 때, 정보를 저장하도록 구성된 메모리(1215)의 연관된 하드웨어가 그것의 저장 기능(들)을 수행하도록 허용한다. 그러나, 정보를 저장하도록 구성된 메모리(1215)는 소프트웨어 단독에는 대응하지 않으며, 정보를 저장하도록 구성된 메모리(1215)는 자신의 기능성을 달성하기 위해 구조적 하드웨어에 적어도 부분적으로 의존한다.
[00245] 도 12를 참조하면, 통신 디바이스(1200)는 선택적으로, 정보를 제시하도록 구성된 사용자 인터페이스 출력 회로(1220)를 더 포함한다. 예에서, 정보를 제시하도록 구성된 사용자 인터페이스 출력 회로(1220)는 적어도 출력 디바이스 및 연관된 하드웨어를 포함할 수 있다. 예컨대, 출력 디바이스는 비디오 출력 디바이스(예컨대, 디스플레이 스크린, 비디오 정보를 반송할 수 있는 포트, 이를테면, USB, HDMI 등), 오디오 출력 디바이스(예컨대, 스피커들, 오디오 정보를 반송할 수 있는 포트, 이를테면, 마이크로폰 잭, USB, HDMI 등), 진동 디바이스 및/또는 임의의 다른 디바이스(이에 의해 정보가 출력을 위해 포맷화되거나 또는 통신 디바이스(1200)의 사용자 또는 오퍼레이터에 의해 실제로 출력될 수 있음)를 포함할 수 있다. 예컨대, 통신 디바이스(1200)가 도 11에 도시된 바와 같은 UE(1100)에 대응하는 경우, 정보를 제시하도록 구성된 사용자 인터페이스 출력 회로(1220)는 디스플레이(1056) 및/또는 스피커(1052)를 포함할 수 있다. 추가의 예에서, 로컬 사용자를 갖지 않는 네트워크 통신 디바이스들과 같은 특정 통신 디바이스들(예컨대, 네트워크 스위치들 또는 라우터들, 원격 서버들 등)의 경우, 정보를 제시하도록 구성된 사용자 인터페이스 출력 회로(1220)는 생략될 수 있다. 정보를 제시하도록 구성된 사용자 인터페이스 출력 회로(1220)는 또한 소프트웨어를 포함할 수 있으며, 소프트웨어는 실행될 때, 정보를 제시하도록 구성된 사용자 인터페이스 출력 회로(1220)의 연관된 하드웨어가 그것의 제시 기능(들)을 수행하도록 허용한다. 그러나, 정보를 제시하도록 구성된 사용자 인터페이스 출력 회로(1220)는 소프트웨어 단독에는 대응하지 않으며, 정보를 제시하도록 구성된 사용자 인터페이스 출력 회로(1220)는 자신의 기능성을 달성하기 위해 구조적 하드웨어에 적어도 부분적으로 의존한다.
[00246] 도 12를 참조하면, 통신 디바이스(1200)는 선택적으로, 로컬 사용자 입력을 수신하도록 구성된 사용자 인터페이스 입력 회로(1225)를 더 포함한다. 예에서, 로컬 사용자 입력을 수신하도록 구성된 사용자 인터페이스 입력 회로(325)는 적어도 사용자 입력 디바이스 및 연관된 하드웨어를 포함할 수 있다. 예컨대, 사용자 입력 디바이스는 버튼들, 터치스크린 디스플레이, 키보드, 카메라, 오디오 입력 디바이스(예컨대, 마이크로폰 또는 오디오 정보를 반송할 수 있는 포트, 이를테면, 마이크로폰 잭 등), 및/또는 임의의 다른 디바이스(이에 의해 정보가 통신 디바이스(1200)의 사용자 또는 오퍼레이터로부터 수신될 수 있음)를 포함할 수 있다. 예컨대, 통신 디바이스(1200)가 도 11에 도시된 바와 같은 UE(1100)에 대응하는 경우, 로컬 사용자 입력을 수신하도록 구성된 사용자 인터페이스 입력 회로(1225)는 터치 패드(1153), 키패드(1154), 마이크로폰(1152) 등을 포함할 수 있다. 추가의 예에서, 로컬 사용자를 갖지 않는 네트워크 통신 디바이스들과 같은 특정 통신 디바이스들(예컨대, 네트워크 스위치들 또는 라우터들, 원격 서버들 등)의 경우, 로컬 사용자 입력을 수신하도록 구성된 사용자 인터페이스 입력 회로(1225)는 생략될 수 있다. 로컬 사용자 입력을 수신하도록 구성된 사용자 인터페이스 입력 회로(1225)는 또한 소프트웨어를 포함할 수 있으며, 소프트웨어는 실행될 때, 로컬 사용자 입력을 수신하도록 구성된 사용자 인터페이스 입력 회로(1225)의 연관된 하드웨어가 그것의 입력 수신 기능(들)을 수행하도록 허용한다. 그러나, 로컬 사용자 입력을 수신하도록 구성된 사용자 인터페이스 입력 회로(1225)는 소프트웨어 단독에는 대응하지 않으며, 로컬 사용자 입력을 수신하도록 구성된 사용자 인터페이스 입력 회로(1225)는 자신의 기능성을 달성하기 위해 구조적 하드웨어에 적어도 부분적으로 의존한다.
[00247] 도 12를 참조하면, 1205 내지 1225의 구성된 구조적 컴포넌트들이 연관된 통신 버스(1230)를 통해 서로 커플링되는 별개의 또는 개별 블록들로서 도 12에 도시되지만, 하드웨어 및/또는 소프트웨어(이에 의해, 1205 내지 1225의 각각의 구성된 구조적 컴포넌트들이 자신들의 각각의 기능성을 수행함)가 부분적으로 오버랩할 수 있다는 것이 인지될 것이다. 예컨대, 1205 내지 1225의 구성된 구조적 컴포넌트들의 기능성을 가능하게 하기 위해 사용되는 임의의 소프트웨어는 정보를 저장하도록 구성된 메모리(1215)와 연관된 비-일시적 메모리에 저장될 수 있어서, 1205 내지 1225의 구성된 구조적 컴포넌트들 각각은 정보를 저장하도록 구성된 메모리(1215)에 의해 저장된 소프트웨어의 동작에 부분적으로 기반하여 자신들의 각각의 기능성(즉, 이 경우, 소프트웨어 실행)을 수행한다. 마찬가지로, 1205 내지 1225의 구성된 구조적 컴포넌트들 중 하나와 직접적으로 연관된 하드웨어는 때때로 1205 내지 1225의 다른 구성된 구조적 컴포넌트들에 의해 사용되거나 또는 차용(borrow)될 수 있다. 예컨대, 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)는, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)에 의해 송신되기 전에 적합한 포맷으로 데이터를 포맷할 수 있어서, 정보를 수신 및/또는 송신하도록 구성된 트랜시버 회로(1205)는 정보를 프로세싱하도록 구성된 적어도 하나의 프로세서(1210)와 연관된 구조적 하드웨어의 동작에 부분적으로 기반하여 자신의 기능성(즉, 이 경우, 데이터의 송신)을 수행한다.
[00248] 따라서, 1205 내지 1225의 다양한 구조적 컴포넌트들은 구조적 하드웨어를 이용하여 적어도 부분적으로 구현되는 양상을 호출하도록 의도되며, 하드웨어와는 독립적인 소프트웨어-전용 구현들 및/또는 비-구조적 기능 해석들에 맵핑되도록 의도되지는 않는다. 1205 내지 1225의 구조적 컴포넌트들 간의 다른 상호작용들 또는 협력들은 아래에서 더 상세하게 설명되는 양상들의 리뷰로부터 당업자에게 명백해질 것이다.
[00249] 다양한 실시예들은 도 13에서 예시된 서버(1300)와 같은 다양한 상업적으로 입수가능한 서버 디바이스들 중 임의의 서버 디바이스 상에서 구현될 수 있다. 예에서, 서버(1300)는 위에서 설명된 MME(142), OTT SP(150/350/450/550/650/750/850/950), ESInet(160), E-SMLC(172), 로케이션 서버/GMLC/SLP(170), ELS(370/794), E-CSCF(443/543/643), LRF(448/548/648) 및 PSAP(180)의 일 예시적 구성에 대응할 수 있다. 도 13에서, 서버(1300)는 휘발성 메모리(1302) 및 대용량 비휘발성 메모리, 이를테면, 디스크 드라이브(1303)에 커플링된 프로세서(1301)를 포함한다. 서버(1300)는 또한, 프로세서(1301)에 커플링된 플로피 디스크 드라이브, CD(compact disc) 또는 DVD 디스크 드라이브(1306)를 포함할 수 있다. 서버(1300)는 또한, 다른 브로드캐스트 시스템 컴퓨터들 및 서버들 또는 인터넷에 커플링된 로컬 영역 네트워크와 같은 네트워크(1307)와의 데이터 연결들을 설정하기 위해 프로세서(1301)에 커플링된 네트워크 액세스 포트들(1304)을 포함할 수 있다. 도 12와 관련해서, 도 13의 서버(1300)가 통신 디바이스(1200)의 일 예시적 구현을 예시하며, 이에 의해, 정보를 송신 및/또는 수신하도록 구성된 로직(1205)은 네트워크(1307)와 통신하기 위해 서버(1300)에 의해 사용되는 네트워크 액세스 포트들(1304)에 대응하고, 정보를 프로세싱하도록 구성된 로직(1210)은 프로세서(1301)에 대응하고, 정보를 저장하기 위한 로직 구성(1215)은 휘발성 메모리(1302), 디스크 드라이브(1303) 및/또는 디스크 드라이브(1306)의 임의의 조합에 대응한다는 것이 인지될 것이다. 정보를 제시하도록 구성된 선택적 로직(1220) 및 로컬 사용자 입력을 수신하도록 구성된 선택적 로직(1225)은 도 13에 명시적으로 도시되지 않았으며, 도 13에 포함될 수 있거나 또는 포함되지 않을 수 있다. 따라서, 도 13은 도 11에서와 같은 UE 구현에 부가적으로, 통신 디바이스(1200)가 서버로서 구현될 수 있다는 것을 나타내는 것을 돕는다. 따라서, 본 개시내용의 실시예는, 예컨대 MME(142), OTT-SP(150), ESInet(160), E-SMLC(172), 로케이션 서버/GMLC/SLP(170), ELS(370/794), E-CSCF(443/543/643), LRF(448/548/648) 및 PSAP(180)를 참조하여 설명된 기능들과 같은, 본원에서 설명된 기능들을 수행할 능력을 포함하는 서버(예컨대, 서버(1300))를 포함할 수 있다.
[00250] 도 14는 도 1a 및 1b의 RAN(120) 또는 CN(140)의 임의의 컴포넌트와 같이 UE를 서빙하는 액세스 네트워크 노드에 의해 수행되는 UE를 로케이팅하기 위한 예시적인 흐름을 예시한다. 예컨대, 액세스 네트워크 노드는 MME(142)에 대응할 수 있다.
[00251] 1410에서, 도 2a의 206A 또는 도 2b의 202B에서와 같이, 액세스 네트워크 노드는 UE로부터 제 1 메시지를 수신한다. 예컨대, 액세스 네트워크 노드가 LTE를 지원하는 MME에 대응하는 경우, 제 1 메시지들은 NAS 어태치 요청 또는 NAS 추적 영역 업데이트 요청일 수 있다. 액세스 네트워크 노드가 UMTS를 지원하는 SGSN에 대응하는 경우, 제 1 메시지는 GPRS 어태치 요청 또는 GPRS 라우팅 영역 업데이트 요청일 수 있다.
[00252] 1420에서, 액세스 네트워크 노드는 UE에 대한 로케이션 레퍼런스를 결정한다. 로케이션 레퍼런스는, 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 도 1a의 로케이션 서버(170) 또는 도 1b의 GMLC/SLP(170)와 같은 로케이션 서버에 대한 것일 수 있고, UE가 로케이팅되게 할 수 있다. UE에 대한 로케이션 레퍼런스는 로케이션 서버의 어드레스 및 UE의 UE 레퍼런스를 포함할 수 있다. UE 레퍼런스는 로케이션 서버에 의해 할당될 수 있으며, IP 어드레스, IMSI, TMSI, 액세스 네트워크 노드의 어드레스, 또는 이들의 임의의 조합을 포함할 수 있다. UE 레퍼런스는 또한 암호화될 수 있다.
[00253] 도 2a의 208A 또는 도 2b의 204B를 참조로 위에 논의된 바와 같이, 1420에서 결정하는 단계는 UE에 대한 로케이션 레퍼런스의 요청을 로케이션 서버에 전송하는 단계 및 UE에 대한 로케이션 레퍼런스를 로케이션 서버로부터 수신하는 단계를 포함할 수 있다. 대안적으로, 위에 논의된 바와 같이, 액세스 네트워크 노드는 UE 자신에 대한 로케이션 레퍼런스를 생성할 수 있다. 그 경우, 액세스 네트워크 노드는, UE에 대한 로케이션 레퍼런스가 그 오퍼레이터에 대한 액세스 네트워크 노드에 의해 생성되었음을 나타내기 위해 UE에 대한 로케이션 레퍼런스를 디지털적으로 서명할 수 있다.
[00254] 1430에서, 도 2a의 212A 또는 도 2b의 206B에서와 같이, 액세스 네트워크 노드는 제 2 메시지를 UE에 전송한다. 제 2 메시지는 로케이션 레퍼런스를 포함할 수 있다. 액세스 네트워크 노드가 LTE를 지원하는 MME에 대응하는 경우, 제 2 메시지들은 NAS 어태치 수용 또는 NAS 추적 영역 업데이트 수용일 수 있다. 액세스 네트워크 노드가 UMTS를 지원하는 SGSN에 대응하는 경우, 제 2 메시지는 GPRS 어태치 수용 또는 GPRS 라우팅 영역 업데이트 수용일 수 있다.
[00255] UE는, OTT SP(150)와 같은 OTT SP에 전송되는 긴급 서비스들 호 요청에, UE에 대한 로케이션 레퍼런스를 포함시킬 수 있다. UE는 액세스 네트워크 노드의 액세스 네트워크와는 상이한 액세스 네트워크를 통해서 긴급 서비스들 호 요청을 OTT SP에 전송할 수 있다. OTT SP는 로케이션 레퍼런스에 기반하여 로케이션 서버로부터 UE의 로케이션을 획득할 수 있다.
[00256] 도시되지 않았지만, 도 14에 예시된 흐름은 제 2 메시지를 전송하기 전에 UE를 인증하는 단계를 더 포함할 수 있다. 부가적으로, 도 14에 예시된 흐름은 UE가 액세스 네트워크 노드에 어태치되는 동안 UE에 대한 신규의 로케이션 레퍼런스를 주기적으로 결정하는 단계 그리고 신규의 로케이션 레퍼런스를 UE에 전송하는 단계를 더 포함할 수 있다.
[00257] 도 15는 도 1a의 로케이션 서버(170) 또는 도 1b의 GMLC/SLP(170)와 같은 로케이션 서버에서 수행되는 UE를 로케이팅하기 위한 예시적인 흐름을 예시한다.
[00258] 1510에서, 도 2a의 208A 또는 도 2b의 204b에서와 같이, 로케이션 서버는 UE를 서빙하는 액세스 네트워크 노드로부터 UE에 대한 로케이션 레퍼런스 요청을 수신한다.
[00259] 1520에서, 도 2a의 208A 또는 도 2b의 204B에서와 같이, 로케이션 서버는 액세스 네트워크 노드에 UE에 대한 로케이션 레퍼런스를 전송한다. 로케이션 레퍼런스는 로케이션 서버의 어드레스 및 UE에 대한 로컬 레퍼런스를 포함할 수 있다.
[00260] 1530에서, 도 2a의 216A 또는 도 2b의 214B에서와 같이, 로케이션 서버는 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신한다. 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함할 수 있다. 다른 네트워크 엔티티는, 예컨대, OTT SP, ESInet 제공자, 또는 PSAP에 속하는 네트워크 엔티티일 수 있다.
[00261] 1540에서, 도 2a의 218A 또는 도 2b의 216B-226B 또는 228B에서와 같이, 로케이션 서버는 UE에 대한 로케이션 추정을 결정할 수 있다. 로케이션 서버가 SLP에 대응하는 경우, UE에 대한 로케이션 추정을 결정하는 단계는 UE와의 SUPL 세션을 설정하는 단계를 포함할 수 있다. 로케이션 서버가 GMLC에 대응하는 경우, UE에 대한 로케이션 추정을 결정하는 단계는 제어 평면 로케이션 솔루션을 사용하여 로케이션 추정을 결정하는 단계를 포함할 수 있다. 그 경우, 도 2a의 218A 또는 도 2b의 216B-226B에서와 같이, 제어 평면 로케이션 솔루션을 사용하여 로케이션 추정을 결정하는 단계는, 액세스 네트워크 노드에 로케이션 요청을 전송하는 단계 및 로케이션 추정을 포함하는 로케이션 응답을 액세스 네트워크 노드로부터 수신하는 단계를 포함할 수 있다.
[00262] 1550에서, 도 2a의 224A 또는 도 2b의 232B에서와 같이, 로케이션 서버는 UE에 대한 로케이션 추정을 네트워크 엔티티에 전송한다.
[00263] UE는 OTT SP에 전송된 긴급 서비스들 호 요청에 로케이션 레퍼런스를 포함한다. 일 실시예에서, UE는 로케이션 서버에 대한 오퍼레이터와 상이한 오퍼레이터에 대한 액세스 네트워크를 통해 긴급 서비스들 호 요청을 OTT SP에 전송할 수 있다.
[00264] 도 16은 도 1a의 로케이션 서버(170) 또는 도 1b의 GMLC/SLP(170)와 같은 로케이션 서버에서 수행되는 UE를 로케이팅하기 위한 예시적인 흐름을 예시한다.
[00265] 1610에서, 도 2a의 216A 또는 도 2b의 214B에서와 같이, 로케이션 서버는 UE를 서빙하는 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 UE의 로케이션에 대한 로케이션 요청을 수신한다. 로케이션 요청은 UE에 대한 로케이션 레퍼런스를 포함할 수 있다. 로케이션 레퍼런스는 UE에 대한 UE 레퍼런스를 포함할 수 있다. UE 레퍼런스는, IP 어드레스, IMSI, TMSI, 액세스 네트워크 노드의 어드레스, 또는 이들의 임의의 조합일 수 있다. 다른 네트워크 엔티티는, 예컨대, OTT SP, ESInet 제공자, 또는 PSAP에 속하는 네트워크 엔티티일 수 있다.
[00266] 1620에서, 로케이션 서버는 UE에 대한 로케이션 레퍼런스를 인증한다. 로케이션 레퍼런스는 디지털 시그니처를 포함할 수 있는데, 이 경우 로케이션 레퍼런스를 인증하는 것은 디지털 시그니처를 인증하는 것을 포함한다.
[00267] 1630에서, 도 2a의 218A 또는 도 2b의 216B-226B 또는 228B에서와 같이, 로케이션 서버는 UE에 대한 로케이션 레퍼런스에서의 UE 레퍼런스에 기반하여 UE에 대한 로케이션 추정을 결정한다. 일 실시예에서, UE 레퍼런스는 암호화될 수 있고, 이 경우 UE에 대한 로케이션 추정을 결정하는 것은 암호화된 UE 레퍼런스를 복호화하는 것(deciphering)을 포함할 수 있다. 로케이션 서버가 SLP에 대응하는 경우, UE에 대한 로케이션 추정을 결정하는 단계는 UE와의 SUPL 세션을 설정하는 단계를 포함할 수 있다. 로케이션 서버가 GMLC에 대응하는 경우, UE에 대한 로케이션 추정을 결정하는 단계는 제어 평면 로케이션 솔루션을 사용하여 로케이션 추정을 결정하는 단계를 포함할 수 있다. 그 경우, 도 2a의 218A 또는 도 2b의 216B-226B에서와 같이, 제어 평면 로케이션 솔루션을 사용하여 로케이션 추정을 결정하는 단계는, 액세스 네트워크 노드에 로케이션 요청을 전송하는 단계 및 로케이션 추정을 포함하는 로케이션 응답을 액세스 네트워크 노드로부터 수신하는 단계를 포함할 수 있다.
[00268] 1640에서, 도 2a의 224A 또는 도 2b의 232B에서와 같이, 로케이션 서버는 UE에 대한 로케이션 추정을 다른 네트워크 엔티티에 전송한다.
[00269] UE는, OTT SP와 같은 OTT SP에 전송된 긴급 서비스들 호 요청에, UE에 대한 로케이션 레퍼런스를 포함할 수 있다.
[00270] 도 17은 UE, 이를테면, UE(1100)에 의해 수행되는 호를 수행하는 UE를 로케이팅하기 위한 예시적인 흐름을 예시한다. 호는 긴급 호일 수 있다.
[00271] 1710에서, UE는 UE를 서빙하는 액세스 네트워크 노드에 제 1 메시지를 전송한다. 액세스 네트워크 노드가 LTE를 지원하는 MME에 대응하는 경우, 제 1 메시지들은 NAS 어태치 요청 또는 NAS 추적 영역 업데이트 요청일 수 있다. 액세스 네트워크 노드가 UMTS를 지원하는 SGSN에 대응하는 경우, 제 1 메시지는 GPRS 어태치 요청 또는 GPRS 라우팅 영역 업데이트 요청일 수 있다.
[00272] 1720에서, UE는 UE에 대한 로케이션 레퍼런스를 포함하는 제 2 메시지를 액세스 네트워크 노드로부터 수신한다. 로케이션 레퍼런스는, 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 도 1a의 로케이션 서버(170) 또는 도 1b의 GMLC/SLP(170)와 같은 로케이션 서버에 대한 것일 수 있고, UE가 그 호에 대해 로케이팅되게 할 수 있다. UE에 대한 로케이션 레퍼런스는 로케이션 서버의 어드레스 및 UE의 UE 레퍼런스를 포함할 수 있다. 액세스 네트워크 노드가 LTE를 지원하는 MME에 대응하는 경우, 제 1 메시지들은 NAS 어태치 요청 또는 NAS 추적 영역 업데이트 요청일 수 있다. 액세스 네트워크 노드가 UMTS를 지원하는 SGSN에 대응하는 경우, 제 1 메시지는 GPRS 어태치 요청 또는 GPRS 라우팅 영역 업데이트 요청일 수 있다. 도 17에 예시되지 않았지만, 흐름은 제 2 메시지를 수신하기 이전에 UE를 액세스 네트워크 노드에 인증하는 단계를 더 포함할 수 있다.
[00273] 1730에서, UE는 UE의 사용자로부터 호에 대한 요청을 수신한다.
[00274] 1740에서, UE는 OTT SP, 이를테면, OTT SP(150)에 그 호에 대한 요청을 전송한다. 호에 대한 요청은 UE에 대한 로케이션 레퍼런스를 포함할 수 있다. 일 실시예에서, 호 요청은, 액세스 네트워크 노드에 대한 액세스 네트워크와 상이한 액세스 네트워크를 통해 UE에 의해 OTT SP에 전송된다.
[00275] 도 17에 예시되지 않았지만, 흐름은, UE가 액세스 네트워크 노드에 어태치되는 동안, 액세스 네트워크 노드로부터 UE에 대한 신규의 로케이션 레퍼런스를 주기적으로 수신하는 단계를 더 포함할 수 있다.
[00276] 도 18은 OTT 서비스 제공자, 이를테면 OTT SP(150)에서 긴급 호들을 지원하기 위한 예시적인 흐름을 예시한다. 실시예에서, 도 18에 예시된 흐름은 포지셔닝 모듈(1058)에 의해 수행될 수 있거나, 또는 포지셔닝 모듈(1058)에 의해 수행되도록 야기될 수 있다.
[00277] 1810에서, OTT SP(150)는, 806 및 906에서와 같이, UE, 이를테면 UE들(200, 300, 400, 500, 600, 700, 800, 900, 1002, 및 1100) 중 임의의 UE로부터 긴급 호 요청을 포함하는 제 1 메시지를 수신한다. 제 1 메시지는, UE에 대한 서빙 MNO, 이를테면 서빙 MNO(790, 890, 또는 990)를 통해 OTT SP(150)에 전달된다. 제 1 메시지는, 서빙 MNO에 대한 IMS, 이를테면 IMS(894 또는 994)의 어드레스를 포함한다.
[00278] 820에서, OTT SP(150)는, 808 및 908에서와 같이, 그 어드레스에 기반하여 IMS에 제 2 메시지를 전송한다. 제 2 메시지는 긴급 호에 대한 요청일 수 있다. 제 1 메시지, 제 2 메시지, 또는 그 두 메시지들은 SIP INVITE일 수 있다.
[00279] 도 18에 예시되지 않았지만, 흐름은, 812에서와 같이 목적지 PSAP에 대한 라우팅 정보를 포함하는 제 3 메시지를 IMS로부터 수신하는 단계, 및 그 라우팅 정보에 기반하여 PSAP에 또는 PASP를 향해 제 4 메시지를 전송하는 단계를 더 포함할 수 있다. 제 3 메시지는 SIP(300) 다중 선정 메시지일 수 있고, 제 4 메시지는 긴급 호에 대한 요청일 수 있다. IMS에 대한 어드레스는 LRF에 대한 것일 수 있다. 라우팅 정보는 레퍼런스 ID를 포함할 수 있고, 이 경우 흐름은 레퍼런스 ID를 제 4 메시지에 포함시키는 단계를 더 포함할 수 있으며, 여기서 레퍼런스 ID는 PSAP가 LRF로부터 UE에 대한 로케이션을 획득할 수 있게 한다.
[00280] IMS는 목적지 PASP에 또는 목적지 PASP를 향해 제 5 메시지를 전송할 수 있으며, 여기서 제 5 메시지는 UE에 대한 긴급 호 요청일 수 있다. IMS에 대한 어드레스는 E-CSCF에 대한 것일 수 있다. IMS는 제 5 메시지에 레퍼런스 식별자를 포함하고, 여기서 레퍼런스 식별자는 PSAP가 IMS로부터 UE에 대한 로케이션을 획득할 수 있게 한다.
[00281] 도 19는 서빙 MNO, 이를테면 서빙 MNO(890 또는 990)에 대한 IMS 엔티티, 이를테면 IMS(894 또는 994)에서 긴급 호들을 지원하기 위한 예시적인 흐름을 예시한다. 일 양상에서, IMS 엔티티는 LRF일 수 있다. 실시예에서, 도 19에 예시된 흐름은 포지셔닝 모듈(1058)에 의해 수행될 수 있거나, 또는 포지셔닝 모듈(1058)에 의해 수행되도록 야기될 수 있다.
[00282] 1910에서, IMS 엔티티는, 808 및 908에서와 같이, OTT 서비스 제공자, 이를테면 OTT SP(150)에 의해 전송된 제 1 메시지를 수신하고, 여기서 제 1 메시지는 UE에 대한 긴급 호 요청을 포함한다. 긴급 호 요청은 UE에 대한 MNO 데이터를 포함한다. 제 1 메시지는 SIP INVITE 메시지일 수 있다.
[00283] 1920에서, IMS 엔티티는, 도 9의 911에서와 같이, MNO 데이터에 기반하여 목적지 PSAP에 대한 라우팅 정보를 결정한다.
[00284] 도 19에 예시되지 않았지만, 일 실시예에서, 흐름은 라우팅 정보를 포함하는 제 2 메시지를 OTT 서비스 제공자에게 전송하는 단계를 더 포함할 수 있고, 여기서 라우팅 정보는 OTT 서비스 제공자가 목적지 PSAP에 또는 목적지 PSAP를 향하여 긴급 호를 라우팅할 수 있게 한다. 이 경우, 라우팅 정보는 PASP 또는 중간 목적지의 레퍼런스 ID 및 어드레스 또는 아이덴티티일 수 있다. 제 2 메시지는 SIP (300) 다중 선정 메시지일 수 있다.
[00285] 일 실시예에서, 흐름은 다른 엔티티로부터 레퍼런스 ID를 포함하는 제 3 메시지를 수신하는 단계, 레퍼런스 ID에 기반하여 UE를 식별하는 단계, UE에 대한 로케이션을 획득하는 단계, 및 로케이션을 포함하는 다른 엔티티에 제 4 메시지를 전송하는 단계를 더 포함할 수 있다. 레퍼런스 ID는, ESRK, ESRD 및 MSISDN, 또는 로케이션 URI일 수 있다. UE의 로케이션은 제어 평면 로케이션 솔루션 또는 사용자 평면 로케이션 솔루션을 사용하여 획득될 수 있다. 일 양상에서, 다른 엔티티는 PSAP, ALI, 또는 ESInet일 수 있다.
[00286] 일 실시예에서, 흐름은 라우팅 정보에 기반하여 PSAP에 또는 PSAP를 향하여 제 2 메시지를 전송하는 단계를 더 포함할 수 있고, 여기서 제 2 메시지는 긴급 호에 대한 요청을 포함한다. 이 경우, IMS 엔티티는 긴급 CSCF일 수 있다.
[00287] 도 20은, UE, 이를테면 UE들(200, 300, 400, 500, 600, 700, 800, 900, 1002, 및 1100) 중 임의의 UE에서의 긴급 호들을 지원하기 위한 예시적인 흐름을 예시한다. 실시예에서, 도 20에 예시된 흐름은 포지셔닝 모듈(1054)에 의해 수행될 수 있거나, 또는 포지셔닝 모듈(1054)에 의해 수행되도록 야기될 수 있다.
[00288] 2010에서, UE는 UE의 사용자로부터 긴급 호에 대한 요청을 수신한다.
[00289] 2020에서, UE는 802/804 및 902/904에서와 같이, UE에 대한 서빙 MNO에 대한 MNO 데이터를 획득한다.
[00290] 2030에서, UE는, 806 및 906에서와 같이, OTT 서비스 제공자, 이를테면 OTT SP(150)에 긴급 호에 대한 요청을 포함하는 제 1 메시지를 전송한다. 긴급 호에 대한 요청은 MNO 데이터를 포함한다. MNO 데이터는, 서빙 MNO에 대한 IMS에 대한 어드레스, UE에 대한 현재 서빙 이동성 관리 엔티티 또는 SGSN에 대한 아이덴티티, UE에 대한 서빙 MNO 할당된 IP 어드레스, UE에 대한 글로벌 아이덴티티 또는 로컬 아이덴티티, 또는 이들의 몇몇 조합을 포함할 수 있다.
[00291] OTT 서비스 제공자는 IMS에 대한 어드레스에 기반하여 IMS에 제 2 메시지를 전송하며, 여기서, 제 2 메시지는 긴급 호에 대한 요청을 포함하고 그리고 MNO 데이터를 포함한다. IMS는 MNO 데이터에 기반하여 긴급 호에 대한 라우팅 정보를 결정한다. 이러한 실시예에서, 흐름은 사용자 평면 로케이션 솔루션 또는 제어 평면 로케이션 솔루션에 따라 로케이션 추정에 대한 또는 로케이션 측정에 대한 요청을 수신하는 것을 더 포함하며, 여기서, 로케이션 추정 또는 로케이션 측정들은 IMS가 UE에 대한 로케이션을 획득하는 것을 가능하게 하고, 여기서, UE에 대한 로케이션은 IMS가 라우팅 정보를 결정하거나 또는 PSAP에 로케이션을 제공하는 것을 가능하게 한다.
[00292] IMS는 라우팅 정보를 포함하는 제 3 메시지를 OTT 서비스 제공자에 전송할 수 있다. OTT 서비스 제공자는 목적지 PSAP에 또는 그를 향해 제 4 메시지를 전송하며, 여기서, PSAP는 라우팅 정보에 기반하여 결정된다. 이러한 경우에서, IMS에 대한 어드레스는 LRF에 대한 어드레스이다.
[00293] IMS는 목적지 PSAP에 또는 그를 향해 제 5 메시지를 전송할 수 있으며, 여기서, 제 5 메시지는 긴급 호에 대한 요청을 포함하고, 여기서, PSAP는 라우팅 정보에 기반하여 결정된다. IMS에 대한 어드레스는 E-CSCF에 대한 어드레스일 수 있다.
[00294] 도 21은, 일련의 상호관련된 기능적 모듈들로 표현되는 예시적인 액세스 네트워크 노드 장치(2100)를 예시한다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2110)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1014)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1056)과 결합된, 프로세싱 시스템(1034)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 결정하기 위한 모듈(2120)은 적어도 일부 양상들에서, 예컨대, 선택적으로 포지셔닝 모듈(1056)과 결합된, 프로세싱 시스템(1034)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 전송하기 위한 모듈(2130)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1014)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1056)과 결합된, 프로세싱 시스템(1034)과 같은 프로세싱 시스템에 대응할 수 있다.
[00295] 도 22는, 일련의 상호관련된 기능적 모듈들로 표현되는 예시적인 로케이션 서버 장치(2200)를 예시한다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2210)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 전송하기 위한 모듈(2220)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2230)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 결정하기 위한 모듈(2240)은 적어도 일부 양상들에서, 예컨대, 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 전송하기 위한 모듈(2250)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다.
[00296] 도 23은, 일련의 상호관련된 기능적 모듈들로 표현되는 예시적인 로케이션 서버 장치(2300)를 예시한다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2310)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 인증하기 위한 모듈(2320)은 적어도 일부 양상들에서, 예컨대, 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 결정하기 위한 모듈(2330)은 적어도 일부 양상들에서, 예컨대, 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 전송하기 위한 모듈(2340)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다.
[00297] 도 24는, 일련의 상호관련된 기능적 모듈들로 표현되는 예시적인 사용자 장비 장치(2400)를 예시한다. 본원에서 논의되는 바와 같이, 전송하기 위한 모듈(2410)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1008)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1054)과 결합된, 프로세싱 시스템(1032)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2420)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1008)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1054)과 결합된, 프로세싱 시스템(1032)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2430)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1008)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1054)과 결합된, 프로세싱 시스템(1032)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 전송하기 위한 모듈(2440)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1008)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1054)과 결합된, 프로세싱 시스템(1032)과 같은 프로세싱 시스템에 대응할 수 있다.
[00298] 도 25는, 일련의 상호관련된 기능적 모듈들로 표현되는 예시적인 OTT 서비스 제공자 장치(2500)를 예시한다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2510)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 전송하기 위한 모듈(2520)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다.
[00299] 도 26은, 일련의 상호관련된 기능적 모듈들로 표현되는 예시적인 IMS 엔티티 장치(2600)를 예시한다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2610)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1026)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 결정하기 위한 모듈(2620)은 적어도 일부 양상들에서, 예컨대, 선택적으로 포지셔닝 모듈(1058)과 결합된, 프로세싱 시스템(1036)과 같은 프로세싱 시스템에 대응할 수 있다.
[00300] 도 27은, 일련의 상호관련된 기능적 모듈들로 표현되는 예시적인 사용자 장비 장치(2700)를 예시한다. 본원에서 논의되는 바와 같이, 수신하기 위한 모듈(2710)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1008)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1054)과 결합된, 프로세싱 시스템(1032)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 획득하기 위한 모듈(2720)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1008)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1054)과 결합된, 프로세싱 시스템(1032)과 같은 프로세싱 시스템에 대응할 수 있다. 본원에서 논의되는 바와 같이, 전송하기 위한 모듈(2730)은 적어도 일부 양상들에서, 예컨대, 도 10의 통신 디바이스(1008)와 같은 통신 디바이스, 또는 선택적으로 포지셔닝 모듈(1054)과 결합된, 프로세싱 시스템(1032)과 같은 프로세싱 시스템에 대응할 수 있다.
[00301] 도 21-27의 모듈들의 기능성은 본원의 교시들에 일치하는 다양한 방식들로 구현될 수 있다. 일부 설계들에서, 이들 모듈들의 기능성은 하나 또는 그 초과의 전기 컴포넌트들로 구현될 수 있다. 일부 설계들에서, 이들 블록들의 기능성은 하나 또는 그 초과의 프로세서 컴포넌트들을 포함하는 프로세싱 시스템으로 구현될 수 있다. 일부 설계들에서, 이들 모듈들의 기능성은 예컨대, 하나 또는 그 초과의 집적 회로들(예컨대, ASIC)의 적어도 부분을 사용하여 구현될 수 있다. 본원에 논의된 바와 같이, 집적 회로는 프로세서, 소프트웨어, 다른 관련 컴포넌트들, 또는 이들의 어떤 조합을 포함할 수 있다. 따라서, 상이한 모듈들의 기능성은 예컨대, 집적 회로의 상이한 서브세트들로, 소프트웨어 모듈들의 세트의 상이한 서브세트들로, 또는 이들의 조합으로 구현될 수 있다. 또한, (예컨대, 집적 회로 및/또는 소프트웨어 모듈들의 세트의) 주어진 서브세트는, 1개 초과의 모듈에 대한 기능성의 적어도 부분을 제공할 수 있다는 것이 인식될 것이다.
[00302] 부가적으로, 도 21-27에 의해 표현된 컴포넌트들 및 기능들 뿐만 아니라 본원에 설명된 다른 컴포넌트들 및 기능들은 임의의 적절한 수단을 사용하여 구현될 수 있다. 그러한 수단은 또한, 본원에 교시된 바와 같은 대응하는 구조를 사용하여 적어도 부분적으로 구현될 수 있다. 예컨대, 도 21-27의 컴포넌트들을 "위한 모듈"과 함께 위에서 설명된 컴포넌트들은 또한, 유사하게 지정된 기능을 "위한 수단"에 대응할 수 있다. 따라서, 일부 양상들에서, 그러한 수단 중 하나 또는 그 초과는 프로세서 컴포넌트들, 집적 회로들, 또는 본원에 교시된 바와 같은 다른 적절한 구조 중 하나 또는 그 초과를 사용하여 구현될 수 있다.
[00303] 정보 및 신호들이 다양한 상이한 기술들 및 기법들 중 임의의 기술 및 기법을 사용하여 표현될 수 있음을 당업자들은 인식할 것이다. 예컨대, 위의 설명 전반에 걸쳐 참조될 수 있는 데이터, 명령들, 커맨드들, 정보, 신호들, 비트들, 심볼들, 및 칩들은 전압들, 전류들, 전자기파들, 자기장들 또는 자기 입자들, 광학 필드들 또는 광학 입자들, 또는 이들의 임의의 조합에 의해 표현될 수 있다.
[00304] 추가로, 본원에 개시된 실시예들과 관련하여 설명된 다양한 예시적인 로지컬 블록들, 모듈들, 회로들, 및 알고리즘 단계들이 전자 하드웨어, 컴퓨터 소프트웨어, 또는 이 둘의 결합들로서 구현될 수 있음을 당업자들은 인식할 것이다. 하드웨어와 소프트웨어의 이러한 교환가능성을 명확히 예시하기 위해, 다양한 예시적인 컴포넌트들, 블록들, 모듈들, 회로들, 및 단계들은 그들의 기능성의 관점들에서 일반적으로 위에서 설명되었다. 그러한 기능이 하드웨어로서 구현되는지 또는 소프트웨어로서 구현되는지는 특정 애플리케이션 및 전체 시스템에 부과된 설계 제약들에 의존한다. 당업자들은 설명된 기능성을 각각의 특정 애플리케이션에 대해 다양한 방식들로 구현할 수 있지만, 이러한 구현 결정들이 본 개시내용의 범위를 벗어나게 하는 것으로 해석되어서는 안 된다.
[00305] 본원의 개시된 실시예들과 관련하여 설명되는 다양한 예시적인 로지컬 블록들, 모듈들, 및 회로들이 범용 프로세서, DSP(digital signal processor), ASIC(application specific integrated circuit), FPGA(field programmable gate array) 또는 다른 프로그램가능 로직 디바이스, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들 또는 본원에 설명된 기능들을 수행하도록 설계된 이들의 임의의 조합으로 구현되거나 또는 수행될 수 있다. 범용 프로세서는 마이크로프로세서일 수 있지만, 대안적으로, 프로세서는 임의의 종래의 프로세서, 제어기, 마이크로제어기, 또는 상태 머신일 수 있다. 또한, 프로세서는 컴퓨팅 디바이스들의 조합, 예컨대 DSP와 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 또는 그 초과의 마이크로프로세서들, 또는 임의의 다른 그러한 구성으로서 구현될 수 있다.
[00306] 본원에 개시된 실시예들과 관련하여 설명되는 방법들, 시퀀스들, 및/또는 알고리즘들은, 직접적으로 하드웨어로, 프로세서에 의해 실행되는 소프트웨어 모듈로, 또는 이 둘의 조합으로 구현될 수 있다. 소프트웨어 모듈은, RAM 메모리, 플래시 메모리, ROM 메모리, EPROM 메모리, EEPROM 메모리, 레지스터들, 하드 디스크, 제거가능 디스크, CD-ROM, 또는 당업계에 알려져 있는 임의의 다른 형태의 저장 매체에 상주할 수 있다. 예시적인 저장 매체는 프로세서가 저장 매체로부터 정보를 판독하고, 저장 매체에 정보를 기록할 수 있도록 프로세서에 커플링된다. 대안적으로, 저장 매체는 프로세서에 통합될 수 있다. 프로세서 및 저장 매체는 ASIC에 상주할 수 있다. ASIC는 사용자 단말(예컨대, UE)에 상주할 수 있다. 대안적으로, 프로세서 및 저장 매체는 사용자 단말에서 이산 컴포넌트들로서 상주할 수 있다.
[00307] 하나 또는 그 초과의 예시적인 실시예들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수 있다. 소프트웨어로 구현되면, 기능들은 컴퓨터-판독가능 매체 상에 하나 또는 그 초과의 명령들 또는 코드로서 저장되거나 이들을 통해 송신될 수 있다. 컴퓨터-판독가능 매체는 일 장소에서 다른 장소로의 컴퓨터 프로그램의 전달을 용이하게 하는 임의의 매체를 포함한 통신 매체 및 컴퓨터 저장 매체 둘 모두를 포함한다. 저장 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있다. 제한이 아닌 예로서, 그러한 컴퓨터-판독가능 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 저장소, 자기 디스크 저장 또는 다른 자기 저장 디바이스들, 또는 명령들 또는 데이터 구조들의 형태로 원하는 프로그램 코드를 반송 또는 저장하는데 사용될 수 있고, 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 연결수단(connection)이 컴퓨터-판독가능 매체로 적절히 지칭된다. 예컨대, 소프트웨어가 동축 케이블, 광섬유 케이블, 연선, DSL(digital subscriber line), 또는 적외선, 라디오 및 마이크로파와 같은 무선 기술들을 사용하여 웹사이트, 서버 또는 다른 원격 소스로부터 송신되면, 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 적외선, 라디오 및 마이크로파와 같은 무선 기술들이 매체의 정의에 포함된다. 본원에서 사용되는 바와 같이, 디스크(disk) 및 디스크(disc)는 CD(compact disc), 레이저 디스크(disc), 광학 디스크(disc), DVD(digital versatile disc), 플로피 디스크(disk) 및 블루-레이 디스크(disc)를 포함하며, 여기서 디스크(disk)들은 일반적으로 데이터를 자기적으로 재생하지만, 디스크(disc)들은 레이저들을 이용하여 광학적으로 데이터를 재생한다. 또한, 상기의 것들의 조합들은 컴퓨터-판독가능 매체들의 범위 내에 포함되어야 한다.
[00308] 전술한 개시내용은 본 개시내용의 예시적인 실시예들을 도시하지만, 첨부된 청구항들에 의해 정의되는 바와 같은 본 개시내용의 범위를 벗어나지 않으면서 다양한 변화들 및 수정들이 이루어질 수 있음이 주목되어야 한다. 본원에 설명된 개시내용의 실시예에 따른 방법 청구항들의 기능들, 단계들 및/또는 액션들은 임의의 특정 순서로 수행될 필요는 없다. 또한, 본 개시내용의 엘리먼트들이 단수로 설명되거나 청구될 수 있지만, 단수에 대한 제한이 명시적으로 언급되지 않으면 복수가 고려된다.

Claims (30)

  1. UE(user equipment)를 서빙하는 액세스 네트워크 노드에 의해서 수행되는, UE를 로케이팅(locating)하는 방법으로서,
    상기 UE로부터 제 1 메시지를 수신하는 단계 ― 상기 제 1 메시지는 상기 UE가 상기 액세스 네트워크 노드에 어태치(attach)하기 위한 요청을 포함함 ―;
    상기 제 1 메시지를 수신하는 것에 대한 응답으로, 상기 UE에 대한 로케이션 레퍼런스(location reference)를 결정하는 단계 ― 상기 로케이션 레퍼런스는 상기 액세스 네트워크 노드에 대한 오퍼레이터(operator)에 속하는 로케이션 서버에 대한 것이고, 그리고 상기 로케이션 레퍼런스는 상기 UE가 로케이팅되게 할 수 있음 ―; 및
    상기 UE에 제 2 메시지를 전송하는 단계를 포함하고,
    상기 제 2 메시지는 상기 UE가 상기 액세스 네트워크 노드에 어태치하기 위한 요청의 수용을 포함하고, 그리고
    상기 제 2 메시지는 상기 로케이션 레퍼런스를 포함하는, UE를 로케이팅하는 방법.
  2. 제 1항에 있어서,
    상기 UE에 대한 로케이션 레퍼런스를 결정하는 단계는:
    상기 UE에 대한 상기 로케이션 레퍼런스에 대한 요청을 상기 로케이션 서버에 전송하는 단계; 및
    상기 로케이션 서버로부터 상기 UE에 대한 상기 로케이션 레퍼런스를 수신하는 단계를 포함하는, UE를 로케이팅하는 방법.
  3. 제 1항에 있어서,
    상기 UE에 대한 상기 로케이션 레퍼런스는 프로토콜의 식별, 상기 로케이션 서버의 어드레스 및 상기 UE에 대한 UE 레퍼런스를 포함하는, UE를 로케이팅하는 방법.
  4. 제 3항에 있어서,
    상기 UE 레퍼런스는 IP(Internet protocol) 어드레스, IMSI(International Mobile Subscriber Identifier), TMSI(Temporary Mobile Subscriber Identifier), 상기 UE의 로컬 어드레스, 상기 액세스 네트워크 노드의 어드레스, 또는 이들의 임의의 조합을 포함하는, UE를 로케이팅하는 방법.
  5. 제 1항에 있어서,
    상기 UE에 대한 로케이션 레퍼런스를 결정하는 단계는 상기 액세스 네트워크 노드에서 상기 UE에 대한 로케이션 레퍼런스를 생성하는 단계를 포함하는, UE를 로케이팅하는 방법.
  6. 제 5항에 있어서,
    상기 UE에 대한 로케이션 레퍼런스가 상기 오퍼레이터에 대한 상기 액세스 네트워크 노드에 의해서 생성되었음을 표시하기 위해 상기 UE에 대한 로케이션 레퍼런스를 디지털적으로 서명하는 단계를 더 포함하는, UE를 로케이팅하는 방법.
  7. 제 1항에 있어서,
    상기 액세스 네트워크 노드는 LTE(Long Term Evolution)를 지원하는 MME(Mobility Management Entity)를 포함하고,
    상기 제 1 메시지는 NAS(Non Access Stratum) 어태치 요청 또는 NAS 추적 영역 업데이트 요청을 포함하며, 그리고
    상기 제 2 메시지는 NAS 어태치 수용 또는 NAS 추적 영역 업데이트 수용을 포함하는, UE를 로케이팅하는 방법.
  8. 제 1항에 있어서,
    상기 액세스 네트워크 노드는 UMTS(Universal Mobile Telecommunications System)를 지원하는 SGSN(Serving General Packet Radio Service (GPRS) Support Node)을 포함하고,
    상기 제 1 메시지는 GPRS 어태치 요청 또는 GPRS 라우팅 영역 업데이트 요청을 포함하며, 그리고
    상기 제 2 메시지는 GPRS 어태치 수용 또는 GPRS 라우팅 영역 업데이트 수용을 포함하는, UE를 로케이팅하는 방법.
  9. 제 1항에 있어서,
    상기 로케이션 서버는 GMLC(Gateway Mobile Location Center), SLP(Secure User Plane Location (SUPL) Location Platform) 또는 LRF(Location Retrieval Function)를 포함하는, UE를 로케이팅하는 방법.
  10. 제 1항에 있어서,
    상기 UE는 OTT(over-the-top) SP(service provider)에 전송되는 긴급 서비스들 호 요청에 상기 UE에 대한 로케이션 레퍼런스를 포함시키는, UE를 로케이팅하는 방법.
  11. 제 10항에 있어서,
    상기 UE는 상기 액세스 네트워크 노드에 대한 액세스 네트워크와 상이한 액세스 네트워크를 통해서 상기 긴급 서비스들 호 요청을 상기 OTT SP에 전송하는, UE를 로케이팅하는 방법.
  12. 제 10항에 있어서,
    상기 OTT SP는 상기 로케이션 레퍼런스에 기반하여 상기 로케이션 서버로부터 상기 UE의 로케이션를 획득하는, UE를 로케이팅하는 방법.
  13. 제 1항에 있어서,
    상기 제 2 메시지를 전송하기 이전에 상기 UE를 인증하는 단계를 더 포함하는, UE를 로케이팅하는 방법.
  14. 제 1항에 있어서,
    상기 UE가 상기 액세스 네트워크 노드에 어태치되는 동안에 상기 UE에 대한 새로운 로케이션 레퍼런스를 주기적으로 결정하는 단계; 및
    상기 UE에 상기 새로운 로케이션 레퍼런스를 전송하는 단계를 더 포함하는, UE를 로케이팅하는 방법.
  15. 로케이션 서버에서 수행되는, UE(user equipment)를 로케이팅하는 방법으로서,
    상기 UE를 서빙하는 액세스 네트워크 노드로부터 상기 UE에 대한 로케이션 레퍼런스에 대한 요청을 수신하는 단계;
    상기 액세스 네트워크 노드에 상기 UE에 대한 로케이션 레퍼런스를 전송하는 단계;
    상기 액세스 네트워크 노드 이외의 네트워크 엔티티로부터 상기 UE의 로케이션에 대한 로케이션 요청을 수신하는 단계 ― 상기 로케이션 요청은 상기 UE에 대한 로케이션 레퍼런스를 포함함 ―;
    상기 UE에 대한 로케이션 추정을 결정하는 단계; 및
    상기 네트워크 엔티티에 상기 UE에 대한 로케이션 추정을 전송하는 단계를 포함하는, UE를 로케이팅하는 방법.
  16. 제 15항에 있어서,
    상기 네트워크 엔티티는 OTT(Over-the-Top) 서비스 제공자, ESInet(Emergency Services IP network) 제공자 또는 PSAP(Public Safety Answering Point)에 속하는 네트워크 엔티티를 포함하는, UE를 로케이팅하는 방법.
  17. 제 15항에 있어서,
    상기 로케이션 서버는 SLP(Secure User Plane Location (SUPL) Location Platform), 또는 SLP와 연관되거나 또는 상기 SLP에 연결되는 로케이션 리트리벌 기능부를 포함하고, 그리고
    상기 UE에 대한 로케이션 추정을 결정하는 단계는 사용자 평면 로케이션 솔루션을 사용하여 상기 로케이션 추정을 결정하는 단계를 포함하는, UE를 로케이팅하는 방법.
  18. 제 15항에 있어서,
    상기 로케이션 서버는 GMLC(Gateway Mobile Location Center), 또는 GMLC와 연관되거나 또는 상기 GMLC에 연결되는 LRF(Location Retrieval Function)를 포함하고, 그리고
    상기 UE에 대한 로케이션 추정을 결정하는 단계는 제어 평면 로케이션 솔루션을 사용하여 상기 로케이션 추정을 결정하는 단계를 포함하는, UE를 로케이팅하는 방법.
  19. 제 15항에 있어서,
    상기 로케이션 레퍼런스는 프로토콜의 식별, 상기 로케이션 서버의 어드레스, 및 상기 로케이션 서버에 로컬적인 상기 UE에 대한 UE 레퍼런스를 포함하는, UE를 로케이팅하는 방법.
  20. 로케이션 서버에서 수행되는, UE(user equipment)를 로케이팅하는 방법으로서,
    네트워크 엔티티로부터 상기 UE의 로케이션에 대한 로케이션 요청을 수신하는 단계 ― 상기 로케이션 요청은 상기 UE에 대한 로케이션 레퍼런스를 포함하고, 그리고 상기 로케이션 레퍼런스는 상기 UE에 대한 UE 레퍼런스를 포함함 ―;
    상기 UE에 대한 로케이션 레퍼런스를 인증하는 단계;
    상기 UE에 대한 로케이션 레퍼런스의 UE 레퍼런스에 기반하여 상기 UE에 대한 로케이션 추정을 결정하는 단계; 및
    상기 네트워크 엔티티에 상기 UE에 대한 로케이션 추정을 전송하는 단계를 포함하는, UE를 로케이팅하는 방법.
  21. 제 20항에 있어서,
    상기 UE에 대한 로케이션 레퍼런스는 디지털 시그니처(digital signature)를 포함하고, 그리고
    상기 로케이션 레퍼런스를 인증하는 단계는 상기 디지털 시그니처를 인증하는 단계를 포함하는, UE를 로케이팅하는 방법.
  22. 제 20항에 있어서,
    상기 UE 레퍼런스는 암호화되고, 그리고
    상기 UE에 대한 로케이션 추정을 결정하는 단계는 암호화된 UE 레퍼런스를 복호화하는 단계를 포함하는, UE를 로케이팅하는 방법.
  23. 제 20항에 있어서,
    상기 네트워크 엔티티는 OTT(Over-the-Top) 서비스 제공자, ESInet(Emergency Services IP network) 제공자 또는 PSAP(Public Safety Answering Point)에 속하는 네트워크 엔티티를 포함하는, UE를 로케이팅하는 방법.
  24. 제 20항에 있어서,
    상기 UE는 OTT(Over-the-Top) SP(service provider)에 전송되는 긴급 서비스들 호 요청에 상기 UE에 대한 로케이션 레퍼런스를 포함시키는, UE를 로케이팅하는 방법.
  25. UE(user equipment)에 의해서 호가 수행되게 하는, UE를 로케이팅하는 방법으로서,
    상기 UE를 서빙하는 액세스 네트워크 노드에 제 1 메시지를 전송하는 단계 ― 상기 제 1 메시지는 상기 UE가 상기 액세스 네트워크 노드에 어태치하기 위한 요청을 포함함 ―;
    상기 UE에 대한 로케이션 레퍼런스를 포함하는 제 2 메시지를 상기 액세스 네트워크 노드로부터 수신하는 단계 ― 상기 제 2 메시지는 상기 UE가 상기 액세스 네트워크 노드에 어태치하기 위한 요청의 수용을 포함하고, 상기 로케이션 레퍼런스는 상기 액세스 네트워크 노드에 대한 오퍼레이터에 속하는 로케이션 서버에 대한 것이고, 그리고 상기 로케이션 레퍼런스는 상기 UE가 상기 호를 위해 로케이팅되게 할 수 있음 ―;
    상기 UE의 사용자로부터 상기 호에 대한 요청을 수신하는 단계; 및
    상기 호에 대한 요청을 OTT(over-the-top) SP(service provider)에 전송하는 단계를 포함하고,
    상기 호에 대한 요청은 상기 UE에 대한 로케이션 레퍼런스를 포함하는, UE를 로케이팅하는 방법.
  26. 제 25항에 있어서,
    상기 UE에 대한 로케이션 레퍼런스는 프로토콜의 식별, 상기 로케이션 서버의 어드레스, 및 상기 로케이션 서버에 로컬적인 상기 UE의 UE 레퍼런스를 포함하는, UE를 로케이팅하는 방법.
  27. 제 25항에 있어서,
    상기 제 2 메시지를 수신하기 이전에 상기 액세스 네트워크 노드에 UE 아이덴티티(identity)를 인증하는 단계를 더 포함하는, UE를 로케이팅하는 방법.
  28. 제 25항에 있어서,
    상기 UE가 상기 액세스 네트워크 노드에 어태치되는 동안에 상기 액세스 네트워크 노드로부터 상기 UE에 대한 새로운 로케이션 레퍼런스를 주기적으로 수신하는 단계를 더 포함하는, UE를 로케이팅하는 방법.
  29. 제 25항에 있어서,
    상기 호는 긴급 서비스들 호를 포함하는, UE를 로케이팅하는 방법.
  30. 제 25항에 있어서,
    상기 UE는 상기 액세스 네트워크 노드에 대한 액세스 네트워크와 상이한 액세스 네트워크를 통해서 상기 호에 대한 요청을 상기 OTT SP에 전송하는, UE를 로케이팅하는 방법.
KR1020177013693A 2014-11-24 2015-11-10 Ott(over-the-top) 긴급 호에 대한 레퍼런스에 의한 로케이션 KR102409866B1 (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201462083768P 2014-11-24 2014-11-24
US62/083,768 2014-11-24
US201562101974P 2015-01-09 2015-01-09
US62/101,974 2015-01-09
US14/863,794 US10097979B2 (en) 2014-11-24 2015-09-24 Location by reference for an over-the-top emergency call
US14/863,794 2015-09-24
PCT/US2015/060011 WO2016085648A1 (en) 2014-11-24 2015-11-10 Location by reference for an over-the-top emergency call

Publications (2)

Publication Number Publication Date
KR20170091598A true KR20170091598A (ko) 2017-08-09
KR102409866B1 KR102409866B1 (ko) 2022-06-15

Family

ID=54608971

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177013693A KR102409866B1 (ko) 2014-11-24 2015-11-10 Ott(over-the-top) 긴급 호에 대한 레퍼런스에 의한 로케이션

Country Status (8)

Country Link
US (2) US10097979B2 (ko)
EP (1) EP3225041B1 (ko)
JP (1) JP6805143B2 (ko)
KR (1) KR102409866B1 (ko)
CN (1) CN107005802B (ko)
AU (1) AU2015354710B2 (ko)
BR (1) BR112017010802B1 (ko)
WO (1) WO2016085648A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11617059B1 (en) 2021-05-28 2023-03-28 T-Mobile Usa, Inc. Mobile device geographic location determination for emergency services

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10097979B2 (en) 2014-11-24 2018-10-09 Qualcomm Incorporated Location by reference for an over-the-top emergency call
US9756664B2 (en) 2014-11-24 2017-09-05 Qualcomm Incorporated Methods of supporting location and emergency calls for an over-the-top service provider
US10292125B2 (en) * 2015-09-02 2019-05-14 Huawei Technologies Co., Ltd. Method and apparatus for interoperability
CN115175372A (zh) * 2016-01-08 2022-10-11 北京三星通信技术研究有限公司 控制ue上下文和ue连接的方法和设备
WO2017196753A1 (en) * 2016-05-09 2017-11-16 Rapidsos, Inc. Systems and methods for emergency communications
EP3504693B1 (en) 2016-08-26 2021-07-28 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
US10506413B2 (en) 2017-08-28 2019-12-10 Intrinsic Value, Llc Systems, devices, and methods for emergency responses and safety
US10412093B2 (en) 2016-08-31 2019-09-10 Bank Of America Corporation Preventing unauthorized access to secured information systems by injecting device data collectors
US10263971B2 (en) 2016-08-31 2019-04-16 Bank Of America Corporation Preventing unauthorized access to secured information systems by injecting device data collectors
CN108243405B (zh) * 2016-12-26 2021-09-21 中国移动通信集团广东有限公司 一种指纹库的建立方法、测量报告mr的定位方法及装置
US10721703B2 (en) * 2017-02-02 2020-07-21 Telefonaktiebolaget Lm Ericsson (Publ) Notification of ongoing multilateration timing advance (MTA) procedure to a serving GPRS support node (SGSN)
US10477502B2 (en) 2017-02-02 2019-11-12 Telefonaktiebolaget Lm Ericsson (Publ) Notification of delivery of a RRLP multilateration timing advance request message to a base station subsystem (BSS)
US10412537B2 (en) * 2017-08-31 2019-09-10 T-Mobile Usa, Inc. SIP options based location determination
CN107750051B (zh) * 2017-09-29 2020-06-23 重庆玖舆博泓科技有限公司 无线传播模型的优化方法及其装置
US10939239B2 (en) * 2017-11-06 2021-03-02 Qualcomm Incorporated Systems and methods for coexistence of different location solutions for fifth generation wireless networks
US10652950B2 (en) 2017-11-16 2020-05-12 Cisco Technology, Inc. Method and system for providing signed user location information
CN111434149B (zh) * 2017-11-22 2022-09-23 华为技术有限公司 定位服务方法及相关设备
CN108282844B (zh) * 2018-01-27 2020-11-17 惠州Tcl移动通信有限公司 一种控制用户终端选择网络制式的网络及方法
US10616935B2 (en) * 2018-06-22 2020-04-07 Blackberry Limited Emergency calls
US20220191650A1 (en) * 2019-05-10 2022-06-16 Samsung Electronics Co., Ltd. Method and apparatus for obtaining and managing location information of mobile terminal in edge computing system
US10873845B1 (en) * 2019-08-19 2020-12-22 T-Mobile Usa, Inc. Modernized messaging compatibility with interim text-to-911
US11129128B2 (en) * 2020-01-27 2021-09-21 T-Mobile Usa, Inc. Device to device communication for establishing voice calls in a 5G cellular system
US11134368B1 (en) * 2020-05-29 2021-09-28 T-Mobile Usa, Inc. Conveying precise civic address with an emergency call
US11399271B2 (en) 2020-06-01 2022-07-26 T-Mobile Usa, Inc. Conveying user equipment location with an emergency call
US20230328478A1 (en) * 2022-04-12 2023-10-12 At&T Intellectual Property I, L.P. Guidance to a target location
WO2024159399A1 (en) * 2023-01-31 2024-08-08 Nokia Solutions And Networks Oy Location integrity protection

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110201305A1 (en) * 2010-02-12 2011-08-18 Mark Buer Method and system for ensuring user and/or device anonymity for location based services (lbs)
US20110222471A1 (en) * 2010-03-11 2011-09-15 Charles Abraham Method and system for optimized transfer of location database information
US20120178411A1 (en) * 2009-09-24 2012-07-12 Zte Corporation Method and System for Implementing Emergency Location
US8254877B2 (en) * 2008-01-04 2012-08-28 Qualcomm Incorporated Method and apparatus for extended call establishment for IMS emergency calls
JP2014504044A (ja) * 2010-12-02 2014-02-13 日本電気株式会社 通信システム、制御装置、通信方法およびプログラム
WO2014093613A1 (en) * 2012-12-12 2014-06-19 Interdigital Patent Holdings, Inc. Independent identity management systems

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100391307C (zh) * 2004-12-22 2008-05-28 华为技术有限公司 根据用户终端请求进行位置定位的方法
EP1703758B1 (en) * 2005-03-18 2017-05-17 Alcatel Lucent Provision of location information relating to an emergency call
US7852834B2 (en) 2005-04-12 2010-12-14 Telecommunication Systems, Inc. Temporary ENUM gateway
CN1889606B (zh) * 2005-06-30 2011-04-06 华为技术有限公司 一种分组域地理位置信息查询方法
US20070086382A1 (en) 2005-10-17 2007-04-19 Vidya Narayanan Methods of network access configuration in an IP network
US20070153986A1 (en) 2006-01-03 2007-07-05 Sony Ericsson Mobile Communications Ab Method and Apparatus for Routing Emergency Calls in a VoIP System
US7463880B2 (en) 2006-01-13 2008-12-09 Kyocera Wireless Corp. E911 behavior with GSRM in a wireless communication device
US8493267B2 (en) * 2006-11-10 2013-07-23 Qualcomm Incorporated Method and apparatus for position determination with extended SPS orbit information
US9185216B2 (en) 2007-06-15 2015-11-10 Blackberry Limited System and method for indicating emergency call back to user equipment
US7991382B1 (en) 2007-11-08 2011-08-02 Sprint Spectrum L.P. Method for communicating indoor location to an emergency service system
US20090154397A1 (en) 2007-12-17 2009-06-18 Nortel Networks Limited System and method for providing quality of service enablers for third party applications
CN101203046B (zh) * 2007-12-19 2010-12-15 华为技术有限公司 用户位置信息的获取方法、系统及呼叫接收设备
US9208293B1 (en) 2008-01-28 2015-12-08 Sprint Communications Company L.P. Authentication for tag-based content delivery
US8369822B2 (en) 2009-05-28 2013-02-05 At&T Intellectual Property I, Lp Systems and methods for providing emergency callback procedures
US8594015B2 (en) 2009-07-29 2013-11-26 T-Mobile Usa, Inc. System and method for providing emergency service in an IP-based wireless network
US20110026687A1 (en) 2009-07-31 2011-02-03 Vladimir Smelyansky Emergency 911 services with just-in-time provisioning for voip customers
US8270574B2 (en) 2009-09-08 2012-09-18 Verizon Patent And Licensing Inc. Emergency calls in internet protocol multimedia subsystem (IMS) over evolved packet core (EPC) networks
US8315589B2 (en) 2009-09-30 2012-11-20 Verizon Patent And Licensing Inc. Emergency calls for internet protocol multimedia subsystem (IMS) over packet switched code division multiple access (CDMA) networks
US8565714B2 (en) 2011-01-14 2013-10-22 Interdigital Patent Holdings, Inc. Identifying public safety answering point (PSAP) callbacks in internet protocol (IP) multimedia subsystem (IMS) emergency services
US8929855B2 (en) 2011-12-02 2015-01-06 Maple Acquisition Llc Enabling location determination of user device originating emergency service call
EP2807857B1 (en) 2012-01-27 2017-06-28 Telefonaktiebolaget LM Ericsson (publ) Handover of emergency calls from a circuit switched to a packet switched access network
WO2013135316A1 (en) 2012-03-12 2013-09-19 Telefonaktiebolaget L M Ericsson (Publ) Handover of user-equipment (ue) undetected emergency calls
US9161196B2 (en) * 2012-08-07 2015-10-13 Google Technology Holdings LLC Apparatus and method for secure private location information transfer
EP2901766A2 (en) * 2012-09-27 2015-08-05 Interdigital Patent Holdings, Inc. End-to-end architecture, api framework, discovery, and access in a virtualized network
US20140031003A1 (en) 2012-10-02 2014-01-30 Bandwidth.Com, Inc. Methods and systems for providing emergency calling
US9609497B2 (en) 2012-11-16 2017-03-28 Verizon Patent And Licensing Inc. Intelligent emergency session handling
US9426833B2 (en) 2013-03-01 2016-08-23 T-Mobile Usa, Inc. Systems and methods for emergency call route failover
US9516689B2 (en) * 2014-02-21 2016-12-06 Apple Inc. Mitigating no-service delays for LTE capable wireless devices without LTE access permission
US10299099B2 (en) 2014-09-17 2019-05-21 Nokia Technologies Oy Emergency call handling using over-the-top services
WO2016080880A1 (en) 2014-11-20 2016-05-26 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for retrieving geographic location
US10097979B2 (en) 2014-11-24 2018-10-09 Qualcomm Incorporated Location by reference for an over-the-top emergency call
US9756664B2 (en) 2014-11-24 2017-09-05 Qualcomm Incorporated Methods of supporting location and emergency calls for an over-the-top service provider

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8254877B2 (en) * 2008-01-04 2012-08-28 Qualcomm Incorporated Method and apparatus for extended call establishment for IMS emergency calls
US20120178411A1 (en) * 2009-09-24 2012-07-12 Zte Corporation Method and System for Implementing Emergency Location
US20110201305A1 (en) * 2010-02-12 2011-08-18 Mark Buer Method and system for ensuring user and/or device anonymity for location based services (lbs)
US20110222471A1 (en) * 2010-03-11 2011-09-15 Charles Abraham Method and system for optimized transfer of location database information
JP2014504044A (ja) * 2010-12-02 2014-02-13 日本電気株式会社 通信システム、制御装置、通信方法およびプログラム
WO2014093613A1 (en) * 2012-12-12 2014-06-19 Interdigital Patent Holdings, Inc. Independent identity management systems

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11617059B1 (en) 2021-05-28 2023-03-28 T-Mobile Usa, Inc. Mobile device geographic location determination for emergency services

Also Published As

Publication number Publication date
US10085142B2 (en) 2018-09-25
WO2016085648A1 (en) 2016-06-02
CN107005802B (zh) 2020-08-21
CN107005802A (zh) 2017-08-01
AU2015354710B2 (en) 2019-07-11
KR102409866B1 (ko) 2022-06-15
US20160249193A1 (en) 2016-08-25
EP3225041B1 (en) 2021-08-04
US20170339543A1 (en) 2017-11-23
BR112017010802B1 (pt) 2023-10-24
JP2017539161A (ja) 2017-12-28
JP6805143B2 (ja) 2020-12-23
EP3225041A1 (en) 2017-10-04
AU2015354710A1 (en) 2017-05-04
BR112017010802A2 (pt) 2017-12-26
US10097979B2 (en) 2018-10-09

Similar Documents

Publication Publication Date Title
KR102409866B1 (ko) Ott(over-the-top) 긴급 호에 대한 레퍼런스에 의한 로케이션
KR101825898B1 (ko) 오버-더-탑 서비스 제공자를 위한 로케이션 및 긴급 호들을 지원하는 방법들
JP6736582B2 (ja) 非補償気圧情報の転送
EP3537668B1 (en) Location identifiers in mobile messaging
CN101273615B (zh) Voip紧急呼叫处理
EP2785084A1 (en) Locating emergency calls via femto access points
CN110622025B (zh) 用于移动装置的定位的方法和/或系统
US20110231561A1 (en) System and Method for Routing SUPL Proxy-Mode Traffice When Multiple Nodes are Deployed in a Network
WO2017121566A1 (en) Location determination of a wireless device

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant