Bug #1544

PCU Benchmarking / Testing Setup

Added by laforge about 2 years ago. Updated 11 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 almost 2 years ago

  • Assignee set to neels

#3 Updated by laforge almost 2 years ago

  • Priority changed from Normal to High

#4 Updated by neels almost 2 years ago

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

#5 Updated by laforge over 1 year ago

  • Priority changed from High to Normal

#6 Updated by neels about 1 year ago

  • Assignee changed from neels to Osmocom Developers

#7 Updated by laforge 12 months 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 11 months 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 11 months ago

  • Assignee changed from Osmocom Developers to sysmocom

Also available in: Atom PDF