CN115002744B

CN115002744B - 呼叫请求的处理方法、电子设备、程序产品及介质

Info

Publication number: CN115002744B
Application number: CN202111312532.5A
Authority: CN
Inventors: 李海波
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-09-29
Filing date: 2021-11-08
Publication date: 2023-04-11
Anticipated expiration: 2041-11-08
Also published as: CN115002744A

Abstract

本申请提供了一种呼叫请求的处理方法、电子设备、计算机程序产品及计算机可读存储介质。在呼叫请求的处理方法中：UE向基站发送呼叫请求或接收基站发送的呼叫请求，UE接收基站发送的指示UE重定向LTE的指示信息，且确定UE不支持基于5G的语音业务VoNR，UE利用指示信息选择LTE小区驻留后抑制NR测报。由上述内容可以看出：UE发送呼叫请求或接收到呼叫请求时，UE利用指示信息选择LTE小区驻留后抑制NR测报，LTE则不会收到UE对NR小区检测得到的测量报告，LTE不会下发重定向到NR的指示给UE，可避免出现UE根据该指示定向到NR，因UE不支持VoNR导致的通话掉话问题。

Description

呼叫请求的处理方法、电子设备、程序产品及介质

本申请要求于2021年9月29日提交中国专利局、申请号为202111150260.3、发明名称为“呼叫请求方法、电子设备、程序产品及介质”，中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及通信技术领域，尤其涉及一种呼叫请求的处理方法、电子设备、计算机程序产品及计算机可读存储介质。

背景技术

用户设备(User Equipment，UE)，如手机，SA功能开启时，UE发起呼叫请求后一段时间内，如20秒，若呼叫请求未被接通，UE会自动挂断该呼叫请求。同样，UE接收到呼叫请求后一段时间内，如20秒，若呼叫请求也未被接通，UE也会自动挂断。

发明内容

本申请提供了一种呼叫请求的处理方法、电子设备、程序产品及计算机可读存储介质，目的在于解决UE开启SA功能，发起呼叫请求或接收呼叫请求一段时间后自动挂断的问题。

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

第一方面，本申请提供了一种应用于UE的呼叫请求的处理方法，该呼叫请求的处理方法包括：UE向基站发送呼叫请求，UE接收基站发送的指示UE重定向LTE的指示信息，且确定UE不支持基于5G的语音业务VoNR，UE利用指示信息选择LTE小区驻留后抑制NR测报；以及，UE接收基站发送的呼叫请求，UE接收基站发送的指示UE重定向LTE的指示信息，且确定UE不支持基于5G的语音业务VoNR，UE利用指示信息选择LTE小区驻留后抑制NR测报。

由上述内容可以看出：UE发送呼叫请求或接收到呼叫请求时，UE利用指示信息选择LTE小区驻留后抑制NR测报，LTE则不会收到UE对NR小区检测得到的测量报告，LTE不会下发重定向到NR的指示给UE，可避免出现UE根据该指示定向到NR，因UE不支持VoNR导致的通话掉话问题。

在一个可能的实施方式中，抑制NR测报包括：UE不进行NR小区信号强度的检测，或者，UE进行NR小区信号强度的检测但不向LTE上报NR小区信号强度的检测的测量报告。

在一个可能的实施方式中，UE确定UE不支持基于5G的语音业务VoNR的方式，包括：UE读取并解析配置文件；UE根据配置文件的解析结果，确定UE是否支持VoNR。

在一个可能的实施方式中，还包括：UE控制在通话全程不搜NR，其中，通话全程是指：从呼叫请求接入或发起到呼叫请求结束。

在上述可能的实施方式中，UE被命令在通话全程均不搜索NR小区，则只会搜索LTE小区，也可避免UE定向到NR小区，因UE不支持VoNR导致的通话掉话问题。

在一个可能的实施方式中，UE控制在通话全程不搜NR，包括：UE在通话全程忽略LTE下发的NR小区的测量指示，或者UE对NR小区进行测量，但不向LTE上报NR小区的测量结果。

在一个可能的实施方式中，呼叫请求的处理方法还包括：UE接收LTE下发的重定向NR的指示；UE确定LTE不是要终止本次通话；UE将定向NR的指示所指定的NR小区调整为LTE小区，LTE小区为UE在LTE驻留的小区或UE搜索到的LTE小区。

在上述可能的实施方式中，UE收到LTE下发的重定向NR的指示，原则上UE会按照重定向NR的指示，定向到NR小区，为避免UE执行此操作，UE将重定向NR的指示所指示的NR小区，调整为LTE原小区，可以确保继续驻留在LTE小区，以防止UE驻留到NR上。

在一个可能的实施方式中，呼叫请求的处理方法还包括：UE接收LTE下发的无线资源控制RRC释放；UE确定LTE不是要终止本次通话；UE确定LTE和UE之间建立的专有承载没有上下行数据包；UE向LTE发送空数据包。

在一个可能的实施方式中，UE确定LTE不是要终止本次通话，包括：UE确定未接收到LTE下发的删除通话的专有承载请求或中断通话的SIP消息。

在一个可能的实施方式中，UE将定向NR的指示所指定的NR小区调整为LTE小区之后，还包括：UE确定LTE和UE之间建立的专有承载没有上下行数据包；UE向LTE发送空数据包。

在一个可能的实施方式中，UE向LTE发送空数据包，包括：UE每间隔预定时间，向LTE发送空数据包。

在一个可能的实施方式中，呼叫请求的处理方法还包括：UE确定呼叫请求被接通；UE停止向LTE发送空数据包。

在一个可能的实施方式中，呼叫请求的处理方法还包括：UE确定向LTE发送空数据包有效；UE保存LTE小区的小区信息到喂包小区列表，LTE小区为UE在LTE驻留的小区。

在一个可能的实施方式中，UE向LTE发送空数据包之前，还包括：UE确定LTE小区需要发送空数据包，LTE小区为UE在LTE驻留的小区。

