OpenBSC July 2016

openbsc@lists.osmocom.org

19 participants
39 discussions

by Neels Hofmeyr

Hi 3G folks, I would like to make our osmocom jenkins build openbsc with --enable-iu, which still requires use of non-master branches in aper-prefix, libosmo-sccp and libosmo-netif. I will at first make the jenkins build use these branches to build 3G, but since we'd like them to be merged to master anyway, let's try to push this forward. Here are the remaining tasks again, as from the openbsc@ mail on Feb 19, 2016: http://lists.osmocom.org/pipermail/openbsc/2016-February/007906.html ( <20160219083519.GA4570@nataraja> ) First the good news for libosmo-sccp: On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote: > > libosmo-sccp: * laforge/wip > > My main problem with this patch set is naming. We are creating an 'SCCP > User SAP' which should look the same no matter what the underlying > transport protocol stacking is. [...] This boils down to a mere rename of opaque structs osmo_sua_link and osmo_sua_user, which I've started to submit. https://gerrit.osmocom.org/477 > > asn1c: * aper-prefix First of all, it looks like we imported from svn, but Lev Walkin later did another migration to git, which we fetched as well. So our master is on our old svn import, while the upstream master has different hashes in its history. Our aper-prefix branch is based on the upstream history, not our "stale" master, which made a rebase a bit easier. Furthermore, on https://github.com/vlm/asn1c/commits/master there are scores of new commits we don't have in our asn1c. our last commit from Lev Walkin is from 2015-04-28, "?= was confusing some environments", 62913d8b8e1eb96d74315ff I have thus: * fetched upstream master from github's vlm/asn1c, pushed as new branch vlm/master to our git.osmocom.org/asn1c * rebased our aper-prefix branch to that master (with minor conflicts), pushed as new branch aper-prefix-onto-upstream We should probably: * reset --hard our master to vlm/master * reset --hard our aper-prefix to aper-prefix-onto-upstream (after testing) Agreed? Then follows: On Fri, Feb 19, 2016 at 09:35:19AM +0100, Harald Welte wrote: > > If you look at the aper code I took from OpenAirInterface and re-based, For the record: https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/S1AP/MESSAGES/ASN1 https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/S1AP/MESSAGES/ASN1… https://gitlab.eurecom.fr/oai/openair-cn/blob/master/SRC/S1AP/MESSAGES/ASN1… > you will see that it does not look 100% complete and would > probably not yet qualify for submitting it to the upstream asn1c > project. The situation is not made better by my hackish way to > implement the type prefixing on top of it by means of an environment > variable. > > Specifically, it > * contains commented-out code which might just have been a work-around > of some buggy code, rather than fit for removal in general > * contains TODO comments like "/* TODO: act upon NOTE in #18.7 for > canonical PER */" which hints that it is not properly implementing > parts of the PER specification > * contrary to the rest of asn1c, it does not come with a comprehensive > test suiet for the APER encoding and decoding routines of all types > > Any help in cleaning this code up (it could be done for the type > prefixing independent of the APER support) would be much appreciated. > The goal is to get this merged in asn1c, after all. > > It might also be worth to contact the OpenAirInterface guys about their > thoughts on moving this code forward. I fear there might be none, as > they are using an ancient version of asn1c to begin with. But they are > a much larger project and might be convinced to put some resources on > doing this properly? I've written to the openair-cn-devel list. https://lists.eurecom.fr/sympa/arc/openaircn-devel/2016-07/msg00001.html > Unless we think something is ready for pushing to upstream asn1c, we > should keep it out of our local master, too. > > libosmo-netif: * sysmocom/sctp > > commit d484b0593112222cef3f106da654df07c3d40919 (hash changed after rebases) > basically just > prints some messages to the log file in case there are association state > changes like UP and LOST. This is clearly not the intended behavior. > > The application should be notified accordintly in such events, > particularly in 'connection lost' events that can be communicated in the > same way as they can for e.g. TCP sockets. > > Only after that is resolved, we can merge it to master. This doesn't look like a lot of work, though I'm not familiar with how exactly this should be done. ret = sctp_recvmsg(conn->ofd.fd, msgb_data(msg), msgb_tailroom(msg), NULL, NULL, &sinfo, &flags); if (flags & MSG_NOTIFICATION) { union sctp_notification *notif = (union sctp_notification *) msgb_data(msg); LOGP(DLINP, LOGL_DEBUG, "NOTIFICATION %u flags=0x%x\n", notif->sn_header.sn_type, switch (notif->sn_header.sn_type) { case SCTP_ASSOC_CHANGE: LOGP(DLINP, LOGL_DEBUG, "===> ASSOC CHANGE:"); switch (notif->sn_assoc_change.sac_state) { case SCTP_COMM_UP: LOGPC(DLINP, LOGL_DEBUG, " UP\n"); call accept_cb? break; case SCTP_COMM_LOST: LOGPC(DLINP, LOGL_DEBUG, " LOST\n"); osmo_stream_srv_destroy() ? break; case SCTP_RESTART: LOGPC(DLINP, LOGL_DEBUG, " RESTART\n"); break; case SCTP_SHUTDOWN_COMP: LOGPC(DLINP, LOGL_DEBUG, " SHUTDOWN COMP\n"); break; case SCTP_CANT_STR_ASSOC: LOGPC(DLINP, LOGL_DEBUG, " CANT STR ASSOC\n"); break; } break; case SCTP_PEER_ADDR_CHANGE: LOGP(DLINP, LOGL_DEBUG, "===> PEER ADDR CHANGE\n"); break; case SCTP_SHUTDOWN_EVENT: LOGP(DLINP, LOGL_DEBUG, "===> SHUTDOWN EVT\n"); /* Handle this like a regular disconnect */ osmo_stream_srv_destroy() ? return 0; break; } return -EAGAIN; Thanks for any thoughts or even help :) ~Neels -- - 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

