Eindrapport. pgsm beproeving OOV. Versie 1.0. Datum 2 december 2010

Eindrapport pGSM beproeving OOV

Versie 1.0

Datum Status

2 december 2010 Definitief

DEFINITIEF | pGSM beproeving OOV | 2 december 2010

Colofon

IVENT RIC i.s.m. RadioAccess CDC Madame Curielaan 4-6 Postbus 20703 2289 CA Rijswijk Contactpersoon

LKol F.T.M. Snels Projectleider M +31 6 51705209 [email protected]

Versie Opdrachtgever Auteur(s) Projecten

1.0 R. van Bladel F.T.M. Snels, P. Brooijmans i-Bridge2.0

Pagina 2 van 46

Eindrapport pGSM Beproeving Definitief

Inhoud Colofon ................................................................................................................. 2 1 Inleiding. ..................................................................................................... 5 2 Systeemontwerp en samenstelling ............................................................... 5 3 Aanmeldingsproces voor gebruikers met SIM-kaarten van Mobiele Netwerk Operators .............................................................................................................. 6 3.1 Vraagstelling ............................................................................................... 6 3.2 Gerealiseerde oplossing ................................................................................ 6 3.3 Gehanteerde randvoorwaarde voor deze oplossing........................................... 8 3.4 Resultaat van veldtest met deze oplossing ...................................................... 8 3.5 Ervaring, conclusies, adviezen en input voor volgende fase van PoC. ................. 8 4 Systeem architectuur: IP Plan ...................................................................... 9 4.1 Vraagstelling ............................................................................................... 9 4.2 Gerealiseerde oplossing ................................................................................ 9 4.3 Gehanteerde randvoorwaarde voor deze oplossing........................................... 9 4.4 Resultaat van veldtest met deze oplossing ...................................................... 9 4.5 Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC ............ 10 5 Systeem architectuur: Nummerplan ........................................................... 10 5.1 Vraagstelling .............................................................................................. 10 5.2 Gerealiseerde oplossing ............................................................................... 10 5.3 Gehanteerde randvoorwaarde voor deze oplossing.......................................... 10 5.4 Resultaat van veldtest met deze oplossing ..................................................... 10 5.5 Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC. ........... 10 6 Systeem architectuur: SW versies modules ................................................ 10 6.1 Vraagstelling .............................................................................................. 10 6.2 Gerealiseerde oplossing ............................................................................... 10 6.3 Gehanteerde randvoorwaarde voor deze oplossing.......................................... 11 6.4 Resultaat van veldtest met deze oplossing ..................................................... 11 6.5 Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC ............ 11 7 Gebruikte antennes en antennehoogte ...................................................... 11 7.1 Vraagstelling .............................................................................................. 11 7.2 Gerealiseerde Oplossing .............................................................................. 12 7.3 Gehanteerde randvoorwaarde voor deze oplossing.......................................... 16 7.4 Resultaat van de veldtest van deze oplossing ................................................. 16 7.5 Ervaring, conclusies en adviezen .................................................................. 20 8 Satelliet backhaul....................................................................................... 20 8.1 Vraagstelling .............................................................................................. 20 8.2 Gerealiseerde oplossing ............................................................................... 20 8.3 Gehanteerde randvoorwaarde voor deze oplossing.......................................... 21 8.4 Resultaat van veldtest met deze oplossing ..................................................... 21 8.5 Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC ............ 21 9 Push to Talk over Cellular: Server en Applicatie ......................................... 21 9.1 Vraagstelling .............................................................................................. 21 9.2 Gerealiseerde oplossing ............................................................................... 21 9.3 Gehanteerde randvoorwaarde voor deze oplossing.......................................... 22 9.4 Resultaat van veldtest met deze oplossing ..................................................... 22 9.5 Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC ............ 22 10 Push to Talk over Cellular: Toestellen ........................................................ 23 10.1 Vraagstelling ............................................................................................ 23 10.2 Gerealiseerde oplossing ............................................................................. 23 10.3 Gehanteerde randvoorwaarde voor deze oplossing ........................................ 24 10.4 Resultaat van veldtest met deze oplossing ................................................... 24

Commercieel vertrouwelijk

pag 3 van 46


10.5 Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC ........... 24 11 Gebruikte antennemasten, pGSM Core behuizing en stroomvoorziening .... 24 11.1 Vraagstelling ............................................................................................ 24 11.2 Gerealiseerde oplossing ............................................................................. 24 11.3 Gehanteerde randvoorwaarden ................................................................... 25 11.4 Resultaat ................................................................................................. 25 11.5 Ervaring, conclusies & advies...................................................................... 26 12 Schaalbaarheid en Flexibiliteit vanuit diverse invalshoeken ...................... 28 12.1 Vraagstelling ............................................................................................ 28 12.2 Gerealiseerde oplossing ............................................................................. 28 12.3 Ervaring, conclusies, adviezen en input voor een vervolgfase. ........................ 29 13 Beheer van systeem in het veld ................................................................. 30 13.1 Vraagstelling ............................................................................................ 30 13.2 Gerealiseerde oplossing ............................................................................. 30 13.3 Gehanteerde randvoorwaarde voor deze oplossing ........................................ 30 13.4 Resultaat van veldtest met deze oplossing ................................................... 31 13.5 Ervaring, conclusies, adviezen en input voor volgende fase van PoC. ............... 31 14 GRSOOV applicatie en website ................................................................... 32 14.1 Inleiding .................................................................................................. 32 14.2 Uitgangspunten en randvoorwaarden .......................................................... 32 14.3 Entiteiten ................................................................................................. 34 14.4 Overige functies ........................................................................................ 39 14.5 MOSCOW lijst ........................................................................................... 41 15 Afkortingenlijst .......................................................................................... 43


pag 4 van 46


1

Inleiding. Dit document beschrijft de vraagstelling , gerealiseerde (technologische) oplossingen , ervaringen en adviezen voor een vervolgfase van het project „Privaat GSM systeem beproeving voor de openbare Orde en Veiligheid (pGSM OOV). Het project „pGSM beproeving OOV‟ heeft tot doel te onderzoeken of een Privaat GSM systeem een complementair nood telecommunicatienetwerk kan vormen voor inzet bij hulpverlenende instanties in geval bestaande telecommunicatievoorzieningen ten gevolge van calamiteiten overbelast dan wel onbruikbaar zijn. In het document wordt achtereenvolgens op diverse relevante aspecten van de beproeving ingegaan, waarbij telkens ook conclusies worden getrokken en aanbevelingen worden gedaan. In de bijlage staan de relevante gegevens voor de applicatie GRSOOV vermeld, welke is gebruikt om de benodigde gebruikersinformatie te verzamelen in voorbereiding op de beproeving. De code van de database en relevante technische gegevens zijn opvraagbaar bij het Research & Innovatie Centrum van IVENT. De in het document vermelde gebruikerservaringen zijn verkregen door interviews voor, tijdens en na de operationele beproevingen. Tevens is na afloop van de beproevingen nog een enquête onder de deelnemers gehouden.

2

Systeemontwerp en samenstelling Het systeem voor de beproeving is samengesteld om te voldoen aan functionele behoeftes zoals deze zijn geïnventariseerd binnen de OOV-sector. Belangrijke karakteristieken van de gekozen opzet zijn :   

Het pGSM-systeem mag alleen toegankelijk zijn voor geautoriseerde gebruikers Het pGSM-systeem moet toegankelijk zijn voor SIM-kaarten van elke willekeurige operator Het pGSM-systeem moet voor de hulpverleners herkenbare spraakdiensten bieden

Deze eisen hebben geleid tot een systeem dat als volgt is samengesteld:


pag 5 van 46


IP over Satcom tbv spraakkoppeling op PSTN

BTS MSC BGAN

IPT met koppeling op PSTN

SMSC

BSC

HLR/ VLR PTT Backhaul vbd

PSTN BTS

Figuur 1 : Schematische weergave Privaat GSM systeem van eindgebruiker tot koppeling op publieke telefoonnetwerk

Met dit systeem zijn de volgende testen doorlopen:  Systeemtesten bij de leverancier  Veldtesten zonder eindgebruikers  Operationele beproevingen tijdens twee oefendagen van de Brandweer van Hulpverlening Gelderland-Midden (HGM)

3

Aanmeldingsproces voor gebruikers met SIM-kaarten van Mobiele Netwerk Operators

3.1

Vraagstelling Hoe kunnen medewerkers van de hulpverlenende instanties hun eigen mobiele telefoon gebruiken in combinatie met een snel inzetbaar autonoom mobiel communicatiesysteem, zonder dat er een SIM kaart uitgewisseld dien te worden? Op welke wijze kan er een mechanisme worden gerealiseerd waarbij alleen van te voren geautoriseerde medewerkers zich kunnen aanmelden op dit communicatiesysteem?

3.2

Gerealiseerde oplossing Mobiele GSM telefoons zijn uitgerust met een SIM kaart. Deze SIM kaart bevat onder andere  een IMSI (International Mobile Subscriber Identity) nummer  Ki sleutel, ten behoeve van de authenticatie  Door gebruiker gevulde telefoonlijst De basis van elk GSM netwerk is de HLR, het Home Location Register. Deze HLR is onder andere de database die het toegewezen mobiele telefoonnummer (MSISDN nummer) koppelt aan het binnen het GSM netwerk gehanteerde IMSI nummer dat zich in de SIM van het mobiele toestel bevindt. Om een mobiel telefoontoestel te koppelen aan een tijdelijk autonoom GSM netwerk, dient het IMSI nummer te worden geladen in de HLR van dit netwerk. Het IMSI nummer is


pag 6 van 46


