通信设备及紧急呼叫处理方法

摘要

本发明提供至少一种通信设备及紧急呼叫处理方法，其中一种通信设备包含：基带信号处理装置、射频信号处理装置、存储装置以及处理器，处理器用于发送具有远程识别码的正常呼叫建立信号至网络以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求，接收指示正常呼叫为自网络传输而来的紧急呼叫的指示消息，将所述远程识别码记录于存储装置中，并当接收到具有所述远程识别码的第二呼叫发端请求时，发送具有所述远程识别码的紧急呼叫建立信号至网络以发起紧急呼叫，来响应第二呼叫发端请求。本发明不仅可解决因未检测到的紧急呼叫而造成的延迟及/或丢失呼叫的问题，也可防止误发送具有非有效紧急呼叫地址的远程识别码的紧急呼叫建立信号。

权利要求

1.一种通信设备，包含：

基带信号处理装置；

射频信号处理装置；

存储装置；以及

处理器，用于发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求，自所述网络接收指示所述正常呼叫作为紧急呼叫进行传输的指示消息，将所述远程识别码记录于所述存储装置中，并当接收到具有所述远程识别码的第二呼叫发端请求时，将所述第二呼叫发端请求所具有的所述远程识别码与所述存储装置中记录的数据进行比较，以检测并确定所述远程识别码为紧急呼叫地址，发送具有所述远程识别码的紧急呼叫建立信号至所述网络，以发起紧急呼叫，来响应所述第二呼叫发端请求。

2.根据权利要求1所述的通信设备，其特征在于，所述远程识别码为移动台国际用户目录号、会话初始化协议统一资源标识符或电话统一资源标识符。

3.根据权利要求1所述的通信设备，其特征在于，所述指示消息为互联网协议多媒体子系统中的会话初始化协议消息、可选服务会话初始化协议响应消息、或者包含私人主张识别码头域及求救信号标识的会话初始化协议响应消息。

4.一种紧急呼叫处理方法，包含：

由用户设备发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求；

由所述用户设备自所述网络接收指示所述正常呼叫作为紧急呼叫进行传输的指示消息；

由所述用户设备将所述远程识别码及所述用户设备的位置信息记录于存储装置中；以及当接收到具有所述远程识别码的第二呼叫发端请求时，所述用户设备将所述第二呼叫发端请求所具有的所述远程识别码与所述存储装置中记录的数据进行比较，以检测并确定所述远程识别码为紧急呼叫地址，发送具有所述远程识别码的紧急呼叫建立信号至所述网络，以发起紧急呼叫，来响应所述第二呼叫发端请求。

5.根据权利要求4所述的紧急呼叫处理方法，其特征在于，所述用户设备的所述位置信息包含所述网络的公共陆地移动网络识别码、所述网络的基站识别码、所述网络的小区识别码、所述网络的移动国家码及/或所述用户设备的全球定位系统数据。

6.根据权利要求4所述的紧急呼叫处理方法，其特征在于，所述远程识别码为移动台国际用户目录号、会话初始化协议统一资源标识符或电话统一资源标识符。

7.根据权利要求4所述的紧急呼叫处理方法，其特征在于，所述指示消息为互联网协议多媒体子系统中的会话初始化协议消息、可选服务会话初始化协议响应消息、或者包含私人主张识别码头域及求救信号标识的会话初始化协议响应消息。

8.一种紧急呼叫处理方法，包含：

由用户设备发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求；

由所述用户设备自所述网络接收指示所述正常呼叫作为紧急呼叫进行传输的指示消息；

由所述用户设备将所述远程识别码及所述用户设备的位置信息记录于存储装置中；

当接收到具有所述远程识别码的第二呼叫发端请求时，所述用户设备将所述第二呼叫发端请求所具有的所述远程识别码与所述存储装置中记录的数据进行比较，以检测并确定所述远程识别码为紧急呼叫地址，由所述用户设备将具有所述远程识别码的紧急呼叫建立信号发送至所述网络，以发起紧急呼叫，来响应具有所述远程识别码的第二呼叫发端请求；

确定所述用户设备的位置是否发生多个预定变化中的至少一个；以及

当确定所述用户设备的所述位置已发生所述多个预定变化中的至少一个时，由所述用户设备删除所述远程识别码的记录。

9.根据权利要求8所述的紧急呼叫处理方法，其特征在于，所述用户设备的所述位置信息包含所述网络的公共陆地移动网络识别码、所述网络的基站识别码、所述网络的小区识别码、所述网络的移动国家码及/或所述用户设备的全球定位系统数据。

10.根据权利要求8所述的紧急呼叫处理方法，其特征在于，所述用户设备的所述位置的所述多个预定变化包含所述网络的公共陆地移动网络识别码的变化，所述网络的基站识别码的变化，所述网络的小区识别码的变化，所述网络的移动国家码的变化，所述用户设备的关于所述网络的注册状态的变化，所述用户设备的全球定位系统数据的变化。

11.根据权利要求10所述的紧急呼叫处理方法，其特征在于，通过将与已记录的远程识别码有关的已记录位置信息与所述用户设备的当前位置信息作比较，来确定所述用户设备的所述多个预定变化中的至少一个是否发生。

12.根据权利要求8所述的紧急呼叫处理方法，其特征在于，所述远程识别码为移动台国际用户目录号、会话初始化协议统一资源标识符或电话统一资源标识符。

13.根据权利要求8所述的紧急呼叫处理方法，其特征在于，所述指示消息为互联网协议多媒体子系统中的会话初始化协议消息、可选服务会话初始化协议响应消息、或者包含私人主张识别码头域及求救信号标识的会话初始化协议响应消息。

14.一种通信设备，包含：

发送模块，发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求；

接收模块，接收所述第一呼叫发端请求，并自所述网络接收指示所述正常呼叫作为紧急呼叫进行传输的指示消息；

存储装置，耦接于所述接收模块，用于将所述远程识别码记录于所述存储装置中；以及处理器模块，耦接于所述发送模块、所述接收模块及所述存储装置，当所述接收模块接收到具有所述远程识别码的第二呼叫发端请求时，所述处理器模块将所述第二呼叫发端请求所具有的所述远程识别码与所述存储装置中记录的数据进行比较，以检测并确定所述远程识别码为紧急呼叫地址，以及所述发送模块发送具有所述远程识别码的紧急呼叫建立信号至所述网络，以发起紧急呼叫，来响应所述第二呼叫发端请求。

说明书

通信设备及紧急呼叫处理方法

技术领域

[0001] 本发明是有关互联网协议(IP)多媒体子系统(IP Multimedia Subsystem,IMS)中的紧急呼叫处理方法，更具体地，是有关于IP多媒体子系统中未检测到的紧急呼叫的处理方法。

背景技术

[0002] IP多媒体子系统使用会话初始化协议(Session Initiation Protocol,SIP)来建立和控制用户终端之间的呼叫或会话。SIP信号所承载的会话描述协议(Session Description Protocol,SDP)用于对会话的多媒体组件进行描述和协商。当SIP作为用户对用户(user-to-user)协议创建时，IP多媒体子系统相应允许运营商和服务提供者控制对服务的用户接入和对用户的收费。

[0003] 用户终端的用户，例如，可能需要在紧急情况下发起呼叫。无线通信网络可识别紧急呼叫，并可将紧急呼叫传输(route)至与无线通信网络有关的公共安全通信系统。

[0004] 用户可能需要在其处于“本地(home)”通信网络或当其处于“漫游(roaming)”状态且可能接近另一个“当地(local)”或“访问的(visited)”通信网络时发起紧急呼叫。然而，当移动手机用户处于漫游时，来自用户移动手机的紧急呼叫可能没有传输至与当地(或访问的)通信网络有关的本地公共安全系统。因此，位于或靠近用户当前位置的适当的紧急响应者有可能接收不到及时的提醒。

