OpenBSC

openbsc@lists.osmocom.org

12 participants
4278 discussions

Osmocom nightly packages
by Martin Hauke 04 Mar '17

04 Mar '17

Hi, i'm building osmocom-related packages for openSUSE since a few years on OBS. https://build.opensuse.org/project/show/home:mnhauke:osmocom https://build.opensuse.org/project/show/home:mnhauke:osmocom-iuh Now i'd like to add support for RPM-based distributions to the osmocom-nightly packages. My current plan is to first add support for (open)SUSE based distributions and if there's interest then find out all the subtle changes that are needed for the spec-file to also add support for Redhat/Fedora/CentOS. # Phase1 - openSUSE_Leap_42.2 (x86_64) - openSUSE_Tumbleweed (i586, x86_64) - openSUSE_Factory_ARM (armv7l, aarch64) - SLE_12_SP2 (x86_64) # Phase2 - CentOS_7 (x86_64) - Fedora_25 (i586, x86_64) - RHEL_7 (x86_64) How does the current workflow for the daily check-in of the nightly debian/ubuntu packages look like? There's probably a bunch of scripts that do - git checkout from all relevant repositories - update changelog based on git commit messages - change the package version - create the new tarball - maybe osc local build - upload the tarball and the dsc to OBS - monitor if all the OBS-packages are successfully built and in state published Thanks in advance, Martin

2 1

osmo-(bts-)trx multi-trx is broken
by Max 04 Mar '17

04 Mar '17

Hi. There's been few updates to osmo-bts-trx recently so I've decided to get back to https://projects.osmocom.org/issues/1648 and it seems like it's completely broken: - the "multiplexing" option (osmo-trx -m -c 2) which used to work now leads to startup error of osmo-trx - the "separate channel" option (osmo-trx -c 2) which wasn't working properly but at least phone could see the network, now leads to situation where no network is visible Am I missing some magic combination of .cfg and command-line parameters which could make it work? Am I using too old version of uhd or smth else? The hw has not changed (usrp b210 + external 10MHz reference clock) but maybe I've got to do some calibrations on it? Any ideas as to what could be causing those regressions? Is there anyone out there for whom some multi-trx setup is working? If so, I'd like to compare notes to understand why it isn't working form me. -- 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

4 4

Virtual layer 1 - Questions
by Sebastian Stumpf 04 Mar '17

04 Mar '17

Hi, The virtual layer 1 is currently in a state where the l23 app can successfully connect to the bts and most of the signaling messages will be forwarded and handled. TCH is not yet implemented. I have some problems still, not knowing if these are caused by configuration problems or my coding :). - Trying to initiate a call via the mobile vty will result in VTY: call 1 123 OsmocomBB# % (MS 1) % Call has been rejected call 1 123 OsmocomBB# % (MS 1) % Call has been released And no actual call setup message is transfered over the Um interface. What could be reasons for that? I am using the test-sim option the mobile app offers. - Occasionaly the T3210 timer is fired, which causes a new registering within the network. LOG: gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired How can i prevent that? - I did not implement a tdma or multiframe scheduler in the mobile uplink as the logical channel is directly put to the gsmtap-header and thus known by the bts. As Harald used a multiframe based scheduling for the bts downlink, i wonder if this might be necessary, though. To submit msgs with the correct frame number for example. - In my wireshark capture files, the gsmtap messages sent over the multicast sockets are only recognized as UDP messages. I have to "cast" them with the wireshark context menu "Decode as...". Why? I would be super happy if someone of you could check out my project (osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch stumpf/virt-phy) try to run it with the config files lying within the project folders and tell me the problems they see :). Here you can find a wireshark capture file of 2 mobiles connecting to a virt bts. I also tried to init calls from both of them but the call setup is not send. https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-… Kind Regards, Sebastian Stumpf

2 7

how to stop paging
by Neels Hofmeyr 03 Mar '17

03 Mar '17

