從數(shù)據(jù)協(xié)議查看器中可以看到，WAP網(wǎng)關(guān)不斷重復(fù)發(fā)送序號為4的本組最后一個數(shù)據(jù)包，手機則因為未收到序號為1、2、3的數(shù)據(jù)包而不斷給WAP網(wǎng)關(guān)發(fā)送Negative Ack消息，并在Negative Ack消息中告知WAP網(wǎng)關(guān)1、2、3號數(shù)據(jù)包丟失，從這一現(xiàn)象看，WAP網(wǎng)關(guān)似乎始終沒有收到手機發(fā)送的Negative Ack消息，否則不會一直重復(fù)發(fā)送最后一個數(shù)據(jù)包�？梢园l(fā)在RLC/MAC層看看MS有沒有發(fā)起過UL TBF的建立請求。
懷疑，WAP網(wǎng)關(guān)收不到Negative Ack是由于手機始終未發(fā)出，而手機在WTP協(xié)議層面是在不斷嘗試發(fā)送的，但在負(fù)責(zé)無線鏈路控制的RLC/MAC協(xié)議層面，手機卻始終未發(fā)起過上行 TBF的建立請求，使得WTP協(xié)議無法成功發(fā)送Negative Ack消息，最終導(dǎo)致WAP網(wǎng)關(guān)超時取消數(shù)據(jù)傳輸。造成WAP下載的失敗。
3GPP規(guī)范定義，當(dāng)下行TBF存在時，由于手機監(jiān)聽PACCH信道而不是CCCH信道，因此如要建立上行TBF，需將Channel Request包含在Packet Downlink Ack/Nack消息中進行發(fā)送，而不是通過CCCH直接發(fā)送Channel Request，此時如果下行TBF中沒有數(shù)據(jù)傳輸，手機就不會發(fā)送Packet Downlink Ack/Nack消息，因而也就無法發(fā)送Channel Request。而只有在等待下行TBF釋放的階段才會出現(xiàn)有下行TBF存在，卻又沒有下行數(shù)據(jù)傳輸?shù)那闆r。下行數(shù)據(jù)傳輸完成后，手機等待下行TBF釋放的時長由T3192決定，當(dāng)手機發(fā)出對下行最后一個數(shù)據(jù)包的Packet Downlink Ack/Nack消息后，便啟動T3192，并繼續(xù)監(jiān)聽PACCH信道直至T3192超時。在上圖所示的WAP下載失敗中，可能是手機想發(fā)送Negative Ack時，T3192剛好在計時。