Vladimir Rolbin wrote:
Hi Andreas and Ivan.
 
I've recorded three sessions, every one contains pcu log with print fix andreas asked (rlcmac_*.log) and corresponding  GSMTAP and Gb pcap:
 
1)  openBTS pulled from git on 31.10.2012 (with gsmtap support for PDCH), UE - Nokia 5000d.
      I have very bad results with Nokia and SonyEriccsson devices with not modified git branch.
      As I wrote before I guess  they are sensitive to non-standard L2 pseudo length. Immediate Assignment
      is already fixed for now but SI13 is not. I sent my modifications before.. a great part of them are
      really debug prints, but the other one fixes the Nokia device behaviour ( session 2).
 
2) modified openBTS merged   with openBTS pulled from git on 31.10.2012, UE - Nokia 5000d.
     m.facebook.com is successfully opened. No scheduler issues. But sometimes it  has..
     I need to open more pages one after one to see the problem.
 
3) modified openBTS merged   with openBTS pulled from git on 31.10.2012 (env is like in session 2).
     UE - SonyEricsson z750i. A lot of scheduler issues (look for "unknown"). I think this UE is more
     pedantic than others.
 
   Regards,
   Vladimir Rolbin

   
 
 
On Wed, Oct 31, 2012 at 8:00 AM, jolly <andreas@eversberg.eu> wrote:
Vladimir Rolbin wrote:
> gprs_rlcmac_data.cpp:1532 Polling sheduled in this TS 7
hi vladimir,

i missed something. this debug line above does not show us the frame
number. you can change that debug line to:

LOGP(DRLCMAC, LOGL_DEBUG, "Polling sheduled in this "
    "TS %d, FN=%d\n", ts, fn);

regards,

andreas



hi vladimir,

ich looked at one situation (see z750i):

<0002> gprs_rlcmac_data.cpp:1532 Polling sheduled in this TS 7, FN=650918
<0002> gprs_rlcmac.cpp:983 Starting DL TBF=0 timer 3191.
<0006> gprs_rlcmac_sched.cpp:260 Received RTS for PDCH: TRX=0 TS=7 FN=650927 block_nr=10 scheduling free USF for polling at FN=650931 of DL TFI=0
<0002> gprs_rlcmac_data.cpp:270 +++++++++++++++++++++++++ RX : Uplink Control Block +++++++++++++++++++++++++
<0002> gprs_rlcmac_data.cpp:273 ------------------------- RX : Uplink Control Block -------------------------
<0002> gprs_rlcmac_data.cpp:376 PACKET DOWNLINK ACK with unknown FN=650927 TFI=0 (TRX 0 TS 7)

the polling of downlink frame is scheduled at FN 650918 (see no. 775 in wireshark trace). as you can see, the rlcmac header starts with 0x0f (first byte of the last 23 bytes of frame). these bits mean: payload-type=00, rrbp=00, s/p=1, usf=111. the s/p is set, because polling is requested. the rrbp indicates that the downlink ack message is polled 13 frames later. but the message is received 9 frames later (instead of 13), this is one block too early (see no. 781 in wireshark trace).

i come to the solution, that the block (B8) starting at frame 650918 was actually sent one block too early (B7) by openBTS at 650914, or the frame number of the received block (downlink ack message) was set wrong.

regards,

andreas