[0005] 因此，需要提供一种加强型的IP多媒体子系统中的紧急呼叫处理方法。

发明内容

[0006] 有鉴于此，本发明提供至少一种通信设备及紧急呼叫处理方法。

[0007] 本发明提供一种通信设备，包含：基带信号处理装置；射频信号处理装置；存储装置；以及处理器，用于发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求，自所述网络接收指示所述正常呼叫作为紧急呼叫进行传输的指示消息，将所述远程识别码记录于所述存储装置中，并当接收到具有所述远程识别码的第二呼叫发端请求时，将所述第二呼叫发端请求所具有的所述远程识别码与所述存储装置中记录的数据进行比较，以检测并确定所述远程识别码为紧急呼叫地址，发送具有所述远程识别码的紧急呼叫建立信号至所述网络，以发起紧急呼叫，来响应所述第二呼叫发端请求。

[0008] 本发明另提供一种紧急呼叫处理方法，包含：由用户设备(User Equipment,UE)发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求；由所述用户设备自所述网络接收指示所述正常呼叫作为紧急呼叫进行传输的指示消息；由所述用户设备将所述远程识别码及所述用户设备的位置信息记录于存储装置中；以及当接收到具有所述远程识别码的第二呼叫发端请求时，所述用户设备将所述第二呼叫发端请求所具有的所述远程识别码与所述存储装置中记录的数据进行比较，以检测并确定所述远程识别码为紧急呼叫地址，发送具有所述远程识别码的紧急呼叫建立信号至所述网络，以发起紧急呼叫，来响应所述第二呼叫发端请求。

[0009] 本发明另提供一种紧急呼叫处理方法，包含：由用户设备发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求；由所述用户设备自所述网络接收指示所述正常呼叫作为紧急呼叫进行传输的指示消息；由所述用户设备将所述远程识别码及所述用户设备的位置信息记录于存储装置中；由所述用户设备将具有所述远程识别码的紧急呼叫建立信号发送至所述网络，以发起紧急呼叫，来响应具有所述远程识别码的第二呼叫发端请求；确定所述用户设备的位置是否发生多个预定变化中的至少一个；以及当确定所述用户设备的所述位置已发生所述多个预定变化中的至少一个时，由所述用户设备删除所述远程识别码的记录。

[0010] 本发明另提供一种通信设备，包含：发送模块，发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有所述远程识别码的第一呼叫发端请求；接收模块，接收所述第一呼叫发端请求，并自所述网络接收指示所述正常呼叫作为紧急呼叫进行传输的指示消息；存储模块，耦接于所述接收模块，用于将所述远程识别码记录于存储装置中；其中，当所述接收模块接收到具有所述远程识别码的第二呼叫发端请求时，所述发送模块发送具有所述远程识别码的紧急呼叫建立信号至所述网络，以发起紧急呼叫，来响应所述第二呼叫发端请求。

[0011] 利用本发明所提供的至少一种通信设备及紧急呼叫处理方法，不仅可解决因未检测到的紧急呼叫而造成的延迟及/或丢失呼叫的问题，也可防止误发送具有非有效紧急呼叫地址的远程识别码的紧急呼叫建立信号的情况出现。

附图说明

[0012] 图1为根据本发明一实施例的通信设备的方块示意图。

[0013] 图2为根据本发明一实施例的处理正常呼叫的IP多媒体子系统的架构示意图。

[0014] 图3为根据本发明一实施例的处理紧急呼叫的IP多媒体子系统的架构示意图。

[0015] 图4为根据本发明一实施例的通信系统中的紧急呼叫处理流程图。

[0016] 图5为根据本发明另一实施例的通信系统中的紧急呼叫处理流程图。

[0017] 图6为根据本发明另一实施例的紧急呼叫数据库的管理流程图。

