Note: This page contains developer notes from contributors in the public release. The OpenBTS commercial release already has handover implemented. This will be released in public shortly. Commercial customers should Range Networks for more information.
0. For impatient
If you just need to make it work, and have no time to read all the stuff, please take a look at handover setup page
While the theory can be found below..
1. GSM 04.08 handover
GSM 04.08 describes 4 handover options, while implementing 184.108.40.206.2 Non synchronized cell case is enough.
In few words, the successful air interface procedure looks like:
- HANDOVER COMMAND (downlink) with
-- Handover Reference (see below)
-- channel description
- HANDOVER ACCESS (uplink, new channel) - single-byte packet with Handover Reference, must be decoded like Assess Burst at RACH. The goal is to compute time advance.
- PHYSICAL INFORMATION (downlink, new channel, unacknowledged mode) - providing time advance to a mobile.
- HANDOVER COMPLETE (uplink, new channel)
Three parameters are defined:
- T3103 timer - global timeout for originating site
- T3105 timer - intervals between sending PHYSICAL INFORMATION
- Ny1 - number of attempts to deliver PHYSICAL INFORMATION
Need to mention, GSM 04.08 220.127.116.11: transaction identity must be kept unchanged
2. handover for OpenBTS
- procedure will be packed with SIP
- Handover Reference is allocated at the target site
- when handover succeeds, SIP Register must be performed
- SIP REFER should be avoided, as it might be unsupported by a soft switch
2.2. general implementation ideas
- after handover performed, the "old" site acts like an "anchor MSC" from the legacy GSM
- SIP messages will follow handover path, while RTP will run directly between call legs
- a new type of call, "handover-originated", is introduced, which is handled like MO and MT-ones and differs in call setup only
- a dedicated handover thread is added. It is aimed at keeping timeouts, sending PHYSICAL INFORMATION, doing SIP REGISTER (it's better to do it here, not to pause channel processing threads)
2.3. SIP-based handover procedure
- a special INVITE goes directly from the "old" to the "target" side; it carries handover signature, IMSI, L3TI
- "target" side responds with PROCEEDING, SIP message body contains data mentioned at the first paragraph
- air procedure is performed
- when Handover Complete got, "target" site sends SIP 200 with new sdp values
- 200 is ACK-ed. Old site requests re-INVITE(to the softswitch, keeping original callId) and acts like a proxy
- "target" performs SIP REGISTER
- the following configuration parameters are needed:
2.4. implementing handover procedure at the "target" site, successful case
- handover request is detected inside checkINVITE(), that differs from the legacy Invite message in callID structure. Old transaction identifier (L3TI) is also fetched from the mentioned field. When detected, new transaction and handover entries are created, linked one with another. Handover reference and a traffic channel are allocated, and transceiver is instructed to expect RACH burst with the definite value (ea Handover Reference) at the desired time slot. All necessary parameters are provided to the initiating cell.
- when Handover Access is detected in processBurst() inside GSML1FEC.cpp, transceiver is turned back to the normal operation, and handover thread periodically issues Physical Information message.
- after Handover Complete is received, SIP 200 message is sent, and the logical channel continues the normal call handling. Handover thread is instructed to perform SIP Register.
- as soon as SIP Register is done, handover entry is removed, and a call is treated as a legacy OpenBTS call
2.5. handover at the "old" site, successful case
- as soon as handover attempts runs asynchronously to calls, a mHOAllowed flag is added to transaction data structure to allow a single handover attempt per call in a given time; if flag is down, handover is prohibited for a given call. Flag is restored if an attempt fails.
- when handover decision is taken, a new (temporary) transaction is created; new transaction references the ogiginal one, but is completely independent. SIP Invite message with a specific callID is sent to the target cell (SIP session belongs to a new transaction). Activities are carried within a single handover thread.
- as soon as SIP Invite is replied, Handover Command is sent to a mobile
- when 200 OK is received, original transaction issues re-invite to the stable side and releases radio resources. It lives within a handover thread, exchanging SIP messages with handover transaction. From now on, it is responsible for handling or re-transmitting a limited number of SIP messages. So, 2 transactions are kept inside a BTS, both are served by a handover thread, and both are processing SIP events only.
2.6. changes at the "stable" leg of a call (if mobile-mobile call is being handovered)
Activities at the "fixed" leg depend on switch configuration:
- if switch is involved into media path (such as Asterisk with "canreinvite=no"), it must support re-Invite; there are no new requirements to OpenBTS software; so, OpenBTS is not involved. This is a typical use case.
- if media goes directly between endpoints, the "stable" leg must support re-Invite procedure, ea it must be able to send rtp to another endpoint when requested
2.7. Removing loops
- as an extension to the procedure mentioned in 2.4, when handover invite is received, all existing transactions are checked against an IMSI. If another transaction exists, a Mobile Originated, Mobile Terminated or Handover Originated one, it is stored at mExistingTransaction
- the procedure runs exactly as described above.
- if succeeds, a radio resource thread linked with a transaction from mExistingTransaction, re-invite is issued from the mentioned transaction
- an old BTS receives no rtp packets and breaks a call, removing a loop.
3. handover scenarios
The primary goal was to implement handover support, while avoiding any influence at the overall system architecture. As soon as the goal is achieved, there are 3 options available. Two of them are implemented already.
3.1. CLI command to start handover
just type ho <IMSI>. The rest will be hopefully done by itself.
3.2. handover controlled by BTS
if GSM.Handover.BTS.Enable is non-zero, MS-provided measurement results are processed, and handover procedure is triggered. If a target cell is capable of accepting a call, handover will hopefully occur.
- new data fields are added into transaction data structure, that are used to average measurement results. The weights are configured by means of GSM.Handover.BTS.Weights
- GSM.Handover.BTS.Hysteresis value defines a difference between a serving sell and a candidate
- if there are several neighbour cells defined, when a handover attempt is undertaken, integrated measurement results for a chosen cell are cleared to allow the second candidate to succeed in the case of handover failure.
3.3. handover triggered from network management center
if there is a network element that collects measurement results (ea supplied by means of SIP), it can ussue a command. As the result, gBTS.handover().performHandover() function will be called, that starts a procedure. All you need is to do some coding by yourself..
- do not forget to apply handover.sql patches, create a file like Neighbors.txt and download files from git
- frequency accuracy is important http://wush.net/trac/rangepublic/wiki/Clocks. Moving from USRP1 + N200 to umTRX + umTRX made the behaviour predictable
- Asterisk 1.8 processed re-INVITE improperly: re-INVITE was acknowledged, but Asterisk continued sending rtp to the initial address. This could be caused by the lack of my knowledge in configuring it, meanwhile a whole week was spent in vain.
- Handover with Freeswitch is fine. It is important to set rtp-rewrite-timestamps parameter to true when rtp goes through Freeswitch
- a given Sagem OT 190 perfectly processes MO calls and always fails with MT ones. Jet suspects SI6 (GSM 04.08 9.1.40) is to blame
- handover is not working with Nokia handsets
- flipping handover loops is being tested
- .. challenging ROAMING:
My handover activities are almost finished. I'm also maintaining a Sigtran Gateway project.
It makes sense to apply this knowledge to implement a legacy GSM roaming support as described here http://wush.net/trac/rangepublic/attachment/wiki/GSM/OpenBTS%20roaming%20architecture.pdf
I would appreciate an opportunity to have GSM MAP connectivity (plus proper SS7 SCCP GT routing, let us say to MCC/MNC 001/01) for testing roaming.
Please email to dmi3sol<at>gmail<dot>com if you are managing MNO or MVNO and ready to help.
running multiple OpenBTS instances at a single PC
if you need to do so, you have to change mentioned below parameters
You also need to place SQLite configuration file into the current directory and make corresponding changes in OpenBTS software
some historical traces
- first sequential handover with a removed loop http://opengigtran.org/20130121_ho_remove_loop.pcap
- first handover, triggered by BTS itself http://opensigtran.org/20121222-first-automated-handover.pcap
- multiple handovers during a call http://opensigtran.org/20121127_3handovers_in_a_call.pcap.gz
- first proper handover (with voice) can be found here http://opensigtran.org/20121022_handover_voice.pcap.gz.
(102.2 KB) - added by guest
3 years ago.
handover message flow
- proposal-ho.pdf (67.8 KB) - added by guest 3 years ago.
- handover-old1.jpg (11.5 KB) - added by dmisol 3 years ago.
- handover-old2.jpg (11.3 KB) - added by dmisol 3 years ago.
- handover-target.jpg (15.4 KB) - added by dmisol 3 years ago.