用于处理针对紧急呼叫的请求的方法和用户设备与流程

在此的实施例大体上涉及无线移动通信领域，并且更具体地涉及无线移动通信网络中的紧急呼叫的应对。

背景技术：

为了满足自从部署4G通信系统以来已经增加的无线数据业务的需求，已经做出努力来开发改进的5G或5G前(pre-5G)通信系统。因此，5G或5G前通信系统也称为‘超4G网络’或‘后LTE系统’。认为5G通信系统实现在较高频率(毫米波)频带(例如60GHz频带)中，以便达到较高的数据速率。为了减少无线电波的传播损耗并增加传输距离，在5G通信系统中讨论波束形成、大规模多输入多输出(MIMO)、全维度MIMO(FD-MIMO)、阵列天线、模拟波束形成、大规模天线技术。此外，在5G通信系统中，基于先进小小区、云无线接入网络(RAN)、超密集网络、设备到设备(D2D)通信、无线回程、移动网络、协作通信、协作多点(CoMP)、接收端干扰消除等，正在进行系统网络改进的开发。在5G系统中，已经开发了作为先进编码调制(ACM)的混合FSK与QAM调制(FQAM)和滑动窗口叠加编码(SWSC)以及作为先进接入技术的滤波器组多载波(FBMC)、非正交多址接入(NOMA)和稀疏码多址接入(SCMA)。

作为人类生成和消费信息的以人为中心的连接网络的互联网，现在正演进到分布式实体(诸如事物)在没有人类干预的情况下交换和处理信息的物联网(IoT)。已经出现了万联网(IoE)，其为IoT技术和大数据处理技术通过与云服务器的连接的结合。由于已经需要诸如“感测技术”、“有线/无线通信和网络基础设施”、“服务接口技术”和“安全技术”之类的技术元素用于IoT实现，因此最近已经研究了传感器网络、机器对机器(M2M)通信、机器类型通信(MTC)等等。这样的IoT环境可以提供智能互联网技术服务，其通过对在连接的事物之间生成的数据进行收集和分析来为人类生活创造新的价值。IoT可以通过现有的信息技术(IT)和各种工业应用之间的融合和结合而应用于包括智能家居、智能建筑、智能城市、智能汽车或连网汽车、智能电网、健康护理、智能家电和先进医疗服务的各种领域。

与此一致，已经进行了将5G通信系统应用于IoT网络的各种尝试。例如，可以通过波束成形、MIMO和阵列天线来实现诸如传感器网络、机器类型通信(MTC)和机器对机器(M2M)通信之类的技术。也可以认为作为上述大数据处理技术的云无线接入网络(RAN)的应用是5G技术与IoT技术之间的融合的示例。

无线移动通信网络实现诸如语音呼叫、短消息服务(SMS)、多媒体消息服务(MMS)、互联网接入、紧急呼叫等等的大量服务。根据由第三代合作伙伴计划(3GPP)制定的标准，通过诸如移动电话、平板、可穿戴设备之类的用户设备(UE)来提供这些服务。正在无缝地修改3GPP标准中的规范以在用于无线移动通信的网络中实现有效带宽利用，提高数据速度，增强用户体验等等。为提供给UE的用户的各种特征提供最佳可能的服务质量(QoS)主要有助于增强用户体验。

技术实现要素：

技术问题

紧急呼叫服务使得UE的用户能够在注册或未注册到服务提供商的网络的情况下呼叫预定义的紧急号码。紧急呼叫服务的最关键的要求之一是将紧急呼叫掉话、紧急呼叫失败或紧急呼叫延迟的情况减少到最小。然而，利用应对紧急呼叫的当前方法，根据3GPP标准，对于某些情况，呼叫掉话、呼叫失败或呼叫延迟的情况可能是相当多的。例如，考虑以下情况，即，UE中的控制平面(CP)层出于如3GPP TS 24.301规范中指定的原因(例如，由于T3412定时器到期等)而以TAU请求向网络发起特定过程(例如，跟踪区更新(TAU)过程)的情况。万一，同时如果CP接收到紧急呼叫请求，则紧急呼叫被阻止，直到完成TAU过程为止。从而紧急呼叫被搁置。此外，如果TAU请求被网络以针对原因值#9、#10或#40的TAU拒绝而拒绝，则根据拒绝原因应对，UE应该发起附着过程。因此，即使紧急呼叫正在待决，UE也发起附着过程，并且紧急呼叫被进一步搁置。一旦UE从网络获得附着接受，只有那时UE才发起扩展服务请求(ESR)过程以移至2G/3G无线电接入技术(RAT)，使得可以发起紧随移动性管理(MM)和呼叫控制CC)过程的紧急呼叫过程。此外，如果发起的附着请求过程由于来自网络的附着拒绝或由于某些临时网络异常条件而不成功，如规范24.301中所指定的，则这进一步延迟紧急呼叫或者甚至可能导致紧急呼叫建立失败。

