PCU Benchmarking / Testing Setup
- 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
- 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
Updated by laforge over 4 years ago
- Assignee changed from Osmocom CNI 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.
Updated by pespin almost 3 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.