Det ble koplet opp et testoppsett for å prøvd ut kommunikasjon over flere GSM-kanaler i praksis. Da det ble støtt på en del praktiske problemer i forbindelse med testoppsettet er det valgt å beskrive dette nokså inngående her.
Testoppsettet består av to enheter, hver bestående av en datamaskin
med tilhørende kommunikasjonsutstyr. Den ene enheten var fast plassert
i telesentralen på NTNU Gløshaugen og utgjorde den faste delen av
testoppsettet. Den andre var mobil, og ble prøvd i ulike
situasjoner. I begge datamaskinene var det innstallert spesielle
seriekort for å få et utvidet antall serielle utganger. Til disse var
det på den fast plasserte enheten koplet fire vanlige
telefonmodem. Disse var igjen koplet til hver sin telefonlinje på det
åpne telenettet med hvert sitt telefonnummer. Den faste enheten var
også knyttet til det åpne TCP/IP Internettet ved hjelp av et
nettverkskort. Til seriellutgangene på den mobile enheten var det
tilknyttet fire mobiltelefoner med innebygget grensesnitt for
datakommunikasjon over GSM. Oppsettet er skissert i Figur
![[*]](cross_ref_motif.gif)
.
Det ble i starten gjort forsøk med kun en node og oppkobling mot oppringttjenere hos henholsvis NTNU og Telenor Nextel. Det var imidlertid ikke mulig å få dette til å fungere, da ingen av oppringttjenerne som ble forsøkt støttet multilink-PPP protokollen.
Når kommunikasjonen skjedde ble modemene på den faste enheten oppringt
av mobiltelefonene. Det blir da for hver enkelt oppringing etablert en
kanal som følger følgende vei: Først som radiosamband til nærmeste
basestasjon (BSS). Deretter til den tilhørende svitsj, MSC og videre
til NetComs tjenestegrensesnitt for datatjenester for eksterne nett,
IWF (Interworking Function). Forbindelsen går videre over det åpne
telefonnettet (PSTN) til NTNUs telefonsentral og deretter til modemet
som ble ringt opp. Denne kommunikasjonsveien er skissert i Figur
. Denne kommunikasjonsveien var transparent
for oss.
For å muliggjøre datakommunikasjon over GSM kreves det at telefonabonnementet er aktivert for datakommunikasjon. Hvis dette ikke er gjort vil MSC nekte å overføre datasamband til IWF, og datakommunikasjon kan ikke skje. I testoppsettet ble det benyttet fire testabonnement som ble gitt av NetCom GSM. Ett av abonnementene var ikke korrekt aktivert for datakommunikasjon, og måtte resettes før datakommunikasjon fungerte.
Det ble benyttet vanlige PC-er med Pentium prosessor. Oppsettet stiller ikke særlige krav til maskinen utover at den har nok minne, disk og prosessorkraft til å drive operativsystemet FreeBSD, som ble benyttet i testoppsettet.
For å muliggjøre kommunikasjon over fire kanaler var det nødvendig å innstallere ekstra serieporter i begge datamaskinene. Vanlige PC-er har en eller to serieporter innebygget. Begge maskinene som ble brukt hadde to serieporter innebygget. Det ble i begge maskinene innstallert spesielle konfigurerbare seriekort med to ekstra serieporter, som kan konfigureres til spesielle innstillinger, med hensyn til IRQ-nummer og interne kommunikasjonsadresser. Konfigurasjonen av disse skapte ekstra hodebry fordi seriedriveren i FreeBSD ikke støtter deling av IRQ-linjer. Det var derfor nødvendig å få tak i seriekort som støttet andre IRQ enn 3 og 4 som er det vanlige for seriekommunikasjon og konfigurer disse så de ikke kom i konflikt med annet utstyr som var i maskinene. Et ekstra problem var at seriekortene har en 9-pins RS-232 port og en 25-pins RS-232 port. Da kablene til mobiltelefonene var 9-pins var det nødvendig med overganger til disse.
De fleste operativsystemer (inkludert Windows og Windows NT) støtter Multilink PPP for ISDN-kommunikasjon.
Valget av operativsystemet FreeBSD [2] ble gjort fordi det var ønskelig med et operativsystem som kjører på PC-plattformen, samtidig det måtte være støtte for Multilink PPP over modem. FreeBSD er et gratis operativsystem som bygger på UNIX-varianten BSD 4.2. FreeBSD kjører på 80x86 plattformen og kan innstalleres fra medium som finnes i salg eller hentes ned fra Internett. Når det gjelder andre operativsystem som støtter Multilink PPP for modem/mobiltelefoner, så finnes det en testdriver for dette for operativsystemet Linux. Denne ble ikke prøvd. Cisco IOS [1] støtter også Multilink PPP for modem, så det burde være en konfigurasjonssak å sette opp oppringttjenere til å kunne motta flerkanals kommunikasjon over mobiltelefoner. Det ble ikke funnet støtte for mulitlink PP for modem i flere operativsystemer.
For å gjennomføre datakommunikasjon over GSM er det nødvendig med et spesielt datakommunikasjonsgrensesnitt i telefonen. Noen GSM-telefoner har mulighet for å innstallere et slikt ved hjelp av et PCMCIA-kort i telefonen. Andre telefoner krever en ekstern tilkoblingsboks. I det siste har det kommet noen modeller som har datakommunikasjonsgrensesnittet innebygget i telefonen. En slik modell ble benyttet i testoppsettet. Telefonene var utlånt av Ericsson, og var av typen Ericsson GS18 [11]. Disse telefonene kommer med en ledning som man kan kople direkte til en 9-pins serieport og dermed sette i gang med datakommunikasjon (i teorien). Telefonene hadde en 2W sender og innebygget uttrekkbar antenne.
I denne sammenhengen er det av størst interesse hvordan grensesnittet mellom telefonen og datamaskinen fungerte. Telefonen kommuniserer serielt med datamaskinen i henhold til RS-232 standarden ved hastigheter opp til 19200 bps. For å styre kommunikasjonen implementerer telefonen et standard Hayes-AT kommandosett, tilsvarende det som finnes på vanlige modem. I tillegg er det implementert en del ekstra kommandoer for å styre de funksjonene som er spesielle for mobiltelefoner. Disse er dokumentert i [12], som fulgte med telefonene. De aktuelle spesielle kommandoene er for eksempel for å skifte mellom transparant og ikke-transparant kommunikasjon og forskjellige hastigheter.
GSM-standarden spesifiserer en standard for kommunikasjon i 12 kbps. Denne er foreløpig ikke implementert i GSM-nettet, og var heller ikke implementert i telefonene. Derfor ble det brukt 9.6 kbps som hastighet ved alle forsøkene. Denne hastigheten ble brukt både mellom datamaskinen og telefonene og i GSM-nettet. GSM-telefonene støttet ikke datakomprimeringsprotokoller som v42bis. Det var derfor ikke nødvendig å benytte høyere hastighet mellom datamaskinen og telefonen enn i GSM-nettet.
Det ble benyttet Multitech ZDX modem på den faste enheten. Modemet hadde en maksimal hastighet på 28.8 kbps, og støttet ulike komprimeringsprotokoller. Hastigheten mellom datamaskinen og modemene ble satt til 115.2 kbps. Dette ble gjort for å gjøre det mulig å utnytte effekten av modemets komprimeringsprotokoller når sammenlignende prøver med kommunikasjon over vanlig modem ble gjort.
Multilink PPP daemon [9] for FreeBSD (heretter kalt mpd) er
skrevet av Archie L. Cobbs og bygger på den opprinnelige PPP daemonen
for FreeBSD av Toshiharu Ohno [19]. I dette oppsettet ble det
benyttet versjon 1.0b4 av mpd. Det opprinnelige programmet ppp av Ohno
er en brukermodus ppp-daemon som ved oppstart konfigurerer et modem,
ringer opp en oppringttjener og starter opp PPP protokollen (se
) over modemforbindelsen. Cobbs har reimplementert programmet
til også å støtte Multilink PPP (se ). Fordi programmet er
ment til å være et brukermodusprogram, er det dårlig støtte for
typiske serverfunksjoner. Imidlertid er PPP en symmetrisk protokoll (
se ) som opererer mellom to likeverdige parter. Det er derfor
mulig å bruke mpd i begge ender, ved å konfigurere disse riktig.
I den mobile enden startes og stoppes mpd manuelt av brukeren når
kommunikasjonen skal starte og stoppe. Dette er imidlertid ikke
praktisk på serversiden. Da mpd er ment som et brukerprogram og ikke
har noen serverfunksjon, var det nødvendig å lage et shellprogram som
starter mpd, og restarter den når det er nødvendig. Shellscriptet
fungerer ved å starte mpd i bakgrunnsmodus, og deretter vente til en
kommunikasjon er over. Dette detekteres ved å lese loggfilen til mpd
og se når det ikke lenger er noen aktive kanaler. Når dette detekteres
drepes daemonen, og en ny startes opp. Shellscriptet er gjengitt i
vedlegg .
Mpd er meget konfigurerbart. Konfigurasjonsfilene ligger i /usr/local/etc/mpd . I filen mpd.links konfigureres parametre som er spesielle for hver link, nemlig hvilken kommunikasjonskanal som skal benyttes, hastighetsparametre, initstrenger for modemet, telefonnummer og liknende. I tillegg defineres parametre for båndbredde og forsinkelse for hver kanal. Disse benyttes for å beregne hvordan lasten skal fordeles på de forskjellige linkene. I testoppsette ble båndbredde og forsinkelse satt til å være likt på alle linkene, slik at lasten ble jevnt fordelt over de fire kanalene.
I filen mpd.script defineres script for hvordan modemene skal oppføre seg under oppkobling. I testoppsettet ble det laget to ulike script som ble brukt på henholdsvis den mobile og den faste enheten. Den faste enheten svarer på samtaler og den mobile enheten ringer opp samtaler.
Hovedkonfigurasjonen av mpd ligger i filen mpd.conf . Her defineres en del globale parametre for mpd, og viktigst: det lages en bundle - en bunt - som er en samling av et antall av linkene som ble definert i mpd.links. Denne bunten er den samlede kommunikasjonskanalen som kommunikasjonen foregår over. I tillegg blir det i denne filen definert en del parametre for hver link, blant annet parametre for autentisering av forbindelsen. I testoppsettet ble all autentisering slått av.
Konfigurasjonsfilene mpd.links, mpd.script og mpd.conf for henholdsvis
den mobile enheten og den faste enheten er gjengitt i vedlegg
.
Da kommunikasjonen over fire kanaler endelig var kommet i gang, var det ønskelig å utføre en del målig for å prøve ytelsen til kommunikasjonen. Verktøyet ttcp ble benyttet for å måle ytelsen ved overføring av store datamengder over tcp. Verktøyet ping ble benyttet for å måle forsinkelsen over forbindelsen. Det ble også utført en ytelsesmåling ved test av WWW-respons. Dette ble gjort ved å ta tiden på nedhenting av forskjellige web-sider.
Ttcp [5] er et verktøy som tar tiden på en overføring av en fil, eller en tilfeldig datamengde over TCP eller UDP mellom to stasjoner i et IP-nett. Ttcp virker ved å koble seg til en bestemt TCP/UDP port og vente når den settes i mottaksmodus, eller koble seg direkte til den andre porten og sende dataene når den settes i sendemodus. Det blir ikke benyttet noen annen protokollinformasjon enn det TCP gir. Ttcp kan benyttes til å sende filer. Dersom dette ikke velges, vil ttcp generere en datamengde som består av tre bytes med nuller, et åtte-bits tall, tre bytes med nuller, tallet inkrementert med 1 og så videre. Ttcp generer altså en datamengde som er lett komprimerbar. På grunn av dette ble det i prøvene forsøkt med både vanlig ttcp test og overføring av en binærfil som ikke er så lett komprimerbar.
Ttcp måler tiden det tar å overføre datamengden, og beregner gjennomsnittlig ytelse ut fra det. Tiden taes fra programmet startes til TCP-forbindelsen er avsluttet, dermed taes tiden for ``3-way handshake'' og avlutning av forbindelsen også med i beregningen. Det er verdt å merke seg at dersom man starter den mottagende ttcp en stund før den sendende ttcp vil tidsmålingen starte når programmet startes, og målingene på den mottagende siden vil følgelig bli helt feil. I prøvene som ble utført her er alle verdier hentet fra den sendende siden.
Ping [3] er et standardverktøy som måler responstiden over et nettverk ved å sende en ICMP Echo request pakke til en stasjon i et IP-nett. Stasjonen skal da sende en ICMP Echo reply pakke i retur. Responstiden måles som den tiden det tar fra den første pakken sendes, til svaret mottas. Det måles altså såkalt Round Trip Time (RTT). ICMP er dokumentert i [22].
For å få en relativt realistisk test av hvordan ytelsen testoppsettet gir, ble det også gjort noen ytelsesmålinger ved praktisk bruk av WWW. Ved bruk av WWW, blir HTTP benyttet over TCP. HTTP er dokumentert i [13]. For å få et relativt realistisk inntrykk av bruken av WWW, ble Netscape - verdens mest brukte nettleser - brukt. Versjonen av Netscape som ble brukt var Netscape 4.04 for X11 under FreeBSD. Netscape har en spesiell egenskap som har betydning for ytelsen. Istedet for å hente inn bilder i dokumentet med flere serielle TCP-forbindelse (HTTP 1.0) eller en lang TCP-forbindelse (HTTP 1.1), starter den flere TCP forbindelser parallellt, for å hente inn flere bilder samtidig med HTTP 1.1. Dette har betydning for resultatene i denne testen.
For å slippe å sette opp ruting over den faste enheten, ble det brukt et triks for å få over HTTP-trafikken. Verktøyet ssh [4] ble benyttet for å tunnellere all TCP trafikk fra en bestemt port (port 8080) på den faste enheten som har DNS-navnet sampras.itea.ntnu.no, over til en bestemt port (8080) til NTNUs WWW-proxy tjener. Proxy-tjeneren (www.ntnu.no) fungerer slik at normale HTTP-forespørsler sendes til TCP-port 8080. Proxyen henter da inn det aktuelle dokumentet og sender svaret tilbake til forespørreren. Proxyer brukes til mellomlagring av dokumenter og er et eget fagfelt som ikke omhandles videre her. Ved hjelp av ssh-tunnellen ble nå alle forespørsler til maskinen sampras.itea.ntnu.no på port 8080 videresendt til www.ntnu.no og besvart der. Det var derfor mulig å sette opp Netscape på den mobile enheten til å bruke port 8080 på den faste enheten som proxy-tjener. Det kan invendes mot denne løsningen at den er tung, men med lokalnett og såpass rask maskinvare som ble brukt er det uansett telefonforbindelsen som er det tregeste leddet: Målingene er derfor realistiske likevel.
