No subject

historical

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 at 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:
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20121014/7aa14bc1/attachment.htm>