Project

General

Profile

Feature #3614

Feature #2583: SGsAP Interface for LTE/ePC CSFB Support

SGs integration tests in TTCN3

Added by laforge 5 months ago. Updated 1 day ago.

Status:
In Progress
Priority:
High
Assignee:
Category:
SGs Interface
Target version:
-
Start date:
10/02/2018
Due date:
% Done:

90%

Resolution:

Description

Let's use the TITAN SGsAP encoder to implement integration tests against a [future] SGs interface of OsmoMSC.

This includes our usual stack of something like a SGsAP_CodecPort, SGsAP_Emulation,... as well as the individual test cases.

The tests become part of MSC_Tests.ttcn, and can hence interact on AoIP, GSUP, SGs, VTY, CTRL, etc. with the IUT (OsmoMSC).

Tests should include tests for successful procedures as well as common error paths/cases.

Let's use the checklist here to collect what to test.

spurious_cp-error.pcap spurious_cp-error.pcap 11 KB dexter, 02/07/2019 12:49 PM

History

#1 Updated by laforge 5 months ago

  • Priority changed from Normal to High

#3 Updated by laforge 4 months ago

I've started to create a quite extensive list of send and receive teplates for SGsAP, see https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11305/

Those will be the basis for the actual tests, together with the SGsAP_CodecPort.ttcn (https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11306/) and upcoming SGsAP_Emulation.ttcn modules.

#4 Updated by laforge 4 months ago

  • Checklist item LU for non-EPS services (MME originated) set to Done
  • Checklist item IMSI detach from PS indication (MME originated) set to Done
  • Checklist item IMSI detach from non-EPS indication (MME originated) set to Done
  • Status changed from New to Stalled
  • Assignee set to laforge
  • % Done changed from 0 to 20

First couple of test cases have been implemented. Now it's up for OsmoMSC to catch up in terms of an actual implementation that can be tested.

#5 Updated by laforge about 2 months ago

  • Assignee changed from laforge to dexter
  • % Done changed from 20 to 60

dexter has been working on this, we should have transferred ownership of this ticket sooner. Please check those boxes that have tests, and think about whether it makes sense to add tests for those unchecked boxes remaining.

#6 Updated by dexter about 1 month ago

  • Checklist item Paging for non-EPS services (VLR originated) set to Done
  • Checklist item MM-INFO (VLR originated) set to Done
  • Checklist item downlink unitdata (VLR originated) set to Done
  • Checklist item MME failure/reset (MME originated) set to Done
  • Checklist item tunneling / uplink unitdata (MME originated) set to Done
  • Checklist item service request (MME originated) set to Done

#7 Updated by dexter about 1 month ago

The first batch of SGs related TTCN3 tests are merged to master. Since the related osmo-msc patches are not yet merged to master, those tests are expected to fail. Unfortunately there is a problem with the testsuite now since the testsuite now tries to reach the SGs interface of osmo-msc during initalization. This causes almost all testcases to fail. The following patch adds a configuration option that makes the SGs interface optional and switches it off by default. As soon as the related osmo-msc patches are merged to master we can enable the SGs interface again.

See also: https://gerrit.osmocom.org/12477

#8 Updated by laforge about 1 month ago

sorry, that was my bad. I somehow thought the MSC side patches were merged.

However, after checking now, I realize the SGs patch for the MSC i sstill marked
as WIP and not ready for merge. Can you please remind me why that was the case?

#9 Updated by dexter about 1 month ago

  • Checklist item VLR failure/reset (VLR originated) set to Done

I have removed the WIP flag now. I think could merge it since even if there are still problems with the SGs interface we could fix that in a follow up patch. The risk that it interferes with the existing A/Iu functionality is low since SGs is more or less a separate thing. I ran the current state through docker locally now, everything seems to be fine.

With SGs in particular I still see a few minor problems:

  • Service abort: This message is sent if the VLR/MSC decides to abort the call just before any sccp communication happend. I wonder what this abort reasons could be. Maybe using Ts14 would be a good idea, however, the spec seems not to mention that explicitly ecaclty when the service abort should be sent.
  • NON-EPS Alert: When I get 3GPP TS 29.118, chapter 5.3 correctly this functionality is used to notify to the MSC that there is signaling activity between UE and MME. I am not sure what we do with this information on osmo-msc. To me this looks like an optional feature that can be omitted.
  • IMSI Detach: There seems to be not much difference between an implicit and an explicit IMSI detach. The only difference I can see so far is that an implicit IMSI detach must not remove the subscriber from the VLR when there is an existing signalling connection. From my understanding that means if we are attached on A or Iu an implicit imsi detach must not have any effect other then moving the SGs association to NULL (it should already be NULL anyway)

In my optinon the patchset should now receive a practical test on a real MME so that we can see where the real problems are.

#10 Updated by dexter about 1 month ago

  • % Done changed from 60 to 80

#11 Updated by dexter 13 days ago

The patchset for current master that implements (the basic) SGs interface is now merged to current master, so its time to enable the SGs interface in TTCN3 so that the SGs related tests can run.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12855 MSC_Tests: Enable SGs interface by default

