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
Hi Philipp,
while reading your comments to:
https://gerrit.osmocom.org/c/osmo-bsc/+/19670https://gerrit.osmocom.org/c/osmo-mgw/+/20250
I realized that it would be better to discuss here.
My initial idea was that the absence of attributes (in the command
definition and thus in the VTY reference) implicitly indicates that a
given VTY command in the 'config' node comes into effect immediately.
This way we would only need to add attributes to commands requiring
program restart or reestablishment of some link(s) / connection(s).
However, in some applications *most* of the commands may require full
program restart. Or the opposite: most commands may apply immediately.
Adding same attributes to every command is annoying, so I came up with a
concept of default 'applies when' policy: what if we add a new field to
'struct cmd_node' indicating default attributes of all commands
belonging to it?
struct cmd_node foo_node = {
.node = FOO_NODE,
.prompt = "%s(config-net)# ",
.vtysh = 1,
.usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL), // (!)
};
This way a DEFUN() command definition would inherit foo_node.usrattr,
and a DEFUN_USRATTR() command definition would override it.
dexter wrote:
> I just wonder if there could be a VTY_ATTR_RESTART_FULL predefined in
> libosmore. Almost any of the osmo program will need it. Maybe also an
> VTY_ATTR_RESTART_IMMEDIATE?
ACK. I think they could be even moved to generic attributes:
/*! Attributes (flags) for \ref cmd_element */
enum {
CMD_ATTR_DEPRECATED = (1 << 0),
CMD_ATTR_HIDDEN = (1 << 1),
CMD_ATTR_APPLY_IMMEDIATE = (1 << 2),
CMD_ATTR_APPLY_FULL_RESTART = (1 << 3),
};
dexter wrote:
> Maybe we could have some standard letters defined in libosmocore
> for standard situations:
> F = Full restart required
> I = Applied Immediately
ACK. We can also agree that generic (pre-defined) attributes use upper
case letters, while the application specific ones use lower case?
What do you think about these ideas? If you agree, and nobody has any
objections, I can quickly implement them in libosmocore. Would be also
nice to know what other developers think. Neels, Harald, Pau, Daniel?
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
Possibly interesting to note this OAI announcement.
Unfortunately none of the links are direct, but all of them are ugly tracking
links. Also ads for facetwoogle. So I had to blank out a lot. Also interesting
to note how they don't self-host, but rather spread their code across *both*
hosted-gitlab and github. Also interesting how the From: address is a gmail one
vs. the contact(a)openairinterface.org further below. In a massive herd effort,
folks are fudging up the internet, no news there at least.
~N
----- Forwarded message from OpenAirInterface Software Alliance <osalliance5g(a)gmail.com> -----
Date: Fri, 25 Sep 2020 05:40:17 +0000
From: OpenAirInterface Software Alliance <osalliance5g(a)gmail.com>
To: nhofmeyr(a)sysmocom.de
Subject: OpenAirInterface releases 5G core network code
X-Mailer: MailChimp Mailer - **CIDbb030ed5232925faf6b6**
** OpenAirInterface releases 5G core network code
------------------------------------------------------------
Dear Community,
The OpenAirInterface Software Alliance is pleased to announce the release of the OAI 5G Core Network code. An initial set of features is already available and developments with a solid team are underway to build the rest of the 3GPP 5G SBA core. The project home page is here (<blanked-tracking-link>) and gives a good overview of the development phases and the roadmap.
The AMF (<blanked-tracking-link>) and the SMF (<blanked-tracking-link>) code is available on GITLAB. While working to release the UPF code, we are working with the SPGW-U (<blanked-tracking-link>) on the GITHUB.
A CI bench is already operational and in place. Any new features or developments introduced by community developers will automatically launch the CI pipeline and changes will only merge after having thoroughly been tested against third party testers and the OAI 5G RAN test benches.
We cordially invite the community to contribute to the developments of the OAI 5G core network and reach out to contact(a)openairinterface.org for any questions and contribution proposals.
The OpenAirInterface Software Alliance Team*
[removing a ton of tracking links]
----- End forwarded message -----
Hi all,
we seem to have problems with structure alignment in the new version of
the PCUIF protocol:
PCUIFv9: sizeof(struct gsm_pcu_if) -> 212; 212 % 4 == 0
PCUIFv10: sizeof(struct gsm_pcu_if) -> 1006; 1006 % 4 != 0
I think we would need to add/remove some padding. The question is
whether we should make sure that all structures are aligned, or having
the top level struct gsm_pcu_if aligned would be enough?
Even in PCUIFv9 not all structures are properly aligned:
sizeof(struct gsm_pcu_if_data_cnf_dt) -> 21; 21 % 4 -> 1,
sizeof(struct gsm_pcu_if_rts_req) -> 13; 13 % 4 -> 1,
sizeof(struct gsm_pcu_if_rach_ind) -> 15; 15 % 4 -> 3,
sizeof(struct gsm_pcu_if_pag_req) -> 11; 11 % 4 -> 3,
sizeof(struct gsm_pcu_if_susp_req) -> 11; 11 % 4 -> 3.
I devise by 4 because the widest member is uint32_t in all cases.
Kind 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
Hello!
Can anybody share a working /etc/dahdi/system.conf file? I'm trying to
bring up RBS 2000 with osmo-bsc and I'm not sure that I have correct
configuration.
1. Which signaling should be used? CAS? CCS? RBS?
2. There is the same thing with framing. hdb3?
3. parameter "dslot=1,4" pointed in RBS2000 wiki looks wrong. dahdi_cnf
does not work with it at least now.
Thank you
Ivan
Hi Xaver,
[posting this on the mailing list, as it may be of interest to others]
On Fri, Sep 11, 2020 at 04:55:35PM +0200, Xaver Zu wrote:
> This is a dynamic linking.
this is true, but the nature of the linking does not matter in terms of
what creates the derivative work.
> Is this a problem even if I do not distribute the resulting binary?
The AGPL (contrary to the GPL) conditions start when users remotely interact
with your software (See Section 13 of AGPLv3). This means even operating
a network with remote users already means you need to provide the complete
and corresponding source code to the entire work under AGPLv3, which is
impossible if you have a proprietary dependency.
So if you build the software, and you make sure that nobody but yourself
every uses the resulting GSM network, you are fine. But as soon as any
third party uses it, you would be putting yourself in the impossible position
to providing the source code to a proprietary library.
> I can simply add a warning to the file that the compiled program cannot be distributed.
One might consider this a "further restriction" which by itself is a
violation of AGPLv3:
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. [...] You may not impose
any further restrictions on the exercise of the rights granted or
affirmed under this License.
But even beyond that: How many users do you think willread that warning
in the source code vs. how many will simply run it (and possibly allow
others to register). Even if you added a message to start-up, and to
the user manual, I still would think many people don't look at that.
I don't think we should distribute something that "tricks" people into
committing license violations or putting them in an impossible position,
legally speaking.
> Is it a violation that someone assembles and uses it on their own machine?
It is not a violation as long as they are they only person using the
resulting GSM network (or using its VTY or its TRXC/TRXD interface).
I would compare distributing source code like that to shipping a product
that is almost impossible to use safely, but very easy to use in a
[legally] unsafe way.
> Is it a violation to even have sources and build instructions for it?
Maybe not, but see above, I don't want to make it too easy for people to
shoot themselves into their foot.
> Can we agree to leave it as a starting point until someone will have the
> time to do it using IPC?
I'm very sorry (really), but we will not merge this code to the
mainline osmo-trx code base on osmocom.org.
Kind 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)
Hello GSM network side folks,
I assume that most of you are probably aware of the existence of a
certain hack called CalypsoBTS: it's a rather unbelievable hack that
takes a piece of hw meant to be a GSM MS and turns it into a poor
man's GSM BTS, all inherent asymmetry in the GSM air interface be
damned. As a manufacturer of Calypso-based GSM MS devices I
occasionally get approached by people who seek to acquire a Calypso
device seemingly for the sole purpose of running that CalypsoBTS hack,
and every time I get approached by someone of that sort, I always
shake my head in bewilderment - isn't there a better way to get your
own little toy BTS running than to misuse GSM MS hardware?
The purpose of the present post is to solicit advice from the community
as to what I should tell those poor souls who are seeking to set up
their own toy BTS and are looking to do it via the CalypsoBTS route -
is there some better way that we as a community can steer them toward
instead?
It is my understanding - please correct me if I'm wrong - that the
least expensive way to set up your own GSM BTS for toy purposes (as
opposed to running a real operational GSM network which people will
depend on for real communication) is to use a generic SDR device of
one of several types that are supported by osmo-bts-trx/osmo-trx - but
this is where my knowledge in this area ends, as this particular mode
of GSM toying has never been an area of interest for me. But for
those people who (unlike me) *are* interested in setting up their own
toy BTS in the least expensive way, what SDR hardware should we as the
community recommend for them? What is the cheapest option that will
be good enough - especially if the criteria for "good enough" are
compared to CalypsoBTS? What would be the least expensive option that
is just good enough to be advocated as a better alternative to the
CalypsoBTS hack?
In the case of my current FCDEV3B hardware the price tag seems to be
an effective deterrent against people misusing it as CalypsoBTS:
FCDEV3B is expensive, and someone whose actual need is to run their
own BTS rather than MS can easily buy a suitable SDR device for the
same price or less, it seems. But the issue is beginning to rear its
ugly head again because I have another development board in the works
(not here yet, probably won't have the hw until December), and there
is a possibility (nothing is certain yet) that it might be a bit less
expensive than FCDEV3B.
Is there an SDR-based option (or any other non-CalypsoBTS option) for
running a toy BTS with osmo-bts-trx and the Osmocom CNI stack behind
it that would cost $250 or less in hardware? The $250 number comes
from my anticipated-around-December new FreeCalypso development board
- there is a chance that it might be that cheap (but again, absolutely
nothing is certain at the present moment) - and if there is no SDR or
other option for running your own toy BTS for the same or lower hw
price, then I fear that I am going to be flooded with support requests
from people asking for help with using my new board as CalypsoBTS,
which I absolutely dread. Hence my present attempt to pre-emptively
seek some better solution for those people.
(It would be nice if that stream of support requests from people
seeking to run the CalypsoBTS hack could be redirected to Sysmocom or
some other commercial entity who could make some money helping those
people, but my experience is that these people are not the kind who
would ever pay for commercial support, so no hope there...)
It may also be worth mentioning that the filter replacement hack
(removing or replacing Rx SAW filters that are meant to limit the GSM
MS device's Rx capability to only specific GSM downlink bands) will
not be possible on the new FreeCalypso GSM MS board that will be
coming around December - that design uses an integrated RF FEM (front
end module) instead of discrete antenna switch and SAW filter
components. But I've also heard that plenty of people run the
CalypsoBTS hack without doing any filter rework, just letting the
strong signal from a nearby GSM MS force its way through wrong SAW
filters and not caring about the 40 dB or so of attenuation being
incurred - I cringe at the thought, but that's what people do...
M~
Hi Thomas,
it's been some time, hope you're doing fine!
Today on IRC we were collectively wondering about one detail in the osmo-trx
mcbts implementation that has been there from day one:
Your're creating the Channelizer and Synthesis class for four channels of 800kHz
within the 3.2Mbps wideband-channel. So far so good.
But why does the code ever only use up to three of them?
And why is there a specific re-ordering, see radioInterfaceMulti.cpp in
getLogicalChan() ?
It would be great if you could share your thoughts on that.
To me, it looks like the constraint to 3 channels is arbitrary and we should just
as well be able to use all four?
Thanks,
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)
That library does a lot of work. Configures HW, sends samples to FPGA via
DMA, does calibration, normalization, format conversions ... Highly
optimized for Intel CPU. If everything were to be done in an equivalently
closed version, it would take several years of work for me. I would like to
start with a simple proof-of concept. Implementing only the functions used
in osmo-trx-pciesdr. In the first phase, these can be only dummy functions
writing or reading zeros.
I assume that the GPL violation problem will be solved from the moment I
will be able to build the library and link it with osmo-trx and run it.
The next step is just a matter of effort from anyone in the community.
Xaver