Hi!
Just a "quick" status report about the progress I've made with the code
over the last three days, and what is now in 'master':
1) handover is not only working on a signalling level, but also fully working
with actual voice traffic
This turned out to be a major headache, since we don't [yet?] have a proper
RTP media gateway and so far decided to simply relay the RTP frames rather
than doing proper processing. In case of handover though, the RTP source
changes (different SSRC / timestamp / sequence) - plus we also get some
dropped frames and have to ensure that we don't hide that fact from the
receiver.
In order to make it work, I added a new "MNCC RTP Proxy" mode, which is
automatically selected if you
a) enable the RTP Proxy mode with "-P" on the command line, and
b) enable handover using the 'handover 1' command on the VTY
The Handover decision (handover_decision.c) is currently still based on
a single MEASUREMENT REPORT, i.e. way too volatile. This was intended
for testing, where we need as many handovers as possible.
I've meanwhile written a lot of additional code to implement proper measurement
averaging and neighbor cell selection. This is not committed yet, but
will be committed by tomorrow.
2) Support for MNCC (lcr) with RTP based BTS is in 'master'
There's no need for any old branches or patches for this anymore
3) Support for EFR frames with RTP based BTS in MNCC
4) No half-rate support at 26C3. The integration with lcr is likely
too much work, and I think we should try not to implement even more
features that have not yet received lots of testing
5) fixing tons of compiler warnings all over the code
6) fix segfault in RRLP in case of unsuccessful paging (sorry sylvain,
I fixed this independently before seeing your patch, but I actually
prefer your solution, will look at it tomorrow)
7) correct System Information Type 5 and 6 on ip.access
The two BTS types implement the RSL SACCH FILLing slightly different,
resulting in broken neighbor cell lists on ip.access systems.
Any testing of current master that you can do is very much appreciated,
let's hope we can catch more bugs before we go live at 26C3.
Regards,
Harald
--
- 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)
Hi,
I have a nanobts unit 139 with a software that somehow only accepts GSM FR
(and not EFR), unless I also send the RTP payload type IE (
RSL_IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the "RTP
payload type" IE, the "RTP payload type 2" has no effect I can see).
hi,
here are two patches (attached):
the lcr_rtp.fix will make the current lcr_rtp branch compile. also it
works with LCR.
the systeminfo.fix contains a pointer fix and a question why there is a
value cleared again. (don't apply it, just apply the line with the
pointer fix)
regards,
andreas
Here's a small series with some minor fixes I found when looking at multiple
SMS in a single RR connection.
For the MO case, it actually now works as described in the spec in the
no-error case. But what can happen is that after the second
CM SERVICE REQUEST, we may never receive the last CP-ACK of the previous
transaction (and thus leak a transaction). The spec says than when receiving
a CP-DATA after a CM SERVICE REQUEST we should consider we also implicitely
received the last CP-ACK of the previous transaction ... that's not
implemented yet.
For the MT case, it currently makes several RR connection which is quite
bad ... to be fixed.
Sylvain
Is there anyone well knowing about the signaling part in openbsc project
there might be interested in the solving of a few specific tasks against
payment?
the results will be posted in the openbsc project also.
Please contact me.
Med venlig hilsen / Best regards
Kasper Hessellund Hansen
Denmark
Khh at viptel.dk
Is there anyone well knowing about the signaling part in openbsc project
there might be interested in the solving of a few specific tasks against
payment?
the results will be posted in the openbsc project also.
Please contact me.
Med venlig hilsen / Best regards
Kasper Hessellund Hansen
Denmark
Hi Andreas + List,
I have now studied the new "RTP capable" lcr integration in detail. My
sincere apologies once again for the long delay that this has been taking
me.
I really like the interface (like its predecessor). The major restriction
at the moment seems to be its limitation to support only GSM Version 1
Full Rate.
After doing some testing with the current 'lcr_rtp' branch in git, as well
as the attempt to integrate handover support with the lcr/mncc interface,
I am considering to add support for other codec types, too.
GSM EFR (only exists in full-rate) is interesting for everyone, as almost
all phones support it, and it renders significantly higher quality.
GSM V1 halfrate is important for BS-11 users who want increased capacity, since
this BTS does not support AMR-halfrate.
GSM V1 full-rate is important for ip.access, since it is the only half-rate
codec it supports, and thus the only way to increase capacity for this BTS.
GSM AMR full-rate is probably of the least interest, but still nice to have.
For the 26C3, I would love to run in a EFR-fullrate and AMR-halfrate
configuration, depending on the phone's capabilities.
Regards,
Harald
--
- 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)
Hi!
I've just committed the current state of the handover code to git.
What is working so far:
* receiving + parsing the measurement reports from both MS and BTS
* performing the actual handover process, i.e. allocating / activating
the new logical channel on the new BTS, waiting for the ACK, sending
handover command to the MS, waiting for HO complete, HO fail or timeout,
...
* a minimalistic handover decision making. without any averaging: If we
have a cell that's >= 3dB better than the current one, try a handover.
What's missing:
* switching the actual traffic channel contents (i.e. re-configuring the RTP
streams in the ip.access case, or reconfiguring the TRAU mux in E1 case)
* better handover algorithm implementation including averaging
I'm on a business trip tomorrow, but the code is already seeming to work quite
fine, and it looks like:
<0400> abis_rsl.c:980 MEASUREMENT RESULT NR=13 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 10dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-61dBm RXL-SUB-dl=-56dBm RXQ-FULL-dl=6 RXQ-SUB-dl=4 NUM_NEIGH=1
<0400> abis_rsl.c:1010 ARFCN=868 BSIC=63 => -70 dBm
<80000> handover_decision.c:61 process meas res: No better cell
<0400> abis_rsl.c:980 MEASUREMENT RESULT NR=14 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 10dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-87dBm RXL-SUB-dl=-83dBm RXQ-FULL-dl=6 RXQ-SUB-dl=4 NUM_NEIGH=1
<0400> abis_rsl.c:1010 ARFCN=868 BSIC=63 => -69 dBm
<80000> handover_decision.c:61 process meas res: Cell on ARFCN 868 is better, starting handover
<80000> handover_logic.c:92 (old_lchan on BTS 0, new BTS 1): <0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE ACK
<80000> handover_logic.c:151 handover activate ack, send HO Command
<0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 2 pd 06) Sending 0x2b to MS.
<0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1082 HANDOVER DETECT access delay = 0
<0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1082 HANDOVER DETECT access delay = 0
<0001> abis_rsl.c:1396 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a sapi=0 ESTABLISH INDICATION
<0001> abis_rsl.c:1396 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a sapi=0 DATA INDICATION
<0008> gsm_04_08.c:1595 HANDOVER COMPLETE cause = Normal event
<0002> handover_logic.c:203 lchan (bts=0,trx=0,ts=2,ch=0) decreases usage to: 0
Regards,
Harald
--
- 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)
