This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgDear Arthur, On Tue, Mar 19, 2019 at 06:55:36AM +0000, ArthurLRJ at outlook.com wrote: > I am facting the following problems and hope you can help me: > > - At present, I have two GGSN nodes(such as A and B), I also hava a sgsnemu node which is connected to GGSN-A and hold a PDP context, now I want to connect this PDP context to GGSN-B to simulate the handover of mobile devices between different base stations. How can I do it? 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. > - And I I wonder if sgsnemu can generate “Update PDP Context Request” message. 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 at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)