通话处理方法及装置

摘要

本申请提供一种通话处理方法及装置，应用于电子设备，被叫或发起主叫的电子设备在从5G网络重定向至LTE网络后，驻留在LTE网络，所述方法包括：响应于接收到非接入层安全模式命令消息，发送非接入层安全命令完成消息，响应于再次接收到非接入层安全模式命令消息，发送非接入层安全命令完成消息，响应于接收到接入层安全模式命令流程的触发消息，进行完整性保护检查，在完整性保护检查通过后，成功建立通话。可见，虽然重发了非接入层安全命令完成消息，但完整性保护还是可以通过，并成功建立通话，所以，能够提高EPS FB中重定向后通话建立的成功率。

权利要求

1.一种通话处理方法，其特征在于，应用于电子设备，被叫或发起主叫的所述电子设备在从5G网络重定向至LTE网络后，驻留在所述LTE网络，所述方法包括：响应于接收到非接入层安全模式命令消息，发送非接入层安全命令完成消息；

响应于再次接收到非接入层安全模式命令消息，发送非接入层安全命令完成消息；

响应于接收到携带第一参数的接入层安全模式命令流程的触发消息，基于所述第一参数、所述电子设备记录的非接入层消息计数以及重复发送非接入层安全命令完成消息的次数，进行完整性保护检查，所述第一参数与核心网记录的非接入层消息计数相关；

在完整性保护检查通过后，成功建立通话。

2.根据权利要求1所述的方法，其特征在于，所述基于所述第一参数、所述电子设备记录的非接入层消息计数以及重复发送非接入层安全命令完成消息的次数，进行完整性保护检查，包括：在完整性保护检查失败后，将所述电子设备记录的非接入层消息计数从第一数值减小至第二数值，所述第二数值表示所述重复发送非接入层安全命令完成消息的次数；

基于所述第一参数以及所述第二数值进行完整性保护检查。

3.根据权利要求2所述的方法，其特征在于，所述将所述电子设备记录的非接入层消息计数从第一数值减小至第二数值，包括：响应于第一完整性消息鉴权码的数值与第二完整性消息鉴权码的数值不一致，将所述非接入层消息计数的数值从所述第一数值减小至所述第二数值，所述第一完整性消息鉴权码的数值基于所述电子设备记录的非接入层消息计数获得，所述第二完整性消息鉴权码的数值基于所述第一参数获得。

4.根据权利要求2或3所述的方法，其特征在于，还包括：记录所述重复发送非接入层安全命令完成消息的次数；

所述将非接入层消息计数从第一数值减小至第二数值，包括：响应于所述次数大于0，将所述非接入层消息计数从所述第一数值减小至所述第二数值。

5.一种通话处理方法，其特征在于，应用于核心网设备，所述核心网设备触发电子设备从5G网络重定向至LTE网络，所述方法包括：响应于接收到所述电子设备发送的跟踪区域更新请求消息，发送非接入层安全模式命令消息；

响应于没有接收到非接入层安全命令完成消息，再次发送非接入层安全模式命令消息；

接收非接入层安全命令完成消息；

在发送初始上下文建立请求消息之后，再次接收非接入层安全命令完成消息；

响应于接收到初始上下文建立成功消息，成功建立所述电子设备与对端设备的通话。

6.一种通话处理方法，其特征在于，应用于核心网设备，所述核心网设备触发电子设备从5G网络重定向至LTE网络，所述方法包括：响应于接收到所述电子设备发送的跟踪区域更新请求消息，发送非接入层安全模式命令消息；

响应于没有接收到非接入层安全命令完成消息，再次发送非接入层安全模式命令消息；

接收非接入层安全命令完成消息；

在发送初始上下文建立请求消息之后，再次接收非接入层安全命令完成消息；

接收初始上下文建立失败消息；

响应于再次接收到的跟踪区域更新请求消息，成功建立所述电子设备与对端设备的通话。

7.根据权利要求6所述的方法，其特征在于，在所述响应于再次接收到的跟踪区域更新请求消息，成功建立所述电子设备与对端设备的通话之前，还包括：响应于所述初始上下文建立失败消息，确定存在消息重传；

保留所述电子设备的上下文。

8.根据权利要求7所述的方法，其特征在于，所述保留所述电子设备的上下文，包括：响应于消息重传导致与所述电子设备记录的非接入层消息计数不一致，保留所述电子设备的上下文。

9.根据权利要求8所述的方法，其特征在于，确定所述消息重传导致与所述电子设备记录的非接入层消息计数不一致的流程，包括：获取所述初始上下文建立请求消息中携带的非接入层消息计数为第一数值；

获取最新的非接入层消息计数为第二数值，所述第一数值小于所述第二数值。

10.一种电子设备，其特征在于，包括：

存储器以及至少一个处理器；所述存储器用于存储应用程序，所述至少一个处理器用于执行所述应用程序，以实现权利要求1‑4任一项所述的通话处理方法。

11.一种核心网设备，其特征在于，包括：

存储器以及至少一个处理器；所述存储器用于存储应用程序，所述至少一个处理器用于执行所述应用程序，以实现权利要求5或6‑9任一项所述的通话处理方法。

