支持用于过顶服务提供者的定位和紧急呼叫的方法和设备

摘要

本发明揭示了用于支持过顶OTT服务提供者的定位和紧急呼叫的方法和设备。UE可将针对紧急呼叫的请求发送到OTT服务提供者，且可在所述请求中包含用于所述UE的服务移动网络运营商MNO的MNO数据。所述OTT服务提供者可将所述紧急呼叫请求转发到因特网协议IP多媒体子系统IMS。所述IMS可确定用于所述紧急呼叫的路由信息，且将所述路由信息返回到所述OTT服务提供者以使所述OTT服务提供者能够将所述紧急呼叫路由到公共安全应答点PSAP或者可以自身将所述紧急呼叫路由到所述PSAP。由所述IMS或由所述OTT服务提供者路由的所述呼叫请求可包含参考识别符，所述参考识别符可使得所述PSAP能够从所述IMS获得所述UE的位置。

权利要求

1.一种在过顶OTT服务提供者处支持紧急呼叫的方法，其包括：从用户设备UE接收包括紧急呼叫请求的第一消息，其中所述第一消息经由用于所述UE的服务移动网络运营商MNO传送到所述OTT服务提供者，且其中所述第一消息包含用于所述服务MNO的因特网协议IP多媒体子系统IMS的地址；以及基于所述地址将第二消息发送到所述IMS，其中所述第二消息包括针对紧急呼叫的请求。

2.根据权利要求1所述的方法，其中所述第一消息、所述第二消息或这两个消息包括会话起始协议SIP邀请消息。

3.根据权利要求1所述的方法，其进一步包括：

从所述IMS接收包括用于目的地公共安全应答点PSAP的路由信息的第三消息；以及基于所述路由信息将第四消息发送到或朝向所述PSAP，其中所述第四消息包括针对紧急呼叫的请求。

4.根据权利要求3所述的方法，其中所述第三消息包括会话起始协议SIP 300多重选择消息。

5.根据权利要求3所述的方法，其中用于所述IMS的所述地址是用于位置检索功能LRF的地址。

6.根据权利要求5所述的方法，其中所述路由信息包含参考识别符ID，且其中所述方法进一步包括：在所述第四消息中包含所述参考ID，其中所述参考ID使得所述PSAP能够从所述LRF获得所述UE的位置。

7.根据权利要求1所述的方法，其中所述IMS将第五消息发送到或朝向目的地PSAP，其中所述第五消息包括针对所述UE的紧急呼叫请求。

8.根据权利要求7所述的方法，其中用于所述IMS的所述地址是用于紧急呼叫会话控制功能E-CSCF的地址。

9.根据权利要求7所述的方法，其中所述IMS在所述第五消息中包含参考识别符，其中所述参考识别符使得所述PSAP能够从所述IMS获得所述UE的位置。

10.一种在用于服务移动网络运营商MNO的因特网协议IP多媒体子系统IMS实体处支持紧急呼叫的方法，其包括：接收由过顶OTT服务提供者发送的包括针对用户设备UE的紧急呼叫请求的第一消息，其中所述紧急呼叫请求包含用于所述UE的MNO数据；以及基于所述MNO数据确定用于目的地公共安全应答点PSAP的路由信息。

11.根据权利要求10所述的方法，其中所述第一消息包括会话起始协议SIP邀请消息。

12.根据权利要求10所述的方法，其进一步包括：

将包括所述路由信息的第二消息发送到所述OTT服务提供者，其中所述路由信息使得所述OTT服务提供者能够将所述紧急呼叫路由到或朝向所述目的地PSAP。

13.根据权利要求12所述的方法，其中所述第二消息包括会话起始协议SIP 300多重选择消息。

14.根据权利要求12所述的方法，其中所述IMS实体是位置检索功能LRF。

15.根据权利要求12所述的方法，其中所述路由信息包括参考识别符ID以及所述PSAP或中间目的地的地址或身份。

16.根据权利要求15所述的方法，其进一步包括：

从另一实体接收包括所述参考ID的第三消息；

基于所述参考ID识别所述UE；

获得所述UE的位置；以及

将包括所述位置的第四消息发送到所述另一实体。

17.根据权利要求16所述的方法，其中所述参考ID包括紧急服务路由密钥ESRK、紧急服务路由数位ESRD加上移动台国际订户目录号码MSISDN，或位置统一资源识别符URI。

18.根据权利要求16所述的方法，其中使用控制平面定位解决方案或用户平面定位解决方案获得所述UE的所述位置。

19.根据权利要求16所述的方法，其中所述另一实体是所述PSAP、自动位置识别ALI或紧急服务IP网络ESInet。

20.根据权利要求10所述的方法，其进一步包括：

基于所述路由信息将第二消息发送到或朝向所述PSAP，其中所述第二消息包括针对所述紧急呼叫的请求。

21.根据权利要求20所述的方法，其中所述IMS实体是紧急呼叫会话控制功能CSCF。

22.一种在用户设备UE处支持紧急呼叫的方法，其包括：接收来自所述UE的用户的针对紧急呼叫的请求；

获得用于所述UE的服务移动网络运营商MNO的MNO数据；以及将包括针对所述紧急呼叫的请求的第一消息发送到过顶OTT服务提供者，其中针对所述紧急呼叫的所述请求包含所述MNO数据。

23.根据权利要求22所述的方法，其中所述MNO数据包括用于所述服务MNO的因特网协议IP多媒体子系统IMS的地址、用于所述UE的当前服务移动性管理实体或服务通用包无线电服务支持节点SGSN的身份、用于所述UE的服务MNO指派IP地址、所述UE的全局身份或本地身份，或其任何组合。

24.根据权利要求23所述的方法，其中所述OTT服务提供者基于用于所述IMS的所述地址将第二消息发送到所述IMS，其中所述第二消息包括针对所述紧急呼叫的请求且包含所述MNO数据。

25.根据权利要求24所述的方法，其中所述IMS基于所述MNO数据确定用于所述紧急呼叫的路由信息。

26.根据权利要求25所述的方法，其进一步包括：

接收针对根据用户平面定位解决方案或控制平面定位解决方案的位置估计或位置测量的请求，其中所述位置估计或位置测量使得所述IMS能够获得所述UE的位置，其中所述UE的所述位置使得所述IMS能够确定所述路由信息或为所述PSAP提供所述UE的所述位置。

27.根据权利要求25所述的方法，其中所述IMS将包括所述路由信息的第三消息发送到所述OTT服务提供者，其中所述OTT服务提供者将第四消息发送到或朝向目的地公共安全应答点PSAP，其中所述PSAP是基于所述路由信息而确定。

28.根据权利要求27所述的方法，其中用于所述IMS的所述地址是用于位置检索功能LRF的地址。

29.根据权利要求25所述的方法，其中所述IMS将第五消息发送到或朝向目的地PSAP，其中所述第五消息包括针对所述紧急呼叫的请求，且其中所述PSAP是基于所述路由信息而确定。

30.一种用于在过顶OTT服务提供者处支持紧急呼叫的设备，其包括：至少一个处理器；以及

收发器，其耦合到所述至少一个处理器且经配置以：

从用户设备UE接收包括紧急呼叫请求的第一消息，其中所述第一消息经由用于所述UE的服务移动网络运营商MNO传送到所述OTT服务提供者，且其中所述第一消息包含用于所述服务MNO的因特网协议IP多媒体子系统IMS的地址；以及基于所述地址将第二消息发送到所述IMS，其中所述第二消息包括针对所述紧急呼叫的请求。

说明书

支持用于过顶服务提供者的定位和紧急呼叫的方法和设备

[0001] 相关申请的交叉参考

[0002] 本专利申请案主张2014年11月24日申请的标题为“用于过顶紧急呼叫的通过参考的定位(LOCATION BY REFERENCE FOR AN OVER-THE-TOP EMERGENCY CALL)”的第62/083,768号美国临时申请案以及2015年1月9日申请的标题为“过顶服务提供者的位置传送替代方案(LOCATION TRANSFER ALTERNATIVES TO AN OVER-THE-TOP SERVICE PROVIDER)”的第
62/101,974号美国临时申请案的权益，以上申请案转让给本受让人且明确地以全文引用的方式并入本文中。

背景技术

[0003] 本发明的实施例涉及提供对用于过顶(over-the-top，OTT)服务提供者(SP)的定位和紧急呼叫的支持。

[0004] 无线通信系统已发展了多代，包含第一代模拟无线电话服务(1G)、第二代(2G)数字无线电话服务(包含过渡2.5G网络)及第三代(3G)及第四代(4G)高速数据/具有因特网功能的无线服务。

[0005] 作为4G演进的部分，长期演进(LTE)已由第三代合作伙伴计划(3GPP)开发作为无线电接入网络技术，用于移动电话和其它数据终端的高速数据的无线通信。LTE已经从全球移动通信系统(GSM)和从GSM的衍生物演进，例如GSM演进增强数据速率(EDGE)、通用移动电信系统(UMTS)以及高速分组接入(HSPA)。

[0006] 在北美，由公用网络运营商采用的例如支持GSM、UMTS和LTE的那些无线通信系统使用用于增强911或E911的解决方案，其将紧急情况呼叫者与适当的公共资源链接。所述解决方案尝试使呼叫者、即呼叫者的用户设备(UE)与例如物理地址或地理坐标等特定位置自动关联。以高准确性(例如，以50米或更小的距离误差)自动定位呼叫者且将位置提供到公共安全应答点(PSAP)可增加在紧急情况期间公共安全侧可响应的速度，尤其是呼叫者可能不能传送他/她的位置或不知道此位置的情况。另外，知道紧急情况呼叫者的近似位置(例如，呼叫者的装置正在接入的特定网络单元)对于将紧急呼叫路由到用于呼叫者的位置的正确PSAP可为必要的。

[0007] 被称为过顶(OTT)服务提供者(SP)的某些其它提供者还可将话音和数据相关服务提供到无线装置的用户，但不一定拥有或操作公共无线网络或者充当移动虚拟网络运营商(MVNO)。具有无线装置的用户接着可经由某个其它无线网络SP(例如，具有UMTS或LTE网络的SP)且可能也经由因特网而接入OTT SP资源(例如，一或多个服务器)。所述接入通常对服务无线网络SP透明(不同于对归属无线网络或MVNO的接入)，且可通常在网络和IP协议层级上方发生，从而得到名称“过顶”。在此情况下，OTT SP可为用户提供进行话音和数据呼叫(或会话)的能力以及在一些情况下进行紧急呼叫的能力。

[0008] 然而，OTT SP与公共无线网络运营商相比可能更难以获得紧急情况呼叫者的准确且可靠的位置，原因是对位置相关信息的受限制接入以及能够定位的资源的缺乏。举例来说，虽然服务无线网络可以接入无线呼叫者的小区相关信息(例如，无线呼叫者的服务小区ID)且可具有可用以获得无线呼叫者的准确位置的网络基础设施(例如，可测量来自无线呼叫者的装置的信号或其信号可由无线呼叫者的装置和位置服务器测量以将这些测量变换为位置估计的基站)，但OTT SP可能几乎没有此基础结构或信息。这会妨碍OTT SP将来自无线呼叫者的紧急呼叫路由到正确PSAP和/或将无线呼叫者的准确位置提供到PSAP，这会妨碍OTT SP提供可靠的紧急服务。另外，即使当PSAP可为已知的时，OTT SP也可能不始终具有将紧急呼叫转发到目的地PSAP的通信装置，或响应于来自PSAP的对呼叫者的位置的询问，例如在OTT SP缺乏到PSAP的必要连接性或者缺乏转发紧急呼叫或提供呼叫者位置的授权
的情况中。因此可存在改善对OTT SP的位置和紧急情况服务呼叫的支持的益处。

发明内容

[0009] 下文呈现涉及本文所揭示的用于对过顶(OTT)服务提供者提供位置传送替代方案的机制相关联的一或多个方面和/或实施例的简化概述。由此，不应将以下概述视为与所有预期方面和/或实施例相关的广泛概述，也不应认为以下概述识别与所有预期方面和/或实施例相关的关键或至关重要的要素，或描绘与任何特定方面和/或实施例相关联的范围。因此，以下概述具有以下唯一目的：以简化形式呈现和与本文中所揭示的机制相关的一或多个方面和/或实施例相关的某些概念以先于下文呈现的具体实施方式。

[0010] 揭示了用于支持OTT服务提供者的定位和紧急呼叫的方法及设备。一种在OTT服务提供者处支持紧急呼叫的方法包含：从用户设备(UE)接收包括紧急呼叫请求的第一消息，其中所述第一消息经由用于所述UE的服务移动网络运营商(MNO)传送到所述OTT服务提供者，且其中所述第一消息包含用于所述服务MNO的因特网协议(IP)多媒体子系统(IMS)的地址；以及基于所述地址将第二消息发送到所述IMS，其中所述第二消息包括针对紧急呼叫的请求。

[0011] 一种在用于服务MNO的IMS实体处支持紧急呼叫的方法包含：接收由OTT服务提供者发送的包括针对UE的紧急呼叫请求的第一消息，其中所述紧急呼叫请求包含用于所述UE的MNO数据；以及基于所述MNO数据确定用于目的地公共安全应答点(PSAP)的路由信息。

[0012] 一种在UE处支持紧急呼叫的方法包含：接收来自所述UE的用户的针对紧急呼叫的请求；获得用于所述UE的服务MNO的MNO数据；以及将包括针对所述紧急呼叫的请求的第一消息发送到OTT服务提供者，其中针对所述紧急呼叫的所述请求包含所述MNO数据。

[0013] 一种用于在OTT服务提供者处支持紧急呼叫的设备包含至少一个处理器以及收发器，所述收发器经配置以：接收包括来自UE的紧急呼叫请求的第一消息，其中所述第一消息经由用于所述UE的服务MNO传送到所述OTT服务提供者，且其中所述第一消息包含用于所述服务MNO的IMS的地址；以及基于所述地址将第二消息发送到所述IMS，其中所述第二消息包括针对所述紧急呼叫的请求。

[0014] 一种用于在用于服务MNO的IMS实体处支持紧急呼叫的设备包含至少一个处理器和收发器，所述收发器经配置以：接收由OTT服务提供者发送的包括针对UE的紧急呼叫请求的第一消息，其中所述紧急呼叫请求包含用于所述UE的MNO数据，且其中所述至少一个处理器经配置以基于所述MNO数据确定用于目的地PSAP的路由信息。

[0015] 一种用于在UE处支持紧急呼叫的设备包含至少一个处理器和收发器，所述收发器经配置以接收来自所述UE的用户的针对紧急呼叫的请求，获得用于所述UE的服务MNO的MNO数据，且将包括针对紧急呼叫的请求的第一消息发送到OTT服务提供者，其中针对紧急呼叫的所述请求包含所述MNO数据。

[0016] 一种用于在OTT服务提供者处支持紧急呼叫的设备包含：用于接收包括来自UE的紧急呼叫请求的第一消息的装置，其中所述第一消息经由用于所述UE的服务MNO传送到所述OTT服务提供者，且其中所述第一消息包含用于所述服务MNO的IMS的地址；以及用于基于所述地址将第二消息发送到所述IMS的装置，其中所述第二消息包括针对紧急呼叫的请求。

[0017] 一种在用于服务MNO的IMS实体处支持紧急呼叫的设备包含：用于接收由OTT服务提供者发送的包括针对UE的紧急呼叫请求的第一消息的装置，其中所述紧急呼叫请求包含用于所述UE的MNO数据；以及用于基于所述MNO数据确定用于目的地PSAP的路由信息的装
置。

[0018] 一种用于在UE处支持紧急呼叫的设备包含：用于接收来自UE的用户的针对紧急呼叫的请求的装置；用于获得用于所述UE的服务MNO的MNO数据的装置；以及用于将包括针对紧急呼叫的请求的第一消息发送到OTT服务提供者的装置，其中针对紧急呼叫的所述请求包含所述MNO数据。

[0019] 一种用于在OTT服务提供者处支持紧急呼叫的非暂时性计算机可读媒体包含：用以接收包括来自UE的紧急呼叫请求的第一消息的至少一个指令，其中所述第一消息经由用于所述UE的服务MNO传送到所述OTT服务提供者，且其中所述第一消息包含用于所述服务
MNO的IMS的地址；以及用以基于所述地址将第二消息发送到所述IMS的至少一个指令，其中所述第二消息包括针对紧急呼叫的请求。

[0020] 一种用于在用于服务MNO的IMS实体处支持紧急呼叫的非暂时性计算机可读媒体包含：用以接收由OTT服务提供者发送的包括针对UE的紧急呼叫请求的第一消息的至少一个指令，其中所述紧急呼叫请求包含用于所述UE的MNO数据；以及用以基于所述MNO数据确定用于目的地PSAP的路由信息的至少一个指令。

[0021] 一种用于在UE处支持紧急呼叫的非暂时性计算机可读媒体包含：用以接收来自所述UE的用户的针对紧急呼叫的请求的至少一个指令；用以获得用于所述UE的服务MNO的MNO数据的至少一个指令；以及用以将包括针对紧急呼叫的请求的第一消息发送到OTT服务提供者的至少一个指令，其中针对紧急呼叫的所述请求包含所述MNO数据。

[0022] 所属领域的技术人员基于附图和具体实施方式将明白与本文中所揭示的机制相关联的其它目的和优点。

附图说明

[0023] 因为在结合附图考虑时通过参考以下详细描述更好地理解本发明实施例及其许多附带优点，所以将容易获得对本发明实施例及其许多附带优点的更全面了解，附图只是为了说明而不是限制本发明而呈现，且在附图中：

[0024] 图1A说明根据本发明的至少一个方面的无线通信系统的高级系统架构。

[0025] 图1B说明根据本发明的至少一个方面的用于长期演进(LTE)无线接入的图1A中的系统架构的实例配置。

[0026] 图2A说明根据本发明的至少一个方面的图1A中说明的网络实体提供通过参考的定位的特定交互。

[0027] 图2B说明根据本发明的至少一个方面的图1B中说明的网络实体提供通过参考的定位的特定交互。

[0028] 图3说明根据本发明的至少一个方面的用于提供紧急服务的示范性架构。

[0029] 图4说明根据本发明的至少一个方面的用于通过参考的定位支持的示范性架构。

[0030] 图5说明根据本发明的至少一个方面的用于紧急服务的因特网协议(IP)多媒体子系统(IMS)支持的示范性架构。

[0031] 图6说明根据本发明的至少一个方面的用于紧急服务的IMS支持的另一示范性架构。

[0032] 图7说明根据本发明的至少一个方面的用于通过值的定位和通过参考的定位的示范性呼叫流程。

[0033] 图8说明根据本发明的至少一个方面的用于紧急呼叫的IMS支持的又一示范性呼叫流程。

[0034] 图9说明根据本发明的至少一个方面的用于紧急呼叫的IMS支持的另一示范性呼叫流程。

[0035] 图10是经配置以支持如本文教示的通信的组件的若干样本方面的简化框图。

[0036] 图11说明根据本发明的至少一个方面的用户设备(UE)的实例。

[0037] 图12说明包含用以执行本文所描述的功能性的结构组件的通信装置。

[0038] 图13说明根据本发明的实施例的服务器。

[0039] 图14到20说明根据本发明的各种方面的用于定位UE的示范性流程。

[0040] 图21到27是经配置以支持如本文教示的通信的设备的若干样本方面的其它简化框图。

