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.
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@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/
Hi Alexander,
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.
The goal is to minimize changes in OpenBTS, really. The transfer of calls from one cell to another (=handover) would be handled by the "SIP entity"; the goal is that OpenBTS only has to be able to establish and tear down a call/channel between the GSM side and the "SIP entity". (This means OpenBTS stays a BTS-like entity, it doesn't become a call-switching system.)
Call flow in that case could look as follows for a handover (MS is associated with BTS1 at start of call, handover to BTS2; in the right column I indicated the equivalent BSSMAP messages):
MS BTS1 BTS2 "SIP-entity" | | | | | | | <- INVITE -- | (Handover Request) | | | -- 180 (TCH,HRef) > | (Hand.Req.Ack.) | | <- INFO? (TCH,Handover Ref) -- | (Handover Command) | <- RR H-Cmd | | --- RR Handover Accept -> | | | | -- 200 --> | (Handover Detected) | - RR Handover Complete -> | | | | -- INFO --> | (Handover Complete) | | <- BYE (handover) -------------- | (Clear Command) | | -- 200 ------------------------> | (Clear Complete)
Basically we establish a new "call" (SIP session) with BTS2, notify BTS1 so that it triggers the Handover Command, BTS2 connects the call, and eventually we disconnect the call on BTS1. After the handover BTS1 is no longer in the call path at all.
The issues I have are related to "what happens in case of failure" and how to encode this in SIP; for example in the above call-flow the first INFO message ("Handover Command") could instead be a BYE message, but I'm not sure what the behavior of the MS is if the handover fails, so it's safer to use an INFO message in that case. Also I'm not sure how things work when the network asks the MS to change cells outside of a call (if I understand properly this is called handoff): is this also accomplished using RR Handover messages? In that case we shouldn't use an INFO or a BYE message, we need to use a NOTIFY (or PUBLISH) message instead.
The PUBLISH addition for Measurement Reports is a related but separate idea, this is to externalize the decision-making for handover. "PUBLISH" SIP messages would be generated when OpenBTS receives a RR Measurement Report:
MS BTS | | | | -- RR Measurement Report -> | | | | -- PUBLISH -> |
This would require a separate software entity that handles these messages, implements the decision algorithm, and triggers handover from an MM and a CM perspectives.
Overall in this approach OpenBTS (or some kind of A-bis-over-IP/SIP translation system as you mentioned) would exchange: - REGISTER messages with a registrar network (which plays the role of HLR/VLR/EIR); - INVITE messages with the "SIP entity"; the "SIP entity" deals with peer-to-peer communication, in-call handover control, ..; - PUBLISH messages with some third entity, which deals with resource management and uses the "SIP entity" to implement handover.
S.
-
Alexander Chemeris -
stephane＠shimaore.net