 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
主叫上發(fā)CM service request之后1到2秒后隨即上發(fā)位置更新請求是怎么回事？求高手幫忙
主叫上發(fā)CM service request之后1到2秒后隨即上發(fā)位置更新請求是怎么回事？且CM service request消息里確定是呼叫業(yè)務(wù)，求高手幫忙
提問者:
• 【VOLTE】主叫為啥發(fā)起servICEreQUEst一直后不RRC建立，導致未接通？ 2017-07-29
• 聯(lián)通打電話，被叫信令中沒有extendservICEreQUEst這條信令，主叫直接聽到用戶暫時無法接通，這是什么原因呢？ 2016-07-13
• 什么原因情況下主叫UE上發(fā)CMservICEabort，導致未接通 2014-11-16
• 主叫撥打電話提示無法接通，看LOG終端一直在發(fā)CM_servICE_reQUEst 2013-06-25
• 鼎力ATU測試中，CM servICE reQUEst后主叫上發(fā)RRC status之后，網(wǎng)絡(luò)下發(fā)RRC釋放命令導致未接通 2013-03-10
• 主叫手機做cm servICE reQUEst后，為什么還能位置更新？而且更新后再發(fā)cm servICE reQUEst？ 2011-05-15
• 主叫起呼，RRC連接建立完成后，發(fā)送CM servICE reQUEst 之后未收到響應(yīng)導致未接通 2010-06-28
• 聯(lián)通打電話，被叫信令中沒有extendservICEreQUEst這條信令，主叫直接聽到用戶暫時無法接通，這是什么原因呢？ 2016-07-13
• 什么原因情況下主叫UE上發(fā)CMservICEabort，導致未接通 2014-11-16
• 主叫撥打電話提示無法接通，看LOG終端一直在發(fā)CM_servICE_reQUEst 2013-06-25
• 鼎力ATU測試中，CM servICE reQUEst后主叫上發(fā)RRC status之后，網(wǎng)絡(luò)下發(fā)RRC釋放命令導致未接通 2013-03-10
• 主叫手機做cm servICE reQUEst后，為什么還能位置更新？而且更新后再發(fā)cm servICE reQUEst？ 2011-05-15
• 主叫起呼，RRC連接建立完成后，發(fā)送CM servICE reQUEst 之后未收到響應(yīng)導致未接通 2010-06-28
問題答案
( 5 )
是每次都是還是個別現(xiàn)象，要是個別現(xiàn)象這屬于主叫在做位置更新，可能會造成主叫呼叫失敗，算作未接通的。具體的解決辦法看后臺網(wǎng)管此小區(qū)謂之更新請請求次數(shù)是否很多，可以調(diào)整CRH參數(shù)
回答者：
zhaolin123ll@16
回答時間：2011-01-10 20:37
14
16
不是個別現(xiàn)象，同時用三套軟件測試，只有移動的自動路測儀有這個問題，而且不是一次兩次的，但是設(shè)計院說沒有問題。這個軟件在信令流程中沒有channel request ，直接以CM service request判斷為一次起呼�，F(xiàn)在問題是在這條信令中有CM service request type顯示是呼叫業(yè)務(wù)，但是在1s或者2s主叫又上發(fā)位置更新請求，導致未接通了。我懷疑是不是有可能是上發(fā)CM service request 到網(wǎng)絡(luò)響應(yīng)這段時間定時器超時才導致主叫位置更新的，但是這又是哪個定時器呢？怎么設(shè)置的？愛立信的設(shè)備
wulina0102 2011-01-11 09:37
1.會不會是開了周期性更新或者是基于參數(shù)變化的更新？？？
2.移動臺是否在LAC邊界來回走，或者在LAC邊界某個站出了故障，導致LAC邊界產(chǎn)生變化
2.移動臺是否在LAC邊界來回走，或者在LAC邊界某個站出了故障，導致LAC邊界產(chǎn)生變化
回答者：
d2k2000
回答時間：2011-01-10 20:57
13
13
你是用TEMS軟件測試的吧？在TEMS軟件測試軟件里，從第三層信令可以看到：MS發(fā)起呼叫時首先是CM service request，然后再是才Channel Request。CM service request占用的是SDCCH信道，而Channel Request占用的是RACH信道。很明示TEMS里這CM service request信令顯示是有誤的。應(yīng)該是先有Channel Request，然后才是CM service request。TEMS以前也是Channel Request在前，然后才是CM service request，后來從5.0的版本就把他們的順序調(diào)換了。至于原因我也不知道。
位置更新占用的是SDCCH信道，而CM service request也是占用SDCCH信道。當MS已進行CM service request，MS的SDCCH信道已經(jīng)被占用，怎么還可能位置更新，如果MS已占用TCH信道，更不可能進行位置更新。很顯然是MS在發(fā)起Channel Request后，在CM service request業(yè)務(wù)請求之前剛好MS進行了位置更新。是TEMS信令的顯示誤導了大家。具體原因在上面也提到了。
為什么會位置更新，可能是由于周期性的位置更新，也可能是正常位置更新。樓主可以看一下LOG是否此時剛好在LAC邊界。
位置更新占用的是SDCCH信道，而CM service request也是占用SDCCH信道。當MS已進行CM service request，MS的SDCCH信道已經(jīng)被占用，怎么還可能位置更新，如果MS已占用TCH信道，更不可能進行位置更新。很顯然是MS在發(fā)起Channel Request后，在CM service request業(yè)務(wù)請求之前剛好MS進行了位置更新。是TEMS信令的顯示誤導了大家。具體原因在上面也提到了。
為什么會位置更新，可能是由于周期性的位置更新，也可能是正常位置更新。樓主可以看一下LOG是否此時剛好在LAC邊界。
回答者：
五年陽光
回答時間：2011-01-10 22:19
17
13
贊一個，LS的信令基礎(chǔ)知識學習的很扎實，學習了。
Stardustming 2011-01-11 08:44
不是tems,是移動的自動路測儀，我們都懷疑很有可能是軟件問題，但是設(shè)計院說沒有問題，這個軟件在信令流程中沒有channel request ，直接以CM service request判斷為一次起呼�，F(xiàn)在問題是在這條信令中有CM service request type顯示是呼叫業(yè)務(wù)，但是在1s或者2s主叫又上發(fā)位置更新請求，導致未接通了。我懷疑是不是有可能是上發(fā)CM service request 到網(wǎng)絡(luò)響應(yīng)這段時間定時器超時才導致主叫位置更新的，但是這又是哪個定時器呢？怎么設(shè)置的？愛立信的設(shè)備
wulina0102 2011-01-11 09:32
位置更新有三種情況。一是周期性位置更新（即T3212計時器），二是正常位置更新，三是IMSI附著。在你所說的情況，可能是正常位置更新(MS在LAC邊界），也可能是周期位置更新。如果MS進行了CM service request 后是不可能進行位置更新的。應(yīng)該也是自動路測儀信令顯示的問題。TEMS就是一開始起呼就是CM service request 信令，而實際不是。樓主可以看看LOG,看是否這樣，如果開始起呼就是CM service request ，那就和TEMS里信令顯示一樣了。
五年陽光 2011-01-11 12:23
應(yīng)該不是正常位置更新，也不是周期位置更新，因為三套設(shè)備一起測另外兩套設(shè)備全部沒有問題，越來越確定是軟件問題了 無奈設(shè)計院的專家們說很正常，無奈ing。。。。謝謝同志們幫忙啦
wulina0102 2011-01-11 16:48
回復(fù)“???ê???? 的答案”
哥們，TEMS中先有CM service request，再有Channel Request，這個是準確的。
規(guī)范中先有Channel Request，再有CM service request，是因為規(guī)范是站在空中接口的角度來理解的。
而在測試手機中看到的信令，是站在手機側(cè)的角度來理解的。
CM service request只是在手機側(cè)的MM層的信令，并未走到空口。
至于5.0前，只能說明愛立信意識到上述這種問題。
莫非又是傳說中的ATU ~~~
懷疑測試設(shè)備問題！
這個問題我也遇到過，通過分析發(fā)現(xiàn)，上一次呼叫起呼的時候和掛機的時候不在同一個LAC區(qū)，正常流程應(yīng)該在掛機后進行Location Updating，在進行Routing Area Update.但是這個設(shè)備掛機之后掛機之后主叫MS只做了Routing Area Update，而沒有做Location Updating，或者兩個都不作；
重新呼叫，起呼后MS發(fā)現(xiàn)沒有進行Location Updating，又重新進行Location Updating，在進行Routing Area Update.
已經(jīng)發(fā)出了CM service request軟件統(tǒng)計一次call failure。
（還有一點不理解的就是假如沒做位置更新也就是VLR中應(yīng)該無用戶信息，為何能到CM service request）
陽光大哥層三高手您的答案才是最需要的
deathlover 2012-03-26 10:26
學習了,支持一下啊!
回答者：
feiniao216
回答時間：2011-01-11 09:25
21
9
學習學習 頂一下
回答者：
朱峰
回答時間：2011-01-13 15:07
11
7
主叫上發(fā)CM service request之后1到2秒后隨即上發(fā)位置更新請求是怎么回事？且CM service request
麻煩你們看清楚問題。。。。。。。。。
我請問你們？ CM SERVICE REQUEST之后該出現(xiàn)什么信令？是不是該是一 CM SERVICE ACCEPT？
這個問題最大的疑問在這，“如果出現(xiàn)位置更新請求的話”那么CM SERVICE 之前分配的SDCCH到底是用來位置更新的了？還是CM SERVICE REQUEST 呼叫請求的了？？？？？
不懂別亂叫~```````````
很顯然LZ的問題答案應(yīng)該是CM SERVICE REQUEST 信令丟失 或者網(wǎng)絡(luò)原因沒有響應(yīng)。。
• 成都旗訊通信技術(shù)有限公司
聘：【移動項目】招督導、維護轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點：四川省,河南省,山東省,安徽省,湖北省
• 重慶信科通信工程有限公司 聘：南昌電信中興原廠高級
需求人數(shù)：2 人 地點：南昌市
• 嘉環(huán)科技股份有限公司 聘：核心網(wǎng)工程師-IMC青海
需求人數(shù)：2 人 地點：西寧市
• 上海德專信息技術(shù)有限公司 聘：內(nèi)蒙古初級后臺
需求人數(shù)：2 人 地點：內(nèi)蒙古
• 浙江明訊網(wǎng)絡(luò)技術(shù)有限公司 聘：浙江網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：2 人 地點：湖州市,寧波市
• 陜西瑞達灃通信技術(shù)有限公司 聘：內(nèi)蒙辦長期需求華為持證中高級人員
需求人數(shù)：30 人 地點：呼和浩特市,包頭市,巴彥淖爾市,鄂爾多斯市
• 南京順盛通信科技有限責任公司 聘：中興傳輸PTN/SPN工程師
需求人數(shù)：1 人 地點：徐州市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：急聘！華為項目（江蘇南京移動）
需求人數(shù)：30 人 地點：江蘇省
• 北京萬思維通信技術(shù)有限公司 聘：廣東 愛立信高端優(yōu)化后臺
需求人數(shù)：2 人 地點：廣東省
• 南京華蘇科技有限公司 聘：塔工（河南）
需求人數(shù)：5 人 地點：鄭州市,焦作市,新鄉(xiāng)市
需求人數(shù)：12 人 地點：四川省,河南省,山東省,安徽省,湖北省
• 重慶信科通信工程有限公司 聘：南昌電信中興原廠高級
需求人數(shù)：2 人 地點：南昌市
• 嘉環(huán)科技股份有限公司 聘：核心網(wǎng)工程師-IMC青海
需求人數(shù)：2 人 地點：西寧市
• 上海德專信息技術(shù)有限公司 聘：內(nèi)蒙古初級后臺
需求人數(shù)：2 人 地點：內(nèi)蒙古
• 浙江明訊網(wǎng)絡(luò)技術(shù)有限公司 聘：浙江網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：2 人 地點：湖州市,寧波市
• 陜西瑞達灃通信技術(shù)有限公司 聘：內(nèi)蒙辦長期需求華為持證中高級人員
需求人數(shù)：30 人 地點：呼和浩特市,包頭市,巴彥淖爾市,鄂爾多斯市
• 南京順盛通信科技有限責任公司 聘：中興傳輸PTN/SPN工程師
需求人數(shù)：1 人 地點：徐州市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：急聘！華為項目（江蘇南京移動）
需求人數(shù)：30 人 地點：江蘇省
• 北京萬思維通信技術(shù)有限公司 聘：廣東 愛立信高端優(yōu)化后臺
需求人數(shù)：2 人 地點：廣東省
• 南京華蘇科技有限公司 聘：塔工（河南）
需求人數(shù)：5 人 地點：鄭州市,焦作市,新鄉(xiāng)市
熱點問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動通信網(wǎng) © 2006 - |