[0041] 应注意在图2A、2B、7、8和9中所示的消息和呼叫流程中，个别消息和动作由数字标签指示，其有时在描述中称为操作或步骤。

具体实施方式

[0042] 揭示了用于支持过顶(OTT)服务提供者的位置和紧急呼叫的方法及设备。用户设备(UE)可将对紧急呼叫的请求发送到OTT服务提供者，且可在所述请求中包含用于UE的服务移动网络运营商(MNO)的MNO数据。MNO数据可包含用于所述服务MNO的IP多媒体子系统
(IMS)的地址。OTT服务提供者可将紧急呼叫请求转发到IMS。IMS可确定用于紧急呼叫的路由信息，且将路由信息返回到OTT服务提供者以使OTT服务提供者能够将紧急呼叫路由到公共安全应答点(PSAP)或者可以将紧急呼叫自身路由到PSAP。由IMS或由OTT服务提供者路由的呼叫请求可包含参考识别符，其可使得PSAP能够从IMS获得UE的位置。

[0043] 本发明的这些和其它方面在针对本发明的具体实施例的以下描述和相关附图中揭示。可在不脱离本发明范围的情况下设计替代性实施例。另外，将不会详细描述本发明的众所周知的元件或将省略所述元件，以免混淆本发明的相关细节。

[0044] 本文中所使用的词语“示范性”和/或“实例”意味着“充当实例、例子或说明”。本文中描述为“示范性”和/或“实例”的任何实施例未必应理解为比其它实施例优选或有利。同样，术语“本发明的实施例”并不需要本发明的所有实施例包含所论述的特征、优点或操作模式。

[0045] 另外，依据待由(例如)计算装置的元件执行的动作的序列来描述许多实施例。将认识到，可由特定电路(例如，专用集成电路(ASIC))、由正由一或多个处理器执行的程序指令或由两者的组合来执行本文中所述的各种动作。另外，可认为本文中所述的这些动作序列完全体现于任何形式的计算机可读存储媒体内，所述计算机可读存储媒体中存储有一组对应的计算机指令，所述计算机指令在被执行时将导致相关联的处理器执行本文中所述的功能性。因此，本发明的各种方面可以数种不同形式来体现，预期其全部属于所主张的标的物的范围内。另外，对于本文中所描述的实施例中的每一者来说，任何此类实施例的对应形式可在本文中被描述为(例如)“经配置以(执行所描述的动作)的逻辑”。

[0046] 表1提供本发明中使用的术语和缩写的词汇表：

[0047]

[0048]

[0049]

[0050] 表1-术语和缩写的词汇表

[0051] 在本文中被称作用户设备(UE)的客户端装置可以是移动的或静止的，且可以与无线电接入网络(RAN)通信。如本文所使用，术语“UE”可互换地称为“接入终端”或“AT”、“无线装置”、“无线终端”、“订户装置”、“订户终端”、“订户台”、“用户终端”或“UT”、“移动终端”、“移动台”、“终端”、“装置”、“用户装置”、及其变化。通常，UE可以经由RAN与核心网络通信，且通过核心网络，UE可以与因特网等外部网络连接。当然，对于UE来说，连接到核心网络和/或因特网的其它机制也是可能的，例如经由有线接入网络、WiFi网络(例如，基于IEEE 802.11等)等等。UE可以通过多个类型的装置中的任一者来实施，所述多个类型的装置包含但不限于PC卡、压缩闪存装置、外部或内部调制解调器、无线或有线电话、智能电话、平板计算机、膝上型计算机等等。UE可借以向RAN发送信号的通信链路被称为上行链路信道(例如，反向业务信道、反向控制信道、接入信道等)。RAN可借以向UE发送信号的通信链路被称为下行链路或前向链路信道(例如，寻呼信道、控制信道、广播信道、前向业务信道等)。如本文中所使用，术语“业务信道(TCH)”可指上行链路/反向抑或下行链路/前向业务信道。

[0052] 图1A说明根据本发明实施例的无线通信系统100A的高级系统架构。无线通信系统100A含有标记为1...N的N数目个UE。UE 1…N可包含蜂窝式电话、个人数字助理(PDA)、寻呼机、膝上型计算机、桌上型计算机等等。举例来说，在图1A中，UE 1...2被说明为蜂窝式呼叫电话，UE 3...5被说明为蜂窝式触摸屏电话或智能电话，且UE N被说明为桌上型计算机或PC。

[0053] 参考图1A，UE 1...N经配置以在图1A中示出为空中接口104、106、108和/或直接有线连接102的物理通信接口或层上与接入网络(例如，RAN 120、接入点125等)通信。空中接口104和106可遵循给定的蜂窝式通信协议(例如，码分多址(CDMA)、演进数据优化(EVDO)、增强高速率包数据(eHRPD)、全球移动通信系统(GSM)、GSM演进增强数据速率(EDGE)、宽带CDMA(WCDMA)、长期演进(LTE)等)，而空中接口108可遵循无线局域网(WLAN)协议(例如，IEEE 802.11、 等)。如下文将进一步描述，RAN 120包含经由例如空中接口104和106等空中接口服务于UE的多个接入点。RAN 120中的接入点可称为接入节点(AN)、接入点(AP)、基站(BS)、节点B、演进型节点B(eNodeB)等。这些接入点可为地面接入点(或地面站)，或卫星接入点。RAN 120经配置以连接到核心网络(CN)140，其也可被称作包核心网络(PCN)或演进型包核心(EPC)，其可执行多种功能，包含在由RAN 120服务的UE与由RAN 120或不同RAN或完全不同(非RAN)网络服务的其它UE或其它非UE实体之间路由和连接电路交换(CS)
呼叫，且也可调解经由例如因特网175等外部网络与其它实体的包交换(PS)数据的交换。
RAN 120加CN 140可充当用于UE 1到N中的一或多者的服务无线网络。本文的术语无线网络与术语移动网络运营商(MNO)可互换地使用以指代无线网络以及无线网络内的基础结构
(例如，RAN 120和CN 140)。

[0054] 因特网175包含数个路由代理和处理代理(为方便起见图1A中未展示)。在图1A中，UE N展示为直接连接到因特网175(即，单独地从核心网络140，例如经由DSL或包电缆SP且其在一实例中可经由接入点125自身(例如，用于WiFi路由器))。因特网175可进而用以在UE N与接入因特网175(例如，经由核心网络140)的其它UE之间路由包交换数据通信。

[0055] 图1A中还展示与RAN 120分离的接入点125。接入点125可独立于核心网络(CN)140连接到因特网175(例如，经由例如FiOS等光学通信系统、电缆调制解调器等)。空中接口108可经由本地无线连接(例如，在一实例中为IEEE 802.11或蓝牙)而服务于UE 4或UE 5。

[0056] 参考图1A，位置服务器170展示为连接到因特网175、CN 140或这两者。位置服务器170可以实施为多个在结构上分开的服务器，或替代地可以与单一服务器相对应。如下文将更详细描述，位置服务器170经配置以支持用于可经由CN 140和/或经由因特网175连接到位置服务器170的UE的一或多个位置服务(例如，定位服务、通过参考的定位服务等)。

[0057] 图1A进一步说明过顶(OTT)服务提供者(SP)150。OTT SP可在因特网175上且可能在RAN 120和CN 140上以对因特网175、RAN 120和CN 140部分或完全地透明的方式将音频、视频和/或其它媒体内容传送到UE 1到N中的一或多者和/或从所述一或多者传送音频、视TM
频和/或其它媒体内容。OTT SP通常指代第三方提供者，例如Skype 、Hulu、Netflix、谷歌等。OTT SP 150可在因特网175、CN 140、RAN 120和/或接入点125上与UE 1...N通信。虽然图1A在中说明仅单个OTT SP 150，但显而易见，可存在连接到因特网175的任何数目的OTT SP 150，其各自对应于不同的OTT SP。OTT SP 150可具有一或多个服务器、路由代理和/或其它实体(图1A中未图示)，其可执行本文所描述的用于OTT SP 150的各种功能。同理可适用于本文稍后提到的其它OTT SP，例如OTT SP 350、450、550、650、750、850和950。

[0058] 在图1A中还说明紧急服务IP网络(ESInet)和/或选择性路由器(SR)160。ESInet 160可能够将由UE 1到N中的任一者进行且经由因特网175、CN 140或OTT SP 150接收的基于IP的紧急呼叫路由到合适的公共安全应答点(PSAP)，例如PSAP 180。类似地，SR 160可能够将由UE 1到N中的任一者进行且经由CN 140接收的电路交换(CS)紧急呼叫路由到PSAP，例如PSAP 180。在一些实施例中，UE 1到N中的任一者可发起基于IP的紧急呼叫，其可由CN 
140或由OTT SP 150变换为CS紧急呼叫且发送到SR 160(例如，经由图1A中未图示的公共交换电话网络)以用于路由到具有CS能力的PSAP 180。这可当存在SR 160但不存在ESInet 
160时和/或当PSAP 180支持CS紧急呼叫但不支持基于IP的紧急呼叫时发生。应理解，在本文稍后的经由OTT SP 150的紧急呼叫建立的描述中，紧急呼叫可作为来自UE(例如，UE 1到N中的任一者)的基于IP的紧急呼叫而发出，但可由OTT SP 150转换成CS紧急呼叫，并经由SR 160且不经由ESInet 160而路由到PSAP 180。

[0059] 图1A中的UE 1...N可能够经由因特网175进行话音、文字、视频或其它数据紧急呼叫。举例来说，UE 1...N可能够经由OTT SP 150进行此紧急呼叫，如下文中进一步描述。ESInet/SR 160可将这些话音、文字、视频和数据紧急呼叫递送到PSAP 180，其可为(例如)紧急呼叫中心。用于递送这些紧急呼叫的协议可为由因特网工程任务小组(IETF)界定的会话起始协议(SIP)。另外，可使用由3GPP界定的IP多媒体子系统(IMS)递送基于SIP的紧急呼叫，所述IMS支持SIP的使用且可由CN 140支持。

[0060] 用于RAN 120和CN 140的协议特定实施方案的实例在下文相对于图1B而提供以帮助在对RAN 120的LTE接入的支持的情况下更详细阐释无线通信系统100A。确切地说，RAN 
120和CN 140的组件对应于与支持包交换(PS)通信相关联的组件，借此传统电路交换(CS)组件也可以存在于这些网络中，但在图1B中未显式地图示。

[0061] 具体地说，图1B说明根据本发明的实施例基于支持LTE无线接入的演进包系统(EPS)的RAN 120和CN 140所述实例配置100B。在图1B的实例中，EPS/LTE网络中的RAN 120经配置有多个演进型节点B(eNodeB或eNB)122、124和126。CN 140包含多个移动性管理实体(MME)142和144、增强型服务移动定位中心(E-SMLC)172、服务网关(S-GW)146，以及包数据网络网关(PDG)148。在图1B的实例中，位置服务器170是支持LTE控制平面定位解决方案的网关移动定位中心(GMLC)或支持由开放移动联盟(OMA)界定的SUPL定位解决方案的安全用户平面位置(SUPL)定位平台(SLP)170。在一些实施例中，位置服务器170可为具有到GMLC和/或SLP的连接或者与其的关联的位置检索功能(LRF)。这些组件、RAN 120与因特网175之间的网络接口在图1B中说明且在表2中界定。

[0062]

[0063] 表2

[0064] 现将描述图1B的RAN 120和CN 140中所示的组件的高级描述。然而，这些组件中的一些是所属领域中从各种3GPP技术规范(TS)众所周知的，且本文含有的描述并不希望为这些组件执行的所有功能性的详尽描述。

[0065] 参考图1B，MME 142和144经配置以管理用于EPS承载的控制平面信令且支持接入CN 140的UE的移动性。MME功能包含：非接入层(NAS)信令、NAS信令安全性、用于技术间和技术内越区移交的移动性管理、PDG和S-GW选择，以及用于具有MME改变的越区移交的MME选择。

[0066] S-GW 146是网关，其端接于用于用户平面信令的朝向RAN 120的接口。对于附接到用于基于EPS的系统的CN 140的每一UE，在给定时间点，存在单个S-GW。用于基于代理移动IPv6(PMIP)的S5/S8的S-GW 146的功能包含：移动性锚点、包路由和转发，以及基于相关联EPS承载的QoS类标识符(QCI)设定DiffServ码点(DSCP)。

