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(a)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(a)gmail.com>om>:
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(a)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/bfa47ccfa26ab30b0232584ac67…
>
>
> 2012/10/10 Vladimir Rolbin <vrolbin(a)gmail.com>om>:
> > 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(a)lists.osmocom.org;
openbts-discuss(a)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