 |
善于提問(wèn)，勤于回答，你也是專(zhuān)家
|
 |
問(wèn)題已開(kāi)啟
(普通問(wèn)題)
排隊(duì)長(zhǎng)度（MaxQueueLength）設(shè)置太長(zhǎng)會(huì)影響到 SDCCH 資源
為什么 有什么具體的流程 和資料
提問(wèn)者:
• GSM發(fā)現(xiàn)某個(gè)地區(qū)出現(xiàn)SDCCH擁塞怎么準(zhǔn)確定位到小區(qū) 2016-09-12
• MAXSDCCHNOTRX修改后不起效果 2016-06-27
• 愛(ài)立信雙倍SDCCH無(wú)法定義 2016-06-03
• GSM的sDCCH失敗原因中，由bcsu下門(mén)限或上門(mén)限過(guò)載引起的大量的sDCCH失敗，可能是由于什么造成的呢 2016-04-14
• sDCCH：2條改成1條如何修改？ 2016-03-01
• RPG版本是GARP2E新的TRH類(lèi)型載波容量與MAXNOSDCCHTRX這個(gè)參數(shù)的關(guān)系？ 2016-02-18
• NSNgsm用什么參數(shù)開(kāi)啟動(dòng)態(tài)SDCCH信道分配和增強(qiáng)型動(dòng)態(tài)SDCCH信道分配功能啊 2016-01-30
• bcsu過(guò)載下門(mén)限原因大量SDCCH失敗，尋呼量很高，引起的原因是什么，怎么解決 2016-01-25
• MAXSDCCHNOTRX修改后不起效果 2016-06-27
• 愛(ài)立信雙倍SDCCH無(wú)法定義 2016-06-03
• GSM的sDCCH失敗原因中，由bcsu下門(mén)限或上門(mén)限過(guò)載引起的大量的sDCCH失敗，可能是由于什么造成的呢 2016-04-14
• sDCCH：2條改成1條如何修改？ 2016-03-01
• RPG版本是GARP2E新的TRH類(lèi)型載波容量與MAXNOSDCCHTRX這個(gè)參數(shù)的關(guān)系？ 2016-02-18
• NSNgsm用什么參數(shù)開(kāi)啟動(dòng)態(tài)SDCCH信道分配和增強(qiáng)型動(dòng)態(tài)SDCCH信道分配功能啊 2016-01-30
• bcsu過(guò)載下門(mén)限原因大量SDCCH失敗，尋呼量很高，引起的原因是什么，怎么解決 2016-01-25
問(wèn)題答案
( 1 )
MaxQueueLength，就是常用的MQL參數(shù)。
樓主的問(wèn)題詳解如下：
1、當(dāng)用戶(hù)占用SDCCH的時(shí)候，原因一共有4種，短信息、主叫、被叫和位置更新。短信息和主被叫除了業(yè)務(wù)時(shí)間外大致相同，只有業(yè)務(wù)申請(qǐng)，其他一般都已經(jīng)省掉，所以一般它們占用SDCCH的時(shí)間可以控制在1.5s以下，在1.3s附近。而位置更新（包括普通位置更新和開(kāi)機(jī)過(guò)程，周期性位置更新和上面的情況一樣）一般會(huì)需要做鑒權(quán)、TMSI重分配、IMEI CHECK、業(yè)務(wù)申請(qǐng)和位置更新過(guò)程，前三項(xiàng)是集團(tuán)公司要求必須要做的，但是如果沒(méi)有省掉的話(huà)位置更新的時(shí)間大約需要2.5s，如果省掉的話(huà)則也可以把時(shí)間降低到1.5s以?xún)?nèi)；這樣的手段一般只在針對(duì)有第三方測(cè)試的時(shí)候用，不會(huì)在平時(shí)使用。
2、非常規(guī)占用在上面已經(jīng)提到，主要是針對(duì)Queueing 和 Directed Retry 來(lái)說(shuō)的，一般來(lái)說(shuō)，這兩個(gè)功能我們都會(huì)開(kāi)啟，對(duì)于Queueing來(lái)說(shuō)，存在呼叫和切換兩種情況，由于切換是在TCH的狀態(tài)，我們不加以討論，我們主要針對(duì)的是呼叫階段來(lái)說(shuō)，在呼叫嘗試的階段， Queueing 和 Directed Retry 是同時(shí)進(jìn)行的，在這個(gè)時(shí)間內(nèi)，如果哪個(gè)先成功，就會(huì)按照哪種方式獲得TCH。等待Queueing的用戶(hù)個(gè)數(shù)是由MQL參數(shù)來(lái)控制的， Directed Retry 的用戶(hù)個(gè)數(shù)則沒(méi)有找到相應(yīng)的理論根據(jù)，是和Queueing一起排隊(duì)還是另外的方法不是很清楚。但是在NED里有說(shuō)明就是在呼叫階段，如果Directed Retry 的MADR超時(shí)則會(huì)造成呼叫失敗，而不論TLC是否超時(shí)，所以決定我們占用SDCCH時(shí)間的參數(shù)就是MADR和MQL，并且Directed Retry 和Queueing是分別進(jìn)行排隊(duì)的。另外要注意的就是在進(jìn)行這兩個(gè)過(guò)程的時(shí)候都有T8來(lái)控制時(shí)間，T8一般為12s，所以一旦超過(guò)這個(gè)時(shí)間，所有的呼叫都會(huì)被終止。
3、當(dāng)TCH擁塞無(wú)信道可以分配的時(shí)候，手機(jī)處于Queueing 和 Directed Retry 的時(shí)候，如果MQL的長(zhǎng)度是50，則可以進(jìn)入Queueing的手機(jī)數(shù)量是載頻數(shù)量乘以8再除以2，如果載頻數(shù)量是4的話(huà)，則會(huì)有4*8/2=16個(gè)用戶(hù)處于等待TCH的分配，而他們會(huì)占用16個(gè)SDCCH信道，這樣的話(huà)會(huì)很容易造成SDCCH的擁塞，所以如果TCH擁塞較多且造成了SDCCH的擁塞的時(shí)候可以考慮降低MQL或者M(jìn)ADR，但是通常降低這兩個(gè)參數(shù)都會(huì)影響到接入成功率，所以調(diào)整這個(gè)參數(shù)的時(shí)候一定要注意跟蹤相關(guān)的KPI，確保調(diào)整后對(duì)這方面沒(méi)有負(fù)面影響。
希望能幫到樓主
樓主的問(wèn)題詳解如下：
1、當(dāng)用戶(hù)占用SDCCH的時(shí)候，原因一共有4種，短信息、主叫、被叫和位置更新。短信息和主被叫除了業(yè)務(wù)時(shí)間外大致相同，只有業(yè)務(wù)申請(qǐng)，其他一般都已經(jīng)省掉，所以一般它們占用SDCCH的時(shí)間可以控制在1.5s以下，在1.3s附近。而位置更新（包括普通位置更新和開(kāi)機(jī)過(guò)程，周期性位置更新和上面的情況一樣）一般會(huì)需要做鑒權(quán)、TMSI重分配、IMEI CHECK、業(yè)務(wù)申請(qǐng)和位置更新過(guò)程，前三項(xiàng)是集團(tuán)公司要求必須要做的，但是如果沒(méi)有省掉的話(huà)位置更新的時(shí)間大約需要2.5s，如果省掉的話(huà)則也可以把時(shí)間降低到1.5s以?xún)?nèi)；這樣的手段一般只在針對(duì)有第三方測(cè)試的時(shí)候用，不會(huì)在平時(shí)使用。
2、非常規(guī)占用在上面已經(jīng)提到，主要是針對(duì)Queueing 和 Directed Retry 來(lái)說(shuō)的，一般來(lái)說(shuō)，這兩個(gè)功能我們都會(huì)開(kāi)啟，對(duì)于Queueing來(lái)說(shuō)，存在呼叫和切換兩種情況，由于切換是在TCH的狀態(tài)，我們不加以討論，我們主要針對(duì)的是呼叫階段來(lái)說(shuō)，在呼叫嘗試的階段， Queueing 和 Directed Retry 是同時(shí)進(jìn)行的，在這個(gè)時(shí)間內(nèi)，如果哪個(gè)先成功，就會(huì)按照哪種方式獲得TCH。等待Queueing的用戶(hù)個(gè)數(shù)是由MQL參數(shù)來(lái)控制的， Directed Retry 的用戶(hù)個(gè)數(shù)則沒(méi)有找到相應(yīng)的理論根據(jù)，是和Queueing一起排隊(duì)還是另外的方法不是很清楚。但是在NED里有說(shuō)明就是在呼叫階段，如果Directed Retry 的MADR超時(shí)則會(huì)造成呼叫失敗，而不論TLC是否超時(shí)，所以決定我們占用SDCCH時(shí)間的參數(shù)就是MADR和MQL，并且Directed Retry 和Queueing是分別進(jìn)行排隊(duì)的。另外要注意的就是在進(jìn)行這兩個(gè)過(guò)程的時(shí)候都有T8來(lái)控制時(shí)間，T8一般為12s，所以一旦超過(guò)這個(gè)時(shí)間，所有的呼叫都會(huì)被終止。
3、當(dāng)TCH擁塞無(wú)信道可以分配的時(shí)候，手機(jī)處于Queueing 和 Directed Retry 的時(shí)候，如果MQL的長(zhǎng)度是50，則可以進(jìn)入Queueing的手機(jī)數(shù)量是載頻數(shù)量乘以8再除以2，如果載頻數(shù)量是4的話(huà)，則會(huì)有4*8/2=16個(gè)用戶(hù)處于等待TCH的分配，而他們會(huì)占用16個(gè)SDCCH信道，這樣的話(huà)會(huì)很容易造成SDCCH的擁塞，所以如果TCH擁塞較多且造成了SDCCH的擁塞的時(shí)候可以考慮降低MQL或者M(jìn)ADR，但是通常降低這兩個(gè)參數(shù)都會(huì)影響到接入成功率，所以調(diào)整這個(gè)參數(shù)的時(shí)候一定要注意跟蹤相關(guān)的KPI，確保調(diào)整后對(duì)這方面沒(méi)有負(fù)面影響。
希望能幫到樓主
回答者：
OscarDon
回答時(shí)間：2013-01-26 18:21
12
10
• 重慶信科通信工程有限公司
聘：南昌電信中興原廠(chǎng)高級(jí)
需求人數(shù)：2 人 地點(diǎn)：南昌市
• 上海大唐移動(dòng)通信設(shè)備有限公司 聘：網(wǎng)絡(luò)優(yōu)化RF工程師（河北保定）
需求人數(shù)：1 人 地點(diǎn)：保定市
• 成都旗訊通信技術(shù)有限公司 聘：【移動(dòng)項(xiàng)目】招督導(dǎo)、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：四川省,河南省,山東省,安徽省,湖北省
• 南京格安信息系統(tǒng)有限責(zé)任公司 聘：RF中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：北京市
• 北京萬(wàn)思維通信技術(shù)有限公司 聘：廣東 愛(ài)立信高端優(yōu)化后臺(tái)
需求人數(shù)：2 人 地點(diǎn)：廣東省
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：1 人 地點(diǎn)：上海市
• 南京華蘇科技有限公司 聘：中興固網(wǎng)多媒體工程師
需求人數(shù)：2 人 地點(diǎn)：濰坊市,濟(jì)南市
• 珠海世紀(jì)鼎利科技股份有限公司 聘：寧波投訴測(cè)試優(yōu)化工程師
需求人數(shù)：1 人 地點(diǎn)：寧波市
• 元道通信股份有限公司 聘：網(wǎng)優(yōu)工程師-黃山高級(jí)后臺(tái)
需求人數(shù)：3 人 地點(diǎn)：黃山市
• 北京電旗通訊技術(shù)股份有限公司 聘：中高級(jí)后臺(tái)優(yōu)化工程師-山東中興
需求人數(shù)：10 人 地點(diǎn)：菏澤市,濟(jì)寧市
需求人數(shù)：2 人 地點(diǎn)：南昌市
• 上海大唐移動(dòng)通信設(shè)備有限公司 聘：網(wǎng)絡(luò)優(yōu)化RF工程師（河北保定）
需求人數(shù)：1 人 地點(diǎn)：保定市
• 成都旗訊通信技術(shù)有限公司 聘：【移動(dòng)項(xiàng)目】招督導(dǎo)、維護(hù)轉(zhuǎn)網(wǎng)優(yōu)
需求人數(shù)：12 人 地點(diǎn)：四川省,河南省,山東省,安徽省,湖北省
• 南京格安信息系統(tǒng)有限責(zé)任公司 聘：RF中高級(jí)優(yōu)化工程師
需求人數(shù)：2 人 地點(diǎn)：北京市
• 北京萬(wàn)思維通信技術(shù)有限公司 聘：廣東 愛(ài)立信高端優(yōu)化后臺(tái)
需求人數(shù)：2 人 地點(diǎn)：廣東省
• 杭州東信網(wǎng)絡(luò)技術(shù)有限公司 聘：LTE/5G網(wǎng)絡(luò)中高級(jí)優(yōu)化工程師
需求人數(shù)：1 人 地點(diǎn)：上海市
• 南京華蘇科技有限公司 聘：中興固網(wǎng)多媒體工程師
需求人數(shù)：2 人 地點(diǎn)：濰坊市,濟(jì)南市
• 珠海世紀(jì)鼎利科技股份有限公司 聘：寧波投訴測(cè)試優(yōu)化工程師
需求人數(shù)：1 人 地點(diǎn)：寧波市
• 元道通信股份有限公司 聘：網(wǎng)優(yōu)工程師-黃山高級(jí)后臺(tái)
需求人數(shù)：3 人 地點(diǎn)：黃山市
• 北京電旗通訊技術(shù)股份有限公司 聘：中高級(jí)后臺(tái)優(yōu)化工程師-山東中興
需求人數(shù)：10 人 地點(diǎn)：菏澤市,濟(jì)寧市
熱點(diǎn)問(wèn)題
更多精彩
| 聯(lián)系我們 - 問(wèn)通信專(zhuān)家 | Powered by MSCBSC 移動(dòng)通信網(wǎng) © 2006 - |