echter niet door de gebruiker op te vragen in het toestel en moet daarom op een andere wijze worden achterhaald. De methode die hiervoor is ontwikkeld maakt gebruik van het IMEI (Internatonal Mobile Equipment Identity) nummer van de mobiele telefoon. Het IMEI nummer is een uniek (serie) nummer van een mobiele telefoon. Dit nummer is door de gebruiker eenvoudig opvraagbaar door het intoetsen van de code *#06#. Het tijdelijke autonome GSM netwerk wordt geladen met de lijst van IMEI nummers van de medewerkers die geautoriseerd zijn om zich aan te melden op dit netwerk. Zodra een medewerker zich probeert aan te melden op het tijdelijke autonome GSM netwerk stuurt de mobiele telefoon zowel het IMSI als ook het IMEI nummer naar het netwerk. Dit is dan het moment waar het GSM netwerk geladen wordt met het IMSI nummer teneinde de koppeling te kunnen leggen tussen het MSISDN nummer en het IMSI nummer. Het MSISDN nummer is het nummer dat gebruikt wordt buiten het autonome GSM netwerk en tussen de telefonienetwerken onderling. Uit bovenstaande blijkt dat het daarom noodzakelijk is vooraf IMEI nummers van de geautoriseerde gebruikers te verzamelen. Met een verdere ondersteuning van de OOV sector in gedachten heeft IVENT een web-applicatie ontwikkeld (genaamd GRSOOV) waarmee op gebruiksvriendelijke wijze de noodzakelijke gegevens verzameld en gevalideerd kunnen worden. Voor het verzamelen van de noodzakelijke gegevens van de medewerkers worden deze uitgenodigde zich aan te melden op een (publiek toegankelijke) website. Op deze site dienen de medewerkers de volgende gegevens in te voeren:  Naam medewerker  Bedrijfsonderdeeldeel en/of afdelingsnaam  06 nummer (MSISDN nummer) dat de medewerker heeft in het publieke GSM netwerk  IMEI nummer van het toestel van de medewerker  E-mail adres van de medewerker voor de finale authenticatie Na invoer van de gegevens en een eenvoudige controle op de juistheid van de ingevoerde gegevens ontvangen de medewerkers een bevestigingsverzoek per email. Indien dit bevestigingsverzoek door de medewerker (gecontroleerd en) bevestigd wordt, worden de relevante gegevens opgeslagen om te kunnen worden geladen in het IVENT tijdelijke GSM netwerk. De gegevens die in het IVENT tijdelijke GSM netwerk worden geladen zijn:  Naam  IMEI nummer  MSISDN nummer dat de medewerker heeft in het publieke GSM netwerk Als de betreffende gegevens in het tijdelijke GSM netwerk geladen zijn, kan het toestel zich aanmelden en is het (binnen het nummerplan van het tijdelijke netwerk) bereikbaar middels het reguliere MSISDN nummer. Aanmelding van deze toestellen dient handmatig te geschieden. De SIM kaart zal namelijk te allen tijde haar eigen „home‟ netwerk zoeken en zich daar aan melden. Aanmelding op het OOV pGSM netwerk is mogelijk door in het GSM toestel de functie „netwerk zoeken‟ op „handmatig‟ te zetten. Na handmatige selectie en bevestiging zal het GSM toestel, mits geautoriseerd, zich aanmelden. De netwerk identificatie code MCC gevolgd door de MNC, (Mobile Country Code resp Mobile Network Code) die voor deze proef gebruikt is, is 20467 op sommige GSM toestellen ook wel weergegeven als NL67 (204 is het MCC voor Nederland, 67 is de MNC voor deze proef)


pag 7 van 46


Het beproefde systeem was voorzien van twee ip.access nanoBTSen die elk 200 mW zendvermogen hadden. Een derde High Power mini BTS van STM bleek door de leverancier niet tijdig te kunnen worden voorzien van de noodzakelijke software om te kunnen functioneren in de 1800 MHz band. De beproeving van deze High Power mini BTS zal mogelijk later plaats vinden. Een nanoBTS stond opgesteld naast de pGSM server. De tweede nanoBTS is gekoppeld aan de pGSM server middels een microwave (IP) straalverbinding over een afstand van ca. 1,2 km, gezien het feit dat gewenste dekkingsgebied groter was dan kon worden gedekt door één BTS. In deze configuraties zijn eveneens zogenaamde hand-over relaties gedefinieerd zodat een mobiele telefoon haar verbinding blijft behouden zodra deze van het dekkingsgebied van een BTS naar het gebied van de andere BTS beweegt.

3.3

Gehanteerde randvoorwaarde voor deze oplossing Aanmelding van de medewerkers moet zo eenvoudig mogelijk zijn en het laden van de noodzakelijke gegevens moet zo min mogelijk fouten kunnen introduceren. Het tijdelijke, autonome GSM netwerk is – in principe - niet gekoppeld aan de buitenwereld. Daarom moet er een moment gekozen worden waarop de middels internet verzamelde gegevens geladen worden in dit tijdelijke netwerk. Vanaf dat moment zijn mutaties anders dan mutaties direct in de HLR van het IVENT tijdelijke netwerk, niet meer mogelijk. Om de medewerkers ten tijde van de beproeving ook vanaf het openbare telefonienetwerk bereikbaar te laten zijn, is aan de medewerkers geadviseerd het MSISDN nummer in het openbare GSM netwerk middels *21*<10-cijferig telefoonnummer># door te laten schakelen naar het tijdelijk toegewezen 085 nummer. Als alternatief voor *21* kan er ook voor *62*<10-cijferig telefoonnummer># worden gebruikt (doorschakelen indien buiten bereik eigen netwerk)

3.4

Resultaat van veldtest met deze oplossing Van de 35 op internet aangemelde medewerkers hadden er ca 7 ten tijde van het sluiten van de inschrijvingstermijn nog geen laatste bevestigingsmail gestuurd. Deze medewerkers werden dien tengevolge dan ook niet toegevoegd aan de lijst van IMEI nummers in het IVENT tijdelijke GSM netwerk die zich mochten aanmelden. De oorzaak hiervoor lag in een foutieve DNS-instelling op de mailserver die werd gebruikt ter ondersteuning van GRSOOV. Voor verdere informatie betreffende de GRSOOV wordt verwezen naar bijlage A. Alle overige medewerkers konden na instructie zich zonder problemen afmelden van het reguliere openbare GSM netwerk en zich handmatig aanmelden bij het IVENT tijdelijke GSM netwerk. De medewerkers waren bovendien goed bereikbaar middels het MSIDSN nummer vanaf de openbare telefonienetwerken aangezien deze hun eigen nummer hadden doorgeschakeld naar het tijdelijk toegekende 085 nummer.

3.5

Ervaring, conclusies, adviezen en input voor volgende fase van PoC. Per email verstuurde bevestigingsverzoeken dienen zodanig te worden opgesteld dat deze niet door spamfilters worden tegengehouden. De publieke DNS van de mailservers dient daarom bekend te zijn.


pag 8 van 46


4

Systeem architectuur: IP Plan

4.1

Vraagstelling Maak een opzet voor een IP plan welke te allen tijde bruikbaar is, ook wanneer aan een externe koppeling (via internet) dynamisch een IP-adres wordt toegewezen.

4.2

Gerealiseerde oplossing Het gehele systeem bestaat uit een drietal servers waarvan een uitgevoerd is met meerdere ethernet poorten. De scheiding van netwerken vind plaats middels deze uitbreiding. Aan de WAN zijde is gekozen voor een toewijzing van IP adressen middels DHCP. De interne kant is statisch uitgevoerd. De gekozen interne IP reeks (10.10.10.0/24) is van een – willekeurige - vrij gekozen aard welke uitsluitend binnen het interne netwerk adresseerbaar is.

Figuur 2 : Schematisch overzicht IP plan

4.3

Gehanteerde randvoorwaarde voor deze oplossing De gekozen oplossing vereist in deze wel dat er aan de WAN zijde van het GSM platform een DHCP voorzien is, echter door een kleine modificatie in de configuratie van het systeem zou er in principe ook met een statisch IP adres gewerkt kunnen worden.

4.4

Resultaat van veldtest met deze oplossing De WAN IP verbinding komt tot stand middels een door IVENT aangeleverde satellietterminal (een zgn Regional BGAN) welke via Inmarsat de reach back verbinding vormt voor alle externe uitgaande en inkomend SIP verkeer. Door de nauwkeurig gekozen protocollen voor de reach back verbinding kan het telefonieverkeer met voldoende kwaliteit afgehandeld worden. De configuratie als geleverd is voldoende om alle beschikbare radiokanalen actief te maken. In absolute zin houdt dit in dat er 14 simultane gesprekken met een goede kwaliteit mogelijk zijn.


pag 9 van 46


4.5

Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC Het gekozen IP plan heeft probleemloos gefunctioneerd. Tijdens de veldtest zijn er geen feiten ontstaan die enige afwijking van de normaal zouden kunnen indiceren. Voor vervolgfases zou er geen aanpassingen op het IP plan nodig hoeven te zijn.

5

Systeem architectuur: Nummerplan

5.1

Vraagstelling Op welke wijze kan een nummerplan worden opgezet welke bruikbaar is om aangeleverde (en dus reeds in gebruik zijnde) mobiele nummers te koppelen aan uit te geven, niet geografisch gebonden publieke telefoonnummers?

5.2

Gerealiseerde oplossing Er is een nummerblok van honderd stuks 085-nummers (31852012350 t/m 31852012449) gereserveerd voor PoC GSM. Deze nummers worden via de RadioAccess pop-locatie door een IAX2 trunk gerouteerd naar de GSM server. Door de originele 06-nummers als gekoppelde identiteit te configureren kan een bestaande GSM met in het toestel een CFNRC (Call Forward Not Reachable) bereikt worden op zijn originele 06-nummers op het eigen netwerk maar ook op het privé GSM netwerk. Het privé GSM netwerk biedt naast het 06-nummer ook bereikbaarheid via het extra 085-nummer. Uitbellen vanaf het privé GSM netwerk geschiedt door het meezenden van het toegewezen 085-nummer.

5.3

Gehanteerde randvoorwaarde voor deze oplossing Het vanaf vaste KPN en/of mobiele grote partijen (KPN, Vodafone, T-Mobile) bereikbaar zijn is afhankelijk van het wel of niet aanwezig zijn van de BGAN verbinding. Deze zorgt in het veld voor de verbinding naar het “vaste land” en dus de daadwerkelijke verbinding naar de pop-locatie in Den Bosch.

5.4

Resultaat van veldtest met deze oplossing Het bellen met de 085-nummers naar de buitenwereld en gebeld worden op deze nummers wordt als positief ervaren door de meerderheid van de gebruikers.

