Hi Stephane,
Could you describe the communication between the OpenBTS and the "SIP
entity" in more details? I want to better understand how could we
avoid changes in the OpenBTS by introducing this entry.
On another note, I'm more and more leaning towards using OsmoBTS
instead of OpenBTS. We're looking at the idea of implementing an
OpenBTS-like SIP interface for it to get benefits of both worlds. The
best idea so far is to have a A-interface to SIP converter
application, where SIP part is taken from a high level lib like reSIP.
This is quite similar to your ideas, so I want to better understand
details.
On Mon, May 6, 2013 at 12:10 PM, <stephane(a)shimaore.net> wrote:
Hello team,
I met in Paris with Jean-Samuel last Friday. We talked among other
things about handover in OpenBTS and I wanted to share some of our ideas
with you.
Note: this is my recollection of things, if I misreported something it's
my fault. :}
# Handling SIP intricacies outside of OpenBTS
We both agreed that it is better/simpler to keep the complexity of SIP
protocol out of OpenBTS. There are already very good platforms that can
hide the intricacies of SIP from OpenBTS (FreeSwitch, Asterisk, OpenSIPS
B2BUA, etc.). The alternative (implementing a complete, compliant B2BUA
SIP stack inside OpenBTS) seems difficult (complete rewrite using e.g.
sofia-sip) and doesn't help with time-to-market.
We also both enjoy the "GSM handset looks like a SIP endpoint" analogy
that is the basis of OpenBTS and would like to keep the OpenBTS
GSM-to-SIP interface as transparent as possible.
From that point of view, handover is seen as a call transfer from one
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/
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru