5G NR L1 -puhelun verifioinnin automatisointi

(1)

Lasse Leinonen

5G NR L1 -PUHELUN VERIFIOINNIN AUTOMATISOINTI

(2)

5G NR L1 -PUHELUN VERIFIOINNIN AUTOMATISOINTI

Lasse Leinonen Opinnäytetyö Syksy 2020

Tietotekniikan tutkinto-ohjelma Oulun ammattikorkeakoulu

(3)

TIIVISTELMÄ

Oulun ammattikorkeakoulu

Tietotekniikan tutkinto-ohjelma, ohjelmistokehityksen suuntautumisvaihtoehto

Tekijä: Lasse Leinonen

Opinnäytetyön nimi: 5G NR L1 -puhelun verifioinnin automatisointi Työn ohjaaja: Teemu Korpela

Työn valmistumislukukausi ja -vuosi: Syksy, 2020 Sivumäärä: 26

Opinnäytetyössä oli tarkoituksena automatisoida 5G NR L1 -puhelun verifiointi CI-ympäristöjä (Continuos Integration, jatkuva integraatio) varten. Tilaajayrityk- sen CI-ympäristöissä L1-puhelun verifiointi tehtiin käyttäen VIAVI E500 -palvelin- keskusta. Työn tavoitteena oli vähentää käsin tehtävää työtä CI-ympäristöistä ja parantaa radiotukiasemien sekä E500:n käyttöastetta edellisestä. Tilaajayrityk- sen edellisessä toteutuksessa uusia mahdollisia tukiasemakonfiguraatioita varten L1-puhelun verifioinnin parametrisointi piti tehdä käsin.

Työssä oli tarkoitus saada tämä prosessi automatisoitua ja lisättyä CI-ympäristö- jen testiajoihin mukaan. Tätä varten tilaajayrityksen CI-kirjastoihin alettiin teke- mään automaatiokomponenttia, joka hoitaisi tämän prosessin.

Lopputuloksena automaatiokomponentti saatiin valmiiksi ja lisättyä CI-ympäristö- jen testiajoihin mukaan. Automaatiokomponentti osaa jäsentää radiotukiasemalta tulevat arvot oikeaan muotoon E500:aa varten ja sitä voi myös käyttää CI:n ulkopuolella, mikäli komentosarjoja tarvitaan E500:n manuaaliseen käyttöön testaus- tai virheenkorjaustilanteeseen.

Asiasanat: 5G, automaatio, jatkuva integraatio

(4)

4

ABSTRACT

Oulu University of Applied Sciences

Degree Programme in Information Technology, Option of Software Development

Author: Lasse Leinonen

Title of thesis: Automation of 5G NR L1 call verification Supervisor: Teemu Korpela

Term and year when the thesis was submitted: Autumn, 2020 Number of pages: 26

The goal of this thesis work was to automate parametrization for L1 call verification. L1 call verification is done using VIAVI E500 data center cabinet. Previous implementation required manually listing E500 commands with correct parameters, and therefore utilization rate of E500 and radio base stations were lowered, since these command scripts weren’t available for every possible radio base station and base station configuration.

This automation would also help when these scripts need to be updated, since you can update the automation part, instead of having to manually add the changes to each command script.

In this thesis a program that would parse required parameters from the base station to the E500 was to be created. This program would then be added to current CI environment and be used in CI test runs.

Keywords: 5G, automation, continuous integration

(5)

SISÄLLYS

SANASTO ... 6

1 JOHDANTO ... 7

2 VIAVI E500 -PALVELUKESKUSKABINETTI ... 9

3 AUTOMAATIOKOMPONENTTI ... 11

3.1 Ohjelmistosuunnittelu ... 11

3.2 Ongelmakohtia ... 16

3.3 Tulevaisuudessa päivitettävää ... 18

4 TESTAUS JA INTEGRAATIO CI-YMPÄRISTÖÖN ... 20

5 YHTEENVETO ... 23

LÄHTEET ... 25

(6)

6

SANASTO

3GPP Organisaatio, joka tuottaa mm. 5G standardit CI Continuous integration, jatkuva integrointi E500 Viavin valmistama palvelinkeskuskabinetti FR1 Taajuusalue 1, alle 6 GHz:n taajuuksille