5.5

Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC. Aan het begin van de oefening en de start van het gebruik van de privé telefonie merkt de gebruiker dat er een tijdsverschil zit tussen de originerende en terminderende partij. Dit wordt in het begin als hinderlijk ervaren en vaak zie je dan ook dat gebruikers vaak vragen “wat zeg je?”. Na enige tijd “went” men aan dit fenomeen. De door gebruikers opgemerkte vertraging is volledig te wijten aan de grote afstanden (71.400km als gevolg van de up- en down link van en naar de satelliet)) welke door de IAX2 trunk afgelegd moet worden wat op IP nivo een vertraging van ongeveer 1200 milliseconden oplevert.

6

Systeem architectuur: SW versies modules

6.1

Vraagstelling Nvt

6.2

Gerealiseerde oplossing MSC: Windows 2003 Server WE patch 2 MSC applicatie 2.0.0.15 Router/BSC/SIP gateway


pag 10 van 46


Linux Centos 5.4 Router ip-tables BSC applicatie 4.1.1 Asterisk 1.4.x PTT server Linux Centos 5.4 Celtius poc_server 2.7.27 (RPM) Celtius poc_client 2.2.0 (Symbian) 6.3

Gehanteerde randvoorwaarde voor deze oplossing nvt

6.4

Resultaat van veldtest met deze oplossing nvt

6.5

Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC nvt

7

Gebruikte antennes en antennehoogte

7.1

Vraagstelling Hoe kan met behulp van twee masten de gewenste dekking op het oefenterrein gerealiseerd worden? De functionele eis was dat de plaats van de gesimuleerde brand en het CoPi (Commando Plaats Incident) van dekking moet worden voorzien. Het oefenterrein is aangegeven op de kaart hieronder. Later is een deel van de MOB Complex aan de dekkingseis toegevoegd omdat een deel van de gebruikersgroep (oefenleiding Brandweer) zijn werkzaamheden op het terrein van het MOB-complex verrichtte.


pag 11 van 46


Figuur 3 : Topografische kaart van het oefenterrein, met daarop ingetekend de locatie van de brand en het CoPi.

7.2

Gerealiseerde

Oplossing Voor details betreffende de gebruikte masten zie paragraaf 11. 7.2.1

Ontwerpschema Mast 1


pag 12 van 46


Figuur 4 : Schematische weergave van mast 1.


pag 13 van 46


Ontwerpschema Mast 2

Figuur 5 : Schematische weergave van mast 2.


pag 14 van 46


7.2.2

Mast Locaties – Eerste Testdag Op de eerste testdag in Ede werden onderstaande mastlocaties gebruikt. De dekking is gemeten met een meettelefoon en niet geregistreerd met de pentablet. Tijdens de metingen werd al snel duidelijk dat de dekking op het open heide gebied goed was. In de bossen was de dekking redelijk tot onvoldoende. In het noord-oosten van het gebied was de dekking onvoldoende. Tevens kwam het verzoek om een deel van het MOB Complex van dekking te voorzien. Er is daar gemeten maar de signaalsterkte was op zijn best onvoldoende, op de meeste plaatsen was geen signaal aanwezig.

Figuur 6 : Top overzicht van het oefengebied op testdag 1

Locatie Mast 1

Locatie Mast 2

Figuur 7 : Detailoverzichten van de mastlocaties op testdag 1


pag 15 van 46


7.2.3

Mast Locaties – Tweede Testdag De resultaten van de metingen van deze dag staan in paragraaf 7.4.5.

Figuur 8 : Top overzicht van het oefengebied op testdag 2

Locatie Mast 1

Locatie Mast 2

Figuur 9 : Detailoverzichten van de mastlocaties op testdag 2

7.3

Gehanteerde randvoorwaarde voor deze oplossing Het doel was dekking te creëren met de apparatuur die standaard door RadioAccess geleverd worden en geen gebruik te maken van high power producten.

7.4

Resultaat van de veldtest van deze oplossing

7.4.1

Toegepaste Apparatuur en Software Voor de meting is de volgende apparatuur en software gebruikt:  Sagem type OT290M GPRS engineering telephone  Toshiba Portégé pentablet computer  Agilent E6474A Wireless Network Measurement Software v.14.0.


pag 16 van 46


7.4.2

Meetprocedure De metingen zijn uitgevoerd met een engineering telefoon die de sterkte van het signaal meet. De telefoon is aangesloten op een pentablet computer. In de computer is een gedigitaliseerde plattegrond geladen van de te meten verdieping(en) of de te meten omgeving. Door tijdens de meting aan te geven waar men zich bevindt op de plattegrond, wordt de meetdata gerelateerd aan een bepaalde positie en kunnen plots van de metingen worden gemaakt. De metingen worden via een automatisch script in de Agilent software uitgevoerd. Alle data wordt in één log bestand (*.aod file) opgeslagen. De log bestanden worden bewaard en kunnen op een later tijdstip weer afgespeeld worden

7.4.3

Legenda Rx-Lev (Sub) Signaalsterkte -60

tot

0

dBm

Zeer goed

0 t/m

2

Goed

-70

tot

-60

dBm

Goed

3 en

4

Acceptabel

-80

tot

-70

dBm

Voldoende

5 t/m

7

Onvoldoende

-85

tot

-80

dBm

Acceptabel

-90

tot

-85

dBm

Onvoldoende

-100 tot

-90 100

dBm

Slecht

dBm

Zeer slecht

-110 tot 7.4.4

Rx-Qual (Sub) Signaalkwaliteit

Details Opstelpunten Informatie Algemeen

Opstelling

Mast 1

Mast 1

Mast 2

Mast 2

Kathrein

Kathrein

Kathrein

VTorch

MCC

69

Antenne

NCC

69

Type

Omni

Omni

Paneel

Omni

BTS Tx Pwr

13 dBm

Gain

11 dBi

0 dBi

18 dBi

0 dBi

BTS 1 – kanaal

878

Hoogte

10 m

2.5 m

6m

2.5 m

BTS 2 - kanaal

872

Input Power

30 dBm

10 dBm

28 dBm

10 dBm

EIRP

41 dBm

10 dBm

46 dBm

10 dBm


pag 17 van 46


7.4.5

Plots De gemeten radioveldsterkte (RxLev) in het veld is in onderstaande plot weergegeven

Figuur 10 : Gemeten signaalniveau in het oefenterrein


pag 18 van 46


De gemeten verbindingskwaliteit (RxQual) in het veld is in de volgende plot weergegeven

Figuur 11 : Gemeten signaalkwaliteit in het oefenterrein.

De Cell ID‟s waarop de meetontvanger zich heeft geregisteerd is op volgende plot weergegeven( Rood = Mast 1, Blauw = Mast 2)

Figuur 12 : Overzicht celregistratie in het oefenterrein


pag 19 van 46


7.5

Ervaring, conclusies en adviezen Mast 1 met de omni-antenne (11 dBi, Kathrein K738187) op 10m hoogte had een boven verwachting goede performance en kon zelfstandig het hele terrein van goede signaalsterkte en goede signaalkwaliteit voorzien. Het signaal was zelfs dominant bij het CoPI dat op 1.5 km van Mast 1 stond. Mast 2 met de paneel antenne (18 dBi, Kathrein K742215) op 6m hoogte had een beduidend minder goede performance dan verwacht. Uit een redelijk uitgebreide meting op de 2e demonstratie dag (17-April-2010) met enkel een meettelefoon bleek dat die dag de signaalsterkte beter was dan tijdens de 2e testdag. De „geringe dekking‟ en verschil tussen de metingen werd waarschijnlijk veroorzaakt door de geringe hoogte van de antenne en de problemen om de tilt goed te krijgen. Antennes met een hoge gain hebben een kleine verticale openingshoek en zijn dus erg gevoelig voor tilts. Een uptilt van enkele graden is al voldoende om ervoor te zorgen dat de hoofdbundel van de antenne de grond mist. Op het einde van de 2de demonstratiedag leek de signaalsterkte minder te worden. Beide kisten met de apparatuur waren erg warm van binnen. Met name de boosters bleken erg warm te zijn geworden en zouden de oorzaak van de verminderde signaalsterkte kunnen zijn. Verder bleek de een van de antennemasten iets schuin te staan waardoor een tilt in de stralingsbundel leek te ontstaan waaroor op grotere afstand de veldsterkte minder was dan voorspeld. Gezien de goede kwaliteit van de rondstraler (omni-antenne) enerzijds en anderzijds de smalle openingshoek van de paneelantenne en daarmee gepaard gaande noodzakelijke handelingen om deze antenne uit te richten op het gebied dat radiodekkend moet worden, gaat de voorkeur uit naar de inzet van de gebruikte high gain rondstraler.

8

Satelliet backhaul

8.1

Vraagstelling Hoe kan men zoveel mogelijk gesprekken over beperkte bandbreedte transporteren en acceptabele spraakkwaliteit behouden. Doel van de opzet is om geen “streaming mode” van BGAN te hoeven gebruiken om zo de kosten te reduceren. Nevendoel van de opzet is om minimaal 14 gesprekken te kunnen garanderen met de beschikbare bandbreedte.

8.2

Gerealiseerde oplossing

Spraakkwaliteit Voor de spraak codecs over de satelliet is er gekozen voor AMR mode 1 dat gelijk staat aan 4,75kbit/s aan audio informatie. Vastgesteld is dat de AMR codec kwalitatief beter werkte dan de overige geteste lage bitrate codecs. Het is echter wel zo dat er meer van de CPU capaciteit geëist wordt dan bij bijv. G729a codecs. Aangezien de spraak over een link met veel vertraging wordt getransporteerd en er een zekere inconsistentie in jitter aanwezig is, is er gekozen voor een jitter buffer die begint bij 500ms. Dit geeft een extra vertraging in de lijn, maar zorgt er wel voor dat spraak vloeiender overgebracht wordt.


pag 20 van 46


