From vyanitskiy at sysmocom.de  Sat Aug  1 16:28:30 2020
From: vyanitskiy at sysmocom.de (Vadim Yanitskiy)
Date: Sat, 1 Aug 2020 23:28:30 +0700
Subject: osmo-bts-trx + osmo-trx: dummy burst filling
Message-ID: <c4669c16-b332-b965-f0fd-8dbe8e9a761f@sysmocom.de>

Hi all,

as some of you may know, I am currently working on baseband frequency 
hopping implementation for osmo-bts-trx (see OS#4546).  I've already 
submitted more or less final implementation to Gerrit [1], and in 
general it works fine [2].

The idea is quite simple: you have several RF carriers (transceivers) 
with fixed frequencies, so on hopping timeslots osmo-bts-trx distributes 
bursts between them according to the configured hopping sequence. 
However, when it comes to hopping timeslots on C0, the burst 
distribution algorithm gets a bit more complicated.

The problem is that on C0 the BTS has to maintain constant power level, 
even if there is nothing to transmit, so the phones can detect it 
reliably during the power scan.  This is achieved by sending dummy 
bursts.  When frequency hopping is not in use, the scheduler in 
osmo-bts-trx sends a dummy burst immediately.  When it is in use, 
sending dummy bursts needs to be postponed until all transceivers are 
processed, because some other transceiver might need to send a normal 
burst on the frequency of C0, and there would be no need to send a dummy 
burst in that case.  So I came up with [3] (any comments regarding 
potential optimizations and further improvements are welcome).

While working on this, I stumbled upon the burst filling feature in 
osmo-trx [4], that is disabled by default.  If enabled, osmo-trx would 
be sending dummy bursts itself, so there is no need to send them from 
osmo-bts-trx, and thus no need to complicate the burst distribution logic.

I am now wondering why don't we enable this feature by default?

 From the VTY reference:

 > Send a dummy burst when there is nothing to send on C0 (TRX0) and
 > empty burst on other channels.  Use for OpenBTS compatibility only,
 > don?t use with OsmoBTS as it breaks encryption.

it's unclear how sending dummy bursts would break encryption...

[1] https://gerrit.osmocom.org/c/osmo-bts/+/19030
[2] https://www.youtube.com/watch?v=tGMVNYo9s7E
[3] https://gerrit.osmocom.org/c/osmo-bts/+/19029
[4] 
http://ftp.osmocom.org/docs/latest/osmotrx-vty-reference.pdf#subsection.1.9.11

Best regards,
Vadim.

-- 
- Vadim Yanitskiy <vyanitskiy at 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


From laforge at osmocom.org  Sat Aug  1 16:40:53 2020
From: laforge at osmocom.org (Harald Welte)
Date: Sat, 1 Aug 2020 18:40:53 +0200
Subject: osmo-bts-trx + osmo-trx: dummy burst filling
In-Reply-To: <c4669c16-b332-b965-f0fd-8dbe8e9a761f@sysmocom.de>
References: <c4669c16-b332-b965-f0fd-8dbe8e9a761f@sysmocom.de>
Message-ID: <20200801164053.GC1141190@nataraja>

Hi Vadim,

On Sat, Aug 01, 2020 at 11:28:30PM +0700, Vadim Yanitskiy wrote:
> While working on this, I stumbled upon the burst filling feature in osmo-trx
> [4], that is disabled by default.  If enabled, osmo-trx would be sending
> dummy bursts itself, so there is no need to send them from osmo-bts-trx, and
> thus no need to complicate the burst distribution logic.
> 
> I am now wondering why don't we enable this feature by default?

No idea, sorry.

> From the VTY reference:
> 
> > Send a dummy burst when there is nothing to send on C0 (TRX0) and
> > empty burst on other channels.  Use for OpenBTS compatibility only,
> > don?t use with OsmoBTS as it breaks encryption.
> 
> it's unclear how sending dummy bursts would break encryption...

I also cannot follow that argument.

Alexander Chemeris added this VTY text in 2019 in I752eb2c1162d084e8769181f2fcd6c0877663448,
he should know?

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From xaver1zu at gmail.com  Sat Aug  8 13:46:45 2020
From: xaver1zu at gmail.com (Xaver Zu)
Date: Sat, 8 Aug 2020 15:46:45 +0200
Subject: Support for new SDR devices
In-Reply-To: <d02fbfec-4007-14e8-f4fa-d08f00fb4372@sysmocom.de>
References: <CAAtamJbY4mvdVQLPLygpToA=WzXJ7du4nYxC2jqpAe3dcGL9TQ@mail.gmail.com>
 <d02fbfec-4007-14e8-f4fa-d08f00fb4372@sysmocom.de>
Message-ID: <CAAtamJZZAHJUK1oL6RfTUi8oQ-CwznJUpSJ=Af1w+9O+C-xBjw@mail.gmail.com>

Hi,

I updated API and rebased it.

It works more stable with new version of osmo-bts.

What exactly does a "device backend" mean?
Is it content of osmo-trx/Transceiver52M/device/pciesdr/ or lower layers
(libsdr, kernel drivers or HW)?
This crash happen after device stop - start (caused by cmd PWROFF from
osmo-bts).

PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0
<0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested

I haven't found a working solution yet. Starting the demon again helps.

I managed to reach an uptime of more than 3 hours with one MS connected. So
I decide push it into gerrit for review
https://gerrit.osmocom.org/c/osmo-trx/+/19548

Are you considering adding support for floating format samples to the radio
interface?
The proprietary libsdr.so library (driver from manufacturer) expects
samples in float format. I have to convert short to float again during Rx /
Tx.

I received a feedbak from laforge with a request to complete the PCIeSDR
description. Is it possible to create a page on the wiki for this purpose?

Regards
XK1Zu


so 18. 7. 2020 v 18:19 odes?latel Pau Espin Pedrol <pespin at sysmocom.de>
napsal:

> Hi,
>
> without looking into much detail at your branch, I should suggest:
>
> * Rebase your work on top of current osmo-trx master, the base commit
> you use is uite old and the API has changed a bit since then, with some
> fixes and improvements.
>
> * Make sure you run both osmo-trx and osmo-bts-trx with RR scheduler
> (realtime). For instance, osmo-trx VTY cmd "rt-prio 18", and
> osmo-bts-trx cmd line arg "-r 1".
>
> * From what i see in the logs, it looks like you have some issues with
> how you are managing the tmestamps inside your device backend, so
> something is not being done correctly in there most probably, then 0 is
> returned and osmo-trx upper layers decide to stop the process.
>
> Once you have something working acceptably fine (MS can use the network
> more or less reliably, and osmo-trx doesn't stop or crash), I'm happy to
> review your patch in gerrit.
>
> Regards,
> Pau
>
> --
> - Pau Espin Pedrol <pespin at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200808/13a66eda/attachment.htm>

From nhofmeyr at sysmocom.de  Wed Aug 12 01:47:00 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 12 Aug 2020 03:47:00 +0200
Subject: build trigger thunder cloud
Message-ID: <20200812014700.GA5771@my.box>

Today I noticed that osmo-msc-master was being built several times in a row and
I found there are multiple redundant ricocheting downstream builds of the same
original upstream build timer.

All of:
https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18894/
https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18895/
https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18896/

show:
  Started by upstream project master-libosmocore build number 1624

And then there are:

https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18897/
https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18898/

showing:
  Started by upstream project master-libosmo-abis build number 2611

So there are two timers launching master-libosmocore and launching
master-libosmo-abis, and each of these cause multiple downstream build triggers
of osmo-msc. Then there is also the osmo-msc timer, independently launching
more nightly master-osmo-msc builds.

It is not necessary to depend these builds on each other, because none of them
depends on artifacts built in another job, each of them in turn builds the
entire chain of libosmocore up to that build's target project.

Upon a libosmocore *code change*, it makes sense to trigger downstream builds,
but not when caused by a timer or for other jenkins trigger or user reasons.

I vaguely remember discussing this before, but now I realize we could solve
this and have less redundant builds:

Do not configure libosmocore to trigger downstream builds of
master-libosmo-abis (and so on), but instead trigger master-libosmo-abis upon
each libosmocore patch merge. That can be done by adding a "Gerrit trigger" on
the master-libosmo-abis build job config, making a patch-merge to the gerrit
libosmocore.git cause a master-libosmo-abis build. At that point, jenkins
timers no longer cause downstream builds, but merges to master on upstream git
repositories do still cause builds.
(maybe there is also a normal git SCM way that doesn't require
gerrit.osmocom.org?)

For projects like osmo-msc, we would add multiple projects as upstream git
repositories, like libosmocore, libosmo-abis, libosmo-netif, ... , osmo-iuh,
osmo-mgw, ...

Basically all of the projects with more than one dependency get retriggered
redundantly every night, some doing their entire build matrix over several
times for no good reason.

I'm not sure that it's really worth the effort, but I thought I'd mention it
since seeing so many redundant builds on various osmo source trees at night
seems avoidable stupidity.  Should someone spend cycles to implement this?

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200812/b77f73a6/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Aug 13 00:45:32 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 13 Aug 2020 02:45:32 +0200
Subject: ttcn3-bsc-test-latest status
Message-ID: <20200813004532.GA14580@my.box>

I recently broke ttcn3-bsc-test-latest for a couple of builds, which is fixed now.

Still it appears like some 'latest' tests remain damaged, but that is actually
not the case. Here a summary of those that look like failures but are expected:

TC_chan_rel_rr_cause:
the test is new and tests a feature not implemented in 'latest' yet.

TC_chan_rqd_emerg_deny:
the test is new and I'm not sure of its 'latest' status.

TC_si2quater_2_earfcns, TC_si2quater_3_earfcns:
osmo-ttcn3-hacks just now merged a patch that also tests EARFCN presence in a
Channel Release message. Since 'latest' still has a bug that causes only the
first EARFCN to appear in that message, these two tests now fail in 'latest'.

TC_cbsp_emerg_write_bts_cgi_cchan:
This used to fail, then during the massive failures it suddenly passed for a
bit, and now fails again. The passes must have been flukes.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200813/bf863f57/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Aug 13 01:10:48 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 13 Aug 2020 03:10:48 +0200
Subject: osmo-mslookup-client.c
In-Reply-To: <CAK0c-E_uJ5ZtAcdKqgN=DUh=kgqP6PVUSqWcRO5WLzJA1cFdQw@mail.gmail.com>
References: <CAK0c-E_uJ5ZtAcdKqgN=DUh=kgqP6PVUSqWcRO5WLzJA1cFdQw@mail.gmail.com>
Message-ID: <20200813011038.GA15023@hud.box>

Hi Edgard,

thanks for your interest in the Osmocom project.

On Sat, Aug 08, 2020 at 08:56:08PM +0100, Edgard Ndassimba wrote:
> I have difficulte to implemente osmo-mslookup-client.c

I'm sorry, I don't understand the question...

I looked, and I notice that osmo-mslookup-client is missing from the binary packages.
I opened a bug tracker for it: https://osmocom.org/issues/4706

If you want to use osmo-mslookup-client, you need to build osmo-hlr manually.
For that, please look at
https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source

MSLookup and DGSM are explained in http://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
chapter "12 Distributed GSM / Multicast MS Lookup"

If you have more questions about this, please write an email to
openbsc at lists.osmocom.org
or ask on IRC: FreeNode #osmocom

Please write to the mailing list, and not to me personally.
That way you have more people that can help you, and more people can learn from
your progress. Thanks!

~N

> 
> I use ubuntu 16.04 LTS amd64
> 
> Could you help me please?
> 
> Best Regards
> 
> -- 
> Edgard NDASSIMBA


From pespin at sysmocom.de  Mon Aug 17 09:01:38 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 17 Aug 2020 11:01:38 +0200
Subject: Support for new SDR devices
In-Reply-To: <CAAtamJZZAHJUK1oL6RfTUi8oQ-CwznJUpSJ=Af1w+9O+C-xBjw@mail.gmail.com>
References: <CAAtamJbY4mvdVQLPLygpToA=WzXJ7du4nYxC2jqpAe3dcGL9TQ@mail.gmail.com>
 <d02fbfec-4007-14e8-f4fa-d08f00fb4372@sysmocom.de>
 <CAAtamJZZAHJUK1oL6RfTUi8oQ-CwznJUpSJ=Af1w+9O+C-xBjw@mail.gmail.com>
Message-ID: <0f66b036-f789-b630-5fd4-0660dfef57ce@sysmocom.de>

Hi,

On 8/8/20 3:46 PM, Xaver Zu wrote:
> What exactly does a "device backend" mean?
> Is?it content of osmo-trx/Transceiver52M/device/pciesdr/ or lower layers
> (libsdr, kernel drivers or HW)?
> This crash happen after device stop - start (caused by cmd PWROFF from
> osmo-bts).

When I talk about osmo-trx I mean each of osmo-trx-* binaries, which
basically differ on the code being taken from a different directory in
osmo-trx/Transceiver52M/device/ each.

> 
> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0
> <0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested
> 
> I haven't found a working solution yet. Starting the demon again helps.
> 
> I managed to reach an uptime of more than 3 hours with one MS connected.
> So I decide push it into gerrit for review
> https://gerrit.osmocom.org/c/osmo-trx/+/19548

Thanks, I'll have a look at some point when I find some time.

> 
> Are you considering adding support for floating format samples to the
> radio interface?

No one is working or planning to work on that as far as I am concerned.

> The proprietary libsdr.so library (driver from manufacturer) expects
> samples in float format. I have to convert short to float again during
> Rx / Tx.
> 
> I received a feedbak from laforge with a request to complete the PCIeSDR
> description. Is it possible to create a page on the wiki for this purpose?

Sure, ask for permissions to edit the wiki here if you don't have them yet.


-- 
- Pau Espin Pedrol <pespin at 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


From laforge at osmocom.org  Mon Aug 17 10:17:01 2020
From: laforge at osmocom.org (Harald Welte)
Date: Mon, 17 Aug 2020 12:17:01 +0200
Subject: Support for new SDR devices
In-Reply-To: <0f66b036-f789-b630-5fd4-0660dfef57ce@sysmocom.de>
References: <CAAtamJbY4mvdVQLPLygpToA=WzXJ7du4nYxC2jqpAe3dcGL9TQ@mail.gmail.com>
 <d02fbfec-4007-14e8-f4fa-d08f00fb4372@sysmocom.de>
 <CAAtamJZZAHJUK1oL6RfTUi8oQ-CwznJUpSJ=Af1w+9O+C-xBjw@mail.gmail.com>
 <0f66b036-f789-b630-5fd4-0660dfef57ce@sysmocom.de>
Message-ID: <20200817101701.GM2916512@nataraja>

On Mon, Aug 17, 2020 at 11:01:38AM +0200, Pau Espin Pedrol wrote:
> > I received a feedbak from laforge with a request to complete the PCIeSDR
> > description. Is it possible to create a page on the wiki for this purpose?
> 
> Sure, ask for permissions to edit the wiki here if you don't have them yet.

I've granted wiki write privileges now.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ivan.babanov at gmail.com  Wed Aug 19 08:24:30 2020
From: ivan.babanov at gmail.com (Ivan Babanov)
Date: Wed, 19 Aug 2020 11:24:30 +0300
Subject: openBSC with commercial BTS
Message-ID: <CACWjWCjNvboakHCSPbktsTuoSfgxFm6jXU_TbL0knV2KGv+QdA@mail.gmail.com>

Hello,

I see that currently openBSC/osmoBSC works with a number of old commercial
BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis.  My question
is, did somebody try something newer than Nokia UltraSite? I have an
ability to try with FlexiBTS rel.3 with Abis over IP. I'm trying to find
out if maybe it was already tried and had some unresolveable problems?
Please let me know if any.

Thank you
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200819/108d77a3/attachment.htm>

From mia at mob5g.net  Wed Aug 19 08:43:57 2020
From: mia at mob5g.net (Michael Andersen)
Date: Wed, 19 Aug 2020 10:43:57 +0200
Subject: openBSC with commercial BTS
In-Reply-To: <CACWjWCjNvboakHCSPbktsTuoSfgxFm6jXU_TbL0knV2KGv+QdA@mail.gmail.com>
References: <CACWjWCjNvboakHCSPbktsTuoSfgxFm6jXU_TbL0knV2KGv+QdA@mail.gmail.com>
Message-ID: <002101d67604$e0c98be0$a25ca3a0$@mob5g.net>

Hi Ivan,

 

Yes, we developed an adaption layer between Nokia IUA (packet Abis) and Osmo BSC. This was working well enough for basic signaling and 1st call.

 

However, we abandoned that design when we realized that we would have a lot of work, fixes and refactoring to do in the Osmo BSC to support the scalability of the Nokia platform. In the Nokia Flexi 2G architecture, TRXes and most other resources of the BTS are defined and instantiated based on signaling instructions from the BSC.

 

We developed our own 2G mobile core from scratch and we?re quite happy with it. It has already been commercially launched in a live, nationwide network.

 

I can send you a copy of the adaption layer if you?re interested. It may be able to bring your BTS online ? but you will likely find that the path is generally a bit futile.

 

 

Best Regards,

 

Michael Andersen

mob5g.net

 

 

From: OpenBSC <openbsc-bounces at lists.osmocom.org> On Behalf Of Ivan Babanov
Sent: Wednesday, 19 August, 2020 10:25
To: openbsc at lists.osmocom.org
Subject: openBSC with commercial BTS

 

Hello,

 

I see that currently openBSC/osmoBSC works with a number of old commercial BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis.  My question is, did somebody try something newer than Nokia UltraSite? I have an ability to try with FlexiBTS rel.3 with Abis over IP. I'm trying to find out if maybe it was already tried and had some unresolveable problems? Please let me know if any. 

 

Thank you

Ivan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200819/690e5828/attachment.htm>

From ivan.babanov at gmail.com  Wed Aug 19 09:44:51 2020
From: ivan.babanov at gmail.com (Ivan Babanov)
Date: Wed, 19 Aug 2020 12:44:51 +0300
Subject: openBSC with commercial BTS
In-Reply-To: <002101d67604$e0c98be0$a25ca3a0$@mob5g.net>
References: <CACWjWCjNvboakHCSPbktsTuoSfgxFm6jXU_TbL0knV2KGv+QdA@mail.gmail.com>
 <002101d67604$e0c98be0$a25ca3a0$@mob5g.net>
Message-ID: <CACWjWCi6iqeuFqHzWLKj8-7DLFf3AfsWTF+6XTi=uXSs7xSkpQ@mail.gmail.com>

Hello Michael,

Thank you for your reply. I'd really appreciate it if you could send me
your adaptation layer software. I'm a postgraduate student of The
Saint-Petersburg University of Telecommunications and we are building a
laboratory of Radio Systems for practical study of radio access
technologies. So we do not need commercial functionality, stability or
scalability, we need just an ability to show working with real hardware and
ability to make some simple configurations and L3 calls.

Thank you
Ivan

??, 19 ???. 2020 ?. ? 11:43, Michael Andersen <mia at mob5g.net>:

> Hi Ivan,
>
>
>
> Yes, we developed an adaption layer between Nokia IUA (packet Abis) and
> Osmo BSC. This was working well enough for basic signaling and 1st call.
>
>
>
> However, we abandoned that design when we realized that we would have a
> lot of work, fixes and refactoring to do in the Osmo BSC to support the
> scalability of the Nokia platform. In the Nokia Flexi 2G architecture,
> TRXes and most other resources of the BTS are defined and instantiated
> based on signaling instructions from the BSC.
>
>
>
> We developed our own 2G mobile core from scratch and we?re quite happy
> with it. It has already been commercially launched in a live, nationwide
> network.
>
>
>
> I can send you a copy of the adaption layer if you?re interested. It may
> be able to bring your BTS online ? but you will likely find that the path
> is generally a bit futile.
>
>
>
>
>
> Best Regards,
>
>
>
> Michael Andersen
>
> mob5g.net
>
>
>
>
>
> *From:* OpenBSC <openbsc-bounces at lists.osmocom.org> *On Behalf Of *Ivan
> Babanov
> *Sent:* Wednesday, 19 August, 2020 10:25
> *To:* openbsc at lists.osmocom.org
> *Subject:* openBSC with commercial BTS
>
>
>
> Hello,
>
>
>
> I see that currently openBSC/osmoBSC works with a number of old commercial
> BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis.  My question
> is, did somebody try something newer than Nokia UltraSite? I have an
> ability to try with FlexiBTS rel.3 with Abis over IP. I'm trying to find
> out if maybe it was already tried and had some unresolveable problems?
> Please let me know if any.
>
>
>
> Thank you
>
> Ivan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200819/72736914/attachment.htm>

From laforge at osmocom.org  Thu Aug 20 11:45:16 2020
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 20 Aug 2020 13:45:16 +0200
Subject: openBSC with commercial BTS
In-Reply-To: <CACWjWCjNvboakHCSPbktsTuoSfgxFm6jXU_TbL0knV2KGv+QdA@mail.gmail.com>
References: <CACWjWCjNvboakHCSPbktsTuoSfgxFm6jXU_TbL0knV2KGv+QdA@mail.gmail.com>
Message-ID: <20200820114516.GI3544863@nataraja>

Dear Ivan,

On Wed, Aug 19, 2020 at 11:24:30AM +0300, Ivan Babanov wrote:
> I see that currently openBSC/osmoBSC works with a number of old commercial
> BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis.  My question
> is, did somebody try something newer than Nokia UltraSite? 

We have just made current OsmoBSC + OsmoMGW work with the Ericsson
RBS6000, specifically with the DUG10 + DUG20 models.  If you use
'master' of all of Osmocom (or the nightly builds, for that matter) and
the config file examples from https://git.osmocom.org/osmo-bsc/tree/doc/examples/osmo-bsc/ericsson
it should work.  Of course you have to make sure that your MCTR
configuration / number of TRX / transmit power levels / ARFCNs etc.
match the capability of your hardware and the IDB that's installed in
the DUG.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ivan.babanov at gmail.com  Mon Aug 24 09:34:10 2020
From: ivan.babanov at gmail.com (Ivan Babanov)
Date: Mon, 24 Aug 2020 12:34:10 +0300
Subject: openBSC with commercial BTS
In-Reply-To: <20200820114516.GI3544863@nataraja>
References: <CACWjWCjNvboakHCSPbktsTuoSfgxFm6jXU_TbL0knV2KGv+QdA@mail.gmail.com>
 <20200820114516.GI3544863@nataraja>
Message-ID: <CACWjWCgs+pQsMJw6cZ=LrLFHcZav222nzMBC00qVp5tkk_Q7kg@mail.gmail.com>

Hello Harald,

Thank you for information, Is my understanding correct that in your case
RBS6000 connected via E1?

Thank you
Ivan

??, 20 ???. 2020 ?. ? 14:45, Harald Welte <laforge at osmocom.org>:

> Dear Ivan,
>
> On Wed, Aug 19, 2020 at 11:24:30AM +0300, Ivan Babanov wrote:
> > I see that currently openBSC/osmoBSC works with a number of old
> commercial
> > BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis.  My
> question
> > is, did somebody try something newer than Nokia UltraSite?
>
> We have just made current OsmoBSC + OsmoMGW work with the Ericsson
> RBS6000, specifically with the DUG10 + DUG20 models.  If you use
> 'master' of all of Osmocom (or the nightly builds, for that matter) and
> the config file examples from
> https://git.osmocom.org/osmo-bsc/tree/doc/examples/osmo-bsc/ericsson
> it should work.  Of course you have to make sure that your MCTR
> configuration / number of TRX / transmit power levels / ARFCNs etc.
> match the capability of your hardware and the IDB that's installed in
> the DUG.
>
> --
> - Harald Welte <laforge at osmocom.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200824/0e1f854f/attachment.htm>

From laforge at gnumonks.org  Mon Aug 24 10:59:42 2020
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 24 Aug 2020 12:59:42 +0200
Subject: openBSC with commercial BTS
In-Reply-To: <CACWjWCgs+pQsMJw6cZ=LrLFHcZav222nzMBC00qVp5tkk_Q7kg@mail.gmail.com>
References: <CACWjWCjNvboakHCSPbktsTuoSfgxFm6jXU_TbL0knV2KGv+QdA@mail.gmail.com>
 <20200820114516.GI3544863@nataraja>
 <CACWjWCgs+pQsMJw6cZ=LrLFHcZav222nzMBC00qVp5tkk_Q7kg@mail.gmail.com>
Message-ID: <20200824105942.GD3822842@nataraja>

Dear Ivan,

On Mon, Aug 24, 2020 at 12:34:10PM +0300, Ivan Babanov wrote:
> Thank you for information, Is my understanding correct that in your case
> RBS6000 connected via E1?

This is correct. Our primary E1 interface so far has been the Digium
(now Sangoma) cards with the DAHDI Linux driver.  However, Sylvain has
recently created an open source hardware + open source software USB E1
adapter.  This adapter is already fully supported by osmo-bsc /
libosmo-abis via osmo-e1d.  Related hardware should soon become available.

In case you were wondering about IP based back-haul:
Some years ago we also created an implementation of "Packet Abis over IP",
which is wha the Ericsson SIU / TCU are speaking towards the BSC.  The related code
can be found in the osmo-el2tpd repository.  However, it was for a proof of concept
at the time, and only signaling plane + packet data was tested, not any voice services.

It should not be too much effort to take this from the proof-of-concept
state (remove hard-coded IP addresses, ...) and fully integrate that
into OsmoBSC/MGW/PCU.  As usual, sysmocom is very happy to work in that
area.

If I'm not mistaken, the more recent RBS6000 digital units for GSM
(DUS31, DUS41, ...) speak the same L2TP derived "Packet Abis over IP",
but we have no experience with those as of yet.

Regards,
	Harld
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From matt9j at cs.washington.edu  Mon Aug 24 21:24:33 2020
From: matt9j at cs.washington.edu (Matthew Johnson)
Date: Mon, 24 Aug 2020 14:24:33 -0700
Subject: Patches and Packaging for Erlang Components
Message-ID: <CAKUjAJC_CUaOgeHhK=mc+jWi9BySqpd4WM55S82Caqbdxx7jaQ@mail.gmail.com>

Hello!

I was able to use the experimental osmo_dia2gsup converter to successfully
enable circuit switched fallback in a test network, but have a couple fixes
for it and osmo_ss7 needed to work with the latest 2G CN components. I
would open a change request in gerrit, but I see that the rebar.conf of
osmo_dia2gsup already depends on a WIP branch from osmo_ss7. How best
should I provide patches for review? Is there ongoing work in
http://git.osmocom.org/erlang/osmo_ss7/log/?h=laforge/wip that needs to be
merged first, and is there a reason it has not been merged already?
Otherwise should I open a change request towards the WIP branch?

Also, do folks have any opinions on how best to package erlang components?
I was going to generate a Debian package for a stand-alone erlang ?release?
of osmo_dia2gsup, and am happy to contribute the debian metadata and build
files upstream, but I am not an erlang expert and want to make sure it?s
structured in the correct way if there is a convention I should follow.
>From a random sample it looks like none of the other erlang components are
packaged, so I don?t have a good example to go from. If there is no opinion
I will make an attempt, but I wanted to ask first!

Thanks for your help and patience!
-Matt J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200824/02410da9/attachment.htm>

From laforge at osmocom.org  Tue Aug 25 07:04:24 2020
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 25 Aug 2020 09:04:24 +0200
Subject: Patches and Packaging for Erlang Components
In-Reply-To: <CAKUjAJC_CUaOgeHhK=mc+jWi9BySqpd4WM55S82Caqbdxx7jaQ@mail.gmail.com>
References: <CAKUjAJC_CUaOgeHhK=mc+jWi9BySqpd4WM55S82Caqbdxx7jaQ@mail.gmail.com>
Message-ID: <20200825070424.GU3822842@nataraja>

Hi Matt,

On Mon, Aug 24, 2020 at 02:24:33PM -0700, Matthew Johnson wrote:
> I was able to use the experimental osmo_dia2gsup converter to successfully
> enable circuit switched fallback in a test network, 

great! I think that's an achievement considering the lack of documentation and the
state where I had to leave it at the time.  I guess you're the third person to ever
run it ;)

> but have a couple fixes for it and osmo_ss7 needed to work with the latest 2G CN components. 

excellent.

> I would open a change request in gerrit, but I see that the rebar.conf of
> osmo_dia2gsup already depends on a WIP branch from osmo_ss7. 

I didn't even remember that, will look into it.

> How best should I provide patches for review? 

> Is there ongoing work in http://git.osmocom.org/erlang/osmo_ss7/log/?h=laforge/wip that needs to be
> merged first, and is there a reason it has not been merged already?

The reason is overload and juggling too many tasks for about the last decade or so :/

> Otherwise should I open a change request towards the WIP branch?

gerrit works on individual patch granularity, it doesn't know the notion
of a 'change request'.

I will rebase, review and push that branch.  If there's anything we need
to fix up, I'll mark those patches as WIP.  Feel free to take it from
there if there are TODO items.

> Also, do folks have any opinions on how best to package erlang components?

Not really.  I'm not aware what is the best practice these days either.

> I was going to generate a Debian package for a stand-alone erlang ?release?
> of osmo_dia2gsup, 

this sounds great.

> and am happy to contribute the debian metadata and build
> files upstream,

great!

> but I am not an erlang expert and want to make sure it?s
> structured in the correct way if there is a convention I should follow.

I'm not an Erlang expert either, and I guess nobody here is.  I would
just check how other Erlang projects are doing this, preferably projects
that have official debian packages like ejabberd, or maybe you can find
a less complex example.

> From a random sample it looks like none of the other erlang components are
> packaged, so I don?t have a good example to go from. 

That is correct.  They were mostly developed for one specific customer
at the time, and there was no requirement for debian packaging at the
time.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at osmocom.org  Tue Aug 25 07:19:59 2020
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 25 Aug 2020 09:19:59 +0200
Subject: Patches and Packaging for Erlang Components
In-Reply-To: <CAKUjAJC_CUaOgeHhK=mc+jWi9BySqpd4WM55S82Caqbdxx7jaQ@mail.gmail.com>
References: <CAKUjAJC_CUaOgeHhK=mc+jWi9BySqpd4WM55S82Caqbdxx7jaQ@mail.gmail.com>
Message-ID: <20200825071959.GV3822842@nataraja>

Hi Matt,

so from laforge/wip, the only problematic bit I could find is
	https://gerrit.osmocom.org/c/erlang/osmo_ss7/+/19808/1

It would be appreciated if you could take that patch and extend it as described in the
review comment.  Once the application can specifiy that IPA CCM option list, we can
merge the patch and then subsequently modify osmo_diameter2gsup to use the master
branch (and that new function to specify the MME-00.... IPA CCM option).

Whatever other changes you may have, please submit them to gerrit to the respective
repository.  osmo_gsup, osmo_ss7 and osmo_diameter2gsup are luckily all using
gerrit + jenkins verification these days.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nhofmeyr at sysmocom.de  Wed Aug 26 12:23:03 2020
From: nhofmeyr at sysmocom.de (nhofmeyr at sysmocom.de)
Date: Wed, 26 Aug 2020 14:23:03 +0200
Subject: New Defects reported by Coverity Scan for Osmocom
In-Reply-To: <5f447c42e1a36_150c082aeccd756f548145e@prd-scan-dashboard-0.mail>
References: <5f447c42e1a36_150c082aeccd756f548145e@prd-scan-dashboard-0.mail>
Message-ID: <20200826122303.GA20838@my.box>

On Tue, Aug 25, 2020 at 02:49:39AM +0000, scan-admin at coverity.com wrote:
> *** CID 212862:  Error handling issues  (CHECKED_RETURN)
> /source-Osmocom/osmo-pcu/src/pdch.cpp: 211 in gprs_rlcmac_pdch::packet_paging_request()()
> 205     
> 206     	/* loop until message is full */
> 207     	while (pag) {
> 208     		if (log_check_level(DRLCMAC, LOGL_DEBUG)) {
> 209     			struct osmo_mobile_identity omi = {};
> 210     			char str[64];
> >>>     CID 212862:  Error handling issues  (CHECKED_RETURN)
> >>>     Calling "osmo_mobile_identity_decode" without checking return value (as is done elsewhere 20 out of 22 times).
> 211     			osmo_mobile_identity_decode(&omi, pag->identity_lv + 1, pag->identity_lv[0], true);
> 212     			osmo_mobile_identity_to_str_buf(str, sizeof(str), &omi);
> 213     			LOGP(DRLCMAC, LOGL_DEBUG, "Paging MI - %s\n", str);
> 214     		}

I'd like to let you guys know that I intentionally don't check the return value
here. This is only for logging the mobile identity, and if decoding fails, the
logging should just show "NONE".

~N


From laforge at osmocom.org  Wed Aug 26 18:47:12 2020
From: laforge at osmocom.org (Harald Welte)
Date: Wed, 26 Aug 2020 20:47:12 +0200
Subject: New Defects reported by Coverity Scan for Osmocom
In-Reply-To: <20200826122303.GA20838@my.box>
References: <5f447c42e1a36_150c082aeccd756f548145e@prd-scan-dashboard-0.mail>
 <20200826122303.GA20838@my.box>
Message-ID: <20200826184712.GY3739@nataraja>

On Wed, Aug 26, 2020 at 02:23:03PM +0200, nhofmeyr at sysmocom.de wrote:

> I'd like to let you guys know that I intentionally don't check the return value
> here. This is only for logging the mobile identity, and if decoding fails, the
> logging should just show "NONE".

AFAIR, there are ways how you can annotate the code in a way to avoid coverity raising it.

There should be something like //coverity[] but some people claim there is also the option of
casting the return value to (void):
	https://stackoverflow.com/questions/5073164/coverity-prevent-how-to-handle-checked-return-warning-when-i-deliberately-don

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)