在一个可能的实施方式中，UE确定LTE小区需要发送空数据包，包括：UE在喂包小区列表中筛查到LTE小区；或者，UE未在喂包小区列表中筛查到LTE小区，但LTE小区为新小区。

第二方面，本申请提供了一种电子设备，包括：一个或多个处理器、存储器和移动通信模块；存储器和移动通信模块与一个或多个处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，电子设备执行如第一方面任意一项的呼叫请求的处理方法。

第三方面，本申请提供了一种计算机存储介质，用于存储计算机程序，计算机程序被执行时，具体用于实现如第一方面任意一项的呼叫请求的处理方法。

第四方面，本申请提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如第一方面任意一项的呼叫请求的处理方法。

附图说明

图1a和图1b为本申请提供的呼叫请求的页面展示图；

图2a和图2b为本申请提供的呼叫请求的信令图；

图3a为本申请提供的电子设备的硬件结构图；

图3b为本申请提供的电子设备的软件架构图；

图4为本申请实施例一提供的呼叫请求的处理方法的时序图；

图5为本申请实施例二提供的一种呼叫请求的处理方法的时序图；

图6为本申请实施例三提供的呼叫请求的处理方法的时序图；

图7为本申请实施例四提供的一种呼叫请求的处理方法的时序图。

具体实施方式

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

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

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

为了更清楚地阐明本申请技术方案，下面对本申请涉及的相关概念进行解释。

5G新无线(5G New Radio，5G NR)技术，简称NR，是即将大规模商用的通信技术。5G基站的组网方式存在两种，一种是非独立组网(None-Standalone，NSA)，另一种是独立组网(Standalone，SA)。

非独立组网NSA是指在现有的4G基站(Evolved Node B，eNB)上进行5G基站(g-Node B，gNB)部署组网。基于NSA架构的5G载波仅承载用户数据，其控制信令仍通过4G网络传输。

NSA中，用户设备在接入gNB时或切换gNB时，需要进行NR测量，确定是否存在满足B1事件(邻小区质量高于一定门限)的目标gNB。用户设备将接入或切换至满足B1事件的目标gNB。其中，在进行NR测量时，目标gNB对应的eNB一般会通过配置信息向用户设备发送目标gNB的NR频段号，由用户设备在NR频段号对应的NR频段上对目标gNB进行NR测量。

独立组网SA是指新建5G网络，包括新基站、回程链路以及核心网。SA引入了全新网元与接口的同时，还将大规模采用网络虚拟化、软件定义网络等新技术，并与5G NR结合，同时其协议开发、网络规划部署及互通互操作所面临的技术挑战将超越3G和4G系统。

IMS(IP Multimedia Subsystem，IP多媒体子系统)，可以在分组交换网络下实现语音业务。

VoNR：是Voice over NR的缩写，5G的无线接入部分叫做NR(New Radio)，跟IMS结合之后，独立打电话的问题解决。因此基于5G的语音业务称为VoNR。

EPS Fallback：也叫EPSFB，当不支持VoNR的时候，手机驻留到5G SA网络后，一般通过EPS Fallback到LTE来进行语言通话。使用EPS Fallback的NR语音业务通过一个触发机制能够使得UE在呼叫建立期间从NG-RAN回退到LTE建立VoLTE呼叫。这个触发机制的启动的原因有若干种，例如UE或者网络不具备VoNR的能力和功能情况下可以被触发，或者在NR中暂时缺少覆盖情况启动等。

MO:Mobile Original，发起；MO call指代发起呼叫。

MT:Mobile Terminated，接收；MT call指代接收呼叫。

UE：User Equipment，用户设备。

QCI(QoS Class Identifier)是一个标度值，用于衡量特定的提供给SDF(服务数据流)的包转发行为(如丢包率，包延迟预算)，同时应用于GBR和Non-GBR承载，用于指定访问节点内定义的控制承载级分组转发方式(如调度权重、接纳门限、队列管理门限、链路层协议配置等)。

图1a和图1b展示的应用场景中，手机支持SA功能。若手机的SA功能开启，如图1a所示，手机发起呼叫请求后一段时间内，如20秒，若呼叫请求还未被对方接通，手机会自动挂断该呼叫请求。同样，如图1b所示，手机接收到呼叫请求后一段时间内，如20秒，若呼叫请求也未被用户接通，手机也会自动挂断该呼叫请求。若手机关闭SA功能，手机发起呼叫请求或接收呼叫请求，均不会出现上述问题。

如手机等UE接收呼叫请求的流程，可参见图2a和图2b。以下以UE接收呼叫请求的流程为例，对UE处理呼叫请求的具体过程进行展开说明。

需要说明的是，图2a、图2b及下述内容中，LTE指代4G网，包括4G基站、接入网和核心网。NR指代5G网，包括5G基站、接入网和核心网。

如图2a所示，NR接收IMS转发的呼叫MT call，NR向UE发送invite请求，invite请求通常携带有消息体，消息体包含主叫方的媒体信息，消息体还可以包含其它会话信息，比如说资源列表。

UE接收到invite请求后，分别向NR返回应答消息100Tring和应答消息183，NR将该应答消息100Tring和应答消息183返回到IMS。在UE不支持VoNR时，NR会基于EPS Fallback，向UE发送重定向LTE的指示，UE收到该指示后，则在LTE驻留，并建立与LTE的专有承载。并且，UE会振铃，且通过LTE向IMS转发180Ringing振铃信息，以说明被叫用户正在振铃。

EPS fallback到LTE一段时间后，如图2a展示的20S后，若用户一直未接起该呼叫请求，则LTE会重定向到NR，即LTE向UE发送重定向5G的指示。UE收到该指示后，则在5G网驻留。但是，由于UE和网络侧并不支持VoNR，导致通话无法继续进行，进而发生掉话，网络侧可理解成5G网以及IMS。

