紧急呼叫必须在任何情况下都能工作，并且网络最终会响应当紧急呼叫出现故障时，定义正确的行为是很重要的，因为紧急呼叫必须在所有情况下工作，最终进行网络响应，现在小编就来说说关于imsi数据被盗用?下面内容希望能帮助到你，我们来一起看看吧!
imsi数据被盗用
紧急呼叫必须在任何情况下都能工作，并且网络最终会响应。当紧急呼叫出现故障时，定义正确的行为是很重要的，因为紧急呼叫必须在所有情况下工作，最终进行网络响应。
IMS紧急呼叫程序可分为以下几个部分：
- 用户拨打紧急电话号码（如110或119）；
- 紧急PDN连接建立；
- 紧急注册；
- 紧急会话建立。
以下是有关IMS紧急呼叫失败的当前解决方案：
一、如果有紧急PDN连接建立失败，UE立即通过CS重试紧急连接。
二、IMS紧急注册失败：
如果紧急注册失败且有任何错误响应或超时（即入站漫游者有漫游协议并注册到本地IMS，但本地IMS的紧急注册失败），UE应建立匿名紧急呼叫，如3GPP TS 23.167中描述的可选呼叫和IR.92版本10.0中描述的强制呼叫。
当Emerg-reg计时器到期而没有对紧急寄存器的任何响应时，UE将紧急注册确定为失败。Emerg-reg计时器在3GPP 24.229第5.1.6.1节的定义是：
UE应在发送initial REGISTER request以执行初始紧急注册时启动Emerg-reg定时器，根据3GPP TS24.229的5.1.6.2所述，UE应在接收到任何最终SIP响应时停止计时器。当Emerg-reg计时器到期时，UE应认为紧急注册失败，并应用3GPP TS 23.167子条款4.1中定义的与紧急注册失败相关的程序。
三、IMS紧急会话建立失败：
当IMS呼叫在会话建立过程中由于对INVITE没有响应而失败时，终端不会等到计时器A或B（3GPP TS 24.229表7.8）过期，而是在5秒内通过CS重试呼叫，如3GPP TS 24.173 V14.0.0第J.2.1.3节和附录L所述。在本标准规范中，还描述了计时器在接收到来自网络的“100 TRYING”响应时停止。此要求仅对正常VoLTE呼叫有效。
在接收到100 TRYING时停止计时器表示UE和网络之间的连接已经建立。在100 TRYING后发生的呼叫建立延迟可能有一个好的原因，例如远距离目标。因此，网络（如PCSCF）负责处理此问题，如果需要，应启动CSFB（如380）。对于正常VoLTE电话，此计时器RequestTimeout已足够。
对于紧急呼叫，情况就不同了。 UE应在一段合理的时间（例如，由于紧急情况和本地环境而不超过10秒）之后发起CSFB，该时间独立于发生延迟的呼叫建立阶段，并且如果网络行为是否有故障也独立于此。
目前在DT的测试过程中，可以看到一些终端在IMS紧急呼叫建立的振铃阶段（180 ringing 和200 OK之间）执行CSFB。其他UE在3-5秒后独立于任何呼叫应答进行CSFB。
总而言之，对于时间紧迫的紧急呼叫会话超时，需要解决方案。
解决方案：定义一个新的计时器–EmergencyRequestTimeout，它有一个可配置的值，在收到18倍的临时响应后停止。
原因：有了这个新的计时器，特别是启动紧急会话将有助于减少建立时间，用每一秒的计数，在减少故障的情况下，以更快地处理紧急呼叫。
定时器应是可配置的，因此当例如PSAP向UE发送公告时，用户不应注意到由于定时器到期而放弃IMS紧急呼叫。
计时器在VPLMN（漫游场景）中也应与在HPLMN中的有效方式相同。
在TS 24.229子条款5.1.6.8中实施EmergencyRequestTimeout计时器，仅对紧急会话有效，并且当UE接收到18x临时响应时，计时器被占用。当计时器过期时，将执行CSFB。
,