Capaciteit Om de capaciteit over BGAN maximaal te benutten is er gekozen voor een IAX2 trunking opzet. Een van de grote voordelen van deze setup ten opzichte van SIP is dat alle voice streams in hetzelfde pakket samengevoegd worden. Hierdoor wordt de additionele overhead bij elke stream voorkomen, waardoor het bandbreedte verbruik drastisch verkleind wordt. De pakketten worden ook nog eens in plaats van de standaard interval van 20ms iedere 40ms verstuurd. Ook dit zorgt voor veel minder overhead informatie. Het is gebleken dat op deze manier met een satelliet bandbreedte van 128kbit/sec er 14 gelijktijdige gesprekken gerealiseerd kunnen worden. 8.3

Gehanteerde randvoorwaarde voor deze oplossing De kwaliteit van de satelliet link dient minimaal 40 dBM te zijn en daarvoor is een goede open zicht verbinding nodig naar het zuiden. Enige aandacht bij het uitrichten van de satelliet verbinding alvorens deze te activeren, is daarvoor noodzakelijk.

8.4

Resultaat van veldtest met deze oplossing Resultaten zijn positief ervaren en er zijn geen bijzondere issues naar voren gekomen behalve de bekende satelliet vertraging waar men aan moest wennen.

8.5

Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC De conclusie van het werken met bovengenoemde opzet is dat er geen additionele aanpassingen nodig zijn voor de volgende fase van het project. Er is maximaal resultaat gehaald uit de beschikbare bandbreedte en de daarachter liggende techniek. Opgemerkt moet worden dat er tijdens de oefening nooit het maximale aantal van 14 externe gesprekken gehaald is.

9

Push to Talk over Cellular: Server en Applicatie

9.1

Vraagstelling

Realiseer een portofoonachtige omgeving middels GPRS welke het portofoonnetwerk zou kunnen vervangen 9.2


Met behulp van de Celtius gebaseerde Push-To-Talk server is een portofoonachtige omgeving nagebouwd. De server is opgebouwd rond een Linux gebaseerd systeem welke het centrale punt vormt voor alle mobiele clients. Het tijdslot waarin de functionaliteit gerealiseerd moest worden heeft er toe geleidt dat er kozen werd voor Celtius. Deze partij was de enige die binnen afzienbare tijd een werkend geheel kon leveren en was ook de enige partij die een kant en klaar produkt kon leveren. Er is een aparte server in het systeem opgenomen om er zeker van te zijn dat alle beschikbare resources tbv PTT zouden kunnen worden gebruikt. Commercieel vertrouwelijk

pag 21 van 46


Theoretisch had de PTT server applicatie op het eerste Linux platform (BSC) bijgezet kunnen worden. Aan gebruikerszijde is vanuit compatibiliteitsoverwegingen de Nokia E52 als end-user device gebruikt. Het systeem vereist, achteraf geconstateerd, een gebied met een hoge (data-) dekkingsgraad. Op plaatsen waar de spraakdekking nog afdoende was, bleek de datadekking niet meer toereikend te zijn. Dit werd veroorzaakt door het feit dat de PTT applicatie nogal veeleisend is betreffende data-throughput. De Nokia E52 moest op kritische afstanden veel hertransmissies uitvoeren dat er toestelproblemen ontstonden.

9.3

Gehanteerde randvoorwaarde voor deze oplossing IVENT heeft aangegeven een PTT test te willen uitvoeren met end-user devices van het merk Sonim. Deze toestellen bieden deze functionaliteit alleen in combinatie met een Sonim PTT server. Sonim heeft echter nog geen werkende PTT server voor kleinschalige toepassingen (zoals deze trial). Een hosted oplossing die Sonim wel biedt, is echter voor deze stand-alone trial in het veld daarop geen optie. Hoewel Sonim claimt dat de toestellen voldoen aan de OMA PoC (Open Mobile Alliance Push to talk Over Cellular), bleken Sonim en Celtius niet in staat om op afzienbare termijn een interoperable combinatie op te leveren. De te realiseren PTT oplossing behoeft niet dezelfde solide performance en functionaliteit te bieden als de bij de hulpdiensten in gebruik zijnde traditionele analoge dan wel C2000 portofoons

Er moet een mobiel datanetwerk aanwezig zijn welke voorziet in voldoende dekking. De minimale ontvangstwaarde moet in de orde van grootte van -75dBm zijn. 9.4

Resultaat van veldtest met deze oplossing

Met lagere signaal waardes (<-75dBm) kan de Celtius client moeilijk danwel niet overweg wat resulteert in veel herttransmissies. De applicatie en de CPU van het toestel hebben hier veel moeite mee. Uiteindelijk leidde dit tot een noodzakelijke toestel herstart. Verschillende gebruikers viel het op dat er regelmatig een significante vertraging tussen het inspreken en afspelen van berichten bestond. Dit leidde niet direct tot problemen maar werd wel aangemerkt als punt van aandacht. De audiokwaliteit mocht een voldoende krijgen en was zeker acceptabel te noemen.

9.5

Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC

Push-to-talk is een service welke over een bearer getransporteerd wordt welke zelf geen Quality of Service ondersteund. Hierdoor is er slechts een marginale tot geen garantie af te geven voor de functionaliteit van de PTT


pag 22 van 46


service. In het bijzonder aan de rand van het data dekkingsgebied waar de signaal ruis verhouding voor GPRS kritisch begint te worden neemt de kwaliteit en de betrouwbaarheid van de PTT dienst snel af. Bij voldoende dekking, welke gerealiseerd kan worden door een goede radioplanning/ontwerp werkt de applicatie naar alle redelijkheid. Het installeren van de PTT server en het activeren van de PTT clients heeft relatief veel inspanning gekost. Hier zijn enkele lessons learned uit naar voren gekomen. Beseft moet worden dat de PTT server een evaluatieversie betrof die niet 100% compleet was vwb de user provisioning (trial versie). Van belang is in dat geval dat de verwachtingen van de gebruikers te managen. PoC is geen volledige vervanging of alternatief van reguliere portofoonnetwerken, het biedt slechts point-to-multipoint communicatie, net zoals portofoonnetwerken. Gezien we belangrijke wens dat de toestellen gebruikt voor PTT van degelijke kwaliteit zijn en Sonim een van de zeer weinige leveranciers op dit gebied is, zal een nieuwe PTT test gedaan moeten worden zodra Sonim haar PTT server beschikbaar heeft voor kleinschalige inzet. Volgens Sonim zal dat einde Q2 2010 zijn.

10

Push to Talk over Cellular: Toestellen

10.1

Vraagstelling

Welke PTT toestellen zijn bruikbaar voor de PTT service op het privé GSM netwerk, die ook als normaal GSM toestel gebruikt kunnen worden 10.2


Omdat de PTT applicatie uitsluitend werkt op Symbian S60 series software is de keuze in toestellen niet erg uitgebreid. Op basis van een kort marktonderszoek is er gekozen voor de Nokia E52. Hierop is de PTT client geïnstalleerd en geactiveerd. Het voor deze proef gebruikte E52 toestel is een uitgebreid toestel dat licht en compact is en functies biedt voor met name zakelijk gebruik. Voor buitentoepassingen en voor gebruik onder zwaardere omstandigheden is dit toestel minder geschikt. Het audiovolume is onvoldoende, de toetsen zijn relatief klein en in het zonlicht is het display ook moeilijker af te lezen.


pag 23 van 46


Figuur 13 : Gebruikte Push To Talk toestel, Nokia E52

10.3

Gehanteerde randvoorwaarde voor deze oplossing

Defensie heeft aangegeven een test te willen doen met de stevige Sonim toestellen. Sonim was echter niet in staat om (op afzienbare termijn) een toestel te kunnen leveren dat zou samenwerken met de Celtius PTT applicatie. Daarmee viel de keuze voor deze Sonim toestellen helaas af. 10.4

Resultaat van veldtest met deze oplossing

Met de Nokia E52 als PTT toestel was duidelijk niet enige tevredenheid geschapen. Het toestel is voor menigeen te fragiel en is niet echt een “veldtoestel” . 10.5

Ervaring, conclusies, adviezen en input voor volgende fase(s) voor PoC

De eigenschap „ruggedized‟ kan niet aan dit toestel toegewezen worden waarmee het al snel als een kantoortoestel aangemerkt moet worden. De functionaliteit is weliswaar helemaal aanwezig echter blijft het toestel “te mooi voor in het veld”. Bij extreme omstandigheden hoort gewoon een toestel met grote knoppen.

11

Gebruikte antennemasten, pGSM Core behuizing en stroomvoorziening

11.1

Vraagstelling De fysieke aspecten en voeding van de gebruikte opstelling: wat is er naast de netwerkapparatuur gebruikt om het pGSM netwerk tot stand te brengen?

11.2

Gerealiseerde oplossing Om de apparatuur op de twee locaties op te stellen en van voeding te voorzien is er gebruik gemaakt van: Locatie 1: Antennemast: Mechanische telescoopmast op basis van een aanhangwagenplatform, voorzien van een spatwaterdichte bak voor de plaatsing van apparatuur.


pag 24 van 46


De mast is gebruikt voor het opstellen van de richtantenne, WaveIP unit en een omnidirectionele antenne om het gebied achter de richtantenne van dekking te voorzien. Aggregaat: 220V, 2,5kW, voorzien van trekstarter Levert voeding voor core-, radio- en transmissieapparatuur. Er was ruim voldoende capaciteit om naast de GSM apparatuur diverse andere apparatuur te voeden, zoals de laptop(s) die gebruikt werden voor het monitoren en configureren van het netwerk en het opladen van testtelefoons. pGSM Core behuizing: Het core-deel van de testopstelling is gemonteerd in een niet afgesloten Hardigg case voorzien van een 19” server rack. Alle patching tussen de elementen van het core-deel kan intern in de behuizing worden gedaan, hierdoor is er bij gebruik van een gesloten behuizing alleen kabeldoorvoer voor de externe aansluitingen (voeding & Ethernet) nodig. De core is tijdens gebruik opgesteld in een auto welke op ongeveer 10 meter van de mast geparkeerd stond. Locatie 2: Antennemast: Pneumatische telescoopmast op basis van een aanhangwagenplatform, voorzien van kantelmechanisme en een spatwaterdichte bak voor de plaatsing van apparatuur. De mast is gebruikt voor het opstellen van de omnidirectionele antenne en WaveIP unit Aggregaat: 220V, 1kW, voorzien van trekstarter Levert voeding voor radio- en transmissieapparatuur.

