Project

General

Profile

Actions

Bug #2249

closed

RR GPRS suspension request is not forwarded to the GMM/SGSN

Added by lynxis almost 7 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
05/09/2017
Due date:
% Done:

100%

Spec Reference:

Description

using a sysmobts:
- a MS can send a GPRS suspension request to the network to notify it is unavailable for some time
(e.g. if sending/receiving a SMS).

This request isn't yet forwarded to the SGSN.


Files


Related issues

Related to OsmoSGSN - Bug #4616: osmo-sgsn PS paging an MS on each DL ip packet received for itResolvedpespin06/16/2020

Actions
Related to OsmoPCU - Feature #4761: ttcn3-pcu: Add test verifying behavior upon GPRS Suspension Request received from MS through PCUIFClosedpespin09/22/2020

Actions
Actions #1

Updated by laforge over 6 years ago

well, this is not really a bug.

GPRS has multiple "Network Mode of Operation", NMO I, NMO II and NMO III. As we don't have an (optional!) Gs interface between SGSN and VLR, there is no coordination between the Cs and Ps domain. We also don't support DTM (Dual Transfer Mode).

As such, it is surprising to me why a MS will send a "GPRS SUSPEND" over the DCCH to the CS side of the network at all.

Unfortunately, TS 03.60 Chapter 16.2.1 is rather unclear about the suspend/resume details.

The MS sends an RR Suspend (TLLI, RAI) message to the BSS. The BSS may terminate any ongoing GPRS traffic for this TLLI.

this doesn't specify over which logical channel (PDTCH or DCCH) this is sent to "the BSS" at all.

The BSS sends a Suspend (TLLI, RAI) message to the SGSN

is equally vague, as the Cs-side of the BSS (BTS, BSC) have no connection to the SGSN at all. Only the PCU does, and the PCU has no relation to DCCH on the Cs side.

So I suspect that we somehow
a) we are sending something wrong in our SI that makes MSs believe that we support some kind of NMO-I or DTM related functionality, or
b) some MS send GPRS SUSPEND over DCCH even though the network nowhere indicated such functionality

Actions #2

Updated by laforge over 6 years ago

https://image.slidesharecdn.com/chap09physrlc03kh-130222002219-phpapp02/95/chap09-phys-rlc03-kh-22-638.jpg?cb=1361492647 seems to indicate that "Class B" mobile phones always send a GPRS suspend request via (S)DCCH if they are entering circuit switched services while previously being in a TBF on the Ps side of things.

Relevant spec references:
  • TS 03.60 Section 16.2.1
  • TS 44.018 Section 3.4.15 GPRS suspension procedure

The optional Gs interface between BSC and SGSN does not support any signalling of GPRS SUSPEND.

So I think in order to support this, we indeed would need to filter such messages inside OsmoBTS, and pass them over the PCU socket into OsmoPCU. Inside the PCU, we then can forward them via BSSGP as if we had received a suspend request over the P*TCH.

Actions #3

Updated by laforge over 6 years ago

Actions #4

Updated by laforge over 6 years ago

  • Status changed from New to In Progress
  • Assignee set to laforge
  • % Done changed from 0 to 50

Implemented in laforge/gprs-suspend branches of osmo-bts and osmo-pcu, remains to be tested.

The inverse operation (GPRS Resume via the GPRS Resumption IE of the RR CHANNEL RELEASE) is entirely optional, so we should get away with not implementing it.

Actions #5

Updated by laforge about 6 years ago

  • Status changed from In Progress to New
Actions #6

Updated by laforge over 5 years ago

  • Assignee changed from laforge to osmith
Actions #7

Updated by osmith about 5 years ago

  • Status changed from New to Stalled

Implemented in laforge/gprs-suspend branches of osmo-bts and osmo-pcu, remains to be tested.