FR2 Taajuusalue 2, 24,25 GHz–52,6 GHz:n taajuuksille L1 Radio layer 1, radion ensimmäinen kerros

RF Radio frequency, radiotaajuus

TMA Test Mobile Application, ohjelma, jolla ohjataan E500:aa

(7)

1 JOHDANTO

5G-tiedonsiirron tärkeys kasvaa tulevaisuudessa, kun yhä useampi mobiili- verkko-operaattori tarjoaa 5G-liittymiä ympäri maailmaa. 5G-älypuhelimien myynti on nousussa, ja tulevaisuudessa 5G-älypuhelimien määrä ja kysyntä vain nousee. (1.)

5G-tukiasemien testauksessa automatisoidut CI-ympäristöt (Continuous Integra- tion, jatkuva integraatio) ja DevOps-toimintaperiaate ovat avainasemassa. De- vOps ja CI-toimintaperiaate esitellään kuvassa 1. Testauksen suorittamiseen tarvittavan työn määrää voidaan vähentää lisäämällä automaatiota, jonka takia mahdollisimman moni komponentti halutaankin automatisoida. (2.)

KUVA 1. Manuaalisen testauksen ongelmia, joihin DevOps-automaatio ja CI-ym- päristöt pyrkivät vastaamaan (3)

(8)

8

Tilaajayrityksen nykyisissä CI-ympäristöissä kaikki muut komponentit ovat auto- matisoituja, paitsi uusille radiotukiasemakonfiguroinneille tehtävä L1-puhelun verifiointi. L1 viittaa radion ensimmäiseen tasoon eli fyysiseen tasoon. Jos jollekin mahdolliselle uudelle tukiasemakonfiguroinnille tarvitaan L1-puhelun tarkastus, testausta CI-ympäristöissä ei voida toteuttaa, ennen kuin L1-puhelun verifiointiin tarvittavat mittalaitekomennot on käsin parametrisoitu. Opinnäytetyön tavoitteena onkin automatisoida näiden komentojen parametrisointi, mikä vähentää tulevaisuudessa tarvittavan työn määrää ja nopeuttaa uusien konfiguraatioiden testaa- mista sekä nostaa radiotukiasemien käyttöastetta huomattavasti.

Työssä tutustuttiin aluksi tilaajayrityksen nykyiseen toteutukseen, jonka pohjalta alettiin suunnittelemaan sitä, miten L1-puhelun verifioinnin automatisointi voitaisiin toteuttaa. Työ suoritettiin etänä koronavirukseen liittyvien ohjeistuksien vuoksi.

(9)

2 VIAVI E500 -PALVELUKESKUSKABINETTI

L1-puhelun verifiointiin käytetään VIAVI E500 -palvelinkeskuskabinettia (kuva 2), joka on tarkoitettu radiotukiasemien signaalin testaukseen. Se käyttää VIAVI TM500^TM -verkkotesteriteknologiaa ja pystyy emuloimaan tuhansia mobiililaitteita sekä oikean maailman RF-olosuhteita (4).

KUVA 2. E500 -palvelinkeskuskabinetti (4)

(10)

10

E500:ssa on neljä radiokorttia, joihin jokaiseen voidaan yhdistää kaksi RF-kaapelia. E500:aa käytetään L1-puhelun verifiointiin, joka suoritetaan lähettämällä E500:lle komentoja, joissa radiotukiasemalta tulevan signaalin parametrit kerro- taan. Parametrien asettamisen jälkeen E500 palauttaa signaalin statistiikat, joiden avulla voidaan todeta, onnistuiko radiotukiaseman konfigurointi.

Tärkein tarkistettava statistiikka on BLER (Block Error Rate). BLER-arvo kertoo, kuinka suuri osa tiedosta luettiin onnistuneesti. BLER-arvo halutaan saada mahdollisimman alhaiseksi (5), ja se pitää tarkastaa kumpaankin suuntaan, eli uplink- ja downlink-suuntaan. Mikäli testiajon tuloksissa BLER-arvo on 0 % kumpaankin suuntaan, voidaan todeta, että radiotukiaseman L1-puhelun konfigurointi oli on- nistunut.

E500:aa ohjataan käyttäen tietokoneella TMA-ohjelmaa, jolla suoritetaan komennot. TMA-ohjelma toimii rajapintana tietokoneen ja E500:n välillä. Sen avulla voidaan lisäksi muuttaa joitakin E500:n asetuksia.