11.3

Gehanteerde randvoorwaarden Locatie 1: Voldoende ruimte voor het plaatsen van de antennemast met tuien, aggregaat en auto met daarin de pGSM core. De afstand tussen mast en core moet minder zijn dan 100 meter in verband met de koppeling via een twisted pair Ethernet kabel. Er moet vrij zicht op de satelliet zijn wanneer er gebruik gemaakt wordt van een satellietbackhaul. Locatie 2: Voldoende ruimte voor het plaatsen van de antennemast met tuien en het aggregaat. Overig: Tussen locatie 1 en locatie 2 is een line of sight nodig voor een goede werking van de straalverbinding. Er moest op beide locaties voldoende afstand van de wegen gehouden worden om hinder bij de oefening te voorkomen.

11.4

Resultaat Opbouw van apparatuur op locatie Mast locatie 1:


pag 25 van 46


De benodigde tijd en mankracht voor het opstellen van deze mast is door het ontbreken van een kantelmechanisme sterk afhankelijk van de te plaatsen antennes. Bij het gebruik van een lichtgewicht antenne, welke verticaal geplaatst kan worden met behulp van een ladder, kan de opstelling door 2 man in ongeveer 25-30 minuten plaatsvinden. Wordt er gebruik gemaakt van een zwaardere antenne, dan zal de aanhangwagen gekanteld moeten worden om de antenne te plaatsen. De toename in benodigde tijd is voor een groot deel afhankelijk van de ervaring van het bedienende personeel. Een ervaren team van 3 mensen kan de opstelling echter nog steeds in 30-35 minuten realiseren. Mast locatie 2: Deze mast is voorzien van een kantelmechanisme en kan zodoende in de meeste situaties door een team van 2 man opgesteld worden. Dit kan in ongeveer 20 minuten worden gerealiseerd. Wanneer er meer mensen beschikbaar zijn kan deze tijd worden verkort aangezien diverse handelingen gelijktijdig uitgevoerd kunnen worden. De bovengenoemde tijden zijn gebaseerd op de tijd die nodig is vanaf het moment dat de aanhangwagen geplaatst is, dit omdat de tijd benodigd voor de plaatsing zelf sterk afhankelijk is van de omgeving waarin de antenne opgesteld wordt. pGSM core: De testen zijn positief afgerond, alle apparatuur start correct op na het booten. De apparatuur hoefde alleen aangesloten te worden op de voeding en met een netwerkkabel aan de radioapparatuur gekoppeld te worden en kon zodoende in enkele minuten aangesloten en opgestart worden. 11.5

Ervaring, conclusies & advies De opbouw van een (vooraf geconfigureerd) mobiel pGSM netwerk kan in zeer korte tijd gerealiseerd worden. Van aankomst op locatie tot het in de lucht hebben van een volledig werkend netwerk is meerdere malen in een tijdsbestek van ongeveer een uur en een kwartier gerealiseerd. Het bleek wel uiterst belangrijk te zijn dat de BGAN was aangesloten en draaide voordat de servers werden opgestart ivm de DHCP-functie (dynamisch uitdelen van IP-adressen aan de router-server). Tijdens de opbouw was er maar één geschikt voertuig beschikbaar om de masten naar de opstellocatie te brengen. Hierdoor was het noodzakelijk om diverse malen op en neer te rijden en de aanhangers af- en aan te koppelen. De opbouwtijd van het pGSM netwerk kan worden verkort door inzet van de juiste middelen. Voor een snelle inzet geniet een pompmast met een kantelmechanisme de voorkeur. Hierbij is de opbouwtijd aanzienlijk korter en minder afhankelijk van de gebruikte antenne. Dit masttype is ook met minder mankracht te plaatsen. Het gebruik van gemechaniseerde middelen in combinatie met geroutineerd bedienend personeel en goed opgestelde procedures, moet het maken het opbouwen van twee masten in minder dan een uur te realiseren. Een aandachtspunt bij het gebruik van de pneumatische mast is dat er perslucht, compressor of pomp nodig is voor het uitschuiven. Tijdens de opbouw bleek de gebruikte persluchtcilinder niet toereikend te zijn voor het aantal malen dat het nodig was om de mast uit te schuiven. Het gebruik van een compressor of het hebben van een pomp als back up is daarom aan te raden. Voor de toekomstige deployment van een pGSM-systeem door de Defensie dienen GSM en IP-straalverbindingsantennes gemonteerd te worden op de standaard door Defensie gebruikte zogenaamde steekmasten of op de bij Defensie in gebruik zijnde pneumatische


pag 26 van 46


telescoopmasten. Geoefend personeel is daarmee in staat pGSM systemen snel en doeltreffend op te bouwen waar ook ter wereld.


pag 27 van 46


12

Schaalbaarheid en Flexibiliteit vanuit diverse invalshoeken

12.1

Vraagstelling Wat is de schaalbaarheid en flexibiliteit van het complete netwerk? Deze vraagstelling geldt zowel voor het gerealiseerde pGSM-systeem als overige aspecten zoals de gebruikte masten en de bediening van het systeem. Daarnaast moet worden bepaaldhoe dit concept in te zetten is bij grootschalige OOV activiteiten, waarbij deze systemen op een aantal centrale locaties in Nederland in opslag staan in afwachting van een inzet op locatie.

12.2

Gerealiseerde oplossing Zoals eerder in dit document beschreven is een volledig stand-alone GSM netwerk gerealiseerd dat zowel met eigen SIM kaarten functioneert als met SIM kaarten van andere providers. Het beproefde systeem was voorzien van twee ip.access nanoBTSen. Technische capaciteiten van het pGSM systeem. De gebruikerscapaciteit van de gerealiseerde oplossing betrof maximaal 50 SIM kaarten. Deze grens is gekozen vanwege het beperkte karakter van het experiment. Technisch gezien kan de gerealiseerde oplossing (met twee servers) ca. 500 SIM kaarten bedienen. Hierbij wordt uitgegaan van een normale gesprekslast van 0,13 Erlang per gebruiker (dit wil zeggen dat van de 13 gebruikers er voordurend gemiddeld één gesprek gevoerd wordt). Bij calamiteiten zal deze verkeerslast echter een veelvoud zijn van de hier genoemde 0,13 Erlang. Daardoor zal de capaciteit van één server dus lager liggen. Naast de capaciteit van de server is er ook nog een andere bottleneck: de capaciteit van elke BTS. In de hier gebruikte configuratie kon elke BTS maximaal 7 gelijktijdige gesprekken verwerken. Voor de totale configuratie konden dus 2 x 7 = 14 gesprekken gelijktijdig gevoerd worden. Eén server is daarmee in staat ca 9 [(500 x 0,13)/7] BTSen te bedienen. Door toepassing van HalfRate codering in de air-interface in plaats van de normale Full Rate, is de gesprekscapaciteit per nBTS te verdubbelen. Echter de pGSM sever kan dan echter een lager aantal concurrent calls verwerken, in verband met de extra (de)codering die plaatst dient te vinden. In geval van toepassing van HalfRate is de inschating dat 50 concurrent calls gevoerd kunnen worden. In het kader van het verhogen van de betrouwbaarheid in functioneren is alle apparatuur zodanig geconfigureerd dat het geheel automatisch kan opkomen na een onverwachte “power off”.


pag 28 van 46


Overige aspecten Personeel De testen zijn doorlopen met behulp van de inzet van personeel van de leverancier van het pGSM systeem. Het personeel heeft tijdens de beproevingen het systeem opgebouwd en bediend. Dat gold zowel voor het plaatsen en opbouwen van de masten evenals het in bedrijf stellen en houden van het systeem. Dit personeel moet als specialist worden beschouwd. Bij het ontwikkelen van een operationeel systeem zal gestreefd moeten worden naar het ontwikkelen van oplossingen die uitblinken in eenvoud voor installeren, bedienen en onderhouden. Materieel Voor de masten is gebruik gemaakt van een aanhangwagen met liermast van de leverancier en aanhangwagen met een pompmast (op persluchtdruk) die was geleend van het Rode Kruis. Een geoefende ploeg van 3 man kon deze masten in één uur tijd opzetten. De GSM-core bestaat uit drie 19” servers. Van deze drie servers leverden twee servers de daadwerkelijke GSM-core (inclusief een voicelogger), de derde server deed dienst als PTTserver. Zonder PTT kan de GSM-core bestaan uit 2 servers. Voor het experiment zijn deze ingebouwd in een oude TITAAN serverkast zonder voor en achterzijde. De GSM-core kan ook in een Application Server Box (ASB) worden ingebouwd. 12.3

Ervaring, conclusies, adviezen en input voor een vervolgfase.

Afhankelijk van de snelheid waarmee systemen inzetbaar moeten zijn zal gekozen moeten worden voor het gebruiken van een mast die achterop een voertuig is gemonteerd of in een aanhangwagen is geplaatst. Voor een allround systeem lijkt een getuide pompmast van met een maximale hoogte van 15 m voldoende. Bij de keuze voor wel of geen aanhangwagen moet wel worden meegewogen dat het overige materiaal (antennes, kabels, kleine 19” kast voor de GSM-core en een aggregaat van 2,5 kW) mee moet worden getransporteerd. Zoals al vermeld in paragraaf 7.5 lijkt de keuze voor een rondstralende antenne de meest flexibele oplossing te bieden. Voor de definitieve oplossing zal nog een keuze moeten worden gemaakt waarbij voorzien wordt in een of volledig ingebouwde GSM-core in een shelter of een volledig afsluitbare en draagbare oplossing (Application Server Box) met robuuste aansluitingen voor antennekabels, voedingskabels en data kabels (UTP/FTP). De grootste uitdaging van de toepassing van dit concept is het van te voren bekend zijn van (gebruikers van) de toestellen die geautoriseerd zijn om zich aan te melden. De ontwikkelde database GRSOOV is zodanig ontworpen dat deze kan worden opgeschaald. Door een definitieve keuze te maken voor waar de database zal worden gehost onder het gelijktijdig oprichten van een stukje technisch en functioneel beheer, kunnen in theorie alle hulpverleners in NLD (beroeps of vrijwilliger) hun gegevens


