Bug #1544
closed
PCU Benchmarking / Testing Setup
Added by laforge about 8 years ago.
Updated over 5 years ago.
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
- Priority changed from Normal to High
My awareness level of this issue so far is very low.
- Priority changed from High to Normal
- Assignee changed from neels to 118
- 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.
- 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
- Assignee changed from 118 to 4368
- Assignee changed from 4368 to pespin
- 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