(11)

3 AUTOMAATIOKOMPONENTTI

Tilaajayrityksen muut kirjastot on tehty Python-ohjelmointikielellä, joten automaatiokomponentti päätettiin kirjoittaa kyseisellä kielellä. Automaatiokomponentti li- sätään osaksi CI-kirjastoa, joka hoitaa automaattisen radiotukiaseman konfigu- roinnin CI-ympäristöissä ja -testiajoissa. Tämän ansiosta automaatiokomponentti voidaan vaivatta lisätä mukaan muihinkin ohjelmistokirjastoihin ja täten sen saa myös CI-ympäristöjen testiajoihin mukaan.

TMA-komennot pitää parametrisoida oikein, muuten testiajo epäonnistuu. Jotkut parametrit komentoihin löytyivät suoraan radiotukiaseman parametreista, mutta suurimpaan osaan piti tehdä joitakin muutoksia, ennen kuin ne olivat oikeassa muodossa komentoja varten. Osaan piti muuttaa kerrannaisyksikkö, jotkut piti kartoittaa eri alueelle ja osa piti laskea muista arvoista laskukaavoja käyttäen.

Osaa ei myöskään löytynyt radiotukiaseman parametreista, joten niille piti etsiä jokin tietty vakioarvo, joka ei muutu. Nämä vakioarvot otettiin yleensä 3GPP-stan- dardeista, mutta osa myös liittyi CI-ympäristön struktuuriin, kuten RF-kytkentöjen määrään.

Automaatiokomponentin tarkoitus onkin siis automaattisesti asettaa TMA-ohjel- man komentoihin oikeat parametrit sekä käydä suorittamassa komennot CI-ym- päristön testiajoissa.

3.1 Ohjelmistosuunnittelu

Kun alettiin suunnitella automaattista TMA-komentojen parametrisointia, otettiin inspiraatiota aiemmasta toteutuksesta, johon etsittiin mahdollisia ongelmakohtia ja mietittiin niihin parannuksia. Piti myös varmistaa, ettei uuden toteutuksen seurauksena tule uusia ongelmia, ja jos tulee, niin niihin pitäisi etsiä ratkaisu.

Aiemmassa toteutuksessa TMA-komennot oli listattu komentolistaan yksittäiseen tekstitiedostoon, joka suoritettiin E500:n ohjaustietokoneen kautta. Ongelmana

(12)

12

tässä toteutuksessa on se, että koko komentosarjan suorituksessa tulee vain yksi paluuarvo. Uudessa toteutuksessa komennot laitetaan Python-listaobjektiin (6), josta ne suoritetaan yksitellen. Tällöin jokaisesta yksittäisestä komennosta saadaan paluuarvo, eikä vain koko komentosarjasta. Tämä helpottaa ja nopeuttaa työn tekoa mahdollisten virheenkorjaus- ja ongelmatilanteiden ratkaisussa, sillä aiemmassa toteutuksessa nämä yksittäiset paluuarvot saatiin vasta, kun komentosarja käytiin suorittamassa käsin. Tällaisissa tilanteissa piti odottaa, että kai- kissa CI-ympäristöissä olevat testiajot on suoritettu, koska muuten CI-ympäris- tössä käytetty RF-kytkin varattaisiin muille testiajoille käyttöön ja komentosarjan manuaalinen suoritus estyisi.

Katsottiin nykyisiä olemassa olevia TMA-komentosarjoja, joiden struktuurin pohjalta suunniteltiin funktiot automaatiokomponenttiin. Komentosarjojen komennot jaoteltiin loogisiin kokonaisuuksiin, jotka parametrisoidaan automatisoidussa toteutuksessa samassa funktiossa. Esimerkiksi kaikki komennot, jotka liittyivät PDSCH-kanavan konfigurointiin, menivät yhden funktion alle. Koska automaatiokomponentin toiminnallisuus on jaoteltu pienempiin kokonaisuuksiin, on sen koodi tällöin helpommin luettavissa, ja jos jossakin kohtaa ilmestyy ohjelmointi- virheitä, voidaan ne helpommin paikallistaa ja korjata. Kuvassa 3 esitellään automaatiokomponentin lopullinen toimintakaavio.

