OpenBSC June 2017

openbsc@lists.osmocom.org

23 participants
44 discussions

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

libosmo-sccp: Build breakage on --disable-static
by Holger Freyther 03 Jun '17

03 Jun '17

Hi, I just looked into a build breakage when --disable-static is passed. The first failure is because of: libosmo_sigtran_la_LDFLAGS = -version-info $(LIBVERSION) \ -no-undefined \ -export-symbols-regex '^osmo_' The testcases use xua_* sua_ symbols but they are not exported. Shall we export them or shall we forbid --disable-static on libosmo-sccp? The second part is that I had preferred the sccp library to be static only to avoid having to do proper ABI checking/versioning. If we fix the above, maybe we have to fix this part too? holger

2 2

Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB
by Gerard Lawrence Pinto 01 Jun '17

01 Jun '17

Greetings, Congrats on OsmoCon 2017! I have been working with OsmocomBB, osmo-sim-auth, mncc-python projects in Osmocom. I would like to contribute some code snippets with your acceptance. To begin with I have committed: I) MNCC with OsmocomBB - *https://github.com/GerardPinto/call-control-mncc-sap <https://github.com/GerardPinto/call-control-mncc-sap>* (Has both implementations in Python and C + Tested voice with gsm-fr with gsm audio file - works great). - Some of which can be committed to mncc-python? (In order to support MNCC with OsmocomBB too) Although, Harald told me it was built for OpenNITB - I'm not sure, the relevance of this contribution to this repo? Reason: 1. Solves some mailing list questions: Some questions on mailing list are pertaining sending voice from PC to phone and receive. 2. Useful for test cases: In the future, if 'gsm-efr' codec is implemented, we can use these snippets and send audio with gsm-efr sample, instead of connecting to LCR (Am I correct?) *Issues faced*: File: l23api.c | function: l1ctl_rx_traffic_req() 264 bits (33 bytes) of voice codec are interleaved into 456 bits. The DAC, ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 = 456. So Layer23 sends 4 - 114 bits into the queue to Layer1 in function => l1ctl_rx_traffic_req *Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC]) if num > 4 dropping traffic frame. (114 x 4) The code above indicates if queue has any (114 x 4) bits drop the incoming voice request. So I faced the issue of voice packets getting dropped, but that was just twice/thrice and then it did not give me any trouble (I'm not sure how it got fixed), I could hear *clear* voice gsm-fr on the called party cell phone. *My Question is*: If I happened to send voice packets 33 bytes really fast. There should be some kind of buffer rather than a check (Code) and drop frame? - OR this case can never happen? My apologies, if my understanding is incorrect, I just tried to reverse engg. from code and GSM codec available online! II) osmo-sim-auth with added other SIM related API's (still needs code clean up, SIM response check, code re-usable, README.md etc,) * https://github.com/GerardPinto/osmo-sim-auth <https://github.com/GerardPinto/osmo-sim-auth> * - I did check out PySIM (I think I can add some code to the existing repository, with your permission). Could you please let me know if my osmo-sim-auth repo? If it is correct to combine with PySIM, with the changes done below? Files modified: 1. SIM.py - Added more API's. 2. osmo-sim-auth.py - Options parser. Thanks, Gerard.

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2017