Feature #3614

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

SGs integration tests in TTCN3

Added by laforge 4 months ago. Updated 13 days ago.

SGs Interface
Target version:
Start date:
Due date:
% Done:




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.


#1 Updated by laforge 4 months ago

  • Priority changed from Normal to High

#3 Updated by laforge 3 months ago

I've started to create a quite extensive list of send and receive teplates for SGsAP, see

Those will be the basis for the actual tests, together with the SGsAP_CodecPort.ttcn ( and upcoming SGsAP_Emulation.ttcn modules.

#4 Updated by laforge 3 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 18 days 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 14 days 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 14 days 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:

#8 Updated by laforge 14 days 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 13 days 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 13 days ago

  • % Done changed from 60 to 80

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)