[0067] 参考图1B，PDG 148是网关，其端接于朝向包数据网络(PDN)(例如，因特网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使用RAN 120提供到GSM/EDGE无线电接入网(GERAN)/UTRAN仅具UE和LTE功能的UE两者的PDN连接性，所述RAN可为E-UTRAN、GERAN或UTRAN中的任一者。PDG 148在S5/S8接口上使用RAN 120提供到具有LTE能力的UE的PDN连接性，所述RAN包括例如图1B中所示的eNB(其称为E-UTRAN)。

[0068] 参考图1B，GMLC/SLP 170展示为连接到MME 142，连接到CN 140中的PDG 148和/或连接到因特网175。GMLC/SLP 170可为GMLC或SLP，或者可为具有到GMLC或SLP的连接或与其的关联的LRF。GMLC 170(或具有相关联或连接的GMLC的LRF 170)支持LTE控制平面定位解决方案，而SLP 170(或具有相关联或连接的SLP的LRF 170)支持SUPL定位解决方案。在GMLC/SLP 170是GMLC但不是SLP的情况下，GMLC/SLP 170可连接到MME 142且连接到PDG 
148和因特网175中的一者或两者。在GMLC/SLP 170是SLP但不是GMLC的情况下，GMLC/SLP 
170可以或可以不连接到MME 142，且可连接到PDG 148和因特网175中的一者或两者。GMLC/SLP 170可使得例如OTT SP 150、ESInet 160或PSAP 180等外部实体能够将定位请求发送到用于图1A中的UE 1到N中的任一者的GMLC/SLP 170，可在GMLC的情况下使用3GPP控制平面定位解决方案或在SLP的情况下使用SUPL协调此UE的位置确定，且可将所确定的位置返回到请求的外部实体。在图1B中说明的E-SMLC 172连接到MME 142，且是用于使用LTE控制平面定位解决方案获得UE位置估计的另一位置服务器。

[0069] 在控制平面定位解决方案中，位置服务器(例如，图1A中的位置服务器170或图1B中的GMLC/SLP 170)由其它元件(包含UE)经由网络中的现有信令接口而接入。与UE的位置相关的所有信令作为所有接口上的信令显式地输送。在LTE接入的情况下，在3GPP TS 23.271和36.305中界定控制平面定位解决方案。

[0070] 在例如SUPL解决方案等用户平面位置解决方案中，UE和例如图1B中的GMLC/SLP 170等位置服务器通过例如经由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的关联或到其的连接的LRF。连接到GMLC或与其相关联的LRF 170可类似于GMLC而支持控制平面定位，而连接到SLP或与其相关联的LRF 170可类似于SLP而支持SUPL用户平面定位。

[0071] 电信行业解决方案联盟(ATIS)在研究支持由UE经由OTT服务提供者建立的下一代9-1-1(NG911)呼叫，例如SkypeTM。一个主要问题是获得和提供911呼叫者的准确且可靠的位置以实现通过OTT SP将NG911呼叫路由到或朝向正确的PSAP，且实现通过PSAP对呼叫用户的位置的公共安全支持的调度。因为例如OTT SP 150等OTT SP将常常几乎不具有关于由呼叫UE使用的接入网络的信息，所以OTT SP可能难以利用基于陆地的定位方法(例如WiFi、增强型小区ID(E-CID)和观测到达时间差(OTDOA))来直接定位呼叫UE。此外，当呼叫UE在室内时，由OTT SP使用卫星定位系统(SPS)，例如全球定位系统(GPS)、某种其它全球导航卫星系统(GNSS)或经由辅助GPS(A-GPS)或辅助GNSS(A-GNSS)对UE的定位也可能由于在室内使用
SPS定位的固有困难和/或由于OTT SP缺乏控制和/或辅助SPS定位的使用的能力而不可靠。

[0072] 可由OTT SP 150使用以获得已经由OTT SP 150发出紧急呼叫的UE的位置的一个解决方案涉及在OTT SP 150可具备或可推断位置服务器的地址的情况下，OTT SP 150询问接入网络中的位置服务器(例如图1A中的位置服务器170或图1B中的GMLC/SLP 170)以获得呼叫UE的位置。在另一解决方案中，发出紧急呼叫的UE可将其位置直接提供到OTT SP 150(例如，在用以建立NG911呼叫的SIP邀请中)。UE将其位置直接提供到OTT SP 150可为有吸引力的解决方案，因为(a)对标准(例如，3GPP标准)的新影响可受限制，(b)对移动网络运营商(MNO)RAN和CN网络的实施方案影响可为低的或零，(c)UE通常无论如何都支持独立定位能力(例如，由UE操作系统供应商或UE芯片供应商辅助的解决方案)，以及(d)解决方案可为与现有NG911标准的良好配合，其允许UE在发送以发出紧急呼叫的SIP邀请中提供UE位置。

[0073] UE提供的位置(例如，包含在SIP邀请中)可通过值(例如，UE直接提供其纬度/经度坐标)或通过参考。对于通过参考的定位，UE提供统一资源识别符(URI)(原始由UE从位置服务器获得且在本文中被称作“位置URI”)，其含有位置服务器的名称或地址、对可由位置服务器指派的UE的唯一参考，以及用以从位置服务器获得UE位置的协议的指示。“位置URI”在本文可互换地称为“位置参考”和“通过参考的定位”。位置URI可如IETF在请求注解(RFC)3986和5808中界定，且可包括符合RFC 3986中的规则的字符串，所述规则用于对例如SIP或HTTP等方案名称或协议名称的识别以及资源的识别进行编码，所述资源可包括位置服务器的识别(例如，因特网路径名称或地址)加上UE的识别。

[0074] UE的识别，在本文中也被称作“UE参考”、“本地UE参考”或“本地参考”，可包括向位置服务器识别UE但将UE的真实身份隐藏于其它实体且可由位置服务器本地指派的字符。UE可使用例如IETF RFC 5985中界定的具有HTTP功能的位置递送(HELD)协议等位置配置协议从位置服务器请求且获得位置URI。UE可使用例如IETF RFC 6442中界定的SIP等位置传递协议将位置URI传达到另一实体，例如图1A和图1B中的OTT SP 150、ESInet 160或PSAP 180。接收UE的位置URI的实体(例如，图1A和图1B中的OTT SP 150、ESInet 160或PSAP 180)可使用例如SIP、HTTP或HELD等位置提领协议从位置服务器请求和接收UE的位置(例如，可包括纬度和经度(且可能海拔)的地理坐标或可包括邮政地址或街道地址(且可能楼层编
号、房间编号、套房编号等)的城市位置)。关于位置提领，请求位置的实体将位置URI提供到位置服务器，位置服务器从位置URI识别UE，获得UE的位置，且将所述位置返回到请求实体。

[0075] 通过参考的定位解决方案可比通过值的定位解决方案更有吸引力，因为其允许UE或位置服务器有更多时间来获得UE的位置且可用以在不同时间获得UE的多于一个位置。举例来说，通过参考的定位解决方案可由OTT SP 150使用以初始地获得近似UE位置以辅助路由，且在稍后时间获得较准确UE位置用于PSAP调度。

[0076] 通过参考的定位解决方案可具有对UE和位置服务器的显著影响，这两者可能需要支持(a)位置配置协议，例如HELD，借此UE可请求且位置服务器可提供位置URI，以及(b)用于当(a)中的询问/响应发生时位置服务器验证UE的身份的装置。可能需要(b)中的影响，因为位置服务器可能需要在指派位置URI时可靠地识别UE，以便在某个稍后时间当客户端(例如，OTT SP 150或PSAP 180)通过以位置URI询问位置服务器而请求UE的位置时定位正确的UE(例如，而不是某个其它UE)。例如HELD等一些位置配置协议可能通常不需要或支持(b)中的验证，因为提供位置URI的UE的IP地址可当(a)发生时从UE可用于位置服务器，且可视为足够可靠的以当位置URI稍后由OTT SP 150、ESInet 160或PSAP 180提领(例如，使用HELD)时在稍后时间识别和定位UE。

[0077] 然而，IP地址可能错误。举例来说，不是UE但能够拦截去往和来自UE的IP通信的实体可使用位置配置协议，通过将定位请求发送到含有用于UE的IP地址的位置服务器而获得UE的位置URI。所述实体接着可(i)伪装为OTT SP以通过将提领请求发送到含有所获得位置URI的位置服务器而获得UE的位置，或(ii)发出紧急呼叫且将位置URI提供到OTT SP 150以使得公共安全调度到UE的位置，即使UE并未做出紧急呼叫。

[0078] 另外，甚至当用于UE的IP地址正确时且当请求UE位置的实体合法时，位置服务器也可能需要用于UE的不同身份以便在稍后时间获得UE的位置和/或正确地识别UE。举例来说，如果位置服务器采用控制平面定位解决方案获得UE的位置(例如，用于LTE的3GPP控制平面定位解决方案)，那么位置服务器可能需要用于UE的无线相关联身份，例如国际移动订户编号(IMSI)或临时移动订户编号(TMSI)，而不是UE的IP地址。另外，如果定位的UE需要稍后经识别用于收费或记账目的(例如，允许用于位置服务器的SP向OTT SP 150记账)或稍后在所获得位置错误或用于统计和会计目的的情况下追随，那么可能需要UE的某种永久性全局身份而不是IP地址。为了确保位置服务器具有UE的正确身份且位置URI提供到正确UE而不是伪装为UE的实体，可能需要上文(b)中的验证影响。(a)和(b)的双重影响可使得通过参考的定位解决方案(例如，如本文上文所提及的IETF RFC所界定)对于UE供应商和MNO或其位置服务器供应商是复杂的。

[0079] 利用通过参考的定位对上文所述的问题的解决方案将是服务接入网络而不是位置服务器在UE(及其身份)已由接入网络验证之后为UE提供通过参考的定位。通过接入网络对UE的验证是对于许多类型无线网络(例如，GSM、UMTS、LTE、IEEE 802.11)所支持或可支持的无线网络操作的典型部分，且因此不会对UE或接入网络增加新影响。通过接入网络对UE提供通过参考的定位可(i)紧接在UE已成功地附接到接入网络且经验证之后发生，(ii)在UE附接到接入网络(例如，使得能够基于不同位置服务器和/或不同本地UE参考而更换前一通过参考的定位)的同时周期性地发生，和/或(iii)在UE附接到接入网络的同时按UE的请求而发生。

[0080] 在一个实施例中，接入网络可与位置服务器通信以获得UE的通过参考的定位。在此实施例中，接入网络可充当代理且代表UE从位置服务器获得通过参考的定位。UE和位置服务器随后将不需要支持位置配置协议以使UE能够从位置服务器获得位置URI。实际上，UE将从接入网络获得位置URI且接入网络将从位置服务器获得位置URI。虽然此实施例可添加新的接入网络-位置服务器接口，但其可以不需要支持位置配置协议以及UE和位置服务器两者对UE的验证，且因此可为比使用传统位置配置协议让UE直接询问位置服务器更简单的解决方案。

[0081] 在另一实施例中，接入网络可将通过参考的定位指派给UE自身而不涉及位置服务器。举例来说，接入网络(例如，MME 142)可产生位置URI，其包含目标位置服务器(例如，图1A中的位置服务器170或图1B中的GMLC/SLP 170)的已知地址或已知身份(例如，已知的因特网路径名称)、用以从客户端询问位置服务器的方案或协议，以及(作为对位置服务器的地址或身份的扩展)识别UE的UE参考。在正常位置URI中，UE参考可由产生位置URI的位置服务器本地指派。关于此处描述的实施例，UE参考可由接入网络指派且可包括全局UE识别，例如UE的IP地址、UE的IMSI和/或对接入网络已知的UE的身份，例如TMSI、由接入网络节点(例如，MME或SGSN)指派的UE的本地地址和/或接入网络节点的地址，或其任何组合。UE参考可进一步包含指派的日期和/或时间，和/或可经加密以保护用户隐私(例如，其中密码密钥对接入网络和位置服务器是已知的但对其它方不是已知的)。在UE参考包括TMSI或IP地址的情况下，可能不需要加密因为UE的真实身份(例如，UE的IMSI)未包含在UE参考中且因此不可用于其它方。位置URI也可以由接入网络以数字方式签署(例如，可包含数字签名)以使得正以位置URI询问的位置服务器可知道位置URI是由接入网络指派的。在一些情况下，位置URI可经加密且以数字方式签署，例如使用美国美国国家标准与技术研究所(NIST)计数器与密码分组链接-消息验证代码(CCM)方法。

[0082] 以上实施例的使用可仅影响接入网络和位置服务器。因此，MNO可从其中接入网络指派位置URI而不涉及位置服务器的第二实施例迁移到其中接入网络充当用于位置服务器的代理而不影响其它实体(例如，包含UE)的第一实施例。在一些情况下，MNO迁移可为从第一实施例到第二实施例。在接入网络支持LTE且属于蜂窝式MNO的情况下，用于UE的通过参考的定位可由用于UE的服务MME指派，例如图1B中的MME 142。所述指派可通过UE作为LTE网络附接的部分和/或通过UE作为跟踪区域更新的部分而发生。此指派可将含有指派位置URI的一个新参数添加到用于LTE支持的几个非接入层(NAS)消息，且可对UE和接入网络(例如，MME)两者具有小的影响。此解决方案对MNO和UE供应商的益处可在于，支持所述解决方案的影响可为有限的且可提供灵活的定位解决方案给符合现有标准的OTT SP。

[0083] 返回参看图1A和图1B，图2A说明根据本文所描述的实施例在图1A中以及在LTE接入的情况下在图1B中说明的网络实体的特定交互以提供用于OTT紧急呼叫的通过参考的定位。参考图2A，术语“接入网络”指代RAN 120和CN 140。接入网络节点240可为接入网络中的某个实体，例如接入节点、接入点、基站、eNodeB(例如，eNB 122、124或126)、毫微微小区、MME(例如，MME 142)等。接入网络节点可在RAN 120内或CN 140内。

[0084] 在202A，UE 200(例如，其可对应于图1A中的UE 1到N中的任一者)经由接入网络节点240附接到接入网络。在204A，UE 200的用户经由安装在UE 200上的OTT应用程序(例如，Skype)进行紧急呼叫。在206A，UE 200将针对位置参考的请求发送到接入网络节点240。在一些实施例中，框206A可由OTT应用程序发起，所述应用程序可在框204A处辨识紧急呼叫请求且可请求UE 200(例如，使用到UE 200上的调制解调器的应用程序编程接口(API))以获得位置参考。

[0085] 在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之间的受信任关系，例如，基于接入网络节点240和位置服务器170属于同一SP或同一网络运营商的关系，且可采用每一实体中的预配置安全凭证来实现安全连接的建立。位置服务器170接着可在框208A处指派且返回位置参考(例如，其可包含对位置服务器170为本地的UE参考)，其可稍后使用(例如，由OTT SP 
150)以从位置服务器170获得UE 200的位置，如稍后描述。

[0086] 虽然框208A添加接入网络节点240与位置服务器170之间的新接口，但其避免了位置服务器170与UE 200交互和验证所述UE的需要。在一些实施例中，接入网络节点240和位置服务器170可在208A使用SIP、HELD或由开放移动联盟(OMA)界定的移动位置协议(MLP)中的一者来请求和返回位置参考。在212A，接入网络节点240将从位置服务器170获得的位置参考发送到UE 200。在一些实施例中，UE 200(例如，UE 200上的调制解调器)可将位置参考提供到OTT应用程序。

[0087] 在一些实施例中，并非询问位置服务器170以得到UE 200的位置参考，接入网络节点240可指派位置参考自身而不涉及位置服务器170，如本文先前描述。接入网络节点240可同样如本文所描述而加密位置参考的UE参考部分和/或以数字方式签署位置参考。在此情况下，任何加密/解密密钥和/或用于数字签名的密钥对于接入网络节点240和位置服务器170两者可为已知的，但对于其它方不是已知的。

[0088] 在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的验证的消息中包含经指派位置参考。

[0089] 作为另一实例，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可包括仅用以获得位置参考的新消息。

[0090] 在一些实施例中，在212A将位置参考发送到UE 200之前，接入网络节点240可验证UE 200(在图2A中未图示)的身份。此验证可确保在212A将位置参考返回到正确UE 200。此外，UE 200的此验证可形成支持UE 200对由接入网络节点240提供的服务的接入(例如，例如用于UE 200的网络附接和移动性的支持)的正常部分，任意不会对UE 200或接入网络节点240添加额外影响以仅用于在212A返回位置参考的目的。

[0091] 在214A，UE 200将包含UE 200的位置参考的紧急呼叫请求发送到OTT SP 150。在一些实施例中，紧急呼叫请求可由UE 200经由接入网络节点240和/或经由用于接入网络节点240的接入网络传送到OTT SP 150。虽然图2A中未说明，但UE 200可从用于属于第一网络运营商(还可拥有位置服务器170)和/或符合第一无线电接入技术(RAT)的第一接入网络的接入网络节点240获得位置参考，且经由属于第二网络运营商和/或符合第二RAT的第二接入网络将含有位置参考的紧急呼叫请求发送到OTT SP 150。以此方式，位置参考可在多个接入网络、多个RAT和/或多个网络运营商之间共享和/或可对于它们有效，且可使得UE 200能够在越区切换到新RAT或新网络之后和/或当同时接入若干网络或若干RAT时使用同一位置参考。举例来说，UE 200可从属于网络运营商A的蜂窝式接入网络的基站或其它服务节点(例如，MME)获得位置参考，且将包含位置参考的紧急呼叫请求发送到属于网络运营商B的WLAN接入网络中的WiFi接入点(其中运营商A可或可不相同于运营商B)，所述接入点将把紧急呼叫请求转发到OTT SP 150。

[0092] 在216A，OTT SP 150将包含在214A中从接入网络节点240接收的位置参考的位置请求(或位置提领请求)发送到位置服务器170。OTT SP 150可从在214A处接收的位置参考的内容识别位置服务器170(例如，识别用于位置服务器170的地址或路径名称)。位置服务器170可通过以下方式检验在216A处接收的位置参考是有效的：检验所述位置参考对应于由位置服务器170先前指派的位置参考(例如，在框208A发生的情况下作为框208A的部分而指派)。举例来说，位置服务器170可检验位置参考中的UE参考是先前由位置服务器170指派以识别UE 200。替代地，如果在216A处接收的位置参考是由接入网络节点240而不是由位置服务器170指派(例如，例如在框208A不存在的情况下发生)，那么位置服务器170可通过检验位置参考中的任何数字签名(如果存在)，和/或通过解密位置参考的UE参考部分且检验经解密UE参考部分正确地符合用于有效UE参考的任何格式化或编码规则，而检验接入网络节点240指派了位置参考。

[0093] 在218A，位置服务器170(或在位置服务器170是LRF的情况下与位置服务器170相关联或连接到所述位置服务器的GMLC)可将针对UE 200的位置的定位请求发送到接入网络节点240，且在所述定位请求中可包含用于UE 200的识别，其可为(i)在208A发生且位置服务器170已指派在216A处接收的位置参考的情况下在208A处较早接收的用于UE 200的识
别，或(ii)在接入网络节点240而不是位置服务器170已经指派位置参考的情况下在216A处作为位置参考的部分接收的UE参考或经解密UE参考的部分或全部。接入网络节点240接着可从另一实体(在图2A中未图示)获得UE 200的位置估计(如在218A处由位置服务器170识
别)。举例来说，接入网络节点240可从另一位置服务器(例如，E-SMLC 172)或另一具有定位能力的实体(例如，RAN 120)或从服务于UE 200的基站或AP请求位置估计，替代地，接入网络节点240可能已经自身具有UE 200的位置信息(例如，如果接入网络节点240是服务于UE 
200的基站或WiFi AP)。接入网络节点240接着可将UE 200的位置估计返回到位置服务器
170(或在位置服务器170是LRF的情况下返回到与位置服务器170相关联或连接到所述位置服务器的GMLC)作为218A的部分。在一些实施例中，框218A可当位置服务器170采用控制平面定位解决方案获得UE 200的位置时发生。

[0094] 替代于或补充在218A处询问接入网络节点240以得到UE 200的位置，位置服务器170可在222A处直接询问UE 200。举例来说，如果位置服务器170是SUPL SLP或者连接到SLP或与SLP相关联的LRF，那么222A可发生，其中SLP在222A处向UE 200发起SUPL用户平面定位会话以便从UE 200获得位置相关测量值(例如，GPS或GNSS卫星的测量值和/或用于UE 200的接入网络中的基站和/或AP的测量值)，位置服务器170可使用所述测量值来确定UE 200的位置。举例来说，UE 200可将GPS和观测到达时间差(OTDOA)测量值提供到位置服务器
170。OTDOA是多边测量方法，其中UE 200测量来自基站对的特定信号之间的时间差且将测得的时间差报告到位置服务器170，所述位置服务器随后计算UE 200的位置。替代地，位置服务器170(或在位置服务器170是LRF的情况下与位置服务器170相关联或连接到所述位置服务器的SLP)可在222A处向UE 200发起SUPL会话以从UE 200获得UE 200的位置，其中UE 
200从例如GPS、GNSS和/或OTDOA测量值等位置相关测量值获得所述位置。在224A，位置服务器170将在218A和/或在222A获得的UE 200的位置发送到OTT SP 150。在一些实施例中，OTT SP 150和位置服务器170可在216A和224A采用SIP、HELD或MLP中的一者以请求和返回UE 
200的位置。在其中使用SIP或HELD的这些实施例中的一些实施例中，SIP或HELD的使用可经界定为位置参考的部分。

[0095] 在216A到224A的消息流可在图2A中说明的时间发生以使得OTT SP 150能够获得UE 200的位置以辅助紧急呼叫的路由(例如，通过确定具有包含UE 200的位置的紧急服务覆盖范围的PSAP 180)和/或将UE 200的位置提供到ESInet 160或PSAP 180。在216A到224A的消息流是任选的，因为如果OTT SP 150从PSAP 180接收到针对UE 200的定位请求且需要询问位置服务器170以获得和返回UE 200(在图2A中未图示)的当前位置，那么所述消息流可替代地或另外在204A处起始的紧急呼叫经设置之后(即，在228A之后)发生。另外，类似于
216A到224A的消息流可发生(替代或补充在216A到224A的消息流)以使得ESInet 160或
PSAP 180能够从位置服务器170直接请求UE 200的位置。这些类似的消息流可相同或几乎相同于216A到224A，不同的是ESInet 160或PSAP 180可在216A处发送定位请求和在224A处接收位置响应方面代替消息流中的OTT SP 150。

[0096] 返回到图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可使用在224A获得的UE 200的位置(如果已执行)以将在204A起始的紧急呼叫路由到适当ESInet 160(或SR 160)。ESInet 160可使用在紧急呼叫请求中接收的UE 200的位置参考以通过执行类似于已经描述的216A到224A的步
骤而从位置服务器170获得UE 200的位置。ESInet 160接着可使用此获得的位置将紧急呼叫路由到适当PSAP 180。

[0097] 在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的位置。

[0098] 返回参看图1B，图2B说明根据本文所描述的实施例的在图1B中说明的实体的特定交互以提供通过参考的定位以用于OTT紧急呼叫。图2B中的交互类似于针对图2A描述的那些交互，但具体来说涉及具有LTE接入的UE 200。相比之下，与图2A结合描述的交互可应用于具有任何类型的无线或有线接入的UE 200，包含但不限于LTE接入。

[0099] 在202B，UE 200附接到具有LTE能力的服务网络，且作为附接程序的部分将NAS附接请求发送到服务MME 142。在一些实施例中，NAS附接请求包含针对位置参考的请求。在204B，MME 142可任选地将位置参考请求发送到GMLC/SLP 170。GMLC/SLP 170在将使用控制平面定位解决方案获得UE 200的位置的情况下可为GMLC，在将使用SUPL获得UE 200的位置的情况下可为SLP，在控制平面定位和SUPL中的任一者或两者将用以获得UE 200的位置的情况下可为组合的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的获得位置参考的请求的部分
的需要。

[0100] 在框204B中的请求/响应可使用GMLC/SLP 170与MME 142之间的安全连接，其使得GMLC/SLP 170能够知道MME(例如，属于与GMLC/SLP 170相同的运营商或SP)正在请求位置参考。GMLC/SLP 170与MME 142之间的安全连接可利用GMLC/SLP 170与MME 142之间的受信任关系，例如基于属于同一SP或同一网络运营商的MME 142和GMLC/SLP 170的关系，且可采用每一实体中的预配置安全凭证来实现所述安全连接的建立。GMLC/SLP 170接着可指派且返回位置参考(例如，可包含对GMLC/SLP 170为本地的UE参考)，其将稍后允许GMLC/SLP 170例如在下文描述的框214B和232B将UE 200的位置提供到另一实体。在一些实施例中，MME 142和GMLC/SLP 170可在204B使用SIP、HELD或由OMA界定的移动位置协议(MLP)中的一者以请求和返回位置参考。

[0101] 在206B，MME 142在NAS附接接受消息中将从GMLC/SLP 170获得的位置参考发送到UE 200。在202B的NAS附接请求和在206B的NAS附接接受可如3GPP TS 23.401和TS 24.301中界定，其中在NAS附接请求中添加了位置参考请求参数和/或在NAS附接接受中添加了位置参考参数。在一些实施例中，可仅当在202B的NAS附接请求含有针对位置参考的请求时执行框204B和206B。在其它实施例中，可当在202B的NAS附接请求不含针对位置参考的请求时执行框204B和206B。

[0102] 替代地，并非在204B询问GMLC/SLP 170以得到UE 200的位置参考，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管理的某个实体指派。

[0103] 补充或替代于在206B获得位置参考，UE 200可在UE 200的用户起始紧急呼叫(208B)之后、在UE 200附接到MME 142的同时周期性地、和/或在UE 200与MME 142之间的某种其它交互期间获得位置参考，如上文参考图2A所论述。

[0104] 替代于发送202B处的NAS附接请求和206B处的NAS附接接受以获得位置参考，UE 200可在202B发送NAS跟踪区域更新，且在获得或指派位置参考(例如，在204B)之后，MME 
142可在206B发送含有位置参考的NAS跟踪区域更新接受。在202B的NAS跟踪区域更新请求和在206B的NAS跟踪区域更新接受可如3GPP TS 23.401和TS 24.301中界定，其中在NAS跟踪区域更新请求中添加了位置参考请求和/或在NAS跟踪区域更新接受中添加了位置参考。

[0105] 在一些实施例中，在于206B处在NAS附接接受或NAS跟踪区域更新接受中将位置参考发送到UE 200之前，MME 142可验证UE 200的身份(图2B中未图示)。此验证可确保位置参考在206B返回到正确UE 200。此外，UE 200的此验证可形成支持UE 200和MME 142的UE 200附接或UE 200跟踪区域更新的正常部分，任意不会对UE 200或MME 142增加额外影响以仅用于在206B返回位置参考的目的。

[0106] 对于支持GSM或UMTS而不是LTE的接入网络，图2B中的程序可用以如本文中所描述针对LTE网络支持OTT紧急呼叫，但其中E-SMLC 172被GSM或UMTS RAN代替且MME 142被服务GPRS支持节点(SGSN)代替。在所述情况下，UE 200将在202B将可含有针对位置参考的请求的GPRS附接请求或GPRS路由区域更新请求发送到SGSN，且SGSN将在206B分别以GPRS附接接受或GPRS路由区域更新接受进行响应。在此情况下，在202B的GPRS附接请求或GPRS路由区域更新请求和在206B的GPRS附接接受或GPRS路由区域更新接受可如3GPP TS 24.008中界定，其中在GPRS附接请求或GPRS路由区域更新请求中添加了位置参考请求和/或在GPRS附接接受或GPRS路由区域更新请求中添加了位置参考。

[0107] 在208B，UE 200的用户经由安装于UE 200上的OTT应用程序(例如SkypeTM)进行紧急呼叫。在212B，UE 200将包含在206B获得的位置参考的紧急呼叫请求发送到OTT SP 150。举例来说，UE 200可经由eNB 124、S-GW 146、PDG 148和因特网175将紧急呼叫请求发送到OTT SP 150。在实施例中，UE 200可如上文所描述从MME 142获得位置参考，且在212B经由与含有MME 142且与GMLC/SLP 170相关联的接入网络不同的接入网络将含有位置参考的紧急呼叫请求发送到OTT SP 150。举例来说，所述不同接入网络可支持与LTE不同的RAT(例如，WiFi)。以此方式，位置参考可在不同接入网络之间且可能在UE 200处的不同RAT之间共享。举例来说，UE 200可经由WLAN接入点将包含位置参考的紧急呼叫请求发送到OTT SP 
150。

[0108] 在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参考是由GMLC/SLP 170先前指派以识别UE 200。替代地，如果在214B接收的位置参考是由MME 142而不是由GMLC/SLP 170指派(例如，例如在框204B不存在的情况下发生)，GMLC/SLP 170可通过以下方式检验MME 142指派了位置参考：(i)检验位置参考中的任何数字签名(如果存
在)，(ii)解密位置参考的UE参考部分且检验经解密UE参考部分正确地符合用于有效UE参考的任何格式化或编码规则，和/或(iii)检验位置参考符合已知的格式化规则(例如，含有长度和/或特征内容符合已知规则的UE参考)。

[0109] 如果正利用控制平面定位解决方案(意味着GMLC/SLP 170是或含有GMLC或者是连接到GMLC或与GMLC相关联的LRF)，那么执行在216B到226B的消息流(如由虚线框指示)。具体地说，在216B，GMLC 170将针对UE 200的定位请求发送到MME 142。GMLC 170可从在214B接收的位置参考中的UE参考的内容确定MME 142的地址或身份以便在216B正确地发送请求(例如，如果MME 142或GMLC 170在位置参考中包含MME 142地址或身份)。替代地，GMLC 170可使用位置参考的UE参考部分中在214B接收的用于UE 200的识别符(例如，IMSI)询问用于UE 200的归属订户服务器(HSS)以得到MME 142的地址(图2B中未图示)。GMLC在216B处发送的定位请求中包含UE 200的身份，其包含在214B处接收的位置参考的UE参考部分中或者是在204B先前接收且由GMLC 170存储(在GMLC 170指派位置参考的情况下)。

[0110] 在218B，MME 142将针对UE 200的定位请求发送到E-SMLC 172，且可包含在216B接收或对MME 142已知的UE 200的任何身份。在222B，E-SMLC 172可发起与UE 200的3GPP LTE定位协议(LPP)位置会话，且作为此会话的部分可将定位请求发送到UE200，所述UE以位置信息进行响应。由UE 200提供的位置信息可包括GPS位置测量值、GNSS位置测量值、OTDOA测量值、增强型小区ID(ECID)测量值、WiFi位置测量值、蓝牙(BT)位置测量值或这些的任何组合，或可含有由UE 200获得的UE 200的位置估计。当位置信息包括位置测量值但不包括位置估计时，E-SMLC 172可从这些测量值计算UE 200的位置估计。替代于或补充222B，E-SMLC 172可将定位请求(图2B中未图示)发送到用于UE 200的服务eNB(例如，图2B中的eNB 124)以便获得位置估计或测量值，E-SMLC 172可据此确定UE 200的位置估计。在224B，E-SMLC 
172可将包含UE 200的位置的位置响应发送到MME 142。在226B，MME 142将包含在224B接收的UE 200的位置的位置响应发送到GMLC 170。

[0111] 替代地，如果正利用SUPL用户平面定位解决方案(意味着GMLC/SLP 170是或含有SLP或者是与SLP相关联或连接到SLP的LRF)，那么可能不执行在216B到226B的消息流，且改为(或可能另外)在228B在SLP 170与UE 200之间建立SUPL会话。SLP 170可经由SUPL会话
(例如，从由UE 200获得的GPS、GNSS、OTDOA、ECID、WiFi和/或BT测量值)获得UE 200的位置。
在216B到228B的消息流是以虚线说明，因为在一些实施例中，执行在216B到226B的消息流或执行在228B的消息流，但不同时执行。在232B，GMLC/SLP 170将UE 200的位置估计发送到OTT SP 150。

[0112] 在214B到232B的消息流(例如，(a)214B到226B和232B或(b)214B、228B和232B)可在图2B中说明的时间发生以使得OTT SP 150能够获得UE 200的位置以辅助紧急呼叫的路由(例如，通过确定具有包含UE 200的位置的紧急服务覆盖范围的PSAP 180)和/或将UE 
200的位置提供到ESInet 160或PSAP 180。在214B到232B的消息流可替代地或另外在OTT SP 150从PSAP 180接收到针对UE 200的定位请求且需要询问GMLC/SLP 170以获得和返回
UE 200(在图2B中未图示)的当前位置的情况下在208B处起始的紧急呼叫经设置之后(即，在236B之后)发生。另外，类似于214B到232B的消息流可发生(替代或补充在214B到232B的消息流)以使得ESInet 160或PSAP 180能够从GMLC/SLP 170直接请求UE 200的位置。这些类似的消息流可相同或几乎相同于214B到232B，不同的是ESInet 160或PSAP 180可在214B处发送定位请求和在232B处接收位置响应方面代替消息流中的OTT SP 150。

[0113] 返回到图2B中所示的紧急服务呼叫，在234B，OTT SP 150将紧急呼叫路由到适当ESInet 160，或可能在OTT SP 150需要将呼叫转换为CS紧急呼叫的情况下路由到SR160。ESInet 160(或SR 160)随后将紧急呼叫路由到适当PSAP 180。在234B发送的这些紧急呼叫请求可包含在212B获得的UE 200的位置参考。OTT SP 150可使用在232B获得的UE 200的位置(如果已执行)以将在208B起始的紧急呼叫路由到适当ESInet 160(或SR 160)。ESInet 
160可使用在紧急呼叫请求中接收的UE 200的位置参考以通过执行类似于如上文所描述的
214B到232B的框而从GMLC/SLP 170获得UE 200的位置。ESInet 160接着可使用此获得的位置将紧急呼叫路由到适当PSAP 180。

[0114] 在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的位置。

[0115] 图3说明根据本发明的至少一个方面的展示替代定位解决方案的用于经由OTT服务提供者提供紧急服务的示范性架构。图3中说明的架构包含UE 300(其可对应于UE200)、接入网络320(其可对应于RAN 120)、包核心网络340(其可对应于核心网络140)、OTT SP 
350(其可对应于OTT SP 150)、ESInet/SR 360(其可对应于ESInet/SR 160)、紧急情况位置服务器(ELS)370(其可对应于E-SMLC 172、GMLC/SLP 170或位置服务器170)、IP网络375(其可对应于因特网175)、可为用于UE 300的归属网络的归属网络385，以及PSAP 380(其可对应于PSAP 180)。

[0116] 图3展示用于将已调用紧急情况服务(例如，紧急情况话音呼叫、紧急情况文字消息会话)的UE 300的位置传送到OTT SP 350或从其传送的各种替代解决方案，标记为S1、S2、S3、S3a、S3b、S4和S5。对于每一解决方案，OTT SP可负责紧急情况服务呼叫进入紧急情况服务网络(例如，到ESInet或直接到PSAP)的调用和路由。

[0117] 对于解决方案S1，UE 300可将适合于路由(且可能调度)的位置推送到OTT SP 350。所述位置可为通过值的定位(LbyV)或通过参考的定位(LbyR)且可从位置服务器(例
如，ELS 370)获得或可在通过值的定位的情况下由UE 300单独确定。在通过参考的定位情况中，UE 300可将针对位置参考的请求发送到位置服务器，并且然后将所接收位置参考(以位置URI的形式)发送到OTT SP 350。OTT SP 350接着可通过从指派位置URI的位置服务器(例如，ELS 370)请求位置值而执行提领(例如，使用HELD)。

[0118] 关于解决方案S2，OTT SP 350可例如在SIP邀请消息中从UE 300接收到紧急情况服务呼叫调用之后询问UE 300以得到UE 300的位置。所述询问可使用服务中信令(例如，经由SIP信息消息的请求)或服务外信令(例如，经由单独数据或信令路径的请求)。UE 300可使用类似于请求的方式将位置返回到OTT SP 350，例如在所述请求使用呼叫中信令的情况下的呼叫中信令。返回的位置信息可对于解决方案S1是相同的，例如LByV或LbyR。

[0119] 关于解决方案S3，在(例如，SIP邀请中)从UE 300接收到紧急情况服务呼叫调用之后，OTT SP 350可询问例如可在接入网络320或PCN 340中或与其相关联的ELS 370。OTT SP 350可在某些情况下使用由UE 300提供到OTT SP 350的UE的IP地址或用于接入网络320或
PCN 340的识别符而确定接入网络320、PCN 340和/或ELS 370。举例来说，在IP地址的情况下，IP地址中的IP地址的已知范围或特定子字段可由OTT SP 350配置(例如，在呼叫服务器中)且映射到特定接入网络和PCN。在解决方案S3的变体S3a和S3b中，OTT SP 350可将针对UE 300的定位请求分别发送到接入网络320和PCN 340以用于向前转发到位置服务器(例
如，ELS 370)。

[0120] 关于解决方案S4，在(例如，SIP邀请中)从UE 300接收到紧急情况服务呼叫调用之后，OTT SP 350可询问用于UE 300的归属网络385中的位置服务器或位置服务。可使用全局公共身份(例如，SIP URI、MSISDN等)参考UE 300。OTT SP 350可使用全局公共身份确定归属网络385以及归属网络385中的位置服务器或位置服务。归属网络385可知道UE 300的一般位置(例如，根据从PCN 340接收的支持漫游的信息)和/或可直接定位UE 300(例如，使用SUPL)。

[0121] 关于解决方案S5，PSAP 380或ESInet/SR 360可询问OTT SP 350以得到用于路由或调度所需要的UE 300的位置。OTT SP 350可使用其它解决方案替代例(S1、S2、S3、S3a、S3b、S4)中的一者以获得UE 300的通过值的定位(例如，地理位置或城市位置)或者UE 300的通过参考的定位，且接着可将这返回到PSAP 380或ESInet/SR 360。如果返回通过参考的定位，那么PSAP 380或ESInet/SR 360将需要询问接入网络320或PCN 340中指派了通过参考的定位的位置服务器(例如，ELS 370)以获得UE 300的位置。

[0122] 先前与图1A、1B、2A和2B结合描述的通过参考的定位解决方案可结合先前针对图3描述的解决方案S1、S2和S5而采用。这些通过参考的定位解决方案可减少对例如UE 200和UE 300等UE以及对例如位置服务器170和ELS 370等位置服务器的影响以如先前描述获得位置参考。然而，所述解决方案可能不解决OTT SP 150或OTT SP 350的紧急呼叫支持的其它方面，例如将紧急呼叫路由到PSAP(例如，PSAP 180或PSAP 380)以及使得PSAP能够请求且获得可用于PSAP调度的UE 200或UE 300的位置。为了解决紧急呼叫支持的这些其它方
面，接下来描述另外的定位解决方案，其在一些方面中可不同于与图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中)且可使用控制平面定位解决方案和/或用户平面定位解决方案接入PCN 340和/或AN 320内部的位置确定能力。