12.一种计算机存储介质，用于存储计算机程序，计算机程序被执行时，用于实现权利要求1‑9任一项所述的通话处理方法。

说明书

通话处理方法及装置

[0001] 本申请要求于2021年12月22日提交中国专利局、申请号为202111583520.6、发明名称为“通话处理方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

[0002] 本申请涉及通信技术领域，尤其涉及一种通话处理方法及装置。

背景技术

[0003] 5G新无线(5G New Radio，5G NR)技术，简称NR，是逐渐大规模商用的通信技术。但目前的5G网络并不支持语音通话，因此手机驻留到NR网络后，如果手机发起主叫或者被叫，手机将从驻留的5G网络切换至长期演进(Long Term Evolution，LTE)网络(又称为4G网络)，在LTE网络执行通话业务，这种操作通常被称为紧急步骤回落(Emergency procedures Fallback，EPS FB)。

发明内容

[0004] 本申请提供了一种通话处理方法及装置，目的在于提高EPS FB中重定向后通话建立的成功率。

[0005] 为了实现上述目的，本申请提供了以下技术方案：

[0006] 本申请的第一方面提供一种通话处理方法，应用于电子设备，被叫或发起主叫的电子设备在从5G网络重定向至LTE网络后，驻留在LTE网络，所述方法包括：响应于接收到非接入层安全模式命令消息，发送非接入层安全命令完成消息，响应于再次接收到非接入层安全模式命令消息，发送非接入层安全命令完成消息，响应于接收到接入层安全模式命令流程的触发消息，进行完整性保护检查，在完整性保护检查通过后，成功建立通话。可见，虽然重发了非接入层安全命令完成消息，但完整性保护还是可以通过，并成功建立通话，所以，能够提高EPS FB中重定向后通话建立的成功率。

[0007] 在一些实现方式中，接入层安全模式命令流程的触发消息携带第一参数，第一参数与核心网记录的非接入层消息计数相关。进行完整性保护检查包括：基于第一参数、电子设备记录的非接入层消息计数以及重复发送非接入层安全命令完成消息的次数，进行完整性保护检查。因为将重复发送非接入层安全命令完成消息的次数作为依据，所以，能够提高完整性保护检查通话的可能性。

[0008] 在一些实现方式中，基于第一参数、电子设备记录的非接入层消息的条数以及重复发送非接入层安全命令完成消息的次数，进行完整性保护检查，包括：在完整性保护检查失败后，将电子设备记录的非接入层消息计数从第一数值减小至第二数值，第二数值表示重复发送非接入层安全命令完成消息的次数，基于第一参数以及第二数值进行完整性保护检查。将电子设备记录的非接入层消息计数从第一数值减小至表示重复发送非接入层安全命令完成消息的次数的第二数值，所以，能够消除因重复发送非接入层安全命令完成消息而导致的完整性保护检查不通过的可能性。

[0009] 在一些实现方式中，将电子设备记录的非接入层消息计数从第一数值减小至第二数值，包括：响应于第一完整性消息鉴权码的数值与第二完整性消息鉴权码的数值不一致，将非接入层消息计数的数值从第一数值减小至第二数值，第一完整性消息鉴权码的数值基于电子设备记录的非接入层消息计数获得，第二完整性消息鉴权码的数值基于第一参数获得。可见，从完整性保护检查的具体方式入手，消除因重复发送非接入层安全命令完成消息而导致的完整性保护检查不通过的可能性，因此具有更高的可实施性以及兼容性。

[0010] 在一些实现方式中，还包括：记录重复发送非接入层安全命令完成消息的次数，将非接入层消息计数从第一数值减小至第二数值，包括：响应于次数大于0，将非接入层消息计数从第一数值减小至第二数值。次数大于0说明存在重复发送非接入层安全命令完成消息的情况，从而避免对因其它原因导致完整性保护检查不通过进行干扰的可能性。

[0011] 本申请的第二方面提供一种通话处理方法，应用于核心网设备，核心网设备触发电子设备从5G网络重定向至LTE网络，所述方法包括：响应于接收到电子设备发送的跟踪区域更新请求消息，发送非接入层安全模式命令消息，响应于没有接收到非接入层安全命令完成消息，再次发送非接入层安全模式命令消息，接收非接入层安全命令完成消息，在发送初始上下文建立请求消息之后，再次接收非接入层安全命令完成消息，响应于初始上下文建立成功消息，成功建立电子设备与对端设备的通话。可见，在发送初始上下文建立请求消息之后，再次接收非接入层安全命令完成消息的情况下，还能够成功建立电子设备与对端设备的通话，从而能够提高EPS FB中重定向后通话建立的成功率。

[0012] 本申请的第三方面提供一种通话处理方法，应用于核心网设备，核心网设备触发电子设备从5G网络重定向至LTE网络，所述方法包括：响应于接收到电子设备发送的跟踪区域更新请求消息，发送非接入层安全模式命令消息，响应于没有接收到非接入层安全命令完成消息，再次发送非接入层安全模式命令消息，接收非接入层安全命令完成消息，在发送初始上下文建立请求消息之后，再次接收非接入层安全命令完成消息，接收初始上下文建立失败消息，响应于再次接收到的跟踪区域更新请求消息，成功建立电子设备与对端设备的通话。可见，在发送初始上下文建立请求消息之后，再次接收非接入层安全命令完成消息且接收到初始上下文建立失败消息的情况下，还能够成功建立电子设备与对端设备的通话，从而能够提高EPS FB中重定向后通话建立的成功率。

