8 Jul
2013
8 Jul
'13
9:19 p.m.
Today, after I successfully started two InSite BTS units on the same E1
line, I tried to test the OpenBSC handover function.
I got a strange error message, that I have to enable RTP Proxy
mode with "-P" in osmo-nitb. Because these units are running from E1,
I just simply ask: do we have handover support for E1 based BTSs? Cell
reselection and inter BTS voice calls, SMSs are working just fine.
BR,
Csaba
10 Jul
10 Jul
5:54 p.m.
Hi,
On Mon, Jul 08, 2013 at 09:19:23PM +0200, Sipos Csaba wrote:
I got a strange error message, that I have to enable
RTP Proxy
mode with "-P" in osmo-nitb.
That's of course funny.
Please take some minutes of your time to look at the source code line
that generates yoru error message. I'm sure (without looking) that
the message will be printed if bts->model != SIEMENS_BS11. So you
simply need to extend that to include all E1 based bts's.
Because these units are running from E1, I just simply
ask: do we have
handover support for E1 based BTSs?
yes, this was already working with the BS-11 a long time ago.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
8:44 p.m.
New subject: Re[2]: Nokia InSite handover
Hi Harald,
Hi,
On Mon, Jul 08, 2013 at 09:19:23PM +0200, Sipos Csaba
wrote:
> I got a strange error message, that I have to enable RTP Proxy
> mode with "-P" in osmo-nitb.
That's of course funny.
Please take some minutes of your time to look at the
source code line
that generates yoru error message. I'm sure (without looking) that
the message will be printed if bts->model != SIEMENS_BS11. So you
simply need to extend that to include all E1 based bts's.
The part generates this message is the following:
openbsc/openbsc/src/libbsc/bsc_vty.c
#define HANDOVER_STR "Handover Options\n"
DEFUN(cfg_net_handover, cfg_net_handover_cmd,
"handover (0|1)",
HANDOVER_STR
"Don't perform in-call handover\n"
"Perform in-call handover\n")
{
int enable = atoi(argv[0]);
struct gsm_network *gsmnet = gsmnet_from_vty(vty);
if (enable && ipacc_rtp_direct) {
vty_out(vty, "%% Cannot enable handover unless RTP Proxy mode "
"is enabled by using the -P command line option%s",
VTY_NEWLINE);
return CMD_WARNING;
}
gsmnet->handover.active = enable;
return CMD_SUCCESS;
}
After I removed this check, I was able to start OpenBSC with
handover=1, even the OpenBSC VTY said to "show network" that handover
is On, but I was not able to do any handovers even when there was
30-40dB difference (RXlev) between the target and the source cell. The
target was ate -50, the source was around -100, suddenly the phone
jumped to the target cell, but after 3-4 seconds of terrible noise,
both phones are dropped the call. I think it was a cell reselection
not a failed handover, because there was no HO attempts in the
statistics.
> Because these units are running from E1, I just
simply ask: do we have
> handover support for E1 based BTSs?
yes, this was already working with the BS-11 a long
time ago.
If I can help resolve this issue, just let me know what to try.
BR,
Csaba
10:22 p.m.
On Wed, Jul 10, 2013 at 08:44:49PM +0200, Sipos Csaba wrote:
if (enable && ipacc_rtp_direct) {
this check should be conditional on using a nanobts/sysmobts, and not be
present for E1 based bts's.
After I removed this check, I was able to start
OpenBSC with
handover=1, even the OpenBSC VTY said to "show network" that handover
is On, but I was not able to do any handovers even when there was
30-40dB difference (RXlev) between the target and the source cell. The
target was ate -50, the source was around -100, suddenly the phone
jumped to the target cell, but after 3-4 seconds of terrible noise,
both phones are dropped the call. I think it was a cell reselection
not a failed handover, because there was no HO attempts in the
statistics.
You should enable debugging logging of the handover code and see what
kind of messages you get. 'logging enable' 'lgging filter all 1' and
'logging level ho debug' should do the trick.
Please have a look at handover_logic.c and handover_decision.c in the
src/libbsc subdirectory of openbsc.git. If that doesn't help, you can
also enable measurement debugging, and manually check if the measurement
reports from the phone arrive at the bsc, if they contain measurements
of the neighbor cell, and if the reported signal levels of the neighbor
cell really are better than the original cell where you started the
call, etc.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
22 Jul
22 Jul
11:51 p.m.
New subject: Re[2]: Nokia InSite handover
Hi Harald,
this check should be conditional on using a
nanobts/sysmobts, and not be
present for E1 based bts's.
I just removed that check from the code and now it is possible to
enable the HO functions without the RTP Proxy.
You should enable debugging logging of the handover
code and see what
kind of messages you get. 'logging enable' 'lgging filter all 1' and
'logging level ho debug' should do the trick.
I did as you said, the result is interesting, I just paste the
relevant log parts, the full dump (logging all debug) is attached.
So I wanted to do inter-BTS handover (two Nokia InSite units, one
GSM900 and one GSM1800), neighbors list configured. Two phones calling
each other, each one is camped on different cell. The one that is
camped on the GSM1800 unit tries to handover to the GSM900 unit. Here
is what happens:
<000c> handover_decision.c:203 (bts=0,trx=0,ts=2): Cell on ARFCN 123 is better:
<000c> handover_logic.c:96 (old_lchan on BTS 0, new BTS 1) Starting handover
<0004> abis_rsl.c:1165 (bts=1,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK
<000c> handover_logic.c:204 handover activate ack, send HO Command
<0004> abis_rsl.c:1138 (bts=1,trx=0,ts=2,ss=0) HANDOVER DETECT access delay = 0
<0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 ESTABLISH INDICATION
<0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION
<0003> bsc_api.c:515 HANDOVER COMPLETE cause = Normal event
<000c> handover_logic.c:261 Subscriber 244153333330126 HO from BTS 0->1 on ARFCN
885->123
<0000> chan_alloc.c:405 (bts=0,trx=0,ts=2,ss=0) starting release sequence
<0000> abis_rsl.c:891 (bts=0,trx=0,ts=2,ss=0) RSL RLL RELEASE REQ (link_id=0x00,
reason=1)
<0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
..
..
<0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:988 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: RELEASING
CAUSE=0x01(Radio Link Failure)
<0004> abis_rsl.c:679 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1
<0004> abis_rsl.c:633 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD
<0000> abis_rsl.c:891 (bts=0,trx=0,ts=2,ss=0) RSL RLL RELEASE REQ (link_id=0x40,
reason=1)
<0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:731 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK
<001a> trau_frame.c:196 unimplemented TRAU Frame Type 0x06
<-- a lot of "unimplemented TRAU Frame Type 0x06" -->
<001a> trau_frame.c:275 unimplemented TRAU Frame Type 0x06
<0004> abis_rsl.c:988 (bts=0,trx=0,ts=3,ss=0) CONNECTION FAIL: RELEASING
CAUSE=0x28(unknown 0x28)
<0004> abis_rsl.c:679 (bts=0,trx=0,ts=3,ss=0) RF Channel Release CMD due error 1
<0004> abis_rsl.c:633 (bts=0,trx=0,ts=3,ss=0) DEACTivate SACCH CMD
<0000> abis_rsl.c:891 (bts=0,trx=0,ts=3,ss=0) RSL RLL RELEASE REQ (link_id=0x40,
reason=1)
<0004> abis_rsl.c:731 (bts=0,trx=0,ts=3,ss=0) RF CHANNEL RELEASE ACK
<0001> gsm_04_08.c:1265 (bts 0 trx 0 ts 3 ti 0 sub 12346) Sending
'MNCC_REL_IND' to MNCC.
<0006> mncc_builtin.c:348 (call 1) Received message MNCC_REL_IND
<0006> mncc_builtin.c:257 (call 1) Releasing remote with cause 47
<0006> mncc_builtin.c:52 (call 1) Call removed.
<0006> gsm_04_08.c:2877 receive message MNCC_REL_REQ
<0001> gsm_04_08.c:3063 (bts 0 trx 0 ts 2 ti 08 sub 12345) Received
'MNCC_REL_REQ' from MNCC in state 10 (ACTIVE)
<0001> gsm_04_08.c:1739 starting timer T308 with 10 seconds
<0001> gsm_04_08.c:1204 new state ACTIVE -> RELEASE_REQ
<0001> gsm_04_08.c:113 (bts 1 trx 0 ts 2 ti 80) Sending 'RELEASE' to MS.
<0001> gsm_04_08.c:1204 new state ACTIVE -> NULL
<0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION
<0001> gsm_04_08.c:3156 (bts 0 trx 0 ts 2 ti 8 sub 12345) Received
'RELEASE_COMPL' from MS in state 19 (RELEASE_REQ)
<0001> gsm_04_08.c:1245 stopping pending timer T308
<0001> gsm_04_08.c:1265 (bts 1 trx 0 ts 2 ti 8 sub 12345) Sending
'MNCC_REL_CNF' to MNCC.
<0006> mncc_builtin.c:348 (call 80000001) Received message MNCC_REL_CNF
<0006> mncc_builtin.c:52 (call 80000001) Call removed.
<0001> gsm_04_08.c:1204 new state RELEASE_REQ -> NULL
<0000> chan_alloc.c:405 (bts=1,trx=0,ts=2,ss=0) starting release sequence
<0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 0 Type: 2
<0004> abis_rsl.c:633 (bts=1,trx=0,ts=2,ss=0) DEACTivate SACCH CMD
<0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 RELEASE INDICATION
<0004> abis_rsl.c:679 (bts=1,trx=0,ts=2,ss=0) RF Channel Release CMD due error 0
<0004> abis_rsl.c:731 (bts=1,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:648 (bts=0,trx=0,ts=2,ss=0) is back in operation.
<0004> abis_rsl.c:648 (bts=0,trx=0,ts=3,ss=0) is back in operation.
In the moment when the phone handed over to the new serving BTS, the
voice is completely noisy, and after a few seconds both phones got
disconnected.
This is the same with both directions, and "show statistics" shows
that these handovers were all successful.
My config:
handover 1
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
# handover maximum distance 9999
timer t3101 10
timer t3103 6
timer t3105 2
timer t3107 0
timer t3109 4
timer t3111 9
timer t3113 60
timer t3115 0
timer t3117 0
timer t3119 0
timer t3141 0
timer t3122 5
bts 0
cell reselection hysteresis 4
periodic location update 6
neighbor-list mode manual
neighbor-list add arfcn 123
rxlev access min 22
bts 1
cell reselection hysteresis 4
periodic location update 6
neighbor-list mode manual
neighbor-list add arfcn 885
nokia_site skip-reset 1
rxlev access min 22
For OML and RSL I am using D channels, the traffic channels are B
channels in the DAHDI config file.
If someone has an idea what to do or try, it will be appreciated.
Thanks,
Csaba
3938
days inactive
3952
days old
4 comments
2 participants
participants (2)
-
Harald Welte -
Sipos Csaba