8 years, 11 months

OsmoTRX / BER, RSSI and Link Quality

by Harald Welte

Hi Tom and List, we're currently introducing some code that will make more use of measurement related information associated with the PH-RACH.req and PH-DATA.ind coming from the PHY up into L2. The first part is to introduce a reasonable BER limit fo 17% for RACH ghost elimination, but I have more plans for unifying the measurement processing/generation accross all supported BTS models. For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the related information on RSSI, BER and LinkQuality for each of the RACH and DATA indications from the PHY. However, how can I get the related information from osmo-bts-trx? osmo-bts-trx seems to lack any BER reporting toward the common part, which among other things is the reason why link/rate adaption in the PCU can not work with it. Could you sched some light on this? -- - 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)

8 years, 11 months

[PATCH 0/2] osmo-trx: add .gitignore, add a configure check

by Neels Hofmeyr

From: Neels Hofmeyr <neels(a)hofmeyr.de> Rebased the patches onto updated master, added a binary to .gitignore. Neels Hofmeyr (2): add basic .gitignore configure.ac: check for boost/config.hpp header .gitignore | 44 ++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 3 +++ 2 files changed, 47 insertions(+) create mode 100644 .gitignore -- 2.1.4

8 years, 11 months

dynamic PDCH

by Neels Hofmeyr

> I am Tiger. Glad to connect with you.From osmo-bts commitment I see you are > working on dynamic PDCH which I think is a breakthrough. Is it working now? > It looks like only support PDCH and Full TCH switch,right? Hi Tiger, thanks for your comments and enquiry! I am still working on TCH/F <-> PDCH switching for the osmo-bts-trx SDR platform, but for ip.access nanobts, SysmoBTS and the litecell15, dynamic TCH/F <-> PDCH switching is already functional. TCH/F <-> PDCH could be called the ip.access compatibility mode, as it uses ip.access vendor specific messages to activate and deactivate PDCH on a TCH/F_PDCH timeslot. There are plans to include TCH/H as well, using a different vendor specific extension. Though development has not commenced yet, which will depend on funding by interested parties. See: http://osmocom.org/issues/1565 http://osmocom.org/issues/1757 BTW, Tiger, you have contacted my private email address. Instead, I'm replying from my sysmocom address, Bcc to you and copying to our mailing list, which would be the most appropriate place for questions on osmocom development. ~Neels -- - 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