[0123] 图3的解决方案S1和S2可视为彼此互补的且均可受支持。举例来说，当UE 300检测到用户正在调用紧急呼叫且在将紧急呼叫请求发送到OTT SP 350之前有时间获得一些位置信息时可使用解决方案S1。当UE 300未检测到用户正在调用紧急呼叫或在将紧急情况服务请求发送到OTT SP 350之前没有足够时间获得位置信息时可使用解决方案S2。

[0124] 图3的解决方案S1和S2的增强可能需要解决当代表由UE 300初始发送到OTT SP 350的紧急呼叫而通过服务MNO支持位置和路由时的若干问题集合。接下来描述且例示这些各种问题集合。

[0125] 问题集合1：传统PSAPS

[0126] 当传统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进行位置检索。第二问题可为OTT SP 350可能不可能将LbyV发送到传统PSAP 380作为呼叫信令的部分(例如，如果用于UE 300的紧急呼叫是通过使用MF中继来到达PSAP 380的SR 360而路由)。第三问题可为在OTT SP 350将LbyR而非LbyV提供到PSAP 380的情况下传统PSAP 380(或与传统PSAP 380相关联的ALI)可能通常不支持LbyR的提领。

[0127] 以上三个问题可意味着，当传统PSAP 380不被ESInet 360支持(例如，但仅被SR 360支持)时，仅基于LbyV或LbyR到OTT SP 350的提供的解决方案S1和S2的任何增强可能不支持可调度位置到传统PSAP 380的提供。

[0128] 问题集合2：服务MNO中的控制平面定位

[0129] 关于用于LTE或HSPA接入的3GPP控制平面定位解决方案(例如，如3GPP TS 23.271、25.305和36.305中界定)，用于进行紧急呼叫的UE 300的当前服务MME或服务SGSN的身份需要在LRF或GMLC处已知，以便将针对UE 300位置的请求路由到正确的服务MME或服务SGSN。对于通过服务MNO建立而不涉及OTT SP的紧急呼叫(例如，如ATIS-0700015中所描述)，此信息可当UE 300建立紧急情况PDN连接或紧急情况PDP上下文(例如，作为建立紧急呼叫的部分)时由服务MME或服务SGSN以及当越区移交发生时由新的或前一个MME或SGSN在LRF和GMLC(正用以支持用于紧急情况呼叫UE 300的定位)中保持更新。然而，对于通过OTT SP 350建立的紧急呼叫，服务MNO可能不知道所述紧急呼叫，且因此LRF(和GMLC)可能不关于服务MME或服务SGSN的身份保持更新。无此信息的情况下，GMLC可能不能够将定位请求路由到正确的服务MME或服务SGSN。这意味着当服务于来自OTT SP 350的用于UE 300的位置提领请求时，ELS 370(例如，LRF)可能不能够使用控制平面解决方案来获得UE 300的位置，例外的可能是当ELS 370具有足够信息来从HSS询问此信息时的归属订户的情况。

[0130] 问题集合3：服务MNO中的用户平面定位

[0131] 当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已知或由服务MNO指派的IP地址的UE接受传入位置请求，那么这可在VPN指派的IP地址包含在由OTT SP 350发送到服务MNO(例如，发送到ELS 370)的定位请求中的情况下防止服务MNO使用SUPL定位。对于IP地址是由归属网络385指派(例如，其中用于LTE接入的PDN网关在归属网络385中)的漫游UE 300可发生相似问题。然而，在此情况下，服务MNO(例如，服务MNO中的SLP)可配置有由例如归属网络385等漫游伙伴指派的IP地址(例如，地址范围)，在此情况下用户平面(例如，SUPL)定位的使用仍可为可能的。

[0132] 问题集合4：紧急呼叫到PSAP的路由

[0133] 虽然OTT SP 350可能够在用于PSAP 380的正确地址或身份已知(例如，SIP URL或电话DN)的情况下将紧急呼叫从UE 300路由到PSAP 380(例如，经由IP网络375或经由PSTN)，但一些OTT SP 350可能缺乏将UE 300的地理位置映射到服务区域包含UE 300地址的位置的PSAP 380的地址或身份中的能力。举例来说，如果OTT SP 350在与UE 300和PSAP 
380两者不同的国家中且不具有在其它国家中获得用于PSAP的路由信息的能力(例如，使用由IETF界定的LoST协议)的情况下此能力缺乏可发生。在一些情况下，即使PSAP 380地址或身份由OTT SP 350已知，OTT SP 350也不可能将用于UE 300的紧急呼叫转发到PSAP 380，原因是在PSAP 380侧的紧急呼叫入口上的限制。

[0134] 上文描述且例示的问题集合1到4可通过对先前提到的解决方案S1和S2的特定增强来解决，如接下来所描述。

[0135] 图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(其可对应于CN 140与AN 120组合或对应于PCN 340与AN 320组合)。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标准中界定。

[0136] 关于图4中针对解决方案S1所示的正常LbyR支持，UE 400将含有LbyR的紧急呼叫请求401发送到OTT SP 450。OTT SP 450随后通过将位置询问402发送到由紧急呼叫请求
401中接收的LbyR指示的ELS(例如，服务MNO 490中的LRF 448)而提领LbyR。所述ELS(图4中展示为LRF 448)获得UE 400的位置且将位置和/或路由信息返回到OTT SP 450。OTT SP 
450随后基于从LRF 448接收且含有原始所接收LByR的路由信息或位置而将紧急呼叫路由
到PSAP(消息403A中的传统PSAP 482或消息403B中的具有NENA i3能力的PSAP 480)。PSAP 
480/482接着可在稍后时间将询问404A(针对PSAP 482)或404B(针对PSAP 480)发送到ELS
(例如，LRF 448)以用于使用所接收LByR的可调度的定位。如上文针对问题集合1所论述，位置询问404A对于传统PSAP 482是不可能的，除非ESInet支持PSAP。

[0137] 上文与图4结合描述的基本LbyR解决方案可针对图3的解决方案S1和S2增强以克服上文针对问题集合2和3所述的问题。具体地说，由服务MNO 490(例如，由LRF 448)指派作为用于UE 400的LbyR的位置URI可经格式化为含有以下信息：

[0138] a)在服务MNO 490将使用用户平面定位来定位UE 400的情况下且在本地IP地址是由服务MNO 490指派给UE 400的情况下，用于UE 400的本地IP地址；

[0139] b)在服务MNO 490将使用控制平面定位来定位UE 400的情况下，服务MME(例如，MME 142)或服务SGSN的本地身份；以及

[0140] c)在服务MNO 490将使用控制平面定位来定位UE 400的情况下，UE 400的身份(例如，MSISDN、IMSI，或由服务MME或SGSN指派的本地ID)。

[0141] 以上在(a)、(b)和(c)中的信息可被包含作为LbyR的通常用作UE 400的本地参考的部分，且将允许由服务MNO 490中的AN 420或PCN而不是由例如LRF 448等ELS(例如，如先前与图1A到2B结合所描述)的LbyR指派，这可简化实施方案。此信息的格式化可对服务MNO 
490为特定的(例如，可能未标准化)。服务MNO 490中的在来自OTT SP 450的针对LbyR的提领请求(例如请求402)中接收到此位置URI且知道用于LbyR的格式化规则的ELS(例如，LRF 
448)可提取以上(a)到(c)中的信息，且使用所述信息来调用UE 400的控制平面或用户平面定位。增加的益处在于，所述ELS不需要维持用于来自UE 400的紧急呼叫或UE 400的信息，且可仅基于包含在每一此类请求中的信息而响应于每一提领请求(例如，请求402)。

[0142] 如结合图4所描述的以上增强在本文中被称作“增强型LbyR”且本文稍后使用额外的图说明，但无法解决以上问题集合2中的所有问题。举例来说，即使用于UE 400的LbyR可含有用于UE 400的当前服务MME或当前服务SGSN的身份，当UE 400切换到新服务MME或SGSN时所述信息也可能变为过时的，除非UE 400将新信息(例如，新LbyR)发送到OTT SP 450(例如，在SIP信息中)，所述OTT SP随后将此新信息转发到PSAP 480或482。

[0143] IMS支持是对图3的解决方案S1和S2的另一增强，其可用以解决上文针对问题集合1、2、3和4描述的所有问题。关于IMS支持，服务MNO可作为如接下来结合图5所描述的LRF或作为如稍后结合图6所描述的E-CSCF而提供支持。

[0144] 图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(其可对应于CN 140与AN 120组合、PCN 340与AN 320组合，或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)。i3ESInet 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中所示的各种实体是此项技术中众所周知的。

[0145] 关于图5中针对图3的解决方案S1所示的LRF支持，从UE 500到PSAP 580或PSAP 582的紧急呼叫可类似于结合图4描述的从UE 400到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 AN 520或服务MNO 590中的PCN获得)。OTT SP 550随后类似于E-CSCF(例如，用于ATIS-0700015标准)而表现且将紧急呼叫请求以SIP邀请502A的形式转发到LRF 548，所述LRF类似于针对用于M1接口的ATIS-00700015中的LRF所描述而获得位置和路由信息。LRF 548随后以SIP 300多重选择502B(例如，如ATIS-0700015中在M1接口上发生)的形式将位置和路由信息返回到OTT SP 550。OTT SP 550随后使用路由信息且含有在响应502B中接收的位置信息将紧急呼叫请求路由到PSAP(请求503A中的传统PSAP 582或请求503B中的具有NENA i3能力的PSAP 
580)。在响应502B中接收的位置信息可含有LbyV、LbyR、ESRK或ESRD加上MSISDN，且可对应于ATIS-0700015中界定的参考识别符。对于最后三个替代方案(即，LbyR、ESRK或ESRD加上MSISDN)，PSAP 580/582将通常在稍后时间发送询问504A(对于PSAP 582)或询问504B(对于PSAP 580)到LRF 548以用于UE 500的可调度的定位。

[0146] 图5展示从UE 500到OTT SP 550的初始紧急呼叫请求消息(例如，SIP邀请)501的路径和方向、到LRF 548(用于转发的SIP邀请502A)且回到OTT SP 550(用于SIP 300多重选择502B)的路径，以及从OTT SP 550到PSAP 580/582的用于转发的紧急呼叫请求503A和
503B的路径和方向。因特网575可用以将初始呼叫请求501从服务MNO 590传达到OTT SP 
550且将转发的呼叫请求503B从OTT SP 550传达到ESInet 560，而PSTN 585可用以将CS呼叫请求503A从OTT SP 550传达到SR 563而到达传统PSAP 582。图5还展示分别由传统PSAP 
582或NENA i3 PSAP 580发送到LRF 548的针对UE 500的定位请求504A或504B的路径和方
向。

[0147] 图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(其可对应于CN 140与AN 120组合、PCN 340与AN 320组合、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)。i3ESInet 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中所示的各种实体是此项技术中众所周知的。

[0148] 关于图6中针对图3的解决方案S1所示的E-CSCF支持，OTT SP 650在从UE 600发送的紧急呼叫请求601中接收服务MNO 690中的E-CSCF 643的地址(UE 600可例如在网络附接上从服务MNO AN 620或服务MNO 690中的PCN获得)。OTT SP 650随后类似于S-CSCF而表现且使用标准SIP邀请602将紧急服务请求转发到E-CSCF 643，在已将请求603A发送到LRF 648以获得执行转发所需要的响应603B中的任何路由和位置信息之后，所述E-CSCF随后将呼叫请求604A或604B分别转发到PSAP 680或682。图6中例示的E-CSCF支持可改善向PSAP 
680/682的成功呼叫(或服务)传送的可能性，其代价是服务MNO 690的较多涉及。

[0149] 类似于图5，图6展示从UE 600到OTT SP 650的初始紧急呼叫请求消息(例如，SIP邀请)601的路径和方向、到E-CSCF 643的转发呼叫请求602的路径，以及转发的呼叫请求604A或604B分别到PSAP 680或682的路径和方向，其中位置和路由辅助由E-CSCF 643在请求603A中请求且由LRF 648在响应603B中返回。到LRF 648的请求603A和来自LRF 648的响应603B可如ATIS-0700015中的解决方案界定，例如其中请求603A包括SIP邀请且响应603B包括SIP 300多重选择消息。图6还展示由传统PSAP 682或NENA i3 PSAP 680分别发送到
LRF 648的针对UE 600的定位请求605A或605B的路径和方向。

[0150] 与由3GPP界定(例如，3GPP TS 23.167中)和ATIS-0700015中的IMS紧急呼叫解决方案相比，分别与图5和6结合描述的LRF 648和E-CSCF 643解决方案两者可能需要对LRF和RDF以及对图6的用于E-CSCF解决方案的E-CSCF的一些改变，但也可再利用来自这些标准解决方案的现有功能性。

[0151] 对于上文参考图5和6描述的每一解决方案，UE(例如，UE 500或600)将为OTT SP(例如，OTT SP 550或650)提供某些信息以：(i)实现从OTT SP到服务MNO中的正确实体(LRF或E-CSCF)的紧急呼叫路由，以及(ii)使得OTT SP能够提供足够信息到服务MNO以实现或辅助服务MNO获得UE位置且支持呼叫路由。由UE提供到OTT SP的一些信息可来自通常已知为UE的事物，而其它信息可能已在UE附接时、在向新MME或SGSN的越区移交上和/或每当对新MME或SGSN发生跟踪区域或路由区域更新时，由AN(例如，AN 520或620)或由服务MNO(例如，MNO 590或690)中的PCN提供到UE。在针对UE的紧急呼叫请求中可由UE提供到OTT SP的信息在表3中展示(列1)，以及每一信息项目的可能来源(列2)、对用于UE的用户平面(UP)或控制平面(CP)定位的适用性(列3)，以及当UE与OTT SP之间使用SIP时可用以将每一项目传送到OTT SP(且因此传送到服务MNO)的可能的SIP标头(列4)。

[0152]信息项目 来源 CP或UP适用性 可能的SIP标头
本地UE IP地址 UE或MNO UP 联系标头
全局UE地址 UE或MNO CP和UP 来自标头
LRF或E-CSCF地址 MNO CP和UP 路由标头
服务MME/SGSN ID MNO CP 联系标头
服务MME或SGSN中的本地UE参考 MNO CP 联系标头

[0153] 表3

[0154] 服务MNO 590或690中的LRF 548或E-CSCF 643可能分别与图5或图6中的解决方案结合在分别从OTT SP 550或650接收到初始SIP邀请502A或602之后需要维持状态信息，以在E-CSCF 643的情况下维持呼叫或在LRF 548的情况下响应于来自PSAP 580/582或ESInet 
560的任何后续定位请求。在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信息更新而可为可能的。UE 500或600可使用SIP信息(例如，当OTT SP使用SIP时)或使用某种专有OTT SP消息，分别保持OTT SP 550或650以任何新服务MME或SGSN身份进行更新。

[0155] 图5和6中说明的两个解决方案可将表3中所示的相同信息从UE 500或UE 600分别传送到OTT SP 550或OTT SP 650，不同之处是分别由UE 500或600提供到OTT SP 550或650的服务MNO中的地址可为用于图5的LRF解决方案的LRF 548的地址以及用于图6的E-CSCF解决方案的E-CSCF 643的地址。分别从UE 500或600到OTT SP 550或650的此几乎相同的信息传送可允许支持两个解决方案(对于图5和6)作为UE 500和600以及OTT SP 550和650的共
同解决方案的部分，这可允许服务MNO 590或690决定使用所述两个解决方案中的哪一者，且可支持从一个解决方案到另一解决方案的迁移而不影响UE 500和600以及OTT SP 550和
650的支持。所描述的图接下来更详细例示图5的基于LRF的解决方案和图6的基于E-CSCF的解决方案。

[0156] 图7说明根据本发明的至少一个方面的用于通过值的定位以及增强型通过参考的定位支持的示范性消息流。在图7中说明的消息流可在图3和4中说明的架构中执行且可对应于且扩展与图4结合描述的用于对通过参考的定位的支持的交互。图7中的消息流也可以或实际上在图1A和1B中说明的架构中执行，且可补充和扩展与图2A和2B结合描述的用于对通过参考的定位的支持的交互。因此，图7中的UE 700可对应于图1A中的UE 1到N、UE 200、UE 300或UE 400中的任一者。类似地，OTT SP 750可对应于OTT SP 150、OTT SP 350或OTT SP 450。类似地，AN/PCN 792可对应于AN 420加上MNO 490的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。

[0157] 图7中所示的呼叫流程可直接应用于图3中的解决方案S1，例如可提供支持解决方案S1所需要的交互的更多细节。对应于图3中的解决方案S2的呼叫流程可几乎与图7中所示的呼叫流程相同，不同之处是在706的紧急呼叫请求将不运载LbyV或LbyR(如下针对图7所述)且OTT SP 750将在706之后询问UE 700以得到LbyV或LbyR。另外，关于图3中的解决方案S2，UE 700可以在706不检测用户已发起紧急呼叫(例如，可不辨识用户拨打了例如“911”等紧急号码)，且可在706发送正常呼叫请求到OTT SP 750而不是紧急呼叫请求。OTT SP 750接着可辨识在706发送的呼叫请求是针对紧急呼叫(例如，可辨识拨打的数位是用于例如“911”等紧急号码)且可在继续708之前从UE 700请求LbyR或LbyV。当使用图3的解决方案S2时，图7中所示的其它操作接着可如下所述发生。

[0158] 图7中所示的交互应用于在UE 700正在接入服务MNO 790(例如，正在经由服务MNO 790接入OTT SP 750)的环境中经由OTT SP 750发起紧急呼叫的UE 700。在图7中的702，如果UE 700将使用LbyR支持紧急呼叫，那么UE 700可从服务AN或PCN 792请求LbyR。举例来说，这可当UE 700检测到用户在发起紧急呼叫时发生，或者可当UE 700附接到服务MNO 790或出于某种其它原因(例如，为了支持UE 700移动性)而接入服务MNO时发生。

[0159] 在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中未图示)。

[0160] 在706，响应于UE 700检测到UE 700的用户已发起紧急呼叫(例如，如果UE 700检测到用户已拨打数位“911”)，UE 700将紧急呼叫请求发送到OTT SP 750且包含在704处获得的LbyV或LByR。所述紧急呼叫请求可为SIP邀请或可为用于对OTT SP 750特定的某种其它协议的消息。框706可对应于图2A中的框214A、图2B中的框212B或图4中的紧急呼叫请求401的发送。

[0161] 在708，如果在706接收到LbyR，那么OTT SP 750通过将定位请求(例如，在LByR中参考HELD的情况下根据HELD协议格式化的定位请求)发送到ELS 794而提领LbyR且在所述请求中包含LbyR。OTT SP 750可从在706接收的LbyR中的信息确定ELS 794(例如，确定用于ELS 794的地址、FQDN或URL)。框708可对应于图2A中的框216A、图2B中的框214B或图4中的位置询问402的发送。

[0162] 在710，ELS 794使用在708接收的LbyR中包含的信息(例如，本地或全局UE身份以及用于控制平面定位的服务MME/SGSN ID或用于用户平面定位的本地UE IP地址)以获得UE 700的当前位置，例如使用控制平面或用户平面定位解决方案。框710可对应于图2A中的框
218A和/或222A或者对应于图2B中的框216B到226B或框228B。

[0163] 在712，ELS 794将当前UE 700位置返回到OTT SP 750和/或返回从UE 700位置确定的用于UE 700的路由信息。框712可对应于图2A中的框224A或图2B中的框232B。块708到
712展示为任选的，且在OTT SP 750在706接收到LbyV的情况下可以不执行。

[0164] 在712之后，如果在712仅返回UE 700的位置，那么OTT SP 750使用所述UE位置(例如，使用图7中未图示的LoST询问)确定目的地PSAP。否则，OTT SP 750可使用在712返回的任何路由信息以确定PSAP。当OTT SP 750确定传统PSAP 782时，OTT SP 750可通过将ISUP IAM消息发送到用于PSAP 782的SR 763而使用CS转发呼叫。

[0165] 在716A，SR 763将呼叫转发到传统PSAP 782。

[0166] 在718A，执行呼叫建立的其余部分。随后不执行框714B、716B和718B。

[0167] 当在712之后OTT SP 750确定i3 PSAP 780而不是传统PSAP 782时，不执行框714A、716A和718A。实际上，OTT SP 750通过发送含有在706接收的LbyV或LbyR且在712发生的情况下可能含有在712接收的UE 700的任何位置的SIP邀请而将呼叫转发到ESInet 760。

[0168] 在714B之后且在716B之前，如果在714B提供LbyR，那么ESInet 760可询问ELS 794以得到UE 700的当前位置以帮助路由(图7中未图示)。ESInet 760随后在716B将呼叫转发到i3 PSAP 780。

[0169] 在718B，执行呼叫建立的其余部分。框714A和716A以及框714B和716B可对应于图2A中的框226A、图2B中的框234B或图4中分别消息403A和403B的发送。框718A和框718B可各自对应于图2A中的框228A或图2B中的框236B。

[0170] 在720，如果在716B接收到用于UE 700的LbyR，那么i3 PSAP 780通过将定位请求发送到LbyR中指示的ELS 794且在所述请求中包含LbyR而提领LbyR。框720可对应于图4中的询问404B的发送。

[0171] 在722，ELS 794使用在720接收的LbyR中包含的信息(例如，UE 700的本地或全局身份以及用于控制平面定位的服务MME/SGSN ID或用于用户平面定位的本地UE IP地址)以获得UE 700的当前位置，例如使用控制平面或用户平面定位解决方案。在确定UE 700的位置方面，框722可类似于或相同于图2A中的框218A和/或222A或者图2B中的框216B到226B或框228B。

[0172] 在724，ELS 794将UE 700的当前位置返回到i3 PSAP 780。框720和724可对应于图2A中的框232A或图2B中的框238B。

[0173] 图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中的任一者。类似地，OTT SP 850可对应于OTT SP 150、OTT SP 350或OTT SP 550。类似地，AN/PCN 892可对应于AN 520加上MNO 590的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。

[0174] 图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中的任一者。
类似地，OTT SP 950可对应于OTT SP 150、OTT SP 350或OTT SP 650。类似地，AN/PCN 992可对应于AN 620加上MNO 690的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。

[0175] 图8和9中说明的呼叫流程是相似的，且从IMS 894/994之外的实体(例如，UE 800/900和OTT SP 850/950)的角度可视为单个共同解决方案的部分。虽然IMS 894/994在图8和
9中的呼叫流程中不同地表现，但两个呼叫流程中IMS 894/994与OTT SP 850/950之间的交互可符合SIP的IETF定义(例如，IETF RFC 3261中)且因此均可由充当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规则而反应。这可使得服务MNO 890/990能够从IMS LRF支持迁移到IMS E-CSCF支持或反之亦然，而不需要改变为从UE 800/900或从OTT SP 850/950的支持。
这还可使得OTT 850/950能够根据图8从一或多个MNO(例如，MNO 890)接收IMS LRF支持且根据图9从一或多个其它MNO(例如，MNO 990)接收IMS E-CSCF支持，以用于可能由从这些MNO中的一者接入OTT SP 850/950的不同UE(例如，UE 800和UE 900)发起的紧急呼叫。

[0176] 图8和9中的呼叫流程适用于图3中的解决方案S1。对于图3中的解决方案S2，呼叫流程可几乎相同，不同之处在于下文在每一呼叫流程中在806/906描述的紧急呼叫请求将不包含UE数据和/或MNO数据中的一些或全部。实际上，OTT SP 850/950将在806/906之后询问UE 800/900以得到UE数据和/或MNO数据(例如，通过将含有请求的SIP信息发送到UE 800/900且UE 800/900在SIP OK中或SIP信息中返回所请求UE数据和/或MNO数据)。对于解决方案S2，OTT SP 850/950还可能需要询问UE 800/900以得到UE 800/900在图8中的826和图9中的920发送的经更新MNO数据。然而，此请求可与在806/906之后初始地发送到UE 800/
900的针对UE数据和MNO数据的请求(上文所提及)隐式地或显式地组合。

[0177] 另外，关于图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数据。图8和9中的未像刚才针对图3的解决方案S2描述那样修改的其它操作可如下所述发生。

[0178] 图8中所示的交互可应用于在UE 800正在接入服务MNO 890(例如，正在经由服务MNO 890接入OTT SP 850)的环境中经由OTT SP 850发起紧急呼叫的UE 800。在图8中的
802，UE 800可从服务MNO 890中的AN或PCN 892请求数据以支持使用OTT SP 850的紧急呼叫。举例来说，这可当UE 800检测到用户正在发起紧急呼叫时发生。框802是任选的且可能并不始终发生。

[0179] 在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的地址)，(ii)如果可使用控制平面定位，则用于UE 800的当前服务MME或当前服务SGSN的身份，(iii)如果可使用用户平面定位，则用于UE 800的MNO指派IP地址，和/或(iv)由用于UE 800的服务MME或服务SGSN指派的UE 800的全局身份(例如，IMSI或MSISDN)或UE 800的本地身份。

[0180] 在806，响应于UE 800检测到UE 800的用户已发起紧急呼叫(例如，如果UE 800检测到用户已拨打数位“911”)，UE 800将紧急呼叫请求发送到OTT SP 850，且包含在804获得的MNO数据以及对UE 800已知的可能额外UE数据。UE数据可包含UE 800的全局身份(例如，IMSI或MSISDN)以及UE 800的可能MNO指派IP地址(如果在804未接收到)。在806的紧急呼叫请求可为SIP邀请或可为用于对OTT SP 850特定的某种其它协议的消息。框806可对应于图5中的紧急呼叫请求501的发送。

[0181] 在808，基于在806接收到服务MNO 890中的IMS地址(例如，其中IMS地址可为在806接收的MNO数据的部分且可为在806发送的SIP邀请的路由标头中包含的LRF地址)，OTT SP 850将SIP邀请发送到由服务MNO 890中的IMS地址指示的IMS 894(例如，发送到IMS 894中的LRF)。所述SIP邀请包含在806接收的MNO数据和任何UE数据，指示紧急呼叫且包含OTT SP 
850的身份以及可能位置(例如，国家)。SIP邀请可为在806接收的任何SIP邀请的部分或完整复制。框808可对应于图5中的SIP邀请502A的发送。