(13)

KUVA 3. Automaatiokomponentin lopullinen toimintakaavio

(14)

14

Näitä apufunktioita varten tein erillisen luokan. Suunnittelin, että E500Mapper- luokka hoitaisi arvot, jotka pitää kartoittaa eri alueelle komentojen parametrisaa- tiossa radiotukiaseman arvoihin verrattuna. Tämän lisäksi suunnittelin erikseen E500Calculator-luokan, joka sisältäisi kaikki yksittäiset laskukaavat, joita tarvitaan komentojen parametrisointia varten. Lopulta kuitenkin päädyin yhdistämään nämä kaksi apuluokkaa yhteen, sillä joitakin laskuja varten tarvittiin kartoitettuja arvoja. Koodirakenne, jossa apufunktioluokasta kutsutaan funktiota toisesta apufunktioluokasta, olisi ollut sekava. Kuvassa esitellään esimerkki laskufunktiosta.

KUVA 4. SLIV-arvon laskukaava sekä sen koodillinen toteutus automaatiokom- ponentissa (7)

Uudessa toteutuksessa on siis yhteensä kaksi luokkaa. Pääluokka E500Automa- tion hoitaa radiotukiaseman parametrien etsimisen sekä parametrisoitujen komentojen lisääminen listaan, josta ne lopulta suoritetaan. Apuluokkaa E500Calc käytetään, kun komentojen parametrien arvoja pitää laskea laskukaavoilla tai muuttaa eri muotoon radiotukiaseman arvoihin verrattuna. Kuvassa näkyy automaatiokomponentin lopullinen luokkakaavio.

(15)

KUVA 5. Lopullinen luokkakaavio automaatiokomponentin toteutukselle.

(16)

16

3.2 Ongelmakohtia

CI-ympäristössä E500:lta on vedetty vain kaksi RF-kaapelia RF-kytkimeen. Tä- män takia sillä voi testata L1-puheluissa vain yhtä solua kerrallaan. Tämä tuottaa ongelmia silloin, jos halutaan testata useamman solun L1-puhelua. Ratkaisu tä- hän olisi joko vetää lisää johtoja RF-kytkimelle tukiaseman päästä ja testata solut yksitellen tai lisätä RF-kytkentäkapasiteettia E500:n päästä, jolloin voitaisiin yh- distää solut E500:n eri radiokorteille samanaikaisesti ja testata jokainen solu sa- maan aikaan.

Yksi radiosolu on yleisesti kartoitettu radiotukiaseman kahdelle antennille, ja jo- kaisella solulla täytyy olla omat antennit usean solun testitapauksessa. Kantoaal- lot (component carrier) ovat saman käyttäjän datan siirtoon tarkoitettuja eri taa- juuslohkoja. Sellainen testiajo, jossa on useampi kantoaalto, voidaan kuitenkin suorittaa nykyisellä RF-kaapeloinnilla. Tämä johtuu siitä, että samoista anten- neista tulevan signaalin kautta voi tulla useampi kantoaalto (8). Automaatiokom- ponenttiin pitää lisätä logiikka, jolla tarkastetaan, millainen testitapaus on ky- seessä, ja tämän mukaan asetetaan TMA-komentojen parametrit oikein.

FR2-taajuuksien radiotukiasemien testaukseen vaikuttaa myös se, että E500:n ja tukiasemien väliin on vedetty RF-kytkin. Kytkin tukee vain FR1-taajuuksia, minkä takia E500:ta varten pitää laskea radiotukiasemalta tulevan signaalin välitaajuus (9). Aiemmassa toteutuksessa tämä välitaajuus pystyttiin laskemaan erikseen Microsoft Excel -taulukolla ja lisäämään komentosarjaan. Seuraavaksi tämä las- kenta pitää lisätä automaatiokomponenttiin mukaan. Nämä välitaajuudet ovat ra- diotukiasemasta riippuvaisia, mikä myös johtaa siihen, että tulevaisuudessa automaatiokomponenttia joudutaan päivittämään, mikäli uusia radiotukiasemia ote- taan testaukseen käyttöön. Kuvassa esitellään CI-ympäristöjen RF-kytkentäkaa- vio.

(17)

KUVA 6. CI-ympäristöjen nykyinen RF-kytkentäkaavio

