OpenBSC November 2019

openbsc@lists.osmocom.org

4 participants
13 discussions

Build failures of network:osmocom:nightly/osmo-hlr
by Harald Welte 12 Nov '19

12 Nov '19

Somehow osmo-hlr is no longer building in OBS for a variety of targets -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 3

osmo-msc: repeatpaging?
by Neels Hofmeyr 04 Nov '19

04 Nov '19

I noticed the MSC test that wants osmo-msc to repeat a Paging to the BSC and hNodeB. After fixing the Iu tests, I wanted to get this last ttcn3-msc-test working, so I was about to implement repeated Paging from osmo-msc, but the more I think about it, the less it makes sense to me. The commit log in osmo-ttcn3-hacks says: Repeating will improve the reachability of MS when a Paging is lost or not received because the MS is moving between states. This reasoning seems flawed to me, because the BSC / hNodeB is between the MSC and the MS, and the BSC *does* repeat Paging. That should cover MS moving between states. The link between MSC and {BSC,hNodeB} is considered reliable, and AFAICT nothing really gets better when repeating a Paging request to the BSS. It could make sense to maybe repeat Paging with a larger/more general Cell Identifier List? But why not send the full list in the first place? Also 3GPP TS 48.008 3.1.10 Paging says: A single PAGING message across the MSC to BSS interface contains information on the cells in which the page shall be broadcast. I interpret the "A single" as: there is no repetition of Paging requests toward the BSS, and that's also what makes most sense to me infrastructurally. Is there any spec indicating repeated Paging from the MSC? I would actually remove the test TC_lu_and_mt_sms_paging_repeated. If that's the wrong call, we should specify how osmo-msc should repeat Paging. Before that, having the test makes little sense... What do you guys think? ~N

3 3

contrib: alternative ladder diagram format
by Neels Hofmeyr 01 Nov '19

01 Nov '19

Hi all, I wrote a script and am wondering whether it makes sense to publish it in libosmocore/contrib/. For codec negotiation patches, I was writing ladder diagrams manually in the mscgen format, and it was so annoying to type "[label=]" all the time, that I decided to write a script that parses a leaner ladder diagram format and converts it to mscgen format. I was going to use this format in osmo-msc.git, but actually, after I wrote the first osmo-msc codec ladder diagram, I went a step further and automated the process by transcribing an osmo-msc log output directly to a ladder diagram. That script can output to mscgen format, so in the end there is no dependency on that simpler ladder format from my osmo-msc patches. When writing ladder diagrams manually in the future, I'll probably choose my simpler ladder format. I could always submit the converted format instead of that, i.e. keep the simpler format to myself entirely. I could publish the script privately... Any opinions? Does it make sense to put this in libosmocore/contrib/ before any Osmocom git trees actually depend on it? See branch neels/contrib http://git.osmocom.org/libosmocore/commit/?h=neels/contrib&id=f1ec9483de0f9… ~N

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2019