OpenBSC December 2015

openbsc@lists.osmocom.org

17 participants
38 discussions

by Вадим Яницкий

Hello, Harald, thanks for the answer. first of all, CalypsoBTS is not an active / maintained / stable solution > but more lik an (mindbogglingly amazing!) Hack. Yes, I know that CalypsoBTS is not stable solution. But currently I am a student and I have no so much money to buy anything more powerful. Furthermore, I am interested in this for research purposes only, not for creating public land mobile networks. As you are the first person to report using the code to this list for > quite some time, it would be great if you had some time to re-base, test > and submit it. As I previously said, I also tested master branches. Here are the results: * When I start OsmoBTS I often see this message in OpenBSC log: "Lost some E1 TEI link: X X" from bsc_init.c. In this case my MS can not connect to the test network and I have to restart OsmoBTS until this message will no hide. * When the Location Update process I always see this error: "input/ipaccess.c:277 Bad signalling message,sign_link returned error". But a phone successfully registers in the network. * SMS, USSD and Silent SMS works fine. * When TS1 assigned TCH/H I can call to another ms or LCR. DTMF works. * When TS1 assigned TCH/F I can use FR codec and call to LCR. * PDCH does not work on this BTS. * RRLP works. * ISMI detach works but as in case of Location Update I see "Bad signalling message..." error. * It seems, the network works more stable when battery capacity is 100% and backlight is disabled. If I understood correctly, osmobts-trx was just moved from obsolete repository to the master. Now I am reading the source code and trying to fix this bugs. I have one thing in my mind for a long time. Is it possible to serve a PDCH lchan on TS1 instead of TCH (in case of this "powerful" BTS)? I have tested OsmoSGSN+OpenGGSN with one PDCH channel on TS1, but it did not work. With best regards, Яницкий Вадим. 2015-12-06 18:14 GMT+06:00 Harald Welte <laforge(a)gnumonks.org>: > Hi Vadim, >> >> first of all, CalypsoBTS is not an active / maintained / stable solution >> but more lik an (mindbogglingly amazing!) Hack. >> >> On Sat, Dec 05, 2015 at 06:32:45PM +0600, Вадим Яницкий wrote: >> > When I use jolly/multi-trx branch of libosmo-abis, jolly/testing branch >> of >> > OpenBSC and jolly/trx branch of OsmoBTS my network works very unstable. >> >> I'm sorry to say that none of the branches you refer to are maintained >> by anyone at this point. It would be great if somebody interested in >> that code (i.e. using it) could forward-port it onto current master. >> Now tat l1sap and osmo-bts-trx is in osmo-bts master, this should be >> relatively straight forward. >> >> It's really sad for us to see that people are continuing to use >> old/outdated non-master, rather than rebasing + submitting their changes >> for inclusion. It always makes me tempte to remove some of those >> branches from the repo, ort at least rename them to something like >> 'outdated'. >> >> As you are the first person to report using the code to this list for >> quite some time, it would be great if you had some time to re-base, test >> and submit it. >> >> -- >> - Harald Welte <laforge(a)gnumonks.org> >> http://laforge.gnumonks.org/ >> >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > >

9 years, 6 months

The test suite for libosmocore fails on big-endian architectures

by Ruben Undheim

Hi, While building the package for Debian, apparently there is a problem related to big-endian architectures. Please see the logs here: https://buildd.debian.org/status/fetch.php?pkg=libosmocore&arch=powerpc&ver… and https://buildd.debian.org/status/package.php?p=libosmocore It is related to the test case for smscb and the struct gsm341_ms_message: +++ /«PKGBUILDDIR»/tests/testsuite.dir/at-groups/7/stdout 2015-12-05 15:51:53.463182812 +0000 @@ -1,4 +1,4 @@ -(srl) GS: 1 MSG_CODE: 1 UPDATE: 0 +(srl) GS: 0 MSG_CODE: 256 UPDATE: 1 (msg) msg_id: 1293 -(dcs) group: 1 language: 0 +(dcs) group: 0 language: 1 (pge) page total: 1 current: 1 7. testsuite.at:45: 7. smscb (testsuite.at:45): FAILED (testsuite.at:48) Could you please suggest how we should fix this so that the package also can build for powerpc and other big-endian architectures? Thank you very much in advance. Ruben

9 years, 6 months

osmo-bts / osmo-pcu profiling results

