OpenBSC June 2017

openbsc@lists.osmocom.org

23 participants
42 discussions

Re: vty talloc report
by Vadim Yanitskiy 11 Jun '17

11 Jun '17

Hi Neels, > If you submitted a patch for it I would probably +vote it. Not yet. > I guess it would actually be a whole bunch of patches, > a common part in libosmocore and using it in each osmo* program? Probably, it would be a whole bunch of patches for osmo* programs only. I was wondering about modifying libosmovty to enable a new VTY command in all projects, like Harald did in osmo-fsm implementation. But in case of FSM, all state machines are being registered before use, so libosmovty "knows" about them. What is impossible in case of talloc contexts right now. Of course, we can write a new function and register every root talloc context using it. What about that? Regarding to the commands to add, I think show ctx all - Show list of all registered talloc contexts. show ctx NAME - Find specified context and call talloc_report_full. With best regards, Vadim Yanitskiy. 2017-06-01 4:34 GMT+07:00 Neels Hofmeyr <nhofmeyr(a)sysmocom.de>: > re "what do you guys think about having a special VTY command to get a > talloc report?" > > If you submitted a patch for it I would probably +vote it. I guess it would > actually be a whole bunch of patches, a common part in libosmocore and > using it > in each osmo* program? > > ~N > >

2 2

Proposal: Usage of stow in jenkins build scripts
by Alexander Huemer 10 Jun '17

10 Jun '17

Hi, The osmocom software that I do not install via apt but build myself gets installed in $HOME/usr and I do things like: export PATH="${PATH}:${HOME}/usr/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${HOME}/usr/lib" export PKG_CONFIG_PATH=$HOME/usr/lib/pkgconfig MANPATH="${MANPATH}:${HOME}/usr/man" Therefore I don't have to install to a destination outside my home directory which in turn means I can avoid some sudo calls. But that actually does not matter so much, you can mentally substitute $HOME with '/' and append '/local' in the following if you want. I don't install to $HOME/usr directly but use stow for 'managing' the installations, so an installation goes like this: $ mkdir -p $HOME/src/telco/osmo/libosmo-abis $ cd $HOME/src/telco/osmo/libosmo-abis $ git clone git://git.osmocom.org/libosmo-abis $ autoreconf -i $ ./configure --prefix=$HOME/usr/stow/libosmo-abis $ make $ make install $ STOW_DIR=$HOME/usr/stow stow libosmo-abis This has two advantages: * Good visibility of what is installed by a package. $ tree $HOME/usr/stow/libosmocore * Possibility of uninstalling a package even if the Makefile is not present. For me those two advantages outweigh the small additional effort of using stow. Because of that workflow I sometimes run into situations in which make runs fail because either header files are not found during compilation or libraries are not found during linking. The reason is that autotools variables pointing to pkgconfig supplied directories point to a destination under the prefix path with which configure was called. If a dependency was not mentioned in a Makefile.am the required files are not found because the other dependencies are in other directories. For a system on which the osmocom-own dependency libs are installed in distinct directories, current openbsc master HEAD requires the attached patch for a build to succeed. I admit that in most situations the dependencies are installed in the same directory so this does not matter, but it is still a small bug. Therefore I propose to modify the jenkins build scripts so that they use distinct, stow managed directories for the dependencies. That should help to detect oversights, although admittedly developers would have to adapt their workflows to use stow as well in their daily hacking. Otherwise an oversight would be detected by jenkings and not locally which in turn would require additional cleanup commits which is not so nice. What is your gut feeling? Does the increased correctness of Makefiles.am contents justify the (IMO rather small) additional effort of using stow? Kind regards, -Alex

2 5

osmo-trx rach question
by Max 08 Jun '17

08 Jun '17

