This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/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/