by Harald Welte

Hi all, I've been doing some profiling on osmo-bts recently (on sysmobts hardware, which has only a relatively slow ARM926 CPU core), and the two things that show up most are: * msgb_alloc() -> talloc_zero() -> malloc this can be alleviated somewhat by using talloc pools. For some reason the pools don't remove all of the malloc() calls. * vfprintf() and friends, from logp() statements. The sad part is that calls like gsm_lchan_name() are of course executed beefore the call into logp(), at which point the vfprintf/sprintf/... for arguments has already been executed, and only the last/final one hasn't happened yet. Here we can do two things: Calls like gsm_lchan_name() don't need to happen all the time, as the lchan name is static and can be generated once at the time gsm_lchan is created. I implemented that in osmo-bts (and openbsc, as it's from gsm_data_shared). The second idea would be to expand the LOGP() macro a bit in a way to ensure the the checking whether the log line is enabled _before_ the arguments (and thus associated function calls) are evaluated. Any ideas on that? After a brief look at osmo-pcu profiling, it looks like in the attached picture. We cannot do much about the __copy_to_user_std, do_select and core_sys_select, as those are kernel side. However, there again we see vfprintf and friends, mostly via gprs_rlcmac_tbf::name() - and of course the msgb_alloc() and msgb_free() going through talloc and finally malloc. So the same strategies as above could (and probably should) be applied to osmo-pcu. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

9 years, 6 months

DEc 9, 8pm / Osmocom Berlin Meeting

by Harald Welte

Hi all! This is the announcement for the re-incarnation of our bi-weekly Osmocom Berlin Meeting. Dec 09, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin There is no formal presentation this time, but * there will be SIMtrace equipment in case somebody wants to play with it there will be a sysmoBTS with OsmoBTS, OsmoPCU, OsmoNITB, OsmoSGSN and OpenGGSN if somebody wants to play with it * there will be Huawei Femtocells to play with The meeting is open to anyone interested in mobile communications. You do not have to be involved with the Osmocom projects in order to attend. Anyone interested in mobile communications protocols is welcome. If you are interested to show up, feel free to do so. The meeting is "free as in free beer", despite no actual free beer being around ;) More information can be found at http://openbsc.osmocom.org/trac/wiki/OsmocomMeeting/Berlin Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

9 years, 6 months

FYI: merge of gtphub

by Neels Hofmeyr

Hi list, I'm merging the last commits from the neels/gtphub branch to master (Holger agrees). I will direct my attention to other topics for the time being -- we're waiting for a live testing setup. ATM, I would see gtphub's maturity as "alpha": I believe it works as intended, but all testing so far, even though done with real equipment, was in a controlled test environment. If anyone would like to give it a spin, we'd appreciate any feedback. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte

9 years, 6 months

OpenBSC on CalypsoBTS without voice

by Вадим Яницкий

