Bug #1544

PCU Benchmarking / Testing Setup

Added by laforge almost 3 years ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


Many aspects of GPRS/EDGE come down to the efficiency of algorithms. This includes
  • maximum throughput
    • with single user
    • with multiple defined number of users
    • uni-directional TCP (like HTTP GET) in downlink
    • uni-directional TCP (like SMTP DATA) in uplink
  • fairness of bandwidth distribution in UL and DL between subscribers
  • efficiency of rate/link adaption in changing environment
    • differing bit error rate
    • fading channels (multi-path)
    • changing timing advance (fast moving MS in train/car or the like)
  • timing advance loop
  • uplink and downlink power control loop
It is not yet clear which test cases cold be buil up with what amount of effort. Possible ideas include
  • regular scheduling of building up a test setup + executing tests with a fading channel simulator
  • artificially introducing simulated higher bit error rates, weak signals, etc. on the PCU-L1 interface or in the L1
  • using remote-controlled modems in an actual test installation with as separate BTS free of production traffic
  • building automatic test setup with antenna splitter/combiner and large number of GPRS modems
  • adding at least partial MS-side GPRS capabilities to OsmocomBB


#2 Updated by laforge over 2 years ago

  • Assignee set to neels

#3 Updated by laforge over 2 years ago

  • Priority changed from Normal to High

#4 Updated by neels over 2 years ago

My awareness level of this issue so far is very low.

#5 Updated by laforge over 2 years ago

  • Priority changed from High to Normal

#6 Updated by neels about 2 years ago

  • Assignee changed from neels to Osmocom Developers

#7 Updated by laforge almost 2 years ago

  • Assignee changed from Osmocom Developers to neels

assigning this to neels, but feel free to use lynxis' experience and know-how regarding the modems and using their data capabilities.

I think the very basic first step is to have support for data testing at all, which in the presence of multiple modems means that this entire test case will have to be run in a network namespace to ensure that there are no routing issues when having dozens of PDP contexts (at least one over each modem) to the same GGSN and wanting to run test programs like a simple ping over one of them.

#8 Updated by neels almost 2 years ago

  • Project changed from OsmoPCU to OsmoGSMTester
  • Assignee changed from neels to Osmocom Developers

we first need to add basic data service on the osmo-gsm-tester

#9 Updated by laforge over 1 year ago

  • Assignee changed from Osmocom Developers to sysmocom

#10 Updated by pespin 3 months ago

  • Assignee changed from sysmocom to pespin

#11 Updated by pespin 3 months ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Closing this issue as initial support for data transfer is already in place and several scenarios are being tested.

This task is now too generic; new specific tests can be added in separate tasks.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)