如图2b所示，EPS fallback到LTE一段时间后，如图2b展示的20S后，若用户一直未接起该呼叫请求，LTE会向UE发送RRC(Radio Resource Control，无线资源控制)释放(RRCrelease)，UE接收到RRC释放后，则进入idle态，并进行小区重选，因5G网的小区优先级别高，则会重选到优先级高的5G网。因此，UE在5G网驻留。同样，由于UE和网络并不支持VoNR，导致通话无法继续进行，进而发生掉话。

由上述内容可以看出：若UE开启SA功能，针对UE接收的呼叫请求，在EPS fallback到LTE以后，网络会重定向到NR或者发起RRC release导致UE重选到5G网上。因UE和网络不支持VoNR，最终导致通话无法进行，产生掉话。

不仅如此，在UE发起呼叫请求时，同样因UE和网络不支持VoNR，UE产生同样问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

无线通信模块360可以提供应用在电子设备上的包括无线局域网(wirelesslocal 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转为电磁波辐射出去。

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

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

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

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

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

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

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

图3b是本申请实施例的电子设备的软件结构框图。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

实施例一

图1b展示的被叫用户接收主叫用户呼叫的应用场景中，主叫用户向被叫用户发起呼叫，示例性的，发起呼叫的设备称为主叫设备，接收呼叫的设备称为被叫设备。本实施例提供的呼叫请求的处理方法，可应用于图1b展示用户接收对方用户的电话的应用场景。以下结合图4，对UE接收呼叫请求时，对呼叫请求的处理流程进行介绍。

参见图4，本申请实施例一提供了一种呼叫请求的处理方法，本实施例提供的呼叫请求的处理方法中，UE指代被叫设备。呼叫请求的处理方法，包括步骤：

S401、NR接收IMS转发的呼叫MT call。

主叫设备发起呼叫请求，IMS接收主叫设备发起的呼叫请求，并向NR发送。

S402、NR向UE发送invite请求。

其中，invite请求通常携带有消息体，消息体包含主叫方的媒体信息。消息体还可以包含其它会话信息，比如说资源列表。

S403、UE接收到invite请求后，向NR返回应答消息100Tring。该应答消息100Tring用于向NR说明收到invite请求。

S404、NR向IMS返回应答消息100Tring。

S405、UE向NR返回应答消息183，应答消息183包括表征呼叫进展的信息。

S406、NR向IMS返回应答消息183。

需要说明的是，步骤S403至步骤S406中，应答消息100Tring和应答消息183的具体内容以及执行方式可参考协议SIP-RFC3261的内容，此处不展开说明。并且，图4展示的应答消息100Tring和应答消息183，是UE接收到invite请求，向NR返回应答消息的一种示例，并不构成对UE返回的应答消息的限定。

S407、NR基于EPS Fallback，向UE发送重定向LTE的指示。

如前所述，在UE或网络不支持VoNR时，NR会基于EPS Fallback，向UE发送重定向LTE的指示。一些实施例中，NR向UE发送的重定向LTE的指示会携带频点信息，以指示UE要定向的LTE小区。

还需要说明的是，一些实施例中，NR可通过UE在注册环节的UE信息，如UE上报的能力信息，来确定UE是否支持VoNR。一些实施例中，UE可通过网络侧是否触发EPS Fallback流程来间接判定网络是否支持VoNR。

UE收到重定向LTE的指示后，分别执行下述步骤。

S408、UE判断UE是否支持VoNR。

如果UE支持VoNR，执行常规流程，此处不展开说明。如果UE不支持VoNR，进入S409。

一些实施例中，UE判断自身是支持VoNR判断的方式为：UE读取自身的配置文件，解析该配置文件，以确定UE是否支持VoNR。该配置文件用于存储UE的属性信息，一般会存储于永久存储空间。

还需要说明的是，步骤S408的执行位置可不限于图4展示的位置，也可在步骤S407之前或之后的任意一个时刻执行。若步骤S408在步骤S407之前的任意一个时刻执行，UE接收到LTE下发的重定向LTE的指示后，则执行步骤S409。并且，步骤S408的执行结果会被保存下来，以便根据执行结果执行步骤S412。

S409、UE选择LTE小区驻留。

一些实施例中，UE接收NR下发的重定向LTE的指示，从该指示中确定要定向的LTE小区，UE搜索并选择重定向LTE的指示中携带的LTE小区驻留。

S410、UE建立与LTE的专有承载。

UE接收主叫设备发起的呼叫，为支持UE的语音通话，UE需要与LTE建立发起语音通话的专有承载。

具体的，在UE发起的EPS专有承载的建立中，UE的应用层直接向网络侧提出承载层QoS的请求，如果网络侧接受UE的请求，就会与UE进一步信令交互，建立专有承载。

S411、UE通过LTE向IMS转发180Ringing振铃信息，以说明UE正在振铃。

步骤S411中，在UE接收呼叫并返回应答消息后，UE会以振动、响铃、亮屏显示等方式提醒用户接收到呼叫。与此同时，UE也可响应振动、响铃、亮屏显示等方式的动作，生成并通过LTE向IMS转发180Ringing振铃信息。

通常情况下，180Ringing振铃信息用于说明UE接收到呼叫后正在振动或响铃，当然也可以说明UE以其他方式提醒用户接收到呼叫。

S412、UE抑制NR测报。

其中，NR测报是指：UE可周期性的检测NR小区信号强度，并将测量报告上报LTE。LTE收到测量报告后，根据测量报告确定UE周围存在NR小区，则会向UE下发重定向NR的指示。其中，UE可自主发起或者遵照网络侧的配置进行NR小区信号强度的测量。

UE抑制NR测报，可以理解成UE不进行NR检测或者进行NR检测但不上报测量报告给LTE。

通常情况下，UE抑制NR测报，LTE则不会收到UE对NR小区检测得到的测量报告，LTE不会下发重定向到NR的指示给UE，可避免出现UE根据该指示定向到NR，因UE不支持VoNR导致的通话掉话问题。

一些实施例中，LTE可采用下述两种方式，向UE下发重定向NR的指示。

第一种、LTE接收到UE上报的NR测报，LTE向UE下发重定向NR的指示。

第二种、LTE下发盲重定向NR的指示。在第二种中，LTE可按照自设定的周期向UE下发重定向NR的指示，而不需要受UE上报NR测报的触发。即LTE在没有收到UE上报的NR测报，LTE也会向UE下发重定向NR的指示。

由上述内容可以看出：LTE采用第一种方式向UE下发重定向NR的指示，UE执行步骤S412，UE抑制NR测报，LTE不会收到UE对NR小区检测得到的测量报告，LTE不会下发重定向到NR的指示给UE，才可避免出现UE根据该指示定向到NR，因UE不支持VoNR导致的通话掉话问题。

但是，若LTE采用第二种方式向UE下发重定向NR的指示，无法避免UE定向到NR。基于此，本申请实施例可通过下述步骤S413，步骤S415至步骤S416避免UE定向到NR。

还需要说明的是，一些实施例中，UE接收步骤S407中重定向LTE的指示后，可并行执行步骤S408，与步骤S409至步骤S411。

S413、UE控制在通话全程不搜NR。

UE控制在通话全程不搜NR可以理解成，UE控制在通话全程不搜NR小区。在一些实施例中，UE可周期性的测量自身周围小区的信号情况，基于此，执行步骤S413，UE被命令在通话全程均不搜索NR小区，只会搜索LTE小区。其中，通话全程是指：从呼叫请求接入到呼叫请求结束。

还需要说明的是，UE控制在通话全程不搜NR小区的实现方式可以包括：UE在通话全程忽略LTE下发的NR的测量指示，或者UE按照网络要求对NR小区进行搜索，但是不上报NR小区的测量结果到LTE。

S414、LTE向UE发送重定向NR的指示。

如前述内容，在LTE采用盲重定向UE到NR的方式时，UE执行步骤S412，抑制NR测报，LTE也会向UE下发重定向NR的指示。

一些实施例中，LTE向UE发送的重定向NR的指示会携带频点信息，以指示UE要定向的NR小区。

S415、UE收到LTE下发的重定向NR的指示后，判断LTE是否要终止本次通话。

其中，若UE判断LTE要终止本次通话，则执行常规终止通话流程，此处不展开说明。

一些实施例中，可以通过监控UE是否收到LTE下发删除通话的专有承载请求(Deactivate EPS bearer context request Msg)或中断通话的SIP消息，如BYE消息，来判断LTE是否要终止本次通话。

若LTE不是要终止本次通话，则执行步骤S416、UE将重定向的小区调整为LTE原小区。

其中，UE收到LTE下发的重定向NR的指示，原则上UE会按照重定向NR的指示，定向到NR小区，为避免UE执行此操作，UE将重定向NR的指示所指示的NR小区，调整为LTE原小区，可以确保继续驻留在LTE小区，以防止UE驻留到NR上。

LTE原小区指代步骤S407提出的重定向LTE的指示所指示的LTE小区。

还需要说明的是，步骤S415中，UE接收到LTE下发的重定向NR的指示，且判断LTE不是要终止本次通话，UE还可以将重定向的小区调整为其他LTE小区。

具体的，UE可从搜索到的LTE小区中选择一个LTE小区，将重定向的小区调整为选择的LTE小区。

S417、如果UE处于主被叫振铃阶段，UE判断通话的承载上是否有上下行数据包。

需要说明的是，在LTE和UE之间建立的专有承载长时间没有上下行数据包，LTE有可能也会下发重定向NR的指示或RRC release。基于此，UE执行步骤S412、UE抑制NR测报之后，若LTE和UE之间长时间没有上下行交互数据包，LTE有可能也会下发重定向NR的指示或RRC release。

因此，UE判断通话的承载上是否有上下行数据包。并且，若UE判断通话的承载上没有上下行数据包，则执行步骤S418、UE向LTE发送空数据包。

其中，UE向LTE发送空数据包，简单可以理解成是UE向LTE喂包。UE向LTE喂包以保活链路，避免因LTE和UE之间长时间没有上下行交互数据包，LTE下发重定向NR的指示或RRCrelease。

UE向LTE发送空数据包，是指每隔一段时间向LTE端发送空数据包，可通过如QCI＝5的IMS承载，每隔一段时间向LTE端发送空数据包。当然，QCI并不限于值等于5。

还需要说明的是，在用户接听呼叫请求后，UE则停止向LTE发送空数据包。

实施例一中，步骤S413是可选择执行的步骤。一些实施例中，在LTE采用前述步骤S414的方式来控制UE重定向到NR的场景中，步骤S413可不执行。

并且，步骤S417和步骤S418也是可选择性执行的步骤。一些实施例中，在LTE和UE之间建立的专有承载长时间有上下行数据包，或者，在LTE和UE之间建立的专有承载长时间没有上下行数据包，但LTE并不会下发重定向NR的指示或RRC release的场景中，步骤S417和步骤S418可不执行。

一些实施例中，在步骤S418之后，呼叫请求的处理方法还可以包括：UE对喂包进行有效性判决。

若UE判断向LTE发送空数据包有效，则进行小区信息学习。

小区信息学习是指：若向LTE发送空数据包有效，则保存该小区信息到喂包小区列表中。若向LTE发送空数据包无效则不保存该小区，或从喂包小区列表中移除，或在喂包小区列表中保存但标记为喂包无效，以作为下次通话对小区是否进行向LTE发送空数据包的判断依据。

还需要说明的是，喂包小区列表可应用于下一次呼叫请求流程中。

一些实施例中，向LTE发送空数据包是否有效判断的方式如下：

UE启动向LTE发送空数据包后，呼叫请求接通前，UE未再收到LTE发送的RRCrelease指示或者重定向指示，则认为向LTE发送空数据包有效。UE启动向LTE发送空数据包后依旧收到LTE发送的RRC release或者重定向指示，则认为向LTE发送空数据包无效。

一些实施例中，步骤S411执行之后，呼叫请求的处理方法还可以包括：UE判断现在驻留的LTE小区是否需要向网络发送空数据包。

如果UE判断现在驻留的LTE小区需要向网络发送空数据包，则执行步骤S417。

其中，可根据小区信息学习的结果，判断现在驻留的LTE小区是否需要向网络发送空数据包。

具体的，喂包小区列表中包含有需要向网络发送空数据包的小区的信息，将现在驻留的LTE小区在喂包小区列表中进行筛查，若筛查到现在驻留的LTE小区，则说明现在驻留的LTE小区是需要向网络发送空数据包，否则说明现在驻留的LTE小区可能不需要向网络发送空数据包，或可能是一个新小区，未在喂包小区列表中体现。

如果UE判断现在驻留的LTE小区不需要向网络发送空数据包，并且收到LTE下发的RRC release指示，但网络并没有明示此通话要结束，那么UE可控制UE不搜NR，以使UE继续驻留LTE小区。当然，若是新小区，还需要对网络发送空数据包。

网络是否没有明示此通话要结束的判断方式，可参见步骤S415的内容。

实施例二

在被叫用户接收主叫用户的应用场景中执行的呼叫请求的处理方法，除了前述实施例一提供的实施方式，还可为另一种实施方式。以下结合图5，对本申请实施例提供的另一种呼叫请求的处理方法进行介绍。

本实施例提供的呼叫请求的处理方法中，UE也指代被叫设备，用于接收呼叫请求。

参见图5，本实施例提供的呼叫请求的处理方法，包括步骤：

S501、NR接收IMS转发的呼叫MT call。

S502、NR向UE发送invite请求。

S503、UE接收到invite请求后，向NR返回应答消息100Tring。该应答消息100Tring用于向NR说明收到invite请求。

S504、NR向IMS返回应答消息100Tring。

S505、UE向NR返回应答消息183，应答消息183包括表征呼叫进展的信息。

S506、NR向IMS返回应答消息183。

步骤S501至步骤S506的具体执行过程，可对应参见实施例一的步骤S401至步骤S406的内容，此处不再赘述。

S507、NR基于EPS Fallback，向UE发送重定向LTE的指示。

步骤S507的具体执行过程，可参见实施例一的步骤S407内容，此处不展开说明。

S508、UE判断UE是否支持VoNR。

如果UE支持VoNR，执行常规流程，此处不展开说明。如果UE不支持VoNR，进入S509。

步骤S508的具体执行过程，可参见实施例一的步骤S408内容，此处不展开说明。

还需要说明的是，步骤S508的执行位置可不限于图5展示的位置，也可在步骤S507之前或之后的任意一个时刻执行。在步骤S508在步骤S507之前的任意一个时刻执行时，UE接收到LTE下发的重定向LTE的指示后，则执行步骤S509。并且，步骤S508的执行结果被保存下来，以根据该执行结果执行步骤S512。

S509、UE选择LTE小区驻留。

步骤S509的具体执行过程，可参见实施例一的步骤S409内容，此处不展开说明。

S510、UE建立与LTE的专有承载。

步骤S510的具体执行过程，可参见实施例一的步骤S410内容，此处不展开说明。

S511、UE通过LTE向IMS转发180Ringing振铃信息，以说明UE正在振铃。

步骤S511的具体执行过程，可参见实施例一的步骤S411内容，此处不展开说明。

需要说明的是，一些实施例中，UE接收步骤S507中的重定向LTE的指示后，可并行执行步骤S508以及步骤S509至步骤S511。

S512、UE抑制NR测报。

其中，NR测报是指：UE可周期性的检测NR，并检测结果上报LTE。UE抑制NR测报，可以理解成UE不进行NR检测或者进行NR检测但不上报测量报告给LTE。

步骤S512的具体执行过程，可参见实施例一的步骤S412内容，此处不展开说明。

S513、UE控制在通话全程不搜NR。

步骤S513的具体执行过程，可参见实施例一的步骤S413内容，此处不展开说明。

S514、LTE向UE下发RRC release。

其中，LTE向UE下发RRC release，UE会被触发搜索可停留的小区，基于此，执行步骤S513，UE被命令在通话全程均不搜索NR小区，只会搜索LTE小区。

当然，UE也可以周期性的测量自身周围小区的信号情况，而不必受LTE下发的RRCrelease的触发。在UE周期性的测量自身周围小区的信号情况，UE执行步骤S513，UE会被命令在通话全程均不搜索NR小区，只会搜索LTE小区。其中，通话全程是指：从呼叫请求接入到呼叫请求结束。

S515、UE收到LTE下发的RRC release后，判断LTE是否要终止本次通话。

若UE判断LTE要终止本次通话，则执行常规终止通话流程，此处不展开说明。

若LTE不是要终止本次通话，则执行步骤S516。

步骤S515的具体执行过程，可参见实施例一的步骤S415内容，此处不展开说明。

S516、如果是UE处于主被叫振铃阶段，UE判断通话的承载上是否有上下行数据包。

步骤S516的具体执行过程，可参见实施例一的步骤S417内容，此处不展开说明。

若UE判断通话的承载上没有上下行数据包，则执行步骤S517、UE向LTE发送空数据包。

其中，UE向LTE发送空数据包，简单可以理解成是UE向LTE喂包。UE主动向网络喂包以保活链路，避免因LTE和UE之间长时间没有上下行交互数据包，LTE下发重定向NR的指示或RRC release。

还需要说明的是，在用户接听呼叫请求后，UE则停止发送空数据包。

步骤S517的具体执行过程，可参见实施例一的步骤S418内容，此处不展开说明。

实施例二中，步骤S516和步骤S517也是可选择性执行的步骤。一些实施例中，在LTE和UE之间建立的专有承载长时间有上下行数据包，或者，在LTE和UE之间建立的专有承载长时间没有上下行数据包，但LTE并不会下发重定向NR的指示或RRC release的场景中，步骤S516和步骤S517可不执行。

一些实施例中，在步骤S517之后，呼叫请求的处理方法还可以包括：UE对向LTE发送空数据包进行有效性判决。

若UE判断向LTE发送空数据包有效，则进行小区信息学习。

一些实施例中，步骤S511执行之后，呼叫请求的处理方法还可以包括：判断现在驻留的LTE小区是否需要向网络发送空数据包。

如果UE判断现在驻留的LTE小区需要向网络发送空数据包，则执行步骤S517。

网络是否没有明示此通话要结束的判断方式，可参见步骤S515的内容。

实施例三

前述两个实施例展示了在被叫用户接收主叫用户的应用场景中执行的呼叫请求的处理方法的内容，在图1a展示的主叫用户向被叫用户发起呼叫的应用场景中，同样也可执行呼叫请求的处理方法，本应用场景中，示例性的，发起呼叫的设备称为主叫设备，接收呼叫的设备称为被叫设备。以下结合图6，对应用于图1a展示的主叫用户向被叫用户发起呼叫的应用场景中的呼叫请求的处理方法进行介绍。

本实施例提供的呼叫请求的处理方法中，UE指代主叫设备，参见图6，本实施例提供的呼叫请求的处理方法，包括步骤：

S601、UE通过NR向IMS发起MO call。

S602、NR向IMS发送invite请求。

S603、IMS向NR发送应答消息100Tring。该应答消息100Tring用于向NR说明收到invite请求。

S604、NR向UE发送应答消息100Tring。

S605、MS向NR发送应答消息183，应答消息183包括表征呼叫进展的信息。

S606、NR向UE发送应答消息183。

需要说明的是，步骤S603至步骤S606中，应答消息100Tring和应答消息183的具体内容以及执行方式可参考协议SIP-RFC3261的内容，此处不展开说明。并且，图6展示的应答消息100Tring和应答消息183，是UE发起MO call，接收NR返回应答消息的一种示例，并不构成对NR返回的应答消息的限定。

S607、NR基于EPS Fallback，向UE发送重定向LTE的指示。

步骤S607的具体执行过程，可参见实施例一的步骤S407内容，此处不展开说明。

S608、UE判断UE是否支持VoNR。

如果UE支持VoNR，执行常规流程，此处不展开说明。如果UE不支持VoNR，进入S609。

步骤S608的具体执行过程，可参见实施例一的步骤S408内容，此处不展开说明。

还需要说明的是，步骤S608的执行位置可不限于图6展示的位置，也可在步骤S607之前或之后的任意一个时刻执行。在步骤S608在步骤S607之前的任意一个时刻执行时，UE接收到LTE下发的重定向LTE的指示后，则执行步骤S609。并且，步骤S608的执行结果被保存下来，以根据该执行结果执行步骤S612。

S609、UE选择LTE小区驻留。

步骤S609的具体执行过程，可参见实施例一的步骤S409内容，此处不展开说明。

S610、UE建立与LTE的专有承载。

步骤S610的具体执行过程，可参见实施例一的步骤S410内容，此处不展开说明。

S611、UE通过LTE接收IMS发送180Ringing振铃信息，180Ringing振铃信息说明被叫设备正在振铃。

本步骤中，UE为主叫设备，UE向被叫设备发起呼叫，被叫设备接收呼叫并返回应答消息后，被叫设备会以振动、响铃、亮屏显示等方式提醒用户接收到呼叫。与此同时，被叫设备也可响应振动、响铃、亮屏显示等方式的动作，生成并通过LTE向UE发送180Ringing振铃信息。

通常情况下，180Ringing振铃信息用于说明被叫设备接收到呼叫后正在振动或响铃，当然也可以说明被叫设备以其他方式提醒用户接收到呼叫。

需要说明的是，一些实施例中，UE接收步骤S607中的重定向LTE的指示后，可并行执行步骤S608，与步骤S609至步骤S611。

S612、UE抑制NR测报。

其中，NR测报是指：UE可周期性的检测NR，并将测量报告上报LTE。UE抑制NR测报可以理解成UE抑制NR测报，可以理解成UE不进行NR检测或者进行NR检测但不上报测量报告给LTE。

步骤S612的具体执行过程，可参见实施例一的步骤S412内容，此处不展开说明。

还需要说明的是，若前述步骤S608的执行结果是UE不支持VoNR，则UE执行步骤S612。

S613、UE控制在通话全程不搜NR。

S614、LTE向UE发送重定向NR的指示。

如前述内容，在LTE采用盲重定向UE到NR的方式时，UE执行步骤S612，抑制NR测报，LTE也会向UE下发重定向NR的指示。

S615、UE收到LTE下发的重定向NR的指示后，判断LTE是否要终止本次通话。

若LTE不是要终止本次通话，则执行步骤S616、UE将重定向的小区调整为LTE原小区。

步骤S616的具体执行过程，可参见实施例一的步骤S416内容，此处不展开说明。

还需要说明的是，步骤S615中，UE接收到LTE下发的重定向NR的指示，且判断LTE不是要终止本次通话，UE还可以将重定向的小区调整为其他LTE小区。

S617、如果UE处于主被叫振铃阶段，UE判断通话的承载上是否有上下行数据包。

步骤S617的具体执行过程，可参见实施例一的步骤S417内容，此处不展开说明。

若UE判断通话的承载上没有上下行数据包，则执行步骤S618、UE向LTE发送空数据包。

其中，UE向LTE发送空数据包，简单可以理解成是UE向LTE喂包。UE主动向网络发送空数据包以保活链路，避免因LTE和UE之间长时间没有上下行交互数据包，LTE下发重定向NR的指示或RRC release。

步骤S618的具体执行过程，可参见实施例一的步骤S418内容，此处不展开说明。

实施例三中，步骤S613是可选择执行的步骤。一些实施例中，在LTE采用前述步骤S614的方式来控制UE重定向到NR的场景中，步骤S613可不执行。

并且，步骤S617和步骤S618是可选择性执行的步骤。一些实施例中，在LTE和UE之间建立的专有承载长时间有上下行数据包，或者，在LTE和UE之间建立的专有承载长时间没有上下行数据包，但LTE并不会下发重定向NR的指示或RRC release的场景中，步骤S617和步骤S618可不执行。

一些实施例中，在步骤S617之后，呼叫请求的处理方法还可以包括：UE对向LTE发送空数据包进行有效性判决。

若UE判断向LTE发送空数据包有效，则进行小区信息学习。

一些实施例中，步骤S611执行之后，呼叫请求的处理方法还可以包括：判断现在驻留的LTE小区是否需要向网络发送空数据包。

如果UE判断现在驻留的LTE小区需要向网络发送空数据包，则执行步骤S617。

网络是否没有明示此通话要结束的判断方式，可参见步骤S616的内容。

实施例四

前述实施例提供了应用于图1a展示的主叫用户发起呼叫场景中的呼叫请求的处理方法，应用于图1a展示的主叫用户发起呼叫的应用场景的呼叫请求的处理方法，还可以为另一种实施方式，以下结合图7进行介绍。

本实施例提供的呼叫请求的处理方法中，UE指代主叫设备，参见图7，本实施例提供的呼叫请求的处理方法，包括步骤：

S701、UE通过NR向IMS发起MO call。

S702、NR向IMS发送invite请求。

S703、IMS向NR发送应答消息100Tring。该应答消息100Tring用于向NR说明收到invite请求。

S704、NR向UE发送应答消息100Tring。

S705、MS向NR发送应答消息183，应答消息183包括表征呼叫进展的信息。

S706、NR向UE发送应答消息183。

步骤S701至步骤S706的具体执行过程，可对应参见实施例三的步骤S601至步骤S606的内容，此处不再赘述。

S707、NR基于EPS Fallback，向UE发送重定向LTE的指示。

步骤S707的具体执行过程，可参见实施例一的步骤S407内容，此处不展开说明。

S708、UE判断UE是否支持VoNR。

如果UE支持VoNR，执行常规流程，此处不展开说明。如果UE不支持VoNR，进入S709。

步骤S708的具体执行过程，可参见实施例一的步骤S408内容，此处不展开说明。

还需要说明的是，步骤S708的执行位置可不限于图7展示的位置，也可在步骤S707之前或之后的任意一个时刻执行。在步骤S708在步骤S707之前的任意一个时刻执行时，UE接收到LTE下发的重定向LTE的指示后，则执行步骤S709。并且，步骤S708的执行结果被保存下来，以根据该执行结果执行步骤S712。

S709、UE选择LTE小区驻留。

步骤S709的具体执行过程，可参见实施例一的步骤S409内容，此处不展开说明。

S710、UE建立与LTE的专有承载。

步骤S710的具体执行过程，可参见实施例一的步骤S410内容，此处不展开说明。

S711、UE通过LTE接收IMS发送180Ringing振铃信息，180Ringing振铃信息说明被叫设备正在振铃。

步骤S711的具体执行过程，可参见实施例三的步骤S611内容，此处不展开说明。

需要说明的是，一些实施例中，UE接收步骤S707中的重定向LTE的指示后，可并行执行步骤S708，与步骤S709至步骤S711。

S712、UE抑制NR测报。

通常情况下，UE抑制NR测报，LTE则不会收到UE对NR小区检测得到的测量报告，LTE不会下发重定向到NR的指示给UE，可避免出现UE根据该指示定向到NR，因UE不支持VoNR导致的通话掉话问题步骤S712的具体执行过程，可参见实施例一的步骤S412内容，此处不展开说明。

S713、UE控制在通话全程不搜NR。

S714、LTE向UE下发RRC release。

其中，LTE向UE下发RRC release，UE会被触发搜索可停留的小区，基于此，执行步骤S713，UE被命令在通话全程均不搜索NR小区，只会搜索LTE小区。

当然，UE也可以周期性的测量自身周围小区的信号情况，而不必受LTE下发的RRCrelease的触发。在UE周期性的测量自身周围小区的信号情况，UE执行步骤S713，UE会被命令在通话全程均不搜索NR小区，只会搜索LTE小区。其中，通话全程是指：从呼叫请求接入到呼叫请求结束。

S715、UE收到LTE下发的RRC release后，判断LTE是否要终止本次通话。

若LTE不是要终止本次通话，则执行步骤S716。

步骤S715的具体执行过程，可参见实施例一的步骤S415内容，此处不展开说明。

S716、如果是UE处于主被叫振铃阶段，UE判断通话的承载上是否有上下行数据包。

步骤S716的具体执行过程，可参见实施例一的步骤S417内容，此处不展开说明。

若UE判断通话的承载上没有上下行数据包，则执行步骤S717、UE向LTE发送空数据包。

步骤S717的具体执行过程，可参见实施例一的步骤S418内容，此处不展开说明。

实施例四中，步骤S716和步骤S717是可选择性执行的步骤。一些实施例中，在LTE和UE之间建立的专有承载长时间有上下行数据包，或者，在LTE和UE之间建立的专有承载长时间没有上下行数据包，但LTE并不会下发重定向NR的指示或RRC release的场景中，步骤S716和步骤S717可不执行。

一些实施例中，在步骤S717之后，呼叫请求的处理方法还可以包括：UE对向LTE发送空数据包进行有效性判决。

若UE判断向LTE发送空数据包有效，则进行小区信息学习。

一些实施例中，步骤S711执行之后，呼叫请求的处理方法还可以包括：判断现在驻留的LTE小区是否需要向网络发送空数据包。

如果UE判断现在驻留的LTE小区需要向网络发送空数据包，则执行步骤S717。

网络是否没有明示此通话要结束的判断方式，可参见步骤S717的内容。

还需要说明的是，按照前述四个实施例的方法，可以确定UE接入到LTE后，会产生网络发起RRC释放或者重定向这个异常行为的LTE小区。基于此，记录有异常行为的小区，并将记录的小区，在UE进行搜网/重选/测报时，对该小区的优先级降低，以避免进入到该小区。并且，还可以在确定驻留到该小区以后，自动关闭SA功能，退出该小区后打开SA功能。

由前述四个实施例的内容可以看出：为避免UE发起呼叫请求或接收呼叫请求一段时间后自动挂断的问题，本申请提供的呼叫请求的处理方法，包括下述步骤：

UE判断是否满足第一条件，以及判断是否支持VoNR。

其中，第一条件用于表征UE发起或接收呼叫。一些实施例中，UE作为主叫设备，向基站发送呼叫请求，并接收到基站返回的应答消息。另一些实施例中，UE作为被叫设备，接收基站发送的呼叫请求，或向基站返回应答消息。还需要说明的是，此处的基站通常指代5G基站。

UE判断是否支持VoNR的具体实现方式，可参见前述四个实施例的内容，此处不再赘述。

UE判断出满足第一条件，且不支持VoNR的场景下，UE接收到NR发送的指示信息，则执行第一操作。

指示信息用于指示UE驻留到LTE小区。一些实施例中，指示信息可为前述实施例提出的NR发送的重定向LTE的指示。

第一操作可以理解成是抑制UE返回NR，控制UE驻留在LTE小区的操作。一些实施例中，第一操作可包括：UE抑制NR测报，控制UE在通话全程不搜NR，以及将LTE下发的重定向到NR的指示中的NR小区，调整小区为LTE小区三个操作中的至少一个或任意组合。

其中，UE抑制NR测报，控制UE在通话全程不搜NR，以及将LTE下发的重定向到NR的指示中的NR小区，调整小区为LTE小区三个操作的具体执行过程，可参见前述四个实施例的内容，此处不再赘述。

当然，UE在接收NR发送的指示信息，除执行第一操作之外，还可执行常规流程，如前述实施例提出的UE选择LTE小区驻留，建立与LTE的专有承载，具体内容可参见前述四个实施例内容，此处也不再赘述。

本申请另一实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

本申请另一实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

Claims

1.一种呼叫请求的处理方法，其特征在于，应用于UE，所述呼叫请求的处理方法包括：

所述UE向基站发送呼叫请求，或接收所述基站发送的呼叫请求；

所述UE接收所述基站发送的指示信息，且确定UE不支持基于5G的语音业务VoNR，所述指示信息用于指示UE重定向LTE；

所述UE利用所述指示信息，选择LTE小区驻留后抑制NR测报；

所述UE接收所述LTE下发的重定向NR的指示；

所述UE确定所述LTE不是要终止本次通话；

所述UE将所述重定向NR的指示所指定的NR小区调整为LTE小区，所述LTE小区为所述UE在LTE驻留的小区或UE搜索到的LTE小区。

2.根据权利要求1所述的呼叫请求的处理方法，其特征在于，所述抑制NR测报包括：UE不进行NR小区信号强度的检测，或者，UE进行NR小区信号强度的检测但不向LTE上报NR小区信号强度的检测的测量报告。

3.根据权利要求1或2所述的呼叫请求的处理方法，其特征在于，所述UE确定UE不支持基于5G的语音业务VoNR的方式，包括：

所述UE读取并解析配置文件；

所述UE根据所述配置文件的解析结果，确定UE是否支持VoNR。

4.根据权利要求1至3中任意一项所述的呼叫请求的处理方法，其特征在于，还包括：所述UE控制在通话全程不搜NR，其中，所述通话全程是指：从呼叫请求接入或发起到呼叫请求结束。

5.根据权利要求4所述的呼叫请求的处理方法，其特征在于，所述UE控制在通话全程不搜NR，包括：

所述UE在所述通话全程忽略所述LTE下发的NR小区的测量指示，或者所述UE对NR小区进行测量，但不向所述LTE上报NR小区的测量结果。

6.根据权利要求1至5中任意一项所述的呼叫请求的处理方法，其特征在于，还包括：

所述UE接收所述LTE下发的无线资源控制RRC释放；

所述UE确定所述LTE不是要终止本次通话；

所述UE确定所述LTE和所述UE之间建立的专有承载没有上下行数据包；

所述UE向所述LTE发送空数据包。

7.根据权利要求1或6所述的呼叫请求的处理方法，其特征在于，所述UE确定所述LTE不是要终止本次通话，包括：

所述UE确定未接收到所述LTE下发的删除通话的专有承载请求或中断通话的SIP消息。

8.根据权利要求1所述的呼叫请求的处理方法，其特征在于，所述UE将所述重定向NR的指示所指定的NR小区调整为LTE小区之后，还包括：

所述UE向所述LTE发送空数据包。

9.根据权利要求6或8所述的呼叫请求的处理方法，其特征在于，所述UE向LTE发送空数据包，包括：

所述UE每间隔预定时间，向所述LTE发送空数据包。

10.根据权利要求6、8或9所述的呼叫请求的处理方法，其特征在于，还包括：

所述UE确定所述呼叫请求被接通；

所述UE停止向所述LTE发送空数据包。

11.根据权利要求6、或者8至10中任意一项所述的呼叫请求的处理方法，其特征在于，还包括：

所述UE确定向LTE发送空数据包有效；

所述UE保存LTE小区的小区信息到喂包小区列表，所述LTE小区为所述UE在LTE驻留的小区。

12.根据权利要求6、或者8至11中任意一项所述的呼叫请求的处理方法，其特征在于，所述UE向所述LTE发送空数据包之前，还包括：

所述UE确定LTE小区需要发送空数据包，所述LTE小区为所述UE在LTE驻留的小区。

13.根据权利要求12所述的呼叫请求的处理方法，其特征在于，所述UE确定LTE小区需要发送空数据包，包括：

所述UE在喂包小区列表中筛查到所述LTE小区；或者，所述UE未在喂包小区列表中筛查到所述LTE小区，但所述LTE小区为新小区。

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

一个或多个处理器、存储器和移动通信模块；

所述存储器和所述移动通信模块与所述一个或多个所述处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，所述电子设备执行如权利要求1至13任意一项所述的呼叫请求的处理方法。

15.一种计算机存储介质，其特征在于，用于存储计算机程序，所述计算机程序被执行时，具体用于实现如权利要求1至13任意一项所述的呼叫请求的处理方法。