RR GPRS suspension request is not forwarded to the GMM/SGSN
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.
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.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.
- Status changed from New to In Progress
- Assignee set to laforge
- % Done changed from 0 to 50
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.