Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Dear Osmocom developers,
the number of branches in many repositories (most notably libosmocore)
is growing to a rather large number, and I would like to encourage everyone
to have a quick look about which branches can be deleted by now (and delete
them, if no longer needed).
Thanks!
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear all,
36c3 is going to happen soon, and as usually we're planing to setup
our own GSM/UMTS network (LTE is to be discussed). While we do have
enough UMTS NodeB units, we're looking for heroes who could sacrifice
their GSM base stations (preferably sysmoBTS or nanoBTS) for the
duration of the congress. Note that we're not considering SDRs (unless
somebody with a strong aspiration wants to ensure proper clock
distribution, filtering, power amplification, etc).
Please let us know 1) how many (and what kind of) units we could
borrow from you, 2) can you bring them to Leipzig before the first
day, or can you drop them somewhere in Berlin (Sysmocom? AfRa?).
Thanks!
On behalf of the GSM team,
Vadim Yanitskiy.
Somehow osmo-hlr is no longer building in OBS for a variety of targets
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
I noticed the MSC test that wants osmo-msc to repeat a Paging to the BSC and
hNodeB.
After fixing the Iu tests, I wanted to get this last ttcn3-msc-test working, so
I was about to implement repeated Paging from osmo-msc, but the more I think
about it, the less it makes sense to me.
The commit log in osmo-ttcn3-hacks says:
Repeating will improve the reachability of MS when a Paging is lost
or not received because the MS is moving between states.
This reasoning seems flawed to me, because the BSC / hNodeB is between the MSC
and the MS, and the BSC *does* repeat Paging. That should cover MS moving
between states.
The link between MSC and {BSC,hNodeB} is considered reliable, and AFAICT
nothing really gets better when repeating a Paging request to the BSS.
It could make sense to maybe repeat Paging with a larger/more general Cell
Identifier List? But why not send the full list in the first place?
Also 3GPP TS 48.008 3.1.10 Paging says:
A single PAGING message across the MSC to BSS interface contains information
on the cells in which the page shall be broadcast.
I interpret the "A single" as: there is no repetition of Paging requests toward
the BSS, and that's also what makes most sense to me infrastructurally.
Is there any spec indicating repeated Paging from the MSC?
I would actually remove the test TC_lu_and_mt_sms_paging_repeated.
If that's the wrong call, we should specify how osmo-msc should repeat Paging.
Before that, having the test makes little sense...
What do you guys think?
~N
Hi all,
I wrote a script and am wondering whether it makes sense to publish it in
libosmocore/contrib/.
For codec negotiation patches, I was writing ladder diagrams manually in the
mscgen format, and it was so annoying to type "[label=]" all the time, that I
decided to write a script that parses a leaner ladder diagram format and
converts it to mscgen format.
I was going to use this format in osmo-msc.git, but actually, after I wrote the
first osmo-msc codec ladder diagram, I went a step further and automated the
process by transcribing an osmo-msc log output directly to a ladder diagram.
That script can output to mscgen format, so in the end there is no dependency
on that simpler ladder format from my osmo-msc patches.
When writing ladder diagrams manually in the future, I'll probably choose my
simpler ladder format. I could always submit the converted format instead of
that, i.e. keep the simpler format to myself entirely.
I could publish the script privately...
Any opinions? Does it make sense to put this in libosmocore/contrib/ before any
Osmocom git trees actually depend on it?
See branch neels/contrib
http://git.osmocom.org/libosmocore/commit/?h=neels/contrib&id=f1ec9483de0f9…
~N
