Project

General

Profile

Feature #1543

link/rate adaption as per spec

Added by laforge almost 2 years ago. Updated over 1 year ago.

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

0%

Estimated time:
24.00 h
Spec Reference:

Description

Even for GPRS only, our downlink link/rate adaption currently is only based on the error rate in terms of how many lost RLC packets / bytes we see from that MS. This method works well but is not conforming to a certain standard.

As per the GPRS spec, it should be based on bit error rate, expressed as link quality measurements, as it is done in the uplink direction.

What needs to be done
  • the above metrics first need to be computed/generated as per spec and then passed into a decision making algorithm.
  • that algorithm should be modular so that we can experiment (and switch at runtime) future different algorithms to compare them against each other.
  • unit tests for metrics + inital algorithm

Also, it is a question whether we should keep all the above separate for uplink and downlink, resulting in possibly diffeent CS based on the direction.

Finally, the question is how to test this properly, in a way that can be automatized and become part of a continuous integration setup.


Related issues

Related to OsmoBTS - Bug #1616: osmo-bts-trx / osmo-bts-octphy doesn't provide C/I information to PCU Stalled 02/23/2016
Related to OsmoPCU - Feature #1536: Implement adaptive CS selection New 02/22/2016

History

#2 Updated by laforge over 1 year ago

  • Assignee set to neels

#3 Updated by neels over 1 year ago

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

#4 Updated by laforge over 1 year ago

  • Related to Bug #1616: osmo-bts-trx / osmo-bts-octphy doesn't provide C/I information to PCU added

#5 Updated by msuraev over 1 year ago

  • Related to Feature #1536: Implement adaptive CS selection added

#6 Updated by laforge over 1 year ago

  • Assignee changed from neels to msuraev

Also available in: Atom PDF