This patch enables setting cipher and integrity algorithms
in Amarisoft eNB and srsENB via scenario files. If no
settings are defined following defaults are applied:
- Cipher algorithm: EEA0, EEA2, EEA1
- Integrity algorithm: EIA2, EIA1, EIA0
Example of setting cipher algorithms:
- 4g:srsue-rftype@uhd+srsenb-rftype@uhd+mod-enb-cipher@eea1+mod-enb-cipher@eea0+mod-enb-nprb@6
Change-Id: I595206b7d49016fb6d0aec175c828d9537c53886
To expand the test capacities we would like to introduce
Android UEs as new modems. Currently the following tests
are supported:
- Ping
- iPerf3 DL/UL
- RRC Mobile MT Ping
In the following is a small description.
Prerequisites:
- Android UE
- Rooted (Ping, iPerf, RRC Idle MT Ping)
- Qualcomm baseband with working diag_mdlog (RRC Idle MT Ping)
- iPerf3
- Dropbear
- OGT Slave Unit
- Android SDK Platform-Tools
(https://developer.android.com/studio/releases/platform-tools#downloads)
- Pycrate (https://github.com/P1sec/pycrate)
- SCAT
clone https://github.com/bedrankara/scat/ & install dependencies
checkout branch ogt
symlink scat (ln -s ~/scat/scat.py /usr/local/bin/scat)
Infrastructure explaination:
The Android UEs are connected to the OGT Units via USB. We
activate tethering and set up a SSH server (with Dropbear).
We chose tethering over WiFi to have a more stable route
for the ssh connection. We forward incoming connections to
the OGT unit hosting the Android UE(s) on specific ports
to the UEs via iptables. This enables OGT to issue commands
directly to the UEs. In case of local execution we use ADB
to issue commands to the AndroidUE. The set up was tested
with 5 Android UEs connected in parallel but it should be
scalable to the number of available IPs in the respective
subnet. Furthermore, we need to cross compile Dropbear
and iPerf3 to use them on the UEs. These tools have to be
added to the $PATH variable of the UEs.
Examplary set up:
In this example we have two separate OGT units (master
and slave) and two Android UEs that are connected to the
slave unit. An illustration may be found here: https://ibb.co/6BXSP2C
On UE 1:
ip address add 192.168.42.130/24 dev rndis0
ip route add 192.168.42.0/24 dev rndis0 table local_network
dropbearmulti dropbear -F -E -p 130 -R -T /data/local/tmp/authorized_keys -U 0 -G 0 -N root -A
On UE 2:
ip address add 192.168.42.131/24 dev rndis0
ip route add 192.168.42.0/24 dev rndis0 table local_network
dropbearmulti dropbear -F -E -p 131 -R -T /data/local/tmp/authorized_keys -U 0 -G 0 -N root -A
On OGT slave unit:
sudo ip link add name ogt type bridge
sudo ip l set eth0 master ogt
sudo ip l set enp0s20f0u1 master ogt
sudo ip l set enp0s20f0u2 master ogt
sudo ip a a 192.168.42.1/24 dev ogt
sudo ip link set ogt up
Now we have to manually connect to every UE from OGT Master
to set up SSH keys and verify that the setup works.
Therefore, use:
ssh -p [UE-PORT] root@[OGT SLAVE UNIT's IP]
Finally, to finish the setup procedure create the
remote_run_dir for Android UEs on the slave unit like
following:
mkdir /osmo-gsm-tester-androidue
chown jenkins /osmo-gsm-tester-androidue
Example for modem in resource.conf:
- label: mi5g
type: androidue
imsi: '901700000034757'
ki: '85E9E9A947B9ACBB966ED7113C7E1B8A'
opc: '3E1C73A29B9C293DC5A763E42C061F15'
apn:
apn: 'srsapn'
mcc: '901'
mnc: '70'
select: 'True'
auth_algo: 'milenage'
features: ['4g', 'dl_qam256', 'qc_diag']
run_node:
run_type: ssh
run_addr: 100.113.1.170
ssh_user: jenkins
ssh_addr: 100.113.1.170
ue_ssh_port: 130
adb_serial_id: '8d3c79a7'
scat_parser:
run_type: local
run_addr: 127.0.0.1
adb_serial_id: '8d3c79a7'
Example for default-suites.conf:
- 4g:ms-label@mi5g+srsenb-rftype@uhd+mod-enb-nprb@25+mod-enb-txmode@1
Change-Id: I79a5d803e869a868d4dac5e0d4c2feb38038dc5c
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
* 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
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
YAML allows it, and it will allow suites tarting with a number on its
name (like the '4g' one) to register its own schema on next commits.
Change-Id: I64e5a9d6604085d3b17eba30498a5e7a66242cc8
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
Nils Fürste
Pau Espin