具体实施方式

[0018] 在说明书及权利要求当中使用了某些词汇来指称特定的组件。本领域技术人员应可理解，硬件制造商可能会用不同的名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。在通篇说明书及权利要求当中所提及的“包含”及“包括”为一开放式的用语，故应解释成“包含但不限定于”。“大致”是指在可接受的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。此外，“耦接”一词在此包含任何直接及间接的电性连接手段。因此，若文中描述一第一装置耦接于一第二装置，则代表该第一装置可直接电性连接于该第二装置，或通过其它装置或连接手段间接地电性连接至该第二装置。以下所述为实施本发明的较佳方式，目的在于说明本发明的精神而非用以限定本发明的保护范围，本发明的保护范围当视后附的权利要求所界定者为准。

[0019] 图1为根据本发明一实施例的通信设备的方块示意图。通信设备100可为笔记本电脑、移动手机、便携式游戏装置、便携式多媒体播放器、全球定位系统(Global Positioning System,GPS)、接收器、个人数字助理、台式电脑或其他类似装置。通信设备100可包含至少一基带信号处理装置110、射频信号处理装置120、处理器130、存储装置140及包含至少一天线的天线模块。请注意，为了清楚说明本发明的概念，在图1所呈现的简化方块示意图中，只显示与本发明有关的元件。然而，本发明不应以图1所示元件为限。

[0020] 射频信号处理装置120可通过天线接收射频信号，并对接收到的射频信号进行处理，将接收到的射频信号转换为基带信号，以待基带信号处理装置110进行处理，或者射频信号处理装置120可接收来自基带信号处理装置110的基带信号，并将接收到的基带信号转换为射频信号，以待发送至同级通信设备。射频信号处理装置120可包含用于执行无线电频率转换的多个硬件元件。例如，射频信号处理装置120可包含功率放大器、混频器或其他。

[0021] 基带信号处理装置110可进一步处理基带信号。基带信号处理装置110也可包含多个硬件元件以执行基带信号处理器。基带信号处理可包含模数转换(Analog-to-Digital Conversion,ADC)/数模转换(Digital-to-Analog Conversion,DAC)、增益调整、调制/解调、编码/解码等。

[0022] 处理器130可控制基带信号处理装置110和射频信号处理装置120的操作。根据本发明一实施例，处理器130也可安排用于执行对应的基带信号处理装置及/或射频信号处理装置的软件模块的程序代码。携带数据结构中的特定数据的程序代码在被执行时也可称为处理器逻辑单元或协议栈实例(stack instance)。因此，处理器可视为包含多个处理器逻辑单元，每个逻辑单元用于执行相应软件模块的一个或多个特定功能或任务。存储装置140可储存通信设备100的软件或固件(firmware)程序代码、系统数据、用户数据等。

[0023] 根据本发明一实施例，射频信号处理装置120及基带信号处理装置110可共同视为能够按照预定无线电接入技术(Radio Access Technology,RAT)与无线网络通信以提供无线通信服务的无线电模块。请注意，在本发明的一些实施例中，通信设备100可进一步扩展为包含多于一个天线及/或多于一个无线电模块，本发明并不仅限于图1所示。

[0024] 另外，在本发明的一些实施例中，处理器可配置于基带信号处理装置110的内部，或通信设备100可包含配置于基带信号处理器装置110内部的另一处理器。因此，本发明并不仅限于图1所示架构。

[0025] 图2为根据本发明一实施例的处理正常呼叫的IP多媒体子系统的架构示意图。IP多媒体子系统核心网络210包含代理呼叫/会话控制功能(Proxy Call/Session Control Function,P-CSCF)及服务呼叫/会话控制功能(Serving Call/Session  Control Function,S-CSCF)网络节点及媒体平面(media plane)。IP多媒体子系统服务层220包含一个或多个SIP应用服务器(SIP Application Servers,SIP-AS)。P-CSCF为用于SIP终端的IP多媒体子系统内的第一联络点。SIP终端可以是，例如，UE或图1所示的通信设备。S-CSCF为用户提供其订制的服务。IP接入网可建立于UE与IP多媒体子系统核心网络之间。家庭用户服务器(Home Subscriber Server,HSS)提供用户数据至S-CSCF。

