Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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

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.

• 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.

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.

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".)

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

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.

• https://gerrit.osmocom.org/#/c/osmo-pcu/+/3384
• https://gerrit.osmocom.org/#/c/osmo-bts/+/13347

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

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/

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