Feature #4380

D-GSM TTCN-3 tests

Added by osmith 22 days ago. Updated 9 days ago.

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



neels wrote:

ttcn3-hlr-tests have been enhanced to include GSUP tests simulating messages arriving via a proxy instead of an MSC
(making sure messages are sent back including the original remote sender as destination_name).


  • include mDNS MS lookup in ttcn3 tests, to also simulate osmo-hlr being the proxy, not the final recipient.
  • include mDNS to make sure osmo-hlr responds to MSISDN requests
    • when it is the proxy that is closest to the MSC
    • when there is no proxy involved and the MSC is directly talking to the home HLR

OsmoHLR being the final recipient

  • Added titan.ProtocolModules.DNS as dependency to osmo-ttcn3-hacks
  • Integrated the DNS server from that repository into OsmoHLR_Tests.ttcn (needs some clean up, but works)
  • Configured the DNS server to listen on the multicast IP and port, as used by mslookup. To prevent an "address already in use" error, I have added a reuseAddr parameter to titan.TestPorts.UDPasp. So I've forked it to the Osmocom github repository (as done with SCTPasp) and patched it there.
  • Added WIP templates for receiving and sending mslookup DNS messages
  • Successfully received and verified a test message from osmo-mslookup-client
  • Successfully sent back the mslookup result to osmo-mslookup-client
  • Patches:

OsmoHLR being the proxy

  • Concept:
    • TS (testsuite) tries LU (location update) towards OsmoHLR with unknown IMSI
    • OsmoHLR does mslookup
    • TS answers to mslookup
    • OsmoHLR connects to emulated OsmoHLR server by TS
    • TS is now talking to itself with real OsmoHLR in the middle, and finishes the LU
  • Implementation:
    • mslookup mDNS emulation was attached to HLR Conn Hdlr already in previous patch
    • Started with two HLR Conn Hdlrs, so I could reuse f_perform_UL without modification and have the testsuite emulating a second OsmoHLR in parallel. But that lead to lots of port runtime errors ("port has neither connections nor mappings" or "more than one active connections"). It was not possible to answer the mslookup request from the testsuite with the second mslookup emulation instance.
    • I've changed the approach to only use one HLR Conn Hdlr (and one mslookup emulation therefore), that makes the code much simpler.
    • It's possible to answer the mslookup request from the testsuite
    • OsmoHLR connects to the emulated OsmoHLR server by TS
    • Sending GSUP messages from the emulated OsmoHLR to the real OsmoHLR results in another port runtime error, continuing here today.
    • WIP branch: osmith/dgsm at osmo-ttcn3-hacks.git


#1 Updated by osmith 22 days ago

  • Description updated (diff)

#2 Updated by osmith 21 days ago

I've fixed "Couldn't find GsupExpect" by connecting vc_GSUP_server with GSUP_PROC too. That resulted in a new error "GSUP_PROC has more than one active connections. Message can be sent on it only with explicit addressing.". To fix that, I've tried to decouple GSUP_ConnHdlr from HLR_ConnHdlr, to have 2x GSUP_ConnHdlr per HLR_ConnHdlr. But connecting the ports did not work then ("Referencing fields of a component is not allowed"). I've considered duplicating the ports to make it work, but ran into more errors. I've reverted the decoupling idea.

Finally, with figuring out and actually using explicit "to" and "from" addressing, and passing the related component vars, the emulated GSUP server in ttcn-3 receives the message! \o/

This was probably the hardest problem to solve, the rest should just be implementing the rest of the LU checking and cleaning up the patches. New patch pushed to the branch. Before submitting to gerrit, I'll make the emulated GSUP server in the ttcn-3 tests optional, so it doesn't break existing tests that don't use explicit to/from addressing.

#3 Updated by osmith 20 days ago

  • % Done changed from 70 to 80

Test infrastructure adjustments and OsmoHLR proxy test submitted: (and following patches)

The remaining bit before this issue can be closed, is a test where OsmoHLR is proxy again, but answers (or not) to mDNS requests. This should be rather easy.

#4 Updated by osmith 19 days ago

  • % Done changed from 80 to 90

Three more tests submitted, that cover all requirements set above.

#5 Updated by osmith 9 days ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

All test-related patches were merged.

Afterwards, all HLR TTCN-3 tests were failing, because the OsmoHLR patches that add new D-GSM related VTY commands were not merged yet. Until this is done, I've set "mp_hlr_supports_dgsm := false" (can be reverted once related D-GSM patches are merged to osmo-hlr.git):

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)