I have rebased the osmo-bts branch and force-pushed it. But the osmo-pcu branch does not exist anymore, can you push it again laforge? (It doesn't seem to be merged, at least osmo-pcu.git does not mention this issue in "git log".)

Actions #8

Updated by laforge about 5 years ago

On Fri, Mar 08, 2019 at 04:54:54PM +0000, wrote:

[OsmoBSC - Bug #2249] RR GPRS suspension request is not forwarded to the GMM/SGSN
https://osmocom.org/issues/2249

You were mentioned by osmith on 2019-03-08 16:54:54

Implemented in laforge/gprs-suspend branches of osmo-bts and osmo-pcu, remains to be tested.

I have rebased the osmo-bts branch and force-pushed it. But the osmo-pcu branch does not exist anymore, can you push it again laforge? (It doesn't seem to be merged, at least osmo-pcu.git does not mention this issue in "git log".)

Erm, the branch very well still exists on the server. I just wanted to push (a probably rebased version)

git push gerrit laforge/gprs-suspend

To ssh://gerrit.osmocom.org:29418/osmo-pcu.git
! [rejected] laforge/gprs-suspend -> laforge/gprs-suspend (non-fast-forward)
error: failed to push some refs to 'ssh::29418/osmo-pcu.git'

Actions #9

Updated by osmith about 5 years ago

You are right, the branch exists indeed (a simple checkout said that the pathspec doesn't exist for some reason, but git checkout -b laforge/gprs-suspend origin/laforge/gprs-suspend worked).

Actions #10

Updated by osmith almost 5 years ago

Implemented in laforge/gprs-suspend branches of osmo-bts and osmo-pcu, remains to be tested.

I've compiled latest master for sysmoBTS 1002 and tested sending SMS with a smartphone, with and without the patches and searched for the GPRS suspension message in the wireshark gsmtap_log. And I can confirm that the patches work! See attached wireshark screenshot.

Submitted to gerrit:

Besides rebasing, the only changes I've made are fixing a missing include and a typo (osmo-bts.git):

diff --git a/src/common/rsl.c b/src/common/rsl.c
index 6f193ebb..cac4abda 100644
--- a/src/common/rsl.c
+++ b/src/common/rsl.c
@@ -29,6 +29,7 @@
 #include <sys/types.h>
 #include <arpa/inet.h>

+#include <osmocom/core/byteswap.h>
 #include <osmocom/core/msgb.h>
 #include <osmocom/core/talloc.h>
 #include <osmocom/gsm/rsl.h>
@@ -2632,7 +2633,7 @@ static int handle_gprs_susp_req(struct msgb *msg)
        }

        gsr = (struct gsm48_gprs_susp_req *) gh->data;
-       tlli = osmo_htnol(gsr->tlli);
+       tlli = osmo_htonl(gsr->tlli);

        LOGP(DRSL, LOGL_INFO, "%s Fwd GPRS SUSPEND REQ for TLLI=0x%08x to PCU\n",
                gsm_lchan_name(msg->lchan), tlli);

Actions #11

Updated by laforge almost 5 years ago

  • Status changed from Stalled to Resolved
  • % Done changed from 90 to 100

patches have been merged. For the BTS side, there's now a patch in PCU_Tests_RAW.ttcn, see https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13383/

Actions #12

Updated by laforge almost 5 years ago

See https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14192 for a test of the BTS side.

It also seems that the BTS implementation was broken: It forwarded RR SUSP REQ which were sent as unacknowledgd UNITDATA, but not those over regular acknowledged mode. AFAIK, the spc implicitly requires the use of acknowledged mode - like for everything else unless it explicitly states unacknowledged mode (measurement report, VGC/VBCS related stuff). Fix see https://gerrit.osmocom.org/#/c/osmo-bts/+/14193

Actions #13

Updated by laforge almost 4 years ago

  • Related to Bug #4616: osmo-sgsn PS paging an MS on each DL ip packet received for it added
Actions #14

Updated by pespin over 3 years ago

  • Related to Feature #4761: ttcn3-pcu: Add test verifying behavior upon GPRS Suspension Request received from MS through PCUIF added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)