在另一情况下，如果对于发起的TAU请求，UE从网络接收到具有原因值#11、#13的TAU拒绝。根据拒绝原因应对，UE应该发起公共陆地移动网络(PLMN)搜索。因此，即使紧急呼叫正在待决，UE也发起PLMN搜索过程。此外，在完成PLMN搜索过程之前，紧急呼叫被延迟或拒绝。

在另一情况下，由于来自UE的AP的紧急呼叫请求，可以由UE的CP向网络发起TAU过程。即使在由于紧急呼叫发起而发起特定过程的这样的情况下，如果该特定过程失败，并且如果UE继续执行相应的失败动作，则这会延迟紧急呼叫过程。类似地，在由于紧急呼叫而发起的TAU过程由于与网络相对应的异常情况而失败的情况下，UE端的紧急呼叫过程受到延迟。

在另一情况下，当UE针对到来的移动终接(MT)呼叫接收到寻呼时，则根据当前3GPP规范，UE以寻呼响应来响应寻呼。此外，UE移至‘等待网络命令’状态，并启动定时器T3240。在该时段期间，如果UE中的连接管理(CM)层发起针对紧急呼叫的CM服务请求，则根据3GPP标准的当前规范，该CM服务请求可以被拒绝或延迟，直到等待网络命令为UE离开的状态为止。这归因于在3GPP标准的当前规范中给予MT呼叫的偏好。此外，每当发起的T3240到期时，UE中止无线电资源(RR)连接并移至空闲状态。因此，这可能进一步导致紧急呼叫建立失败。

然而，需要以高优先级和最小呼叫掉话或呼叫失败率来处理紧急呼叫；否则可能无法提供紧急呼叫的目的。

在此的实施例的主要目的是提供一种用于当UE从网络接收到特定过程拒绝原因或者UE进行与移动终接(MT)呼叫相对应的过程时，处理针对紧急呼叫的待决请求的方法和用户设备(UE)。

在此的实施例的另一目的是提供一种通过中止与拒绝原因的应对相关联的过程来针对紧急呼叫处理请求和继续过程的方法。

在此的实施例的另一目的是提供一种通过对紧急呼叫提供最高优先级并终止与MT呼叫相对应的过程来针对紧急呼叫处理请求和继续过程的方法。

问题的解决方案

鉴于前述，在此的实施例提供了一种在用户设备(UE)中处理针对紧急呼叫的请求的方法。该方法包括在接收到针对紧急呼叫的请求之后，进行忽略从网络接收到的拒绝原因和在为UE定义的呼叫优先级顺序中对紧急呼叫提供最高优先级中的至少一个。此外，该方法包括继续针对紧急呼叫的过程以处理该请求。

实施例还公开了用于处理针对紧急呼叫的请求的用户设备(UE)。此外，UE包括集成电路，集成电路进一步包括该电路内的至少一个处理器和具有计算机程序代码的至少一个存储器。此外，该至少一个存储器和该计算机程序代码与该至少一个处理器使得UE的控制平面(CP)在接收到针对紧急呼叫的请求之后，进行忽略从网络接收到的拒绝原因和在为UE定义的呼叫优先级顺序中对紧急呼叫提供最高优先级中的至少一个。此外，CP被配置为继续针对紧急呼叫的过程以处理该请求。

