<!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:CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi Andreas,</div>
<div> </div>
<div>1. If I see well the pcu expects <span
style="font-family: 'Times New Roman','serif'; font-size: 12pt;">PCU_IF_MSG_DATA_CNF
data starting from plen..</span></div>
<div><span
style="font-family: 'Times New Roman','serif'; font-size: 12pt;">
This error:</span></div>
<div><span
style="font-family: 'Times New Roman','serif'; font-size: 12pt;"></span> </div>
<div><span
style="font-family: 'Times New Roman','serif'; font-size: 12pt;"> <span
lang="EN"><0002> gprs_rlcmac_data.cpp:1138 TX: Immediate
Assignment Uplink (AGCH)</span></span></div>
<p><0002> gprs_rlcmac_data.cpp:1876 Got IMM.ASS confirm, but
rest octets do not start with bit sequence 'HH01' (Packet Downlink
Assignment)</p>
<p> </p>
<div>is caused by openBTS's confirm from PCU_IF_SAPI_AGCH handler,
the example of the frame sent back to the pcu:</div>
</div>
</blockquote>
hi vladimir,<br>
<br>
check out pcu_rx_data_cnf() at pcu_l1_if.cpp. it filters the confirm
and only passes PCU_IF_SAPI_PCH to gprs_rlcmac_imm_ass_cnf(). in your
case above, the uplink assignment on AGCH may result in a confirm, but
in this case it should have PCH sapi in order to be ignored:<br>
<br>
it might help to add this to pcu_rx_data_cnf():<br>
<br>
case PCU_IF_SAPI_AGCH:<br>
break;<br>
<br>
sysmobts is currently not sending an AGCH confirm via PCH interface, so
this is why i did not implement it.<br>
<br>
<br>
<blockquote
cite="mid:CAPPmnBibg=9ePnky2F1Ep7E71neCxxrzamn_cXyrNbp_OV7R=w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><span lang="EN"><span
style="font-family: 'Calibri','sans-serif'; font-size: 11pt;"><span
lang="EN">
<p><0006> gprs_rlcmac_sched.cpp:260 Received RTS for PDCH:
TRX=0 TS=7 FN=2353693 block_nr=4 scheduling free USF for polling at
FN=2353697 of DL TFI=0</p>
<p><0006> gprs_rlcmac_sched.cpp:260 Received RTS for PDCH:
TRX=0 TS=7 FN=2353702 block_nr=6 scheduling free USF for polling at
FN=2353706 of UL TFI=0</p>
<p><0002> gprs_rlcmac_data.cpp:376 PACKET DOWNLINK ACK with
unknown FN=2353693 TFI=0 (TRX 0 TS 7)</p>
<p><0002> gprs_rlcmac_data.cpp:288 PACKET CONTROL ACK with
expected FN=2353706 TLL=0xec8157f3 (TRX 0 TS 7)</p>
</span></span></span></div>
</div>
</blockquote>
the packet control ack seems ok. it is polled at 2353693 with 13 bursts
in advance and therefore the block 2352706 is reserved for uplink. (the
USF is set accordingly 4 bursts earlier.)<br>
<br>
but the packet downlink ack is received 4 bursts too early. i would
suggest to set DRLCMAC debugging to DEBUG. at
gprs_rlcmac_send_data_block_acknowledged() the debugging shows in which
FN it is scheduled. then the frame number to be polled is set there:<br>
<br>
...<br>
LOGP(DRLCMAC, LOGL_DEBUG, "Polling sheduled in this "<br>
"TS %d\n", ts);<br>
...<br>
tbf->poll_state = GPRS_RLCMAC_POLL_SCHED;<br>
tbf->poll_fn = (fn + 13) % 2715648;<br>
...<br>
<br>
you may also just change the log level of that debug line to
LOGL_NOTICE.<br>
<br>
<br>
regards,<br>
<br>
andreas<br>
<br>
</body>
</html>