(18)

18

K2 offset -arvoa (10) PUSCH-kanavan konfiguraatiota varten ei löytynyt mistään radiotukiaseman parametreista, sillä käytetyillä radiotukiasemilla konfiguraatiolla DCI-payload on laskettu valmiiksi Microsoft Excel -laskukaavoilla (11). Tämä ai- heutti ongelmia PUSCH-kanavan tarkistuksen konfiguroinnissa, sillä ilman K2 - arvoa PUSCH-kanavan tarkistus epäonnistuisi.

Lopulta tämä arvo löytyi, mutta vain TDD-radiotukiasemille. FDD-radiotukiasemilla PUSCH-kanavan konfigurointia varten tätä arvoa ei löytynyt, minkä takia FDD-radiotukiasemien testiajoissa K2-arvoksi asetetaan tietty vakioarvo. Tämä vaikuttaa lopputulokseen FDD-radiotukiasemien testauksessa niissä testiajoissa, joissa tämä K2-arvo on eri kuin tämä vakio.

3.3 Tulevaisuudessa päivitettävää

3GPP-standardeja päivitetään säännöllisesti (12), ja joidenkin komentojen parametrit muuttuvat uusien 3GPP-standardien tuomien muutoksien takia. Automaa- tiokomponenttia saatetaan tämän takia joutua päivittämään tulevaisuudessa.

E500:n ohjelmistoihin saattaa tulla myös päivityksiä tulevaisuudessa, jolloin joidenkin komentojen parametrisaatio saattaa muuttua. Tässä tapauksessa pitää tarkistaa, halutaanko lisätä mahdollisuus ajaa testit myös E500:n vanhalla ohjel- mistoversiolla, jolloin pitäisi kartoittaa funktiot eri E500-ohjelmistoversiolle. Toi- sena vaihtoehtona voidaan päivittää kaikki komennot ja testiajot käyttämään uutta ohjelmistoversiota.

Oli päivityksen tarve sitten mikä tahansa, on komentosarjojen päivittäminen kuitenkin helpompaa kuin aiemmassa toteutuksessa. Kooditoteutukseen laitetut muutokset tulevat jokaiseen testiajoon heti mukaan, eikä muutoksia tarvitse täl- löin käsin lisätä erikseen jokaiseen komentosarjaan. Mikäli muutoksia pitää tehdä vain joihinkin komentosarjoihin, voi tämänkin tehdä uudessa koodillisessa toteutuksessa käyttämällä Pythonin ehtolauseita.

(19)

Mikäli RF-kytkennät muuttuvat CI-ympäristössä, pitää useamman solun tapauk- sien logiikkaa muuttaa. Tällä hetkellä näissä tapauksissa RF-kytkin asetetaan aluksi ensimmäisen solun antenneihin, jonka jälkeen tämän solun arvot testa- taan. Tämän jälkeen RF-kytkimen kytkennät vaihdettaisiin seuraavalle testatta- valle solulle. Mikäli RF-kytkentäkapasiteettia saadaan lisättyä tulevaisuudessa niin, että solut voidaan yhdistää samanaikaisesti, tämä logiikka voidaan poistaa.

Näissä testitapauksissa oli myös valmiiksi tehty logiikka poikkeustilannetta varten, jolloin BLER-arvo saa olla yli 0 %. Esimerkiksi kahden solun tapauksessa vain puolet datasta voidaan lähettää testattaessa vain ensimmäistä solua, ja täl- löin BLER on 50 %.

(20)

20

4 TESTAUS JA INTEGRAATIO CI-YMPÄRISTÖÖN

Aluksi testauksen pystyi suorittamaan vertaamalla automaatiokomponentin pa- lauttamaa komentolistaa valmiisiin komentosarjoihin. Koska automaatiokomponentin palauttaman komentolistan parametrit oli asetettu vastaamaan käytetyn radiotukiasemakonfiguraation parametreja, pystyttiin niitä suoraan vertaamaan saman tukiasemakonfiguraation valmiiseen komentosarjaan.

Testaus voitiin aloittaa oikeissa CI-ympäristöissä, kun automaatiokomponentti saatiin siihen pisteeseen, että se palauttaa jokaisen tarvittavan komennon E500:n parametrisaatioon. CI-kirjastoissa oli olemassa toteutus, jolla pystyttiin suorittamaan yksittäisiä TMA-komentoja. Käytin tätä toteutusta automaatiokomponentin palauttamien komentojen suoritusta varten.

