An error occurred fetching the project authors.
- 08 Mar, 2023 2 commits
-
-
Kirill Smelkov authored
This patch provides next building block for E-UTRAN IP Throughput KPI and continues d102ffaa (drb: Start of the package) 5bf7dc1c (amari.{drb,xlog}: Provide aggregated DRB statistics in the form of synthetic x.drb_stats message) Quoting those patches The scheme to compute E-UTRAN IP Throughput is thus as follows: poll eNB at 100Hz frequency for `ue_get[stats]` and retrieve information about per-UE/QCI streams and the number of transport blocks dl/ul-ed to the UE in question during that 10ms frame. Estimate `tx_time` taking into account the number of transmitted transport blocks. And estimate whether eNB is congested or not based on `dl_use_avg`/`ul_use_avg` taken from `stats`. For the latter we also need to poll for `stats` at 100Hz frequency and synchronize `ue_get[stats]` and `stats` requests in time so that they both cover the same time interval of particular frame. Then organize the polling process to provide aggregated statistics in the form of new `x.drb_stats` message, and teach `xamari xlog` to save that messages to `enb.xlog` together with `stats`. Then further adjust `amari.kpi.LogMeasure` <-- NOTE and generic `kpi.Measurement` and `kpi.Calc` to handle DRB-related data. So here we implement the noted step: We teach LogMeasure to take x.drb_stats messages into account and update IP Throughput related fields in appropriate Measurement from x.drb_stats data. This process is relatively straightforward besides one place: for stable output E-UTRAN IP Throughput is required to be computed without taking into account last TTI of every sample. We don't have that level of details since all we have is total amount of transmitted bytes in a burst and estimation of how long in time the burst is. Thus we can only provide an estimation for the E-UTRAN IP Throughput as follows: DRB.IPVol and DRB.IPTime are collected to compute throughput. thp = ΣB*/ΣT* where B* is tx'ed bytes in the sample without taking last tti into account and T* is time of tx also without taking that sample's tail tti. we only know ΣB (whole amount of tx), ΣT and ΣT* with some error. -> thp can be estimated to be inside the following interval: ΣB ΣB ───── ≤ thp ≤ ───── (1) ΣT_hi ΣT*_lo the upper layer in xlte.kpi will use the following formula for final throughput calculation: DRB.IPVol thp = ────────── (2) DRB.IPTime -> set DRB.IPTime and its error to mean and δ of ΣT_hi and ΣT*_lo so that (2) becomes (1). for this to work we also need to introduce new fields to Measurement that represent error of DRB.IPTime. The hope is that introduction is temporary and should be removed once we rework DRB stats to provide B* and T* directly.
-
Kirill Smelkov authored
We added LogMeasure in 71087f67 (amari.kpi: New package with driver for Amarisoft LTE stack to retrieve KPI-related measurements from logs) and its original logic is to read `stats` messages and to create Measurement that covers [Sx, Sx+1) only after seeing Sx+1. However in the next patch we will need to also take into account other smaller messages besides stats, and for that messages we need being-prepared Measurement to already exist to be able to amend it with partial data we see. So we need to rework the process to create Measurement that will cover [Sx, Sx+1) right after seeing Sx without waiting for Sx+1 to come in. This patch does that. Along the way it unifies how events and stats are handled. Previously events and stats were handled via different objects and the code had many scattered places that tried to handle cases like event-event, event-stats, stats-event and stats-stats. And for all those cases the intent was that we still want to emit corresponding Measurement for all of them, even if maybe if all NA data besides timestamps. Thus it does not make sense to split events and stats into different flows - as we can handle all combinations by considering just one flow of "stats or events". This simplifies logic and removes several sporadic branches of code to emit M(ø) around events. It also discovers several places where we were not emitting such M(ø) even though the intent was to do so. All this is fixed now with updated tests.
-
- 12 Dec, 2022 1 commit
-
-
Kirill Smelkov authored
amari.kpi: New package with driver for Amarisoft LTE stack to retrieve KPI-related measurements from logs amari.kpi provides LogMeasure that takes enb.xlog (TODO and enb.log) as input, and produces kpi.Measurements on output. enb.xlog ───────── ─────────> │ Log │ │ │ ────> []kpi.Measurement ─────────> │ Measure │ enb.log ───────── We read log data organizing periods around stats queries, and for now we build Measurement from stats' counters. To do so we take δ(stats_prev, stat) and process it mapping Amarisoft counters to 3GPP ones specified by kpi.Measurement. We emit measurement X after reading stats X+2 - i.e. we emit measurement for a period after reading data covering _next_ period. It is organized this way to account for init/fini correction: fini adjust ------------- ' ' Sx v Sx+1 ' Sx+2 ────|───────────|───────────|──── Measurement Measurement X X+1 This approach has following limitations: - for most of the counters there is no direct mapping in between Amarisoft and 3GPP. For example we currently use s1_erab_setup_request for ERAB.EstabAddAtt.sum, but this mapping is not strictly correct and will break if corresponding S1 E-RAB SETUP REQUEST message contains multiple ERABs. The code has corresponding FIXME marks where such approximations are used. - it is not possible to implement init/fini correction precisely. From aggregated statistics we only get total amount for a fini value for a period - without knowing which part of it corresponds to init events from previous period, and which part to init events from current one. With that it is only possible to make a reasonable guess and try to preserve statistical properties, but not more. See m_initfini in the code for details. - it is possible to handle eNB with single cell only. This limitation comes from the fact that in Amarisoft LTE stack S1-related counters come as "globals" ones, while e.g. RRC-related counters are "per-cell". It is thus not possible to see how much S1 connection establishments are associated with one particular cell if there are several of them. TODO also parse enb.log to fix those issues.
-