 |
善于提问，勤于回答，你也是专家
|
 |
问题已开启
(普通问题)
掉话原因为UE security mode time out，这一般是什么问题导致的？
掉话原因为UE security mode time out，这一般是什么问题导致的？并且在通话过程中还会启动加密模式吗
提问者:
• 关于moshell、decODEr的新版本 2020-07-15
• NR中，RRC_inactive状态下，GNODEB是否有UE的上下文？就像下面的选择题，总感觉答案不对 2020-06-16
• gNODEB根据UE上报的CQI，将其转换为几位长的MCS 2020-06-11
• https://tm.228job.com/public/index.php/user?cODE=001uptRJ1HvY800ud4OJ1HQfRJ1uptRh 2020-06-09
• https://tm.228job.com/public/index.php/user?cODE=0212n6OB0iJNQk2XwTKB0ScrOB02n6Oa 2020-06-09
• https://tm.228job.com/public/index.php/user?cODE=021Gduv02k5IqW086Kv023ZLv02GduvT 2020-06-09
• LTE 哪条信令可以看到enODEb id 2020-06-02
• gNODEB在获取下行业务信道特征的方法有哪些？ 2020-02-17
• NR中，RRC_inactive状态下，GNODEB是否有UE的上下文？就像下面的选择题，总感觉答案不对 2020-06-16
• gNODEB根据UE上报的CQI，将其转换为几位长的MCS 2020-06-11
• https://tm.228job.com/public/index.php/user?cODE=001uptRJ1HvY800ud4OJ1HQfRJ1uptRh 2020-06-09
• https://tm.228job.com/public/index.php/user?cODE=0212n6OB0iJNQk2XwTKB0ScrOB02n6Oa 2020-06-09
• https://tm.228job.com/public/index.php/user?cODE=021Gduv02k5IqW086Kv023ZLv02GduvT 2020-06-09
• LTE 哪条信令可以看到enODEb id 2020-06-02
• gNODEB在获取下行业务信道特征的方法有哪些？ 2020-02-17
问题答案
( 7 )
这种问题没遇到过，如果你已经接通了，不应该会启动加密模式的呀，通话过程中，误码高吗？
回答者：
luyl123
回答时间：2010-07-22 16:31
11
11
加密超时应该建立不了连接的吧
回答者：
luyl123
回答时间：2010-07-22 16:32
10
13
UE security mode time out不知道出现在那个层面上,传输误码高,无线环境差,都有可能
回答者：
goldenhuo
回答时间：2010-07-22 16:35
10
13
好像CS通话过程无加密吧？
回答者：
jingcheng05
回答时间：2010-07-22 17:17
8
6
无线环境良好，是在室内，用的室内分布小区的信号，是在通话过程中出现的掉话，原因值就是加密模式超时，而且在室内，也不存在位置更新或路由区更新的情况，
回答者：
lee20080616
回答时间：2010-07-23 08:24
9
10
加密应在通话前就进行了啊，在通话过程中出现加密超时，可以看一下是不是测试设备出现了问题，比如手机或软件什么的了。
回答者：
bindaowu
回答时间：2010-07-23 09:13
9
10
查看下信令，是否存在并发业务。如果在通话过程中，应该不会出现此掉话原因，而是未接通原因。
回答者：
halking
回答时间：2010-07-23 10:20
10
11
但是的确是掉话了，当时我也在现场，此后我提取了CHR，分析出是UE security mode time out，如果出现并发业务会导致掉话吗
lee20080616 2010-07-23 12:48
没有跟踪信令么？建议对信令进行详细分析。如果仅仅是根据CHR查看的话，应该是看不到整个呼叫流程的。如果你确定是掉话的话，可能是在这种情况下发生的：
之前一直进行的是CS的长呼业务，此时并发进行ps业务，又恰好在此时UE进行了跨RNC的切换,在重新进行安全模式鉴定时超时。在PS域默认为一次未接通，但在CS域则记为一次掉话，最后在CHR里呈现的时候，呈现为一次掉话。（具体为什么呈现掉话而不是未接通，有待继续深究）。
在现网中，如果存在2个以上核心网的话，在跨RNC同时跨核心网侧的时候有可能会出现这种原因的掉话，掉话原因为UE security mode time out，但究其为什么掉话，应该是核心网侧的问题，暂时由于学疏无法解答。
希望对你有帮助。
之前一直进行的是CS的长呼业务，此时并发进行ps业务，又恰好在此时UE进行了跨RNC的切换,在重新进行安全模式鉴定时超时。在PS域默认为一次未接通，但在CS域则记为一次掉话，最后在CHR里呈现的时候，呈现为一次掉话。（具体为什么呈现掉话而不是未接通，有待继续深究）。
在现网中，如果存在2个以上核心网的话，在跨RNC同时跨核心网侧的时候有可能会出现这种原因的掉话，掉话原因为UE security mode time out，但究其为什么掉话，应该是核心网侧的问题，暂时由于学疏无法解答。
希望对你有帮助。
halking 2010-07-23 14:13
掉话发生的场景是在办公楼内，而且有室内分布信号的情况，不存在跨RNC切换的问题阿
lee20080616 2010-07-24 12:24
| 联系我们 - 问通信专家 | Powered by MSCBSC 移动通信网 © 2006 - |