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)