 |
善于提問，勤于回答，你也是專家
|
 |
問題已開啟
(普通問題)
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？無論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
提問者:
• 求高手指點(diǎn)：尋呼成功率提升 2018-08-30
• 尋呼復(fù)幀數(shù)怎么理解 2018-08-16
• 撥測(cè)里面的尋呼和回落和是什么意思，有什么差別 2018-08-04
• 尋呼由網(wǎng)絡(luò)向什么狀態(tài)下的UE發(fā)起 2018-04-27
• 主叫尋呼是怎么找到被叫用戶的？一個(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語音和短信同時(shí)尋呼的流程 2017-07-10
• 尋呼復(fù)幀數(shù)怎么理解 2018-08-16
• 撥測(cè)里面的尋呼和回落和是什么意思，有什么差別 2018-08-04
• 尋呼由網(wǎng)絡(luò)向什么狀態(tài)下的UE發(fā)起 2018-04-27
• 主叫尋呼是怎么找到被叫用戶的？一個(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語音和短信同時(shí)尋呼的流程 2017-07-10
問題答案
( 6 )
主叫呼叫建立（Call proceeding）后，核心網(wǎng)開始下發(fā)paging消息給被叫
回答者：
mobile_luocheng
回答時(shí)間：2012-02-09 09:33
20
13
關(guān)于何時(shí)開始尋呼，有幾種方案供選擇，各種方法有利有弊，LS的是其中1種。
目前TD網(wǎng)絡(luò)實(shí)際用是NB給主叫下發(fā)Call proceeding，主叫RB建立，RB建立完成之后，核心網(wǎng)才開始下發(fā)尋呼。
LS的方案有利于提高呼叫建立時(shí)延，如果網(wǎng)絡(luò)質(zhì)量非常好，能提高用戶的接通速度（呼叫建立時(shí)延）感知。
目前的方案也是從用戶感知度及指標(biāo)考核從發(fā)的。假如在發(fā)送Call proceeding之后就尋呼的話，主叫RB建立失敗，而被叫RB建立成功，這樣就會(huì)導(dǎo)致用戶感知很差（接了電話，對(duì)方掉了還以為對(duì)方不說話）。
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)才開始下發(fā)尋呼。
LS的方案有利于提高呼叫建立時(shí)延，如果網(wǎng)絡(luò)質(zhì)量非常好，能提高用戶的接通速度（呼叫建立時(shí)延）感知。
目前的方案也是從用戶感知度及指標(biāo)考核從發(fā)的。假如在發(fā)送Call proceeding之后就尋呼的話，主叫RB建立失敗，而被叫RB建立成功，這樣就會(huì)導(dǎo)致用戶感知很差（接了電話，對(duì)方掉了還以為對(duì)方不說話）。
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í)候還是遇到你說的另外的一種情況的，納悶了很就沒得到解決，2F一說我就豁然開朗了。
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？
從目前我測(cè)試的情況來是說看信令來說還是Call proceeding下發(fā)之后，核心網(wǎng)開始下發(fā)paging消息給被叫。至于為什么，參考2F的說法，他的回答也幫助了我。
無論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
這個(gè)從路測(cè)測(cè)試來看，是這樣的，不管被叫收到尋呼消息與否，主叫還是正常建立的。至于為什么，這個(gè)我也說不上來，這里就不瞎說了，靜等后面的高手也給我解惑吧！
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？
從目前我測(cè)試的情況來是說看信令來說還是Call proceeding下發(fā)之后，核心網(wǎng)開始下發(fā)paging消息給被叫。至于為什么，參考2F的說法，他的回答也幫助了我。
無論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
這個(gè)從路測(cè)測(cè)試來看，是這樣的，不管被叫收到尋呼消息與否，主叫還是正常建立的。至于為什么，這個(gè)我也說不上來，這里就不瞎說了，靜等后面的高手也給我解惑吧！
回答者：
C羅
回答時(shí)間：2012-02-09 16:09
14
18
在主叫信令走到那步時(shí)被叫手機(jī)收到尋呼消息，為什么？
2F的解釋很好，主要看核心網(wǎng)的設(shè)置，由核心網(wǎng)來決定paging發(fā)給被叫所在ran的時(shí)機(jī)。
無論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
先理解什么是RAB
RAB（Radio Access Bearer）是指用戶平面的承載，用于UE和CN之間傳送語音數(shù)據(jù)及多媒體業(yè)務(wù)。
當(dāng)RRC連接建立以后，UE與CN之間的控制面鏈路已經(jīng)打通了，UE通過直傳把NAS層消息送給CN，CN由此知道UE進(jìn)行什么業(yè)務(wù)，并且依據(jù)相應(yīng)的QoS建立RAB，用以建立用戶面的連接。
當(dāng)RAB成功建立后，MOC的控制面和用戶面承載才算是完成了，此時(shí)CN可以依據(jù)被叫的尋呼情況發(fā)送alerting給MOC，當(dāng)然這也是使用NAS消息。
MOC的控制面、用戶面建立與MTC的狀態(tài)沒有關(guān)系。如果MTC尋呼失敗，CN還是需要使用MOC的用戶面發(fā)送錄音通知；尋呼成功則發(fā)送回鈴音或彩鈴。
2F的解釋很好，主要看核心網(wǎng)的設(shè)置，由核心網(wǎng)來決定paging發(fā)給被叫所在ran的時(shí)機(jī)。
無論被叫UE是否收到尋呼消息，主叫的RAB都是正常建立，為什么？
先理解什么是RAB
RAB（Radio Access Bearer）是指用戶平面的承載，用于UE和CN之間傳送語音數(shù)據(jù)及多媒體業(yè)務(wù)。
當(dāng)RRC連接建立以后，UE與CN之間的控制面鏈路已經(jīng)打通了，UE通過直傳把NAS層消息送給CN，CN由此知道UE進(jìn)行什么業(yè)務(wù)，并且依據(jù)相應(yīng)的QoS建立RAB，用以建立用戶面的連接。
當(dāng)RAB成功建立后，MOC的控制面和用戶面承載才算是完成了，此時(shí)CN可以依據(jù)被叫的尋呼情況發(fā)送alerting給MOC，當(dāng)然這也是使用NAS消息。
MOC的控制面、用戶面建立與MTC的狀態(tài)沒有關(guān)系。如果MTC尋呼失敗，CN還是需要使用MOC的用戶面發(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ì)被叫的尋呼。在此過程中主叫側(cè)的信令則根據(jù)CN的配置（早指配和晚指配）而有所不同，這也導(dǎo)致主被叫信令同時(shí)觀察時(shí)看到的被叫的paging消息下發(fā)的順序存在差異
回答者：
marinelick
回答時(shí)間：2012-02-11 08:55
23
23
• 南京華蘇科技有限公司
聘：性能后臺(tái)-深圳移動(dòng)日常
需求人數(shù)：3 人 地點(diǎn)：深圳市
• 上海瑞禾通訊技術(shù)有限公司 聘：廣州中高級(jí)工程師
需求人數(shù)：3 人 地點(diǎn)：廣州市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點(diǎn)：長(zhǎng)沙市,永州市,郴州市,衡陽市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：貴州電信網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：1 人 地點(diǎn)：貴州省
• 重慶信科通信工程有限公司 聘：后臺(tái)優(yōu)化
需求人數(shù)：2 人 地點(diǎn)：南昌市
• 成都旗訊通信技術(shù)有限公司 聘：電聯(lián)招聘督導(dǎo)、傳輸、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：浙江省,江蘇省,河北省,山西省,遼寧省
• 怡利科技發(fā)展有限公司 聘：網(wǎng)優(yōu)工程師（初級(jí)）
需求人數(shù)：5 人 地點(diǎn)：貴州省
• 北京電旗通訊技術(shù)股份有限公司 聘：網(wǎng)優(yōu)實(shí)習(xí)生通信應(yīng)屆生（云南）
需求人數(shù)：1 人 地點(diǎn)：昆明市,思茅市,昭通市
• 南京格安信息系統(tǒng)有限責(zé)任公司 聘：5G工程單驗(yàn)人員
需求人數(shù)：10 人 地點(diǎn)：北京市
• 福建省鴻官通信工程有限公司 聘：網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：牡丹江市
需求人數(shù)：3 人 地點(diǎn)：深圳市
• 上海瑞禾通訊技術(shù)有限公司 聘：廣州中高級(jí)工程師
需求人數(shù)：3 人 地點(diǎn)：廣州市
• 嘉環(huán)科技股份有限公司 聘：湖南電信原廠優(yōu)化招聘
需求人數(shù)：10 人 地點(diǎn)：長(zhǎng)沙市,永州市,郴州市,衡陽市
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：貴州電信網(wǎng)優(yōu)高級(jí)工程師
需求人數(shù)：1 人 地點(diǎn)：貴州省
• 重慶信科通信工程有限公司 聘：后臺(tái)優(yōu)化
需求人數(shù)：2 人 地點(diǎn)：南昌市
• 成都旗訊通信技術(shù)有限公司 聘：電聯(lián)招聘督導(dǎo)、傳輸、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：浙江省,江蘇省,河北省,山西省,遼寧省
• 怡利科技發(fā)展有限公司 聘：網(wǎng)優(yōu)工程師（初級(jí)）
需求人數(shù)：5 人 地點(diǎn)：貴州省
• 北京電旗通訊技術(shù)股份有限公司 聘：網(wǎng)優(yōu)實(shí)習(xí)生通信應(yīng)屆生（云南）
需求人數(shù)：1 人 地點(diǎn)：昆明市,思茅市,昭通市
• 南京格安信息系統(tǒng)有限責(zé)任公司 聘：5G工程單驗(yàn)人員
需求人數(shù)：10 人 地點(diǎn)：北京市
• 福建省鴻官通信工程有限公司 聘：網(wǎng)絡(luò)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：牡丹江市
熱點(diǎn)問題
更多精彩
| 聯(lián)系我們 - 問通信專家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |