1 Nov
2012
1 Nov
'12
9:14 a.m.
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(a)eversberg.eu
<mailto:andreas@eversberg.eu>> wrote:
Vladimir Rolbin wrote:
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
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