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