[0182] 在一些情况下，在808发送的SIP邀请可首先在用于安全性的服务MNO IMS 894中的边界控制功能(例如，IBCF)处接收，然后转发到IMS 894中的LRF(图8中未图示)。IMS 894(例如，IMS 894中的LRF或IBCF)可首先基于服务MNO 890与OTT SP 850之间的某种商业关系例如使用预配置数据且可能使用OTT SP 850与服务MNO IMS 894之间的安全IP连接以在
808传送SIP邀请，检验在808发送的SIP邀请来自有效的OTT SP。在一些情况下，在810，IMS 
894(例如，IMS 894中的LRF)例如使用控制平面或用户平面定位解决方案，使用在808发送的MNO数据和任何UE数据来获得UE 800的位置。在一些其它情况中，框810不发生，且IMS 
894可从在808的SIP邀请中接收的其它数据确定UE 800的位置(例如，近似位置)，所述其它数据例如在806发送的紧急呼叫请求中由UE 800包含且在808由OTT SP 850传送到IMS 894的LbyV。

[0183] IMS 894(例如，IMS 894中的RDF)随后确定目的地PSAP 880/882，或朝向对应于UE 800的位置的目的地PSAP 880/882路由，且导出路由URI(其也可以称为路由URI)以实现从OTT SP 850到或朝向目的地PSAP 880/882的呼叫路由。所述路由URI可包含PSAP 880/882或中间目的地863(例如，在传统PSAP 882或到用于具有i3能力的PSAP 880的ESInet 860的入口点的情况下为SR)的地址或身份，且可取决于OTT SP 850身份和/或OTT SP 850位置
(例如，所述位置是否与服务MNO 890在同一国家中或在不同国家中)。IMS 894(例如，IMS 
894中的LRF)也在稍后时间确定参考识别符(ID)以实现从ESInet 860或从PSAP 880/882的针对UE 800的后续定位请求。参考ID可为(i)ESRK，或(ii)在传统PSAP 882的情况下为ESRD加上MSISDN，或可为(iii)在具有i3能力的PSAP 880的情况下为位置URI。

[0184] 在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的发送。

[0185] 在814，如果IMS 894(例如，IMS 894中的LRF)可能需要使用控制平面定位，那么IMS 894将SIP预订消息发送到OTT SP 850以预订MNO数据中的改变的通知(例如，服务MME或服务SGSN地址的改变)。IMS 894还可将单独的SIP预订消息发送到OTT SP 850以预订呼叫终止的通知(图8中未图示)。

[0186] 在816，如果814发生，那么OTT SP 850将200OK消息(图8中未图示)返回到894，并且然后在814对MNO数据的预订的情况下返回携载当前MNO数据的每一所接收预订消息的通知消息和/或在对呼叫终止的预订的情况下返回当前呼叫状态。

[0187] 在812之后(且在816发生的情况下可能在816之后)，OTT SP 850根据在812返回的路由URI或参考ID的内容确定目的地PSAP是否为传统PSAP 882或具有i3能力的PSAP 880。在传统PSAP 882的情况下，OTT SP 850可将使用CS的呼叫转发到或朝向PSAP 882。在一个实施例中，OTT SP 850在818A将ISUP IAM消息发送到在812接收的路由URI中指示的中间CS目的地863(例如，SR)。OTT SP 850还在ISUP IAM中包含在812接收的参考ID中的任何ESRK或ESRD加上MSISDN。框818A可对应于图5中的请求503A的发送。

[0188] 在820A，中间CS目的地863将呼叫转发到传统PSAP 882且包含在818A接收的ESRK或ESRD加上MSISDN。

[0189] 在822A，执行呼叫建立的其余部分。随后不执行框818B、820B和822B。

[0190] 当OTT SP 850在812之后确定i3 PSAP 880而不是传统PSAP 882时，不执行框818A、820A和822A。实际上，OTT SP 850将呼叫转发到或朝向PSAP 880。在一个实施例中，OTT SP 850通过发送含有在812的参考ID中接收的位置URI的SIP邀请而在818B将呼叫转发到由在812接收的路由URI指示的ESInet 860。框818B可对应于图5中的请求503B的发送。

[0191] 在820B，ESInet 860将呼叫转发到i3 PSAP 880且包含在818B接收的位置URI。

[0192] 在822B，执行呼叫建立的其余部分。

[0193] 在824，如果MNO数据中存在改变(例如，UE 800越区移交到新SGSN或MME)且如果服务MNO 890可使用控制平面定位用于UE 800，那么AN或PCN 892将新MNO数据发送到UE 800(例如，用于UE 800的新服务MME或SGSN的身份以及新服务MME或SGSN中的UE 800的新本地身份)。在824的新MNO数据的发送可每当MNO数据改变时为自动的(例如，服务MNO 890中的AN或PCN 892不知道经由OTT SP 850用于UE 800的紧急呼叫在进行中)，或可通过UE 800在802先前发送针对MNO数据的请求而触发。

[0194] 在826，UE 800例如当UE 800与OTT SP 850之间使用SIP时，使用SIP信息消息将新MNO数据转发到OTT SP 850。

[0195] 在828，如果IMS 894在814预订MNO数据中的改变的通知，那么OTT SP 850在SIP通知消息中将新MNO数据发送到IMS 894(例如，IMS 894中的LRF)。存储新MNO数据用于IMS 894的未来使用。举例来说，可稍后在框832A或框832B处使用新MNO数据以帮助获得UE 800的位置。

[0196] 在830A，在传统PSAP 882的情况下，PSAP 882或例如ALI等与PSAP 882相关联的实体(例如，ALI 561)可将E2接口ESPOSREQ消息(例如，如TIA/ATIS联合标准J-STD-036中界定)发送到由在820A接收的ESRK或ESRD指示的IMS 894(例如，LRF)以请求UE 800的位置且包含在820A接收的ESRK或ESRD加上MSISDN。框830A可对应于图5中的询问504A的发送。

[0197] 在832A，IMS 894(例如，LRF)使用在830A接收的ESRK或MSISDN以识别UE 800，且使用在808接收的任何UE数据和/或在808或828(如果828发生)接收的MNO数据以使用控制平面或用户平面定位解决方案获得UE 800的位置。

[0198] 在834A，IMS 894(例如，LRF)将所述位置返回到PSAP 882(或与PSAP 882相关联的实体，例如ALI)。

[0199] 在830B，在具有i3能力的PSAP 880的情况下，i3 PSAP 880通过将定位请求发送到位置URI中指示且携载位置URI的IMS 894(例如，IMS 894中的LRF)而提领在820B接收的位置URI。框830B可对应于图5中的询问504B的发送。

[0200] 在832B，IMS 894(例如，LRF)使用在830B接收的位置URI以识别UE 800，且使用在808接收的任何UE数据和/或在808或828(如果828发生)接收的MNO数据以使用控制平面或
用户平面定位解决方案获得UE 800的位置。

[0201] 在834B，IMS 894(例如，LRF)将所述位置返回到PSAP 880。

[0202] 类似于或相同于830B、832B和834B的框可在818B之后发生以使得ESInet 860能够从IMS 894(例如，从IMS 894中的LRF)获得UE 800的位置，并且基于所述位置在820B将紧急呼叫路由到正确的PSAP 880。在所述情况下，ESInet 860(例如，ESInet 860中的ESRP，例如ESRP 566)可在类似于或相同于830B的框中将针对UE 800的定位请求发送到IMS 894，且可在类似于或相同于834B的框中从IMS 894接收UE 800的位置。

[0203] 图9中所示的交互可应用于在UE 900正在接入服务MNO 990(例如，正在经由服务MNO 990接入OTT SP 950)的环境中经由OTT SP 950发起紧急呼叫的UE 900。在图9中的
902，UE 900可从服务MNO 990中的AN或PCN 992请求数据以支持使用OTT SP 950的紧急呼叫。举例来说，这可当UE 900检测到用户正在发起紧急呼叫时发生。操作902是任选的且不会始终发生。

[0204] 在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的地址)，(ii)如果可使用控制平面定位，则用于UE 900的当前服务MME或当前服务SGSN的身份，(iii)如果可使用用户平面定位，则用于UE 900的MNO指派IP地址，和/或(iv)由用于UE 900的服务MME或SGSN指派的UE 900的全局身份(例
如，IMSI或MSISDN)或UE 900的本地身份。

[0205] 在906，响应于UE 900检测到UE 900的用户已发起紧急呼叫(例如，如果UE 900检测到用户已拨打数位“911”)，UE 900将紧急呼叫请求发送到OTT SP 950，且包含在904获得的MNO数据以及对UE 900已知的可能额外UE数据。UE数据可包含UE 900的全局身份(例如，IMSI或MSISDN)以及UE 900的可能MNO指派IP地址(如果在904未接收到)。在906的紧急呼叫请求可为SIP邀请或可为用于对OTT SP 950特定的某种其它协议的消息。框906可对应于图6中的紧急呼叫请求601的发送。

[0206] 在908，基于接收到IMS地址作为在906接收的MNO数据的部分(例如，其中IMS地址是在906接收的SIP邀请的路由标头中的E-CSCF地址)，OTT SP 950将SIP邀请发送到由服务MNO 990中的IMS地址指示的IMS 994(例如，发送到IMS 994中的E-CSCF)。在980发送的SIP邀请包含指示紧急呼叫的在906接收的MNO数据和任何UE数据，且包含OTT SP 950的身份以及可能位置(例如，国家)。在908发送的SIP邀请可为在906接收的任何SIP邀请的部分或完整复制。框908可对应于图6中的SIP邀请602的发送。

[0207] 在一些情况下，在908发送的SIP邀请可首先在用于安全性的服务MNO IMS 994中的边界控制功能(例如，IBCF)处接收，然后转发到IMS 994中的E-CSCF(图9中未图示)。IMS 
994(例如，IMS 994中的E-CSCF或IBCF)可例如基于服务MNO 990与OTT SP 950之间的某种商业关系使用预配置的数据，且可能使用OTT SP 950与服务MNO IMS 994之间的安全IP连接以在908传送SIP邀请，来检验在908发送的SIP邀请来自有效的OTT SP 950。在某些情况下在910，IMS 994(例如，IMS 994中的LRF)可使用在908接收的MNO数据和任何UE数据以例如使用控制平面或用户平面定位解决方案获得UE900的位置。在一些其它情况中，框910不发生，且IMS 994可根据在908的SIP邀请中接收的其它数据确定UE 900的位置(例如，近似位置)，所述其它数据例如在906发送的紧急呼叫请求中由UE 900包含且在908由OTT SP 
950传送到IMS 994的LbyV。

[0208] 在可跟随908或910(如果910发生)的911，IMS 994(例如，IMS 994中的RDF)确定对应于UE 900位置(例如，如在910获得)的目的地PSAP 980/982，或朝向目的地PSAP 980/982路由，且确定路由URI(也被称作路由URI)以实现从IMS 994到或朝向目的地PSAP 980/982的呼叫路由。路由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)确定参考识别符(ID)以在稍后时间实现从ESInet 960或PSAP 980/982的针对UE 900的后续定位请求。参考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的内容)。

[0209] 在一些实施方案中，当910发生时在910的UE 900的定位以及在911的目的地PSAP或朝向目的地PSAP的路由的确定(包含在911确定路由URI和参考ID)可由IMS 994(例如，如果IMS 994对应于图6中的IMS 640)中的LRF(例如，LRF 648)执行，可能由RDF(例如，RDF 
646)辅助。在这些实施方案中，在908发送的SIP邀请可由IMS 994中的E-CSCF(例如，E-CSCF 
643)接收，并且然后由E-CSCF转发到IMS 994中的LRF(例如，LRF 648)。IMS 994中的LRF(例如，LRF 648)接着可在910(如果910发生)获得UE 900的位置，在911确定目的地PSAP，包含确定路由URI和参考ID，且在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。

[0210] 在911确定传统PSAP 982的情况下，IMS 994(例如，IMS 994中的MGCF)可在912A将使用CS的呼叫转发到或朝向PSAP 982。在一个实施例中，IMS 994在912A将ISUP IAM消息发送到在908或910(如果910发生)之后确定的路由URI中指示的SR 963。IMS 994还在ISUP IAM中包含在911确定的参考ID中指示的任何ESRK或ESRD加上MSISDN。

[0211] 在914A，SR 963将呼叫转发到传统982且包含在912A接收的ESRK或ESRD加上MSISDN。

[0212] 在916A，在UE 900、OTT SP 950、IMS 994、SR 963与传统PSAP 982之间执行呼叫建立的其余部分。随后不执行框912B、914B和916B。

[0213] 当IMS 994在911确定i3 PSAP 980而不是传统PSAP 982时，不执行框912A、914A和916A。实际上，在912B，IMS 994(例如，IMS 994中的E-CSCF)将紧急呼叫转发到或朝向PSAP 
980。在一个实施例中，IMS 994通过发送含有来自在911确定的参考ID的位置URI的SIP邀请而将紧急呼叫转发到由在911确定的路由URI指示的ESInet 960。

[0214] 在914B，ESInet 960将紧急呼叫转发到i3 PSAP 980且包含在912B接收的位置URI。

[0215] 在916B，在UE 900、OTT SP 950、IMS 994、ESInet 960与i3 PSAP 980之间执行呼叫建立的其余部分。

[0216] 在918，如果MNO数据中存在改变(例如，UE 900越区移交到服务MNO 990中的新SGSN或MME)且如果服务MNO 990可使用控制平面定位用于UE 900，那么AN或PCN 992将新
MNO数据提供到UE 900(例如，用于UE 900的新服务MME或新服务SGSN的身份以及新服务MME或SGSN中的UE 900的本地身份)。此新MNO数据的发送可每当MNO数据改变时为自动的(例
如，服务MNO 990中的AN或PCN 992不知道经由OTT SP 950用于UE 900的紧急呼叫在进行
中)，或可通过UE 900在902先前发送请求而触发。

[0217] 在920，UE 900例如当UE 900与OTT SP 950之间使用SIP时使用SIP信息消息将新MNO数据转发到OTT SP 950。

[0218] 在922，OTT SP 950例如使用SIP信息消息将新MNO数据转发到IMS 994(例如，转发到IMS 994中的E-CSCF)。存储MNO数据用于IMS 994(例如，由IMS 994中的LRF)的未来使用。

[0219] 在924A，在传统PSAP 982的情况下，PSAP 982或与PSAP 982相关联的实体(例如，例如ALI 661等ALI)可将E2接口ESPOSREQ消息(例如，如TIA/ATIS标准J-STD-036中界定)发送到如由在914A接收的ESRK或ESRD指示的IMS 994(例如，IMS 994中的LRF)以请求UE 900的位置且包含在914A接收的ESRK或ESRD加上MSISDN。框924A可对应于图6中的定位请求605A的发送。

[0220] 在926A，IMS 994(例如，IMS 994中的LRF)使用在924A接收的ESRK或MSISDN以识别UE 900，且使用在908接收的任何UE数据和/或在908或922(如果922发生)接收的MNO数据以使用控制平面或用户平面定位解决方案获得UE 900的位置。

[0221] 在928A，IMS 994(例如，IMS 994中的LRF)将UE 900的位置返回到传统PSAP 982(或返回到与PSAP 982相关联的实体，例如ALI)。

[0222] 在924B，在具有i3能力的PSAP 980的情况下，i3 PSAP 980通过将定位请求发送到位置URI中指示且携载位置URI的IMS 994(例如，IMS 994中的LRF)而提领在914B接收的位置URI。框924B可对应于图6中的定位请求605B的发送。

[0223] 在926B，IMS 994(例如，IMS 994中的LRF)使用在924B接收的位置URI以识别UE 900，且使用在908接收的任何UE数据和/或在908或922(如果922发生)接收的MNO数据以使用控制平面或用户平面定位解决方案获得UE 900的位置。

[0224] 在928B，IMS 994(例如，IMS 994中的LRF)将UE 900的位置返回到具有i3能力的PSAP 980。

[0225] 类似于或相同于924B、926B和928B的框可在912B之后发生以使得ESInet 960能够从IMS 994(例如，从IMS 994中的LRF)获得UE 900的位置，且基于所述位置将在914B的紧急呼叫路由到正确的PSAP 980。在所述情况下，ESInet 960(例如，ESInet 860中的ESRP，例如ESRP 666)可在类似于或相同于924B的框中将针对UE 900的定位请求发送到IMS 994，且可在类似于或相同于928B的框中从IMS 994接收UE 900的位置。

[0226] 应注意，与图4到9结合描述的程序和技术可依赖于发起紧急呼叫的UE将对LbyR的任何更新(例如，针对图4和7)或对MNO数据的任何更新(例如，在图8中的826和图9中的920)发送到用于UE的OTT SP，以使得OTT SP能够将所述更新转发到PSAP或IMS实体，例如LRF(例如，在图8中的828)或E-CSCF(例如，在图9中的922)。然而，在替代实施例中，经更新LbyR或经更新MNO数据(例如，在发起紧急呼叫的UE越区移交到新SGSN或新MME之后可得到)可由服务MNO中的AN或PCN(例如，由AN或PCN中的MME或SGSN)而不是由UE发送到服务MNO中的PSAP或IMS实体(例如LRF或E-CSCF)。这可例如在检测到UE正在发起紧急呼叫之后(例如，分别在图7、8和9中的每一者中的708、808和908之后)，在用于发起紧急呼叫的UE的服务MNO中的IMS实体或与此相关联的实体(例如，GMLC)将针对任何经更新LbyR或经更新MNO数据的请求发送到服务MNO AN或PCN中的实体(例如，发送到MME或SGSN)的情况下发生。关于这些替代实施例，经更新LbyR或经更新MNO数据可能不需要由发起紧急呼叫的UE发送到OTT SP以及由OTT SP发送到PSAP或例如LRF或E-CSCF等IMS实体。

[0227] 图10说明可并入到设备1002、设备1004和设备1006(分别对应于例如用户装置，例如UE 200、300、400、500、600、700、800或900，接入网络节点，例如接入网络节点240，以及网络实体，例如OTT SP 150、位置服务器170等)中以支持如本文教示的操作的若干样本组件(由对应框表示)。将了解，这些组件可在不同实施方案中在不同类型的设备中(例如，在ASIC中、在SoC中等)实施。所说明的组件也可以并入到通信系统中的其它设备中。举例来说，系统中的其它设备可包含类似于所描述的那些组件的组件以提供相似功能性。并且，给定设备可含有所述组件中的一或多者。举例来说，设备可包含多个收发器组件，其使得所述设备能够在多个载波上操作和/或经由不同技术通信。