[0013] 在一些实现方式中，在响应于再次接收到的跟踪区域更新请求消息，成功建立电子设备与对端设备的通话之前，还包括：响应于初始上下文建立失败消息，确定存在消息重传，保留电子设备的上下文。在确定存在消息重传的情况下，说明有可能因为消息重传而删除电子设备的上下文，导致无法成功建立电子设备的通话，所以，保留电子设备的上下文，以提高在存在消息重传的情况下通话成功建立的可能性。

[0014] 在一些实现方式中，保留电子设备的上下文，包括：响应于消息重传导致与电子设备记录的非接入层消息计数不一致，保留电子设备的上下文。将消息重传导致与电子设备记录的非接入层消息计数不一致作为保留上下文的依据，避免对因其它原因导致通话不能成功建立的情况进行干扰的可能性。

[0015] 在一些实现方式中，确定消息重传导致与电子设备记录的非接入层消息计数不一致的流程，包括：获取初始上下文建立请求消息中携带的非接入层消息计数为第一数值，获取最新的非接入层消息计数为第二数值，第一数值小于第二数值，以提供可操作性较高的判断消息重传的方式。

[0016] 本申请的第四方面提一种电子设备，包括：存储器以及至少一个处理器；所述存储器用于存储应用程序，所述至少一个处理器用于执行所述应用程序，以实现本申请的第一方面提供的通话处理方法。

[0017] 本申请的第五方面提供了一种核心网设备，包括：存储器以及至少一个处理器；所述存储器用于存储应用程序，所述至少一个处理器用于执行所述应用程序，以实现本申请的第二方面或第三方面提供的通话处理方法。

[0018] 本申请的第六方面提供了一种计算机存储介质，用于存储计算机程序，计算机程序被执行时，具体用于实现第一方面、第二方面以及第三方面提供的通话处理方法。

[0019] 本申请的第七方面提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行第一方面、第二方面以及第三方面提供的通话处理方法。

附图说明

[0020] 图1a为5G网络和4G网络覆盖同一区域的示例图；

[0021] 图1b为手机在4G网络覆盖下通话的示例图；

[0022] 图2为从5G网络回落4G网络后没有成功建立通话的流程图；

[0023] 图3为本申请实施例公开的一种通话处理方法的流程图；

[0024] 图4为本申请实施例公开的又一种通话处理方法的流程图；

[0025] 图5为本申请实施例公开的电子设备的硬件结构示例图；

[0026] 图6为本申请实施例公开的电子设备的软件框架的示例图。

具体实施方式

[0027] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请实施例中，“一个或多个”是指一个、两个或两个以上；“和/或”，描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

[0028] 在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

[0029] 本申请实施例涉及的多个，是指大于或等于两个。需要说明的是，在本申请实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

[0030] 图1a中，用户没有拨打电话或接听电话，在此情况下，手机通常驻留在5G网络的小区(cell)中(当然也可以驻留在LTE网络的小区中)。图1a中，手机与5G基站连接，表示手机通常驻留在5G网络的小区中。如果用户要拨打电话或接听电话，如图1b所示，需要将手机切换至LTE网络，即手机只能在LTE网络中拨打电话或接听电话。图1b中，手机与4G基站连接，表示手机驻留在4G网络的小区中。

[0031] 但发明人在研究的过程中发现，EPS FB流程中在重定向后，通话的成功率有待提高。

[0032] 以图1b为例，手机主叫情况下，用户拨出电话后，通话建立不成功，用户可能听到提示音“您拨打的用户正在通话中”，假设用户没有携带手机进行较大距离的移动且下一通呼叫与上一通呼叫不超过一定时长(如24小时)，再下一通呼出后通话还是建立不成功，并听到语音提示“您拨打的用户暂时无法接通”。

[0033] 手机被叫的情况也类似，对端手机与本端手机在本通电话以及下一通电话均不能成功建立通话流程，对方手机发出“您拨打的用户正在通话中”或者“您拨打的用户暂时无法接通”的提示音。

[0034] 下面将结合图2，对EPS FB中重定向后通话的成功率不高的原因进行分析：

[0035] 图2以核心网接收到移动台被呼(Mobile Terminated Call，MT call)消息触发EPS FB的场景为例，可以理解的是，核心网接收到移动台始呼(Mobile Originated，MO)消息触发EPS FB的场景类似。

[0036] 图2中包括以下步骤：

[0037] S101、核心网在接收到移动台被呼(Mobile Terminated Call，MT call)消息或移动台始呼(Mobile Originated Call，MO Call)消息后，向NR转发MT call消息或MO Call消息。

[0038] 在本申请的实施例以及附图中，NR是指5G网络的无线接入装置。

[0039] S102、NR响应于MT call消息或MO消息，向用户设备(User Equipment，UE)发送invite消息。

