Project

General

Profile

Actions

Feature #2838

closed

HLR doesn't store timestamps e.g. of last subscriber activity

Added by laforge about 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Start date:
01/18/2018
Due date:
% Done:

0%

Spec Reference:

Description

It would be useful for monitoring etc. if we had a 'last active at' timestamp or the like.

Actions #1

Updated by laforge about 6 years ago

  • Target version set to Event Operation
Actions #2

Updated by ipse about 6 years ago

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.

Actions #3

Updated by laforge almost 6 years ago

  • Assignee set to stsp
  • Priority changed from Normal to Low
Actions #4

Updated by laforge over 5 years ago

Actions #5

Updated by stsp over 5 years ago

  • Status changed from New to In Progress
Actions #6

Updated by stsp over 5 years ago

Actions #7

Updated by stsp over 5 years ago

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?

Actions #8

Updated by stsp over 5 years ago

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

Actions #9

Updated by stsp over 5 years ago

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.

Actions #10

Updated by laforge over 5 years ago

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

Actions #11

Updated by stsp over 5 years ago

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.

Actions #12

Updated by stsp over 5 years ago

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

Actions #13

Updated by stsp over 5 years ago

  • Status changed from In Progress to Resolved

Above patch has been rejected.

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

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)