Project

General

Profile

Actions

Bug #1544

closed

PCU Benchmarking / Testing Setup

Added by laforge about 8 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

100%

Spec Reference:

Description

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
Actions #2

Updated by laforge almost 8 years ago

  • Assignee set to neels
Actions #3

Updated by laforge almost 8 years ago

  • Priority changed from Normal to High
Actions #4

Updated by neels over 7 years ago

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

Actions #5

Updated by laforge over 7 years ago

  • Priority changed from High to Normal
Actions #6

Updated by neels about 7 years ago

  • Assignee changed from neels to 118
Actions #7

Updated by laforge almost 7 years ago

  • Assignee changed from 118 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.

Actions #8

Updated by neels almost 7 years ago

  • Project changed from OsmoPCU to OsmoGSMTester
  • Assignee changed from neels to 118

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

Actions #9

Updated by laforge almost 7 years ago

  • Assignee changed from 118 to 4368
Actions #10

Updated by pespin over 5 years ago

  • Assignee changed from 4368 to pespin
Actions #11

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

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)