Project

General

Profile

Feature #4761

ttcn3-pcu: Add test verifying behavior upon GPRS Suspension Request received from MS through PCUIF

Added by pespin 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
09/22/2020
Due date:
% Done:

0%

Spec Reference:

Description

That message is sent during when the MS has some TBF active and has to move back to CS (eg due to establishing an MO call, being paged or sending an SMS).

When the MS moves to CS, it requests an SDCCH to send the GPRS Suspension Request, which will be sent BTS->PCU through PCUIF (see osmo-pcu pcu_rx_susp_req).

The test should validate:
  • A BSSGP SUSPEND is sent towards SGSN (and SUSPEND ACK is sent abck by it)
  • All active TBFs are released (so for instance if some DL data is queued in PCU waiting to be sent to the MS, it is dropped after receiving the Suspend Request message).
Some reference:
  • osmo-pcu.git 3447c4a8a41ad97ec91045fdfd9f4ce91e450e47
  • 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15
  • #2249

Related issues

Related to OsmoBSC - Bug #2249: RR GPRS suspension request is not forwarded to the GMM/SGSNResolved05/09/2017

History

#1 Updated by pespin 2 months ago

  • Tracker changed from Bug to Feature

#2 Updated by pespin 2 months ago

  • Related to Bug #2249: RR GPRS suspension request is not forwarded to the GMM/SGSN added

#3 Updated by pespin 2 months ago

Freeing the TBFs (so queued dat ais not continued to be sent) can be found here:
https://gerrit.osmocom.org/c/osmo-pcu/+/20245 Free all MS TBFs when receiving GPRS Suspension Request

#4 Updated by pespin 2 months ago

So far I have been testing this locally by having 2 phones registered to a network and then doing an MO_MT call, and it's working fine.

#5 Updated by fixeria 2 months ago

Hi Pau,

The test should validate:
  • A BSSGP SUSPEND is sent towards SGSN (and SUSPEND ACK is sent abck by it)

we already have TC_pcuif_suspend verifying this.

  • All active TBFs are released (so for instance if some DL data is queued in PCU waiting to be sent to the MS, it is dropped after receiving the Suspend Request message).

Feel free to add a new test case for that, but let's please keep TC_pcuif_suspend unchanged. The question is how would you check if TBFs are actually released? Probably, VTY interface is the only reliable variant, but we can additionally check the counters.

#6 Updated by pespin 2 months ago

It's easy:
1- Request UL TBF to PCU, get it and start sending UL rlcmac blocks
2- Send several RLCMAC DL blocks from SGSN, they are queued in osmo-pcu
3- PCUIF sends GPRS Suspension Request
4- Make sure no new data is received at PCUIF (because it's not scheduled because TBF was released). Try sending some data over PCUIF and check no data is received at SGSN (because there's no active TBF).

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)