OpenBSC April 2017

openbsc@lists.osmocom.org

26 participants
32 discussions

osmocom-bb moved to gerrit
by Neels Hofmeyr 24 Apr '17

24 Apr '17

The osmocom-bb git repository has now moved to gerrit. For patch submission to osmocom-bb, see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit ~N

1 0

FSM for lchan release handling -- release indication after SACCH deactivation timeout
by Holger Freyther 24 Apr '17

24 Apr '17

Good Evening, this is a bit of speculation but Keith showed me a trace with some network delay that makes a case for using FSM for the lchan itself. It seems the following can happen: * LU REJECT * Start Channel Release ** Send RR Release to the MS ** Deactivate SACCH ** Start Timer ... network transmission issues... at least 5s * SACCH deactivate timeout ** Start error release procedure.. ... * LATE RELEASE INDICATION arrives triggering other release procedure? So with a proper FSM we would have transitioned into the error path and would just ignore the RELEASE INDICATION. The question is if someone has budget to do a FSM transition here? I will try to build a simulated testcase for that. The other part that seems to happen (and I don't understand yet): * Allocating a lchan before it is fully freed?! * The BTS sending us RF Channel Releasse ACK twice cheers holger

1 0

Control interface introspection of FSMs
by Harald Welte 19 Apr '17

19 Apr '17

Good News, everyone [tm] Some may have already played with it: The osmo_fsm's already have gained a VTY interface (see http://git.osmocom.org/libosmocore/tree/src/vty/fsm_vty.c) some time ago, which is nice for manual debugging and the like. However, for automatic testing one would normally want to do something like the following: 1) send a packet to the implementation under test (IUT) 2) then check if a given FSM has been created, a state has changed, a timer is running, etc. 3) go to '1' for the next packet, or wait for a timeout and then re-check, ... I've just introduced a generic CTRL interface for programmatic access to osmo_fsm. See https://gerrit.osmocom.org/#/c/2377 for details. The general idea is that you can send a CTRL command like GET 1 fsm.FSM_NAME.id.INSTANCE_ID.state GET 1 fsm.FSM_NAME.id.INSTANCE_ID.timer GET 1 fsm.FSM_NAME.id.INSTANCE_ID.parent-name GET 1 fsm.FSM_NAME.id.INSTANCE_ID.dump Where FSM_NAME is the name of the osmo_fsm (class) and INSTANCE_ID is the identity of the instance (e.g. the IMSI of a subscriber in the VLR code). So in OsmoMSC, something like GET 1 fsm.vlr_lu_fsm.id.901700123456789.state would return the string name of the state for the location update FSM of the given IMSI, e.g. "VLR_ULA_S_WAIT_LU_COMPL_STANDALONE" I presume Neels will like this. Could be used from osmo-gsm-tester to not just do "black box testing" from MS to MS or MS to MNCC, but to actually verify individual states/transitions on all osmo_fsm enabled elements. It's of course questionable if an end-to-end test should care, but I can think of all kinds of other testing (particularly of my new SIGTRAN work) where it is absolutely useful. Once the above-mentioned patches are merged, applications with a control inteface will have this functionality enabled automatically. I think this makes osmo_fsm even more useful. I can imagine use cases not only related to testing, but also use cases of e.g. user interfaces or visualization. Regards, Harald p.s.: In German we say "self praise stinks", but I really think osmo_fsm is one of the best things happening to the Osmocom cellular projects in recent years. Now we just need to convert more code to use 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)

2 1

OpenBSC
by Bizhan Changizi 19 Apr '17

19 Apr '17

Dear Sipos Csaba Hi firstly my english languages is not good, and excuse me. i find Your contact info from blow link. http://lists.osmocom.org/pipermail/openbsc/2015-September/000413.html dear Sips i need to help to run OsmoNITB <https://osmocom.org/projects/osmonitb/wiki> but i have a problem when compile the source. but i can’t resolve it, can you help me to to run OpenBSC plz, tnx. Problem : CC abis_om2000_vty.o CC abis_rsl.o CC bsc_rll.o CC paging.o CC bts_ericsson_rbs2000.o CC bts_ipaccess_nanobts.o In file included from bts_ipaccess_nanobts.c:39:0: /usr/local/include/osmocom/abis/ipaccess.h:7:8: error: redefinition of ‘struct ipaccess_unit’ struct ipaccess_unit { ^ In file included from bts_ipaccess_nanobts.c:38:0: /usr/local/include/osmocom/gsm/ipa.h:11:8: note: originally defined here struct ipaccess_unit { ^ make[3]: *** [bts_ipaccess_nanobts.o] Error 1 make[3]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc/src/libbsc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/telecom/osmo/src/osmonitb/openbsc/openbsc' make: *** [all] Error 2 telecom@OpenBCS:~/osmo/src/osmonitb$ best regurds

2 1

UMTS-Stick on nano3G?
by Andreas Mueller 19 Apr '17

19 Apr '17

Hello, I tried to use a Huawei E1823 UMTS-Stick on a debian8-laptop with wvdial and pppd to connect to a nano3G for getting an IP/Internet-connection via UMTS/HSDPA. The setup is mainly as described on http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_wi…. When using an android-Smartphone with the same configuration of the ggsn and the other components the IP/Internet-connection is working. After pppd is started from wvdial it receives his local IP-address from the "net 192.168.99.0/24" parameter of ggsn.conf and also the configured DNS-Server, but no remote-IP, so 10.64.64.64 is used by pppd as a default value: ... --> local IP address 192.168.99.5 --> pppd: ï¿½[7f] --> remote IP address 10.64.64.64 --> pppd: ï¿½[7f] --> primary DNS address 8.8.8.8 --> pppd: ï¿½[7f] ..which results in an unusable ppp0-device: ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.99.5 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 Has anybody successfully used an UMTS-Stick with ggsn? How can I tell ggsn to send his IP-Adress, which can be used by pppd as "remote IP address"? Are there special options for pppd which I have to use? thanks and greetings, Andreas

4 7

OpenBSC TCH/H
by robert 17 Apr '17

17 Apr '17

Hello, I have set all the traffic channels to TCH/H and started the BTS but I was not able to perform a call. Is there something else that should be done ? Best regards,

2 1

Control Interface related testing
by Harald Welte 17 Apr '17

17 Apr '17

Dear all, I have just submitted some patches which allow test cases to use the Control Interface internally, without binding to a TCP port. See https://gerrit.osmocom.org/#/c/2375/ and https://gerrit.osmocom.org/#/c/2376/ Using this, one can now write unit tests for control commands, without having to go for a multi-process setup with an external control client connected to the control TCP port (which is not easily possible in CI as the port might be used by another test case, ...) -- - 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)

1 0

Running osmo-trx and osmo-bts-trx Shows Errors
by Ron 12 Apr '17

12 Apr '17

Hi, We just finished installing the following osmo elements using Ubuntu 14.04 and the procedures from this link: https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_f… https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_source * libosmocore * libosmo-abis * libosmo-netif * openggsn * libosmo-sccp * openbsc * osmo-pcu * osmo-trx * osmo-bts We are now trying to run each applications to test osmo. All applications were run smoothly except for osmo-trx and osmo-bts-trx. We also installed the UHD driver of Ettus B2xx series using both “apt-get install” process and binary process as well using this link: https://files.ettus.com/manual/page_install.html https://files.ettus.com/manual/page_build_guide.html But still, the same errors were received. Errors received: # osmo-trx [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-128-g379f922d opening configuration table from path :memory: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd6device4findERKNS_13device_addr_tE # osmo-bts-trx -c /etc/osmo-bts.cfg ((*)) | / \ OsmoBTS There is no such command. Error occurred during reading below line: fn-advance 20 Failed to parse the config file: '/etc/osmo-bts.cfg’ What seems to cause this errors? What logs do we need to check? Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 [cid:D7861C66-51ED-4DB6-B9ED-BADEB28148EC] Singapore * Philippines Products: Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you.

4 4

weekly test report (w14 2017)
by Joachim Steiger 08 Apr '17

08 Apr '17

Hi, this is the BTS test report for week14 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G Most test cases have passed: sysmobts and nanobts worked without issue. the only one failing were with the octbts: the issues there were reliability of establishing a voicecall and or gprs. only every 2nd or 3rd attempt works. on the 3 TCH/H, 3 PDCH config gprs was not working at all with the ettus B200 everything worked but gprs seemed extremely slow or lossy. i could only view small testpages, big graphics do not load. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests following are some git hashes/version strings of tested components: libosmo-abis: bf7976c0b0076410ad1bd67061dd18d0f33a7f43 libosmocore: ff20641d9e3bb4373f9577c3382df1480ace4e91 libosmo-netif: 5fe77a4656f3590c343861ea96bcec18e370e437 libosmo-sccp: 8e708d1f2da1b187f631bf08172a5194a85b1a23 libsmpp34: cc0bcd6bc051d5ccaf32cdbbc28f073369900857 openbsc: 2d92162a6b6720d72129bee1bcbef353b0fd0aa6 openggsn: 19e19e3609508d121ba46c165e5ed1502a3cf9da osmo-bts: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-bts-octphy: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-pcu: e6d26ec09c2bcd2126416a58cb23af27318ec67e osmo-trx: 6031734f448c6308d67b1ee464a13d60b33cd843 sysmobts: OsmoBTS version 0.4.0.414-e16b5 sysmobts: Osmo-PCU version 0.2.900-e6d2 octbts: (name='octsdr_gsm', desc='Software Define Radio', ver='02.07.00-B1039', ver_hdr='02.07.00-B1039') octbts: (platform='Opus2', version='OCTSYS_VERSION=01.02.19.B1;OCTODK_VERSION=01.15.01-B1;OCTADF_VERSION=04.05.01-B2637;') nanobts: Equipment_Version='165g029_79' nanobts: Software_Version='168d462_v200b202d0' if you are interested in the details, drop me a mail and i'll forward the whole report. kind regards -- - Joachim Steiger <jsteiger(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 * Geschaeftsfuehrer / Managing Directors: Harald Welte

1 0

[RFC] Coding Style: Longer Line Lengths?
by Harald Welte 06 Apr '17

06 Apr '17

Dear all, [Despite today being April 1st, this is not an april fool's joke] ever since the start of the Osmocom project, we have adopted pretty much 1:1 the Linux Kernel coding style. Having a uniform coding style all over the project is important for readability, and from my point of view it doesn't really matter too much which style it is, as long as it is uniform accross the projects. I'm still fine with the Linux kernel coding style for most parts, but I think we could consider allowing longer lines. 80 characters is still nice here and there, but maybe something like 100, 120 or even 130 might actually make the code more readable and permit us to use slightly longer identifiers without having to wrap every second statement in the code. What do people generally think here? 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)

10 16

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC April 2017