【正文】 在每個(gè)小區(qū)中每個(gè)尋呼組都對(duì)應(yīng)于一個(gè)尋呼子信道，移動(dòng)臺(tái)根據(jù)自身的 IMSI計(jì)算出它所屬的尋呼組，進(jìn)而計(jì)算出屬于該尋呼組的尋呼子信道位置，在實(shí)際網(wǎng)絡(luò)中，移動(dòng)臺(tái)只 “收聽 ”它所屬的尋呼子信道而忽略其它尋呼子信道的內(nèi)容，甚至在其它尋呼子信道期間關(guān)閉移動(dòng)臺(tái)中某些硬件設(shè)備的電源以節(jié)約移動(dòng)臺(tái)的功率開銷（即 DRX的來(lái)源）。尋呼信道復(fù)幀數(shù)（ MFR）是指以多少?gòu)?fù)幀數(shù)作為尋呼子信道的一個(gè)循環(huán)。專題 — MFR、 DRX參數(shù)實(shí)驗(yàn)MFR、 DRX概述 DRX（ DRX_TIMER_MAX）在 DRX模式中， MS僅收聽歸屬尋呼組的尋呼塊，而在非 DRX模式下， MS將收聽所有的 CCCH塊。非 DRX模式持續(xù)的時(shí)間由兩個(gè)參數(shù)共同決定： NON_DRX_TIMER和DRX_TIMER_MAX，等于兩者的最小值。 DRX_TIMER_MAX設(shè)定 MS在從分組傳輸模式進(jìn)入分組空閑模式時(shí)，執(zhí)行 NONDRX模式時(shí)長(zhǎng)的最大值。 NON_DRX_TIMER由 MS在 GPRS附著的過程中和 SGSN協(xié)商。 NON_DRX_TIMER的大小可以在ATTACHREQUEST中看到； DRX_TIMER_MAX的數(shù)值可從 SystemInformationType13中看到。DRX_TIMER_MAX的取值范圍為 0～ 7，表達(dá)的取值遵循公式： 2k1（其中 k=0時(shí)，表示參數(shù)值為 0），即參數(shù)取值為： 0， 1s、 2s、 4s……64s 。專題 — MFR、 DRX參數(shù)實(shí)驗(yàn)DRX模式與非 DRX模式概述當(dāng)移動(dòng)臺(tái)處在 DRX模式的時(shí)候，移動(dòng)臺(tái)只會(huì)監(jiān)聽和它尋呼組相關(guān)的尋呼子信道。若 PCU判斷該 MS正處于 DRX模式時(shí)，它將計(jì)算 MS屬于哪個(gè)尋呼組，并向 BTS發(fā)出資源分配消息，當(dāng) BTS收到該消息后將在 MS所偵聽的 CCCH信道上發(fā)出立即指配消息。 BS_PA_MFRMS定義了尋呼信道的復(fù)幀數(shù)，目前現(xiàn)網(wǎng)的默認(rèn)設(shè)置是 5，也就是說 MS在收聽了自己尋呼組所對(duì)應(yīng)的 CCCH塊后，將等待 4個(gè) 51復(fù)幀，繼續(xù)收聽的將是第 6個(gè) 51復(fù)幀的同樣位置的 CCCH塊。 MS如果錯(cuò)過了自己所偵聽的尋呼子信道，它將不得不再等待，直到下一個(gè)尋呼子信道到來(lái)。如果 MFR=5，那么在最壞的情況下， MS要收到立即指配的消息，就必須等待：5235ms=1175ms。如果立即指配消息隨機(jī)出現(xiàn)， MFR=5， MS要等待的平均時(shí)間就是：235ms（ 5+4+3+2+1） /5=705ms如果立即指配消息隨機(jī)出現(xiàn)， MFR=2，等待的平均時(shí)間就減少為：235ms（ 2+1） /2=節(jié)約的時(shí)間為 ?。?！專題 — MFR、 DRX參數(shù)實(shí)驗(yàn)DRX模式與非 DRX模式概述當(dāng) MS由分組傳輸模式返回分組空閑模式時(shí)（比如 TBF釋放），在DRX_TIMER_MAX與 NON_DRX_TIMER的共同作用下，如果 MS進(jìn)入非 DRX傳輸?shù)臓顟B(tài)，將如下圖所示： 在非 DRX模式期間內(nèi)， MS將收聽所有的 CCCH塊，同時(shí) PCU保留 MS相關(guān)的上下文。此時(shí)下行 TBF建立的立即指配消息不需要再計(jì)算尋呼組，可以直接在 AGCH上發(fā)送。所以設(shè)置了非 DRX模式后會(huì)大大縮短下行 TBF的建立時(shí)間，缺點(diǎn)是會(huì)加快手機(jī)電池的消耗。專題 — MFR、 DRX參數(shù)實(shí)驗(yàn)MFR、 DRX參數(shù)實(shí)驗(yàn)結(jié)果專題 — T3192參數(shù)實(shí)驗(yàn)T3192概述當(dāng) MS向網(wǎng)絡(luò)發(fā)送 “最后證實(shí)標(biāo)志 ”（ FAI）等于 “1”的 “分組下行證實(shí) /未證實(shí)”(PACKETDOWNLINKACK/NACK)消息時(shí)啟動(dòng)定時(shí)器 T3192，或者在以非確認(rèn)模式發(fā)送 “分組控制證實(shí) ”（ PACKETCONTROLACK）作為最后一個(gè)數(shù)據(jù)塊的響應(yīng)時(shí)， MS啟動(dòng)定時(shí)器 T3192。在 T3192期間，滿足啟動(dòng)條件時(shí)，將重新啟動(dòng)T3192。當(dāng)移動(dòng)臺(tái)收到 PCU發(fā)送的 “分組下行指配 ”（ PACKETDOWNLINKASSIGNMENT）消息或 “分組時(shí)隙重新配置 ”（ PACKETTIMESLOTRECONFIGURE）時(shí)，停止定時(shí)器 T3192。如果 T3192超時(shí)， MS將釋放 TBF相關(guān)資源并開始監(jiān)聽尋呼信道。 此參數(shù)以 500ms為單位進(jìn)行配置。在 TBF釋放階段，如果 MS處于半雙工狀態(tài)并且收到上行指配， MS將立即響應(yīng)該命令；如果在TBF釋放階段沒有收到上行指配， MS將進(jìn)入分組空閑模式，在雙傳輸模式時(shí)將進(jìn)入專用模式。在進(jìn)入空閑模式或?qū)Ｓ媚Ｊ綍r(shí)，根據(jù)協(xié)議，仍舊需要執(zhí)行一段非DRX時(shí)間。 專題 — T3192參數(shù)實(shí)驗(yàn)T3192概述該參數(shù)的設(shè)置越大， TBF相關(guān)資源保留（包括 TFI和時(shí)隙）的時(shí)間就越長(zhǎng)，相同TBF傳送占用的時(shí)間就越長(zhǎng)，容易導(dǎo)致?lián)砣?。而該參?shù)設(shè)置越小，因?yàn)?MS將很快將 TBF資源釋放掉，若網(wǎng)絡(luò)有新的下行數(shù)據(jù)到來(lái)，網(wǎng)絡(luò)必須發(fā)起尋呼或立即指配流程（若 MS處于就緒狀態(tài)），所以下行 TBF建立的時(shí)間就越長(zhǎng)。而如果網(wǎng)絡(luò)側(cè)新的下行數(shù)據(jù)到來(lái)時(shí)， T3192還未超時(shí)，則網(wǎng)絡(luò)可以直接發(fā)送 “分組下行指配 ”消息，來(lái)建立一個(gè)新的下行 TBF，縮短 TBF的建立時(shí)間。該參數(shù)的設(shè)置，應(yīng)充分考慮該小區(qū)的業(yè)務(wù)負(fù)荷、小區(qū)的業(yè)務(wù)模型，網(wǎng)絡(luò)資源較充足的情況下，應(yīng)盡量設(shè)置 T3192較大，減少新 TBF建立時(shí)間，提高數(shù)據(jù)傳輸速率。網(wǎng)絡(luò)側(cè)有相對(duì)應(yīng)的計(jì)數(shù)器 T3193， 要求 T3193必須大于 T3192。專題 — T3192參數(shù)實(shí)驗(yàn)T3192參數(shù)實(shí)驗(yàn)結(jié)果T3192設(shè)置為 秒 ， T3192會(huì)影響 TBF建立時(shí)間的長(zhǎng)短，常規(guī)情況下，當(dāng)一組數(shù)據(jù) RLC傳完之后，手機(jī)會(huì)啟動(dòng) T3192，等待 秒 (注意剛才在使用 PDCH時(shí)隙)，如果沒有續(xù)傳的指令， T3192超時(shí)，釋放下行 TBF而且開始監(jiān)視 Paging信道。當(dāng)再次有數(shù)據(jù)傳時(shí)，需要重新立即指配。這無(wú)形中延長(zhǎng)了 TBF建立時(shí)間。T3192 設(shè)置為 秒 ，容易導(dǎo)致 GPRSterritoryugradereject(%)，而且增加了PDP激活時(shí)間，降低了 PDP激活成功率。T3192 設(shè)置為 1 秒 ，對(duì)小數(shù)據(jù)交互多的 GPRS業(yè)務(wù)或小區(qū)重選等 TBF變更頻繁的地方的數(shù)據(jù)傳輸速度上有改善 ,而對(duì)于定點(diǎn)的穩(wěn)定大數(shù)據(jù)量的 FTP下載沒有正面或負(fù)面影響。專題 — BCCHTRX、 TCHTRX（HF/NHF）下 GPRS性能比較BCCH TRX、 TCH TRX（ HF/NHF）下 GPRS性能比較為明確了解 BCCH載頻、 TCH載頻在跳頻、非跳頻及不同編碼方式下 FTP下載速率的變化情況，尋找特定小區(qū)進(jìn)行了詳盡的測(cè)試 ，具體情況如下：p無(wú)線環(huán)境好、接收電平強(qiáng)測(cè)試地點(diǎn)設(shè)在一寫字樓內(nèi)，由于樓內(nèi)主要由微蜂窩覆蓋，周邊的無(wú)線環(huán)境較好，主控小區(qū)的電平遠(yuǎn)遠(yuǎn)高于相鄰小區(qū)，接收電平在－ 55dBm左右，在這種情況下通過測(cè)試發(fā)現(xiàn)，占用 BCCH或 TCH、跳頻或非跳頻之間的下載速率差異值不是很大。專題 — BCCHTRX、 TCHTRX（HF/NHF）下 GPRS性能比較p無(wú)線環(huán)境好、接收電平低測(cè)試地點(diǎn)為一寫字樓內(nèi)，用手機(jī)鎖頻到室外大站，接收電平在 85dBm左右，由于樓體的屏蔽雖然使服務(wù)小區(qū)電平很低，但周圍的干擾電平也很低無(wú)線環(huán)境較干凈。在這種情況下通過測(cè)試發(fā)現(xiàn)，占用 BCCH或 TCH、跳頻或非跳頻之間的下載速率差異值不是很大。BCCH TRX、 TCH TRX（ HF/NHF）下 GPRS性能比較專題 — BCCHTRX、 TCHTRX（HF/NHF）下 GPRS性能比較p無(wú)線環(huán)境差、接收電平低測(cè)試地點(diǎn)為一 16層建筑物頂層，用手機(jī)鎖頻的室外大站接收電平為－ 80dBm左右，由于樓頂?shù)臒o(wú)線環(huán)境較差，周圍較多大站飄來(lái)的信號(hào)對(duì)當(dāng)前小區(qū)帶來(lái)干擾。在這種情況下通過測(cè)試發(fā)現(xiàn)，占用 TCH載頻在跳頻和非跳頻情況下的下載速率差異較大， CS12與 CS34算法下下載速率差異較大。由于 BCCH載頻不參加跳頻，所以在跳頻或非跳頻之間測(cè)試值并無(wú)太大差異。所以只統(tǒng)計(jì)了 TCH載頻在跳頻或非跳頻情況下的測(cè)試結(jié)果。BCCH TRX、 TCH TRX（ HF/NHF）下 GPRS性能比較專題 — BCCHTRX、 TCHTRX（HF/NHF）下 GPRS性能比較通過對(duì)測(cè)試結(jié)果的分析發(fā)現(xiàn)，在無(wú)線環(huán)境較差的條件下，打開跳頻比關(guān)閉跳頻的下載速率慢，打開 CS34比 CS12算法下的下載速率慢。造成上述現(xiàn)象的主要原因是：由于跳頻技術(shù)的主要特點(diǎn)是將被干擾的信息塊 “打散 ”，分配到若干載頻上，使得原來(lái)集中在一個(gè)載頻上的干擾被幾個(gè)載頻分擔(dān)了。通過如此做法可將由干擾帶來(lái)的掉話概率大大降低。但對(duì)于 GPRS業(yè)務(wù)則恰恰相反，在非跳頻的情況下干擾電平集中在一個(gè)頻點(diǎn)上，因此只會(huì)對(duì)這一載頻上的包做重傳。但如果打開跳頻，則所有載頻上都會(huì)有被干擾的信息快，因此都需要重傳，從而大大降低下載速率。測(cè)試結(jié)果對(duì)比分析專題 — BCCHTRX、 TCHTRX（HF/NHF）下 GPRS性能比較測(cè)試結(jié)果對(duì)比分析216。 GPRS數(shù)據(jù)傳輸性能與無(wú)線環(huán)境有直接的關(guān)系，而與信號(hào)接收電平關(guān)系不明顯216。當(dāng)無(wú)線環(huán)境很好時(shí)，在 BCCH、 TCH跳頻和不跳頻下測(cè)試的結(jié)果相差不大；但如果無(wú)線環(huán)境不好， TCH跳頻情況下 GPRS性能要遠(yuǎn)差于非跳頻的情況，特別當(dāng)所在小區(qū)打開 CS34功能時(shí)，影響更為明顯，因此對(duì)于此種特定環(huán)境下為保證 GPRS性能，不建議開跳頻，這與話音業(yè)務(wù)有一定的矛盾，需要權(quán)衡考慮216。不建議跳頻 TCH載頻開 CS34功能，目前 CS34功能僅限于在 BCCH載頻上開啟專題 — 假事件假事件案例 1—FTP 下載失敗通過對(duì) Gi口抓包分析，發(fā)現(xiàn)在登陸 FTP服務(wù)器成功后， FTP服務(wù)器就因收到 [RESET]消息而停止發(fā)送數(shù)據(jù)。由于發(fā)送端已中止發(fā)送，而在手機(jī)終端側(cè) FTP下載測(cè)試進(jìn)程并沒有停止，最終測(cè)試軟件判斷超時(shí)失敗。該種情況主要是由于位置更新導(dǎo)致登陸服務(wù)器中斷， FTP登陸時(shí) TCP協(xié)議進(jìn)程因丟包出現(xiàn)錯(cuò)誤，而從測(cè)試軟件的表象上看，已顯示成功登陸，但無(wú)法下載數(shù)據(jù)。專題 — 假事件從測(cè)試設(shè)備抓包可以看到已經(jīng)成功接收到 FTPDATA包，但是卻沒有將收到的數(shù)據(jù)包變?yōu)橛行?shù)據(jù)，最終導(dǎo)致接收窗口溢出，數(shù)據(jù)傳輸中止。而 FTP下載測(cè)試進(jìn)程同樣并沒有停止，最終測(cè)試軟件判斷超時(shí)失敗。 該種情況同樣是由于位置更新導(dǎo)致登陸服務(wù)器中斷，雖然 FTP登陸 TCP協(xié)議進(jìn)程正常，可以正常傳輸數(shù)據(jù)，但是 FTPDATA仍然出錯(cuò)。假事件案例 1—FTP 下載失敗專題 — 假事件總之，上述兩種 FTP下載的斷線情況均是由于 FTP協(xié)議出現(xiàn)錯(cuò)誤導(dǎo)致 ，該錯(cuò)誤出現(xiàn)在 TCP/IP的傳輸層和應(yīng)用層，而不是由 GPRS網(wǎng)絡(luò)層故障引起。從測(cè)試軟件上看，都是在登陸 FTP服務(wù)器后無(wú)法接收應(yīng)用層數(shù)據(jù)，最后超時(shí)顯示 FTPdownloadfail，統(tǒng)計(jì)為掉線一次。但是因 PING可以成功，說明網(wǎng)絡(luò)傳輸通路正常，不屬于集團(tuán)公司考核中的掉線定義范圍。 假事件案例 1—FTP 下載失敗專題 — 假事件問題：在手機(jī) Get需要的網(wǎng)頁(yè)后， WAP網(wǎng)關(guān)回 “URLNOTEXIST”消息。該消息是WAP網(wǎng)關(guān)收到 SP服務(wù)器回應(yīng)的 “服務(wù)暫時(shí)中斷 ”消息后作出的響應(yīng)。解決方案：該次測(cè)試在 CDS后處理軟件中將被剔除。不作為一次測(cè)試嘗試。假事件案例 2—WAP 圖鈴下載失敗專題 — 假事件問題： MS在 CI1763發(fā)送 MMS時(shí)失敗，從 log中看被叫手機(jī)無(wú)相應(yīng)信令下發(fā)，MS在此時(shí)處于 Standby狀態(tài)，查看信令發(fā)現(xiàn)該時(shí)段主叫手機(jī)有 SMS進(jìn)來(lái)。檢查該時(shí)段 OMCKPI看出該小區(qū)有很小比例的 DLTBFDropRate是由于 suspend和noresponse的原因?qū)е碌?。判斷次?CASE是由于 SMS進(jìn)來(lái)導(dǎo)致手機(jī)做了 RAU，網(wǎng)絡(luò)延遲加大造成的 MMS發(fā)送失敗。 解決方案：關(guān)閉測(cè)試卡所有短信定制服務(wù)。假事件案例 3—MMS 發(fā)送失敗 交 流 討 論演講完畢，謝謝觀