Bug #2249
closedRR GPRS suspension request is not forwarded to the GMM/SGSN
100%
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
Updated by laforge almost 7 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
Updated by laforge almost 7 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.
Updated by laforge almost 7 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.
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".)
Updated by laforge about 5 years ago
On Fri, Mar 08, 2019 at 04:54:54PM +0000, redmine@lists.osmocom.org wrote:
[OsmoBSC - Bug #2249] RR GPRS suspension request is not forwarded to the GMM/SGSN
https://osmocom.org/issues/2249You 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://laforge@gerrit.osmocom.org:29418/osmo-pcu.git'
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).
Updated by osmith about 5 years ago
- File 2019-03-20-160655_1916x1041_scrot.png 2019-03-20-160655_1916x1041_scrot.png added
- % Done changed from 50 to 90
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);
Updated by laforge about 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/
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
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
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