Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

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.

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.

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.

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

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.

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)

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.

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.

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?

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/

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/

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

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

it would be great to get the missing four tests still implemented at some point, so the ticket can be closed.

I have added testcases that send an implicit IMSI detach messages (noneps and eps):
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13351 MSC_Tests: add testcase TC_sgsap_impl_imsi_det_noneps
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13352 MSC_Tests: add testcase TC_sgsap_impl_imsi_det_eps

Regarding the alerting I still do not understand for what it is for. The procedure is described in 5.3. In the end it means that the VLR can request the MME to send SGsAP-UE-ACTIVITY-INDICATION messages when there is signaling activity detected for the UE. If we implement this, there are basically two open questions:

• On what condition do we request alerting? Always? (VTY-Option)
• What do we do when we receive SGsAP-UE-ACTIVITY-INDICATION? (In 5.3.2.4 there is an Deployment option 2 mentioned, but I am not sure if this applies to our situation)

For the service abort we might want to investigate. At the moment the sending of a service abort is not implemented in osmo-msc. The service abort procedure seems also be only of interest in the time frame where a SGsAP-PAGING-REQUEST had been sent but no L3 complete message on the A interface was carried out yet. Once the SCCP connection is made, the procedure seems not to apply anymore. I wonder how we could test this. We would have to make the MSC to abort the call somehow. Maybe we can do this via the MNCC interface?

@pmaier, it would be great to implement those two missing test cases so we can finally close this ticket.

laforge wrote:

@pmaier, it would be great to implement those two missing test cases so we can finally close this ticket.

ping?

The problem I see here is that those two missing tests relate to features we currently do not implement in osmo-msc. The service abort procedure is indeed something we could test.

Actually this would be TC_sgsap_paging_and_nothing than. This test currently expects the MSC to stop paging silently. This test could be extended so that it expects the SGsAP-SERVICE-ABORT-REQUEST as well.

I have now added sending of the SGsAP-SERVICE-ABORT-REQUEST on paging timeout. I also fixed the related TTCN3 test to expect this message.

See also:
https://gerrit.osmocom.org/c/osmo-msc/+/15598 paging: Send SGsAP-SERVICE-ABORT-REQUEST on paging timeout
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15597 MSC_Tests: Expect SGsAP-SERVICE-ABORT-REQUEST on paging timeout

The only missing point now is Non-EPS Alert, we could try to implement this. Probably the MME implementations we currently have access to will be able to send us Alert events but then is the question what do we do with those events. I think we should drop this point for the moment as we do not need this feature.