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
Hi, Vladimir!
Hi, Vladimir!
I haven't any problems with downlink assignment and PACKET_UPLINK_ACK_NACK now, but I will check it. Please, check, have you applied this patch? https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67f...
2012/10/10 Vladimir Rolbin vrolbin@gmail.com:
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
Hi, Ivan
Yes, the patch is applied.. It's not so clear the role of the timers mT3101, mT3111 and mT3109 for PDTCH channel. If I see well when "AccessGrantResponder -> LCH = gBTS.getPDTCH();" the same channel is opened every time (it's never closed explicitly):
LogicalChannel::open(); -> L1FEC::open() -> mDecoder->open(); -> void L1Decoder::open() -> { ScopedLock lock(mLock); if (!mRunning) start(); mFER=0.0F; mT3111.reset(); mT3109.reset(); mT3101.set(); mActive = true; }
handleGoodFrame function is overridden, so the channel stops to be active here after mT3101 is elapsed:
void XCCHL1Decoder::writeLowSide(const RxBurst& inBurst) { OBJLOG(DEBUG) <<"XCCHL1Decoder " << inBurst; // If the channel is closed, ignore the burst. if (!active()) { OBJLOG(DEBUG) <<"XCCHL1Decoder not active, ignoring input"; return; }
...
}
Pls advice..
Regards, Vladimir
On Wed, Oct 10, 2012 at 6:13 PM, Ivan Kluchnikov < Ivan.Kluchnikov@fairwaves.ru> wrote:
Hi, Vladimir!
Hi, Vladimir!
I haven't any problems with downlink assignment and PACKET_UPLINK_ACK_NACK now, but I will check it. Please, check, have you applied this patch?
https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67f...
2012/10/10 Vladimir Rolbin vrolbin@gmail.com:
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
-- Regards, Ivan Kluchnikov. http://fairwaves.ru
Hi, Vladimir!
I fixed this problem with PDTCH channel and got rid of T3111, T3109 and T3101 timers. Just update your repository.
I have two recommendations for tests: 1. Run osmo-pcu with parameters of your SIM card, for that use options: -m --mcc MCC use given MCC instead of value provided by BTS -n --mnc MNC use given MNC instead of value provided by BTS Example: ./osmo-pcu -n 02 -m 250 2. Add config file to osmo-pcu/src directory, which you can find in attachment.
2012/10/11 Vladimir Rolbin vrolbin@gmail.com:
Hi, Ivan
Yes, the patch is applied.. It's not so clear the role of the timers mT3101, mT3111 and mT3109 for PDTCH channel. If I see well when "AccessGrantResponder -> LCH = gBTS.getPDTCH();" the same channel is opened every time (it's never closed explicitly):
LogicalChannel::open(); -> L1FEC::open() -> mDecoder->open(); -> void L1Decoder::open() -> { ScopedLock lock(mLock); if (!mRunning) start(); mFER=0.0F; mT3111.reset(); mT3109.reset(); mT3101.set(); mActive = true; }
handleGoodFrame function is overridden, so the channel stops to be active here after mT3101 is elapsed:
void XCCHL1Decoder::writeLowSide(const RxBurst& inBurst) { OBJLOG(DEBUG) <<"XCCHL1Decoder " << inBurst; // If the channel is closed, ignore the burst. if (!active()) { OBJLOG(DEBUG) <<"XCCHL1Decoder not active, ignoring input"; return; }
...
}
Pls advice..
Regards, Vladimir
On Wed, Oct 10, 2012 at 6:13 PM, Ivan Kluchnikov Ivan.Kluchnikov@fairwaves.ru wrote:
Hi, Vladimir!
Hi, Vladimir!
I haven't any problems with downlink assignment and PACKET_UPLINK_ACK_NACK now, but I will check it. Please, check, have you applied this patch?
https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67f...
2012/10/10 Vladimir Rolbin vrolbin@gmail.com:
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
-- Regards, Ivan Kluchnikov. http://fairwaves.ru
Hi, Ivan
I've added the config file (thanks), but the parameter alloc-algorithm a I have already set in pcu source before. The only problem with MCC, MNC I've encountered is that osmo-sgsn rejects SIMs not belonging to configured MCC, MNC.. so will you explain the first recommendation? Till today I used gnuradio 3.3.0/libusb 0.12. Today I tried unsuccessfully to update the gnuradio to 4.3.2 version. What versions of gnuradio and libusb are you currently using in your test env?
I have different results for different UEs. I'am able to open facebook.com(one of my tests) with about 80% success when testing Samsung Z500, but Sony Ericsson Z750i failes on attach request (it responses on imsi identity request and does not on imei identity request sending attach request many times till cell reselection). What are your best results?
Regards, Vladimir
On Fri, Oct 12, 2012 at 12:32 PM, Ivan Kluchnikov < Ivan.Kluchnikov@fairwaves.ru> wrote:
Hi, Vladimir!
I fixed this problem with PDTCH channel and got rid of T3111, T3109 and T3101 timers. Just update your repository.
I have two recommendations for tests:
- Run osmo-pcu with parameters of your SIM card, for that use options:
-m --mcc MCC use given MCC instead of value provided by BTS -n --mnc MNC use given MNC instead of value provided by BTS Example: ./osmo-pcu -n 02 -m 250 2. Add config file to osmo-pcu/src directory, which you can find in attachment.
2012/10/11 Vladimir Rolbin vrolbin@gmail.com:
Hi, Ivan
Yes, the patch is applied.. It's not so clear the role of the timers mT3101, mT3111 and mT3109 for
PDTCH
channel. If I see well when "AccessGrantResponder -> LCH = gBTS.getPDTCH();" the
same
channel is opened every time (it's never closed explicitly):
LogicalChannel::open(); -> L1FEC::open() -> mDecoder->open(); -> void L1Decoder::open() -> { ScopedLock lock(mLock); if (!mRunning) start(); mFER=0.0F; mT3111.reset(); mT3109.reset(); mT3101.set(); mActive = true; }
handleGoodFrame function is overridden, so the channel stops to be active here after mT3101 is elapsed:
void XCCHL1Decoder::writeLowSide(const RxBurst& inBurst) { OBJLOG(DEBUG) <<"XCCHL1Decoder " << inBurst; // If the channel is closed, ignore the burst. if (!active()) { OBJLOG(DEBUG) <<"XCCHL1Decoder not active, ignoring input"; return; }
...
}
Pls advice..
Regards, Vladimir
On Wed, Oct 10, 2012 at 6:13 PM, Ivan Kluchnikov Ivan.Kluchnikov@fairwaves.ru wrote:
Hi, Vladimir!
Hi, Vladimir!
I haven't any problems with downlink assignment and PACKET_UPLINK_ACK_NACK now, but I will check it. Please, check, have you applied this patch?
https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67f...
2012/10/10 Vladimir Rolbin vrolbin@gmail.com:
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
-- Regards, Ivan Kluchnikov. http://fairwaves.ru
-- Regards, Ivan Kluchnikov. http://fairwaves.ru
osmocom-net-gprs@lists.osmocom.org
-
Ivan Kluchnikov -
Vladimir Rolbin