[0040] invite消息通常携带有消息体，消息体包含主叫方的媒体信息，消息体还可以包含其它会话信息，例如资源列表。

[0041] S103、UE接收到invite消息后，分别向NR发送应答消息100Trying和会话_进程(SESSION_PROGRESS)消息(183)。

[0042] S104、NR将应答消息100Trying和SESSION_PROGRESS消息(183)发送到核心网。

[0043] S105、核心网响应于应答消息100Trying和SESSION_PROGRESS消息(183)，向NR发送触发EPS FB的消息。

[0044] 在某些实现方式中，核心网和NR之间进行消息交互来确认开启EPS FB，S105为消息交互的触发步骤，消息交互的具体实现方式，可参见通信协议，这里不再赘述。

[0045] S106、NR向UE发送重定向消息。

[0046] 重定向消息用于将UE重定向到LTE网络，重定向消息包括LTE网络的频点标识，本实施例中频点标识以频点号为例。

[0047] S107、UE使用LTE的频点号搜到合适的LTE小区。

[0048] 合适的LTE小区的定义以及具体的搜索方式可参见通信协议，这里不再赘述。

[0049] S108、UE向LTE发送跟踪区域更新请求消息(Tracking Area Update Request Mag)。

[0050] 也就是说，UE在驻留到LTE网络的小区后，发起跟踪区域更新(Tracking Area Update，TAU)流程。

[0051] 可以理解的是，本申请的实施例中所述的LTE可以为LTE网络中的无线设备，例如基站。

[0052] S109、LTE向核心网发送跟踪区域更新请求消息。

[0053] 本流程中，假设在此步骤之前，UE与核心网的交互正常，在此情况下，UE与核心网协商并记录的非接入层(non‑access stratum，NAS)计数(COUNT)一致，记为N，以图2中虚线处的NAS COUNT＝N表示。

[0054] 按照通信协议，核心网在接收到一条NAS消息后，核心网将本地记录的NAS COUNT加1，UE在接收到一条NAS消息并且发出该条NAS消息的反馈消息后，UE将本地记录的NAS COUNT加1。

[0055] S110、核心网向LTE发送NAS安全模式命令消息(Security Mode Command Msg)。

[0056] 也就是说，网络收到TAU请求后，发起NAS安全模式命令(Security Mode Command，SMC)流程。

[0057] 为了便于理解，图2中，将本步骤发送的安全模式命令消息记为第一条NAS安全模式命令消息。

[0058] S111、LTE向UE发送NAS安全模式命令消息。

[0059] S112、UE向LTE发送安全命令完成消息(Security Command Complete Msg)。

[0060] 相应的，图2中，将本步骤发送的NAS安全命令完成消息记为第一条NAS安全命令完成消息。

[0061] S113、UE将NAS COUNT加1，即NAS COUNT更新为N+1。

[0062] 可以理解的是，基站在接收到第一条NAS安全命令完成消息后，向核心网发送第一条NAS安全命令完成消息。在一些实现方式中，由于基站异常或者上行突发干扰等原因，导致NAS安全命令完成消息没有及时传输至核心网。在此情况下，核心网如果在规定时间内(如1秒)没有接收到NAS安全命令完成消息或者NAS安全命令拒绝消息(Security command Reject Msg)，则重传NAS安全模式命令消息，本流程中，假设核心网重传了一次，如S114。

[0063] S114、核心网向通过LTE再次向UE发送NAS安全模式命令消息。

[0064] 图2中，将本步骤发送的NAS安全模式命令消息记为第二条NAS安全模式命令消息。

[0065] 图2中，假设在核心网发出第二条NAS安全模式命令消息后，接收到第一条NAS安全命令完成消息，如S115。

[0066] S115、核心网接收到第一条NAS安全命令完成消息。

[0067] 可以理解的是，本步骤接收到的NAS安全命令完成消息为UE在S112发出。

[0068] S116、核心网将NAS COUNT加1，即NAS COUNT更新为N+1。

[0069] 按照通信协议，核心网接收到NAS安全命令完成消息，则执行后续流程，如S117。

[0070] S117、核心网向LTE发送TAU接受消息(TAU Accept)以及初始上下文建立请求(Initial Context Setup Request)消息。

[0071] 在某些实现方式中，初始上下文建立请求携带核心网的NAS COUNT，如前所述，核心网的NAS COUNT为N+1。

[0072] 图2中，假设核心网在执行S117之后，接收到第二条NAS安全命令完成消息，即如S118。

[0073] S118、核心网通过LTE接收UE发送的第二条NAS安全模式完成消息。

[0074] 图2中，将本步骤发送的NAS安全命令完成消息记为第二条NAS安全命令完成消息。

[0075] 可以理解的是，UE在S114接收到第二条NAS安全命令请求消息后，在S114‑S118之间的任意时机，发送第二条NAS安全模式完成消息。

[0076] S119、UE将NAS COUNT加1，即NAS COUNT更新为N+2。

[0077] S120、LTE向UE发送接入层(access stratum，AS)SMC流程的触发消息，消息中携带核心网的NAS COUNT为N+1。

[0078] S121、UE进行的完整性保护检查失败。

