Feature #2478
closedManual interop testing with NG40 core simulator
Added by laforge over 6 years ago. Updated over 5 years ago.
90%
Description
Please use a sysmoBTS 1002 with current 201705-nightly image, connect it to an OsmoBSC and configure it to interconnect with OsmoSTP and the NG40 core simulator.
The goal should be to test the interop of OsmoBSC with the MSC in the NG40, for basic BSSAP/BSSMAP procedures such as- BSSAP RESET
- LU (imsi attach + periodic)
- USSD
- MO-SMS
- MT-SMS
- MO-call (voice)
- MT-call (voice)
We should identify which (if any) interoperability issues exist and create separte tickets about such issues.
Please coordinate with Daniel to help you getting started with the NG40 core.
Files
| trace_filtered.pcapng | trace_filtered.pcapng | 6.9 MB | dexter, 11/03/2017 09:52 AM | ||
| trace_rtp_stream_between_mgw_and_msc.pcapng | trace_rtp_stream_between_mgw_and_msc.pcapng | 6.96 MB | dexter, 11/03/2017 09:52 AM | ||
| mgcp.log | mgcp.log | 8.16 KB | dexter, 11/03/2017 09:52 AM | ||
| bsc.log | bsc.log | 46.2 KB | dexter, 11/03/2017 09:53 AM |
Related issues
Updated by dexter over 6 years ago
- % Done changed from 0 to 50
Thanks Daniel I am now familiar with the NG40 tester. The current state is that we can't really test SMS, this seems to be due to a configuration problem, but we are able to place testcalls. The signalling part of the call seems to work fine, but there is no Voice comming through. This is probably because osmo-bsc presents an IP/port of the BTS and since the MSC runs inside the NG40 box the packets probably get stuck. I suspect that things will be much better if we present an IP/PORT that is on the same machine as osmo-bsc runs on.
Updated by laforge over 6 years ago
On Mon, Sep 18, 2017 at 04:17:24PM +0000, dexter [REDMINE] wrote:
Thanks Daniel I am now familiar with the NG40 tester. The current
state is that we can't really test SMS, this seems to be due to a
configuration problem,
please document that problem in detail with protocol traces, probably
best as a separate issue here (or a child issue?)
but we are able to place testcalls. The
signalling part of the call seems to work fine, but there is no Voice
comming through. This is probably because osmo-bsc presents an IP/port
of the BTS and since the MSC runs inside the NG40 box the packets
probably get stuck. I suspect that things will be much better if we
present an IP/PORT that is on the same machine as osmo-bsc
runs on.
Ok. Let's postpone further testing until osmo-mgw support is fully
integrated into / used by osmo-bsc.
Updated by dexter over 6 years ago
Did another test of osmo-bsc today, found a segfault which is now fixed. Currently osmo-bsc responds with an assignment failure, I will investigate why.
Updated by dexter over 6 years ago
- Status changed from New to In Progress
Did another test this morning. I managed to fix the bug that caused the assignment to fail. The call signalling is fine now, except for the fact that osmo-mgw returns the wrong IP-Address with the CRCX-Response for the network side. I have hacked osmo-mgw to return the correct IP-Address, but for some reason it still does not work. It looks just like the NG40 simulator does not send any RTP packets.
Updated by dexter over 6 years ago
Since we now have a convenient way to determine the IP-Address for the uplink audio stream, I will implement this into osmo-mgw. Then we can re-test.
daniel: We have also the feeling that there is a problem with the tester. I hacked osmo-bsc to transmit the correct IP in the assignment complete message. Even then I saw no RTP packets comming from the tester.
Updated by dexter over 6 years ago
- File trace_filtered.pcapng trace_filtered.pcapng added
- File trace_rtp_stream_between_mgw_and_msc.pcapng trace_rtp_stream_between_mgw_and_msc.pcapng added
- File mgcp.log mgcp.log added
- File bsc.log bsc.log added
I did another test on the NG40 tester today. The result is the same, except
hat the IP addresses that are negotiated on MGCP level look now correct.
There are also some odd UDP packets I can not explain:
We see the following connection is negotiated by the bsc via mgcp:
BTS =========================> 10.9.1.122:4002 MGW 172.16.28.100:4004 <======================== MSC
BTS 10.9.1.133:32346 <======================== MGW ==========================> 172.16.28.1:4000 MSC
When looking at Assignment Request and Assignment complete we see that the
IP-Addresses and ports match the IP-Addresses on the MGCP layer (leg pointing
towards the core network).
It is possible to make out an RTP stream that goes from the BTS, through the
MGW up to the MSC, but there is no RTP stream in the opposite direction.
However, when observing the stream between MGW and MSC further we can make
out empty UDP packets comming from the MSC side. Can it be possible that
this is a bug in the NG40 tester? Maybe it fails somehow to generate an
RTP payload and eventually sends empty packets? The ports do match up,
just the payloads seems missing.
(see attached traces)
Updated by laforge over 6 years ago
Hi Dexter,
On Fri, Nov 03, 2017 at 09:56:11AM +0000, dexter [REDMINE] wrote:
However, when observing the stream between MGW and MSC further we can make
out empty UDP packets comming from the MSC side. Can it be possible that
this is a bug in the NG40 tester? Maybe it fails somehow to generate an
RTP payload and eventually sends empty packets? The ports do match up,
just the payloads seems missing.
As far as I remember, you must somehow configure which samples / sample files
are played back by the simulator. I don't know the details, but I know
there are some files and those files must be in the correct path to be found,
there was some conversation about this at some point.
I suggest you have a look about this and then send a full report with traces
to ng4t, Daniel can establish the contact.
Updated by laforge over 6 years ago
- Related to Feature #2477: Automate execution and reporting of OsmoMSC interop tests with NG40 core simulator added
Updated by laforge over 6 years ago
- Priority changed from High to Urgent
please make sure you follow-up on the voice topic, with Daniel and possibly NG4T help.
Updated by laforge over 6 years ago
- Related to Support #2622: Prepare automatic interop testing of OmsoBSC against NG40 core simulator + osmo-bts-virtual + mobile added
Updated by laforge over 6 years ago
It might make sense to teach roh how to perform this testing, now that you have a setup for it. roh could execute this once per week (like in old days!) until we have a more automatic test setup (see related tickets). So next time you do manual testing, please schedule with roh that he joins you and learns how to do this.
Updated by dexter over 6 years ago
- % Done changed from 50 to 60
Since we found the RTP length bug #2625 yesterday I have re-tested on NG40 now. This time the test was successful. All packets I see contain useful RTP data and we hear an echo on the phone. Probably the NG40 tester did not like the oversized packets.
Updated by dexter over 6 years ago
- % Done changed from 60 to 70
There is great news. I tried a call between two subscribers now and it worked including voice! So we can now test mobile originated and mobile terminated calls.
Updated by dexter over 6 years ago
- % Done changed from 70 to 80
I managed to find out why SMS did not work. It was the SMSC number setting in subscriber.conf that was set to 12345, but we seem to use 00495555 in our sims by default. I have now fixed this in subscriber.conf and mobile originated/mobile terminated SMS seems to work fine now.
From my perspective my two main problems are solved now. Is there anything else we need to focus now? Probably we want to get the playback numbers and different codecs running.
Updated by laforge over 6 years ago
On Fri, Nov 10, 2017 at 01:22:26PM +0000, dexter [REDMINE] wrote:
From my perspective my two main problems are solved now. Is there anything else we need to focus now? Probably we want to get the playback numbers and different codecs running.
- all 5 different codecs, indeed
- SMS over SACCH during active TCH voice call
- inter-BTS (intra-BSC) hand-over during active voice calls
- maybe dynamic PDCH/TCH switching? I don't think it has implications
beyond the BSC, though.
Updated by laforge over 6 years ago
On Fri, Nov 10, 2017 at 12:41:04PM +0000, dexter [REDMINE] wrote:
There is great news. I tried a call between two subscribers now and it worked including voice! So we can now test mobile originated and mobile terminated calls.
congratulations!
please inform NG4T about this, and let them know from which particular commit versions
onwards this has been fixed. They are particularly interested in running this on a
sysmoBTSv2, so an appropriate test should be done with a 201705-nightly should be done.
Updated by dexter over 6 years ago
- % Done changed from 80 to 90
I was able to reproduce the result with a nightly build on my sysmoBTS. I have informed NG40 now I have sent them the exact image file name and the config files I used. I also re-tested the current development state on my laptop. It still works fine.
Updated by dexter almost 6 years ago
- Status changed from In Progress to Stalled
Updated by dexter almost 6 years ago
- Status changed from Stalled to In Progress
I have re-tested the setup (sysmobts + osmo-bsc) and it still works fine. But as far as I can see NG40 only advertises AMR-HR and AMR-FR. Both work, but when I try to force something different it fails of course (cause code is fine, the BSC recognizes the mismatch). The subscriber.conf lists some profile settings that also have a parameter AMR. Presumably we can also use the other codecs when we change the NG40 configuration.
Updated by laforge over 5 years ago
- Status changed from In Progress to Resolved