pag 29 van 46


gaan aanleveren. Met deze gegevens kunnen dan één of meerdere pGSMsystemen worden geladen voor een eventuele inzet. In het geval er meerdere GSM-cores van het beproefde pGSM-systeem in Nederland worden ingezet, is niet bekend welke gebruikers zich op welk systeem zullen gaan aanmelden. Wordt bovendien een extra gebruiker op één systeem toegevoegd, zal deze zich idealiter ook moeten kunnen registeren op een van de andere pGSM systemen. Om dit te bewerkstelligen lijkt een zogenaamd „Distributed HLR‟ concept noodzakelijk. De database met geautoriseerde gebruikers (de HLR, Home Location Register) zal in dat geval automatisch bij gewerkt worden in allen systemen (zolang er een IP verbinding beschikbaar is tussen de systemen). Een dergelijk concept is in de GSM-wereld nog niet gerealiseerd maar zou, op basis van het feit dat er wereldwijd volop met gedistribueerde databases wordt gewerkt, wel haalbaar moeten worden geacht. Het is een aantal keer voorgekomen dat de BGAN later is opgestart dan de servers en als gevolg daarvan krijgen de servers geen IP-adres van de BGAN. Hierdoor is er een handmatige herstart van de netwerk interface nodig. Wellicht dat deze interface in de toekomst statische ip adres kan krijgen, zodat er geen misverstanden ontstaan bij het opstarten.

13

Beheer van systeem in het veld

13.1

Vraagstelling Hoe kan het pGSM systeem ingericht worden zodat controle van functionaliteit en performance mogelijk is en aangepast kunnen worden naar de behoefte zonder dat er hiervoor al te zeer gespecialiseerd personeel voor hoeft te worden ingezet?

13.2

Gerealiseerde oplossing De bediening van de GSM-core vindt plaats door middel van een koppeling van een laptop en inloggen op het beheersportaal van de PMN applicatie. Ter plaatse moeten er mutaties plaats kunnen vinden van te autoriseren SIM kaarten. De diverse subsystemen op de server subsystemen van het pGSM-systeem zijn te gebruikersonvriendelijk om door onervaren beheerpersoneel te laten bedienen. Daarnaast is het mogelijk om de systemen zodanig te veranderen dat de correcte werking van het systeem in het gedrang komt.

13.3

Gehanteerde randvoorwaarde voor deze oplossing Mutaties dienen met een 1e lijns opleiding te kunnen worden aangebracht


pag 30 van 46


13.4

Resultaat van veldtest met deze oplossing Tijdens de veldtest is voortdurend de performance van het pGSM systeem gemonitord. Door de ervaringen die eerder op zijn gedaan waren ten tijde van de demo dagen op 10 en 17 april geen wijzigingen in de configuratie noodzakelijk. Op verzoek zijn tijdens de demodagen op 10 en 17 april enkele gebruikers die zich niet van te voren via de web portal (GRSOOV) hadden aangemeld toch succesvol toegevoegd aan de pGSM core waarna deze gebruikers alle functionaliteit ter beschikking stond.

13.5

Ervaring, conclusies, adviezen en input voor volgende fase van

PoC. Het is noodzakelijk dat er een „softwarematige schil‟ om het systeem heen gebouwd wordt waarmee op bedienaarniveau allerlei relevante zaken kunnen worden ingesteld en geregeld maar waardoor het onmogelijk wordt gemaakt om kritische systeem instellingen te wijzigen. Een 1e lijns training op het gebied van pGSM technologie en het PMN beheersportaal is een voorwaarde voor het kunnen beheren van een pGSM netwerk in het veld. Voor het pGSM systeem in het veld dienen diversie niveaus van toegang cq bediening beschikbaar te worden gesteld:  Beheer op „veld niveau‟ met alleen de mogelijkheid tot het aanbrengen van eenvoudige mutaties: zogenaamde „Moves, Adds and Changes‟ . Tevens moet het op dit niveau mogelijk zijn om de SMS broadcast functionaliteit te bedienen.  Support op 1e lijns niveau voor eenvoudige diagnoses en mutaties. Bij voorkeur kan dit niveau van support ook op afstand plaats vinden mits er een IP verbinding met de betreffende server beschikbaar is.  Support op 2e lijns niveau voor complexe diagnoses en systeem aanpassingen


pag 31 van 46


14

GRSOOV applicatie en website

14.1

Inleiding

14.1.1

Doel De doelstelling van de opdracht is het ontwerpen en ontwikkelen van de applicatie GRSOOV (Gegevens Registratie Systeem Openbare Orde en Veiligheid). Deze applicatie stelt hulpverleners in staat om vanaf het internet een formulier in te vullen met persoonsgegevens en de gegevens van zijn of haar mobiele telefoon, waarbij het formulier naar het Defensie intranet wordt verstuurd via een email om vervolgens in een applicatie ingelezen en opgenomen te worden. De applicatie moet onder andere in staat zijn de (gestructureerde) emails in te lezen en de gegevens die door de gebruiker vanaf internet worden verstuurd op te slaan in een relationele database. Voor de functionele eisen en wensen van de applicatie en het in kaart brengen van de randvoorwaarden en uitgangspunten is dit Programma van eisen opgesteld. Aan de hand van dit Programma van eisen kan een urenschatting gegeven worden voor totale bouw.

14.1.2

Documentopbouw In paragraaf 14.2 worden de uitgangspunten en voorwaarden aangegeven. In paragraaf 14.3 worden de verschillende entiteiten (tabellen) uiteengezet, dit zijn de gegevens die moeten worden opgeslagen, en acties (functies) die hierop moeten worden uitgevoerd. In paragraaf 14.4 staan de overige functies die het systeem moet kunnen uitvoeren. In paragraaf 14.5 staat de MOSCOW (Must Should Could Would) lijst ten behoeve van afbakening van fases van ontwikkeling.

14.2

Uitgangspunten en randvoorwaarden De applicatie moet correct functioneren in de volgende browsers: Internet Explorer 6 (muv internet-deel), 7 en 8 en Mozilla Firefox 2 en 3.


pag 32 van 46


De applicatie moet volgens de W3C webstandaarden worden gemaakt. De website dient geoptimaliseerd te zijn voor de beeldschermresolutie 1024 x 768 pixels. Er wordt uitgegaan van 088 bedrijfsnummers (companynumbers). De applicatie bestaat uit een intranet (data, logica en beheer-weergave) en internet (hulpverlener weergave en invoer validatie) deel. (Zie afbeelding hiernaast) De applicatie moet de beschikbaarheid hebben over een POP3-emailbox waarop de externe emails binnenkomen. De applicatie aan de internet kant moet gehost worden op een https omgeving. Het protocol HTTPS staat voor HyperText Transfer Protocol Secure. HTTPS is een uitbreiding op het HTTP-protocol met als doel een veilige uitwisseling van gegevens. Bij gebruik van HTTPS wordt de data versleuteld, waardoor het voor een buitenstaander, bijvoorbeeld iemand die afluistert, onmogelijk zou moeten zijn om te weten welke gegevens verstuurd worden. Voor het internet deel wordt uitgegaan van de domeinnaam http://(www).grsoov.nl Voor het intranet deel wordt uitgegaan van de domeinnaam http://grsoov.(opendev.)mindef.nl Voor gebruikersondersteuning wordt gebruik gemaakt van een project op de Proeftuin Beheerloket Defensie.


pag 33 van 46


14.2.1

Afhankelijkheden Voor het intranet deel van de applicatie is een webhostingsplaftorm conform de standaard eisen lijst zoals gedefinieerd op de OpenDev Wiki vereist. Voor het internet deel van de applicatie is een webhostingsplatform vereist waarbij de volgende faciliteiten beschikbaar zijn:

14.3



Apache webserver met PHP 5 interpreter



Webserver mail functionaliteit

Entiteiten Dit hoofdstuk huisvest de entiteiten zoals deze voor de applicatie gewenst zijn. Een entiteit is een object-georiënteerd begrip voor een tabel. Voor het bouwen van een applicatie, en dus een database, is het nodig dat de te gebruiken entiteittypen gespecificeerd worden. Een entiteit bestaat uit attributen (eigenschappen), in onderstaande hoofdstukken hebben we het dan over de geregistreerde gegevens. Dus de eigenschappen die in de database worden opgeslagen. Er wordt voor de entiteiten en geregistreerde gegevens gebruik gemaakt van engelse termen omdat dit in voorbereiding is op de technische implementatie.

14.3.1

Entiteiten Relatie Diagram (ERD) In dit hoofdstuk staat een overzicht van de entiteiten, waarbij is aangegeven wat de relaties tussen de entiteiten is.


pag 34 van 46


14.3.2

Persons Persons zijn de hulpverleners die hun mobiele telefoon en nummer willen registreren in het systeem, het moet mogelijk zijn om na het registreren nog het email-adres, mobiele nummer en de namen te wijzigen of om nog een mobiel nummer toe te voegen.

14.3.2.1 Geregistreerde gegevens Dit hoofdstuk bevat een overzicht met korte uitleg van de gegevens welke geregistreerd worden voor elke 'Person'. ID: uniek ID van elk persoon


pag 35 van 46


email: Huidig Email-adres van de persoon firstname: Voornaam preposition: Tussenvoegsel lastname: Achternaam function: Functie als hulpverlener unit: Eenheid waartoe de hulpverlener behoort

14.3.2.2 Functies Hier wordt beschreven welke acties erop de 'Persons' kunnen worden uitgevoerd. Deze acties moeten zowel uitgevoerd kunnen worden via de mail door de hulpverleners zelf of door een beheerder via de beheerders-pagina, tenzij anders vermeld. Toevoegen: Een nieuwe hulpverlener toevoegen Wijzigen: Het wijzigen van de gegevens van een hulpverlener Verwijderen: Het verwijderen van een hulpverlener Zoeken: Doorzoeken van de hulpverleners (enkel voor beheer)

14.3.3

