Via VTY, handover two lchans of a voice call from bts0 to bts1 and back.
New scenarios/bts1-* allow selecting various types for bts1,
complementing the already existing files for selecting bts0.
Change-Id: I0b2671304165a1aaae2b386af46fbd8b098e3bd8
Remove ARFCNs as a concept from resource pool, assign a fixed ARFCN to
each BTS and TRX in the resource pools.
Using ARFCNs on specific bands as resources was an idea that is hard to
implement, because specific BTS dictate selection of bands which
influences which ARFCNs can be picked. That means reserving ARFCN
resources is only possible after reserving specific BTS resources, but
the tester is currently not capable of such two-stage resolution.
Writing handover tests, I got the problem that both BTS in a scenario
attempt to use the same ARFCN.
The by far easiest solution is to assign one fixed ARFCN to each BTS and
TRX. If ever needed, a scenario modifier can still configure different
ARFCNs.
(Due to uncertainty about OC2G operation stability, I prefer to leave
OC2G on ARFCN 50, as it happened to end up being configured before this
patch.)
Change-Id: I0a6c60544226f4261f9106013478d6a27fc39f38
Doing only the first two modems so far because I need them for handover
runs. The other modems are still todo!
Change-Id: Ibd71acfc76c01ffd105abe5effc1d246b1e65f85
this patch fixes some regressions in the Amarisoft UE class,
the config template, etc. that have been undetected bc we never
executed tests with it.
Change-Id: I397e675a4018acf3372a3b7e29fd864703b2b919
* 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
the default params are set for a single cell in defaults.conf
but this 2 cell config requires them to be set explicitly.
Change-Id: I8b3c486eb3e42aeb04b6a7548d3f0de2aa40ee0c
change pass threshold to 80% of the max rate for
half of the testduration (rolling average).
the overall average might be lowered because of a slower
TCP start or a late UE attach.
Change-Id: I8a545b8175784e9d6b49d6bf80f637ef7aa731f7
make sure to insert cell specific TAC, PCI and root seq ind
into cell config and do not depend on cell index for a particular
enb. This causes issues in multi-eNB setups.
Change-Id: I6642128a449a0562dd23f7fa393ff48ae2503006
It may happen that the non-emergency call MT leg is still not properly
released when the emergency call MT leg is to be assigned a TCH, meaning
BSC will fail with an Assignment Failure upon Assignment request from
MSC.
The test sometimes passed and sometimes didn't, due to above mentioned
race condition. Let's relax a bit the test expectancies to have it
always passing, while still verifying preemption happens, and MT phone
is reached.
Related: OS#4549
Change-Id: I3697227cac56a1327f9ea08c5c2f52568e8d2a8a
we need to use two different configs for Amarisoft and srsENB.
Amarisoft combines the two cells and transmits them on the same
RF port, whereas srsENB sends them on a single port each.
Change-Id: I3a2a8ae7bf4ed2dab6efba8550f442a741ad92e0
this patch adds the basic notion of FDD and TDD duplexing modes
to the eNB object. So far we've always assume FDD.
Since only Amarisoft eNB supports TDD, the required config
template changes, etc. are only applied there.
The patch also adds a scenario to enable the default TDD config.
Change-Id: I37216b5bfdf527d221913283b6c41d3c8fd6b500
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
The getter method was named the same as the itnernal field, and hence
when used it would fail since the intenral field would be sleect and
fail to be called.
Change-Id: I2f631eb6256eb0e065f41d5b7531395c4a054cd8
add comment explaining how the sceneario can be used.
also adopt cell IDs to match the CC index of the eNB.
This makes sure the cell_gain command of srsENB works with the config.
Change-Id: I1d14485df700ef3ba9220507f72c50b819d5e334
when carrier aggregation is enabled we need to multiply the
max rate of a single carrier with the number of carriers to
get the actual achievable rate
Change-Id: I70d850c0996ed461d3733e911adc33f3554c297c
Since I8eb28584e90ad012cbf7f3175ee3a8e775c8d523, the test suite
is supposed to run both BTS_Tests_{SMSCB,LAPDm}.control among with
BTS_Tests.control. Apparently this requires more time than 3600
seconds, so everything is broken since build #2652 in Jenkins.
Change-Id: Ieceab920a94cbf92ff6c83a59d572f22e8ae933f
this refactor no longer enforces blocking operation of the process.
Instead it returns the process object to the caller who
can now run either proc.launch() for non-blocking operation
or proc.launch_sync() for blocking mode.
The non-block mode allos doing other stuff in the background,
for example controlling the rfemu while running a ping.
Change-Id: Ia6372e55a8829f722e40db537d9dfd63a94d1be9
This feature is not really implemented and maybe never was. In any case,
it makes sense to have that working per-test so we can specify different
values per test in case it's needed.
Change-Id: I3c1b95c10e974da87ec9abd25578d8bcc0bc55a3
Otherwise processes using the link like "ping" or "iperf3" may fail
because there's still no IP address assigned.
Change-Id: I28137f10a19db01fe90b24830a60342a448d1e92
Pau Espin Pedrol
Pau Espin
Vadim Yanitskiy