[0228] 设备1002和设备1004各自包含至少一个无线通信装置(由通信装置1008和1014表示(以及在设备1004是中继器的情况下的通信装置1020))以用于经由至少一个指定RAT与
其它节点通信。每一通信装置1008包含用于发射和编码信号(例如，消息、指示、信息等)的至少一个发射器(由发射器1010表示)以及用于接收和解码信号(例如，消息、指示、信息、导频等)的至少一个接收器(由接收器1012表示)。类似地，每一通信装置1014包含用于发射信号(例如，消息、指示、信息、导频等)的至少一个发射器(由发射器1016表示以及用于接收信号(例如，消息、指示、信息等)的至少一个接收器(由接收器1018表示)。如果设备1004是中继站，那么每一通信装置1020可包含用于发射信号(例如，消息、指示、信息、导频等)的至少一个发射器(由发射器1022表示)以及用于接收信号(例如，消息、指示、信息等)的至少一个接收器(由接收器1024表示)。

[0229] 发射器和接收器在一些实施方案中可包括集成装置(例如，实施为单个通信装置的发射器电路和接收器电路)，在一些实施方案中可包括单独的发射器装置和单独的接收器装置，或在其它实施方案中可以其它方式实施。设备1004的无线通信装置(例如，多个无线通信装置中的一者)还可包括用于执行各种测量的网络监听模块(NLM)或类似物。

[0230] 设备1006(以及设备1004(如果其不是中继站))包含用于与其它节点通信的至少一个通信装置(由通信装置1026以及任选地1020表示)。举例来说，通信装置1026可包括经配置以经由基于有线或无线回程与一或多个网络实体通信的网络接口。在一些方面中，通信装置1026可被实施为经配置以支持基于有线或无线信号通信的收发器。此通信可涉及例如发送和接收消息、参数或其它类型的信息。因此，在图10的实例中，通信装置1026展示为包括发射器1028和接收器1030。类似地，如果设备1004不是中继站，那么通信装置1020可包括经配置以经由基于有线或无线回程与一或多个网络实体通信的网络接口。如同通信装置
1026，通信装置1020展示为包括发射器1022和接收器1024。

[0231] 设备1002、1004和1006还包含可以与如本文教示的OTT SP和UE位置相关操作结合使用的其它组件。设备1002包含处理系统1032和定位模块1054以用于提供与例如用户装置操作相关的功能性以支持如本文教示的OTT SP和UE位置相关操作，且用于提供其它处理功能性。设备1004包含处理系统1034和定位模块1056以用于提供与例如接入网络节点操作相关的功能性以支持如本文教示的OTT SP和UE位置相关操作，且用于提供其它处理功能性。设备1006包含处理系统1036和定位模块1058以用于提供与例如网络操作相关的功能性以
支持如本文教示的OTT SP和UE位置相关操作，且用于提供其它处理功能性。

[0232] 设备1002、1004和1006进一步分别包含用于维持信息(例如，指示保留资源、阈值、参数等的信息)的存储器组件1038、1040和1042(例如，各自包含存储器装置)。另外，设备1002、1004和1006分别包含用户接口装置1044、1046和1048，用于将指示(例如，可闻和/或视觉指示)提供到用户和/或用于接收用户输入(例如，在例如小键盘、触摸屏、麦克风等的感测装置的用户致动后)。

[0233] 为方便起见，设备1002、1004和/或1006在图10中展示为包含可根据本文所描述的各种实例配置的各种组件。然而将了解，所说明的框在不同设计中可具有不同功能性。

[0234] 图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的硬件/固件组件。

[0235] 图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中图示的特征或功能中的两个或更多个可以组合。

[0236] UE 1100可包含可连接到一或多个天线1112的一或多个蓝牙收发器1114a。蓝牙收发器1114a包括用于与蓝牙接入点(例如，图1A中的AP 125)通信和/或检测去往/来自所述蓝牙接入点的信号的合适装置、硬件和/或软件。另外或替代地，UE 1100可包含可连接到一或多个天线1112的一或多个广域网(WAN)无线收发器1114b。WAN收发器1114b包括用于与WAN-WAP(无线接入点)通信和/或检测去往/来自所述WAN-WAP的信号和/或直接与网络内的其它无线装置(例如，图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可连接到一或多个天线1112以用于接收卫星信号(例如，用于GPS或某种其它
GNSS)。SPS接收器1114d可以包括用于接收并处理SPS信号的任何合适硬件和/或软件。SPS接收器1114d在适当时从其它系统请求信息和操作，并使用由任何合适的SPS算法获得的测量值来执行确定移动装置1100的位置所必需的计算。另外或替代地，可使用任何其它类型的无线连网技术，例如，超宽带、ZigBee、无线USB等等。

[0237] UE 1100可包含一或多个传感器1120。一或多个传感器1120可收集关于用户的数据，包含关于用户的位置、运动、定向、环境、活动或生物计量的数据。所述传感器可包含(例如)例如计步器1122a等虚拟传感器，以及例如加速度计1122b、陀螺仪1122c、生物计量传感器1120d和/或任何数目的杂项传感器1122n(例如，温度计、气压计、湿度计)等物理传感器。

[0238] UE 1100包含一或多个处理器1130。处理器1130可连接到蓝牙收发器1114a、WAN收发器1114b、WLAN收发器1114c、SPS接收器1114d以及一或多个传感器1120。处理器1130可为多核处理器，且虽然说明为单个单元，但可包含提供处理功能以及其它计算和控制功能性的一或多个微处理器、微控制器和/或数字信号处理器。

[0239] 处理器1130可耦合到存储器1140，所述存储器存储用于实行UE 1100内的经编程功能性的数据和软件指令。存储器1140可载于处理器1130上(例如，同一集成电路封装内)，和/或存储器1140可为在处理器1130外部且经由数据总线在功能上耦合的存储器。存储器
1140可包含任何数目的原生应用程序模块1142a…1142n以及通过空中更新或任何其它方
式的若干外部供应模块以及任何数目的数据模块1144a…1144n。应当了解如图11中所示的存储器内容的组织仅是示范性的，并且因此取决于UE 1100的实施方案，所述模块和/或数据结构的功能性可组合、分离和/或以不同方式结构化。存储器1140可存储程序代码(例如，在应用程序模块1142a到1142n中的一或多个中)，所述程序代码可在处理器1130上运行以使得UE 1100能够执行本文所描述的各种程序和技术中的一些或全部。

[0240] UE 1100还可包含定位模块1180，其经配置以执行用户装置操作以支持OTT SP和UE相关定位，如本文中所描述。定位模块1180可为存储在存储器1140中且在处理器1130上运行的可执行模块，或可为耦合到处理器1130的硬件或固件组件。

[0241] 尽管图11中所示的模块在实例中图示为包含于存储器1140中，但应认识到，在某些实施方案中，可以使用其它或另外机制提供或另外可操作地布置此类程序。举例来说，应用程序模块1142a…1142n中的任一者可以固件提供。处理器1130可包含适合于执行至少本文所提供的技术的任何形式的逻辑。举例来说，处理器1130可以操作性地基于存储器1140中的指令配置以选择性地起始利用运动数据供UE 1100的其它部分使用的一或多个例程。

[0242] UE 1100可包含提供任何合适接口系统的用户接口1150，例如麦克风/扬声器1152、触摸垫1153、小键盘1154、显示器1156、相机1158和接近传感器1159，其允许与UE 
1100的用户交互。麦克风/扬声器1152使用WAN收发器1114b和/或WLAN收发器1114c提供话音辨识和/或话音通信服务。小键盘1154包括用于用户输入的任何合适的按钮。显示器1156包括任何合适的显示器(例如，背光式LCD显示器)，并且可进一步包含用于额外用户输入模式的触摸屏显示器。此外，例如由麦克风/扬声器1152、相机1158或小键盘1154表明的功能性等任何输入功能性也可以视为类似于一或多个传感器1120的输入的传感器输入。

[0243] UE 1100进一步包含电力供应器1160，例如电池，用于将电力供应到UE 1100的各种组件。然而将了解，UE 1100可能不包含所说明的所有元件，且最可能将基于装置和设计考虑的要求而仅包含元件的子集。

[0244] 如上所述，一或多个传感器1120可收集关于用户的数据，包含关于用户的位置、定向、运动、环境、活动或生物计量的数据。所述传感器可包含(例如)计步器1122a(其可为基于来自其它传感器的数据的离散装置或功能模块)、加速度计1122b、陀螺仪1122c、生物计量传感器1120d和/或任何数目的杂项传感器1122n。此外，蓝牙收发器1114a、WAN收发器1114b、WLAN收发器1114c和/或SPS接收器1114d可在它们可用以产生关于用户的位置、运动、环境和/或活动的数据的程度上用作传感器。因此，当本发明大体上提到一或多个传感器1120或者传感器读数或传感器数据时，应理解蓝牙收发器1114a、WAN收发器1114b、WLAN收发器1114c和/或SPS接收器1114d可视为传感器，且从此获得的数据可视为传感器读数或传感器数据。

[0245] 在实施例中，生物计量传感器1122d包含用于识别用户的传感器。举例来说，生物计量传感器1122d可为用于话音辨识、指纹辨识、掌印辨识、面部辨识或虹膜辨识的传感器。生物计量传感器1122d可为具体来说被设计用于话音辨识、指纹辨识、掌印辨识、面部辨识和/或虹膜辨识的专用传感器。在另一可能的情形中，麦克风/扬声器1152用作用于话音辨识的传感器。在另一可能的情形中，小键盘1154用作用于指纹辨识和/或掌印辨识的传感器。在又一可能的情形中，相机1158用作用于面部辨识和/或虹膜辨识的传感器。

[0246] 如上所述，处理器1130可耦合到存储器1140，所述存储器存储用于实行UE 1100内的经编程功能性的数据和软件指令。存储器1140可包含任何数目的应用程序模块1142a…1142n和任何数目的数据模块1144a…1144n。在实施例中，应用程序模块1142a…1142n中的一或多者(例如，应用程序模块1142a)利用从计步器1122a、加速度计1122b、陀螺仪1122c、生物计量传感器1120d和/或杂项传感器1122n中的一或多者搜集的所感测数据。所感测数据可存储在数据模块1144a…数据模块1144n中的一或多者中，例如数据模块1144a。

[0247] 因此，本发明的实施例可包含UE(例如，UE 1100)，其包含执行本文所描述的功能的能力。如所属领域的技术人员将了解，各种逻辑元件可以离散元件、在处理器上执行的软件模块或软件与硬件的任何组合实施，以实现本文中所揭示的功能性。举例来说，处理器1130、存储器1140、用户接口1150和定位模块1180可全部合作性地使用以加载、存储和执行本文所揭示的各种功能，且因此用以执行这些功能的逻辑可分布于各种元件上。替代地，可将功能性并入到一个离散组件中。因此，图11中的UE 1100的特征应被视为仅仅是说明性的，且本发明不限于所说明的特征或布置。

[0248] UE 1100与RAN 120/MME 142之间的无线通信可基于不同技术，例如LTE、CDMA、WCDMA、时分多址(TDMA)、频分多址(FDMA)、正交频分多路复用(OFDM)、GSM，或可用于无线通信网络或数据通信网络中的其它协议。如前文中所论述且在此项技术中已知的，可使用多种网络及配置将话音发射及/或数据从RAN 120发射到UE 1100。因此，本文中所提供的说明不希望限制本发明的实施例且仅辅助描述本发明的实施例的各方面。

[0249] 图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、PSAP180)等。因此，通信装置
1200可对应于经配置以在图1A的无线通信系统100A上或使用图1B的特定配置100B与一或
多个其它实体通信(或促进与其的通信)的任何电子装置。

[0250] 参考图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可包含通信装置1200可借以监视其本地环境的感官或测量硬件(例如，加速度计、温度传感器、光传感器、用于监视本地RF信号的天线等)。经配置以接收和/或发射信息的收发器电路1205还可包含软件，所述软件当执行时准许经配置以接收和/或发射信息的收发器电路1205的相关联硬件执行其接收和/或发射功能。然而，经配置以接收和/或发射信息的收发器电路1205不单独对应于软件，且经配置以接收和/或发射信息的收发器电路1205至少部分地依赖于结构硬件来实现其功能性。

[0251] 参考图12，通信装置1200进一步包含经配置以处理信息的至少一个处理器1210。经配置以处理信息的所述至少一个处理器1210可执行的处理类型的实例实施方案包含(但不限于)执行确定、建立连接、在不同信息选项之间进行选择、执行与数据相关的评估、与耦合到通信装置1200的传感器交互以执行测量操作、将信息从一个格式转换到另一格式(例如，在不同协议之间，例如.wmv到.avi等)等。举例来说，经配置以处理信息的至少一个处理器1210可包含通用处理器、DSP、ASIC、现场可编程门阵列(FPGA)或其它可编程逻辑装置、离散门或晶体管逻辑、离散硬件组件，或其经设计以执行本文所描述的功能的任何组合。通用处理器可为微处理器，但在替代方案中，经配置以处理信息的至少一个处理器310可为任何常规处理器、控制器、微控制器或状态机。处理器也可以被实施为计算装置的组合(例如，DSP与微处理器的组合、多个微处理器、与DSP核心结合的一或多个微处理器，或任何其它此类配置)。经配置以处理信息的至少一个处理器1210也可包含软件，所述软件当执行时准许经配置以处理信息的至少一个处理器1210的相关联硬件执行其处理功能。然而，经配置以处理信息的至少一个处理器1210不单独对应于软件，且经配置以处理信息的至少一个处理器1210至少部分地依赖于结构硬件来实现其功能性。

[0252] 参考图12，通信装置1200进一步包含经配置以存储信息的存储器1215。在一实例中，经配置以存储信息的存储器1215可包含至少非暂时性存储器和相关联硬件(例如，存储器控制器等)。举例来说，包含于经配置以存储信息的存储器1215中的非暂时性存储器可对应于RAM、快闪存储器、只读存储器(ROM)、可擦除可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)、寄存器、硬盘、可装卸式磁盘、CD-ROM或所属领域中已知的任何其它形式的存储媒体。经配置以存储信息的存储器1215还可包含在被执行时准许经配置以存储信息的存储器1215的相关联硬件执行其存储功能的软件。然而，经配置以存储信息的存储器1215并不单独对应于软件，且经配置以存储信息的存储器1215至少部分地依赖于结构硬件来实现其功能性。

[0253] 参考图12，通信装置1200进一步任选地包含经配置以呈现信息的用户接口输出电路1220。在一实例中，经配置以呈现信息的用户接口输出电路1220可包含至少输出装置和相关联硬件。举例来说，所述输出装置可包含视频输出装置(例如，显示屏幕、例如USB、HDMI等可携载视频信息的端口等)、音频输出装置(例如，扬声器、例如麦克风插孔、USB、HDMI等可携载音频信息的端口等)、振动装置和/或可借以格式化信息以用于输出或由通信装置1200的用户或操作者实际输出的任何其它装置。举例来说，如果通信装置1200对应于如图
11中所示的UE 1100，那么经配置以呈现信息的用户接口输出电路1220可包含显示器1056和/或扬声器1052。在另一个实例中，经配置以呈现信息的用户接口输出电路1220可针对某些通信装置省略，例如并不具有本地用户的网络通信装置(例如，网络交换机或路由器、远程服务器等)。经配置以呈现信息的用户接口输出电路1220也可包含软件，所述软件当执行时准许经配置以呈现信息的用户接口输出电路1220的相关联硬件执行其呈现功能。然而，经配置以呈现信息的用户接口输出电路1220不单独对应于软件，且经配置以呈现信息的用户接口输出电路1220至少部分地依赖于结构硬件来实现其功能性。

[0254] 参考图12，通信装置1200进一步任选地包含经配置以接收本地用户输入的用户接口输入电路1225。在一实例中，经配置以接收本地用户输入的用户接口输入电路325可包含至少用户输入装置和相关联硬件。举例来说，用户输入装置可包含按钮、触摸屏显示器、键盘、相机、音频输入装置(例如，麦克风或可载运音频信息的端口，例如麦克风插孔等)，及/或可借以从通信装置1200的用户或操作者接收信息的任何其它装置。举例来说，如果通信装置1200对应于如图11中所示的UE 1100，那么经配置以接收本地用户输入的用户接口输入电路1225可包含触摸垫1153、小键盘1154、麦克风1152等。在另一个实例中，经配置以接收本地用户输入的用户接口输入电路1225可针对某些通信装置省略，例如并不具有本地用户的网络通信装置(例如，网络交换机或路由器、远程服务器等)。经配置以接收本地用户输入的用户接口输入电路1225也可包含软件，所述软件当执行时准许经配置以接收本地用户输入的用户接口输入电路1225的相关联硬件执行其输入接收功能。然而，经配置以接收本地用户输入的用户接口输入电路1225不单独对应于软件，且经配置以接收本地用户输入的用户接口输入电路1225至少部分地依赖于结构硬件来实现其功能性。

[0255] 参考图12，虽然1205到1225的经配置结构组件展示为图12中的经由相关联通信总线1230耦合到彼此的单独或相异块，但将了解，1205到1225的相应经配置结构组件借以执行其相应功能性的硬件和/或软件可部分地重叠。举例来说，用以促进1205到1225的经配置结构组件的功能性的任何软件可存储在与经配置以存储信息的存储器1215相关联的非暂时性存储器中，以使得1205到1225的经配置结构组件部分地基于由经配置以存储信息的存储器1215存储的软件的操作而各自执行其相应功能性(即，在此情况下，软件执行)。同样，与1205到1225的经配置结构组件中的一者直接相关联的硬件可不时地由1205到1225的其
它经配置结构组件借用或使用。举例来说，经配置以处理信息的至少一个处理器1210可将数据格式化为适当格式，然后由经配置以接收和/或发射信息的收发器电路1205发射，以使得经配置以接收和/或发射信息的收发器电路1205部分地基于与经配置以处理信息的至少一个处理器1210相关联的结构硬件的操作而执行其功能性(即，在此情况下，数据的发射)。

[0256] 因此，1205到1225的各种结构组件既定调用至少部分地以结构硬件实施的方面，且并不希望映射到独立于硬件的仅软件实施方案和/或非结构功能解读。所属领域的技术人员从对下文更详细描述的方面的审阅将明了1205到1225的结构组件之间的其它交互或协作。

[0257] 各种实施例可实施于多种市售服务器装置中的任一者上，例如图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包含处理器1301，其耦合到易失性存储器1302和大容量非易失性存储器，例如磁盘驱动器1303。
服务器1300还可包含耦合到处理器1301的软盘驱动器、压缩光盘(CD)或DVD盘驱动器1306。
服务器1300还可包含耦合到处理器1301的网络接入端口1304以用于建立与网络1307的数
据连接，所述网络例如耦合到其它广播系统计算机和服务器或耦合到因特网的局域网。在关于图12的上下文中，将了解，图13的服务器1300说明通信装置1200的一个实例实施方案，借此经配置以发射和/或接收信息的逻辑1205对应于由服务器1300用以与网络1307通信的网络接入端口1304，经配置以处理信息的逻辑1210对应于处理器1301，且用以存储信息的逻辑配置1215对应于易失性存储器1302、磁盘驱动器1303和/或光盘驱动器1306的任何组合。任选的经配置以呈现信息的逻辑1220以及任选的经配置以接收本地用户输入的逻辑
1225在图13中未显式地图示，且可或可不包含于其中。因此，图13有助于证明除了图11中的UE实施方案之外，通信装置1200可被实施为服务器。因此，本发明的实施例可包含服务器(例如，服务器1300)，其包含执行本文所描述的功能的能力，例如参考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描述的功能。

[0258] 图14说明由服务于UE的接入网络节点执行的用于定位UE的示范性流程，所述接入网络节点例如图1A和1B中的RAN 120或CN 140的任何组件。举例来说，所述接入网络节点可对应于MME 142。

[0259] 在1410，接入网络节点例如在图2A的206A或图2B的202B从UE接收第一消息。举例来说，在接入网络节点对应于支持LTE的MME的情况下，第一消息可为NAS附接请求或NAS跟踪区域更新请求。在接入网络节点对应于支持UMTS的SGSN的情况下，第一消息可为GPRS附接请求或GPRS路由区域更新请求。

