OpenBSC February 2019

openbsc@lists.osmocom.org

15 participants
25 discussions

Neighboring femtocells
by Mykola Shchetinin 07 Feb '19

07 Feb '19

Dear Osmocom community, Does somebody have experience using multiple 3G femtocells connected to a single HNBGW? Do cell reselection and handover work properly? How did you configure it? Also, Osmocom (or Syscmocom?) used 3G networks at Congress 35c3. Were you using multiple femtocells? Were they connected to the same HNBGW? How did you configure them for cell reselection and handover to work smoothly? Thank you! Kind regards, Mykola

2 1

GSUP: E-interface messages for inter-MSC HO
by Neels Hofmeyr 06 Feb '19

06 Feb '19

Hi Oliver, I've already spent some time on a first draft for the new messages we will need to implement the E-interface via GSUP for inter-MSC handover. It would be excellent if you could take over from what I have so far. I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho: http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/… Anyone else is also more than welcome to take a look and remark on anything that might seem a bad idea, etc. This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to freely share the trace, let me know if you need details. The most interesting bits in the draft are - the new message types - the newly added IEs (see "Of which are newly added...") The tasks for you would be: - Spell out the protocol messages in common/chapters/gsup.adoc - Implement the definitions in gsup.h - Implement encoding and decoding, and tests It is not so trivial to understand what goes with which message; maybe you don't even need to know in detail? But if any info is still missing for you to grok what's going on, don't hesitate to ask, as always. Also interesting to figure out: Implement the IPA routing for which I added the source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr forward messages to each other via GSUP. - Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and to extend the gsup_server so that we can use the source_name/destination_name IEs to forward GSUP messages between the two clients. (I added these because I'm fairly certain there is no existing in-band IPA protocol bits that would allow such routing; but I only briefly skimmed it, wouldn't hurt if you could verify that again.) The aim is to have plain gsup_client API to allow me to "just send messages back and fort". - The session_id/session_state: we still need to figure out how to avoid collisions in session_id numbers, as any peer may at any point re-use the same session_id. Vadim suggested using a TI flag that gets flipped between sender and receiver, but since there are more than two peers, I guess we should treat each session_id as subordinate to a Request's source_name. IOW, any peer owns the entire session_id number space itself for sending out Request message types, and a Response or Error message type echos this session_id back with the source_name then having become the destination_name; it is perfectly legal for two peers to use the same session_id and collisions are avoided by Request vs. Response/Error. Something like... MSC-A MSC-B MSC-B' -------> FOO_REQUEST(source=alice, destination=bob, id=3, state=BEGIN) <------- FOO_RESPONSE(source=bob, destination=alice, id=3, state=CONTINUE) -------> BAR_REQUEST(source=alice, destination=bob, id=3, state=CONTINUE) <------- BAR_RESPONSE(source=alice, destination=bob, id=3, state=CONTINUE) ---------------> FOO_REQUEST(source=alice, destination=fred, id=4, state=BEGIN) <--------------- FOO_ERROR(source=fred, destination=alice, id=4, state=CONTINUE) ---------------> END_REQUEST(source=alice, destination=fred, id=4, state=END) -------> END_REQUEST(source=alice, destination=bob, id=3, state=END) (We could possibly omit the source_name in Response/Error message types, because the Requestor already knows the peer from sending out the Request; but for sanity, maybe rather always keep both names.) Does this make sense / am I missing something? - And we need to make sure that we can freely re-use the session_id IE on the E-interface without conflicting with the Supplementary Services session_id / without confusing the gsup_client API. Please create issues on osmocom.org for these tasks as you see fit. There is no pressing need yet to get this done *right now*, I have yet to complete the inter-BSC HO in osmo-msc before I can start using GSUP. But it would be great to just build on working API once I need it. I would be super grateful if you could relieve me of the burden of spelling out these details. From the meetings I assume that sysmocom agrees; please manage that, too, and let me know if any other tasks are more important... Thanks!! ~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

4 11

Osmo-SGSN/3G PS unstable behavior question
by Mykola Shchetinin 06 Feb '19

06 Feb '19

Hello, dear Osmocom community, Has somebody been looking at the issue https://osmocom.org/issues/1977 recently? Or, in other words: has anybody got the 3G Packet Switched network working in Osmocom reliably? I am looking for hints that might help me to fix the issue or for possible hacks/fixes if somebody has implemented something like that in their setups. Thank you! Kind regards, Mykola

2 1

