Project

General

Profile

Bug #2249

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

Added by lynxis about 4 years ago. Updated almost 2 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.


Related issues

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

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

Associated revisions

Revision 41723e15 (diff)
Added by laforge about 2 years ago

Forward GPRS SUSPEND REQ from DCCH to PCU socket

As specified in 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15,
a Class B MS is sending a "RR GPRS SUSPEND REQ" via a DCCH to the BTS if
it wants to suspend GPRS services. The BSS is now responsible to
somehow forward this to the SGSN. As the Gs interface between BSC and
SGSN is both optional and doesn't have any provision to forward this
message, we have to send it over to the PCU so it can use regular BSSGP
signaling to inform the SGSN of the SUSPEND REQUEST.

This patch requires libosmocore Change-Id
I90113044460a6c511ced14f588876c4280d1cac7 for the related definition of
struct gsm48_gprs_susp_req.

Change-Id: I3c1af662c8f0d3d22da200638480f6ef05c3ed1f
Closes: OS#2249

Revision 9ef6fa07 (diff)
Added by laforge almost 2 years ago

Fix passing of RR SUSPEND REQ from DCCH to PCU socket

The existing code ssumed that the RR SUSPEND REQ would be a
LAPDm/RSL unitdata request. I couldn't find any spec reference
that would support this. Rather, the message is sent via the normal
main dedicated channel, which is operated in ABM mode.

As the somewhat similar check for diverting measurement results
is in fact looking for UNITDATA, we have to untangle this slightly.

Change-Id: Ic75486f8edaefa9c07bd92515ba1832b1c482fa6
Related: OS#2249
Related: OS#4023

History

#1 Updated by laforge almost 4 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

#2 Updated by laforge almost 4 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.

#3 Updated by laforge almost 4 years ago

#4 Updated by laforge almost 4 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.

#5 Updated by laforge over 3 years ago

  • Status changed from In Progress to New

#6 Updated by laforge over 2 years ago

  • Assignee changed from laforge to osmith

#7 Updated by osmith about 2 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".)

#8 Updated by laforge about 2 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'

#9 Updated by osmith about 2 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).

#10 Updated by osmith about 2 years ago

3606

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);

#11 Updated by laforge about 2 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/

#12 Updated by laforge almost 2 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

#13 Updated by laforge 11 months ago

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

#14 Updated by pespin 8 months ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)