Dear Arthur, On Tue, Mar 19, 2019 at 06:55:36AM +0000, ArthurLRJ(a)outlook.com wrote: I'm sorry, but sgsnemu doesn't implement this functionality. It, as well as the shared libgtp library that's used by sgsnemu and osmo-ggsn are also not very well suited for this purpose. libgtp is implemented to implement *one* SGSN or *one* GGSN node. However, in your situation you actually would want to implement *two* SGSNs and then move context from one simulated SGSN to another. I don't think so, sorry. IT would have to be extended, if needed. sgsnemu is a small hackish tool that was primariliy used in earlier days for manual testing of OpenGGSN (which later became OsmoGGSN). These days, in the Osmocom project, we mainly use test suites written in TTCN-3 to test our implementations. The capabilities of TTCN-3 and the Eclipse TITAN toolchan far outpower the capabilitis of hand-written tools like sgsnemu. So our focus is more on extending the TTCN-3 test coverage than to extend sgsnemu's capabilities. You can find our current test suite for the GGSN at http://git.osmocom.org/osmo-ttcn3-hacks/tree/ggsn_tests/GGSN_Tests.ttcn The tests unfortunately also don't yet include tests for migration of a subscriber from one SGSN to another, but it would really be great to see any developments in this area. One option would be to extend this test suite to include the test cases/scenarios you require. The advantage of implementing tests as part of this test suite is that the tests can be fully automatized. They will be executed automatically against OsmoGGSN and ensure no regressions will go unnoticed. Of course, the tests could also be ran against other GGSN implementations. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)