Nokia E52 doest reply to PUAN message properly
When we indicate MS that we have Nack in receiving window(in PUAN). Nokia E52 MS doesn’t honor that and keeps sending the new RLC blocks even when it crosses its transmit window in UL. causing the reception of RLC blocks outside RLC window.
below is PCU log snippet for one such example:
encoding.cpp:676 - EGPRS URBB, len = 11, SSN = 671, ESN_CRBB = 670, SNS = 2048, WS = 64, V(Q) = 670, V(R) = 682, BOW, EOW
message = 40 24 01 1f 3e 90 00 92 f0 8d 35 3e ff c3 2b 2b 2b 2b 2b 2b 2b 2b 2b
Below is the decoded message.
1... .... = ACKNACK: (Union)
.000 1101 0... .... = ACKNACK Dissector length: 26
.0.. .... = FINAL_ACK_INDICATION: False
..1. .... = BEGINNING_OF_WINDOW: 1
...1 .... = END_OF_WINDOW: 1
.... 0101 0011 111. = STARTING_SEQUENCE_NUMBER: 671
.... ...0 = CRBB Exist: 0
1111 1111 110. .... = URBB_BITMAP: 2046
Other MS like LG F70 and Lenovo K4 note behaves properly for this kind of PUAN with nacked bits present in it.
further investigation needs to be done
#1 Updated by arvind.sirsikar about 4 years ago
It is seen that, E52 asks RLC UL MODE as UM. And there is no IE to indicate the RLC mode for UL in prior rel6 versions in Packet UL assignment. But PCU currently supports only AM mode. so there is out of sync between RLC mode at MS and PCU. With this, even if 1 RLC block needs to be re transmitted from MS, PCU waits indefinitely. But MS keeps sending only fresh RLC blocks. and PCU keeps printing "out of window". and we see data break at end to end testing(using Iperf).
So with this analysis, we conclude it is mandatory to support RLC UM mode at least for UL direction. In our testing we have also seen that, we can have different RLC mode for UL and DL direction.