Cellular Network Infrastructure » Core Network (CN) » OsmoHLR

Last activity timestamp is critically important for commercial networks who need to recycle SIM cards or phone numbers. This recycling is normally performed based on the inactivity time which requires activity timestamps to be stored. E.g. that's the case for the network we're currently installing in Palau where there is a significant customer churn due to tourists, while numbering capacity is very limited.

Initial patch proposed here: https://gerrit.osmocom.org/#/c/osmo-hlr/+/12121

Above patch has been merged.
The HLR DB now stores a timestamp of the last location update recoded in the DB.

This timestamp can already be viewed with sqlite:

sqlite> select imsi,last_lu_seen from subscriber;
901990000000001|2018-12-04 14:17:12

I will prepare a patch to display the timestamp somewhere in the VTY as well.

ipse, is there anything else that needs to be done in order to meet your use case?

See https://gerrit.osmocom.org/#/c/osmo-hlr/+/12202 for a patch which adds VTY support.

I am wondering if there should be an option to toggle use of this feature.
While storing the timestamp will be useful for some users, other users may have privacy concerns.

Should we make this feature optional? If so, I think it should be left disabled by default.
The last_lu_seen column would simply not be populated while this feature is disabled; code making
use of this column has already been written under the assumption that this column may be empty.

laforge wrote:

On Fri, Dec 07, 2018 at 03:09:00PM +0000, stsp [REDMINE] wrote:

I am wondering if there should be an option to toggle use of this feature.
[...]
Should we make this feature optional?

No, it is a mandatory feature of a HLR as per 3GPP specs, as far as I know. Also,
every time we make something optional, we grow our configuration complexity matrix,
and over time some features will likely never be tested with either of the two
settings, causing hidden bugs, ...

I understand your concerns about the test matrix. This can quickly become a real burden.

Regarding 3GPP specs: I believe we should not simply defer decisions which potentially impact the privacy of phone network users to a spec. We want to follow the specs specifically because we want to interoperate with devices made by other vendors. We should not be looking to the spec for guidance with respect to ethical questions regarding our implementation. This responsibility is strictly our own.

So I would instead ask the ethical question: Should a permanent record of personal data be created by default in a phone network which runs the Osmocom stack?

I believe the ethical answer is that such data gathering should be opt-in. In which case operators who enable this feature will carry the responsibility of handling the data properly. As a developer I don't want to be responsible for forcing this decision onto every direct or indirect user of an Osmocom HLR.
If this feature is opt-out then the operator might even be unaware that such data is being recorded, which leaves the data at risk of being exposed accidentally.

This proposed patch disables the feature by default: https://gerrit.osmocom.org/c/osmo-hlr/+/12228
My main motivation for making this proposal are the privacy concerns outlined above.

I don't think test coverage will become a problem in this particular case.
The existing DB unit tests will exercise the timestamp recording code path during 'make check'.

Above patch has been rejected.

I don't see what else can be done for this task. Closing this issue.