Project

General

Profile

Actions

Bug #1544

closed

PCU Benchmarking / Testing Setup

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)