Hi
I have an UmTrx -v2.3.2 and I am trying to implement the multi-BTS feature using Osmocom projects and a single umtrx, as outlined here https://umtrx.org/multi-bts-with-osmocom-and-a-single-umtrx/. However, I encountered some issues and couldn't able to get it working. in the spectrum, I only saw two single-tone signals for the two BTS.
I am afraid maybe I am using the wrong branches of projects. I am not sure which branches correspond to the master branch from 2015, as the fairwaves' blog is from that year.
here are my setup details:
ubuntu 20.04
UHD (branch:3.9-LTS)
UHD-Fairwaves(branch: master)
libosmocore (tag:0.9.6)
libosmo-abis (tag:0.4.0)
libosmo-netif (tag:0.0.6)
libosmo-sccp (tag:0.7.0)
openbsc (branch:fairwaves/master)
first osmo-bts (branch: fairwaves/0.3.0-fw-4, with ./configure --enable-trx )
second osmo-bts (branch:achemeris/2sector, with ./configure --prefix=/usr/local/special/2sector --enable-trx )
osmo-trx (branch:achemeris/2sector)
I was wondering if you could provide more specific guidance on which version of the Osmocom projects I should use. Is there any additional documentation or resources that could be helpful in this regard?
Thank you for your assistance, and I look forward to hearing back from you soon.
Best Regards,
Mobin
SIP endpoint (IMSI X @ cell Y) to another SIP endpoint (IMSI X @ cell Z).
(Here "cell" can be understood as "OpenBTS instance".) The call transfer
is managed by the SIP front-end.
Assuming for the purpose of discussion that the "SIP front-end" would be
FreeSwitch, it could be embeded inside the host that runs OpenBTS
(FreeSwitch would only use a tiny part of CPU compared to e.g. the
transceiver), so this would appear like a "black box that does SIP" to
the outside world even though the functionality are split between two
components (FreeSwitch and OpenBTS) internally.
# Handover decision process outside of OpenBTS
The other aspect we agreed on, was that the decision process of when to
do handover should be better left outside of OpenBTS so that it can be
implemented by the carrier rather than a static function inside OpenBTS.
This allows a carrier to implement the call-control functionality either
as a distributed system (e.g. alongside OpenBTS and FreeSwitch inside
the "embedded" device) or a centralized system. This also allows them to
use different sets of data and policies to decide when to switch a
mobile to/from different bands, etc. (Jean-Samuel makes the point that
handover is used nowadays to help with frequency management /
load-balancing, alongside its historical role for geographical handover.)
In turn this makes the requirements for Measurement Report in OpenBTS
very simple: OpenBTS only needs to send SIP "UPDATE" messages when
receiving Measurement Reports messages. There's no need to process the
Measurement Reports inside OpenBTS itself. (I will have to specify the
content of the UPDATE message separately based on GSM 04.08 section
10.5.2.20.)
Combining this with the previous section leads to a model where the
carrier's handover-decision code interfaces on one side with OpenBTS
(via UPDATE messages) and on the other side with the SIP call-control
element (FreeSwitch), either via a specific interface (e.g. ESL in
FreeSwitch) or via regular SIP third-party-call-control. The
call-control elements then transfers the call from one OpenBTS instance
to another OpenBTS instance (for example by iniatiting a REFER towards
the calling SIP element -- but since we split OpenBTS and FreeSwitch, we
don't have to add support for REFER in OpenBTS!).
In any case this gives a potentially highly-distributed handover
mechanism that doesn't have the limitations of inter-MSC handover, the
process is entirely peer-to-peer.
I'm probably forgetting to mention some other topics, just wanted to put
this in writing for discussion as early as possible.
S.
--
Stéphane Alnet. Telecom Artisan. OpenSource Advocate.
Development and integration for FreeSwitch, OpenSIPS, CouchDB, Node.js.
Mobile: +33643482771 - http://shimaore.net/ - https://github.com/shimaore/
about it and demonstrate it operating OpenBTS and OsmoBTS. I could
talk about our open-source development of OpenBTS, if there would be
any interest.
Also I'd love to talk about OsmoBTS/OpenBSC which the new cool. Only
few people heard about OsmoBTS, while it provides great capabilities:
* it works with off-the-shelf SDR transceivers like UmTRX
* it could use VoIP (SIP) soft-switches to connect calls
* it connects to MSCs of legacy GSM networks
* it supports encryption, handover, FR/HR/AMR codecs and GPRS (in beta)
* standards compliant L1/L2 layers, so there are no issues with
various phone models
I love Osmocom approach to development as well - development is open
to all contributors, the code is well structured and tested, even
build results for all sub-projects are available through a continuous
integration suite:
http://jenkins.osmocom.org/jenkins/
On Sat, May 4, 2013 at 9:00 AM, Robin Coxe <coxe(a)close-haul.com> wrote:
> (Apologies for cross-posting. We wanted to reach everyone who might be
> interested in attending. Please respond responsibly.)
>
> Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and Robi=
n
> Coxe (Close-Haul Communications & Analog Devices) invite those interested=
in
> open GSM hardware and software development to an informal gathering in
> Cambridge, MA on Friday 10 May 2013 from 6-8 pm. Alexander will be visit=
ing
> the Boston area from Moscow.
>
> If you are interested in participating in any capacity in the Boston-area
> open source GSM development community, we look forward to meeting you. O=
ur
> goal is to identify like-minded people involved in or interested in learn=
ing
> more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and OpenBSC.
> If you have a portable, self-contained demo, feel free to bring it with y=
ou.
>
> When: Friday 10 May 2013, 6-8 pm EDT
> Where: Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge, MA
> 02142 USA
> Photo ID required for building entry.
>
> Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/
>
>
>
>
>
>
>
>
--=20
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=
=B8=D0=BE
http://fairwaves.ru
control scripts have been moved from UHD repository to a separate
repository:
https://github.com/fairwaves/umtrx_scripts
On Fri, Jan 25, 2013 at 1:07 AM, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
> Hi all,
>
> Just to let everyone know - in addition to working on manufacturing
> issues we're improving our UmTRX firmware and software support right
> now. And today we've got dual-channel finally working. Thanks to
> Andrew Karpenkov for his awesome work on implementing the second
> channel support in FPGA!
>
> I plan to push the pre-built FPGA image to the download area in the
> during the weekend and Andrew will publish the FPGA code changes soon
> too.
>
> What's ahead of us is to teach OpenBTS to use the second channel of
> UmTRX. This includes support of two independent channels and then
> implementation of switched diversity receive.
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=
=B8=D0=BE
> http://fairwaves.ru
--=20
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=
=B8=D0=BE
http://fairwaves.ru
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
Like every year in early December, it is time to discuss as schedule for
OsmoDevCon in the upcoming year.
Note: Ths is about OsmoDevCon, the more private meeting of developers,
*NOT* about OsmoCon, the public conference.
== When, Who, Where ==
I propose the following date for OsmoDevCon 2018:
April 20 - April 23rd, 2018
* Who: Active developers/contributors of Osmocom projects (as usual)
* Where: IN-Berlin, Berlin (as usual)
Please let me know ASAP if that proposed date works for everyone who'd
want to attend. We can still change it now, but I would want to nail
down the date pretty soon.
== Format ==
After the experiment of reducing from 4 to 3 days last year (due to
OsmoCon), we will again go for *four days* in 2018.
However, we should clearly divide the days in a way that e.g. "GSM/3G"
topics are on two days, while SDR+Other topics are on the other days, so
people not interested in some topics can skip one or two days, as
needed.
We could even divide it further like:
* 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...)
* 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.)
* 2 days misc
Regards, and looking forward to meeting you [again] in 2018,
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)
Hi,
I have a umtrx v2.1 which is not booting anymore. When I power it, only led F and H turn ON and stay in this state forever. Is there anything that can be done ?
best regards,
Hello, list.
My hardware is Umtrx v2.1 and I have already built GSM components:
Osmo-trx (branch fairwaves/master)
libosmocore (branch: master)
libosmo-abis (branch: master)
libosmo-sccp (branch: master)
libosmo-netif (branch: master)
openBSC (branch: fairwaves/master, I use OsmoNITB)
osmoBTS (branch: fairwaves/master. Also did ./configure --enable-trx at the installation process)
So now SMS and calls work fine.
Then I want to get GPRS up. I use master branch of openggsn and master branch of osmo-pcu (osmo-sgsn is supplied with osmoNITN). But when I start osmo-pcu, it says: "PCU interface version number of BTS (5) is different (7). Please re-compile!". After that osmo-pcu aborts. Could you please tell me what branches to use for correct work of GPRS?
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences. Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.
This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.
On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users. And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.
Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.
So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties. I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.
One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.
Another idea would be to split into a 'user day' and 'developer days'
format. This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software. The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.
Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.
One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?
What is the general opinion about this?
Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?
In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany. But I'm of course very happy if somebody wants to
host it some place else...
Regards, and looking forward to meeting you [again] in 2017,
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)
Hi
By default the IP address of the UmTRX board is 192.168.10.2. The
problem is that I can't have two boards on the same network, so I would
like to change the IP address of my boards to make them unique on the
network. How can I do that?
Thanks,
-Osman
