openbts-p2.8-gprs-exp and pcu issues

[jolly]

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 <http://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 at eversberg.eu
> <mailto:andreas at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121101/2b084646/attachment.htm>