I managed to get some InSite units so now I have the whole range.
I tested all units, and this is the result:
1. InSite: it does not initiate the RSL LAPD even when the unit
reports: "waiting for lapd", the BSC needs to start the RSL bootstrap.
Non the less, multi BTS operation does work (tried it with HDSL
cascade), although I have seen some weird behavior between bootstraps
(just starting the BSC does not trigger the same behavior).
2. MetroSite: this unit does start the RSL bootstrap on its own when
the TRXes reaches "waiting for lapd" state, it does not wait for the
BSC to do it. Multi TRX, RF and BB hopping works as expected.
3. UltraSite: it runs exactly the same SW version as the MetroSite,
yet this unit also does not start the RSL bootstrap on its own even
when the unit reports: "waiting for lapd", the BSC needs to start the
RSL bootstrap. Only single TRX works in this case.
Also the MetroSite does not spits out garbage on the E1, the InSite
and UltraSite does.
In general one issue is that even after the BTS reset is ACKed, the
BSC allows the RSL LAPDs to be bootstrapped while the unit is already
resetting, and that fails obviously.
But more importantly, it seems that the whole LAPD logic is not
working exactly the same across the unit types. I wonder if we should
wait more for the RSL to be triggered by the BTS itself and should not
start the RSL bootstrap after CONF_COMPLETE received. I found no info
about who should initiate the RSL bootstrap: the BTS or the BSC?
Regards,
Csaba
<openbsc-request(a)lists.osmocom.org> ezt írta (időpont: 2023. jún. 30.,
P, 14:00):
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
openbsc-request(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: Nokia Site (Ultra, Metro) (Harald Welte)
2. Re: code review (Harald Welte)
3. Re: Nokia Site (Ultra, Metro) (Harald Welte)
----------------------------------------------------------------------
Message: 1
Date: Fri, 30 Jun 2023 12:08:43 +0200
From: Harald Welte <laforge(a)osmocom.org>
Subject: Re: Nokia Site (Ultra, Metro)
To: Sipos Csaba <dchardware(a)gmail.com>
Cc: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org>
Message-ID: <ZJ6pq/2V9WfA3yDw@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Sipos,
On Fri, Jun 23, 2023 at 11:18:35AM +0200, Sipos Csaba wrote:
I checked RF and BB hopping with my MetroSite
with my patch added, and
they both seem to work, multi-TRX was tested a couple days ago, that
also works with 2 TRXes. Obviously I did not tested every possible
hopping scenarios, but in both cases the node manager reported the
correct hopping states and I also checked with a spectrum analyzer.
This is good news. Is that patch already in gerrit somewhere?
Anyway, at this point in time I don't see any
particular issues that
indicates a BSC problem. One feature missing is the ability to
configure sectors (Nokia calls a sector a "BTS" while the base station
is called "BCF"). My question is, do we have any BTS type that has
sector configuration support so I can take a look how this was done
(if any) ?
I think we never had support for this in OsmoBSC or even before in OpenBSC.
In GSM/3GPP spec language, every sector is a BTS. The fact that many networks
use sectorized cells is nothing that reflects anywhere in the specification or
the terminology. It's an implementation detail.
I think from the OsmoBSC point of view, a typical 3-sector site would still be
three logical BTSs (in the data model / structures). It's "just" the
respective
manufacturer OML code would have to be adjusted to accomodate a situation where
there are managed objects that only exist once per site, while others
exist per BTS/TRX/...
We have the same situation with Ericsson OM2000 support: Right now one
can only have a single BTS per RBS, as our OM2000 code doesn't
distinguish between MOs that exist once per site only (CF, TF, IS, ...)
and MOs that exist for each BTS.
--
- Harald Welte <laforge(a)osmocom.org>
https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 2
Date: Fri, 30 Jun 2023 12:02:11 +0200
From: Harald Welte <laforge(a)osmocom.org>
Subject: Re: code review
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: openbsc(a)lists.osmocom.org
Message-ID: <ZJ6oI2u2l9wAJ2Eo@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Neels,
On Wed, Jun 21, 2023 at 05:37:55AM +0200, Neels Hofmeyr wrote:
Let me compare two larger feature branches:
There are weeks of review on 19 patches in osmo-hnbgw/cnpool,
and <24h from submit to merge on 14 patches in osmo-msc.
I'm not saying this is good, but I think the difference is likely in terms of
complexity of the related patches. Small patches doing simple to understand
things are easy to review and hence likely to be merged more quickly.
The cnpool patch series for osmo-hnbgw spawned
huge discussions and long delays
on account of minor issues: log lines, event names and comments. I said so, yet
it droned on and even spawned offspring.
It would be good to have pointers to specific gerrit patches here. I'm trying to
look at it now, but topic:cnpool has so many patches that it's hard to find which
ones you're referring-to exactly.
https://gerrit.osmocom.org/c/osmo-hnbgw/+/33133 has a discussion about
parsing of routing area identities and using shared code rather than
open-coded implementations in various places. I consider that relevant
and not cosmetic/bikeshedding
https://gerrit.osmocom.org/c/osmo-hnbgw/+/33173 contains a discussion
about naming. Naming *is* important, particularly if it uses terms
which already have well-established meaning, such as (here) what is a
RANAP RESET and what is a "lost link". Code in maintained software
development projects is written not merely to execute, but for other
developers to read and continue to develop/maintain. If terminology is
used in a wrong way, it is likely misunderstood by other developers,
causing problems down the road when investigating bugs or adding new
functionality. I am seeing quite a lot of questionable naming in
general when it comes to SS7/SIGTRAN. Also, event/state names of FSMs
may end up in log or VTY output, where it has the potential to confuse
not just other developers but users.
https://gerrit.osmocom.org/c/osmo-hnbgw/+/33178 contains a "maybe add a
log line" spawning a discussion with relatively verbose messages in it.
That might be one of the cases you are referring to? To be fair it was
a "maybe" comment, so a simple one line response might have been
sufficient.
None of the important features was part of code
review:
larger design choices of the API, efficiency in handling the actual signalling,
correctness of the signalling.
tbh, if there's a series of (it feels like) 30+ patches doing lots of complex
stuff, it's hard to assume anyone is able to grasp those from reading
the diffs. For correctness of signalling the test cases and
associated pcaps are probably a better resource than gerrit patch
review.
And at the same time I was "just now"
asked to review some patches for
osmo-msc, which changes an API that I have recently added and had ideas and
reasons for.
again, please provide specific pointers. Without that you are expecting
every reader of this e-mail to re-read all osmo-msc patches of the last
few weeks just to find out which specific one[s] you are referring to.
It might have been
https://gerrit.osmocom.org/c/osmo-msc/+/33358/1 where
I overlooked a *resolved* comment "Not merging this one yet to give
Neels a chance to review as well since he wrote the codec filter stuff
that this is now modeled after." which I didn't see as the patch and
many following it had two positive reviews and built correctly and hence
I merged the entire series.
My workflow is usually to perform code review, and then if I'm done and
there are series or parts of series with V+1/R+2 merge those entire
series/chunks, particularly if there are no unresolved comments.
I'm [obviously] not going through each and every resolved comment of
every patch in a series. Those are *resolved*.
So while it was me who merged that series, and I'm of course sorry if
that created problems, I acted in good faith (see above).
I think if anyone wants to hold back a merge for whatever reason, make
sure you put a -1 vote in so it becomes impossible to be merged by
accident. Or at the very least make sure there is an unresolved comment
which will produce a warning when attempting to merge.
Before I get a chance to even glance, I see that
all the patches
are already merged! It is now basically too late to bring in my feedback,
because the patches are in, and why spend more time on it. Suck it up, bygones.
It's not all lost: One can always send follow-up patches? Or revert the
original patch and replace it? No release has been made in between, so
no stable API has been set in stone that needs to continue to be
supported.
Also I have (in my own free time) tried to get an
improved logging timestamp
into libosmocore. This is tagging along for years and years now, because every
time over it is being blocked by minor details that are matters of taste. For
years I lose precious moments every time i have to read an 'extended-timestamp'
in osmo logging and identify the boundary of hours, minutes and seconds. This I
consider important. AFAIR the reasons for blocking the patches were,
objectively, all not important.
I always found it mildly fascinating how many options, choices and
formats (I think primarily you) introduce to the libosmocore logging.
Like file name in front or file at the end? I think osmo* is the only
software with which I've worked where the actual *format* of the log has
many user-configurable options. I'm not talking about sub-systems,
levels and targets! Now we even have multiple different formats for
timestamps, and we are growing more of them. In my opinion, most of
this is bloat. It just adds complexity to things happening at the
runtime of the osmo-* code for something that could just as well be
obtained with log post-processing (like converting from a unix epoch
timestamp to whatever human readable format the reader desires). We've
already merged a lot of this over the years.
To me, the problem with all those many options is that it becomes
very difficult to have any software parsing/analyzing osmo* logs, as
every deployment might be chosing a different combination of "this is my
personal favorite of ordering the portions of a log line" or "this is my
personal favorite of formatting a timestamp".
But now introducing *timezones* into the program
(
https://gerrit.osmocom.org/c/libosmocore/+/32043) really goes over the
top for me. Timezones are handled at the operating system level / libc.
Let's still give all the code review we can,
but let's keep in mind the actual
impact the particular code change has. If it goes in the "fringe detail"
bucket, let's mention it, but just let it pass if the author disagrees.
To be honest, I don't really see much of this here. I see a lot of
optional / non-critical stuff like "typo here" or "maybe ..." but I
rarely see "I absolutely demand that you must ...".
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org>
https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 3
Date: Fri, 30 Jun 2023 12:09:27 +0200
From: Harald Welte <laforge(a)osmocom.org>
Subject: Re: Nokia Site (Ultra, Metro)
To: Sipos Csaba <dchardware(a)gmail.com>
Cc: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org>
Message-ID: <ZJ6p15URO27eoMei@nataraja>
Content-Type: text/plain; charset=us-ascii
On Sun, Jun 25, 2023 at 03:08:51PM +0200, Sipos Csaba wrote:
I tested up to four TRX with the Metro and that
works as well. Once
everything is tested and working I will provide example files, and try
to updated the Nokia specific wiki as it is quite outdated (info is
from the NITB era).
Thanks in advance!
Will try to look at Ericsson and BS-11, maybe
there are some clues
about sectors there.
See my other mail, unfortunately it's not something implemented.
--
- Harald Welte <laforge(a)osmocom.org>
https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Subject: Digest Footer
_______________________________________________
OpenBSC mailing list -- openbsc(a)lists.osmocom.org
To unsubscribe send an email to openbsc-leave(a)lists.osmocom.org
------------------------------
End of OpenBSC Digest, Vol 104, Issue 8
***************************************