<div dir="ltr"><div>Hi, Ivan</div>
<div> </div>
<div>I've added the config file (thanks), but the parameter <span lang="EN">alloc-algorithm a I have already set in pcu source before. </span></div>
<div><span lang="EN">The only problem with MCC, MNC I've encountered is that osmo-sgsn rejects SIMs not belonging</span></div>
<div><span lang="EN">to configured MCC, MNC.. so will you explain the first recommendation?</span></div>
<div>Till today I used gnuradio 3.3.0/libusb 0.12. Today I tried unsuccessfully to update the gnuradio to 4.3.2 version.</div>
<div> What versions of gnuradio and libusb are you currently using in your test env?</div>
<div> </div>
<div>I have different results for different UEs. I'am able to open <a href="http://facebook.com">facebook.com</a> (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</div>
<div>does not on imei identity request sending attach request many times till cell reselection). What are your best results?</div>
<div> </div>
<div> </div>
<div>Regards,</div>
<div>Vladimir</div>
<div><br> </div>
<div class="gmail_quote">On Fri, Oct 12, 2012 at 12:32 PM, Ivan Kluchnikov <span dir="ltr"><<a href="mailto:Ivan.Kluchnikov@fairwaves.ru" target="_blank">Ivan.Kluchnikov@fairwaves.ru</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">Hi, Vladimir!<br><br>I fixed this problem with PDTCH channel and got rid of T3111, T3109<br>and T3101 timers.<br>
Just update your repository.<br><br>I have two recommendations for tests:<br>1. Run osmo-pcu with parameters of your SIM card, for that use options:<br> -m --mcc MCC use given MCC instead of value provided by BTS<br>
-n --mnc MNC use given MNC instead of value provided by BTS<br>Example:<br>./osmo-pcu -n 02 -m 250<br>2. Add config file to osmo-pcu/src directory, which you can find in attachment.<br><br><br>2012/10/11 Vladimir Rolbin <<a href="mailto:vrolbin@gmail.com">vrolbin@gmail.com</a>>:<br>
> Hi, Ivan<br>><br>> Yes, the patch is applied..<br>> It's not so clear the role of the timers mT3101, mT3111 and mT3109 for PDTCH<br>> channel.<br>> If I see well when "AccessGrantResponder -> LCH = gBTS.getPDTCH();" the same<br>
> channel<br>> is opened every time (it's never closed explicitly):<br>><br>> LogicalChannel::open(); -> L1FEC::open() -> mDecoder->open(); -> void<br>> L1Decoder::open() -><br>> {<br>
> ScopedLock lock(mLock);<br>> if (!mRunning) start();<br>> mFER=0.0F;<br>> mT3111.reset();<br>> mT3109.reset();<br>> mT3101.set();<br>> mActive = true;<br>> }<br>><br>> handleGoodFrame function is overridden, so the channel stops to be active<br>
> here after mT3101 is elapsed:<br>><br>> void XCCHL1Decoder::writeLowSide(const RxBurst& inBurst)<br>> {<br>> OBJLOG(DEBUG) <<"XCCHL1Decoder " << inBurst;<br>> // If the channel is closed, ignore the burst.<br>
> if (!active()) {<br>> OBJLOG(DEBUG) <<"XCCHL1Decoder not active, ignoring input";<br>> return;<br>> }<br>><br>> ...<br>><br>> }<br>><br>> Pls advice..<br>><br>> Regards,<br>
> Vladimir<br>><br>><br>><br>> On Wed, Oct 10, 2012 at 6:13 PM, Ivan Kluchnikov<br>> <<a href="mailto:Ivan.Kluchnikov@fairwaves.ru">Ivan.Kluchnikov@fairwaves.ru</a>> wrote:<br>>><br>>> Hi, Vladimir!<br>
>><br>>><br>>> Hi, Vladimir!<br>>><br>>> I haven't any problems with downlink assignment and<br>>> PACKET_UPLINK_ACK_NACK now, but I will check it.<br>>> Please, check, have you applied this patch?<br>
>><br>>> <a href="https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67f6b195644329a" target="_blank">https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67f6b195644329a</a><br>
>><br>>><br>>> 2012/10/10 Vladimir Rolbin <<a href="mailto:vrolbin@gmail.com">vrolbin@gmail.com</a>>:<br>>> > Similar problem with DL_PACKET_UPLINK_ACK_NACK..., now logs are<br>>> > synchronized:<br>
>> ><br>>> > BTS:<br>>> ><br>>> > 1349870962.242903 <a href="tel:3064806256" value="+13064806256">3064806256</a>: [ BTS -> PCU ] PhDataInd: FN 2543233 FN52<br>>> > 17<br>>> > DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)<br>
>> > 1349870962.261436 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543237 FN52<br>>> > 21<br>>> > DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)<br>>> > 1349870962.262173 3042884464: [ PCU -> BTS ] PCH: L2Length 11<br>
>> > primitive=UNIT_DATA raw=(063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b)<br>>> > 1349870962.262261 3042884464: [ BTS -> PCU ] PhPchCnf:<br>>> > 2d063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b<br>
>> > 1349870962.263013 3042884464: [ PCU -> BTS ] PACCH FN 2543250 FN52 34<br>>> > CNTRL1<br>>> > raw=(4f2400208000000000000000f155d181e02b2b2b2b2b2b)<br>>> > DL_PACKET_UPLINK_ACK_NACK<br>
>> > 1349870962.283385 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543242 FN52<br>>> > 26<br>>> > DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)<br>>> > 1349870962.302008 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543246 FN52<br>
>> > 30<br>>> > DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)<br>>> > 1349870962.320769 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543250 FN52<br>>> > 34<br>>> > DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)<br>
>> > 1349870962.362534 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543259 FN52<br>>> > 43<br>>> > CNTRL1 raw=(40062aba303f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)<br>>> > UL_PACKET_CONTROL_ACKNOWLEDGEMENT<br>
>> > 1349870962.480042 3042884464: [ PCU -> BTS ] PDTCH: FN 2543298 FN52 30<br>>> > DATA<br>>> > raw=(0f01002541c001081501ff6cba2b2b2b2b2b2b2b2b2b2b)<br>>> ><br>>> > PCU:<br>
>> ><br>>> > <0005> gprs_rlcmac_data.cpp:880 Decoded premier TLLI=0x8aae8c0f of UL<br>>> > DATA<br>>> > TBF=0.<br>>> > <0005> gprs_rlcmac_data.cpp:743 Complete UL frame for TBF=0: len=17<br>
>> > <0008> gprs_rlcmac.cpp:1760 LLC [PCU -> SGSN] TFI: 0 TLLI: 0x8aae8c0f<br>>> > len=17<br>>> > <0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI:<br>>> > 000<br>
>> > len: 9<br>>> > <0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10<br>>> > <0002> gprs_rlcmac.cpp:948 - Setting Control TS 7<br>>> > <0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f<br>
>> > Immediate<br>>> > Assignment Downlink (PCH)<br>>> > <0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown<br>>> > FN=2543259<br>>> > TLL=0x8aae8c0f (TRX 0 TS 7)<br>
>> > <0002> gprs_rlcmac.cpp:895 Free UL TBF=0 with TLLI=0x8aae8c0f.<br>>> > <0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9<br>>> > <0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.<br>
>> > <0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI:<br>>> > 000<br>>> > len: 9<br>>> > <0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10<br>
>> > <0002> gprs_rlcmac.cpp:948 - Setting Control TS 7<br>>> > <0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f<br>>> > Immediate<br>>> > Assignment Downlink (PCH)<br>
>> > <0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9<br>>> > <0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.<br>>> ><br>>> > ...<br>>> ><br>
>> ><br>>> ><br>>> > From: Vladimir Rolbin [mailto:<a href="mailto:vrolbin@gmail.com">vrolbin@gmail.com</a>]<br>>> > Sent: Tuesday, October 09, 2012 5:17 PM<br>>> > To: <a href="mailto:osmocom-pcu@lists.osmocom.org">osmocom-pcu@lists.osmocom.org</a>; <a href="mailto:openbts-discuss@lists.sourceforge.net">openbts-discuss@lists.sourceforge.net</a><br>
>> > Subject: [Openbts-discuss] gprs PACCH downlink assignment problem<br>>> ><br>>> ><br>>> ><br>>> > Hi,<br>>> ><br>>> ><br>>> ><br>>> > My set is openbts-p2.8-gprs-exp/osmo-pcu-jolly. I encounter the problem<br>
>> > with<br>>> > PACCH downlink assignment:<br>>> ><br>>> ><br>>> ><br>>> > If the difference between FNs of DL_PACKET_DOWNLINK_ASSIGNMENT and<br>>> > corresponding UL_PACKET_CONTROL_ACKNOWLEDGEMENT<br>
>> > is expected (RRBP = 0) 13 everything is OK (OpenBTS log):<br>>> ><br>>> ><br>>> ><br>>> > 1347379490.099008 3031505776: [ PCU -> BTS ] PACCH FN 2536893 FN52 21<br>>> > CNTRL1<br>
>> > raw=(4f0800000c03400a0800802b2b2b2b2b2b2b2b2b2b2b2b)<br>>> > DL_PACKET_DOWNLINK_ASSIGNMENT<br>>> > 1347379490.118500 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536885 FN52<br>>> > 13<br>
>> > DATA raw=(100101cc741f3203c005650000014500003c00010000ff)<br>>> > 1347379490.136108 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536889 FN52<br>>> > 17<br>>> > DATA raw=(080105cc741f3228e2a8c8aa0100000100000000000003)<br>
>> > 1347379490.154624 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536893 FN52<br>>> > 21<br>>> > DATA raw=(040107cc741f32777777066b616e6e656c036f72670000)<br>>> > 1347379490.215582 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536906 FN52<br>
>> > 34<br>>> > CNTRL1<br>>> ><br>>> > raw=(400731d07ccb2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)UL_PACKET_CONTROL_ACKNOWLEDGEMENT<br>>> ><br>>> ><br>>> ><br>>> ><br>
>> ><br>>> > But it's not always the case<br>>> ><br>>> ><br>>> ><br>>> > 1349788219.582282 3043367792: [ PCU -> BTS ] PACCH FN 2189728 FN52 8<br>>> > CNTRL1<br>
>> > raw=(4f0800000c02800a0d00802b2b2b2b2b2b2b2b2b2b2b2b)<br>>> > DL_PACKET_DOWNLINK_ASSIGNMENT<br>>> > 1349788219.601978 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189720 FN52<br>>> > 0<br>
>> > DATA raw=(040103ae3558373751f40103e800101773022a85464200)<br>>> > 1349788219.620378 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189724 FN52<br>>> > 4<br>>> > DATA raw=(0001042dae355837026a4e0432100000258ccc2b2b2b2b)<br>
>> > 1349788219.638881 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189728 FN52<br>>> > 8<br>>> > DATA raw=(040103ae3558373751f40103e800101773022a85464200)<br>>> > 1349788219.680973 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189737 FN52<br>
>> > 17<br>>> > CNTRL1 raw=(4006b8d560df2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)<br>>> > UL_PACKET_CONTROL_ACKNOWLEDGEMENT<br>>> ><br>>> ><br>>> ><br>>> > diff FN = 9, that causes the following behaviour in pcu:<br>
>> ><br>>> ><br>>> ><br>>> > <0002> gprs_rlcmac_data.cpp:1753 TBF: START TFI: 0 TLLI: 0xae355837<br>>> > Packet<br>>> > Downlink Assignment (PACCH)<br>>> > <0004> gprs_rlcmac_data.cpp:1442 Complete DL frame for TBF=0: len=9<br>
>> > <0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown<br>>> > FN=2163607<br>>> > TLL=0xae355837 (TRX 0 TS 7)<br>>> > <0002> gprs_rlcmac_data.cpp:100 Poll timeout for UL TBF=0<br>
>> > <0002> gprs_rlcmac_data.cpp:107 - Timeout for polling PACKET CONTROL ACK<br>>> > for<br>>> > PACKET UPLINK ACK<br>>> ><br>>> ><br>>> ><br>>> > Any ideas? Is it the known issue?<br>
>> ><br>>> ><br>>> > Regards,<br>>> ><br>>> > Vladimir Rolbin<br>>> ><br>>> ><br>>><br>>><br><span class="HOEnZb"><font color="#888888">>><br>
>> --<br>>> Regards,<br>>> Ivan Kluchnikov.<br>>> <a href="http://fairwaves.ru/" target="_blank">http://fairwaves.ru</a><br>><br>><br><br><br><br>--<br>Regards,<br>Ivan Kluchnikov.<br><a href="http://fairwaves.ru/" target="_blank">http://fairwaves.ru</a><br>
</font></span></blockquote></div><br></div>