Hi. I'm troubleshooting peculiar use case with packet access and osmo-bts-trx. There are 2 options for ME to acknowledge reception of control packet to PCU according to 3GPP TS 44.060 § 11.2.2: 1) Packet Control Acknowledgement message 2) 4 identical access bursts The latter can be both 8-bit RACH and 11-bit RACH (not supported by osmo-bts-trx yet). The choice of response format is defined by OpenBSC in SI: 1) is default, 2) can be activated with "gprs control-ack-type-rach" option. The problem is that I don't understand how 2) will be handled by OsmoTRX? Shall I expect 4 consecutive RACH messages via rx_rach_fn() in scheduler_trx.c in osmo-bts-trx? Shall it be some other message/function? Will it be ignored/dropped altogether by OsmoTRX? -- Max Suraev <msuraev(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 Director: Harald Welte

2 1

osmo-trx: GSM signal generator
by Tom Tsou 07 Jun '17

07 Jun '17

Hi All, I wrote a GSM signal generator application based on osmo-trx. The new osmo-siggen allows random GSM or EDGE burst generation without using special configurations of osmo-trx or the socket control interface. Frame trigger output through GPIO is also available. I use the application for testing modulation parameters and other PHY level testing. Hopefully it's useful to other developers beyond myself. $ ./osmo-siggen -h Options: -h, --help This text -a, --args UHD device args -l --log Logging level ('err', 'warn', 'notice', 'info', 'debug') -b, --burst Burst type ('normal', 'access', 'freq', 'sync', 'edge') -r, --ref Frequency reference ('internal', 'external', 'gps') -f, --freq Tx RF frequency -g, --gain Tx RF gain -s, --sps Tx samples-per-symbol (only 4 supported) -m, --mod GSMK modulator type ('laurent4', 'laurent2', 'laurent1', 'nco') -p, --ampl Tx amplitude (0.0 - 1.0) -o, --offset Baseband frequency offset -t, --tsc Normal and EDGE burst training sequence (0-7) -S, --swap Swap channels Currently osmo-siggen is located in the below branch. I've tested solely with B210. C++14 availability is also required for now. git://git.osmocom.org/osmo-trx ttsou/siggen -TT

1 0

osmo-trx: Generating frame sync output on GPIO?
by Harald Welte 07 Jun '17

07 Jun '17

Hi all, I was wondering if it is possible to generate a TDMA frame sync output on a GPIO line of a USRP device (and/or any other SDR supported by osmo-trx). This way it would be much easier to do e.g. BER testing by using a pure waveform/pattern generator for the "MS side". Such devices (Like an E4433B) can only generate the uplink bursts with pseudo-random sequence, but they don't have any receiver, so they're not able to receive the downlink from the BTS in order to lock on the TDMA frame and transmit the uplink in sync to that. There are of course specialized devices (CMU-300, ...) or hardware options that add such receivers for synchronization on the signal generators, equipment side, but why go there if there would be an easy way to generate some kind of a frame sync output. I would appreciate to know even if there's a way to introduce such "synchronous GPIO toggles" or the like in the command stream to UHD devices. If that existed, it should be rather simple to insert those whenever a new burst for TS0 is sent. A rather computationally (and bandwidth) expensive other option might be to use the second RF output to generate such a signal, but I was hoping not having to abuse the 2nd channel for that ;) 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)

2 1

Accelerate3g5 Problem in cellphone attach procedure
by Lin HUANG 07 Jun '17

07 Jun '17

Hello, We met a problem during the cellphone trying to attach to the network. The modules we ran are: Nano femtocell <- LAN -> osmo-hnbgw <--> osmo-msc <--> osmo-hlr. The cellphone with sysmcom USIM searched the network 90170 and then tried to register in it. The authentication was passed but the connection was released. The cellphone automatically repeated the attach again and again, but always failed. In the output of HLR, it seems the authentication is OK: ---------------------- 20170606183004032 DAUC <0003> db_auc.c:222 901700000014922: Generated 5 vectors 20170606183004032 DAUC <0003> db_auc.c:227 901700000014922: Updating SQN=1728 in DB ... 20170606183005665 DMAIN <0000> luop.c:148 LU OP state change: NULL -> LU RECEIVED 20170606183005665 DMAIN <0000> luop.c:148 LU OP state change: LU RECEIVED -> ISD SENT ---------------------- But in the output of MSC: ---------------------- 20170606183005665 DMM <0002> gsm_04_08.c:3798 <- SECURITY MODE COMPLETE IMSI:901700000014922 ... 20170606183005666 DMM <0002> gsm_04_08.c:201 -> MSISDN:333 LOCATION UPDATE ACCEPT ... 20170606183005666 DMSC <000a> msc_ifaces.c:44 msc_tx 17 bytes to MSISDN:333 via RAN_UTRAN_IU 20170606183005666 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP DT (SUA link 0xcacde0 conn_id 0) 20170606183005666 DSUA <001b> sua.c:506 Received SCCP User Primitive (N-DATArequest) 20170606183005666 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 14 00 1e 00 00 02 00 10 40 12 11 05 02 09 f1 89 28 b6 17 08 99 10 07 00 00 10 94 22 00 3b 40 01 00 00 00 ) 20170606183005666 DVLR <001d> vlr_lu_fsm.c:321 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE 20170606183005666 DVLR <001d> vlr_lu_fsm.c:355 vlr_lu_fsm(901700000014922)[0xcd5250]{VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_PARENT) 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(901700000014922)[0xcd5250] 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Freeing instance 20170606183005666 DVLR <001d> fsm.c:275 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Deallocated 20170606183005666 DVLR <001d> vlr_lu_fsm.c:700 vlr_lu_fsm(901700000014922)[0xcd5250]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE 20170606183005666 DMM <0002> vlr_lu_fsm.c:692 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: Received Event SUBSCR_CONN_E_ACCEPTED 20170606183005666 DMM <0002> subscr_conn.c:77 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: SUBSCR_CONN_FROM_LU 20170606183005666 DMM <0002> subscr_conn.c:84 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: state_chg to SUBSCR_CONN_S_ACCEPTED 20170606183005668 DMM <0002> subscr_conn.c:132 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: Received Event SUBSCR_CONN_E_BUMP 20170606183005668 DMM <0002> subscr_conn.c:168 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: bump: releasing conn 20170606183005668 DMM <0002> subscr_conn.c:169 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: state_chg to SUBSCR_CONN_S_RELEASED 20170606183005668 DMM <0002> subscr_conn.c:255 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR) ---------------------- Why is there a 'Received Event SUBSCR_CONN_E_BUMP'? Regards Lin

