Hi all
I have got trough the pcs 1900 nano bts if you have any doubts pls let me ... and these days I am trying to resolves OML issues with RBS 2308 ericson bts
Thank you very much
Regards
Rajitha peiris
Sent from my iPhone
On Feb 24, 2017, at 9:42 PM, "openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>" <openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>> wrote:
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org<mailto:openbsc-owner@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: Ki and OPC values change when programming MCC and MNC
(Holger Freyther)
2. Re: Virtual layer 1 - Questions (Harald Welte)
3. OsmoHLR and IPA unit id (Neels Hofmeyr)
4. Re: Handover and load balancing on SysmoBTS 2050 (Keith)
5. Re: OsmoHLR and IPA unit id (Harald Welte)
6. Re: Handover and load balancing on SysmoBTS 2050 (Keith)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Feb 2017 15:25:56 +0700
From: Holger Freyther <holger(a)freyther.de<mailto:holger@freyther.de>>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>>
Cc: "openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>" <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>>
Subject: Re: Ki and OPC values change when programming MCC and MNC
Message-ID: <31579AC7-F837-49F1-9EDC-C0B8D2CCC85C(a)freyther.de<mailto:31579AC7-F837-49F1-9EDC-C0B8D2CCC85C@freyther.de>>
Content-Type: text/plain; charset=us-ascii
On 23 Feb 2017, at 09:53, Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>> wrote:
On Wed, Feb 22, 2017 at 05:06:20PM +0100, Sylvain Munaut wrote:
--help will tell you defaults for Ki and OPC is to randomize ...
Ah, indeed, I never saw that. Could also be misunderstood. IMHO it should say
right at the top that you normally want to pass -k and -o when calling pysim.
After all, none of the other options do that. anyway...
"normally".. for the batch mode as used at XC3 events the "normal" is to
generate a random KI, you wouldn't want to do that by hand 4k times. :)
holger
------------------------------
Message: 2
Date: Thu, 23 Feb 2017 15:41:24 +0100
From: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>>
To: Sebastian Stumpf <sebastian.stumpf87(a)googlemail.com<mailto:sebastian.stumpf87@googlemail.com>>
Cc: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>, baseband-devel(a)lists.osmocom.org<mailto:baseband-devel@lists.osmocom.org>
Subject: Re: Virtual layer 1 - Questions
Message-ID: <20170223144124.mdba7w7avdujy23g@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Sebastian,
On Sun, Feb 19, 2017 at 06:16:01PM +0100, Sebastian Stumpf wrote:
I also see that the RACH requesets all are sent with a bogus frame
number: 42. This will not work. The RACH request needs to be sent with
the current frame number at the time being.
I fixed that and calculate the proper rach fn like in
https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer…
good.
Also, RACH retransmissions are happening way too quick.
Calculating a proper frame number didn't fix the fast retransmissions.
They are caused by sending the channel request over the virtual um
immediately after getting the rach-request from layer23. Thus also the
rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its
already transmitted" and will generate the next rach-request for my
layer 1.
i see. the confirmation should probably be delayed somehow. As a quick
intermediate hack you might simply add a timer.
I think one can do without on the MS side, but then the BTS must
basically queue the incoming frames until the respective frame number
indicated in the frame matches the current frame number.
I think to fix the problem with the quick retransmission , I need some type
of scheduling. Because if I queue the incoming uplink-msgs in the
bts-virtual-layer1 instead, I don't know when they are processed on the ms
side and thus don't know when to send the rach-confirm to layer23...
My idea for a simple scheduler would be:
-- no timing and timer interrupts on ms side, but just set the current fn in
the ms state each time we receive a message on downlink to the fn of
the received message, which is accessible in the gsmtap header.
yes, that makes sense.
-- queue the outgoing uplink messages with their confirm callback to l2
and process all that with a smaller fn than the current fn in the
scheduling function.
yes, but please keep in mind that the frame number is wrapping every so
often, so "smaller" must consider that modulo-arithmetic, or you will
(after fn wrap) have pending downlink messages for much higher fn which
are not sent as the wrapped fn is now very small.
-- calling the scheduling function each time we receive a msg on downlink
(so I do not need to handle timer interrupts)
yes. I think it is reasonable to not have any actual timers on the ms
side and always depend on the frame numbers in the downlink messages
from the BTS. After all, in the worst case you have periodic messages
like the BCCH messages that can be used to update the fn.
I hope that will be sufficent and try it out tomorrow. I am a bit
afraid of trouble caused by the frame number skipping values with the
upper incrementation logic.
I don't think skips are that problematic. But then, I haven't tried it ;)
--
- Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 3
Date: Fri, 24 Feb 2017 06:43:26 +0100
From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>>
To: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>
Subject: OsmoHLR and IPA unit id
Message-ID: <20170224054326.GB1368(a)my.box<mailto:20170224054326.GB1368@my.box>>
Content-Type: text/plain; charset="us-ascii"
I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR.
It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM
means) to route GSUP replies back to its sender.
It looks like "NAME-00-00-00-00-00-00".
However, all of our GSUP client code simply sets the unit id to:
"SGSN-00-00-00-00-00-00".
The result is that the VLR never receives an UPDATE LOCATION RESULT, because it
is sent to the SGSN instead, since that was the first one to say that it is
"SGSN-00...".
I would extend the GSUP clients to allow setting an ID from VTY, or maybe a
random ID. At this point it would suffice to make the MSC side say it is
"MSC-00-00-00-00-00-00" but that's beside the point.
Do we really want to do that? Any peer could come along and say it is someone
else, very easy to misconfigure (and not very security sensitive when thinking
of OAP -- which we're not using but maybe we will one day).
For some messages, OsmoHLR uses the conn pointer from msg rx to route the
response back -- that works. AFAICT it just receives messages and replies to
them right away (but haven't seen / understood all of it). For the case of the
UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer,
but the code chooses to resolve by id and then sends to the wrong peer. If it
used the peer's IP address and port instead, things would work out.
With the attached and possibly very stupid patch, OsmoHLR works for me with
both MSC and SGSN talking to it even though they have identical IPA IDs: I
bluntly store the conn in struct lu_operation and re-use it later.
Which way shall we resolve this?
~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-RFC-add-the-osmo_gsup_conn-directly-to-the-lu_operat.patch
Type: text/x-diff
Size: 2550 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170224/121d8d06/at…>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170224/121d8d06/at…>
------------------------------
Message: 4
Date: Fri, 24 Feb 2017 16:42:35 +0100
From: Keith <keith(a)rhizomatica.org<mailto:keith@rhizomatica.org>>
To: Alexander Chemeris <alexander.chemeris(a)gmail.com<mailto:alexander.chemeris@gmail.com>>
Cc: OpenBSC Mailing List <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>>
Subject: Re: Handover and load balancing on SysmoBTS 2050
Message-ID: <39e245c4-ba1a-600b-8e38-cb300c10133f(a)rhizomatica.org<mailto:39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org>>
Content-Type: text/plain; charset=utf-8
Hi Alexander, seeing as how you came in on the thread, as a side topic,
you may have noticed I mentioned meas_json and meas_web in the OP. I
fixed up a small thing with meas_json that was producing unparseable
json in the neighbours array. I also did some stuff server side to
filter for either SDCCH or TCH, although I think I would make this a
clientside javascript filter option, rather than running multiple websocketd
I added the neighbour levels to the displayed data. I hardcoded the
ARFCNs for the site in question, but I would make that happen dynamically.
I found this quite useful for monitoring in relation to analysis on this
site and the would-be handover scenario.
I'm wondering what to do with this work.
Should I make a commit of meas_json to master? In that case I would
appreciate some minor help getting the Makefile right.
Maybe meas_json is not a candidate for the master branch, as it doesn't
currently do anything particularly useful without the external
dependencies, ie meas_web and websocketd or alternative.
I can publish my work on meas_web to github.
Keith.
------------------------------
Message: 5
Date: Fri, 24 Feb 2017 16:53:03 +0100
From: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>>
Cc: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>
Subject: Re: OsmoHLR and IPA unit id
Message-ID: <20170224155303.tuidxovd4qbzp5go@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Neels,
IPA CCM made sense on the Abis interface, where each BTS reports with
its unit_id and MAC address. I'm not quite sure how much sense that
makes in the core network. I also don't know if existing
implementations of e.g. A interface over IPA multiplex actually use it.
In terms of future outlook, the MSC/VLR/SGSN should register at the HLR
with some kind of identity. In MAP, it is the SCCP Address that is used
for this purpose. In absence of SCCP on GSUP, I used the CCM identity
as a replacement. However, it is used as an opaque string, so that any
GSUP/MAP gateway might simply translate the SCCP address into a string
of its choosing, and then talk to OsmoHLR. OsmoHLR would then simply
do a strcmp() on the string to match the identity.
Sooner or later, OsmoHLR will have to store this identity in the
database, e.g. for imlpementing message-waiting-lists of SMSCs in case
of MT-SMS from real SMSCs.
All-in-all, I think the string approach is not too bad in terms of
keeping GSUP simple while having a clan approach to interworkng with
MAP.
On Fri, Feb 24, 2017 at 06:43:26AM +0100, Neels Hofmeyr wrote:
I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR.
It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM
means) to route GSUP replies back to its sender.
It looks like "NAME-00-00-00-00-00-00".
However, all of our GSUP client code simply sets the unit id to:
"SGSN-00-00-00-00-00-00".
The result is that the VLR never receives an UPDATE LOCATION RESULT, because it
is sent to the SGSN instead, since that was the first one to say that it is
"SGSN-00...".
this is of course not good.
I would extend the GSUP clients to allow setting an ID from VTY, or maybe a
random ID. At this point it would suffice to make the MSC side say it is
"MSC-00-00-00-00-00-00" but that's beside the point.
A random ID would not be permissible, as it has to be persistent accross
MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms
working.
I would say, why not simply use the same approach as in OsmoBTS, i.e. use
the MAC address (together with the MSC or SGSN prefix). The MAC address
is unlikely to change frequently or on short notice. For people who
know what they're doing, we can have a VTY command to override the
identity with a manually-specified string. If that option is not set,
the default "(SGSN|MSC)-MAC" is used.
Do we really want to do that? Any peer could come along and say it is someone
else, very easy to misconfigure (and not very security sensitive when thinking
of OAP -- which we're not using but maybe we will one day).
I don't think we are aiming for anyone to use those protocols on
public[ly accessible] networks. There's no message authentication or
other cryptographic protection anyway. OAP seems like a funny but
futile minor obstacle, but nothing that can provide any reasonable level
of security.
For some messages, OsmoHLR uses the conn pointer from msg rx to route the
response back -- that works.
This should be done in all request-response style procedures, I think.
AFAICT it just receives messages and replies to them right away (but
haven't seen / understood all of it). For the case of the UPDATE
LOCATION RESULT, it would also be possible to use the same conn
pointer, but the code chooses to resolve by id and then sends to the
wrong peer. If it used the peer's IP address and port instead, things
would work out.
Looking up by ID would also work in case meanwhile the old connection
has died and a new connection has been established
With the attached and possibly very stupid patch, OsmoHLR works for me with
both MSC and SGSN talking to it even though they have identical IPA IDs: I
bluntly store the conn in struct lu_operation and re-use it later.
For synchronous responses (i.e. no asynchronous activity in between)
this will work. So I think it's an optimization for those cases, and we
shouldn't rely on this to always work for all transactions at all time
in the future. Rather, we should make sure it works even without that
optimization?
--
- Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 6
Date: Fri, 24 Feb 2017 17:12:02 +0100
From: Keith <keith(a)rhizomatica.org<mailto:keith@rhizomatica.org>>
To: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>>
Cc: OpenBSC Mailing List <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>>
Subject: Re: Handover and load balancing on SysmoBTS 2050
Message-ID: <ca4d6dc2-fa43-8eaa-8c39-821939d87e52(a)rhizomatica.org<mailto:ca4d6dc2-fa43-8eaa-8c39-821939d87e52@rhizomatica.org>>
Content-Type: text/plain; charset=windows-1252
On 21/02/2017 16:14, Harald Welte wrote:
Just a quick response: jolly implemented "traffic handover" aka "load
balancing" 3 years ago as part of a branch (I believe for a customer),
but unfortunately this never was merged back to master.
Reading the commit log, this looks terrific...
Meanwhile, we already have all the code for execution of hand-overs in
place. We also have dynamic timeslots in place. So the "mechanics"
should all be there to add the two missing features from those old
branches:
a) de-fragmenting of channels (i.e. merging two separate TCH/H into one
timeslot, so the other timeslot can be switched to TCH/F or PDCH on
demand
b) load/traffic based hand-over
So essentially everything I was talking about is already implemented!
My question then would be, and I understand maybe the answer is not so
easily available without a full code review, but
Was it unfortunately never merged back to master because
Simply no one ever made the effort to do so.
OR
There were problems with the code, disagreement on the implementation or
incompatibilities with other developments etc..
If it's the former, I'll have a go at this.
If it is the latter, it's probably beyond my skills.
The general strategy I would normally assume is to
* switch to half-rate channels with AMR whenever possible
* use dynamic channel switching to switch between TCH/H (default) and
TCH/F (if neded)
Absolutely, I must revisit this one.
It was shelved for us due to my understanding a few months ago that if
we implemented AMR, then we couldn't also use FR.
As that's all now resolved, I can implement, test and report. :-)
------------------------------
Subject: Digest Footer
_______________________________________________
OpenBSC mailing list
OpenBSC(a)lists.osmocom.org<mailto:OpenBSC@lists.osmocom.org>
https://lists.osmocom.org/mailman/listinfo/openbsc
------------------------------
End of OpenBSC Digest, Vol 28, Issue 20
***************************************
Hi Holger,
On Feb 22, 2017 1:02 AM, "Holger Freyther" <holger(a)freyther.de> wrote:
> On 21 Feb 2017, at 21:40, Keith <keith(a)rhizomatica.org> wrote:
Hi Keith,
> On the question about SIP re-invite, I am talking about operating
> without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP
> streams at the same time as handover. From what I've read, this is quite
> feasable, as part of the SIP spec.
> I think this is already considered as part of the development of the
> osmo-sip-connector, which is a project I really want to see moving
> forward and hope to find time to contribute to over the next few months.
yes for the osmo-sip-connector I have ignored the topic of handover. In
general I try to see how long I get away with not having to touch the
UDP/RTP streams.
You don't really need to touch RTP stream if you do re-invite.
In case of hand-over the new BTS might send from a different src IP,
src Port and will most likely have a new SSRC, timestamp seqno. It is
a bit of a question of how "your" PBX will handle it. I can see a
couple of outcomes.
a.) It has some support for "NAT" handling and will just use the new
stream and return packages to the new src IP/src port. It might go back
and forth but at some point the old bts will stop sending things.
b.) It will accept the new stream but will try to send to the old BTS.
The we would have one-way audio.
c.) It will reject it as it is a unknown src ip/port.
I think for b.) and c.) we will require SIP re-invite but also need
to look at the AoIP spec to see if they say how to handle this
scenario. But that depends on how the PBX handles this as well. So it
means for handover we always need to look at BSC/SIP+PBX and how it is
handling SDP/RTP.
If I remember correctly,
(b) is what's going to happen if a client is following vanilla SIP spec,
because changing RTP IP/port requires updating SDP which is done with a
re-invite.
(a) is a hack supported by many SIP clients, but it may depend not only on
PBX, but also on its configuration parameters, on SBCs used on a network,
etc
So if you want to be nice to the other party and follow the spec, it's
better to do re-invite :)
Btw, re-invite will need to be implemented anyway if you want to support
call hold.
Please excuse typos. Written with a touchscreen keyboard.
--
Regards,
Alexander Chemeris
CTO/Founder Fairwaves, Inc.
https://fairwaves.co
Now I've actually added some monitoring on all opened and closed sockets in the
python tests, and it turns out the recent patch had no effect because the
tearDown() is overloaded in TestVTYBase.
With every running test, another socket is opened and they aren't closed until
presumably the test py program exits. "40 sockets open", "41 sockets open",
"42 sockets open", ...
Found two places where we need to close sockets, and now the number of open
sockets stays between 0 and 1. Patches are
https://gerrit.osmocom.org/1903https://gerrit.osmocom.org/1905
Will update the docker for openbsc tests when it's merged, and hopefully we can
remove the extra monitoring of tcp sockets soon.
~N
Hi Sylvain + list,
we have developed a sysmoUSIM-SJS1 specific python tool for sim card
(re)configuration called sysmo-usim-tool. It is complementary of
pySim-prog, in that it is *not* about IMSI/ICCID/MSISDN programming, but
more about the features specific to sysmoUSIM-SJS1, such as
enabling/disabling the USIM application (and getting a classic SIM),
selecting the A3/A8 algorithm (XOR, COMP128vX, MILENAGE), etc.
Philipp has committed his code to pmaier/sim branch of pysim-prog.
The question is now whether you want this in the same repository or a
separate one. The two code-bases share nothing in tems of their
implementation. They are completely separate. So it would just be
convenience feature for the user not to have to check out two
repositories. I'm not quite sure whether to create a new repo or to
have it in pySim-prog. Do you (Sylvain, but also generally people on
the list) have any preference?
The license currently states unintentionally AGPLv3, we'll change that
to GPLv2-or-later before a possible merge.
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)
In case you haven't noticed ... now that the osmo-pcu issue is finally
resolved, we've got a successful sanitizer build on Jenkins! :D
https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/
Still no --enable-sanitize configure switches though, except in libosmocore.
To reiterate, I'll gladly do the jenkins config if someone else takes on the
--enable-sanitize in our builds, e.g. like in https://gerrit.osmocom.org/974 .
~N
Hi all,
I would like to direct your attention towards upcoming fairly fundamental
changes that we would like to make in openbsc.git. The operation of
osmo-nitb will need some adjustments that might stump some users at first.
Hence, I would like to ask your feedback on this. While these changes open
the road forward in exciting ways, to some degree they constitute a code
bomb and a point-of-no-return. Let's discuss, to be prepared for it.
(1) Near future:
We are separating the HLR from OsmoNITB, aka libvlr + OsmoHLR. This gets
us asynchronous HLR database access, 3G authentication and one central HLR
for both OsmoNITB and OsmoSGSN (at some point also several OsmoNITBs).
OsmoNITB will no longer manage its own SQlite subscriber database. OsmoHLR
is a separate process that manages subscriber data, which the OsmoNITB as
well as the OsmoSGSN will contact using the GSUP protocol. On the OsmoNITB
side, libvlr implements a VLR with a brand new finite state machine
implementation of handling attach, authentication and ciphering on a
subscriber connection. libvlr stores subscriber data solely in RAM.
(Note that at first, OsmoNITB will still have an SQlite database file,
which will be used for storage of SMS data, only.)
The main changes in operating OsmoNITB will be:
- A separate osmo-hlr process with its own hlr.db database needs to be
run.
- The osmo-nitb VTY (telnet localhost 4242) and CTRL interface will no
longer allow changing subscriber data; good old commands like
'subscriber create imsi 1234', 'subscriber imsi 1234 authorized 1' and
so on will no longer be available. All subscriber management must be
done on the OsmoHLR side. Since OsmoHLR so far has no VTY or CTRL API
to manage subscribers, that needs to be done via sqlite3 on the hlr.db
file (or re-implemented for OsmoHLR).
Since this will constitute a profound change in operating an Osmocom CN,
it makes sense to think about ways to transition. We're planning to make
the VLR+HLR branch the new 'master' branch of openbsc, while keeping the
current master on a legacy branch (named something like v1, which implies
that the new flavor is Osmocom v2). We do not indend to spend much effort
on maintaining the old flavor, though. Ongoing development and new
features will happen in the new libvlr+OsmoHLR flavor, only.
To take a peek, see the openbsc.git branch 'neels/vlr' and OsmoHLR at
http://git.osmocom.org/osmo-hlr/ .
(2) Further plans:
For Iu and A interfaces (a standalone 3G+2G MSC implementation), we have
also worked towards a complete separation of libmsc from libbsc. As a
result, we will probably completely replace OsmoNITB with the new
OsmoCSCN, meaning "Circuit Switched Core Network", which will be mainly
MSC+VLR, talking to OsmoHLR for subscriber data, and to OsmoBSC and/or
OsmoHNBGW to manage GERAN (2G) and/or UTRAN (3G) radio services.
The main changes in operating an Osmocom CN will be:
- Instead of running OsmoNITB, run separate OsmoBSC, OsmoCSCN and OsmoHLR
instances.
- VTY configuration of the BTS parameters needs to be done on the OsmoBSC
level.
- Logging on the MSC level will no longer have intimate access to BSC and
BTS details. It is thinkable to still offer an OsmoNITB that integrates
BSC and MSC+VLR, but the focus is elsewhere.
- There will be Iuh (3G) support; IuCS in OsmoCSCN (sysmocom/iu branch),
IuPS in OsmoSGSN (already merged to master, 3G Authentication pending).
- It will be possible to operate a real A interface towards other
standalone BSCs.
This will at first stay on the sysmocom/iu branch, and cannot be merged to
the master branch before we have a fully operational A interface.
To take a peek, see
http://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_wi…
Your feedback and opinions on these plans are welcome!
~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
Summary:
[1] some problems found in the current logging filter implementation.
[2]..[7] a long discussion on where we could take Osmocom logging.
[2] logging "lifter" instead of a filter
[3] setting logging levels for flagged objects
[4] multiple log targets and multiple flagged objects
[5] FSM instance logging
[6] setting the log context
[7] VTY logging commands
[1]
In the VLR development, I'm going to split the gsm_subscriber to a
bsc_subscriber and a vlr_subscriber. Hence I need to care about the logging
filter code, that e.g. drops all logging except that for a given subscriber.
At first I wanted to drop it altogether, but in fact filtering on a given
subscriber is an important feature. See https://gerrit.osmocom.org/1685
Looking further into adapting this to two types of subscriber struct being used
in the code, I found that in fact the logging filter code looks quite neglected
and degraded.
- One functional problem is that the constants for BSC_CTX_SUBSCR and
GPRS_CTX_BVC actually have the same value: they both resolve to 1, and both
thus access the same logging context pointer with conflicting types.
openbsc debug.c's filter_fn appears to use both BSC_CTX_SUBSCR and
GPRS_CTX_BVC, but GPRS_* are only set in libosmocore/src/gb/ code. Could be
justified by osmo-nitb and osmo-sgsn not overlapping much, but I doubt that
it's on purpose.
- A log target's filter_data[] possibly holds a subscr_get() reference. If a
log target is closed, like a VTY closing, the reference count may leak,
because there is no filter data tear down that could subscr_put() it back.
- log_set_nsvc_filter() and log_set_bvc_filter() are declared in
openbsc/debug.h, but the only implementations I can find are *static* in
libosmocore/src/gb/gprs_bssgp_vty.c and gprs_ns_vty.c, respectively.
- The openbsc/debug.h enum defining LOG_FILTER_* is never used, because it is
bascially duplicated in debug.c, where the values are called FLT_* instead.
- The BSC_CTX_BTS and BSC_CTX_LCHAN are each set once by a call to
log_set_context(), but no filter function ever reads them back out from the
context array. So they are utterly unused.
Hence in libbsc/libmsc, the *only* logging filter practically used is the IMSI
filter.
The filter code screams for attention and more safety. I would collect the
various constants in a central place in libosmocore to avoid collisions (like
ports.h does), and would use the same constant for both...
the filter ctx array index: ctx[FLT_CONSTANT]
and the bitmask: filter_map & (1 << FLT_CONSTANT)
with a static assert to ensure that the filter category constants don't outgrow
the filter_data[], ctx[], filter_map sizes. I'd drop unused definitions, add a
tear down cb.
[2]
While talking about logging, I'm thinking back to 33c3 where we had a large
active network and might want to highlight a few subscribers in the logging...
Any comments on below bold plans to overhaul the logging semantics are welcome.
Despite the long discussion, implementation of this should not be a lot of work
really.
Nevertheless, there are pressing topics in need of attention, and this mail
doesn't mean that it will be implemented now. It's a unicorn's dream of where I
would take Osmocom logging, and it _might_ be a good time to do it now...
If you will, join me on an extensive journey through our logging:
So far the logging checking goes like this:
1. If a msg's logging category is disabled, drop the msg.
2. If a msg's logging level surpasses the currently set log level of that
category, drop it. otherwise:
3. If filter_all is set (= "don't filter"), log the message; otherwise:
4. If no filter function is set, log the message (in libbsc/libmsc operation, a
filter function is always set).
If a filter function is set:
5. Ask the filter function whether to log:
5.1 If no IMSI filter is set, drop the message. (!)
5.2 If an IMSI filter is set and the ctx has a different subscriber, drop
the message.
5.3 If an IMSI filter is set and it *is* the subscriber, log the message.
The result is that in essence, we don't ever see any logging unless we say
'logging filter all 1'. And then, if filter_all is set, the IMSI filter has no
further effect. To see logging for a specific IMSI, we set 'logging filter all
0' and set the IMSI filter to the subscriber. In that situation, all logging
will cease except for those matching the selected IMSI (assuming that the
filter context is always set correctly). Any logging for this IMSI that would
be more detailed than the given category's global logging level is still
dropped, and parts of the code where the subscriber ctx is not set yet also
shows no logging. One could call it a prohibitive logging paradigm. I had a
hard time understanding the UI for it: makes sense only when reading the code.
My logging vision would be the other way around, more of a logging "lifter". In
a general logging landscape, I would like to flag certain subscribers (plural)
to stand out from this landscape with a more detailed logging level. For
example, I set all categories to level ERROR, but on top allow all MM, RSL and
RR logging on INFO level; but for subscribers 1234 and 5678 I also want to see
all DEBUG level logs across all (or specifically selected) categories.
It would look like this:
1. If there is a logging_lifter function:
1.1 If any items are flagged for more detailed logging, ask the lifter:
1.2 If the logging context is set to a subscriber, and this subscriber is
flagged for more detailed logging, log the message; see also [3].
2. If a msg's logging level is within the currently set general log level of
that category, log the message.
3. Otherwise, drop the message.
This way the general logging landscape remains freely configurable while
certain objects' logging can be made more verbose.
[3]
A problem with 1.2 is that we would always see all categories' logging in all
detail for that subscriber. We could a) set a full category mask per subscriber
for complete logging freedom; Instead I'd go for: b) define one global "raised
logging" category mask to lift flagged subscribers to, and for each subscriber
simply have a boolean flag set to true to make them log on the raised logging
levels -- but what about several logging targets? see [4].
[4]
So far so good, but there is still this clumsiness in my plan: there can be any
number of logging targets. Even if I'd like to highlight subscriber 1234 on my
VTY, I don't necessarily want stderr and other VTYs to raise logging for 1234
as well. So if we flagged raised logging in a subscriber struct, we'd basically
make it affect all logging targets in the same way.
In the current code, I can open N VTY telnets and on each of them show only
logging for a selected IMSI, because all logging flags are saved for each
logging target. But I *can't* lift more than one subscriber instance to raised
logging on *the same* log output, because for each target there is only one
IMSI; and I *can't* combine detailed logging of a given IMSI with a general
background of normal logging on the same log output, because I have to filter
all logging away before I can allow a specific IMSI ('logging filter all 0').
The easiest way to allow multiple subscribers with raised logging on the same
log target is to store the "raise-logging" flag with the subscriber instance,
but to keep the log targets separate, I would instead have in struct log_target
an llist of void* for each filter_data where we can point to N instances we'd
like to flag for raised logging. Then, if the current ctx[] matches any of
those, use the raised logging levels. (Expecting the list to remain short)
This can be filter_fn implementation specific: the filter_data can be used to
point at the first llist_head instead of just one subscriber.
[5]
There's another interesting logging topic: FSM instances. We have the
osmo_fsm_inst feature where we can set all logging emitted by an FSM instance
to a certain logging level. One "problem" with this is that the entire FSM logs
on the same level, and we can only raise or lower all of these messages as one.
The implementation is: remember a logging category and a logging level with the
FSM instance, and log all messages from the FSM on this category and level. The
state transitions and events logged from fsm.c are logged on this logging
level.
Because I wanted to specifically mark some logging as LOGL_ERROR, I've already
broken up that idea by adding the LOGPFSML() macro. It allows passing an
explicit logging level instead of using the FSM instance's. I like to think of
it like this: the FSM instance's logging level tells the fsm.c code on which
level to log state transitions and events (like Debug). The logging I write in my
FSM implementation that I want to stand out from the state transitions (read:
logging that's more than Debug) should be given more specific logging levels,
like any other code we write. We could actually make LOGPFSML() use
MAX(fsm_inst.log_level, log_level_arg) so that changing an FSM instance's log
level raises all log messaging.
One could now think, if I want raised logging for a given subscriber, I could
set its FSM instances' logging level so that it prints more logging. But, again
this implies the clumsiness like in [4]: the raised logging would be global
across all logging targets. In this case, there's no easy way to make the
feature log target specific, and neither do we need to...
FSM instance specific logging levels, while sounding very nice at first, are a
non-feature when taking multiple logging targets into account. The simpler way
to show FSM logging for a specific subscriber is to use above suggested
features: flag the subscriber for raised logging on a speicific log target and
set the raised logging level for DVLR to Debug, relying on the logging ctx to
be set correctly when the subscriber's FSMs are active [6]. No need to adjust
an FSM instance's logging level individually. So, the log level could also be
stored in the osmo_fsm definition instead of each separate osmo_fsm_inst.
[6]
Setting the log context needs to generally happen in these situations:
- message received (e.g. from the MS or HLR)
- timer callback called (e.g. state timeout, SMS queue)
Particularly for timeouts on FSM instances' states this is a bit tricky. If the
fsm.c code triggers the timeout, there isn't a general hook to set the log
context to the FSM's subscriber first. The FSM instances that have timeouts set
need to also set a specific timer_cb to update the log context and repeat the
timeout logging "Timeout of T123" that comes from fsm.c before timer_cb() is
called. (That means the timeout logging may be issued twice in some situations,
once by fsm.c and once by the FSM implementation's timer_cb after setting the
log context to make sure raised logging includes it.)
Maybe we can add a pre_timer_cb to osmo_fsm, or teach osmo_fsm to set a
specific log context whenever it logs things? Probably not that important.
[7]
In the VTY, my plan would look like this:
logging = e:RSL,RR,n:MM,CC ! replace all levels
logging + n:PAG ! set some more
logging raised = d:MM,i:CC ! applies to flagged logging contexts
logging raised + d:PAG,NM
logging raise subscriber (imsi|msisdn|...) 1234
...
logging raise subscriber (imsi|msisdn|...) 1234 not
For setting the logging levels, I would like to introduce letters f, e, n, i, d
for the log levels (Fatal, Error, Notice, Info, Debug) instead of the level
numbers that are "hidden" in logging.h, plus o for Off to disable categories.
I would prefer the format:
[l:]CAT[,[l:]CAT[,...]]
so that a level is followed by N categories to be on this level, possibly
followed by another level and another categories list. (i.e. from the current
format, swap meaning of ',' and ':', reverse the current <cat>[,<level>] order
to [<level>:]<cat> and carry the level over to following categories.)
I would also add the 'all' keyword in the logging category parsing:
logging = n:all,i:MM,CC,PAG
which would put all levels on Notice, except MM, CC and PAG on Info.
To avoid confusion with the old 'logging categories' format, I would like to go
for '=' and '+' commands (yes, the VTY can handle these). The old 'logging
categories' might even co-exist.
'logging = ...' and 'logging + ...' should imply 'logging enable'.
The 'logging raised *' sets the logging levels used for flagged subscribers;
they should default to d:all, i.e. everything on debug level.
'logging raise *' flags a given subscriber (or what else we want to add later).
To remove a raise flag from a subscriber, 'logging no raise *' makes sense, but
it is often useful to just recall a previous VTY command and append a keyword,
so I'd make it 'logging raise subscriber imsi 1234 not' for convenience.
The current 'logging level <CAT> <LVL>' can remain as-is; I would add a
'logging raised level' command.
I would completely drop the 'logging filter' commands. But it would still be
useful on a VTY to mute logging to get a usable prompt without the need to
discard the log target:
logging (mute|off)
logging (unmute|on)
These are shorter and more intuitive than 'logging filter all (0|1)'.
The current 'logging filter all everything' command is ambiguous. It sounds
like it would aggressively turn on every last logging message. But instead it
does the opposite: it can only add a general *restriction* on the logging level
for all categories of a log target. Any category that is not enabled will still
not log anything. Also, even if a log target has a more detailed level set, the
log target's global logging level potentially prevents the detailed logging. So
the command should sound more like 'logging restrict all to LEVEL'. It needs a
rename, but IMHO we could also just drop it.
Turning on every last log message could be done by 'logging = d:all'.
Restrictions can be imposed by 'logging + e:RSL,MM,...'. Going back to a
previous complex logging setup can be achieved by recalling the previous
'logging = ' commandline. The VTY could print such a paste-back-able line
showing the current logging levels, so that going back is just a copy-paste on
the VTY.
So much for the unicorn's dream. For now, I'll start off with tidying up the
things under [1] above.
~N
Hi,
Please find BTS test report, week5 2017.
BTSes which has been tested with OsmoNITB are:
- sysmoBTS1002
- octasic BTS3500
- ettus B200
- nanoBTS model:165G
sysmoBTS1002 has been tested with the following 4 channel configurations:
6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots)
3 TCH/F, 3 PDCH
3 TCH/H, 3 PDCH
6 TCH/F_PDCH (ip.access style dynamic timeslots)
All test cases passed.
----------------------------------------------------
octasic BTS3500 has been tested with the next 2 channel configurations:
3 TCH/F, 3 PDCH
3 TCH/H, 3 PDCH
All test cases passed.
-----------------------------------------------------
ettus B200 has been tested with below channel configurations:
6 TCH/F_TCH/H_PDCH (Osmocom style dynamic timeslots)
3 TCH/F, 3 PDCH
3 TCH/H, 3 PDCH
6 TCH/F_PDCH (ip.access style dynamic timeslots)
All test cases passed.
------------------------------------------------------
During a weekly test of nanoBTS model:165G, an issue has been
discovered. It is reported in redmine: https://osmocom.org/issues/1933
Short description: It was found that the initiated voice call drops
immediately after B subscriber accepts the call, when nanoBTS (model
165G) and NITB is configured with dynamic channels: 3 TCH/H and 3 PDCH.
Default voice codec tch-h hr has been selected.
Remaining test cases passed.
regards,
Ivaylo
--
------------------------------
- Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@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
------------------------------
Hello,
I want to connect osmo-sip-connector with and freepbx server installed
into another machine.
is it possible ?
anybody have a file configuration exemple ?
Thanks
Hi
________________________________
On Wed, Feb 15, 2017 at 09:39:15AM +0000, Snehasish Kar wrote:
> A query, can it be now used with an usrp.
> Please kindly always post questions to the mailing list and not to individual developers. Thanks.
Sorry for that.
> It can be for many years ?!? That's what OsmoTRX, OsmoBTS (with osmo-bts-trx backend) are for.
I meant the version of osmo-nitb supporting 3G be used with a USRP ?
BR
Snehasish
