OpenBSC July 2017

openbsc@lists.osmocom.org

24 participants
43 discussions

legacy codecs / mixing rates and versions
by Neels Hofmeyr 18 Jul '17

18 Jul '17

Today I checked the new AoIP core network using an old Nokia 1100 handset, which confronted me with codecs. The Nokia 1100 says it is capable of FR2, FR1, HR1: Channel Type - (Speech) Element ID: 0x0b Length: 5 0000 .... = Spare bit(s): 0x00 .... 0001 = Speech/Data Indicator: Speech (1) Channel Rate and Type: Full rate TCH channel Bm. Prefer full rate TCH (8) 1... .... = Extension: Additional Octet .001 0001 = Permitted speech version indication: GSM speech full rate version 2 (GSM EFR) (0x11) 1... .... = Extension: Additional Octet .000 0001 = Permitted speech version indication: GSM speech full rate version 1 (GSM FR) (0x01) 0... .... = Extension: Last Octet .000 0101 = Permitted speech version indication: GSM speech half rate version 1 (GSM HR) (0x05) The "stock" osmo-bsc.cfg I was using so far had only HR3 configured. So I naively thought, let's do: codec-list hr3 fr2 hr1 But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is that a hard limitation? I'm not at all familiar with the reasons. Will we never be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist? Then I picked: codec-list hr3 hr1 That worked, but no audio: the Samsung Galaxy got HR3 and the Nokia HR1 (the BTS was configured for only TCH/F channels, so instead the Nokia actually got assigned an FR1 channel). The call was established but no audio worked. I believe in the OsmoNITB we used to complain in the log that we don't transcode in such a situation, and the call was aborted... When I pick codec-list hr1 then the call works between the handsets. Again both get assigned FR1 on TCH/F; if I configure the BTS to use TCH/H instead, both indeed get assigned HR1 as expected. All in all an interesting situation, which appears to mean that we practically can't allow the newer codecs alone because older handsets would not work, and we can't allow both because each side may pick a different one. Should we wait until we know both sides' codecs and consolidate with each other to pick matching ones before assigning? Is that a "late assignment" as in issue "avoid mismatching TCH/F vs TCH/H pchan types"? https://osmocom.org/issues/1778 But what if no match can be found? only MGW transcoding will solve all situations I guess. Are we planning to do that, also with IuUP in mind? https://osmocom.org/issues/1936 https://osmocom.org/issues/1937 ~N

3 4

new osmo-msc repository
by Neels Hofmeyr 13 Jul '17

13 Jul '17

I have created a fresh osmo-msc repository as a copy of openbsc.git, and pushed the first few patches for gerrit review to move to our "new" Osmocom CN: https://gerrit.osmocom.org/#/q/topic:vlr As suggested before, osmo-msc will see code review and patches merged for VLR, 3G and AoIP, and so will form the basis for creating osmo-bsc, osmo-mgw and osmo-sgsn, as distinct repositories replacing the current openbsc.git. All further development happening in openbsc.git from now on will have to be applied to the new repositories later. Keep that in mind, and maybe postpone larger conflict prone efforts for later. The review process could take some effort. Some of the commits are one collapsed commit of fairly large development efforts. Normally, commits should be small, but in the case of completely refactoring an entire section of the code (VLR) or adding a completely new feature (IuCS, AoIP), it doesn't really help to see incremental back-and-forth changes with intermediate errors and fixes. I decided to collapse the errors with their fixes, and to save the effort of logically plucking apart the large commits, since they anyway only make sense as a whole. If necessary for review, we can still do so. Despite the mass of changes, please do look closely. Parts of the new code have possibly been hacked up in a preliminary fashion and were forgotten to implement properly later -- this will become our new Osmocom master branches, the stable releases and our main development arena, so do apply your scrutiny and let's fix early what we can fix now. The other repositories (osmo-{bsc,mgw,sgsn}) also exist already, and I am preparing to make them work as separate entities after the code review, on respective neels/split branches. Each fresh repository contains the *full* openbsc.git history. The option of relying on grafts to include the old openbsc.git history when needed has been mentioned, but so far was more or less turned down. It is still possible to change that. The openbsc.git history is about 9 Mb -- not too large, so IMHO best to keep it with each separate repos to ease log browsing, git blame and so forth. OTOH, we have it four times, which makes 36 Mb of duplicated history. If anyone still prefers a flat snapshot migration with a wiki page describing how to graft in the old history, we may discuss and change that. No branches have been migrated except the current aoip development branch that is going to become the new master. All tags are included, except: the signed '0.1.2' openbsc version tags are replaced by 'openbsc/0.1.2' tags pointing at the same revisions, so that we don't confuse them with the new version tags in each new project. Preliminarily, the last openbsc.git master has been tagged as version 0.0.1 in order to get *something* out from git-version-gen, useful for referencing a version of the new libosmo-mgcp library in osmo-{msc,bsc} configure.ac. We still need to decide whether to start versioning afresh or continue from the openbsc.git version scheme. openbsc.git ended with 0.15.0. My personal choice would be to bump the major and start from 1.0.0 in each new repository. ~N