当结合以下描述和附图考虑时，将更好地认识和理解在此的实施例的这些和其他方面。然而，应当理解，以下描述在表示实施例及其许多具体细节的同时，通过说明而非限制的方式而被给出。在不脱离在此的实施例的精神的情况下，可以在在此的实施例的范围内进行许多改变和修改，并且在此的实施例包括所有这样的修改。

附图说明

在附图中图示了本发明的实施例，贯穿附图相同的参考字母表示各个附图中的相应部分。参考附图根据以下描述将更好地理解在此的实施例，附图中：

图1图示了根据如在此公开的实施例的用于处理针对紧急呼叫的请求的用户设备(UE)的多个组件；

图2图示了根据如在此公开的实施例的用于通过忽略UE从网络接收到的拒绝原因来继续针对紧急呼叫的过程的示例序列图；

图3图示了根据如在此公开的实施例的用于通过在为UE定义的呼叫优先级顺序中对紧急呼叫提供最高优先级来继续针对紧急呼叫的过程的示例序列图；以及

图4是图示根据如在此公开的实施例的当UE检测到拒绝原因或等待网络命令状态时处理针对紧急呼叫的请求的方法的流程图。

具体实施方式

参考在附图中图示并在以下描述中详述的非限制性实施例，更充分地解释在此的实施例及其各种特征和有利细节。省略对众所周知的组件和处理技术的描述，以免不必要地模糊在此的实施例。在此使用的示例仅旨在帮助理解可以实践在此的实施例的方式，并且进一步使得本领域技术人员能够实践在此的实施例。因此，示例不应被解释为限制在此的实施例的范围。

在此的实施例实现用于当UE从网络接收到拒绝原因或者UE进行与移动终接(MT)呼叫相对应的过程时处理针对紧急呼叫的请求的方法和用户设备(UE)。UE可以根据第三代合作伙伴计划(3GPP)的规范24.301和/或规范24.008中指定的过程从网络接收拒绝原因。在实施例中，在这样的情况下，该方法包括通过忽略拒绝原因来处理针对紧急呼叫接收到的请求。此外，该方法包括中止与拒绝原因的应对相关联的过程，以便继续紧急呼叫。因此，该方法减少紧急呼叫延迟或紧急呼叫失败。

在实施例中，紧急呼叫可以是电路交换(CS)呼叫或分组交换紧急呼叫，并且被相应地应对。

在实施例中，用于当从网络接收到拒绝原因时应对待决紧急呼叫请求而定义的UE动作可以同样地应用于接收到的正常呼叫请求(例如，电路交换回落(CSFB)呼叫请求)。因此，增加正常呼叫成功率。

由于UE进行的与移动终接(MT)呼叫相对应的过程，因此UE可以检测到等待网络命令状态。在实施例中，在针对紧急呼叫的请求正在待决并且UE检测到等待网络命令状态的这样的情况下，该方法包括对紧急呼叫提供最高优先级并且终止与MT呼叫相对应的过程。此外，该方法包括继续与紧急呼叫相关联的过程。

因此，该方法包括以紧急呼叫、高优先级接入、MT呼叫和移动始发(MO)呼叫的降序的优先级顺序来定义在UE中的呼叫优先级顺序。

在实施例中，UE是移动电话、平板、个人数字助理、膝上型计算机、可穿戴设备和能够进行无线移动通信的任何其他电子设备。

在实施例中，网络可以是通用移动电信系统(UMTS)、长期演进(LTE)、先进LTE、GSM EDGE无线电接入网络(GERAN)、先进UMTS陆地无线电接入网络(UTRAN)等等。

现在参考附图，并且更具体地参考图1至图4，其中相似的参考标记贯穿附图一致地表示相应特征，它们是所示实施例。

图1图示了根据如在此公开的实施例的用于处理针对紧急呼叫的请求的用户设备(UE)的多个组件。

参考图1，根据本主题的实施例图示了UE 100。在实施例中，UE 100可以包括至少一个处理器102、输入/输出(I/O)接口104(在此为可配置用户接口)、存储器106等等。该至少一个处理器102可以实现为一个或多个微处理器、微计算机、微控制器、数字信号处理器、中央处理单元、状态机、逻辑电路和/或基于操作指令操纵信号的任何设备。除了其他能力，该至少一个处理器102被配置为获取和执行存储在存储器106中的计算机可读指令。

