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/bfa47ccfa26ab30b0232584ac67f6b195644329a
>>
>>
>> 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