Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 1 | == Introduction with Examples |
| 2 | |
| 3 | The osmo-gsm-tester is software to run automated tests of real GSM hardware, |
| 4 | foremost to verify that ongoing Osmocom software development continues to work |
| 5 | with various BTS models, while being flexibly configurable and extendable. |
| 6 | |
| 7 | A 'main unit' (general purpose computer) is connected via ethernet and/or USB to |
| 8 | any number of BTS models and to any number of GSM modems via USB. The modems |
| 9 | and BTS instances' RF transceivers are typically wired directly to each other |
| 10 | via RF distribution chambers to bypass the air medium and avoid disturbing real |
| 11 | production cellular networks. Furthermore, the setup may include adjustable RF |
| 12 | attenuators to model various distances between modems and base stations. |
| 13 | |
| 14 | The osmo-gsm-tester software runs on the main unit to orchestrate the various |
| 15 | GSM hardware and run predefined test scripts. It typically receives binary |
| 16 | packages from a jenkins build service. It then automatically configures and |
| 17 | launches an Osmocom core network on the main unit and sets up and runs BTS |
| 18 | models as well as modems to form a complete ad-hoc GSM network. On this setup, |
| 19 | predefined test suites, combined with various scenario definitions, are run to |
| 20 | verify stability of the system. |
| 21 | |
| 22 | The osmo-gsm-tester is implemented in Python (version 3). It uses the ofono |
| 23 | daemon to control the modems connected via USB. BTS software is either run |
| 24 | directly on the main unit (e.g. for osmo-bts-trx, osmo-bts-octphy), run via SSH |
| 25 | (e.g. for a sysmoBTS) or assumed to run on a connected BTS model (e.g. for |
| 26 | ip.access nanoBTS). |
| 27 | |
| 28 | .Typical osmo-gsm-tester setup |
| 29 | [graphviz] |
| 30 | ---- |
| 31 | digraph G { |
| 32 | rankdir=LR; |
| 33 | jenkins |
| 34 | subgraph cluster_gsm_hardware { |
| 35 | label = "GSM Hardware"; |
| 36 | style=dotted |
| 37 | |
Neels Hofmeyr | 73207e1 | 2017-05-05 02:50:45 +0200 | [diff] [blame] | 38 | modem0 [shape=box label="Modems..."] |
| 39 | modem1 [shape=box label="Modems..."] |
| 40 | modem2 [shape=box label="Modems..."] |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 41 | osmo_bts_sysmo [label="sysmocom sysmoBTS\nrunning osmo-bts-sysmo" shape=box] |
| 42 | B200 [label="Ettus B200" shape=box] |
| 43 | octphy [label="Octasic octphy BTS" shape=box] |
| 44 | nanoBTS [label="ip.access nanoBTS" shape=box] |
| 45 | rf_distribution [label="RF distribution"] |
| 46 | |
| 47 | {modem0 modem1 modem2 osmo_bts_sysmo B200 octphy nanoBTS}->rf_distribution [dir=both arrowhead="curve" arrowtail="curve"] |
| 48 | } |
| 49 | subgraph cluster_main_unit { |
| 50 | label = "Main Unit" |
| 51 | osmo_gsm_tester [label="Osmo-GSM-Tester\ntest suites\n& scenarios"] |
Neels Hofmeyr | 73207e1 | 2017-05-05 02:50:45 +0200 | [diff] [blame] | 52 | subgraph { |
| 53 | rank=same |
| 54 | ofono [label="ofono daemon"] |
| 55 | OsmoNITB |
| 56 | osmo_bts_trx [label="osmo-bts-trx\n+ osmo-trx"] |
| 57 | osmo_bts_octphy [label="osmo-bts-octphy"] |
| 58 | } |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 59 | } |
| 60 | |
| 61 | |
| 62 | jenkins->osmo_gsm_tester [label="trial\n(binaries)"] |
| 63 | osmo_gsm_tester->jenkins [label="results"] |
Neels Hofmeyr | 73207e1 | 2017-05-05 02:50:45 +0200 | [diff] [blame] | 64 | ofono->{modem0 modem1 modem2} [label="USB"] |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 65 | osmo_gsm_tester-> {OsmoNITB osmo_bts_trx osmo_bts_octphy} |
| 66 | osmo_gsm_tester-> osmo_bts_sysmo [taillabel="SSH"] |
| 67 | osmo_gsm_tester-> ofono [taillabel="DBus"] |
| 68 | osmo_bts_trx->B200 [label="USB"] |
| 69 | osmo_bts_octphy->octphy [label="raw eth"] |
Neels Hofmeyr | 73207e1 | 2017-05-05 02:50:45 +0200 | [diff] [blame] | 70 | {osmo_bts_sysmo nanoBTS}->OsmoNITB [label="eth"] |
| 71 | {B200 octphy}->OsmoNITB [label="eth" style=invis] |
| 72 | {osmo_bts_trx osmo_bts_octphy}->OsmoNITB |
| 73 | } |
| 74 | ---- |
| 75 | |
| 76 | .Example of how to select resources and configurations: scenarios may pick specific resources (here BTS and ARFCN), remaining requirements are picked as available (here two modems and a NITB interface) |
| 77 | [graphviz] |
| 78 | ---- |
| 79 | digraph G { |
| 80 | rankdir=TB; |
| 81 | |
| 82 | suite_scenarios [label="Suite+Scenarios selection\nsms:sysmo+band1800"] |
| 83 | |
| 84 | subgraph { |
| 85 | rank=same; |
| 86 | suite |
| 87 | scenarios |
| 88 | } |
| 89 | |
| 90 | subgraph cluster_scenarios { |
| 91 | label = "Scenarios"; |
| 92 | u_sysmoBTS [label="Scenario: sysmo\nbts: type: osmo-bts-sysmo"] |
| 93 | u_trx [label="Scenario: trx\nbts: type: osmo-bts-trx"] |
| 94 | u_arfcn [label="Scenario: band1800\narfcn: band: GSM-1800"] |
| 95 | } |
| 96 | |
| 97 | subgraph cluster_suite { |
| 98 | label = "Suite: sms"; |
Neels Hofmeyr | 5d0330f | 2017-05-18 18:38:50 +0200 | [diff] [blame] | 99 | requires [label="Requirements (suite.conf):\nmodem: times: 2\nbts\nip_address\narfcn"] |
Neels Hofmeyr | 73207e1 | 2017-05-05 02:50:45 +0200 | [diff] [blame] | 100 | subgraph cluster_tests { |
| 101 | label = "Test Scripts (py)"; |
| 102 | mo_mt_sms |
| 103 | etc |
| 104 | } |
| 105 | } |
| 106 | |
| 107 | subgraph cluster_resources { |
| 108 | label = "Resources"; |
| 109 | rankdir=TB; |
| 110 | nitb_addr1 [label="NITB interface addr\n10.42.42.1"] |
| 111 | nitb_addr2 [label="NITB interface addr\n10.42.42.2"] |
| 112 | Modem0 |
| 113 | Modem1 |
| 114 | Modem2 |
| 115 | sysmoBTS [label="osmo-bts-sysmo"] |
| 116 | osmo_bts_trx [label="osmo-bts-trx"] |
| 117 | arfcn1 [label="arfcn: 512\nband: GSM-1800"] |
| 118 | arfcn2 [label="arfcn: 540\nband: GSM-1900"] |
| 119 | |
| 120 | arfcn1->arfcn2 [style=invis] |
| 121 | nitb_addr1->nitb_addr2 [style=invis] |
| 122 | Modem0 -> Modem1 -> Modem2 [style=invis] |
| 123 | sysmoBTS -> osmo_bts_trx [style=invis] |
| 124 | } |
| 125 | |
| 126 | suite_scenarios -> {suite scenarios} |
| 127 | scenarios -> { u_arfcn u_sysmoBTS } |
| 128 | |
| 129 | suite -> requires |
| 130 | requires -> Modem0 |
| 131 | requires -> Modem1 |
| 132 | requires -> sysmoBTS |
| 133 | requires -> arfcn1 |
| 134 | requires -> nitb_addr1 |
| 135 | |
| 136 | { u_sysmoBTS u_arfcn } -> requires [label="influences\nresource\nselection"] |
| 137 | } |
| 138 | ---- |
| 139 | |
| 140 | .Example of a "trial" containing binaries built by a jenkins |
| 141 | [graphviz] |
| 142 | ---- |
| 143 | digraph G { |
| 144 | subgraph cluster_trial { |
| 145 | label = "Trial (binaries)" |
| 146 | sysmo [label="osmo-bts-sysmo.build-23.tgz\n(osmo-bts-sysmo\n+ deps\ncompiled for sysmoBTS)"] |
| 147 | trx [label="osmo-bts-trx.build-5.tgz\n(osmo-trx + osmo-bts-trx\n+ deps\ncompiled for main unit)"] |
| 148 | nitb [label="osmo-nitb.build-42.tgz\n(osmo-nitb\n+ deps\ncompiled for main unit)"] |
| 149 | checksums [label="checksums.md5"] |
| 150 | |
| 151 | checksums -> {sysmo trx nitb} |
| 152 | } |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 153 | } |
| 154 | ---- |
| 155 | |
| 156 | === Typical Test Script |
| 157 | |
| 158 | A typical single test script (part of a suite) may look like this: |
| 159 | |
| 160 | ---- |
| 161 | #!/usr/bin/env python3 |
| 162 | from osmo_gsm_tester.test import * |
| 163 | |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 164 | nitb = suite.nitb() |
| 165 | bts = suite.bts() |
| 166 | ms_mo = suite.modem() |
| 167 | ms_mt = suite.modem() |
| 168 | |
| 169 | print('start nitb and bts...') |
| 170 | nitb.bts_add(bts) |
| 171 | nitb.start() |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 172 | bts.start() |
| 173 | |
| 174 | nitb.subscriber_add(ms_mo) |
| 175 | nitb.subscriber_add(ms_mt) |
| 176 | |
Pau Espin Pedrol | 422f8ba | 2017-06-14 15:57:12 +0200 | [diff] [blame] | 177 | ms_mo.connect(nitb.mcc_mnc()) |
| 178 | ms_mt.connect(nitb.mcc_mnc()) |
| 179 | |
| 180 | print('waiting for modems to attach...') |
| 181 | wait(ms_mo.is_connected, nitb.mcc_mnc()) |
| 182 | wait(ms_mt.is_connected, nitb.mcc_mnc()) |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 183 | wait(nitb.subscriber_attached, ms_mo, ms_mt) |
| 184 | |
Pau Espin Pedrol | 422f8ba | 2017-06-14 15:57:12 +0200 | [diff] [blame] | 185 | sms = ms_mo.sms_send(ms_mt) |
| 186 | wait(ms_mt.sms_was_received, sms) |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 187 | ---- |
| 188 | |
| 189 | === Resource Resolution |
| 190 | |
| 191 | - A global configuration defines which hardware is connected to the |
| 192 | osmo-gsm-tester main unit. |
| 193 | - Each suite contains a number of test scripts. The amount of resources a test |
| 194 | may use is defined by the test suite's 'suite.conf'. |
| 195 | - Which specific modems, BTS models, NITB IP addresses etc. are made available |
| 196 | to a test run is typically determined by a combination of scenario |
| 197 | configurations -- or picked automatically if not. |
| 198 | |
| 199 | [[resources_conf_example]] |
| 200 | === Typical 'resources.conf' |
| 201 | |
| 202 | A global configuration of hardware may look like below; for details, see |
| 203 | <<resources_conf>>. |
| 204 | |
| 205 | ---- |
Neels Hofmeyr | 5d0330f | 2017-05-18 18:38:50 +0200 | [diff] [blame] | 206 | ip_address: |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 207 | - addr: 10.42.42.1 |
| 208 | - addr: 10.42.42.2 |
| 209 | - addr: 10.42.42.3 |
| 210 | |
| 211 | bts: |
| 212 | - label: sysmoBTS 1002 |
| 213 | type: osmo-bts-sysmo |
| 214 | addr: 10.42.42.114 |
| 215 | band: GSM-1800 |
| 216 | |
| 217 | - label: octBTS 3000 |
| 218 | type: osmo-bts-octphy |
| 219 | addr: 10.42.42.115 |
| 220 | band: GSM-1800 |
| 221 | trx_list: |
| 222 | - hw_addr: 00:0c:90:32:b5:8a |
| 223 | net_device: eth0.2342 |
| 224 | |
| 225 | - label: Ettus B210 |
| 226 | type: osmo-bts-trx |
| 227 | addr: 10.42.42.116 |
| 228 | band: GSM-1800 |
| 229 | |
| 230 | - label: nanoBTS 1900 |
| 231 | type: nanobts |
| 232 | addr: 10.42.42.190 |
| 233 | band: GSM-1900 |
| 234 | trx_list: |
| 235 | - hw_addr: 00:02:95:00:41:b3 |
| 236 | |
| 237 | arfcn: |
| 238 | - arfcn: 512 |
| 239 | band: GSM-1800 |
| 240 | - arfcn: 514 |
| 241 | band: GSM-1800 |
| 242 | |
| 243 | - arfcn: 540 |
| 244 | band: GSM-1900 |
| 245 | - arfcn: 542 |
| 246 | band: GSM-1900 |
| 247 | |
| 248 | modem: |
| 249 | - label: m7801 |
| 250 | path: '/wavecom_0' |
| 251 | imsi: 901700000007801 |
| 252 | ki: D620F48487B1B782DA55DF6717F08FF9 |
| 253 | |
| 254 | - label: m7802 |
| 255 | path: '/wavecom_1' |
| 256 | imsi: 901700000007802 |
| 257 | ki: 47FDB2D55CE6A10A85ABDAD034A5B7B3 |
| 258 | |
| 259 | - label: m7803 |
| 260 | path: '/wavecom_2' |
| 261 | imsi: 901700000007803 |
| 262 | ki: ABBED4C91417DF710F60675B6EE2C8D2 |
| 263 | ---- |
| 264 | |
| 265 | === Typical 'suites/*/suite.conf' |
| 266 | |
| 267 | The configuration that reserves a number of resources for a test suite may look |
| 268 | like this: |
| 269 | |
| 270 | ---- |
| 271 | resources: |
Neels Hofmeyr | 5d0330f | 2017-05-18 18:38:50 +0200 | [diff] [blame] | 272 | ip_address: |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 273 | - times: 1 |
| 274 | bts: |
| 275 | - times: 1 |
| 276 | modem: |
| 277 | - times: 2 |
| 278 | ---- |
| 279 | |
| 280 | It may also request e.g. specific BTS models, but this is typically left to |
| 281 | scenario configurations. |
| 282 | |
| 283 | === Typical 'scenarios/*.conf' |
| 284 | |
| 285 | For a suite as above run as-is, any available resources are picked. This may be |
| 286 | combined with any number of scenario definitions to constrain which specific |
| 287 | resources should be used, e.g.: |
| 288 | |
| 289 | ---- |
| 290 | resources: |
| 291 | bts: |
| 292 | - type: osmo-bts-sysmo |
| 293 | ---- |
| 294 | |
Neels Hofmeyr | 5d0330f | 2017-05-18 18:38:50 +0200 | [diff] [blame] | 295 | Which 'ip_address' or 'modem' is used in particular doesn't really matter, so |
Neels Hofmeyr | c0827c4 | 2017-04-23 15:04:19 +0200 | [diff] [blame] | 296 | it can be left up to the osmo-gsm-tester to pick these automatically. |
| 297 | |
| 298 | Any number of such scenario configurations can be combined in the form |
| 299 | '<suite_name>:<scenario>+<scenario>+...', e.g. 'my_suite:sysmo+tch_f+amr'. |
| 300 | |
| 301 | === Typical Invocations |
| 302 | |
| 303 | Each invocation of osmo-gsm-tester deploys a set of pre-compiled binaries for |
| 304 | the Osmocom core network as well as for the Osmocom based BTS models. To create |
| 305 | such a set of binaries, see <<trials>>. |
| 306 | |
| 307 | Examples for launching test trials: |
| 308 | |
| 309 | - Run the default suites (see <<default_suites>>) on a given set of binaries: |
| 310 | |
| 311 | ---- |
| 312 | osmo-gsm-tester.py path/to/my-trial |
| 313 | ---- |
| 314 | |
| 315 | - Run an explicit choice of 'suite:scenario' combinations: |
| 316 | |
| 317 | ---- |
| 318 | osmo-gsm-tester.py path/to/my-trial -s sms:sysmo -s sms:trx -s sms:nanobts |
| 319 | ---- |
| 320 | |
| 321 | - Run one 'suite:scenario' combination, setting log level to 'debug' and |
| 322 | enabling logging of full python tracebacks, and also only run just the |
| 323 | 'mo_mt_sms.py' test from the suite, e.g. to investigate a test failure: |
| 324 | |
| 325 | ---- |
| 326 | osmo-gsm-tester.py path/to/my-trial -s sms:sysmo -l dbg -T -t mo_mt |
| 327 | ---- |
| 328 | |
| 329 | A test script may also be run step-by-step in a python debugger, see |
| 330 | <<debugging>>. |
| 331 | |
| 332 | === Resource Reservation for Concurrent Trials |
| 333 | |
| 334 | While a test suite runs, the used resources are noted in a global state |
| 335 | directory in a reserved-resources file. This way, any number of trials may be |
| 336 | run consecutively without resource conflicts. Any test trial will only use |
| 337 | resources that are currently not reserved by any other test suite. The |
| 338 | reservation state is human readable. |
| 339 | |
| 340 | The global state directory is protected by a file lock to allow access by |
| 341 | separate processes. |
| 342 | |
| 343 | Also, the binaries from a trial are never installed system-wide, but are run |
| 344 | with a specific 'LD_LIBRARY_PATH' pointing at the trial's 'inst', so that |
| 345 | several trials can run consecutively without conflicting binary versions. |
| 346 | |
| 347 | Once a test suite run is complete, all its reserved resources are torn down (if |
| 348 | the test scripts have not done so already), and the reservations are released |
| 349 | automatically. |
| 350 | |
| 351 | If required resources are unavailable, the test trial fails. For consecutive |
| 352 | test trials, a test run needs to either wait for resources to become available, |
| 353 | or test suites need to be scheduled to make sense. (*<- TODO*) |