[0079] 可以理解的是，完整性保护检查需要使用UE确定本地的NAS COUNT计算得到完整性消息鉴权码(简称为MAC‑I)的数值(记为MAC‑I1)，以相同的算法使用核心网的NAS COUNT计算MAC‑I(记为MAC‑I2)，计算得到的数值相同，则完整性保护检查通过，否者完整性保护检查失败。从图2可以看出，UE确定的NAS COUNT数值为N+2，核心网发送的NAS COUNT数值为N+1，两者数值不一致，则导致MAC‑I1不等于MAC‑I2，则完整性保护检查失败。

[0080] S122、UE向LTE发送AS安全模式失败(Security Mode Failure)消息。

[0081] S123、LTE向核心网发送初始上下文建立失败(Initial Context Setup Failure)消息。

[0082] S124、核心网释放UE的上下文(Context)。

[0083] 因为上下文被释放，所以UE需要重新搜索小区并发起TAU流程，如以下步骤：

[0084] S125、UE向LTE发送跟踪区域更新请求消息。

[0085] S126、LTE向核心网发送跟踪区域更新请求消息。

[0086] 核心网由于释放了UE的上下文，故按照通信协议执行以下步骤：

[0087] S127、核心网向LTE发送TAU拒绝(Reject)消息，原因值为#10(隐私detach)。

[0088] #10为原因的代码。

[0089] S128、LTE向UE发送TAU拒绝消息，原因值为#10。

[0090] UE收到这个原因值后，按照协议规定，需要重新附着(attach)，而非建立通话，因此，本通呼叫失败。

[0091] 从图2可以看出，导致EPS FB建立通话失败的原因在于：在EPS FB流程中的重定向后，由于UE与LTE之间的网络不佳等原因，导致核心网没有及时收到UE反馈的安全命令完成消息，所以重发安全模式命令消息(如S114)，即发送了两条NAS安全模式命令消息，所以UE的NAS COUNT的数值增加了两次，但是，核心网在向基站发送初始上下文建立请求消息(如S117)之前，仅接收到一条NAS安全命令完成消息(如S115及S118)，即核心网的NAS COUNT的数值增加了一次，因此，导致核心网发出的NAS COUNT的数值，与UE记录的NAS COUNT的数值不一致，所以UE确认完整性保护检查失败而无法建立通话流程。

[0092] 为了解决上述问题，本申请实施例提供一种通话处理方法，目的在于提高EPS FB中重定向后建立通话的成功率。

[0093] 可以理解的是，通话成功是指，无论UE是主叫还是被叫，均能都与对端UE成功建立通话。

[0094] 本申请的以下实施例应用的场景为：电子设备可接入5G网络或LTE网络。在电子设备驻留在5G的SA网络的情况下，被对端电子设备呼叫或向对端电子设备发起呼叫。5G网络可以为独立组网(Standalone，SA)，也可以为非独立组网(None‑Standalone，NSA)。

[0095] 可以理解的是，从图2可以看出，因为EPS FB之后，本申请实施例涉及的步骤，不在由NR参与，所以在以下实施例的附图中，不再画出NR，并且，在以下实施例的附图中所述的“基站”指LTE网络的无线设备。

[0096] 图3为本申请实施例公开的一种通话处理方法的流程，包括以下步骤：

[0097] S201、核心网响应于接收到MT Call消息或MO Call消息，触发启动EPS FB，并且UE驻留在LTE网络。

[0098] S201为对S101‑S107的概括，即S201的具体实现方式可参见S101‑S107，这里不再赘述。

[0099] S202、UE向LTE发送跟踪区域更新请求消息。

[0100] S203、UE启动消息重传识别，并记录重传次数。

[0101] 可以理解的是，可以建立用于记录消息重传次数的进程或线程，以启动消息重传识别。

[0102] 在某些实现方式中，重传次数的初始值为0，UE缓存最近接收的一条NAS安全模式命令消(记为消息i)，在又接收到一条NAS安全模式命令消息(记为消息i+1)后，对比消息i和消息i+1，两者相同，则识别到重传的消息，将重传次数K加1，两者不同，则K保持不变。

[0103] 在另一些实现方式中，UE通过识别NAS安全命令完成(Security command complete)消息是否未成功发送，来识别消息重传。例如，获得依次经过分组数据汇聚协议(Packet Data Convergence Protocol，PDCP)层和无线链路控制层(Radio Link Control，RLC)层的NAS安全命令完成消息数据包的编号，并判断是否接收到基站对该编号的数据包的响应消息，如果是，则说明该编号的数据包被基站接收，即被成功发送。如果否，则说明该编号的数据包没有被基站接收，即没有成功发送，也不会被核心网接收到，因此按照通信协议，核心网会重发NAS安全模式命令消息，因此，在判断结果为否的情况下，确认识别到消息重传，将重传次数K加1。可以理解的是，PDCP和RLC仅为举例而不作为限定。

[0104] 可以理解的是，还可以为消息重传识别设置执行区间，即在UE发出跟踪区域更新请求消息之后，以及收到TAU ACCEPT消息之前，进行消息重传识别，而在其它时间不进行消息重传识别，以节省UE的资源。