Unfortunately after enabling the SGs interface the tests won't pass. Further investigation revealed that the problem is caused by spurious SMS related messages that distract the SGs tests. To make sure that this interference is not caused by re-using already used IMSI I have made sure that each SGs related tests uses an individual IMSI and never uses the same IMSI again.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12856 MSC_Tests: make sure SGs tests don't interfere

Unfortunately this did not help. The symtom is the MO SMS that is sent from the helper function f_sgsap_bssmap_screening() seems to go through without any problem, but the clear command is not sent by the MSC immediately, instead after a while a CP-ERROR and a CLEAR COMMAND is sent. This behavior is odd because as far as I can tell ther should be just a CLEAR COMMAND after the CP-ACK. The behavior is not visible when MSC_Tests.TC_sgsap_lu is executed alone. But when MSC_Tests.TC_gsup_mt_multi_part_sms (which xfails) is executed before, then the odd behavior is triggered (see attached trace)

#12 Updated by fixeria 13 days ago

The behavior is not visible when MSC_Tests.TC_sgsap_lu is executed alone.
But when MSC_Tests.TC_gsup_mt_multi_part_sms (which xfails) is executed before,
then the odd behavior is triggered (see attached trace)

Ah, yes. I also noticed quite strange behaviour of OsmoMSC during and after this test case.
I will try to replicate your problem on my side, but for now feel free to disable this test
case, multi-part SMS is not (yet) implemented in OsmoMSC anyway.

#13 Updated by dexter 13 days ago

Thanks for telling me, I will try another full run in docker, but without MSC_Tests.TC_gsup_mt_multi_part_sms.

The symptoms seem not to be related to SGs. When I run MSC_Tests.TC_lu_and_mo_sms after MSC_Tests.TC_gsup_mt_multi_part_sms the bug is also triggered. Harald suggested to modify the message reference parameters, so I changed tp.msg_ref and rp.msg_ref to something different but this did not change anything. I also tried with a different tp_addr.

template (value) SmsParameters t_SmsPars(hexstring tp_daddr := '12345'H) := {
    tp := {
        msg_ref := '23'O,
        da := ts_TP_DA('0000'B, '000'B, tp_daddr),
        pid := '00'O,
        dcs := '00'O,
        udl := 0,
        ud := ''O
    },
    rp := {
        msg_ref := '42'O,
        orig := omit,
        dest := { '0000'B, '000'B, '0'B, '98765'H }
    },
    tid := 0,
    dlci := '03'O,
    exp_rp_err := omit
}

Presumably this is a bug in osmo-msc and the attempt with the multipart SMS puts the MSC into a wired state. However, I wonder how this can be. Almost everything (ISMI etc.) is different and there is even a BSSMAP RESET in-between the two tests.

#14 Updated by dexter 13 days ago

I have tried now an entire run in docker with MSC_Tests.TC_gsup_mt_multi_part_sms removed from the control section. Then everything looks normal. Maybe it would be compromise to move MSC_Tests.TC_gsup_mt_multi_part_sms to the end of the testsuite?

#15 Updated by dexter 9 days ago

There is a problem with MSC_Tests.TC_gsup_mt_multi_part_sms, this test seems to mess up osmo-msc in a way that it fails any future SMS related operations, so it also fails the SGSAP tests which rely on sending SMS. I recommend to move MSC_Tests.TC_gsup_mt_multi_part_sms after the SGSAP tests.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12877/

Also there is now a patch that turns on the SGs interface for the TTCN3 testsuite.

See also: https://gerrit.osmocom.org/#/c/docker-playground/+/12878/

#16 Updated by dexter 6 days ago

From what I can see all dependencies now merged and we are ready to turn on the SGs interface in the testsuite. I also checked the tests with a full run in docker and I get no unexpected failures.

See also: https://gerrit.osmocom.org/#/c/docker-playground/+/12878/

#17 Updated by laforge 6 days ago

On Thu, Feb 14, 2019 at 10:10:28AM +0000, dexter [REDMINE] wrote:

From what I can see all dependencies now merged and we are ready to turn on the SGs interface in the testsuite. I also checked the tests with a full run in docker and I get no unexpected failures.

I'd love to have merged such a patch, but as discussed on IRC >= 1 week ago, we cannot
merge the "naive approach" patch due to compatibility with the "latest" tests :(

There needs to be a different config file depending on master vs. latest tests.

#18 Updated by dexter 6 days ago

Unfortunately there are different test runs in docker, those with SGs enabled osmo-msc and those with the old osmo-msc that does not yet support the SGs interface. When we enable the SGs interface globally in the TTCN3 tests we will fail those testruns wich test the older osmo-msc. I now have changed the testsuite so that the SGs interface is only initalized and connected for SGs related tests. This means the SGs tests will still fail on old osmo-msc versions, but the failure will be limited to the SGs tests and not extend over the whole testsuite.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12913 MSC_Tests: Make sure only sgsap related tests use the SGs interface

#19 Updated by dexter 1 day ago

  • % Done changed from 80 to 90

All currently available tests are now enabled. The Testsuite shows fluctuation in TC_sgsap_reset, but otherwise the results look good.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)