[0260] 在1420，接入网络节点确定用于UE的位置参考。所述位置参考可针对属于用于所述接入网络节点的运营商的位置服务器，例如图1A中的位置服务器170或图1B中的GMLC/SLP 170，且使得能够定位UE。用于UE的位置参考可包含位置服务器的地址和UE的UE参考。
UE参考可由位置服务器指派，且可包含IP地址、IMSI、TMSI、接入网络节点的地址或其任何组合。UE参考也可以经加密。

[0261] 如上文参考图2A的208A或图2B的204B所论述，在1420的确定可包含将针对UE的位置参考的请求发送到位置服务器以及从位置服务器接收针对UE的位置参考。替代地，如上文所论述，接入网络节点可自身产生用于UE的位置参考。在所述情况下，接入网络节点可以数字方式签署用于UE的位置参考以指示用于UE的位置参考是由用于运营商的接入网络节点产生的。

[0262] 在1430，接入网络节点例如在图2A的212A或图2B的206B将第二消息发送到UE。所述第二消息可包含位置参考。在接入网络节点对应于支持LTE的MME的情况下，所述第二消息可为NAS附接接受或NAS跟踪区域更新接受。在接入网络节点对应于支持UMTS的SGSN的情况下，所述第二消息可为GPRS附接接受或GPRS路由区域更新接受。

[0263] UE可在发送到OTT SP(例如OTT SP 150)的紧急服务呼叫请求中包含用于UE的位置参考。UE可经由不同于接入网络节点的接入网络的接入网络将紧急服务呼叫请求发送到OTT SP。OTT SP可基于所述位置参考从位置服务器获得UE的位置。

[0264] 虽然未图示，但在图14中说明的流程可进一步包含在发送第二消息之前验证UE。另外，在图14中说明的流程可进一步包含在UE附接到接入网络节点的同时周期性地确定用于UE的新位置参考，且将新位置参考发送到UE。

[0265] 图15说明在位置服务器处执行的用于定位UE的示范性流程，所述位置服务器例如图1A中的位置服务器170或图1B中的GMLC/SLP 170。

[0266] 在1510，位置服务器例如在图2A的208A或图2B的204B从服务于UE的接入网络节点接收针对用于UE的位置参考的请求。

[0267] 在1520，位置服务器例如在图2A的208A或图2B的204B将用于UE的位置参考发送到接入网络节点。所述位置参考可包含位置服务器的地址和用于UE的本地参考。

[0268] 在1530，位置服务器例如在图2A的216A或图2B的214B从除接入网络节点外的网络实体接收针对UE的位置的定位请求。所述定位请求可包含用于UE的位置参考。另一网络实体可例如为属于OTT SP、ESInet提供者或PSAP的网络实体。

[0269] 在1540，位置服务器可例如在图2A的218A或图2B的216B到226B或228B确定UE的位置估计。在位置服务器对应于SLP的情况下，确定UE的位置估计可包含建立与UE的SUPL会话。在位置服务器对应于GMLC的情况下，确定UE的位置估计可包含使用控制平面定位解决方案确定所述位置估计。在所述情况下，使用控制平面定位解决方案确定位置估计可包含如在图2A的218A或图2B的216B到226B将定位请求发送到接入网络节点以及从接入网络节点接收含有位置估计的位置响应。

[0270] 在1550，位置服务器例如在图2A的224A或图2B的232B将UE的位置估计发送到网络实体。

[0271] UE在发送到OTT SP的紧急服务呼叫请求中包含所述位置参考。在实施例中，UE可经由用于与位置服务器的运营商不同的运营商的接入网络将紧急服务呼叫请求发送到OTT SP。

[0272] 图16说明在位置服务器处执行的用于定位UE的示范性流程，所述位置服务器例如图1A中的位置服务器170或图1B中的GMLC/SLP 170。

[0273] 在1610，位置服务器例如在图2A的216A或图2B的214B从除服务于UE的接入网络节点外的网络实体接收针对UE的位置的定位请求。所述定位请求可包含用于UE的位置参考。所述位置参考可包含用于UE的UE参考。UE参考可为IP地址、IMSI、TMSI、接入网络节点的地址，或其任何组合。另一网络实体可例如为属于OTT SP、ESInet提供者或PSAP的网络实体。

[0274] 在1620，位置服务器验证用于UE的位置参考。所述位置参考可包含数字签名，在此情况下，验证位置参考可包含验证所述数字签名。

[0275] 在1630，位置服务器例如在图2A的218A或图2B的216B到226B或228B基于用于UE的位置参考中的UE参考而确定UE的位置估计。在实施例中，UE参考可经加密，在此情况下，确定UE的位置估计可包含对经加密UE参考进行解密。在位置服务器对应于SLP的情况下，确定UE的位置估计可包含建立与UE的SUPL会话。在位置服务器对应于GMLC的情况下，确定UE的位置估计可包含使用控制平面定位解决方案确定所述位置估计。在所述情况下，使用控制平面定位解决方案确定位置估计可包含如在图2A的218A或图2B的216B到226B将定位请求发送到接入网络节点以及从接入网络节点接收含有位置估计的位置响应。

[0276] 在1640，位置服务器例如在图2A的224A或图2B的232B将UE的位置估计发送到另一网络实体。

[0277] UE可在发送到OTT SP(例如OTT SP)的紧急服务呼叫请求中包含用于UE的位置参考。

[0278] 图17说明由例如UE 1100等UE执行的用于定位进行呼叫的UE的示范性流程。所述呼叫可为紧急呼叫。

[0279] 在1710，UE将第一消息发送到服务于UE的接入网络节点。在接入网络节点对应于支持LTE的MME的情况下，第一消息可为NAS附接请求或NAS跟踪区域更新请求。在接入网络节点对应于支持UMTS的SGSN的情况下，第一消息可为GPRS附接请求或GPRS路由区域更新请求。

[0280] 在1720，UE从接入网络节点接收包含用于UE的位置参考的第二消息。所述位置参考可针对属于用于所述接入网络节点的运营商的位置服务器，例如图1A中的位置服务器170或图1B中的GMLC/SLP 170，且使得能够针对呼叫定位UE。用于UE的位置参考可包含位置服务器的地址和UE的UE参考。在接入网络节点对应于支持LTE的MME的情况下，第一消息可为NAS附接请求或NAS跟踪区域更新请求。在接入网络节点对应于支持UMTS的SGSN的情况
下，第一消息可为GPRS附接请求或GPRS路由区域更新请求。虽然在图17中未说明，但所述流程可进一步包含在接收第二消息之前向接入网络节点验证UE。

[0281] 在1730，UE从UE的用户接收针对呼叫的请求。

[0282] 在1740，UE将针对呼叫的请求发送到OTT SP，例如OTT SP 150。针对呼叫的请求可包含用于UE的位置参考。在实施例中，所述呼叫请求由UE经由不同于接入网络节点的接入网络的接入网络发送到OTT SP。

[0283] 虽然在图17中未说明，但所述流程可进一步包含在UE附接到接入网络节点的同时从接入网络节点周期性地接收用于UE的新位置参考。

[0284] 图18说明用于在例如OTT SP 150等OTT服务提供者处支持紧急呼叫的示范性流程。在实施例中，在图18中说明的流程可由定位模块1058执行或被致使由所述定位模块执行。

[0285] 在1810，OTT SP 150如在806和906从UE接收包括紧急呼叫请求的第一消息，所述UE例如UE 200、300、400、500、600、700、800、900、1002和1100中的任一者。第一消息经由用于UE的服务MNO(例如服务MNO 790、890或990)传送到OTT SP 150。所述第一消息包含用于服务MNO的IMS(例如IMS 894或994)的地址。

[0286] 在820，OTT SP 150如在808和908基于所述地址将第二消息发送到IMS。所述第二消息可为针对紧急呼叫的请求。所述第一消息、第二消息或这两个消息可以是SIP邀请。

[0287] 虽然在图18中未说明，但所述流程可进一步包含如在812从IMS接收包括用于目的地PSAP的路由信息的第三消息，且基于所述路由信息将第四消息发送到或朝向PSAP。所述第三消息可为SIP 300多重选择消息，且所述第四消息可为针对紧急呼叫的请求。用于IMS的地址可用于LRF。所述路由信息可包含参考ID，在此情况下，所述流程可进一步包含在第四消息中包含所述参考ID，其中所述参考ID使得PSAP能够从LRF获得UE的位置。

[0288] IMS可将第五消息发送到或朝向目的地PSAP，其中所述第五消息可为针对UE的紧急呼叫请求。用于IMS的地址可用于E-CSCF。IMS在第五消息中包含参考识别符，其中所述参考识别符使得PSAP能够从IMS获得UE的位置。

[0289] 图19说明用于在用于服务MNO(例如服务MNO 890或990)的IMS实体(例如IMS 894或994)处支持紧急呼叫的示范性流程。在一方面中，所述IMS实体可为LRF。在实施例中，在图19中说明的流程可由定位模块1058执行或被致使由所述定位模块执行。

[0290] 在1910，IMS实体如在808和908接收由OTT服务提供者(例如OTT SP 150)发送的第一消息，所述第一消息包括针对UE的紧急呼叫请求。所述紧急呼叫请求包含用于UE的MNO数据。所述第一消息可为SIP邀请消息。

[0291] 在1920，所述IMS实体如在图9的911基于所述MNO数据确定用于目的地PSAP的路由信息。

[0292] 虽然在图19中未说明，但在实施例中，所述流程可进一步包含将包括路由信息的第二消息发送到OTT服务提供者，其中所述路由信息使得OTT服务提供者能够将紧急呼叫路由到或朝向目的地PSAP。在所述情况下，所述路由信息可为参考ID以及PSAP或中间目的地的地址或身份。所述第二消息可为SIP 300多重选择消息。

[0293] 在实施例中，所述流程可进一步包含从另一实体接收包括所述参考ID的第三消息，基于所述参考ID识别UE，获得UE的位置，以及将包括所述位置的第四消息发送到另一实体。所述参考ID可为ESRK、ESRD加上MSISDN，或位置URI。可使用控制平面定位解决方案或用户平面定位解决方案获得UE的位置。在一方面中，另一实体可为PSAP、ALI或ESInet。

[0294] 在实施例中，所述流程可进一步包含基于路由信息将第二消息发送到或朝向PSAP，其中所述第二消息包括针对紧急呼叫的请求。在此情况下，所述IMS实体可为紧急情况CSCF。

[0295] 图20说明用于在UE处支持紧急呼叫的示范性流程，所述UE例如UE 200、300、400、500、600、700、800、900、1002和1100中的任一者。在实施例中，在图20中说明的流程可由定位模块1054执行或被致使由所述定位模块执行。

[0296] 在2010，UE从UE的用户接收针对紧急呼叫的请求。

[0297] 在2020，UE如在802/804和902/904获得用于UE的服务MNO的MNO数据。

[0298] 在2030，UE如在806和906将包括针对紧急呼叫的请求的第一消息发送到OTT服务提供者，例如OTT SP 150。针对紧急呼叫的请求包含MNO数据。MNO数据可包含用于服务MNO的IMS的地址、用于UE的当前服务移动性管理实体或SGSN的身份、用于UE的服务MNO指派IP地址、UE的全局身份或本地身份，或其某一组合。

[0299] OTT服务提供者基于用于IMS的地址将第二消息发送到IMS，其中所述第二消息包括针对紧急呼叫的请求且包含MNO数据。IMS基于MNO数据确定用于紧急呼叫的路由信息。在此实施例中，所述流程进一步包含接收根据用户平面定位解决方案或控制平面定位解决方案针对位置估计或针对位置测量值的请求，其中所述位置估计或位置测量值使得IMS能够获得UE的位置，其中UE的位置使得IMS能够确定路由信息或为PSAP提供所述位置。

[0300] IMS可将包括路由信息的第三消息发送到OTT服务提供者。OTT服务提供者将第四消息发送到或朝向目的地PSAP，其中所述PSAP是基于路由信息而确定。在此情况下，用于IMS的地址是用于LRF的地址。

[0301] IMS可将第五消息发送到或朝向目的地PSAP，其中所述第五消息包括针对紧急呼叫的请求且其中所述PSAP是基于路由信息而确定。用于IMS的地址可为用于E-CSCF的地址。

[0302] 图21说明表示为一系列互相关功能模块的实例接入网络节点设备2100。用于接收的模块2110可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1014，或处理系统，例如处理系统1034，任选地与定位模块1056结合，如本文所论述。用于确定的模块2120可至少在一些方面中对应于例如处理系统，例如处理系统1034，任选地与定位模块
1056结合，如本文所论述。用于发送的模块2130可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1014，或处理系统，例如处理系统1034，任选地与定位模块1056结合，如本文所论述。

[0303] 图22说明表示为一系列互相关功能模块的实例位置服务器设备2200。用于接收的模块2210可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。用于发送的模块2220可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。用于接收的模块2230可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。用于确定的模块2240可至少在一些方面中对应于例如处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。用于发送的模块2250可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。

[0304] 图23说明表示为一系列互相关功能模块的实例位置服务器设备2300。用于接收的模块2310可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。用于验证的模块2320可至少在一些方面中对应于例如处理系统，例如处理系统1036，任选地与定位模块
1058结合，如本文所论述。用于确定的模块2330可至少在一些方面中对应于例如处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。用于发送的模块2340可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。

[0305] 图24说明表示为一系列互相关功能模块的实例用户设备设备2400。用于发送的模块2410可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1008，或处理系统，例如处理系统1032，任选地与定位模块1054结合，如本文所论述。用于接收的模块2420可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1008，或处理系统，例如处理系统1032，任选地与定位模块1054结合，如本文所论述。用于接收的模块2430可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1008，或处理系统，例如处理系统1032，任选地与定位模块1054结合，如本文所论述。用于发送的模块2440可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1008，或处理系统，例如处理系统1032，任选地与定位模块1054结合，如本文所论述。

[0306] 图25说明表示为一系列互相关功能模块的实例OTT服务提供者设备2500。用于接收的模块2510可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。用于发送的模块2520可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。

[0307] 图26说明表示为一系列互相关功能模块的实例IMS实体设备2600。用于接收的模块2610可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1026，或处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。用于确定的模块2620可至少在一些方面中对应于例如处理系统，例如处理系统1036，任选地与定位模块1058结合，如本文所论述。

[0308] 图27说明表示为一系列互相关功能模块的实例用户设备设备2700。用于接收的模块2710可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1008，或处理系统，例如处理系统1032，任选地与定位模块1054结合，如本文所论述。用于获得的模块2720可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1008，或处理系统，例如处理系统1032，任选地与定位模块1054结合，如本文所论述。用于发送的模块2730可至少在一些方面中对应于例如通信装置，例如图10中的通信装置1008，或处理系统，例如处理系统1032，任选地与定位模块1054结合，如本文所论述。

[0309] 图21到27的模块的功能性可以与本文中的教示一致的各种方式实施。在一些设计中，这些模块的功能性可被实施为一或多个电气组件。在一些设计中，这些块的功能性可被实施为包含一或多个处理器组件的处理系统。在一些设计中，这些模块的功能性可使用例如一或多个集成电路(例如，ASIC)的至少一部分来实施。如本文所论述，集成电路可包含处理器、软件、其它相关组件，或其某一组合。因此，不同模块的功能性可例如实施为集成电路的不同子组、实施为一组软件模块的不同子组，或其组合。并且将了解，(例如，集成电路和/或一组软件模块的)给定子组可提供多于一个模块的功能性的至少一部分。

[0310] 另外，由图21到27表示的组件和功能以及本文所描述的其它组件和功能可使用任何合适的装置来实施。此装置也可至少部分地使用如本文教示的对应结构来实施。举例来说，上文与图21到27的“用于…的模块”组件结合所描述的组件也可对应于类似地指定的“用于…的装置”功能性。因此，在一些方面中，这些装置中的一或多者可使用如本文教示的处理器组件、集成电路或其它合适结构中的一或多者来实施。

[0311] 所属领域的技术人员应了解，可以使用多种不同技艺和技术中的任一者来表示信息和信号。举例来说，可通过电压、电流、电磁波、磁场或磁粒子、光场或光粒子或其任何组合来表示在整个上文描述中可能参考的数据、指令、命令、信息、信号、位、符号和码片。

[0312] 此外，所属领域的技术人员将了解，结合本文所揭示的实施例而描述的各种说明性逻辑块、模块、电路和算法步骤可实施为电子硬件、计算机软件或两者的组合。为清楚地说明硬件与软件的此可互换性，上文已大体上就其功能性描述了各种说明性组件、块、模块、电路和步骤。此功能性是实施为硬件还是软件取决于特定应用及施加于整个系统的设计约束。所属领域的技术人员可针对每一特定应用以不同方式实施所描述的功能性，但此类实施决策不应被解译为引起对本发明的范围的偏离。

[0313] 可使用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或经设计以执行本文所描述的功能的其它可编程逻辑装置、离散门或晶体管逻辑、离散硬件组件或其任何组合来实施或执行结合本文中所揭示的实施例而描述的各种说明性逻辑块、模块和电路。通用处理器可以为微处理器，但在替代方案中，处理器可以为任何常规处理器、控制器、微控制器或状态机。处理器还可实施为计算装置的组合，例如，DSP与微处理器的组合、多个微处理器、一或多个微处理器结合DSP核心，或任何其它此类配置。

[0314] 结合本文所揭示的实施例而描述的方法、序列和/或算法可直接以硬件、以由处理器执行的软件模块或以两者的组合体现。软件模块可驻留在RAM存储器、快闪存储器、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或所属领域中已知的任何其它形式的存储媒体中。示范性存储媒体耦合到处理器，使得处理器可从存储媒体读取信息并且将信息写入到存储媒体。在替代例中，存储媒体可与处理器成一体式。处理器和存储媒体可驻留在ASIC中。ASIC可以驻留在用户终端(例如，UE)中。在替代方案中，处理器和存储媒体可以作为离散组件驻留在用户终端中。

[0315] 在一或多个示范性实施例中，所述功能可以在硬件、软件、固件或其任何组合中实施。如果在软件中实施，那么可将所述功能作为一或多个指令或代码而存储在计算机可读媒体上或经由计算机可读媒体发射。计算机可读媒体包含计算机存储媒体及通信媒体两者，通信媒体包含促进将计算机程序从一处传送到另一处的任何媒体。存储媒体可以是可由计算机存取的任何可用媒体。举例来说且非限制，此类非暂时性计算机可读媒体可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储装置、磁盘存储装置或其它磁性存储装置，或可用于携载或存储呈指令或数据结构的形式的所要程序代码且可由计算机存取的任何其它媒
体。而且，恰当地将任何连接称作计算机可读媒体。举例来说，如果使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)或例如红外线、无线电及微波等无线技术从网站、服务器或其它远程源发射软件，则同轴电缆、光纤电缆、双绞线、DSL或例如红外线、无线电及微波等无线技术包含于媒体的定义中。如本文所使用的磁盘及光盘包含压缩光盘(CD)、激光光盘、光学光盘、数字影音光盘(DVD)、软磁盘及蓝光光盘，其中磁盘通常是以磁性方式再现数据，而光盘是用激光以光学方式再现数据。上述各者的组合也应包含在计算机可读媒体的范围
内。

[0316] 虽然前述揭示内容示出本发明的说明性实施例，但应注意，在不脱离如所附权利要求书界定的本发明的范围的情况下，可以在本文中做出各种改变和修改。无需以任何特定次序来执行根据本文中所述的本发明的实施例的方法权利要求的功能、步骤及/或动作。此外，尽管可以单数形式描述或主张本发明的元件，但除非明确陈述限于单数形式，否则也涵盖复数形式。