[0105] S204、基站向核心网发送跟踪区域更新请求消息。

[0106] 可以理解的是，S203和S204的执行顺序不做限定。

[0107] 本实施例中，假设在以下步骤之前，UE与核心网的交互正常，在此情况下，UE与核心网协商并记录的非接入层(non‑access stratum，NAS)计数(COUNT)一致，记为N，以图3中虚线处的NAS COUNT＝N表示。

[0108] S205、核心网经由基站向UE发送第一条NAS安全模式命令消息。

[0109] S206、UE向基站发送第一条NAS安全命令完成消息。

[0110] S207、UE将NAS COUNT加1，即NAS COUNT更新为N+1。

[0111] 本实施例中，假设核心网在规定时长(如1秒)未收到UE反馈的NAS安全命令完成消息或者NAS安全命令拒绝消息，则执行S208。

[0112] S208、核心网经由基站向UE发送第二条NAS安全模式命令消息。

[0113] S209、UE经由基站向核心网发送第二条NAS安全命令完成消息。

[0114] 本实施例中，假设第二条NAS安全命令完成消息在S214之后收到。

[0115] S210、UE将NAS COUNT加1，即NAS COUNT更新为N+2。

[0116] 可以理解的是，第二条NAS安全命令完成消息即为UE重传的消息，因此UE识别到消息重传，执行S211。

[0117] S211、UE记录重传次数K＝1。

[0118] 假设核心网在S208之后，接收到第一条NAS安全命令完成消息，即执行以下流程：

[0119] S212、核心网接收到第一条NAS安全命令完成消息。

[0120] S213、核心网将NAS COUNT加1，即NAS COUNT更新为N+1。

[0121] S214、核心网向基站发送TAU接受消息(TAU Accept)以及初始上下文建立请求(Initial Context Setup Request)消息。

[0122] 初始上下文建立请求消息中包括核心网的NAS COUNT的数值N+1。

[0123] S215、基站使用核心网的NAS COUNT的数值N+1，计算核心网的MAC‑I(简称为MAC‑I2)。

[0124] S216、基站向UE发送接入层(access stratum，AS)SMC流程的触发消息，消息中携带核心网的MAC‑I2。

[0125] UE响应于SMC流程的触发消息，进行完整性保护检查，完整性保护检查的步骤至少包括S217，还可能包括的步骤可以参见通信协议，这里不再赘述。

[0126] S217、UE使用UE记录的NAS COUNT，计算UE的MAC‑I(简称为MAC‑I1)。

[0127] MAC‑I为通信协议规定的AS SMC流程中传输的参数，因此具体格式可以参见通信协议。

[0128] S218、UE判断MAC‑I1与MAC‑I2是否不一致，若是，执行S219，若否，执行S221。

[0129] 在另一种实现方式中，基站不计算MAC‑I2，MAC‑I2由UE计算，即基站向UE发送的接入层(access stratum，AS)SMC流程的触发消息中，携带核心网的NAS COUNT的数值(N+1)，则S217中UE还需要计算MAC‑I2。

[0130] S219、UE判断K是否大于0，若是，执行S220，若否，执行S122以及后续流程。

[0131] K值不大于0，为没有识别到消息重传的情况，说明完整性保护检查失败并非消息重传导致的，所以，执行原有流程。

[0132] S220、UE将UE记录的NAS COUNT的数值减1后，再执行S217‑S218。

[0133] 可以理解的是，减1仅为示例，减去的数值可以预先设置，减去1的情况下，可能需要迭代多次，但容错性较高，而减去K的情况下，能够减少迭代次数。

[0134] 可以理解的是，如果完整性保护检查失败为消息重传导致的，则至少执行一次迭代后，MAC‑I1与MAC‑I2一致，则UE可执行以下步骤：

[0135] S221、UE向基站发送AS安全模式完成消息。

[0136] 按照通信协议，基站在接收到AS安全模式完成消息后，执行S222和S223。

[0137] S222、基站向UE发送TAU接受(Accept)消息。

[0138] S223、基站向核心网发送初始上下文建立成功消息。

[0139] S224、UE在LTE上与对端设备成功建立通话流程。

[0140] 从图3所示的流程可以看出，在UE确定因消息重传而导致MAC‑I1与MAC‑I2不一致而导致完整性保护检查失败的情况下，将本地记录的NAS COUNT的数值减小，以降低因消息重传而导致的MAC‑I1与MAC‑I2不一致，从而提高通话成功建立的可能性。

[0141] 可以理解的是，因为依据某些通信协议，UE最新接收的消息会覆盖上一条接收的消息，所以，图3所示的流程中，UE启动对消息重发的识别并计数。在UE存储接收到的消息的情况下，还可以不启动对消息重发的识别和计数，而在S218之后，依据UE存储的接收到的消息，识别是否有重传的消息以及统计重传的消息的数量K。可见，图3所示的识别消息重传的方式仅为一种实现方式，而不作为限定。

[0142] 图4为本申请实施例公开的又一种通话处理方法的流程，包括以下步骤：

[0143] S301核心网响应于接收到MT Call消息或MO Call消息，触发启动EPS FB，并且UE驻留在LTE网络