I/O接口104可以包括各种软件和硬件接口，例如，网络接口、图形用户接口等等。I/O接口104可以允许UE 100与其他设备进行通信。I/O接口104可以促进各种各样的网络和协议类型内的多种通信，包括有线网络，例如局域网(LAN)、电缆等，以及无线网络，诸如无线局域网(WLAN)、蜂窝、设备到设备(D2D)通信网络、Wi-Fi网络等等。

模块108包括进行特定任务、功能或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。在一个实现方式中，模块108可以包括通信协议层(CP 110)，通信协议层(CP 110)包括授权管理消息(EMM)模块和应用协议层(AP 112)。

在实施例中，当CP 110忙于进行诸如跟踪区更新(TAU)请求、区域区更新(RAU)请求、位置区更新(RAU)请求等等的特定过程时，CP 110可以从AP 112接收针对紧急呼叫的请求。在从网络接收到拒绝原因并且针对紧急呼叫的请求正在待决的这样的情况下，CP 110可以被配置为中止与拒绝原因的应对相关联的过程。此外，CP 110可以被配置为继续针对建立紧急呼叫的过程并且成功地处理接收到的针对紧急呼叫的请求。以示例顺序图和结合图2的示例情况来解释实施例。

在实施例中，CP 100可以被配置为当在正常呼叫请求正在待决而从网络接收到拒绝原因时，应用用于处理待决紧急呼叫请求所定义的动作，以处理正常呼叫请求。因此，提高正常呼叫成功率。

在实施例中，当CP 110忙于进行针对MT呼叫的过程时，CP 110可以接收针对紧急呼叫的请求。因此，当接收到针对紧急呼叫的请求时，CP 110可以识别UE 100处于等待命令状态，具有根据3GPP标准中的规范而发起的定时器T3240。在UE 100处于等待命令状态具有发起的定时器3240并且针对紧急呼叫的请求正在待决的这样的情况下，CP 110可以被配置为停止定时器T3240并终止针对MT呼叫的过程。此外，CP 110可以被配置为对紧急呼叫提供最高优先级，并继续针对建立紧急呼叫的过程。以结合图3的示例序列图来解释实施例。因此，以紧急呼叫、高优先级接入、MT呼叫和移动始发(MO)呼叫的降序的优先级顺序来定义UE 100中的呼叫优先级顺序。

模块108可以包括补充UE 100的应用和功能的程序或编码指令。除了其他事物，数据112用作用于存储由一个或多个模块108处理、接收和生成的数据的储存库。此外，UE 100的其他组件和模块的名称是说明性的，并且不需要被解释为限制。

图2图示了根据如在此公开的实施例的用于通过忽略UE从网络202接收到的拒绝原因来继续针对紧急呼叫的过程的示例序列200图。在实施例中，UE 100与网络202进行通信。UE 100的CP 110发送(204)TAU请求，并从网络202接收(208)TAU拒绝原因。根据规范24.301，TAU拒绝原因可以是拒绝原因#9、#10、#140等等。然而，由于接收到的(206)紧急呼叫请求正在待决，因此CP 110忽略(210)拒绝原因并继续针对紧急呼叫的过程。此外，CP 110发起(212)紧急呼叫过程以处理针对紧急呼叫的请求。

下面提供接收到特定过程拒绝并且UE 100的CP 110可以被配置为针对每个示例情况应对拒绝原因以继续紧急呼叫过程的多个示例情况。

情况1：如果特定过程(例如，组合TAU或组合RAU)成功，但是仅针对“演进分组服务(EPS)服务”或“PS服务”，并且CS注册被拒绝。例如，拒绝原因诸如#16(MSC暂时不可达)；或者#17(网络故障)，如规范24.008和24.301所指定的。在这样的情况下，如果CS紧急呼叫正在待决，则UE 100(CP 110)可以被配置为继续进行适当的MM和CC过程以发起呼叫建立过程。

情况2：如果当接收到特定过程拒绝或者特定过程面临如24.008或24.301中指定的异常情况并且UE 100在LTE RAT中时CS紧急呼叫正在待决，则UE 100(CP 110)可以被配置为选择2G/3G RAT并且继续进行适当的MM和CC过程以发起CS紧急呼叫。