I have a general question about the Paging procedure, specifically about how to stop paging. In libbsc, we have Paging management that receives a request to Page from the MSC and then repeatedly Pages the MS on all BTSes N times or until told to stop. In the NITB, we have code closely tied to the BSC and all BTS management, so that when we receive a Paging Response, we can right away stop sending Paging Commands on all BTSes. So can the standalone-BSC: it stops paging when it received a Paging Response. In OsmoMSC with Iu- and A-interfaces, that's not possible. Looking in 08.08, there seems to be no A-interface message that tells the BSCs "thank you, you can stop paging now". If one BSC or RNC has relayed back a Paging Response from one of the cells, the MSC has no way to tell the other base stations that it's fine to stop sending dozens of Pagings out for "minutes", which would be useless now anyway because the MS has called back via another base station already. Is that a fact of life? We continue Paging in all cells where the MS is not visible? Should the BSC/RNC part of the network page only once, so that "stop paging" is a no-op? Of course we first check which LAC the MS was first seen on and page only there. Is the idea to send paging to one cell, and that cell stops Paging by itself when it received a Paging Response that it relays to the MSC? But IIRC Paging is supposed to spread out across other base stations if at first it didn't succeed -- I recall to have read that in HNB-GW specs or somewhere close to that. Our OsmoHNBGW so far simply Pages everywhere. The practical reason I'm asking is that in the msc_vlr tests, I so far explicitly check whether the "stop paging" function was called. Now on the Iu branch, without libbsc, there is no such function. Should I drop those checks because we will never have that? Or should I add some shim function we call just for the tests so far, which will at some point tell the base stations that Paging has concluded? Thanks for any hints, ~N -- - 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: Harald Welte

1 0

my patches prioritized
by Neels Hofmeyr 03 Mar '17

03 Mar '17

I currently have a whole series of patches on gerrit, many of which fail to build. Here are the pivotal ones I am waiting for, the other patches can be mostly ignored until these are through: https://gerrit.osmocom.org/1682 (struct bsc_subscr) Waiting for a comment. VLR and 3G branches build on it. I'm happy to change the patch, but not sure whether I really have to. IMHO there are benefits to this unusual way, but one word ("no") is enough. https://gerrit.osmocom.org/1923 (cosmetic prep for 1924) https://gerrit.osmocom.org/1924 (python tests: VTY connection speedup) These two are needed for the openbsc python tests speedup patches to work. https://gerrit.osmocom.org/1962 (explicitly terminate ctrl_type_vals[]) https://gerrit.osmocom.org/1940 (find unterminated value strings) The first is a fixup for the second to work, the second one is needed for all of the other value_string topic patches to work. I'd like to add this check to jenkins now, so that all incoming value_string[]s are validated. https://gerrit.osmocom.org/1906 (python tests from separate build dir) I usually build 2G and 3G separately, and I'd like to run the py tests in each dev cycle, now that they are faster. So I'd love to merge this. Hope this helps to save some time... ~N

1 0

libosmo-netif failed on both jenkins FreeBSD and xUbuntu_16.04/i586
by Neels Hofmeyr 28 Feb '17

28 Feb '17

It seems to be a sporadic failure due to timing. Kicking off the same build on jenkins resulted in success. Can anyone relaunch the OBS build? I'm not too familiar with it... http://jenkins.osmocom.org/jenkins/job/libosmo-netif/ https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… Also, it would actually be nice if the opensuse builds also printed all test logs as in osmo-ci/scripts/cat-testlogs.sh -- if anyone knows how and has the time to insert such, that would be great. (git clone https://gerrit.osmocom.org/osmo-ci) Thanks, ~N

2 1

Handover and load balancing on SysmoBTS 2050
by Keith 28 Feb '17

28 Feb '17