Phones De telefoons zijn losgekoppeld van personen om er voor te zorgen dat een persoon 1 of meerdere telefoons kan registreren, dit wil dus zeggen dat de relatie persoon - telefoon een 1 op meer relatie is. Het moet mogelijk zijn telefoons en de bijbehorende gegevens te registreren, wijzigen en verwijderen.

14.3.3.1 Geregistreerde gegevens Dit hoofdstuk bevat een overzicht met korte uitleg van de gegevens welke geregistreerd worden voor elke 'Phone'. imei: De term International Mobile Equipment Identity, meestal afgekort tot IMEI staat voor het unieke (meestal 15-cijferige) nummer dat een mobiel telefoon-toestel identificeert. number: Dit is het mobiele nummer van de telefoon die geregistreerd is.


pag 36 van 46


14.3.3.2 Functies Hier wordt beschreven welke acties erop de 'Phones' kunnen worden uitgevoerd. Deze acties moeten zowel uitgevoerd kunnen worden via de email door de hulpverleners zelf of door een beheerder via de beheerders-pagina, tenzij anders vermeld. Toevoegen: Een nieuwe telefoon (imei en nummer) toevoegen Wijzigen: Het wijzigen van de gegevens van een telefoon (andere telefoon (imei) zelfde nummer, ander nummer zelfde telefoon (imei)). Verwijderen: Het verwijderen van een telefoon Zoeken: Doorzoeken van de telefoons (enkel voor beheer)

14.3.4

Persons_Phones Deze entiteit bied de mogelijkheid om de enteiten persons en phones met elkaar te koppelen en extra gegevens over de koppeling bij te houden. Geregistreerde gegevens phones_id: De unieke sleutel van de phones entiteit. persons_id: De unieke sleutel van de persons entiteit. created: Datum / tijd notatie waarop de koppeling is aangemaakt. verified: Datum / tijd notatie waarop de koppeling laatst is geverifieerd door de persoon van wie de koppeling is (telefoon eigenaar).

14.3.4.1 Functies Hier wordt beschreven welke acties erop de 'Persons_Phones' kunnen worden uitgevoerd. Deze acties moeten zowel uitgevoerd kunnen worden via de mail door de hulpverleners zelf of door een beheerder via de beheerders-pagina, tenzij anders vermeld. Toevoegen: Een nieuwe koppeling tussen een persoon en telefoon maken. Wijzigen: Het wijzigen van de gegevens van de koppeling zoals de verificatiedatum. Verwijderen: Het verwijderen van de koppeling tussen een persoon en telefoon.

14.3.5

Companynumbers Companynumbers is de benaming voor de tabel waarin all 088 nummers beschikbaar voor gebruik staan, zowel vrije nummers als nummer in gebruik staan hier in


pag 37 van 46


Geregistreerde gegevens ID: Uniek nummer van de 088-nummer number: Het telefoonnummer zelf

14.3.5.1 Functies Deze functies zijn alleen door de beheerder uit te voeren. Toevoegen: Toevoegen van een 088-nummer Verwijderen: Verwijderen van een 088-nummer mits deze niet gekoppeld is aan IMEI nummer

14.3.6

Phones_companynumbers Deze entiteit bied de mogelijkheid om de enteiten companynumbers en phones met elkaar te koppelen.

14.3.6.1 Geregistreerde gegevens phones_ID: de unieke sleutel van de phones entiteit companynumbers_id: de unieke sleutel van de companynumbers entiteit Functies Deze functies zijn alleen door de beheerder uit te voeren Toevoegen: Het toevoegen van een koppeling tussen phones en companynumbers Verwijderen: Het verwijderen van een koppeling tussen phones en companynumbers

14.3.7

Emails Opslag van alle ontvangen emails van hulpverleners en alle door het systeem verzonden emails.

14.3.7.1 Geregistreerde gegevens ID: Het unieke nummer van een email Type: Is het een verzonden of ontvangen email Date: Datum van de email


pag 38 van 46


Content: Inhoud van de email Persons_Id: Koppeling met de entiteit "Persons" zodat te achterhalen is waar de email naar toe ging of vandaan kwam

14.3.7.2 Functies Zoeken: Het doorzoeken van zowel verzonden als ontvangen emails op persoon.

14.3.8

Users Opslag van alle gebruikers van het systeem (beheerders)

14.3.8.1 Geregistreerde gegevens ID: Het unieke nummer van een emai. Uaccount: Unieke gebruikers account zoals dat voor het Mulan domein binnen het Defensie intranet wordt gehanteerd. Fitrstname: Voornaam Lastname: Achternaam Organizationalunit: Organisatiedeel van de gebruiker zoals deze is aangegeven in de Corporate Directory

14.3.8.2 Functies Toevoegen: Een nieuwe gebruiker toevoegen Wijzigen: Het wijzigen van de gegevens van een gebruiker Verwijderen: Het verwijderen van een gebruiker Zoeken: Doorzoeken van de gebruikers 14.4

Overige functies Onderstaande functies zijn functies welke niet ter herleiden zijn naar een specifieke entiteit of juist over meerdere entiteiten heen liggen. Invoerformulier op internet webapplicatie moet voorzien zijn van Captcha anti-spam en misbruik beveiliging.


pag 39 van 46


14.4.1

XML-bestand genereren Het genereren van een XML bestand welke door een externe partij ingelezen kan worden om de geregistreerde gebruikers in het lokale telefoonnetwerk op locatie te registreren. Hierbij wordt het format waaraan het XML-bestand moet voldoen aangeleverd door de externe partij.

14.4.2

Initiëren verificatie van gegevens Deze functie moet beheerders in staat stellen om een email ter verificatie te sturen naar alle geregistreerde hulpverleners. Deze kunnen vervolgens op een link klikken om hun gegevens te valideren of corrigeren.

14.4.3

Email handler Het systeem moet in staat zijn om emails te verwerken en versturen, hierbij moet gedacht worden aan gestructureerde emails die binnenkomen op een POP3 of IMAP mailbox welke door de applicatie uitgelezen kan worden. Het systeem moet deze emails kunnen verwerken tot relationele data, en op basis van de informatie (zowel door de gebruiker via het internet als door het internet deel van de applicatie ingevoegd) de gegevens kunnen verwerken en op basis van de acties en gevolgen van deze acties feedback terug kunnen mailen naar de gebruiker. Internet deel Het internet deel van de applicatie schrijft de emails weg in een aparte directory op de webserver, een andere separaat script zorgt er voor de deze verstuurd worden. Hierdoor kunnen deze twee functionaliteiten gescheiden worden om bij kwaadaardige aanvallen de schade te beperken. De webapplicatie die het formulier en de validatie daarop verzorgt zal ook een instantie zijn van het te gebruiken framework, dit om de consistentie in de manier van werken te waarborgen. Intranet deel De intranet applicatie krijgt de emails aangeboden op bestandsysteemniveau of in een lokale pop3 mailbox op de webserver. Emails die vanaf het internet naar een interne mailbox verstuurd worden, worden met een regel doorgestuurd vanaf de centrale Exchange mailserver van Defensie naar de lokale webserver waar de applicatie op staat.


pag 40 van 46


De email functionaliteit kan onderverdeeld worden in de volgende sub-functies: Lezen en verwerken email verstuurd vanaf het internet formulier Versturen bevestigings email van registratie via internet formulier, kan ook foutmeldingen of andere meldingen naar de gebruiker bevatten Versturen van verificatie email voor geregistreerde gebruikers Encryptie van emails (versturen / ontvangen) ten behoeve van de veiligheid. Email inhoud encrypten en decrypten volgens de rijndael-256 methode.

14.5

MOSCOW lijst De MoSCoW-methode is een wijze van prioriteiten stellen die populair is bij de Rapid Application Development software ontwikkelmethode. De eisen aan het resultaat van een project worden ermee ingedeeld. Het is een afkorting, waarvan de letters staan voor: Must have this - deze eis moet in het eindresultaat terugkomen; Should have this if at all possible - deze eis is zeer gewenst, maar een vergelijkbare eigenschap is ook goed genoeg; Could have this if it does not affect anything else - deze eis mag alleen aan bod komen als er tijd genoeg is; Would like to have but won't have this time around - deze eis zal nu niet aan bod komen maar kan in de toekomst interessant zijn. De kleine letters 'o' in de afkorting hebben geen betekenis, maar maken de afkorting makkelijker te onthouden. Een project wordt als gefaald gezien wanneer niet alle Must-have eisen in het eindproduct verwerkt zitten, hieronder staat een tabel met functies en indicaties onder welke prioriteit deze vallen.

Functies

Must Should

Persons

X

Toevoegen

X

Wijzigen

X

Verwijderen

Could

Would

X


pag 41 van 46


Zoeken

X

Phones

X

Toevoegen

X

Wijzigen

X

Verwijderen

X

Zoeken

X

Persons_Phones

X

Toevoegen

X

Wijzigen

X

Verwijderen

X

Companynumbers

X

Toevoegen

X

Verwijderen

X

Phones_Companynumbers

X

Toevoegen

X

Verwijderen

X

Emails

X

Toevoegen

X

Verwijderen

X

Zoeken

X

Users

X

Toevoegen

X

Wijzigen

X

Verwijderen

X

Zoeken

X

Overige functies

X

XML-bestand genereren

X

Initiëren verificatie van gegevens

X

Email handler

X

- Lezen en verwerken

X

- Versturen bevestigings email

X

- Versturen van verificatie email

X

- Encryptie van emails

X


pag 42 van 46

Eindrapport pGSM beproeving Definitief

15

Afkortingenlijst

AMR codec

BGAN

BSC

BTS

CFNRC

DHCP

GPRS

HLR

IAX2 trunk

