Feature #1645
closedmechanism for enabling/disabling GPRS on per-user basis
Added by laforge about 8 years ago. Updated almost 7 years ago.
100%
Description
We need a way how GPRS services can be enabled/disabled on a per-subscriber basis.
Most likely the application-side interface will be towards the upcoming external HLR, which then would need to communicate this to OsmoSGSN, who in turn would have (in case of disabling the user) would have to release any PDP contexts that may exist, both towards subscriber as well as towards GGSN.
Checklist
- external interface to change nam_ps flag from outside HLR
- propagate nam_ps changes to SGSN (cancel subscriber)
Related issues
Updated by laforge about 8 years ago
- Related to Feature #1592: VLR in libmsc, to connect to HLR asynchronously added
Updated by laforge about 8 years ago
- Related to Feature #1643: programmatic access to new asynchronous external HLR added
Updated by laforge almost 8 years ago
- Checklist item external interface to change nam_ps flag from outside HLR added
- Checklist item propagate nam_ps changes to SGSN (cancel subscriber) added
- % Done changed from 0 to 30
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.
What we still need though is- 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.
Updated by msuraev about 7 years ago
How should external interface interact with hlr? Shall we add ctrl interface to hlr? Or shall external interface write to db directly?
Updated by laforge about 7 years ago
On Mon, Feb 13, 2017 at 05:33:02PM +0000, msuraev [REDMINE] wrote:
How should external interface interact with hlr? Shall we add ctrl
interface to hlr? Or shall external interface write to db directly?
this is not clear yet at this point. I see the osmo-gsup-hlr more as a
proof-of-concept implementation at this point, more or less expecting
people with specific requirements to implement GSUP themselves or using
a GSUP-to-MAP translator.
For the context of this ticket it is important to make sure that the
SGSN supports this from the GSUP side, and that somehow it can be
triggered/tested somehow. Control Interface might be a sufficient
approach for now.
Updated by msuraev about 7 years ago
Gerrit 1814, 1817, 1818, 1821, 1838, 1839, 1851, 1852, 1840 are merged; 1827, 1841, 185, 1856 are under review.
Updated by msuraev about 7 years ago
- Status changed from In Progress to Stalled
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.
Updated by msuraev about 7 years ago
- % Done changed from 30 to 50
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.
Updated by laforge about 7 years ago
Hi Max,
On Thu, Feb 16, 2017 at 09:50:03AM +0000, msuraev [REDMINE] wrote:
Shall nam_ps change via ctrl interface be synced to db or shall it be runtime only?
synced to db!
Updated by laforge about 7 years ago
On Thu, Feb 16, 2017 at 12:47:37PM +0000, msuraev [REDMINE] wrote:
Tested with
./bsc_control.py -d localhost -p 4259 -s enable-ps 001640000005666
./bsc_control.py -d localhost -p 4259 -s disable-ps 001640000005666
great!
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".
Well, there's nothing you can do about that, this is normal as there is
no such feature in the GSM/GPRS specifications. We cannot implement
what is not possible :)
Updated by msuraev about 7 years ago
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
Updated by msuraev about 7 years ago
- Checklist item propagate nam_ps changes to SGSN (cancel subscriber) set to Done
Updated by msuraev about 7 years ago
- % Done changed from 50 to 60
Gerrit 1827 and 1841 are under review, the rest is merged.
Updated by msuraev about 7 years ago
- Checklist item external interface to change nam_ps flag from outside HLR set to Done
- Status changed from Stalled to Resolved
- % Done changed from 60 to 100
Everything has been merged to master.
