Project

General

Profile

Feature #1645

mechanism for enabling/disabling GPRS on per-user basis

Added by laforge over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
03/11/2016
Due date:
% Done:

100%

Spec Reference:

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.


Related issues

Related to OsmoNITB - Feature #1592: VLR in libmsc, to connect to HLR asynchronouslyClosed2016-02-23

Related to OsmoHLR - Feature #1643: programmatic access to new asynchronous external HLRNew2016-03-11

History

#1 Updated by laforge over 2 years ago

  • Related to Feature #1592: VLR in libmsc, to connect to HLR asynchronously added

#2 Updated by laforge over 2 years ago

  • Related to Feature #1643: programmatic access to new asynchronous external HLR added

#3 Updated by laforge over 2 years ago

  • Status changed from New to In Progress

#4 Updated by laforge over 2 years ago

  • Assignee set to laforge

#5 Updated by laforge over 2 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.

#6 Updated by laforge almost 2 years ago

  • Priority changed from Normal to Urgent

#7 Updated by laforge over 1 year ago

  • Assignee changed from laforge to msuraev

#8 Updated by msuraev over 1 year ago

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

#9 Updated by laforge over 1 year 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.

#10 Updated by msuraev over 1 year ago

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

#11 Updated by msuraev over 1 year 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.

#12 Updated by msuraev over 1 year 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.

#13 Updated by laforge over 1 year 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!

#14 Updated by laforge over 1 year 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 :)

#15 Updated by msuraev over 1 year 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

#16 Updated by msuraev over 1 year ago

  • Checklist item propagate nam_ps changes to SGSN (cancel subscriber) set to Done

#17 Updated by msuraev over 1 year ago

  • % Done changed from 50 to 60

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

#18 Updated by msuraev over 1 year 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.

#19 Updated by laforge over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)