[0144] S301可参见S201，这里不再赘述。S302、UE向LTE发送跟踪区域更新请求消息。

[0145] S303、基站向核心网发送跟踪区域更新请求消息。

[0146] 本实施例中，假设在以下步骤之前，UE与核心网的交互正常，在此情况下，UE与核心网协商并记录的非接入层(non‑access stratum，NAS)计数(COUNT)一致，记为N，以图4中虚线处的NAS COUNT＝N表示。

[0147] S304、核心网经由基站向UE发送第一条NAS安全模式命令消息。

[0148] S305、UE向基站发送第一条NAS安全命令完成消息。

[0149] S306、UE将NAS COUNT加1，即NAS COUNT更新为N+1。

[0150] 本实施例中，假设核心网在规定时长(如1秒)未收到UE反馈的NAS安全命令完成消息或者NAS安全命令拒绝消息，则执行S307。

[0151] S307、核心网经由基站向UE发送第二条NAS安全模式命令消息。

[0152] S308、UE向基站发送第二条NAS安全命令完成消息。

[0153] S309、UE将NAS COUNT加1，即NAS COUNT更新为N+2。

[0154] 本实施例中以S309之后，核心网收到第一条NAS安全命令完成消息为例，即执行S310以及后续步骤。

[0155] S310、核心网接收到第一条NAS安全命令完成消息。

[0156] S311、核心网将NAS COUNT加1，即NAS COUNT更新为N+1。

[0157] 可以理解的是，按照通信协议，S310触发S312。

[0158] S312、核心网向基站发送TAU接受消息(TAU Accept)以及初始上下文建立请求(Initial Context Setup Request)消息。初始上下文建立请求消息中包括核心网的NAS COUNT的数值N+1。S313、基站向UE发送接入层(access stratum，AS)SMC流程的触发消息，消息中携带核心网的NAS COUNT的数值N+1。

[0159] S314、UE确认MAC‑I1与MAC‑I2不一致，导致完整性保护检查失败。

[0160] 可以理解的是，MAC‑I1使用UE记录的NAS COUNT的数值N+2的数值计算得到，MAC‑I2使用核心网的NAS COUNT的数值N+1计算得到。因为核心网发送的NAS COUNT的数值与UE记录的NAS COUNT的数值不同，所以MAC‑I1与MAC‑I2不一致。

[0161] 在另一些实现方式中，MAC‑I2也可以由基站计算得到，并由基站携带在SMC流程的触发消息中发送至UE，UE直接使用即可，无需再计算，以节省UE的资源。

[0162] 本实施例中，假设核心网在S314之后接收到第二条NAS安全命令完成消息，即S315。

[0163] S315、核心网接收到第二条NAS安全命令完成消息。

[0164] S316、核心网将NAS COUNT加1，即NAS COUNT更新为N+2。

[0165] S317、UE向基站发送AS安全模式失败(Security Mode Failure)消息。

[0166] 可以理解的是，按照通信协议，UE响应于完整性保护检查失败，发出AS安全模式失败消息。S315‑S316与S317的执行顺序不做限定。

[0167] S318、基站向核心网发送初始上下文建立失败(Initial Context Setup Failure)消息。

[0168] S319、核心网判断是否存在消息重传，如果是，执行S320，如果否，执行S124以及后续流程(图3中未画出)。

[0169] 在某些实现方式中，核心网存储已发送的消息，因此核心网查询已发送的消息中是否存储在重传的消息，如果存在，则确定存在消息重传。

[0170] S320、核心网判断是否消息重传导致与UE的NAS COUNT数值不一致，若是，执行S321，若否，执行S124以及后续流程。

[0171] 在某些实现方式中，如果确定初始上下文建立请求消息中携带的NAS COUNT的数值，与最后一次更新(如S316)的NAS COUNT的数值不一致，则确定重传导致与UE的NAS COUNT数值不一致。

[0172] S321、核心网保留UE的上下文。

[0173] 可以理解的是，执行S321之后，说明即使UE的完整性保护检查失败，但核心网仍然保留UE的上下文信息，因此，在UE再次发起TAU流程并尝试建立通话的情况下，因为核心网保留了UE的上下文信息，所以很可能成功建立UE的通话。

[0174] 按照通信协议，UE在接收到AS安全模式失败消息后，重新发起TAU流程，即执行S322。

[0175] S322、UE经由基站向核心网发送跟踪区域更新请求消息。

[0176] 即UE重新发起跟踪区域更新请求。假设此时UE与基站之间的网络正常，则核心网发给UE NAS安全模式命令消息后，能够及时接收到UE发送的NAS安全命令完成消息，则核心网执行S323。

[0177] S323、核心网经由基站向UE发送跟踪区域更新接受消息。

[0178] S324、UE在LTE网络建立通话流程。

[0179] 图4所示的流程与图2不同的是，在核心网络侧执行提高通话流程成功建立的可能性的操作，从而可以节省UE的功耗。

