<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Vladimir Rolbin wrote:
<blockquote
cite="mid:CAPPmnBhuEsejc1=BwkiZqQU2ih50b6aO3B-FRxci=m4N7LyMJQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi Andreas and Ivan.</div>
<div> </div>
<div>I've recorded three sessions, every one contains pcu log with
print fix andreas asked (rlcmac_*.log) and corresponding GSMTAP and Gb
pcap:</div>
<div> </div>
<div>1) openBTS pulled from git on 31.10.2012 (with gsmtap support
for PDCH), UE - Nokia 5000d.</div>
<div> I have very bad results with Nokia and SonyEriccsson
devices with not modified git branch.</div>
<div> As I wrote before I guess they are sensitive to
non-standard L2 pseudo length. Immediate Assignment</div>
<div> is already fixed for now but SI13 is not. I sent my
modifications before.. a great part of them are</div>
<div> really debug prints, but the other one fixes the Nokia
device behaviour ( session 2).</div>
<div> </div>
<div>2) modified openBTS merged with openBTS pulled from git on
31.10.2012, UE - Nokia 5000d.</div>
<div> <a moz-do-not-send="true" href="http://m.facebook.com">m.facebook.com</a>
is successfully opened. No scheduler issues. But sometimes it has..</div>
<div> I need to open more pages one after one to see the problem.
</div>
<div> </div>
<div>3) modified openBTS merged with openBTS pulled from git on
31.10.2012 (env is like in session 2).</div>
<div> UE - SonyEricsson z750i. A lot of scheduler issues (look
for "unknown"). I think this UE is more</div>
<div> pedantic than others.</div>
<div> </div>
<div> Regards,</div>
<div> Vladimir Rolbin</div>
<div><br>
</div>
<div> </div>
<div> </div>
<div class="gmail_quote">On Wed, Oct 31, 2012 at 8:00 AM, jolly <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:andreas@eversberg.eu" target="_blank">andreas@eversberg.eu</a>></span>
wrote:<br>
<blockquote
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"
class="gmail_quote">Vladimir Rolbin wrote:<br>
> gprs_rlcmac_data.cpp:1532 Polling sheduled in this TS 7<br>
hi vladimir,<br>
<br>
i missed something. this debug line above does not show us the frame<br>
number. you can change that debug line to:<br>
<br>
LOGP(DRLCMAC, LOGL_DEBUG, "Polling sheduled in this "<br>
"TS %d, FN=%d\n", ts, fn);<br>
<br>
regards,<br>
<br>
andreas<br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
hi vladimir,<br>
<br>
ich looked at one situation (see z750i):<br>
<br>
<0002> gprs_rlcmac_data.cpp:1532 Polling sheduled in this TS 7,
FN=650918<br>
<0002> gprs_rlcmac.cpp:983 Starting DL TBF=0 timer 3191.<br>
<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<br>
<0002> gprs_rlcmac_data.cpp:270 +++++++++++++++++++++++++ RX :
Uplink Control Block +++++++++++++++++++++++++<br>
<0002> gprs_rlcmac_data.cpp:273 ------------------------- RX :
Uplink Control Block -------------------------<br>
<0002> gprs_rlcmac_data.cpp:376 PACKET DOWNLINK ACK with unknown
FN=650927 TFI=0 (TRX 0 TS 7)<br>
<br>
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).<br>
<br>
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.<br>
<br>
regards,<br>
<br>
andreas<br>
<br>
</body>
</html>