Cellular Network Infrastructure » Core Network (CN) » OsmoSGSN

In 3GPP spec language, this is the 'network access mode (nam) gprs' flag of each subscriber, which is stored in the HLR.

Our new osmo-gsup-hlr database contains nam_cs / nam_ps columns for each subscriber, and if nam_ps is not set for a LU from a SGSN, then it is rejected with GMM_CAUSE_GPRS_NOTALLOWED.

• a method to change this flag in the HLR itself (see external interface to change the HLR #1592)
• a method to propagate if a change is made after a subscriber is already attached. I.e. the LU proceeds, as at LU time nam_ps == true. But then the flag is changed. We need to cancel (remove) the record from the SGSN, and the SGSN needs to handle that cancellation in a reasonable way.

How should external interface interact with hlr? Shall we add ctrl interface to hlr? Or shall external interface write to db directly?

Gerrit 1814, 1817, 1818, 1821, 1838, 1839, 1851, 1852, 1840 are merged; 1827, 1841, 185, 1856 are under review.

Shall nam_ps change via ctrl interface be synced to db or shall it be runtime only? If we don't do it than user can re-attach by simply going into flight mode and back.

Tested with
./bsc_control.py -d localhost -p 4259 -s enable-ps 001640000005666
./bsc_control.py -d localhost -p 4259 -s disable-ps 001640000005666

The latter causes "gprs" symbols to disappear from the phone. The former can be used to allow phone back when it tries again. Although there seems to be no obvious way to tell phone "come back and try gprs again - now it's allowed". The only sure way is to use flight mode to reconnect.

Here's how it looks like on SGSN side:

<000f> sgsn_libgtp.c:644 GTP DATA IND from GGSN, length=52
<000f> gprs_subscriber.c:668 SUBSCR Received GSUP message OSMO_GSUP_MSGT_DELETE_DATA_REQUEST
<0002> gprs_gmm.c:1007 MM Cancelled with cause 'GPRS services not allowed' (7), deleting context
<0002> gprs_gmm.c:986 MM Authorization lost, detaching with cause 'GPRS services not allowed' (7)
<0002> gprs_gmm.c:300 MM Cleaning MM context due to auth lost
<0002> gprs_sgsn.c:308 MM Dropping PDP context for NSAPI=5
<000f> gprs_sgsn.c:402 PDP Forcing release of PDP context
<000f> sgsn_libgtp.c:286 PDP Delete PDP Context
<000f> sgsn_libgtp.c:613 PDP Context was deleted
<000f> gprs_subscriber.c:728 SUBSCR purging MS subscriber
<000f> gprs_subscriber.c:174 SUBSCR Sending GSUP, will send: 0c 01 08 00 61 04 00 00 50 66 f6 09 00 28 01 01
<000f> gprs_subscriber.c:174 SUBSCR Sending GSUP, will send: 16 01 08 00 61 04 00 00 50 66 f6 28 01 01
<000f> sgsn_libgtp.c:590 libgtp cb_conf(type=20, cause=128, pdp=(nil), cbp=0x556df75e4bb0)
<000f> sgsn_libgtp.c:513 PDP Received DELETE PDP CTX CONF, cause=128(Request accepted)
<000f> sgsn_libgtp.c:537 PDP Not deactivating SNDCP layer since the MM context is not available
<000f> gprs_subscriber.c:522 GSUP Completing purge MS
<0013> gprs_sndcp.c:776 Message for non-existing SNDCP Entity (lle=0x556df75e8070, TLLI=f5af3cc3, SAPI=3, NSAPI=5)
<0013> gprs_sndcp.c:776 Message for non-existing SNDCP Entity (lle=0x556df75e8070, TLLI=f5af3cc3, SAPI=3, NSAPI=5)
<0013> gprs_sndcp.c:776 Message for non-existing SNDCP Entity (lle=0x556df75e8070, TLLI=f5af3cc3, SAPI=3, NSAPI=5)
<0013> gprs_sndcp.c:776 Message for non-existing SNDCP Entity (lle=0x556df75e8070, TLLI=f5af3cc3, SAPI=3, NSAPI=5)
<0013> gprs_sndcp.c:776 Message for non-existing SNDCP Entity (lle=0x556df75e8070, TLLI=f5af3cc3, SAPI=3, NSAPI=5)
<0013> gprs_sndcp.c:776 Message for non-existing SNDCP Entity (lle=0x556df75e8070, TLLI=f5af3cc3, SAPI=3, NSAPI=5)
<0013> gprs_sndcp.c:776 Message for non-existing SNDCP Entity (lle=0x556df75e8070, TLLI=f5af3cc3, SAPI=3, NSAPI=5)
<0002> gprs_gmm.c:1770 Cannot handle GMM for unknown MM CTX
<000f> gprs_sgsn.c:871 Checking for inactive LLMEs, time = 7632

Gerrit 1827 and 1841 are under review, the rest is merged.

Everything has been merged to master.