[0180] 以上实施例所述的通话处理方法，均可以适用于手机，平板电脑，桌面型、膝上型、笔记本电脑，超级移动个人计算机(Ultra‑mobile Personal Computer，UMPC)，手持计算机，上网本，个人数字助理(Personal Digital Assistant，PDA)，可穿戴电子设备，智能手表等可支持呼叫的电子设备，前述提出的UE也属于该电子设备。

[0181] 图5为本申请实施例提供的一种电子设备的组成示例。以手机为例，电子设备300可以包括处理器310，外部存储器接口320，内部存储器321，显示屏330，摄像头340，天线1，天线2，移动通信模块350，以及无线通信模块360等。

[0182] 可以理解的是，本实施例示意的结构并不构成对该电子设备的具体限定。在另一些实施例中，该电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

[0183] 处理器310可以包括一个或多个处理单元，例如：处理器310可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural‑network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

[0184] 可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备300的结构限定。在本申请另一些实施例中，电子设备300也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

[0185] 外部存储器接口320可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口320与处理器310通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

[0186] 内部存储器321可以用于存储计算机可执行程序代码，可执行程序代码包括指令。处理器310通过运行存储在内部存储器321的指令，从而执行电子设备300的各种功能应用以及数据处理。内部存储器321可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器321可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器310通过运行存储在内部存储器321的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备的各种功能应用以及数据处理。

[0187] 电子设备通过GPU，显示屏330，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏330和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器310可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

[0188] 显示屏330用于显示图像，视频等。显示屏330包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light‑emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active‑matrix organic light emitting diode的，AMOLED)，柔性发光二极管(flex light‑emitting diode，FLED)，Miniled，MicroLed，Micro‑oled，量子点发光二极管(quantum dot light emitting diodes，QLED)等。在一些实施例中，电子设备可以包括1个或N个显示屏330，N为大于1的正整数。

[0189] 电子设备可以通过ISP，摄像头340，视频编解码器，GPU，显示屏330以及应用处理器等实现拍摄功能。

[0190] ISP用于处理摄像头340反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头340中。

[0191] 电子设备的无线通信功能可以通过天线1，天线2，移动通信模块350，无线通信模块360，调制解调处理器以及基带处理器等实现。

[0192] 天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

[0193] 移动通信模块350可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块350可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块350可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块350还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块350的至少部分功能模块可以被设置于处理器310中。在一些实施例中，移动通信模块350的至少部分功能模块可以与处理器310的至少部分模块被设置在同一个器件中。

[0194] 一些实施例中，电子设备通过移动通信模块350和天线1发起或接收的呼叫请求。

[0195] 无线通信模块360可以提供应用在电子设备上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi‑Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块360可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块360经由天线3接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器310。无线通信模块360还可以从处理器310接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

[0196] 电子设备300可以通过音频模块370，扬声器370A，受话器370B，麦克风370C，耳机接口370D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

[0197] 音频模块370用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块370还可以用于对音频信号编码和解码。在一些实施例中，音频模块370可以设置于处理器310中，或将音频模块370的部分功能模块设置于处理器310中。

[0198] 扬声器370A，也称“喇叭”，用于将音频电信号转换为声音信号。电子设备300可以通过扬声器370A收听音乐，或收听免提通话。

[0199] 受话器370B，也称“听筒”，用于将音频电信号转换成声音信号。当电子设备300接听电话或语音信息时，可以通过将受话器370B靠近人耳接听语音。

[0200] 麦克风370C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风370C发声，将声音信号输入到麦克风370C。电子设备300可以设置至少一个麦克风370C。在另一些实施例中，电子设备300可以设置两个麦克风370C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，电子设备300还可以设置三个，四个或更多麦克风370C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。

[0201] 耳机接口370D用于连接有线耳机。耳机接口370D可以是USB接口，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

[0202] 另外，在上述部件之上，运行有操作系统。例如iOS操作系统，Android操作系统，Windows操作系统等。在操作系统上可以安装运行应用程序。

[0203] 图6是本申请实施例的电子设备的软件结构框图。

[0204] 分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

[0205] 应用程序层可以包括一系列应用程序包。如图6所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

[0206] 应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图6所示，应用程序框架层可以包括窗口管理器，内容提供器，电话管理器，资源管理器，通知管理器，视图系统等。

[0207] 窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

[0208] 内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

[0209] 电话管理器用于提供电子设备的通信功能。例如通话状态的管理(包括接通，挂断等)。

[0210] 资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

[0211] 通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

[0212] 视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

[0213] Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。在本申请一些实施例中，应用冷启动会在Android runtime中运行，Android runtime由此获取到应用的优化文件状态参数，进而Android runtime可以通过优化文件状态参数判断优化文件是否因系统升级而导致过时，并将判断结果返回给应用管控模块。

[0214] 核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

[0215] 应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

[0216] 系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，二维图形引擎(例如：SGL)等。

[0217] 表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

[0218] 媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG2，H.262，MP3，AAC，AMR，JPG，PNG等。

[0219] 三维图形处理库用于实现三维图形绘图，图像渲染、合成和图层处理等。

[0220] 二维图形引擎是2D绘图的绘图引擎。

[0221] 内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动等。

[0222] 需要说明的是，本申请实施例虽然以Android系统为例进行说明，但是其基本原理同样适用于基于iOS、Windows等操作系统的电子设备。