[0026] UE可通过Gm接口(Gm interface)与P-CSCF进行通信。P-CSCF可通过Mw接口(Mw interface)与S-CSCF进行通信。S-CSCF可通过Mw接口与公共安全应答点(Public Safety Answering Point,PSAP)(图中未示)进行通信。SIP-AS可通过ISC接口(ISC interface)与S-CSCF进行通信。HSS可通过Cx接口(Cx interface)与S-CSCF进行通信。

[0027] 图3为根据本发明一实施例的处理紧急呼叫的IP多媒体子系统的架构示意图。IP多媒体子系统核心网络310包含P-CSCF及紧急呼叫/会话控制功能(Emergency Call/Session Control Function,E-CSCF)网络节点及媒体平面。PSAP为呼叫中心，负责对报警、火警及救护服务等紧急电话号码的呼叫予以应答。位置检索功能(Location Retrieval Function,LRF)有助于E-CSCF网络确定发起呼叫的UE的位置。紧急接入转移功能(Emergency Access Transfer Function,EATF)为IP多媒体子系统的紧急会话锚定(session anchoring)及分组交换(Packet Switched,PS)至电路交换(Circuit Switched,CS)的接入转移提供操作(procedures)与功能。LRF可通过MI接口(MI interface)与E-CSCF进行通信。EATF可通过I4接口(I4interface)与E-CSCF进行通信。

[0028] 由于IP多媒体子系统中的正常呼叫和紧急呼叫的处理架构不同，正常呼叫和紧急呼叫也以不同路径进行传输。通常，当UE识别出接收到的呼叫发端(call-origination)请求的地址为紧急呼叫地址时，UE可建立紧急分组数据网络(Packet Data Network,PDN)，即紧急承载(bearer)，或者UE可在SIP消息中包含求救信号(SOS)标识，以便该呼叫可作为紧急呼叫进行传输。相比于正常呼叫，紧急呼叫可具有更高的优先级，更低的阻塞率(blocking rate)及更少的控制策略。然而，当UE无法识别接收到的呼叫发端请求的地址为紧急呼叫地址时(例如，当用户拨出了紧急呼叫号码，但是UE无法将该号码识别为紧急呼叫时)，UE可能建立正常承载，而该紧急呼叫可能作为正常呼叫进行传输。因为正常呼叫相较于紧急呼叫具有低优先级，高阻塞率及更多的控制政策，所以位于或靠近用户当前位置的适当的紧急响应者有可能无法及时地接收到提醒。因此，未被检测到的紧急呼叫有可能发生长时间的延迟及/或高呼叫丢失率的问题。因此，UE获悉未检测到的紧急呼叫很重要。

[0029] 图4为根据本发明一实施例的通信系统中的紧急呼叫处理流程图。根据本发明一实施例，当接收到具有远程识别码的第一呼叫发端请求时，例如，当用户拨出统一资源标识符(Uniform Resource Identifier,URI)或电话号码时，通信设备(如通信设备100，可为通信网络中的UE)中的处理器(如处理器130)可首先确定该远程识别码是否为紧急呼叫地址。根据本发明一实施例，远程识别码和紧急呼叫地址可为移动台国际用户目录号(Mobile Station International Subscriber Directory Number,MSISDN)、SIP URI或电话URI。

[0030] 当处理器确定远程识别码并非紧急呼叫地址时，处理器可发送具有该远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应第一呼叫发端请求。一旦接收到正常呼叫建立信号，网络可基于图2所示的架构开启正常呼叫建立操作。

