Similar problem with DL_PACKET_UPLINK_ACK_NACK..., now logs are synchronized:
 
BTS:
 
1349870962.242903 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543233 FN52 17 DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.261436 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543237 FN52 21 DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.262173 3042884464: [ PCU -> BTS ] PCH: L2Length 11 primitive=UNIT_DATA raw=(063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b)
1349870962.262261 3042884464: [ BTS -> PCU ] PhPchCnf: 2d063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b
1349870962.263013 3042884464: [ PCU -> BTS ] PACCH FN 2543250 FN52 34 CNTRL1 raw=(4f2400208000000000000000f155d181e02b2b2b2b2b2b) DL_PACKET_UPLINK_ACK_NACK
1349870962.283385 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543242 FN52 26 DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.302008 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543246 FN52 30 DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.320769 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543250 FN52 34 DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.362534 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543259 FN52 43 CNTRL1 raw=(40062aba303f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b) UL_PACKET_CONTROL_ACKNOWLEDGEMENT
1349870962.480042 3042884464: [ PCU -> BTS ] PDTCH: FN 2543298 FN52 30 DATA raw=(0f01002541c001081501ff6cba2b2b2b2b2b2b2b2b2b2b)
 
PCU:
 
<0005> gprs_rlcmac_data.cpp:880 Decoded premier TLLI=0x8aae8c0f of UL DATA TBF=0.
<0005> gprs_rlcmac_data.cpp:743 Complete UL frame for TBF=0: len=17
<0008> gprs_rlcmac.cpp:1760 LLC [PCU -> SGSN] TFI: 0 TLLI: 0x8aae8c0f len=17
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI: 000 len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f Immediate Assignment Downlink (PCH)
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown FN=2543259 TLL=0x8aae8c0f (TRX 0 TS 7)
<0002> gprs_rlcmac.cpp:895 Free UL TBF=0 with TLLI=0x8aae8c0f.
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI: 000 len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f Immediate Assignment Downlink (PCH)
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
 
...
 
 

From: Vladimir Rolbin [mailto:vrolbin@gmail.com]
Sent: Tuesday, October 09, 2012 5:17 PM
To: osmocom-pcu@lists.osmocom.org; openbts-discuss@lists.sourceforge.net
Subject: [Openbts-discuss] gprs PACCH downlink assignment problem

 

Hi,

 

My set is openbts-p2.8-gprs-exp/osmo-pcu-jolly. I encounter the problem with PACCH downlink assignment:

 

If the difference between FNs of DL_PACKET_DOWNLINK_ASSIGNMENT and corresponding UL_PACKET_CONTROL_ACKNOWLEDGEMENT
is expected (RRBP = 0) 13 everything is OK (OpenBTS log):

 

1347379490.099008 3031505776: [ PCU -> BTS ] PACCH FN 2536893 FN52 21 CNTRL1 raw=(4f0800000c03400a0800802b2b2b2b2b2b2b2b2b2b2b2b) DL_PACKET_DOWNLINK_ASSIGNMENT
1347379490.118500 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536885 FN52 13 DATA raw=(100101cc741f3203c005650000014500003c00010000ff)
1347379490.136108 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536889 FN52 17 DATA raw=(080105cc741f3228e2a8c8aa0100000100000000000003)
1347379490.154624 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536893 FN52 21 DATA raw=(040107cc741f32777777066b616e6e656c036f72670000)
1347379490.215582 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536906 FN52 34 CNTRL1 raw=(400731d07ccb2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)UL_PACKET_CONTROL_ACKNOWLEDGEMENT

 

 

But it's not always the case

 

1349788219.582282 3043367792: [ PCU -> BTS ] PACCH FN 2189728 FN52 8 CNTRL1 raw=(4f0800000c02800a0d00802b2b2b2b2b2b2b2b2b2b2b2b) DL_PACKET_DOWNLINK_ASSIGNMENT
1349788219.601978 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189720 FN52 0 DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.620378 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189724 FN52 4 DATA raw=(0001042dae355837026a4e0432100000258ccc2b2b2b2b)
1349788219.638881 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189728 FN52 8 DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.680973 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189737 FN52 17 CNTRL1 raw=(4006b8d560df2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b) UL_PACKET_CONTROL_ACKNOWLEDGEMENT

 

diff FN = 9, that causes the following behaviour in pcu:

 

<0002> gprs_rlcmac_data.cpp:1753 TBF: START TFI: 0 TLLI: 0xae355837 Packet Downlink Assignment (PACCH)
<0004> gprs_rlcmac_data.cpp:1442 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown FN=2163607 TLL=0xae355837 (TRX 0 TS 7)
<0002> gprs_rlcmac_data.cpp:100 Poll timeout for UL TBF=0
<0002> gprs_rlcmac_data.cpp:107 - Timeout for polling PACKET CONTROL ACK for PACKET UPLINK ACK

 

Any ideas?  Is it the known issue?


Regards,

Vladimir Rolbin