Valmiissa yksittäisten komentojen suoritukseen tehdyssä toteutuksessa kuitenkin ilmeni ongelmia. Komennot suoritettiin käyttäen Pythonin telnetlib-kirjastoa, joka tekee Telnet-yhteyden E500:ta ohjaavalle tietokoneelle. TMA-ohjelma on käyn- nistetty E500:n ohjaustietokoneella, jolta lähetetään komentoja etänä Telnet-yhteyden kautta Microsoftin PsExec-ohjelmalla (13).

Telnetlib-kirjastosta käytettävää expect-funktio ottaa parametriksi odotetun pa- luuarvon suoritettavasta komennosta (14). Jos tämän parametrin jätti tyhjäksi, niin CI-testiajossa TMA-komennot suoritettiin liian nopeasti, eikä aiempia komentoja ollut ehditty suorittaa. Tämän takia komentosarjan suoritus sekä testiajo epä- onnistuivat.

Testasin myös testiajon suorittamista niin, että expect-funktion parametrina oli

”Ok”. Komennot suoritettiin ja expect-funktion avulla jäätiin odottamaan, että E500 palautti tämän kyseisen merkkijonon. Tällä ”Ok”-arvolla testiajo meni läpi, sillä jokainen suoritettu TMA-komento palauttaa tämän onnistuessaan.

(21)

Tässä toteutuksessa kuitenkin ilmeni ongelmia, sillä telnetlib-kirjaston expect- funktiolla TMA-komennon paluuarvosta palautetaan vain tähän ”Ok”-merkkijo- noon asti, vaikka TMA-komentojen merkkejä olisi enemmän vielä kyseisen merkkijonon jälkeen. Paluuarvojen loput merkit tulevat seuraavan komennon paluuar- von alussa. Tälle ongelmalle ei taida olla järkevää ratkaisua. Ainoa hyvä ratkaisu olisi, jos jokaiselle komennolle tiedettäisiin valmiiksi odotettu paluuarvo kokonaan. Ongelma ei vaikuta automaatiokomponentin toiminnallisuuteen, ainoas- taan luettavuuteen, joten päätin olla käyttämättä aikaani sen korjaukseen. Jos tulevaisuudessa tulee tarve korjata tämä ongelma, pitäisi tehdä kokonaan uusi toteutus komentojen suorituksesta kenties SSH-yhteyttä käyttäen.

Joissakin TMA:n nollaavissa TMA-komennoissa tämä ”Ok”-merkkijono palautet- tiin vasta todella pitkän ajan päästä, jonka seurauksena testiajon suoritus piden- tyy. Vanhassa toteutuksessa koko komentosarjan suorituksessa kesti alle yksi sekunti, mutta nyt näihin komentoihin pitää jäädä odottamaan paluuarvoa jopa 30 sekunniksi. Komentojen dokumentaatiossa kerrottiin, että TMA:n nollaavien komentojen suorituksissa saattaa kestää jopa 60 sekuntia. Jostakin syystä aiemmassa toteutuksessa, jossa nykyisestä poiketen koko komentosarja suoritettiin kerrallaan, näiden komentojen suorituksessa ei kestänyt aikaa. En tiedä, mistä tämä voisi johtua, mutta tähän väliin en myöskään perehdy asiaan tarkemmin.

Vaikka komentosarjan suoritus on hitaampi verrattuna aiempaan toteutukseen, aiheutunut hidastus on kuitenkin koko CI-testiajon pituuteen verrattuna merkityk- setön, minkä takia tämäkin korjataan tulevaisuudessa, mikäli korjaukselle ilme- nee tarvetta.

Useamman solun testitapauksia varten oli tehty toteutus, jossa yksi solu testattiin ja RF-kytkimen avulla kytkennät vaihdettiin toisen solun antenneille, jolloin tämä- kin solu voidaan testata. Tämä toteutus tarvittiin, koska nykyisen CI-ympäristön RF-kytkentäkapasiteetti on rajoitettu. Tällaisia testitapauksia varten automaatiokomponenttiin piti lisätä logiikka, jolla komentosarja parametrisoidaan vain jonkin tietyn solun parametrien mukaan. Tämän logiikan lisäämisen jälkeen pystyttiin nämäkin radiotukiasemakonfiguraatiot testaamaan onnistuneesti automaatiokomponenttia käyttäen nykyisessä CI-ympäristössä.

(22)

22

Piti myös varmistaa, että E500-testiajon komentojen epäonnistuessa testiajo käyttäytyy oikein. Mikäli valmiissa komentojen suoritustoteutuksessa tätä ”Ok”- arvoa ei löytynyt paluuarvosta, komentolistan suoritus kuitenkin jatkui normaalisti.

Jos esimerkiksi solun parametrit menivät väärin, eivät loputkaan komennot voisi suoriutua oikein, joten lopulta ne aikakatkaistaan. Tämän tilanteen korjaukseksi lisäsin logiikan, jolla aikakatkaisun tapahtuessa komentojen suoritustoteutus nostaa poikkeuksen (15), jossa palautetaan myös kaikki merkit, joita Telnet-yhteyden kautta on tullut.

(23)

5 YHTEENVETO

Opinnäytetyössä oli tarkoituksena saada automatisoitua aiemmin manuaalisesti tehtävä työ. E500:ta ohjaavien komentosarjojen tekeminen manuaalisesti oli oma urakkansa, mutta myös ongelmatilanteissa valmiiden komentosarjojen ongelma- ja virheenkorjaustilanteissa saattoi kestää jopa useita viikkoja.

Valmiit komentosarjat olivat luettavuudeltaan erittäin epäselviä, mikä hidasti työn- tekoa. Komentojen parametrit oli laitettu komennon loppuun ilman tarkempaa do- kumentaatiota siitä, mikä arvo vastaa mitäkin parametria radiotukiaseman puo- lelta. Tämän takia ongelmatilanteissa piti lähes poikkeuksetta lukea komentojen dokumentaatiosta, jotta selvisi, mitä arvoa mikäkin parametri vastaa.

Automaattisessa toteutuksessa sen sijaan pystytään katsomaan koodista suoraan se, mitä arvoa tukiasemalla jokainen parametri vastaa. Koodillinen toteutus myös helpottaa muutoksien tekoa, sillä muutoksia pystytään tekemään automaatiokomponenttiin, eikä tarvitse käydä lisäämässä muutoksia manuaalisesti jokaiseen olemassa olevaan komentosarjaan.

Uudessa toteutuksessa komentojen suoritusta varten tehty toteutus oli myös pa- rempi kuin aiemmassa toteutuksessa. Aiemmassa toteutuksessa koko komentosarja suoritettiin kerrallaan, jonka takia suorituksesta saatiin vain yksi paluuarvo.

Uudessa toteutuksessa sen sijaan saadaan palautettua jokaiselta suoritettavalta komennolta paluuarvo, kun taas aiemmassa toteutuksessa näitä paluuarvoja ei voinut saada mitenkään. Jos nämä paluuarvot tarvittiin virheenkorjaustilannetta varten, piti odottaa, että CI-ympäristössä ei ollut meneillään mitään testiajoja, jotta CI:ssä käytetty RF-kytkin olisi vapaana. Tämän jälkeen piti suorittaa testiajo, jossa radiotukiasema konfiguroidaan ja RF-kytkin asetetaan oikeaan asentoon, jonka jälkeen komentosarja piti käydä suorittamassa käsin.

Automaatiokomponentti saatiin onnistuneesti tehtyä valmiiksi ja lisättyä mukaan CI-ympäristön testiajoihin. Automaatiokomponentin avulla uusien testitapauksien

(24)

24

ja radiotukiasemien L1-puhelun konfigurointi ja ongelmanratkaisu nopeutuu ja helpottuu huomattavasti sekä sen avulla radiotukiasemien sekä E500:n käyttö- aste kasvaa.

Automaatiokomponentilla voidaan myös vähentää manuaalisessa testauksessa tarvittavan työn määrää. Jos joku haluaisi testata L1-puhelun testitapauksia manuaalisesti, voidaan automaatiokomponenttia myös ajaa itsenäisesti muusta CI- ympäristöstä, ja tällöin saadaan komentosarja palautettua manuaaliseen testaukseen.