Adaptive Multi-Rate Codec. Dit is een spraakalgoritme dat werkt in variable bit rates tussen 4,75 en 12,2 Kbps. De codec is ontwikkeld voor gebruik met het GSM systeem. Het is een verplichte codec in de moderne 3G netwerken. Broadband Global Area Network. Dit is een satellietnetwerk van Inmarsat dat datasnelheden tot 492 kbit/s kan leveren. BGAN levert zowel spraak- als datadiensten. Base Station Controller. Is een functie binnen een GSM netwerk. De BSC verzorgt de managementtaken die met het radioverkeer te maken hebben. De BSC wijst de radiokanalen toe voor mobiele telefoongesprekken. Tevens is de BSC verantwoordelijk voor de handover, voor zover het een handover betreft tussen twee basisstations. Base Transceiver Station. Is een term die binnen GSM wordt gebruikt om een basisstation mee aan te duiden. Een BTS bestaat uit een radiozend/ontvanger met bijbehorende antenne. De BTS onderhoudt de verbinding met de mobiele stations via radioverbindingen. Iedere BTS verzorgt een beperkt gebied. Dit wordt een cel genoemd. Een BTS staat onder controle van een BSC. Call Forwarding on Mobile Subscriber Not Reachable Een dienst waarbij een inkomend gesprek naar een derde partij wordt doorgezet als de ontvanger niet bereikbaar is. Dynamic Host Configuration Protocol Is een protocol om een IP-adres dynamisch toe te wijzen aan computers binnen een netwerk. General Packet Radio Service. Iseen toevoeging aan de GSM-standaard die efficiënte datacommunicatie mogelijk maakt. Bij GPRS wordt er niet meer een continue verbinding opgebouwd voor de duur van een gesprek, zoals bij een spraakverbinding gebruikelijk is, maar wordt de data verdeeld in pakketjes die ieder afzonderlijk worden verstuurd. Aangezien Internet via dezelfe methode werkt, is deze techniek met name geschikt om toegang te leveren aan Internet of andere op IP gebaseerde netwerken. Home Location Register Is een database in een mobiel netwerk waarin informatie over alle gebruikers wordt bewaard. Het HLR bevat gegevens over de identiteit van de gebruiker, zijn telefoonnummer, de diensten waarop deze geabonneerd is en algemene informatie over waar deze zich bevindt. De exacte locatie wordt bijgehouden in een Visitor Location Register. Inter-Asterix Exchange IAX2 een protocol voor het transport van streaming media over een IP gebaseerd netwerk, inclusief het opzetten,


pag 43 van 46


onderhouden en beëindigen van de sessie. IAX kan worden gebruikt voor alle soorten media maar is met name bedoeld voor het opzetten en onderhouden van een spraakverbinding (VoIP).

IMAP

IMEI

IMSI

IPT

Jitter

Jitter buffer

Ki MCC

MNC

Een methode om de kanalen efficiënter te benutten is kanaalbundeling of trunking. Een aantal frequentiekanalen wordt hierbij gedeeld door verschillende gebruikersgroepen. Een kanaal wordt op verzoek voor de duur van een gesprek toegewezen. Internet Message Access Protocol Is een protocol voor het synchroniseren van e-mail, waarbij er direct op de mailserver wordt gewerkt. International Mobile Equipment Identity Bij GSM zijn de identiteit van het toestel en van de abonnee van elkaar gescheiden door gebruik te maken van een uit het toestel uitneembare SIM. Met het IMEI nummer wordt de identiteit van het toestel vastgelegd. Deze identiteit kan worden gebruikt om het voor bijvoorbeeld gestolen of niet goed functionerende toestellen onmogelijk te maken om daarmee te bellen. International Mobile Subscriber Identity IMSI is een unieke code die wordt gebruikt om GSM-abonnees te identificeren. Deze unieke code is nodig omdat een gebruiker niet via zijn telefoonnummer kan worden geïdentificeerd. De reden hiervoor is dat een abonnee meerdere telefoonnummers (MS-ISDN nummer) kan hebben en omdat een abonnee kan roamen. IP Telefonie Bij IP telefonie wordt gebruik gemaakt van een aparte IPtelefoon, of wordt de bestaande telefoon via een adapter aangesloten op de IP verbinding. Een dergelijke IP verbinding kan door de Internet Service Provider worden geleverd samen met internettoegang of door een onafhankelijke IP telefonie leverancier. Jitter is onregelmatigheid in de tijdbasis van digitaal signaal, of het storende signaal dat hierdoor wordt veroorzaakt. In de geluidstechniek is jitter een oorzaak van kwaliteitsverlies bij opnemen of weergeven van digitaal verwerkt geluid. Is een plek waar spraakpakketjes verzameld worden, opgeslagen en naar de spraakprocessor worden gestuurd in gelijke intervallen. Dit alles gebeurt aan de ontvangende kant. Jitter buffer vertraagt de spraakpakketjes, zodat de ontvanger een goede verbinding ervaart met minimale geluidsverstoringen. Ki zijn sleutels, gebruikt voor authenticatie, waarbij de letter i de eigenaar representeert. Mobile Country Code Dit is een uniek 3-cijferig nummer om een land te identificeren. De MCC wordt binnen de International Mobile Subcriber Identity (IMSI) gebruikt om mobiele gebruikers uniek te kunnen identificeren en binnen de Location Area Identification (LAI) om de locatie van een mobiele gebruiker uniek te kunnen vastleggen. Mobile Network Code


pag 44 van 46


MSC

MSISDN

NCC

OMAPOC

Omni antenne Paneel antenne PMN POP3

PSTN

Dit is een uniek 2-cijferig nummer om een mobiel netwerk te identificeren. De MNC wordt in de International Mobile Subcriber Identity (IMSI) gebruikt om mobiele gebruikers uniek te kunnen identificeren en binnen de Location Area Identification (LAI) om locaties binnen een netwerk uniek te kunnen vastleggen. Mobiele Schakel Centrale/Mobile Switching Centre Is de telefooncentrale van een mobiel telefoonnetwerk, zoals GSM. De MSC verzorgt de verbinding tussen de mobiele abonnee en de beller of gebelde. De schakelcentrales zijn bovendien voorzien van één of meer lokatieregisters. Hierin wordt bijgehouden bij welk basisstation een mobiele abonnee zich bevindt. Ze verzorgen daarnaast de administratieve afhandeling van de communicatie, zoals de kostenregistratie. Mobile Subscriber ISDN nummer Dit is het telefoonnummer van een mobiele abonnee. Een abonnee kan voor verschillende diensten (spraak, fax, data) meerdere MS-ISDN nummers toegewezen krijgen. Network Colour Code Dit is een onderdeel van de Base Station Identity Code (BSIC) die in GSM wordt gebruikt. De NCC wordt gebruikt om het betreffende mobiele netwerk te identificeren. De NCC wordt daarom ook wel PLMN colour code genoemd. De BSIC is van belang om basisstations uniek te kunnen identificeren als deze gebruikmaken van dezelfde frequentie voor hun oproepkanaal. Netwerken binnen een land maken gebruik van verschillende frequenties. Deze netwerken kunnen dus zonder bezwaar dezelfde BSIC (en dezelfde NCC) gebruiken. De NCC is dan ook met name van belang in grensstreken. Open Mobile Alliance Push-to-Talk Over Cellular OMA is een internationaal samenwerkingsverband dat is gericht op mobiele datadiensten. OMA stelt de specifiacties op voor datadiensten zodat deze wereldwijd beschikbaar kunnen komen. De OMAPOC is een standaard van de OMA die Push-to-Talk over mobiele netwerken mogelijk maakt. Een omni antenne is een antenne die in staat is om radiosignalen in alle richtingen te verzenden en te ontvangen. Een paneelantenne is een antenne die radiosignalen in een richting kan verzenden en ontvangen. Private Mobile Network Post Office Protocol Dit is het meest gebruikte protocol voor het ophalen van email van een mailserver. POP3 is de derde versie van dit protocol. Public Switched Telephone Network Dit is het circuit geschakelde openbare telefonie netwerk. Oorspronkelijk was het een volledig analoog netwerk. Tegenwoordig is alleen de lijn van de abonnee naar de telefooncentrale veelal nog analoog en werkt het hele verdere transport van spraak op basis van 64 kbit/s kanalen, ook bekend onder de naam DS0 (Digital Signal 0). Spraak wordt hiervoor gedigitaliseerd met behulp van PCM (Pulse Code


pag 45 van 46


PTT

SIM

SIP

SMSC

VLR

WAN

Modulation). Deze maakt gebruik van een 8 bit codering met een bemonsteringsfrequentie van 8 kHz. Push-to-Talk Dit is een vorm van communicatie waarbij er gebruik wordt gemaakt van een half duplex verbinding. Dat wil zeggen dat je of kan praten (zenden) en/of kan luisteren (ontvangen). Door op een knop te drukken, wordt overgeschakeld van luisteren naar praten. Door de knop weer los te laten, ga je weer terug naar luisteren. Bij PTT is het mogelijk om een groepsgesprek op te zetten. Er kan echter steeds maar één deelnemer tegelijk spreken. Subscriber Identity Module De SIM is een chipkaart waarop de identiteit van de abonnee staat aangegeven, de IMSI, waarbij IMSI staat voor International Mobile Subscriber Identity. Daarnaast is er op de SIM nog ruimte voor bijvoorbeeld een adresboek. Session Initiation Protocol Dit is een protocol voor het initiëren, modificeren en beëindigen van een multimediale sessie in een IP omgeving. Een sessie is hierbij de overdracht van data tussen een aantal participanten, zoals internet telefonie en video telefonie. Short Message Service Centre Ofwel de korte-berichten centrale is een onderdeel binnen een GSM netwerk dat verantwoordelijk is voor het afleveren van korte berichten (SMS). Visitor Location Register Dit is een database in een mobiel netwerk dat hoort bij een Mobiele Schakel Centrale (MSC). De VLR bevat de exacte locatie van de mobiele gebruikers die zich binnen het verzorgingsgebied van de MSC bevinden. Deze informatie is nodig om binnenkomende gesprekken naar het goede basisstation te kunnen leiden. Het database record wordt gewist als de gebruiker zich buiten het verzorgingsgebied beweegt of zijn mobiel uitzet. Wide Area Network Dit is een telecommunicatienetwerk dat een geografisch groot gebied bestrijkt. Een WAN kan een openbaar netwerk zijn of een privaat netwerk, maar een WAN maakt over het algmeen gebruik van openbare netwerkelementen, bijvoorbeeld van huurlijnen.


pag 46 van 46

Eindrapport. pgsm beproeving OOV. Versie 1.0. Datum 2 december 2010

Recommend Documents