Bug #2776

osmo-hnbgw seems to never discard RUA<->SUA mappings

Added by neels 28 days ago. Updated 11 days ago.

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


Spec Reference:


attach a subscriber, and on the hnbgw vty, 'show hnb all'. This will show the hNodeB and two mappings for the subscriber, one for IuCS and one for IuPS.

HNB "" 
    MCC 901 MNC 70 LAC 24358 RAC 22 SAC 65535 CID 1048575 HNBAP ID 0 RUA ID 0
    IuCS 25->1004 (RUA->SUA) state=1
    IuPS 25->1005 (RUA->SUA) state=1

Put the phone in flight mode, the mappings remain. Re-attach the phone, two more mappings show up, and so on.

The mappings remain even after the log shows numerous

osmo-iuh/src/context_map.c:143 Running context mapper garbage collection

Make sure that this gets cleaned up at some point. I would expect at least after a UE Detach, the mappings should go away. I'd expect also right after a conn is closed, so that they are discarded e.g. when a Location Updating is done.


#1 Updated by neels 28 days ago

  • Priority changed from Normal to High

#2 Updated by neels 28 days ago

hmm, there aren't necessarily new mappings created for each flight mode and back... maybe I got the semantics wrong. Still seems to me that the mappings stay around for too long...

#3 Updated by neels 25 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 70

indeed there is a context_map_deactivate() function, which only gets called when the entire hnb context gets torn down.

When to remove context maps? There is a RUA id-Disconnect class of messages, which coincides with an Iu-Release. It makes sense to invalidate a mapping at that point. OsmoHNBGW code already has some state for a mapping by which a discarded mapping remains reserved for two more garbage collector runs, after which it will be discarded.

Found another bug in the garbage collector: must use llist_for_each_entry_*safe* when discarding entries.

#4 Updated by neels 25 days ago

a quite interesting question is: this context map maps RUA Context-IDs to SUA Context IDs (?) but we're not using SUA anymore. In immediate consequence, it maps RUA Context-IDs to prim->*.conn_id, but I'm having trouble to find any place where this prim conn_id is even used in the current M3UA stack when composing RANAP towards the CN. It seems that there must be some mapping in order for connection-ful messages to receive their responses back to RUA with the correct RUA Context-ID, but I can't find the prim conn_id sent up to RANAP anywhere. Could it be that the entire context_map mechanism in osmo-hnbgw is already superseded by some libosmo-sigtran feature?? Still looking...

#5 Updated by laforge 25 days ago

komm doch mal in IRC oder Jabber :P

#6 Updated by neels 25 days ago

It is a bit confusing, but I found the locally created context ID in the SCCP Source Local Reference, where it belongs.

The confusing part is: we created e.g. the local reference id 1002 (decimal), and in the wireshark trace, I get 0xea0300. This looks like a completely unrelated ID, until I observe that hex(1002) = 0x03ea. It seems that either the wireshark dissector for SCCP is a bit crude, or that we encode the reference in the "wrong" byte order. As long as the references go back and forth in the same byte order, there isn't really a "wrong" byte order, yet this made it quite challenging to understand what was going on in the network trace.

#7 Updated by laforge 25 days ago

each SCCP connection is identified (to the SCCP user, such as the hnb-gw) by a connection ID.

Compare the situation with a TCP Socket and think of it something like a socket file descriptor, which has only significance between the "socket provider" (kernel) and the "socket user" (your application program).

The source/destination local references are just present on the wire. Their only requirement is to be unique. There is no defined mapping between the locally-significant connection_id and the protocol-layer source/remote references!

#8 Updated by neels 24 days ago

  • % Done changed from 70 to 100

Related to above discussion: no longer showing the individual context maps on VTY output, rather show overall counts, with

#9 Updated by neels 24 days ago

  • Assignee set to neels

#10 Updated by neels 11 days ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF