Project

General

Profile

Actions

Feature #3614

closed

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

SGs integration tests in TTCN3

Added by laforge over 5 years ago. Updated over 4 years ago.

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

100%

Resolution:
Spec Reference:

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.


Files

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

Checklist

  • Paging for non-EPS services (VLR originated)
  • Non-EPS Alert (VLR originated)
  • VLR failure/reset (VLR originated)
  • MM-INFO (VLR originated)
  • downlink unitdata (VLR originated)
  • servic abort (VLR originated)
  • LU for non-EPS services (MME originated)
  • IMSI detach from PS indication (MME originated)
  • IMSI detach from non-EPS indication (MME originated)
  • Implicit IMSI detach from non-EPS (MME originated)
  • MME failure/reset (MME originated)
  • tunneling / uplink unitdata (MME originated)
  • service request (MME originated)
  • implicit IMSI detach from EPS (MME originated)
Actions #1

Updated by laforge over 5 years ago

  • Priority changed from Normal to High
Actions #3

Updated by laforge over 5 years 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.

Actions #4

Updated by laforge over 5 years 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.

Actions #5

Updated by laforge about 5 years 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.

Actions #6

Updated by dexter about 5 years 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
Actions #7

Updated by dexter about 5 years 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

Actions #8

Updated by laforge about 5 years 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?

Actions #9

Updated by dexter about 5 years 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.

Actions #10

Updated by dexter about 5 years ago

  • % Done changed from 60 to 80
Actions #11

Updated by dexter about 5 years 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)

Actions #12

Updated by fixeria about 5 years 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.

Actions #13

Updated by dexter about 5 years 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.

Actions #14

Updated by dexter about 5 years 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?

Actions #15

Updated by dexter about 5 years 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/

Actions #16

Updated by dexter about 5 years 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/

Actions #17

Updated by laforge about 5 years 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.

Actions #18

Updated by dexter about 5 years 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

Actions #19

Updated by dexter about 5 years 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.

Actions #20

Updated by laforge about 5 years ago

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

Actions #21

Updated by dexter almost 5 years ago

  • Checklist item Implicit IMSI detach from non-EPS (MME originated) set to Done
  • Checklist item implicit IMSI detach from EPS (MME originated) set to Done

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?

Actions #22

Updated by laforge almost 5 years ago

On Thu, Mar 21, 2019 at 11:16:34AM +0000, dexter [REDMINE] wrote:

Regarding the alerting I still do not understand for what it is for.

I guess this may refer to the standard "MAP-READY-FOR-SM" procedure between VLR and HLR?

This is e.g. used to let the HLR know whenever the subscriber has performed some activity,
which means he is reachable again, which means that e.g. pending/previously-failing SMS
can be delivered (The SMSCs will register themselves with the HLR if any
SMS delivery fails, so the HLR can notify the SMSCs when it makes sense
to re-try)

  • 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)

This is about 5G/NR deployment options. Option 1 refers to 5G base
stations attached to a 4G Core, where Option 2 refes to an entirely new
5G core. I guess we can ignore that for now.

In general, I think we can leave this alerting procedure open for now.

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?

From what you're saying isn't that siply a paging timeout ? So when we
don't get any response to the paging, we send the service abort to the
MME?

Actions #23

Updated by laforge over 4 years ago

  • Status changed from In Progress to Stalled
Actions #24

Updated by laforge over 4 years ago

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

Actions #25

Updated by laforge over 4 years ago

  • Status changed from Stalled to Resolved

laforge wrote:

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

ping?

Actions #26

Updated by dexter over 4 years ago

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.

Actions #27

Updated by dexter over 4 years ago

  • Checklist item servic abort (VLR originated) set to Done

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.

Actions #28

Updated by laforge over 4 years ago

On Tue, Sep 24, 2019 at 09:09:34AM +0000, dexter [REDMINE] wrote:

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.

Agreed.

Actions #29

Updated by dexter over 4 years ago

  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)