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