Limesdr mini on Orange Pi Zero
by Gullik Webjorn 06 Feb '19

06 Feb '19

I have now moved the Limesdr mini back and forth between the Orange Pi Zero and a Supermicro (i386). On the Pi Zero I get the following on the console: Tue Jan 22 20:36:43 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043130448] ClockInterface: sending IND CLOCK 321960 Tue Jan 22 20:36:44 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043130448] ClockInterface: sending IND CLOCK 322176 Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 894a7c got 895e68 (895e68) diff=13ec Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 895440 got 897024 (897024) diff=1be4 Tue Jan 22 20:36:45 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043130448] chan 0 recv buffer of len 2500 expect 895e04 got 897de4 (897de4) diff=1fe0 The DDEV message can continue for a long time, and typically then ends with the transceiver exiting. It can however sometimes recover, and the first message of recovery is a IND Clock message, after that the transceiver restarts, and all is again well for some undefined time. I have followed your suggestions, and rebuilt --with-neon-vfpv4 , and I have enabled debugging. If I understand correctly, the function is readSamples, and is the actual input from the Lime rx. The length seems always correct, since I do not get that log entry, but rather that the time has "slipped", i.e. the LMS api has not delivered anything for "diff" time, or the timestamp received has "jumped" in the Lime. This indicates to me that this specific arm cpu in combination with limesdr mini and the software "drops data". I will gladly try to debug or narrow this down, but ask for some suggestions on how to proceed. One thought is to save a timestamp each time through readSamples and compare to some constant to determine that the problem is NOT that we are unable to read as fast as required. reading 2500 samples would take 2.3 mS if I understand this, so we need to cal readsamples at about this rate.... Possible causes could be something *else* locking out the program.

2 10

Re: Build failure of network:osmocom:nightly/libosmocore in xUbuntu_18.04/i586
by Neels Hofmeyr 06 Feb '19

06 Feb '19

hopefully fixed by https://gerrit.osmocom.org/c/libosmocore/+/12841 ~N On Mon, Feb 04, 2019 at 08:00:24PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… > > Package network:osmocom:nightly/libosmocore failed to build in xUbuntu_18.04/i586 > > Check out the package for editing: > osc checkout network:osmocom:nightly libosmocore > > Last lines of build log: > [ 369s] - --> N (configured as T-2147483648 18446744073709551615 s) rc=0; state=N T=-2147483648, 2147483647.000000 s remaining > [ 369s] + --> N (configured as T-2147483648 4294967295 s) rc=0; state=N T=-2147483648, 2147483647.000000 s remaining > [ 369s] - test T=0: > [ 369s] --> O (no timer configured for this state) > [ 369s] - test no timer: > [ 369s] --> X (no timer configured for this state) > [ 369s] - test undefined timer, using default_val arg of osmo_tdef_fsm_inst_state_chg(), here passed as 999: > [ 369s] - --> Y (configured as T666 18446744073709551615 -) rc=0; state=Y T=666, 999.000000 s remaining > [ 369s] + --> Y (configured as T666 4294967295 -) rc=0; state=Y T=666, 999.000000 s remaining > [ 369s] - test disallowed transition: > [ 369s] --> Z (no timer configured for this state) > [ 369s] --> B (configured as T2 100 ms) rc=0; state=B T=2, 1.000000 s remaining > [ 369s] 52. testsuite.at:329: 52. tdef (testsuite.at:329): FAILED (testsuite.at:332) > [ 369s] debian/rules:26: recipe for target 'override_dh_auto_test' failed > [ 369s] make[1]: *** [override_dh_auto_test] Error 1 > [ 369s] make[1]: Leaving directory '/usr/src/packages/BUILD' > [ 369s] debian/rules:15: recipe for target 'build' failed > [ 369s] make: *** [build] Error 2 > [ 369s] dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 > [ 369s] > [ 369s] cloud122 failed "build libosmocore_1.0.1.26.0fd6.dsc" at Mon Feb 4 19:59:58 UTC 2019. > [ 369s] > [ 369s] ### VM INTERACTION START ### > [ 372s] [ 336.663635] sysrq: SysRq : Power Off > [ 372s] [ 336.707211] reboot: Power down > [ 377s] ### VM INTERACTION END ### > [ 377s] > [ 377s] cloud122 failed "build libosmocore_1.0.1.26.0fd6.dsc" at Mon Feb 4 20:00:06 UTC 2019. > [ 377s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/) -- - 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2019