'''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 [http://www.rangenetworks.com/#contact 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 [wiki:Handover-quickstart handover setup] page[[BR]] While the theory can be found below.. = 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.[[BR]] In few words, the successful air interface procedure looks like: * HANDOVER COMMAND (downlink) with -- Handover Reference (see below)[[BR]] -- BCC[[BR]] -- NCCC[[BR]] -- C0[[BR]] -- 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''' * the following configuration parameters are needed: -- GSM.Handover.T3105[[BR]] -- GSM.Handover.T3103[[BR]] -- GSM.Handover.Ny1[[BR]] [[BR]] -- GSM.Handover.BTS.NeighborsFilename[[BR]] -- GSM.Handover.BTS.Enable[[BR]] -- GSM.Handover.BTS.Hysteresis[[BR]] -- GSM.Handover.BTS.Weights[[BR]] -- GSM.Handover.BTS.Interleave[[BR]] [[BR]] SQLite scrip [http://opengigtran.org/handover.sql] and configuration file example [http://opengigtran.org/Neighbors.txt] can be taken from my website [[BR]] [[BR]] == 2.4. implementing handover procedure at the "target" site, successful case == [[Image(handover-target.jpg)]] * 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. [[Image(handover-old1.jpg)]] * 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. [[BR]] = 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 '''. 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.. = important issues = * do not forget to apply '''handover.sql''' patches, create a file like '''Neighbors.txt''' and download files from [https://github.com/dmisol/openbts-p2.8/ git] * frequency accuracy is important[http://wush.net/trac/rangepublic/wiki/Clocks]. Moving from USRP1 + N200 to [http://fairwaves.ru/solution.php 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 = phenomena observed = * 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 = further activities = * flipping handover loops is being tested * .. challenging '''ROAMING''': My handover activities are almost finished. I'm also maintaining a [http://opensigtran.org Sigtran Gateway] project. [[BR]] 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] [[BR]] '''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.''' [[BR]] Please email to '''dmi3sol''''''gmail''''''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[[BR]] -- CLI.Socketpath[[BR]] -- GSM.Radio.UHDargs[[BR]] -- TRX.Port[[BR]] -- SIP.Local.Port[[BR]] -- RTP.Start[[BR]] [[BR]] -- GSM.CellSelection.Neighbors[[BR]] -- GSM.Identity.CI[[BR]] -- GSM.Radio.C0[[BR]] [[BR]] -- Control.Reporting.StatsTable[[BR]] -- Control.Reporting.TransactionTable[[BR]] -- Control.Reporting.PhysStatusTable[[BR]] -- Control.Reporting.TMSITable[[BR]] You also need to place SQLite configuration file into the current directory and make corresponding changes in OpenBTS software [[BR]] = 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]. ----