情况3：如果当接收到特定过程拒绝或者特定过程面临如24.008或24.301中指定的异常情况并且UE 100在UMTS或GSM RAT中时CS紧急呼叫正在待决，则UE 100(CP 110)可以被配置为继续进行适当的MM和CC过程以发起CS紧急呼叫。

情况4：如果当接收到特定过程拒绝或者特定过程面临如24.008或24.301中指定的异常情况时分组交换(PS)紧急呼叫正在待决，则UE 100(CP 110)可以被配置为发起分组数据协议(PDP)激活过程或者紧急附着以建立紧急呼叫。

情况5：在实施例中，每当接收到具有原因#9、#10或#40的特定过程拒绝(例如，TAU拒绝)并且如果CS紧急呼叫正在待决，则UE 100代替进行附着过程可以被配置为尝试选择GERAN或UMTS陆地无线电接入网络(UTRAN)无线电接入技术，并且继续进行适当的MM和CC特定过程。

图3图示了根据如在此公开的实施例的用于通过在为UE定义的呼叫优先级顺序中对紧急呼叫提供最高优先级来继续针对紧急呼叫的过程的示例序列300图。在实施例中，UE 100与网络202进行通信。

CP 110接收(302)针对MT呼叫的寻呼。CP 100发送(304)对接收到的寻呼的寻呼响应。根据3GPP标准，CP 110将UE 110的状态设置为等待网络命令状态，并且启动(306)T3240定时器。CP 110接收(308)针对紧急呼叫的请求。因此，在这样的情况下，在MT呼叫与紧急呼叫(也称为MO紧急呼叫)之间存在冲突。由于紧急呼叫请求正在待决，因此CP 110停止(310)定时器T3240并且继续针对紧急呼叫的过程。因此，CP 110对紧急呼叫提供最高优先级，并且终止与MT呼叫相对应的过程。

此外，CP 110发起(312)紧急呼叫过程以处理针对紧急呼叫的请求。

图4是图示根据如在此公开的实施例的当UE检测到拒绝原因或等待网络命令状态时处理针对紧急呼叫的请求的方法400的流程图。在步骤402，方法400包括允许CP 110检测由CP接收到的呼叫请求是针对紧急呼叫。在步骤402，方法400包括允许CP 110通过进行一个或多个动作来继续针对紧急呼叫的过程。该动作包括忽略UE 100从网络202接收到的拒绝原因，或者在为UE 100定义的呼叫优先级顺序中对紧急呼叫提供最高优先级。忽略拒绝原因包括中止与拒绝原因的应对相关联的过程。可以由CP 110根据规范24.301中指定的过程来接收拒绝原因。此外，该方法包括以紧急呼叫、高优先级接入、MT呼叫和移动始发(MO)呼叫的降序的优先级来定义呼叫优先级顺序。对紧急呼叫提供最高优先级包括在进行与MT呼叫相对应的过程的同时，在UE 100的等待网络命令状态期间停止由UE 100发起的T3240定时器。如图2和图3的示例序列图中所解释的那样进行方法400的步骤，并且为了简洁而不重复。可以以所呈现的顺序、以不同的顺序或者同时地进行方法400中的各种动作。此外，在一些实施例中，可以省略图4中列出的一些动作。

在此公开的实施例可以通过在至少一个硬件设备上运行并且进行网络管理功能以控制网络元件的至少一个软件程序来实现。图1至图3中所示的网络元件包括可以是至少一个硬件设备或者硬件设备和软件模块的组合的块。

特定实施例的前述描述将完全揭示在此的实施例的一般性质，其他人可以通过应用当前知识，在不脱离一般概念的情况下容易地修改和/或适应这样的特定实施例的各种应用，并且因此，这样的适应和修改应当并且旨在在所公开的实施例的等同物的含义和范围内理解。应当理解，在此采用的措辞或术语是为了描述而不是限制的目的。

因此，尽管已经根据优选实施例描述了在此的实施例，但是本领域技术人员将认识到，可以利用在如在此描述的实施例的精神和范围内的修改来实践在此的实施例。