Re: [Openbts-discuss] Intra-cell handover problem

[Alexander C. <ale...@gm...>]

Jet,

Re-invite is at the other ("stable") side of the call. I.e. if call
was from BTS A to BTS B and it is handed over from BTS B to BTS C,
then  SIP re-INVITE is sent by BTS A and is received by BTS A. In your
description you're talking about BTS's B and C.

On Fri, Jul 6, 2012 at 12:45 PM, Jet <icp...@gm...> wrote:
> Hi Alexander,
>
> I'm not sure, but seems that we don't have a central database, so if a
> handover appear on the new bts with a re-Invite, because the new bts
> don't have the sip dialog and transaction tables data in the old bts,
> so the new bts just can't be sure if it is a re-Invite, then can we
> just process the HO invite in this way so that the HO-terminated is
> like at MT except that HO-terminated don't need to page the target
> IMSI, it just need to wait for a handover access with the target
> handover reference.
>
>
> Thanks,
> Jet
>
> On Fri, Jul 6, 2012 at 3:56 PM, Alexander Chemeris
> <ale...@gm...> wrote:
>> Hi Kurtis,
>>
>> It's not needed if all RTP streams are terminated at PBX. If we want
>> to send RTP streams directly between base stations, OpenBTS must be
>> able to handle re-INVITE's.
>>
>> On Fri, Jul 6, 2012 at 3:41 AM, Kurtis Heimerl <khe...@cs...> wrote:
>>> Hey Dimitri,
>>>
>>> I'm in Papua, and just woke up, so I apologize in advance if this
>>> makes no sense.
>>>
>>> Shouldn't OpenBTS be sending re-invites, not receiving them? I can't
>>> think of a reason for it to receive one for a handover.
>>>
>>> On Thu, Jul 5, 2012 at 12:00 PM, Dmitri Soloviev <dm...@ma...> wrote:
>>>> Thank you, Jet
>>>>
>>>> It would be great to support re-invite:
>>>> - detect if INTIVE belongs to an existing SIP session
>>>> - if so, check SDP (it must exist, codec should be the same etc)
>>>> - ack it
>>>> - start sending RTP to the new endpoint
>>>>
>>>> on my side, I'm going to write
>>>> 1) HO-originated call processing (new channel). Now there are MO and MT call
>>>> classes, a third one should be added (I mean Handover Originated)
>>>> 2) some temporary solution (a thread) to perform HO activities for pushing a
>>>> mobile from the old channel. Later on this logic should be integrated with
>>>> MO, MT and HO call handlers, and when mobile lefts (due to handover), it
>>>> should act as a sort of SIP proxy, unlinked from an old timeslot
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Dmitri
>>>>
>>>>
>>>> Thu, 5 Jul 2012 00:13:25 +0800 от Jet <icp...@gm...>:
>>>>
>>>> Hi Dmitri,
>>>> Thanks for the explain to me of the HO procedure and the effort you
>>>> have done, I have some knowledge of the sip and GSM layer 3
>>>> protocol,maybe I can give a hand to speed up the milestone 2.
>>>>
>>>> Regards,
>>>>
>>>> Jet
>>>>
>>>> On Wed, Jul 4, 2012 at 11:30 PM, Dmitri Soloviev <dm...@ma...> wrote:
>>>>> Hi Jet,
>>>>>
>>>>> Let me mention one of the steps of HO procedure (for non-synchronised
>>>>> cells)
>>>>>
>>>>> ... when a mobile appears on the target channel, it issues a tiny
>>>>> (one-byte)
>>>>> command, so-called Handover Access.
>>>>> The goals are:
>>>>> - to fit into desired timeslot (uplink)
>>>>> - to allow BTS provide corrections
>>>>>
>>>>> This procedure is very much alike call setup (on RACH). The same coding is
>>>>> used (that differs from the traffic one)
>>>>>
>>>>> So, to avoid useless computing, a transceiver should know in advance that
>>>>> HA
>>>>> is expected on the particular channel.
>>>>>
>>>>>
>>>>> my question is that did we need to add the HANDOVER and NOHANDOVER command
>>>>> in the USRP/FPGA code to get this handover done
>>>>>
>>>>> These changes are done to Transceiver52M that I'm using:
>>>>>
>>>>> https://github.com/dmisol/openbts-p2.8/commit/b53f61e5481a6cc7169413179cfc3c79ae97d427?
>>>>> the same should be done with any other hardware
>>>>>
>>>>> and can we just set the HandoverReference value as random between 0-255?
>>>>>
>>>>> yes. it is a "random" value, known both to the mobile being forwarded and
>>>>> the target channel.
>>>>>
>>>>>
>>>>> Presently if procedure succeeds, call will be dropped: threads on the new
>>>>> channel are not developed yet. You can trace the procedure with wireshark
>>>>> or
>>>>> in logs.
>>>>> Hope to be back to the activities this weekend. I have the following
>>>>> milestones in mind:
>>>>>
>>>>> milestone 2.
>>>>>
>>>>> Goals:
>>>>> - SIP-negotiated handover
>>>>> - perform handover w/o breaking a call
>>>>> Assumptions:
>>>>> - handover is triggered from CLI
>>>>> - after handover done, call continues. correct call termination is not
>>>>> implemented (on the SIP side)
>>>>> To do:
>>>>> - modifications in call-processing functions
>>>>> - link handover with SIP, ea
>>>>> -- SIP is used to initiate the procedure at the target channel
>>>>> -- SIP is used for negotiating during handover, both successful and
>>>>> unsuccessful cases
>>>>> - thread to process a call at the target channel
>>>>> - all inner processes acting as threads (such as sending Physical Info)
>>>>>
>>>>>
>>>>> milestone 3.
>>>>>
>>>>> Goals:
>>>>> - correct call processing
>>>>> - chain of handover events
>>>>> To do:
>>>>> - full SIP procedure on the donor channel, that acts as a sort of SIP
>>>>> proxy
>>>>> - target is chosen from measurement results
>>>>> Requirements:
>>>>> - second BTS
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Dmitri
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Openbts-discuss mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Openbts-discuss mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>>
>>
>>
>> --
>> Regards,
>> Alexander Chemeris.
>> CEO, Fairwaves LLC / ООО УмРадио
>> http://fairwaves.ru



-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru