Cellular Network Infrastructure » Core Network (CN) » OsmoHNBGW

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...

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.

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...

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.

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!

https://gerrit.osmocom.org/5574
https://gerrit.osmocom.org/5575

Related to above discussion: no longer showing the individual context maps on VTY output, rather show overall counts, with https://gerrit.osmocom.org/5573