Hi list,
implementing paging on Iu-CS directed my attention to the following
situation: What if a subscriber connects to the CN while another
connection with the same subscriber is still recorded active?
In the Iu case, one would expect an Iu-Release or a Reset message and
invalidate old connections before a new connection would be established,
but we can't/don't want to rely on that. A scenario would be that an
hNodeB were suddenly powered down and the UE starts subscribing to another
hNodeB nearby, or the UE moves to a new LAC and reconnects using an
entirely different SUA link.
So basically I'm saying, when a new gsm_subscriber_connection is
established and, from the Location Updating procedure, the conn gets
associated with an actual gsm_subscriber instance, I guess we should walk
the conn list and discard all other connections that this gsm_subscriber
still has open ... does that make sense?
At least for Iu, there should never be more than one conn_id of a SUA link
associated with the same gsm_subscriber, let alone more than one SUA link.
I browsed the gsm_04_08.c related code paths but so far couldn't find
anything that would discard old gsm_subscriber_connections upon
establishing a new location update for a given gsm_subscriber.
Is there a timeout for gsm_subscriber_connections? It's not the
anchor_timeout() from gsm_04_08.c, right? That's only while establishing a
link...
Am I on the right track here?
If yes, should we discard old conns as soon as the subscriber's IMSI is
first seen on a new link, or only after a new Location Update is completed
successfully?
Thanks!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi,
Here are the not yet merged pieces of the kernel GTP support.
I tried to address all the comment from the previous rounds.
After this series has been applied, IPv4 GTP tunnels over IPv4
should be complete. Anything IPv6 still needs work.
Regrads
Andreas
--
Andreas Schultz (12):
gtp: select netns based on NL attribute
gtp-rtnl: and netns support
gtp: add socket destroy handler
gtp: replace udp encap setup with setup_udp_tunnel_sock
gtp: switch to iptunnel framework and no longer depend on real_dev
gtp: Split TID handling for GTPv0 and GTPv1
gtp-rtnl: sync GTPA_FLOW nl attribute name from kernel to userspace
gtp-rtnl: real_ifname is not long needed, remove it
gtp-rtnl: Split TID handling for GTPv0 and GTPv1
gtp: get started with IPv6 support
list Andreas Schultz as author
gtp: add support for replacing PDP contexts
gtp.c | 669 +++++++++++++++++++++++++--------------
gtp_nl.h | 3 +
libgtnl/AUTHORS | 1 +
libgtnl/include/libgtpnl/gtp.h | 6 +
libgtnl/include/libgtpnl/gtpnl.h | 3 +-
libgtnl/include/linux/gtp_nl.h | 5 +-
libgtnl/src/gtp-genl.c | 36 ++-
libgtnl/src/gtp-rtnl.c | 6 +-
libgtnl/src/gtp.c | 44 ++-
libgtnl/src/internal.h | 13 +-
libgtnl/src/libgtpnl.map | 6 +
libgtnl/tools/Makefile.am | 4 +-
libgtnl/tools/gtp-link-add.c | 5 +-
libgtnl/tools/gtp-tunnel.c | 134 +++++---
libgtnl/tools/gtpnl.c | 35 --
15 files changed, 642 insertions(+), 328 deletions(-)
delete mode 100644 libgtnl/tools/gtpnl.c
--
2.7.4