Hello all, I want a confirmation. I 've seen in openBSC features that openBSC handles handover between cells inside one BSC. So I think it's possible to connect several nanoBTS to openBSC and move from one cell to another without losing the outgoing call. Am I right ? Thank you. Chris
On Thu, Apr 21, 2011 at 11:08:43AM +0200, Christopher HENARD wrote:
I 've seen in openBSC features that openBSC handles handover between cells inside one BSC. So I think it's possible to connect several nanoBTS to openBSC and move from one cell to another without losing the outgoing call. Am I right ?
Yes, you are right. Please note, you need to use the --rtp-proxy option of osmo-nitb, as hand-over support is only enabled if the RTP data passes through OpenBSC, it can no longer be routed directly between the BTS's. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 04/21/2011 11:08 AM, Christopher HENARD wrote:
Hello all, I want a confirmation.
I 've seen in openBSC features that openBSC handles handover between cells inside one BSC. So I think it's possible to connect several nanoBTS to openBSC and move from one cell to another without losing the outgoing call. Am I right ?
Yes, there is one bug in the RTP proxy code though. When we move the call we get a new RTP stream (sequence numbers, SSRC...) and our patching seems to add a lag. At public installations (congress) we have not suffered from this as LCR was handling this for us.
I understand, thank you both of you. 2011/4/21 Holger Hans Peter Freyther <holger@freyther.de>
On 04/21/2011 11:08 AM, Christopher HENARD wrote:
Hello all, I want a confirmation.
I 've seen in openBSC features that openBSC handles handover between cells inside one BSC. So I think it's possible to connect several nanoBTS to openBSC and move from one cell to another without losing the outgoing call. Am I right ?
Yes, there is one bug in the RTP proxy code though. When we move the call we get a new RTP stream (sequence numbers, SSRC...) and our patching seems to add a lag. At public installations (congress) we have not suffered from this as LCR was handling this for us.
participants (3)
-
Christopher HENARD -
Harald Welte -
Holger Hans Peter Freyther