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