[0031] 在正常呼叫建立操作期间，正常的呼叫建立信号可由P-CSCF传输至S-CSCF，然后传输至SIP-AS。网络端的P-CSCF及/或SIP-AS可再次检测该远程识别码是否为紧急呼叫地址。当网络端检测到该远程识别码为紧急呼叫地址时，紧急呼叫指示可由网络发送至UE。

[0032] 根据本发明一实施例，指示消息可为IP多媒体子系统中的SIP消息。例如，指示消息可为代码为380(可选服务)的SIP响应消息，指示正常呼叫作为紧急呼叫进行传输。在另一个例子中，指示消息可为包含私人主张识别码(P-Asserted-Identity)头域(header field)及SOS标识的SIP响应消息，指示正常呼叫作为紧急呼叫进行传输。

[0033] 一旦接收到指示消息，处理器可获悉用于紧急呼叫的远程识别码，并可将远程识别码记录于存储装置(如存储装置140)中的紧急呼叫数据库中。紧急呼叫数据库可以任意形式呈现，本发明并不以此为限。例如，紧急呼叫数据库可为紧急呼叫的号码列表、IP地址、SIP URI或电话URI。在另一个例子中，紧急呼叫数据库可为记录紧急呼叫的号码、IP地址、SIP URI或电话URI的数据结构。根据本发明一实施例，紧急呼叫的号码、IP地址、SIP URI或电话URI可由常用用户识别模块卡(如SIM卡、USIM卡及ISIM卡等)中所储存的数据中、由网络接收的数据中、用户手动建立或输入的数据中及在上述呼叫建立操作期间获悉的数据中来获取。

[0034] 当呼叫释放之后及当处理器接收具有该远程识别码的第二呼叫发端请求时，通过将该远程识别码与已记录于紧急呼叫数据库中的数据作比较，处理器可能再次检测到该远程识别码为紧急呼叫地址。此后，处理器可发送具有该远程识别码的紧急呼叫建立信号至网络，以发起紧急呼叫，来响应第二呼叫发端请求。一旦接收到紧急呼叫建立信号，网络可基于图3所示的架构开启紧急呼叫建立操作。因此，当处理器再次接收到具有相同远程识别码的呼叫发端请求时，呼叫发端请求可作为紧急呼叫来对待，从而解决由未检测到紧急呼叫而造成的延迟及/或丢失呼叫的问题。

[0035] 根据本发明另一实施例，除远程识别码之外，处理器可进一步记录与待处理器记录于紧急呼叫数据库的远程识别码有关的通信设备(或UE)的当前位置信息。

[0036] 图5为根据本发明另一实施例的通信系统中的紧急呼叫处理流程图。在图5所示的流程图中，省略了网络端的操作，仅显示通信设备(或UE)所执行的操作。有关网络端操作的详细说明，请参见图4的描述，简洁起见，此处不再赘述。

[0037] 首先，处理器发送具有远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应具有该远程识别码的呼叫发端请求(步骤S502)。当该远程识别码为未检测到的紧急呼叫地址，且当网络检测到该远程识别码为紧急呼叫地址时，处理器可由网络接收指示该正常呼叫作为紧急呼叫进行传输的指示消息(步骤S504)。接着，处理器可将该远程识别码及通信设备(或UE)的位置信息记录于通信设备(或UE)的存储装置中(步骤S506)。根据本发明一实施例，伴随通信设备的当前位置信息的远程识别码可记录于上述紧急呼叫数据库中。通信设备的当前位置信息可能是用于进一步确定已记录的远程识别码有效或无效的重要信息。根据本发明一实施例，位置信息可为网络的公共陆地移动网络识别码(Public Land Mobile Network Identity,PLMN  ID)、网络的基站识别码(Base Station Identifier,BSID)、网络的小区识别码、网络的移动国家码(Mobile Country Code,MCC)及/或通信设备(或UE)的全球定位系统数据。请注意，此处的“网络”指通信设备(或UE)接入、驻留(camp on)、注册及/或有关的网络。

