Note: This page contains developer notes from contributors in the public release. The OpenBTS commercial release already has handover in testing with a release scheduled for April 2012. Commercial customers should  Range Networks for more information.

1. GSM 04.08 handover

GSM 04.08 describes 4 handover options, while implementing 3.4.4.2.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)
-- BCC
-- NCCC
-- C0
-- 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 4.5.1.6: transaction identity must be kept unchanged

2. handover for OpenBTS

2.1. theses

• 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

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

• when handover decision is taken, a new (temporary) transaction is created that is linked with an original call handling transaction. SIP Invite message with a specific callID is sent to the target cell (SIP session belongs to a new transaction)

• 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 is terminated in a specific way: it's callID is mapped to a "temporary" handover transaction. So, temporary handover transaction is pointed by two different callID values. From now on, it is responsible for handling or re-transmitting a limited number of messages, such as Info, Re-Ivnite and Bye, while no OpenBTS resources are associated with the transaction.

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

3. present state of affairs

• re-invite supported is done by Jet https://github.com/icptster. This feature is required for the "stable" leg of handover
• handover thread and related changes in OpenBTS surroundings done by Dmitri https://github.com/dmisol. SIP-independent changes are fixed here  https://github.com/dmisol/openbts-p2.8/tree/handover-thread-only, syslog with handover trace is also attached
• SIP-based "handover call setup" at the target side is implemented and is under testing; handover activities at the "old" site are currently performed inside a CLI thread

4. phenomena observed

• a given Sagem OT 190 perfectly process MO calls and always fails with MT ones. Jet suspects SI6 (GSM 04.08 9.1.40) is to blame
• Handover Command like L3 SAP0 RR Handover Command cellDescription=(ARFCN=866 NCC=0 BCC=1)channelDescription=(typeAndOffset=TCH/F TN=1 TSC=1 ARFCN=866) handoverReference=0x2 powerCommand=0 makes Sagem phone perform handover, while Nokia 6150 ignores it (or behaves in a wrong way?). Carriers' Handover Command traces are welcomed to save efforts (non-synchronized case).
• BTS frequency accuracy seems to be important for handover: for the given USRP1 and N200, handover is ok when jumping from USRP1 to N200, but fails at another direction.