From bogus@does.not.exist.com  Sun Jan  9 16:50:45 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:50:45 -0000
Subject: No subject
Message-ID: <mailman.0.1641747064.43044.umtrx@lists.osmocom.org>

protocol added in HS-2), so I'll be getting the HS-2.


Any news on when delivery will start for umtrx v2?
S.



From bogus@does.not.exist.com  Sun Jan  9 16:50:45 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:50:45 -0000
Subject: No subject
Message-ID: <mailman.1.1641747064.43044.umtrx@lists.osmocom.org>

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 at 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



From bogus@does.not.exist.com  Sun Jan  9 16:50:45 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:50:45 -0000
Subject: No subject
Message-ID: <mailman.2.1641747065.43044.umtrx@lists.osmocom.org>

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 at 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



From bogus@does.not.exist.com  Sun Jan  9 16:50:45 2022
From: bogus@does.not.exist.com ()
Date: Sun, 09 Jan 2022 16:50:45 -0000
Subject: No subject
Message-ID: <mailman.3.1641747065.43044.umtrx@lists.osmocom.org>

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/