8 years, 11 months

Re: osmo-bts: Repository write acces / Gerrit migration

by Harald Welte

Dear Tom, I hope you don't mind me Cc'ing the list, as this question might come up again. On Fri, Jul 01, 2016 at 02:42:25AM -0700, Tom Tsou wrote: > I appear to no longer have write access to the osmo-bts repository. > "ERROR:gitosis.serve.main:Repository write access denied" > Can I have write access restored? As decided at the Osmocom Developer Conference in April 2016, we have started to use gerrit for a more formalized tool for code review. The advantages are plentiful, among other things submitted patches are running through 'make distcheck' on several supported platforms before even being eligible to merge. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for a short intro in how to use it. There are instructions both for submitting patches against master, as well as for pushing to user-private branches. 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)

8 years, 11 months

error install openbsc

by sms makhof

Hi all I am installing OpenBSC.I just following http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC (I am just Building libosmocore, Building libosmo-abis, Building libosmo-netif, Building OpenBSC and install library.) But when I tried to run OpenBSC,I encounter with this error(problem). user12@ubuntu:~$ cd '/home/user12/openbsc/openbsc/src/osmo-nitb' user12@ubuntu:~/openbsc/openbsc/src/osmo-nitb$ sudo ./osmo-nitb <0005> bsc_init.c:492 Failed to parse the config file: 'openbsc.cfg' Or how do I run the software(OpenBSC)! Or do I have to install something missing? Note: My Linux is version ubuntu 12.04 . Please help me. thank you.

8 years, 11 months

freebsd and jenkins

by Max

Hi. Yet again I've hit an issue with jenkins build failing on freebsd only: http://jenkins.osmocom.org/jenkins/job/libosmocore-gerrit/label=FreeBSD_amd… No warnings, no errors, just a failure which I'm unable to reproduce locally as I do not have access to any machine with freebsd. If we can't make freebsd tests optional (which I personally would prefer) can we at least configure jenkins in a way that it runs "cat tests/testsuite.log" so it's available via "console output" part of jenkins web ui? Or somehow else provide access to build artifacts. That will give at least some clue as to what exactly is broken on freebsd. Any ideas as to why build fails are highly appreciated as well. -- 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

8 years, 11 months

Is there a maximum separation in Mhz for ARFCNs on one BTS?

by Keith Whyte

Hi all, Would somebody who is familiar with the relevant part of the GSM spec be able to comment? I'm wondering if there's any issue in GSM running a dual TRX BTS with two ARFCNs on opposite ends of the band? For example, in GSM850, this would mean the downlinks could be on 869.2 and 893.8 Mhz so the phone could have to tune across a wider range between the SDCCH and TCH for example. Thanks!

8 years, 11 months

osmo-nitb/osmo-bts-trx: Logging traffic on A-bis interface

by Sebastian Stumpf

Hi all, I wanted to check if the bts - bsc communication works properly with my configuration. For example, if my osmo-nitb does send the system information messages to the bts. I tried the vty logging interface of osmo-bts and logged some messages, but they were not the messages I expected. I configured the groups rsl, oml, rll, rr and abis to "notice", all to "everything" and everything else to "error" and got following log output (lots of these and nothing else): ... <0006> scheduler.c:405 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=993588 ts=0 trx=0 <0006> scheduler.c:341 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=993588 ts=0 trx=0 ... PH-RTS.ind and PH-DATA.req seem to come from layer1 SAP, the osmo-trx and have probably nothing to do with the SI messages. Is traffic on abis generally not logged or is my log config faulty? I ended up configuring the gsmtap interface for osmo-bts and could so see the uplink/downlink in wireshark and could see that the SI information is properly sent. But gsmtap only works for the air interface. What is the best way for logging/sniffing the communication on the A-bis interface? With kind regards, Sebastian Stumpf

8 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2016