2 2

Question about activate GPRS
by Marcus Dias 13 Jul '17

13 Jul '17

Dear all, I have one sysmo2050, with the GSM running fine. However, i would like to test GPRS data transmission, I was following this setup page ( https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS#Open…), but i couldnt make it work. Anyone has done it before / can help me? Thanks beforehand, Marcus Dias UFPA - Lasse - LaPS

3 4

[RFC] rework location update request
by Alexander Couzens 12 Jul '17

12 Jul '17

Hi, recently my modem with an already known SIM got a location update reject, because the procedure timed out. So I looked more into the location updates. How openbsc location update works: MS Network LOC REQ -> <- Identity Req IMSI Identity Resp IMSI -> <- Identity Req IMEI Identity Resp IMEI -> <- LOC ACCEPT OpenBSC is using a Timeout (5 sec) for the completion of location update. So let's say we trigger for unknown reason the timeout (e.g. RF problem). MS Network LOC REQ -> <- Identity Req IMSI (No response) <- LOC Reject! cause 13 / No roaming allowed. If the MS receive it, it will put our network on it's blacklist and won't try it again until power cycled. We could change reject cause to something different [1], but we might want to reject foreign SIMs not to try our network again. The problem here is that openBSC use the same configuration to reject unknown SIMs as well for timeouts. But I think this timeout should be removed. 04.08 doesn't describe a timeout on location update request on network side. But it describes other timeouts: 04.08 describes: - T3260 auth req. sent, wait until response (12 sec) - T3270 identity req. sent, wait until response (12 sec) I think we should implement both timers and drop the RR connection if it fires. I'm unsure if it's needed: But OpenBSC could count un-successful location update req. Reset counter if it's succeeded. After a certain amount of failures we send a location update reject. (unsure which cause) best, lynxis Related Specs: GSM 04.08 [1] Chapter 4.4 describing location update GSM 04.08 [1] Chapter 11.2 Timers GSM 04.08 [1] Chapter Annex G Reject Causes [0] nitb.cfg: network: location updating reject cause [1] ETSI TS 100 940 -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

2 1

Osmocom releases
by Max 12 Jul '17

12 Jul '17

Hi. So far releases of Osmocom project were rather rare and without any schedule. It would be nice to change that but to do that we've got to make the process of making a release as smooth as possible. The ticket which tracks this activity: https://projects.osmocom.org/issues/1861 What we have right now: https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release What I've implemented: https://gerrit.osmocom.org/#/c/3130/ The TLDR: we type "make REL=minor release" and get: * signed and tagged commit * automated version bump * updated debian/changelog Longer explanation: That's implemented as separate makefile which is installed as part of libosmocore-dev and can be re-used by other projects in few lines (see https://gerrit.osmocom.org/#/c/3131/ for example). It treats libraries separately from non-library projects (we don't have to clean up TODO-RELEASE in the latter case). Also, it does not update LIBVERSION automatically (see https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info…" for details) - I'm not quite sure how this can be automated. Caveats: - it does not push the committed result automatically - so far it's left as an additional chance to inspect the changes before pushing them. Also I'm not sure if we have to tweak our gerrit setup to allow for signed tags to go through and how will it interact with auto-rebase. - it does not replace human decision, it's still your job to adjust version requirements for the libraries you use and properly bump LIBVERSION - it enforces use of semantic versioning (see my previous email about semver and http://semver.org/ for details) Questions: - does it make sense? - what and, more importantly, how can we automate in addition to that? The intention is to make release process easy enough so we could make releases more frequently (maybe even have some schedule for it in a long run). -- 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 2

compiling tests during make
by Max 12 Jul '17

12 Jul '17

Hi. I've noticed that we do not use check_PROGRAMS in any of our Makefile.am (happy to be corrected :) so all the tests/ binaries are built during "make" step instead of "make check". Is this intentional? If so - why? Is this smth we'd rather fix? -- 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

plan for openbsc.git split and code review
by Neels Hofmeyr 12 Jul '17

12 Jul '17

I am currently setting up separate repositories to replace openbsc.git. Aspects: - choice how to separate - apply 3G and AoIP changes to do code review My plan is to separate openbsc.git into these parts: osmo-msc.git = OsmoMSC osmo-bsc.git = OsmoBSC, OsmoBSCNAT osmo-sgsn.git = OsmoSGSN, OsmoGTPHUB osmo-mgw.git = new OsmoMGW, at first plain renamed from osmo-bsc_mgcp + libosmo-mgcp Each of these will contain the full openbsc.git history to be able to follow changes back in the log easily. The libmgcp has so far been internal to openbsc.git. I intend to make it an installed library from osmo-mgw.git (similar to libosmo-ranap from osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not been aware of until now. libiu, shared between MSC and SGSN, has already moved to osmo-iuh. The other thing the MSC and SGSN still share is the GSUP client. The GSUP protocol code has already moved to libosmocore, but the gsup_client is still in openbsc. I believe it is appropriate to move the gsup_client along to libosmocore, even though the notion so far has been to keep it out of there. Otherwise we either duplicate the gsup_client or need another separate libosmo-gsupclient. Possibly other code needs to be moved around similarly, but AFAICT "decreasing in importance". Code review: We can review in various ways. I believe the least troublesome would be this: - create osmo-msc git from the current openbsc. - remove the top level 'openbsc' dir. - go through all of the patches in gerrit to apply to 'master', which will apply the VLR+HLR, then 3G and then AoIP, across all of MSC, BSC, SGSN and MGW, all of these in osmo-msc.git. - the state thus reached is the basis for the split. Copy this to osmo-*.git - in each separate git, remove the files not needed for that particular project. Remove possible remaining code duplication as we go. openbsc.git | | copy v osmo-msc.git | | - `mv openbsc/* .` v | gerrit code review: | +VLR | +3G | +AoIP | +------------------------------- | | v | ----------copy-------- | | | | | v v v | osmo-bsc osmo-sgsn osmo-mgw osmo-msc | | | | | | | | clean unrelated files v v v v continue ongoing development from these new master HEADs I'm currently playing through the separation, osmo-msc with top-level openbsc removed is done, osmo-mgw and osmo-bsc pending. This means that I will need to apply commits merged to openbsc from now on to the new separate gits until we move over for good. That's fairly similar to keeping the 3G,AoIP branch rebased onto openbsc master as we did previously. It may make sense to focus AoIP development onto the new repositories soon. So far I'm keeping the gits privately on a sysmocom office machine. We could also open up new osmo-* repositories on gerrit and git.osmocom.org now. ~N

3 3

OpenBSC Random Access Channel: rach_bsic != bts_bsic
by Vadim Yanitskiy 12 Jul '17

12 Jul '17

Hi all, During experimenting with RACH requests in my virtual Um-interface environment, I found an interesting issue in OpenBSC. According to the specifications, every RACH request should contain BSIC value of target base station, and if I understand correctly BSC (or BTS?) should ignore such requests, where rach_bsic != bts_bsic (Ghost RACH). Meanwhile, when I send all-zero sequence (just for testing) on RACH lchan, BSC allocates me a channel despite bts_bsic != 0x00. It probably also explains the reason, why sometimes in a real OpenBSC + OsmoBTS setup I see channel requests, followed by channel allocation without any further response from MS side. So, do we have any BSIC matching functionality implemented somewhere? If not, I could try to open an issue and implement it. With best regards, Vadim Yanitskiy.

2 1

Control Interface to OsmoSGSN
by Omar Ramadan 12 Jul '17

12 Jul '17

Hey Osmocom, I am trying to understand how to interact with the SGSN via the control interface and do a few things that I can't find documentation for. Hoping you can help explain how to: 1) Query(or push) CDRs for active data sessions 2) Terminate active PDP context (network initiated detach) 3) Manage the ACL for the PS domain (assuming via HLR?) Thanks, Omar

3 2

Re: sscp-context initalization via VTY
by Philipp Maier 10 Jul '17

10 Jul '17

Hello Neels, > (any reason to not discuss this on openbsc@?) I put it on CC. > Still missing in this proposal: how do you tell e.g. the MSC's A and IuCS code > to use a given SCCP instance, local SSN and remote SCCP address? I would add a VTY command where the user has to tell on which ss7 instance the A or IuCS interface should bind. When the IDs for both match up, we know that we use the same SCCP instance, but I think we do not even have to check that. Its implicit by the pointers. If the numbers are the same we will end up with the same sccp instance pointer for both. The SCCP-Addresses are defined by the addressbook. Which one is used will be configured via a VTY command seperately. The SSNs are hardcoded, so this is not a problem currently. If someone wants configurable SSNs and wants two users with different SSNs but same local point codes (which is mandatory in this case), then the user would have to define two addressbook entries where only the SSN is different. Logically this is then a different address and look at postal addresses, there its the same. Two different houses next to each other will have different addresses. The only difference is the number (SSN). At some point we have to make the cut. We could think about unifying the osmo_sccp_user_bind() function as well, so we would get pointers for ready-to-go sccp-users as well, but I think this is out of scope right now. The solution would be similar to the addressbook. We would just define nodes which hold the parameters. The results end up in a list and after parsing is done. The user can call a function that only gets the ID that references the parameter set, the pointer to the sscp instance and the function pointer for the SAP. e.g.: osmo_sccp_user_bind_id(sscp,2,sccp_sap_up) > A much simpler soultion to the problem would be to pack the configuration > options into struct osmo_ss7_instance. Then when the config file parsing > is done, the user must call a function e.g. "osmo_sscp_init()" or so to > trigger the call to osmo_sccp_simple_client(). In struct osmo_ss7_instance we already have the .cfg sub struct. I think we should add the items there instead of introducing something new. Also if we do so we would have to change it for the existing code too to have it consistent. Lets do some practical examples: 1) A and IuCS use the same sscp/ss7 instance cs7 instance 1 sccp-address msc_local point-code 0.0.2 routing-indicator PC sccp name iucs_and_a pc msc_local prot M3UA local-port 1234 remote-port 5678 local-ip 1.1.1.1 remote-ip 2.2.2.2 msc cs7-inst-a 1 cs7-inst-iucs 1 local-addr msc_local 1) A and IuCS use separate sscp/ss7 instances cs7 instance 1 sccp-address msc_local point-code 0.0.1 routing-indicator PC sccp name a pc msc_local prot M3UA local-port 1230 remote-port 5670 local-ip 1.1.1.4 remote-ip 2.2.2.4 cs7 instance 2 sccp-address msc_local point-code 0.0.2 routing-indicator PC sccp name iucs pc msc_local prot M3UA local-port 1234 remote-port 5678 local-ip 1.1.1.1 remote-ip 2.2.2.2 msc cs7-inst-a 1 cs7-inst-iucs 2 local-addr msc_local regards. Philipp -- Philipp Maier <pmaier(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

3 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2017