we previously mixed component specific and component agnostic APIs
(stdout vs. log file for example) for setting and retrieving KPI.
This patch propose to use a single abstract get_kpis() method for
all components that can be enriched with component-specific
stuff as desired.
In the case of srsLTE blocks, the main implementation will
remain in srslte_common() and is shared among srsENB/srsUE/srsEPC.
The KPI analyzer in srslte_common() extract and also manages
all three KPI sources (log, csv and stdout) independently.
In addition to the get_kpis() method that always returns a flat
dictionary, it also exposes get_kpi_tree() that return
a dict of KPI dicts that will be used for the Junit.xml generation.
Change-Id: I4bacc6b8a0cb92a581edfb947100b57022265265
implement as noop for Amarisoft eNB, srsENB will send q+Enter to stdin,
which is implemented in class srslte_common()
Change-Id: Ide606e1a6b523997215aa2fa39d4d56ae1f49181
this patch adds the stdout counter to count events happening
on the stdout (known from the UE already) to the common
process class so they can also be used from the eNB (and other objects)
In addition, we add a PRACH counter to be used for tests.
Change-Id: I434f072b8aa6f4dce9f90889c6b40832f6798ff8
it turned out that we have to reduce the MCS when using QAM256,
especially for 6 PRB as subframe 0 and 5 contains PBCH and PSS
signals, so the available REs are reduced.
The eNB scheduler now has this limitation in mind and lowers the MCS.
Change-Id: I0e38fe28002fd68c768cc8dcffcf74f4f190df02
this was causing failed tests because to achieve QAM64 rates both
eNB and UE need to support it and have it activated.
Change-Id: I599df92d69eeb56a5d44327de08f004222cff073
* add new UE feature
* enable in srsue.conf.templ
* add new table for maximum rates
* add config scenario to enable SIB option for QAM64
Change-Id: I6ac2c9989a761e91b93d76c2507f55f0140b202d
Due to the integration of DL-QAM256 another table for DL max rates is needed.
Therefore, I added the parameter 'qam256' to the feature list in the resource.cfg.
The patch also enables the correct UE settings in the config file.
Change-Id: I2d34395449cdcfb31db66ea887d9adbee551e757
srsENB currently creates 1 zmq stream (1 tx, 1 rx) for each cell (2 if
MIMO is enabled). Each cell transceives on a given EARFCN (and several
cells can transmit on same EARFCN).
However, for handover test purposes, we want to join all cells operating
on the same EARFCN to transceive on the same ZMQ conn, so that an srsUE
can interact with them at the same time (same as if the medium was shared).
Furthermore, we want to set different gains on each of those paths
before merging them in order to emulate RF conditions like handover.
In order to do so, a new element called the Broker is introduced, which
is placed in between ENBs and UEs ZMQ conenctions, multiplexing the
connections on the ENB side towards the UE side.
A separate process for the broker is run remotely (ENB run host) which
listens on a ctrl socket for commands. An internal Broker class is used
in osmo-gsm-tester to interact with the remote script, for instance to
configure the ports, start and stop the remote process, send commands to
it, etc.
On each ENB, when the rfemu "gnuradio_zmq" rfemu implementation is selected
in configuration, it will configure its zmq connections and the UE ones to
go over the Broker.
As a result, that means the UE zmq port configuration is expected to be
different than when no broker is in used, since there's the multiplexing
per EARFCN in between.
In this commit, only 1 ENB is supported, but multi-enb support is
planned in the future.
The handover test passes in the docker setup with this config:
"""
OSMO_GSM_TESTER_OPTS="-T -l dbg -s 4g:srsue-rftype@zmq+srsenb-rftype@zmq+" \
"mod-enb-nprb@6+mod-enb-ncells@2+mod-enb-cells-2ca+suite-4g@10,2+" \
"mod-enb-meas-enable -t =handover.py"
"""
and in resources.conf (or scenario), added:
"""
enb:
...
cell_list:
- dl_rfemu:
type: gnuradio_zmq
- dl_rfemu:
type: gnuradio_zmq
"""
Note that since the broker is used, there's not need for mod-srsue-ncarriers@2
since the broker is joining the 2 enb cells into 1 stream on the UE side.
Change-Id: I6282cda400558dcb356276786d91e6388524c5b1
pass-through the option so they can be used in templates
just concatenate with rf_dev_args for srsLTE eNB/UE, arguments
parsing will handle them
Change-Id: I3818026c159780f29968888f547163cdf730afad
we've added the modifier to configure Amarisoft eNB channel
model. This patch enables it for srsENB.
Change-Id: I30e65d0431b2d2792986128287caf8b23a22b2c1
this method uses the kpi_analyzer module for analyzing
stdout, CSV metrics and the logfile (if present).
if the module can't be loaded, no KPI will be added.
Change-Id: I28226a375f9ac4e08424c488062ae6a74a19af92
the overhead with 6 PRB and MIMO is a bit higher when compared
to other PRBs resulting in lower achievable throughput
Change-Id: I63888435553bba4f7be88cc745e24472921a7fb4
It turned out that the Amarisoft and SRS eNB scheduler produces
slightly different maximum data rates for both UL and DL.
Change-Id: I30fa7006906d101c53ba586fb06bced3945aa960
It is known that sometimes srsENB hangs until it is killed -9, specially
when using ZMQ backend. Let's use RemoteProcessSafeExit in order to make
sure it is killed in an acceptable time (srs binaries use some
preventive sigalarm 6 seconds auto-kill procedure, hence we use 7
seconds) before next test is started and potentially try to re-use the
same ENB and fails due to previous one still running.
Change-Id: I905bd753c7822feccf1c1bb59752698f1d1b85f0
This way we benefit from:
* knowing which attributes are used/required by each object class and
subclass
* Having validation function definitions near the class going to use them
Change-Id: I8fd6773c51d19405a585977af4ed72cad2b21db1
this patch moves the rf_dev_args creation for both eNB types
into the eNB base class, since they are identical.
the patch also fixes the arguments for all CA and MIMO configurations
Change-Id: I8ca3ed83e65dc07927385267e5970bc4f5b120d5
Two implementations are provided:
* Amarisoft Ctrl interface (websocket)
* Mini-Circuits Programmable Attenuator (HW, HTTP API) [1]
in Amarisoft ENBs, if no rfemu is configured explicitly, the Ctrl
interface one is used by default, while still being possible to use the
HW one.
[1] https://www.minicircuits.com/pdfs/RC4DAT-6G-60.pdf
Change-Id: Ie98a3fb9bcd2b87b96ecbb5b79e0f53981892a32