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
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.
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
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.
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