Hi all! Following wiki I am trying to launch OpenBSC on CalypsoBTS (two OsmocomBB phones) with speech support. I compiled libosmocore, libosmo-dsp, libosmo-abis and jolly/trx branch of OsmocomBB with transceiver support. Then I compiled opencore-amr, Sip-Sofia, oRTP for LCR. Then I compiled OpenBSC, OsmoBTS (with osmobts-trx) and LCR. OsmoBTS configured to use two timeslots only (*slotmask 1 1 0 0 0 0 0 0*) and it uses *TS0 as CCCH+SDCCH4* and *TS1 as TCH/H*. Here is some strings from my openbsc.cfg: bts 0 > codec-support fr hr amr > trx 0 > timeslot 0 > phys_chan_config CCCH+SDCCH4 > hopping enabled 0 > timeslot 1 > phys_chan_config TCH/H > hopping enabled 0 > When I use jolly/multi-trx branch of libosmo-abis, jolly/testing branch of OpenBSC and jolly/trx branch of OsmoBTS my network works very unstable. When I try to make voice call sometimes it falls with message "*No resources for TCH/H*". Russian language in SMS is not supported. I think it is because this branches are obsolete. I tried to compile everything again but used master branches, and it worked much better! Now everything works as well. But when I call to 995 or 993 numbers of LCR I hear nothing. :( In OpenBSC console I see: > <0004> abis_rsl.c:1465 (bts=0,trx=0,ts=1,ss=0) Activating ARFCN(806) SS(0) > lctype TCH/F r=CALL ra=0x43 ta=1 > <0004> abis_rsl.c:1199 (bts=0,trx=0,ts=1,ss=0) CHANNEL ACTIVATE ACK > <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 ESTABLISH INDICATION > <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=5 > <0002> gsm_04_08.c:958 <- CM SERVICE REQUEST serv_type=0x01 > MI(TMSI)=4286202573 > <0002> gsm_04_08_utils.c:692 -> CM SERVICE ACK > <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION > <0003> bsc_api.c:500 CLASSMARK CHANGE CM2(len=3) CM3(len=9) > <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION > <0003> bsc_api.c:586 GRPS SUSPEND REQUEST > <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION > <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=3 > <0001> gsm_04_08.c:3508 (bts 0 trx 0 ts 1 ti 8 sub 49643) Received 'SETUP' > from MS in state 0 (NULL) > <0001> gsm_04_08.c:3513 Unknown transaction ID 8, creating new trans. > <0001> transaction.c:71 subscr=0x1d1de30, net=0x1d0bf00 > <0001> gsm_04_08.c:1296 new state NULL -> INITIATED > <0001> gsm_04_08.c:1931 Subscriber 250013894508275 (49643) sends SETUP to > 995 > <0001> gsm_04_08.c:1357 (bts 0 trx 0 ts 1 ti 8 sub 49643) Sending > 'MNCC_SETUP_IND' to MNCC. > <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received > 'MNCC_LCHAN_MODIFY' from MNCC in state 1 (INITIATED) > <000a> bsc_api.c:397 Sending ChanModify for speech 65 1 > <0003> gsm_04_08_utils.c:498 -> CHANNEL MODE MODIFY mode=0x41 > <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received > 'MNCC_CALL_PROC_REQ' from MNCC in state 1 (INITIATED) > <0001> gsm_04_08.c:1296 new state INITIATED -> MO_CALL_PROC > <0001> gsm_04_08.c:139 (bts 0 trx 0 ts 1 ti 80) Sending 'CALL_PROC' to MS. > <0001> gsm_04_08.c:1718 queue tch_recv_mncc request (1) > <0001> gsm_04_08.c:3415 (bts 0 trx 0 ts 1 ti 08 sub 49643) Received > 'MNCC_SETUP_RSP' from MNCC in state 3 (MO_CALL_PROC) > <0001> gsm_04_08.c:1853 starting timer T313 with 30 seconds > <0001> gsm_04_08.c:1296 new state MO_CALL_PROC -> CONNECT_IND > <0001> gsm_04_08.c:139 (bts 0 trx 0 ts 1 ti 80) Sending 'CONNECT' to MS. > <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION > <0003> gsm_04_08_utils.c:534 CHANNEL MODE MODIFY ACK > <0004> abis_rsl.c:1867 (bts=0,trx=0,ts=1,ss=0) IPAC_BIND speech_mode=0x12 > RTP_PAYLOAD=98 > <0003> osmo_msc.c:72 MSC assign complete (do nothing). > <0004> abis_rsl.c:1218 (bts=0,trx=0,ts=1,ss=0) CHANNEL MODE MODIFY ACK > <0004> abis_rsl.c:2031 (bts=0,trx=0,ts=1,ss=0) IPAC_CRCX_ACK > LOCAL_IP=127.0.0.1 LOCAL_PORT=34079 CON_ID=0 <0001> gsm_04_08.c:1570 > pending tch_recv_mncc request > <0004> abis_rsl.c:1906 (bts=0,trx=0,ts=1,ss=0) IPAC_MDCX IP=127.0.0.1 > PORT=30000 RTP_PAYLOAD=98 RTP_PAYLOAD2=0 CONN_ID=0 speech_mode=0x02 > <0004> abis_rsl.c:2041 (bts=0,trx=0,ts=1,ss=0) IPAC_MDCX_ACK > LOCAL_IP=127.0.0.1 LOCAL_PORT=34079 CON_ID=0 > <0000> abis_rsl.c:1653 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION > <0000> gsm_04_08.c:3584 Dispatching 04.08 message, pdisc=3 > <0001> gsm_04_08.c:3508 (bts 0 trx 0 ts 1 ti 8 sub 49643) Received > 'CONNECT_ACK' from MS in state 28 (CONNECT_IND) > <0001> gsm_04_08.c:1337 stopping pending timer T313 > <0001> gsm_04_08.c:1296 new state CONNECT_IND -> ACTIVE > <0001> gsm_04_08.c:1357 (bts 0 trx 0 ts 1 ti 8 sub 49643) Sending > 'MNCC_SETUP_COMPL_IND' to MNCC. > In LCR console: > ** LCR Version 1.14 > > 000000 DEBUG (in sip.cpp/sip_init() line 1987): SIP globals initialized > LCR 1.14 started, waiting for calls... > 000000 TRACE 05.12.15 14:45:48.414 --: LCR 1.14 started, waiting for > calls... > 000000 TRACE 05.12.15 14:50:15.063 CH(1): New call ref LCR<->BSC callref > new=0x80000001 > 000000 TRACE 05.12.15 14:50:15.063 CH(1): Codec negotiation LCR<->BSC > bearer capa='given by MS' speech version='AMR given' version='Full Rate > given' version='AMR Half Rate given' ignored='Not TCH/H' version='Half Rate > given' ignored='Not TCH/H' > 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_SETUP_IND LCR<->BSC > calling number=49643 imsi=XXXXXXXXXXXXXXX dialing number=995 > 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_LCHAN_MODIFY LCR<->BSC > speech version='AMR given' mode 0x41 > 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_CALL_PROC_REQ LCR<->BSC > progress coding=3 location=1 descr=8 > 000000 TRACE 05.12.15 14:50:15.063 CH(1): MNCC_FRAME_RECV LCR<->BSC > 000000 TRACE 05.12.15 14:50:15.063 EP(1): SETUP from CH(1) interface > from=gsm caller id number=49643 present=allowed dialing 995 complete true > 000000 TRACE 05.12.15 14:50:15.064 EP(1): TONE to CH(1) directory > default name dialing > 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION (match) action goto > line 2 > 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION goto/menu (change to) > ruleset gsm dialing 995 > 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION (match) action test > line 6 > 000000 TRACE 05.12.15 14:50:15.064 EP(1): ACTION test test 'hold music' > 000000 TRACE 05.12.15 14:50:15.064 EP(1): CONNECT to CH(1) connect id > number= present='not available' > 000000 TRACE 05.12.15 14:50:15.064 EP(1): TONE to CH(1) directory > default name hold > 000000 TRACE 05.12.15 14:50:15.064 CH(1): MNCC_SETUP_RSP LCR<->BSC > connected type=0 plan=1 present=0 screen=3 number= > 000000 TRACE 05.12.15 14:50:15.880 CH(1): MNCC_SETUP_COMPL_IND LCR<->BSC > I can even send DTMF, but there is no sound... Transceiver logs (part): > <0011> trx.c:590 TRX Data 914281:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914253, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914282:0:0:1500a8741832a5700a0bd5d609f850 > <0011> trx.c:590 TRX Data 914282:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914254, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914283:0:0:811d500a01fd40e845d40284155020 > <0011> trx.c:590 TRX Data 914283:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914255, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914284:0:0:abff40aafff4026bffd500aadd4080 > <0011> trx.c:590 TRX Data 914284:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914256, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914285:0:0:01f5508115d50a651f510801755020 > <0011> trx.c:590 TRX Data 914285:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914257, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914286:0:0:10aabdd500aefd7102ab75108bbd50 > <0011> trx.c:590 TRX Data 914286:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914258, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914287:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914259, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914288:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914260, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914289:0:0:a05f550a04dd106a017d008015d020 > <0011> trx.c:590 TRX Data 914289:1:0:e2985a4a90a51468a03d80e70dd060 > <0011> trx.c:608 TRX Data Indication (fn=914261, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914290:0:0:2ebf548abbf502eaadd548aeff4400 > <0011> trx.c:590 TRX Data 914290:1:0:000000000000000000000000000000 > <0011> trx.c:608 TRX Data Indication (fn=914262, tn=1, toa=0.00) > <0011> trx.c:590 TRX Data 914291:0:0:047d148847740a6517554000754020 > <0011> trx.c:590 TRX Data 914291:1:0:000000000000000000000000000000 > OsmoBTS logs (part): > <0000> rsl.c:1733 (bts=0,trx=0,ts=1,ss=0) Handing RLL msg UNIT_DATA_IND > from LAPDm to MEAS REP > <0000> rsl.c:1683 (bts=0,trx=0,ts=1,ss=0) Tx MEAS RES valid(2) > <0006> scheduler.c:1186 Received Access Burst on RACH fn=913629 toa=54.75 > <0006> scheduler.c:1192 Received bad AB frame at fn=913629 (15/51) > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913674 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913674 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913670 to transmit. > <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 > fn=913677 ts=0 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913677 > ts=0 trx=0 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913679 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913679 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913674 to transmit. > <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 > fn=913681 ts=0 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913681 > ts=0 trx=0 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913683 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913683 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913679 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913687 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913687 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913683 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913692 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913692 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913687 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913696 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913696 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913692 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913700 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913700 > ts=1 trx=0 > <0006> scheduler.c:3012 GSM clock jitter: -4 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913696 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913705 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913705 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913700 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913709 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913709 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913705 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913713 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913713 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913709 to transmit. > <0006> scheduler.c:339 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 > fn=913718 ts=0 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=913718 > ts=0 trx=0 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913718 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913718 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913713 to transmit. > <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 > fn=913722 ts=0 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913722 > ts=0 trx=0 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913722 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913722 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913718 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913726 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913726 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913722 to transmit. > <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 > fn=913728 ts=0 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913728 > ts=0 trx=0 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913731 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913731 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913726 to transmit. > <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 > fn=913732 ts=0 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913732 > ts=0 trx=0 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913735 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913735 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913731 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913739 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913739 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913735 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913744 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913744 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913739 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913748 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913748 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913744 to transmit. > <0006> scheduler.c:3012 GSM clock jitter: 99 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913752 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913752 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913748 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913757 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913757 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913752 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913761 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913761 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913757 to transmit. > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913765 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913765 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913761 to transmit. > <0006> scheduler.c:339 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 > fn=913769 ts=0 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=913769 > ts=0 trx=0 > <0006> scheduler.c:339 PH-RTS.ind: chan=SACCH/TF chan_nr=0x09 link_id=0x40 > fn=913769 ts=1 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x40 fn=913769 > ts=1 trx=0 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913770 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913770 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913765 to transmit. > <0006> scheduler.c:339 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 > fn=913773 ts=0 trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=913773 > ts=0 trx=0 > <0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=913774 ts=1 > trx=0 > <0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=913774 > ts=1 trx=0 > <0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 > ts=1 at fn=913770 to transmit. > What does it mean "*TCH/F has not been served !! No prim for trx=0 ts=1 at fn=913770 to transmit.*"? I tried to make phone<->phone call with and without LCR. I tried to switch between TCH/H and TCH/F and use different codecs: arm fr hr. But unfortunately there is no sound. Can anyone help me? Thanks a lot!

9 years, 6 months

PCU <---> SGSN protocol trace

by Sipos Csaba

Dear list, I just appear to have a strange UE behavior where the UE tries to Attach (both CS and PS), the Osmo-SGSN sends an Attach accept, but the UE never responds with an Attach complete, instead after 10 seconds it tries to re-attach. I had an issue quite similar like this earlies where the UE requests for some IEs or the SGSN sends soething the UE don't like. The point is, I would like to do protocol trace between the SGSN and the PCU, and I managed to see the traffic with Wireshark, but it was not able to dissect/recognise the protocols over the UDP layer. Can someone please help me how to configure Wireshark to be able to dissect the involved protocols? Thanks! Csaba

9 years, 6 months

OpenBSC compile error --> tests --> GTP hub

by Sipos Csaba

Dear Neels, Today just grabbed the latest OpenBSC master, and got this compile error: Making all in gtphub make[3]: Entering directory `/root/new_osmocom/openbsc/openbsc/tests/gtphub' CC gtphub_test.o CC ../../src/gprs/gtphub.o ../../src/gprs/gtphub.c:2191:1: fatal error: opening dependency file .deps/../../src/gprs/gtphub.Tpo: No such file or directory } ^ compilation terminated. make[3]: *** [../../src/gprs/gtphub.o] Error 1 make[3]: Leaving directory `/root/new_osmocom/openbsc/openbsc/tests/gtphub' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/new_osmocom/openbsc/openbsc/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/new_osmocom/openbsc/openbsc' make: *** [all] Error 2 Do you have any idea why is this happening? Regards, Csaba

9 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC December 2015