[0038] 最后，一旦处理器接收到具有相同远程识别码的另一呼叫发端请求，处理器可通过检查上述紧急呼叫数据库中的记录识别出该远程识别码为紧急呼叫地址，并可发送具有该远程识别码的紧急呼叫建立信号至网络，以发起紧急呼叫，来响应呼叫发端请求(步骤S508)。紧急呼叫数据库的检查可通过，例如，将该远程识别码与紧急呼叫数据库中的记录作比较来执行。

[0039] 根据本发明一实施例，通信设备(或UE)可包含接收模块、发送模块及存储模块。当接收模块接收到具有远程识别码的第一呼叫发端请求后，发送模块发送具有该远程识别码的正常呼叫建立信号至网络，以发起正常呼叫，来响应第一呼叫发端请求。接着，接收模块自所述网络接收指示该正常呼叫作为紧急呼叫进行传输的指示消息。存储模块耦接于接收模块，用于将该远程识别码记录于存储装置中。其中，当接收模块接收到具有该远程识别码的第二呼叫发端请求时，发送模块发送具有该远程识别码的紧急呼叫建立信号至网络，以发起紧急呼叫，来响应第二呼叫发端请求。

[0040] 根据本发明另一实施例，处理器可进一步确定记录于紧急呼叫数据库中的远程识别码是否仍为有效的紧急呼叫地址。例如，对于不同国家或不同地区，紧急呼叫地址可能不同。当处理器确定记录于紧急呼叫数据库中的远程识别码不再为有效的紧急呼叫地址时，处理器可删除该记录。

[0041] 图6为根据本发明另一实施例的紧急呼叫数据库的管理流程图。为了管理紧急呼叫数据库，处理器可首先确定通信设备(或UE)的位置是否发生多个预定变化中的至少一个(步骤S602)。根据本发明一实施例，多个预定变化中的至少一个是否发生可通过将与已记录的远程识别码有关的已记录的位置信息与通信设备(或UE)的当前位置信息作比较来确定。

[0042] 根据本发明一实施例，位置的预定变化可为网络的PLMN ID的变化、网络的BSID的变化、网络的小区ID的变化、网络的MCC的变化、与网络有关的UE的注册状态的变化及UE的GPS数据的变化。请注意，此处“网络”指通信设备(或UE)接入、驻留、注册及/或有关的网络。与网络有关的UE的注册状态变化可通过通信设备(或UE)是否由通信设备(或UE)记录远程识别码时先前已注册的网络中注销来确定，或通过与网络有关的通信设备(或UE)记录远程识别码时先前已注册的的注册状态是否由已注册变化为未注册来确定，或其他类似方法来确定。

[0043] 若通信设备(或UE)的位置未发生任何预定变化，则远程识别码的记录因其仍为有效的紧急呼叫地址而可保存于紧急呼叫数据库中。若通信设备(或UE)的位置发生了任意预定变化，则处理器删除该远程识别码的记录(步骤S604)。

[0044] 当紧急呼叫数据库维持良好时，不仅可解决因未检测到的紧急呼叫而造成的延迟及/或丢失呼叫的问题，也可防止误发送具有非有效紧急呼叫地址的远程识别码的紧急呼叫建立信号的情况出现。

[0045] 本发明的上述实施例可以多种方式来实施。例如，实施例可使用硬件、软件及其组合来实施。请注意，执行上述功能的任意元件(component)或元件组合一般可视为控制上述功能的一个或多个处理器。上述一个或多个处理器可实施为多种方式，如使用专用硬件、或采用使用微码(microcode)或软件编程以执行上述功能的通用硬件。

[0046] 虽然本发明已以较佳实施例揭露如上，然其并非用以限定本发明，任何本领域技术人员，在不脱离本发明的精神和范围内，当可作些许的更动与润饰，因此本发明的保护范围当视后附的权利要求所界定者为准。