Ainoa uuteen automatisoituun toteutukseen jäävä puute oli komentojen suorituksessa käytetyn Telnet-yhteyden aiheuttama paluuarvojen huono muotoilu. Sen seurauksena komennoista saatavien paluuarvojen luettavuus huononee, sillä paluuarvot aina katkaistaan keskeltä. Tähän ratkaisuna olisi yrittää saada komennot suoritettua jonkin modernimman yhteystyypin kautta, kuten SSH:n, sillä siinä on valmiina logiikka, jolla saadaan koko paluuarvo helposti palautettua. Tätä puu- tetta ei opinnäytetyössä enää korjattu, sillä se ei vaikuta toiminnallisuuteen, aino- astaan paluuarvojen luettavuuteen.

(25)

LÄHTEET

1. Whitney, Lance 2020. 5G smartphone shipments forecast to grow by more than 1,500% this year. TechRepublic. Saatavissa: https://www.techrepublic.com/article/5g-smartphone-shipments-forecast-to-grow-by-more-than- 1500-this-year/. Hakupäivä 28.10.2020.

2. Patil, Hemant – Price, Gareth 2020. CI/CD and CD/D: continuous software delivery explained. Ericsson. Saatavissa: https://www.erics-

son.com/en/blog/2020/9/cicd-and-cdd-continuous-software-delivery-explained. Hakupäivä 28.10.2020.

3. Stüttgen, Heinrich 2015. Network Softwarization and Virtualization. NEC Corporation. Saatavissa: http://www.5gsummit.org/berlin/docs/slides/Hein- rich-Stuttgen.pdf. Hakupäivä 12.11.2020

4. E500 data center cabinet product brief. Viavi 2018. Saatavissa:

https://www.viavisolutions.com/en-us/literature/e500-data-center-cabinet- brochure-en.pdf. Hakupäivä 21.10.2020.

5. Akhundov, Ziya. Block Error Rate in LTE. Telecompedia. Saatavissa:

https://telecompedia.net/block-error-rate-in-lte/. Hakupäivä 29.10.2020.

6. Data structures. Python Software Foudation. Saatavissa: https://docs.python.org/3/tutorial/datastructures.html. Hakupäivä 28.10.2020.

7. 5G/NR SLIV. ShareTechnote. Saatavissa: https://www.sharetechnote.com/html/5G/5G_SLIV.html. Hakupäivä 6.11.2020

8. Wannstrom, Jeanette 2013.Carrier Aggregation explained. 3GPP. Saata- vissa: https://www.3gpp.org/technologies/keywords-acronyms/101-carrier-

(26)

26

aggregation-explained. Hakupäivä 30.10.2020

9. Yap, How-Siang 2018. Understanding 5G and IoT RF Systems with Off-the- Shelf Components. Microwaves & RF. Saatavissa:

https://www.mwrf.com/technologies/components/article/21848922/understanding-5g-and-iot-rf-systems-with-offtheshelf-components. Hakupäivä 29.10.2020.

10. 5G/NR Scheduling. ShareTechnote. Saatavissa: http://www.sharetechnote.com/html/5G/5G_Scheduling.html. Hakupäivä 29.10.2020.

11. Chelikani, Naveen 2020. 5G-NR K0, K1 & K2 for Time Domain DL & UL Re- source allocation. LinkedIn. Saatavissa: https://www.linkedin.com/pulse/5g- nr-k0k1-k2-time-domain-dl-ul-resource-allocation-naveen-chelikani. Haku- päivä 29.10.2020

12. 3GPP Specification Release Numbers. Electronics Notes. Saatavissa:

https://www.electronics-notes.com/articles/connectivity/3gpp/standards-re- leases.php. Hakupäivä 30.10.2020

13. Fisher, Tim 2020. PsExec: What It Is and How to Use It. Lifewire. Saata- vissa: https://www.lifewire.com/psexec-4587631. Hakupäivä 24.11.2020

14. telnetlib – Telnet Client. Python Software Foundation. Saatavissa:

https://docs.python.org/3/library/telnetlib.html#telnetlib.Telnet.expect. Haku- päivä 5.11.2020

15. Built-in Exception. Python Software Foundation. Saatavissa:

https://docs.python.org/3/library/exceptions.html#Exception. hakupäivä 24.11.2020