Project

General

Profile

Actions

Feature #4761

closed

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

Added by pespin over 3 years ago. Updated about 3 years ago.

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

100%

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/SGSNResolvedosmith05/09/2017

Actions
Actions #1

Updated by pespin over 3 years ago

  • Tracker changed from Bug to Feature
Actions #2

Updated by pespin over 3 years ago

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

Updated by pespin over 3 years 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

Actions #4

Updated by pespin over 3 years 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.

Actions #5

Updated by fixeria over 3 years 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.

Actions #6

Updated by pespin over 3 years 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).

Actions #7

Updated by pespin about 3 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 90

Test makin sure TBF is released has been added (passing) here:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/22100 pcu: Introduce test TC_pcuif_suspend_active_tbf

Once merged we can close the ticket.

Actions #8

Updated by pespin about 3 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

merged, closing.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)