This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Ivan Kluchnikov Ivan.Kluchnikov at fairwaves.ruHi, 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 at 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 at 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/bfa47ccfa26ab30b0232584ac67f6b195644329a >> >> >> 2012/10/10 Vladimir Rolbin <vrolbin at 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 at gmail.com] >> > Sent: Tuesday, October 09, 2012 5:17 PM >> > To: osmocom-pcu at lists.osmocom.org; openbts-discuss at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-pcu.cfg Type: application/octet-stream Size: 43 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121012/ff34d90b/attachment.obj>