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 18.104.22.168.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 22.214.171.124: 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
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
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
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.