Hi list, Hi all. This is quite Rhizomatica, or at least litecel 2050 specific, please excuse me for that. I also don't know, maybe it applies to other use cases. Rhizomatica has one community where an attempt was made to increase coverage at the same time as capacity, by installing two 2050s with a somewhat overlapping coverage area. We have currently plans to do the same in other places. The goal of this email is to try to establish the work needed to be done in order to fix what I outline below, I may just be lacking knowledge in some cases, in other It seems we need to implement some things. I have grabbed fairwaves' meas_json and meas_web and modified a little to give me a visualisation of the neighbour meas reports. So my first doubt is about idle cell reselection on the part of the MS. It doesn't seem to be operating quite as I would imagine it should and I am wondering is there any parameter that might make a difference, such as cell_identity? Is cell reselection hysteresis/offset relevant when handover is disabled? These parameters are not described in the manual. If I understood them I could update that. In the meantime, we seem to be getting reports from users that "the signal is weak" near what I might call the secondary BTS. At the same time, user reports are not terribly reliable. However what seems to be happening is that the MS is camped on the primary BTS, subsequently they have moved away so their handset is showing less 'bars'. I'm sometimes seeing TCH in use on the primary BTS that are showing neighbour measurements from the secondary that are more favourable. Of course, I am often seeing messages such as: handover_decision.c:203 (bts=3,trx=0,ts=2): Cell on ARFCN 242 is better: Skipping, Handover disabled Obviously, this makes sense, and I am not sure why historically we have handover disabled, I presume it is issues with rtp, although we are using the rtp_proxy. I don't have two BTS so I can't test locally here. Could anybody comment on the state of that? I am assuming that there is no way we can do load balancing unless we first have handover enabled, at the same time it is unclear to me if it will even work with handover. I believe this is called "Traffic Handover" Is this already implemented in the BSC? As in, can the BSC assign a channel on another ARFCN to the MS if the current ARFCN (the one the MS makes the access request on) has no TCH available? I also have a doubt about operation with a Litecel/2050. Obviously you don't really want rescue handover operating between the two BTS that are present in the Litecel as it is the same antenna, and this shouldn't happen anyway as the signal levels should never be sufficiently different, but we do want load balancing handover. I do see "no resources available" log messages, (especially related to the BROKEN channels issue) when one BTS in a litecel has no more capacity but the other does, so it would seem that the BSC is not managing this. Is that correct? Would it be correct to assume that maybe some handover rules are required that would specify: Handover from BTS 0 to BTS 3 but not from BTS 0 to BTS 1? Finally, I have a doubt about the rtp proxy mode. Was it ever discussed to implement SIP Mobility aka re-Invite in order to be able to do BTS-MGW rtp and also handover? This would seem to me to be a good thing to have? k/

5 14

vlr+hlr: Insert Data
by Neels Hofmeyr 27 Feb '17

27 Feb '17

What should we do if the HLR sends no Insert Data? When a subscriber does a Location Updating, the VLR sends a Location Updating request to the HLR. The HLR typically responds with a Location Updating Result as success and, in a *separate* message, sends an Insert Data to the VLR to tell it the subscriber's MSISDN. So it is possible to do a successful Location Updating without being told the MSISDN (as my test verifies). What should the VLR do if it never receives the Insert Data from the HLR? In that case the subscriber is attached but cannot be reached by MSISDN. Should we actively wait for Inser Data and reject the subscriber if not successful? It would be fairly easy to just send the MSISDN along in the Location Updating Result. Why this separate message? Thx, ~N

4 7

Ki and OPC values change when programming MCC and MNC
by Giselle Gonzalez lopez 27 Feb '17

27 Feb '17

Hello, We have already contacted our SIM cards provider (sysmocom), and they have referred us towards this Mailing List. We have purchased sysmoUSIM-SJS1 cards and we are having the following problem when trying to program them: We want to change the MCC and MNC values to the ones of our OpenAirInterface LTE system, and Ki and OPC of the SIM card are changing despite we are not intending for that to happen. The main issue with this behavior is that as we have two sets of Ki and OPC values, when we are going to register the user in the LTE database, we don't know for sure which set of parameters we are supposed to introduce. Here on I'll describe the configuration we are using and the commands introduced when programming the SIM cards: As programming software we are using PySIM. The default parameters of the SIM we are programming are: ADM: 20168462 ICCID: 8988211000000099120 Ki: 5B868E2B30C61190ABEFBA1CA6F6D56F OPC: B3425076F23BA6054557FA359B4F9C0C The parameters we are meaning to program are: MCC: 001 MNC: 01 IMSI: 001010000009912 The command we are using to program in the SIM card is: ./pySim-prog.py -p 0 -a 20168462 -x 001 -y 01 -t sysmoUSIM-SJS1 -i 001010000009912 -s 8988211000000099120 And after programming the card, we are getting this: [image: Imágenes integradas 1] Do you what's the reason why this is happening? Thank you very much for your time Best regards, Giselle Glez

4 8

OsmoHLR and IPA unit id
by Neels Hofmeyr 26 Feb '17

26 Feb '17

I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. Which way shall we resolve this? ~N

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC