 |
善于提問(wèn)，勤于回答，你也是專(zhuān)家
|
 |
問(wèn)題已開(kāi)啟
(普通問(wèn)題)
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？無(wú)論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
提問(wèn)者:
• 求高手指點(diǎn)：尋呼成功率提升 2018-08-30
• 尋呼復(fù)幀數(shù)怎么理解 2018-08-16
• 撥測(cè)里面的尋呼和回落和是什么意思，有什么差別 2018-08-04
• 尋呼由網(wǎng)絡(luò)向什么狀態(tài)下的UE發(fā)起 2018-04-27
• 主叫尋呼是怎么找到被叫用戶(hù)的？一個(gè)號(hào)碼只對(duì)應(yīng)一個(gè)s-tmsi嗎？ 2017-11-11
• 哪位高手幫忙解釋一下，CSFB回落成功率，CSFB尋呼成功率，對(duì)應(yīng)的信令統(tǒng)計(jì)節(jié)點(diǎn)分別是哪條信令？ 2017-09-13
• 尋呼信道占用多少個(gè)PRB 2017-09-08
• GSM語(yǔ)音和短信同時(shí)尋呼的流程 2017-07-10
• 尋呼復(fù)幀數(shù)怎么理解 2018-08-16
• 撥測(cè)里面的尋呼和回落和是什么意思，有什么差別 2018-08-04
• 尋呼由網(wǎng)絡(luò)向什么狀態(tài)下的UE發(fā)起 2018-04-27
• 主叫尋呼是怎么找到被叫用戶(hù)的？一個(gè)號(hào)碼只對(duì)應(yīng)一個(gè)s-tmsi嗎？ 2017-11-11
• 哪位高手幫忙解釋一下，CSFB回落成功率，CSFB尋呼成功率，對(duì)應(yīng)的信令統(tǒng)計(jì)節(jié)點(diǎn)分別是哪條信令？ 2017-09-13
• 尋呼信道占用多少個(gè)PRB 2017-09-08
• GSM語(yǔ)音和短信同時(shí)尋呼的流程 2017-07-10
問(wèn)題答案
( 6 )
主叫呼叫建立（Call proceeding）后，核心網(wǎng)開(kāi)始下發(fā)paging消息給被叫
回答者：
mobile_luocheng
回答時(shí)間：2012-02-09 09:33
20
13
關(guān)于何時(shí)開(kāi)始尋呼，有幾種方案供選擇，各種方法有利有弊，LS的是其中1種。
目前TD網(wǎng)絡(luò)實(shí)際用是NB給主叫下發(fā)Call proceeding，主叫RB建立，RB建立完成之后，核心網(wǎng)才開(kāi)始下發(fā)尋呼。
LS的方案有利于提高呼叫建立時(shí)延，如果網(wǎng)絡(luò)質(zhì)量非常好，能提高用戶(hù)的接通速度（呼叫建立時(shí)延）感知。
目前的方案也是從用戶(hù)感知度及指標(biāo)考核從發(fā)的。假如在發(fā)送Call proceeding之后就尋呼的話，主叫RB建立失敗，而被叫RB建立成功，這樣就會(huì)導(dǎo)致用戶(hù)感知很差（接了電話，對(duì)方掉了還以為對(duì)方不說(shuō)話）。
P.s:個(gè)人認(rèn)為下發(fā)Call proceeding的原本意義應(yīng)該就是告訴主叫，我馬上去幫你尋呼，你等等。隨著時(shí)間的推移，人們關(guān)注的東西不一樣了，所以原本的意義也變了。
目前TD網(wǎng)絡(luò)實(shí)際用是NB給主叫下發(fā)Call proceeding，主叫RB建立，RB建立完成之后，核心網(wǎng)才開(kāi)始下發(fā)尋呼。
LS的方案有利于提高呼叫建立時(shí)延，如果網(wǎng)絡(luò)質(zhì)量非常好，能提高用戶(hù)的接通速度（呼叫建立時(shí)延）感知。
目前的方案也是從用戶(hù)感知度及指標(biāo)考核從發(fā)的。假如在發(fā)送Call proceeding之后就尋呼的話，主叫RB建立失敗，而被叫RB建立成功，這樣就會(huì)導(dǎo)致用戶(hù)感知很差（接了電話，對(duì)方掉了還以為對(duì)方不說(shuō)話）。
P.s:個(gè)人認(rèn)為下發(fā)Call proceeding的原本意義應(yīng)該就是告訴主叫，我馬上去幫你尋呼，你等等。隨著時(shí)間的推移，人們關(guān)注的東西不一樣了，所以原本的意義也變了。
回答者：
adsn
回答時(shí)間：2012-02-09 10:41
16
13
呵呵，謝謝2F的講解，一下子我就明白了，以前也和1F的想法一樣的，但是路測(cè)的時(shí)候還是遇到你說(shuō)的另外的一種情況的，納悶了很就沒(méi)得到解決，2F一說(shuō)我就豁然開(kāi)朗了。
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？
從目前我測(cè)試的情況來(lái)是說(shuō)看信令來(lái)說(shuō)還是Call proceeding下發(fā)之后，核心網(wǎng)開(kāi)始下發(fā)paging消息給被叫。至于為什么，參考2F的說(shuō)法，他的回答也幫助了我。
無(wú)論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
這個(gè)從路測(cè)測(cè)試來(lái)看，是這樣的，不管被叫收到尋呼消息與否，主叫還是正常建立的。至于為什么，這個(gè)我也說(shuō)不上來(lái)，這里就不瞎說(shuō)了，靜等后面的高手也給我解惑吧！
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？
從目前我測(cè)試的情況來(lái)是說(shuō)看信令來(lái)說(shuō)還是Call proceeding下發(fā)之后，核心網(wǎng)開(kāi)始下發(fā)paging消息給被叫。至于為什么，參考2F的說(shuō)法，他的回答也幫助了我。
無(wú)論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
這個(gè)從路測(cè)測(cè)試來(lái)看，是這樣的，不管被叫收到尋呼消息與否，主叫還是正常建立的。至于為什么，這個(gè)我也說(shuō)不上來(lái)，這里就不瞎說(shuō)了，靜等后面的高手也給我解惑吧！
回答者：
C羅
回答時(shí)間：2012-02-09 16:09
14
18
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？
2F的解釋很好，主要看核心網(wǎng)的設(shè)置，由核心網(wǎng)來(lái)決定paging發(fā)給被叫所在ran的時(shí)機(jī)。
無(wú)論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
先理解什么是RAB
RAB（Radio Access Bearer）是指用戶(hù)平面的承載，用于UE和CN之間傳送語(yǔ)音數(shù)據(jù)及多媒體業(yè)務(wù)。
當(dāng)RRC連接建立以后，UE與CN之間的控制面鏈路已經(jīng)打通了，UE通過(guò)直傳把NAS層消息送給CN，CN由此知道UE進(jìn)行什么業(yè)務(wù)，并且依據(jù)相應(yīng)的QoS建立RAB，用以建立用戶(hù)面的連接。
當(dāng)RAB成功建立后，MOC的控制面和用戶(hù)面承載才算是完成了，此時(shí)CN可以依據(jù)被叫的尋呼情況發(fā)送alerting給MOC，當(dāng)然這也是使用NAS消息。
MOC的控制面、用戶(hù)面建立與MTC的狀態(tài)沒(méi)有關(guān)系。如果MTC尋呼失敗，CN還是需要使用MOC的用戶(hù)面發(fā)送錄音通知；尋呼成功則發(fā)送回鈴音或彩鈴。
2F的解釋很好，主要看核心網(wǎng)的設(shè)置，由核心網(wǎng)來(lái)決定paging發(fā)給被叫所在ran的時(shí)機(jī)。
無(wú)論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
先理解什么是RAB
RAB（Radio Access Bearer）是指用戶(hù)平面的承載，用于UE和CN之間傳送語(yǔ)音數(shù)據(jù)及多媒體業(yè)務(wù)。
當(dāng)RRC連接建立以后，UE與CN之間的控制面鏈路已經(jīng)打通了，UE通過(guò)直傳把NAS層消息送給CN，CN由此知道UE進(jìn)行什么業(yè)務(wù)，并且依據(jù)相應(yīng)的QoS建立RAB，用以建立用戶(hù)面的連接。
當(dāng)RAB成功建立后，MOC的控制面和用戶(hù)面承載才算是完成了，此時(shí)CN可以依據(jù)被叫的尋呼情況發(fā)送alerting給MOC，當(dāng)然這也是使用NAS消息。
MOC的控制面、用戶(hù)面建立與MTC的狀態(tài)沒(méi)有關(guān)系。如果MTC尋呼失敗，CN還是需要使用MOC的用戶(hù)面發(fā)送錄音通知；尋呼成功則發(fā)送回鈴音或彩鈴。
回答者：
dexter11
回答時(shí)間：2012-02-10 00:27
16
15
看一下測(cè)試log的尋呼信令不就知道了嗎
回答者：
taomingshun
回答時(shí)間：2012-02-10 14:11
15
17
主叫側(cè)在setup這條信令中將被叫的電話號(hào)碼發(fā)給CN，而CN根據(jù)此電話號(hào)碼查找到被叫的IMSI從而發(fā)起對(duì)被叫的尋呼。在此過(guò)程中主叫側(cè)的信令則根據(jù)CN的配置（早指配和晚指配）而有所不同，這也導(dǎo)致主被叫信令同時(shí)觀察時(shí)看到的被叫的paging消息下發(fā)的順序存在差異
回答者：
marinelick
回答時(shí)間：2012-02-11 08:55
24
24
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司
聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：上海市
• 西安中興精誠(chéng)通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：重慶市
• 廣東世炬網(wǎng)絡(luò)科技股份有限公司 聘：網(wǎng)管運(yùn)維工程師
需求人數(shù)：2 人 地點(diǎn)：云南省
• 嘉環(huán)科技股份有限公司 聘：網(wǎng)優(yōu)前臺(tái)RF工程師-高級(jí)
需求人數(shù)：2 人 地點(diǎn)：河源市
• 南京華蘇科技有限公司 聘：濟(jì)南省移動(dòng)高端-材料輸出高手優(yōu)先
需求人數(shù)：1 人 地點(diǎn)：濟(jì)南市
• 北京電旗通訊技術(shù)股份有限公司 聘：山東濱州電信
需求人數(shù)：3 人 地點(diǎn)：濱州市
• 成都旗訊通信技術(shù)有限公司 聘：【聯(lián)通項(xiàng)目】招督導(dǎo)、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：河北省,遼寧省,吉林省,黑龍江,內(nèi)蒙古
• 北京宜通華瑞科技有限公司 聘：電信原廠優(yōu)化高級(jí)（江西急聘）
需求人數(shù)：5 人 地點(diǎn)：南昌市
• 廣東華訊工程有限公司 聘：廣東移動(dòng)維護(hù)支撐
需求人數(shù)：2 人 地點(diǎn)：廣州市
• 重慶信科通信工程有限公司 聘：南昌電信中興原廠高級(jí)
需求人數(shù)：2 人 地點(diǎn)：南昌市
需求人數(shù)：2 人 地點(diǎn)：上海市
• 西安中興精誠(chéng)通訊有限公司 聘：重慶-網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：2 人 地點(diǎn)：重慶市
• 廣東世炬網(wǎng)絡(luò)科技股份有限公司 聘：網(wǎng)管運(yùn)維工程師
需求人數(shù)：2 人 地點(diǎn)：云南省
• 嘉環(huán)科技股份有限公司 聘：網(wǎng)優(yōu)前臺(tái)RF工程師-高級(jí)
需求人數(shù)：2 人 地點(diǎn)：河源市
• 南京華蘇科技有限公司 聘：濟(jì)南省移動(dòng)高端-材料輸出高手優(yōu)先
需求人數(shù)：1 人 地點(diǎn)：濟(jì)南市
• 北京電旗通訊技術(shù)股份有限公司 聘：山東濱州電信
需求人數(shù)：3 人 地點(diǎn)：濱州市
• 成都旗訊通信技術(shù)有限公司 聘：【聯(lián)通項(xiàng)目】招督導(dǎo)、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：河北省,遼寧省,吉林省,黑龍江,內(nèi)蒙古
• 北京宜通華瑞科技有限公司 聘：電信原廠優(yōu)化高級(jí)（江西急聘）
需求人數(shù)：5 人 地點(diǎn)：南昌市
• 廣東華訊工程有限公司 聘：廣東移動(dòng)維護(hù)支撐
需求人數(shù)：2 人 地點(diǎn)：廣州市
• 重慶信科通信工程有限公司 聘：南昌電信中興原廠高級(jí)
需求人數(shù)：2 人 地點(diǎn)：南昌市
熱點(diǎn)問(wèn)題
更多精彩
| 聯(lián)系我們 - 問(wèn)通信專(zhuān)家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |