Changes between Version 10 and Version 11 of Handover

Show
Ignore:
Timestamp:
08/20/2012 12:24:46 PM (9 months ago)
Author:
dmisol
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Handover

    v10 v11  
    22 
    33= 1. GSM 04.08 handover = 
    4 GSM 04.08 describes 4 handover options, while implementing "3.4.4.2.2 Non synchronized cell case" is enough.[[BR]] 
     4GSM 04.08 describes 4 handover options, while implementing '''3.4.4.2.2 Non synchronized cell case''' is enough.[[BR]] 
    55In few words, the successful air interface procedure looks like: 
    66 * HANDOVER COMMAND (downlink) with  
    … …  
    3030 * a new type of call, "handover-originated", is introduced, which is handled like MO and MT-ones and differs in call setup only 
    3131 * 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 chennel processing threads) 
    32 == 2.3. implementing handover procedures at the "old" and "new" cells == 
    33  * handover-originated call set-up, activities at the target cell (will be attached in few days) 
    34  * handover activities at the old site (also attached soon) 
    35 == 2.4. present state of affairs == 
    36  * re-invite seems to be supported by '''Jet'''[https://github.com/icptster]. This feature is required at the "stable" leg of handover 
     32== 2.3. implementing handover procedure at the "target" site, successful case == 
     33[[Image(handover-target.jpg)]] 
     34 * 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. 
     35 * 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. 
     36 * 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. 
     37 * as soon as SIP Register is done, handover entry is removed, and a call is treated as a legacy OpenBTS call 
     38== 2.4. handover at the "old" site, successful case == 
     39 * 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) 
     40[[Image(handover-old1.jpg)]] 
     41 * as soon as SIP Invite is replied, Handover Command is sent to a mobile 
     42 * 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. 
     43[[Image(handover-old2.jpg)]] 
     44== 2.5. changes at the "stable" leg of a call (if mobile-mobile call is being handovered) == 
     45 * the "stable" leg must support re-Invite procedure, ea it must be able to send rtp to another endpoint when requested 
     46[[BR]]  
     47= 3. present state of affairs = 
     48 * re-invite seems to be supported by '''Jet'''[https://github.com/icptster]. This feature is required for the "stable" leg of handover 
    3749 * 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 
    3850 * "handover call setup" at the target side is mostly implemented and is under testing 
    39  
    40 = 3. Below there is a historical description, to be removed soon = 
     51[[BR]]  
     52[[BR]] 
     53[[BR]] 
     54[[BR]] 
     55[[BR]] 
     56[[BR]] 
     57[[BR]] 
     58[[BR]]  
     59= Below there is a historical description, to be removed soon = 
    4160[[BR]] 
    4261[[BR]] 
    4362[[BR]]   
     63[[BR]] 
     64[[BR]] 
     65[[BR]] 
     66[[BR]] 
     67[[BR]] '' 
    4468 
    4569 
    … …  
    130154When HANDOVER COMPLETE is received, target BTS sends 200 OK[[BR]] 
    131155 
    132 Detailed description can be found here 
     156Detailed description can be found here''