4 5

ericsson rbs2308
by Rajitha peiris 07 Jun '17

07 Jun '17

hello everyone ...... anyone doingwith rbs2308 ? i am doing with dhai and E1 interface but it doesn't come to operational mode ....if anyone got any output from rbs 2308 pls let me thanks rajitha

1 0

images
by Neels Hofmeyr 05 Jun '17

05 Jun '17

People keep posting images to this list. I saw that mailman allows to remove image attachments by file suffix and/or by mime type. I suggest we put jpg, png, bmp on the list of attachments to remove. AFAICT there was zero need for a legitimate image post, and if we'd want to we can always create a wiki page or redmine ticket and attach the image there. It would be nicer to bounce messages with such attachments completely, but dropping the attachments is the next best thing. Opinions? I don't have access to the list admin, so (if we agree) someone else would need to effect this / give me the pw: mailman admin / "MIME-/HTML-Filter" / tick 'yes' on top and add image suffixes to the reject list ~N

1 0

ipaccess 1800/1900 model
by Albert Paijmans 03 Jun '17

03 Jun '17

Hello, In the Netherlands the free gsm channel for private gsm networks is; 1875 - 1879,9 MHz 200 mW e.r.p. 200 kHz 875 - 1879,8 MHz 50 mW/MHz e.r.p. ≤4,5 MHz But I am a little bit confused as to how to set up an ipacces nanobts with those frequencies In OsmoBTS configuration file find bts 0 and set band to GSM1800 Also set frequencies to right value arfcn The example says ( https://osmocom.org/projects/openbsc/wiki/Multi-BTS_with_handover) trx 0 rf_locked 0 arfcn 74 ... trx 1 rf_locked 0 arfcn 84 --------------- I am not sure what to put at arfcn as the correct frequency with the mentioned frequency.. A second question, the nanoBTS comes in 1800 for GSM1800, and GSM1900 variant thereof (almost identical hardware) Well I can get 2 of the 1900 version very cheap from the USA but setting the configuration file bts 0 band GSM1800 won´t change the frequeny of the 1900 model to 1800MHz? Or can I only use the 1900 version in the free 1900MHz DECT frequency range? I have attached the official document of the Dutch regulatory body with the allowed frequencies, see page 28 for DECT frequencies in 1900 band and page 29 for picocell frequencies in the 1800 band. To me it seems both bands 1800 and 1900 are allowed, 1800Mhz is the official private gsm but for testing purposes using a 1900 model on the DECT band should be ok to. If the nanobts 1900 US model could also operate on the 1800 band that would be even better. Thanks, Albert

3 2

osmo-gsm-manuals DRAFT
by Neels Hofmeyr 03 Jun '17

03 Jun '17

In our osmo-gsm-manuals, there are various code listings that one would like to copy-paste from the PDF. That would theoretically work, but practically, the 'DRAFT' watermark in the backdrop confuses the text marking, hence making copy-pasting some text from the manuals very very cumbersome. Though I'm not that sure why we need a 'DRAFT' watermark in an open source manual (it's implicitly a draft), I am fine with having such a marking. But I would like the marking to be less obtrusive. We could experiment with putting a bitmap image in the backdrop instead of text, or even better IMHO would be to put it in the page header next to the version. We could also add a generic "DRAFT" disclaimer near the beginning of each document. (Same goes for the sysmocom internal manuals, for which it isn't so easy to get the asciidoc source to paste from.) Any opinions on this? ~N

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2017