Konstruktion av SMS-Gateway för effektökande SMS-tjänster

(1)

Avdelningen för datavetenskap vid Institutionen för Matematik och Informatik

EXAMENSARBETE 2003:D01

Lolita Falk

Konstruktion av SMS-Gateway för

effektökande SMS-tjänster

(2)

Högskolan Trollhättan ⋅ Uddevalla

Institutionen för Informatik och Matematik

Uppsats för filosofie kandidat i Datavetenskap

Konstruktion av SMS-Gateway för effektökande SMS-tjänster

Lolita Falk

Examinator:

Stefan Mankefors Institutionen för Matematik och Informatik Handledare:

Mats Lejon Institutionen för Matematik och Informatik

Trollhättan, 2003

2003:D01

(3)

Construction of SMS Gateway for More Efficient SMS Services

Lolita Falk

Summary

This study researches the construction and functions of a SMS gateway and describes the techniques behind SMS. By using a GSM modem and software, a SMS gateway has been constructed to enable the sending and reciving of messages between IP-network and the GSM-network. Different SMS services can be inserted into the network by using a SMS gateway, these services will improve network reliability and efficiency.

Publisher: University of Trollhättan ⋅ Uddevalla, Department of Informatics and Mathematics Box 957, S-461 29 Trollhättan, SWEDEN

Phone: + 46 520 47 50 00 Fax: + 46 520 47 50 99 Examiner: Stefan Mankefors

Advisor: Mats Lejon, HTU

Subject: Computer science Language: Swedish

Number: 2003:D01 Date: May 13, 2003

Keywords SMS-Gateway, SMS, GSM-modem, SMSD, SMSC, Mobile- and data communication

(4)

Konstruktion av SMS-Gateway för effektökande SMS-tjänster

Lolita Falk

Sammanfattning

Denna studie, som även beskriver tekniken bakom sms, är en informationsinsamling kring konstruktionen av en sms- gateway och dess funktioner. Med hjälp av ett GSM- modem och en programvara har en sms-gateway konstruerats för att sända och mottaga meddelanden mellan ett IP-nätverk och GSM-nät. Genom att använda en sms-gateway kommer olika sms-tjänster att kunna införas för att förbättra ett nätverks tillförlitlighet och effektivitet.

Utgivare: Högskolan Trollhättan ⋅ Uddevalla, Institutionen för Informatik och Mattematik Box 957, 461 29 Trollhättan

Tel: 0520-47 50 00 Fax: 0520-47 50 99 Examinator: Stefan Mankefors

Handledare: Mats Lejon, HTU

Huvudämne: Datavetenskap Språk: Svenska

Nivå: Fördjupningsnivå 1 Poäng: 10

Rapportnr: 2003:D01 Datum: 2003-05-20

Nyckelord: SMS-Gateway, SMS, GSM-modem, SMSD, SMSC, Mobil- och datakommunikation

(5)

Förord

Detta examensarbete uppkom genom ett förslag från IT-enheten på Högskolan i Trollhättan/Uddevalla för att undersöka möjligheterna med en sms- gateway.

Jag vill tacka Amir Palic som fått vara mitt bollplank via ICQ och Stefan Mankefors för hjälp med rapporten.

Trollhättan 2003-05-20

Lolita Falk

(6)

Innehållsförteckning

SUMMARY ... II

SAMMANFATTNING ...III FÖRORD ... IV FÖRKORTNINGAR ...VII

1 INLEDNING ... 1

1.1 B

AKGRUND

... 1

1.2 P

ROBLEMBESKRIVNING

... 1

1.3 S

YFTE

... 2

1.4 A

VGRÄNSNINGAR

... 2

2 METOD ... 2

3 TEKNISK BAKGRUND TILL SMS... 4

3.1 G

RUNDERNA I

SMS ... 4

3.2 I

NFORMATIONSELEMENT

... 4

3.2.1 Validity-Period ... 5

3.2.2 Service-Centre-Time-Stamp... 5

3.2.3 Protocol-Identifier ... 5

3.2.4 More-Message-to-Send ... 5

3.2.5 Priority... 5

3.2.6 Message-Waiting ... 5

3.2.7 Alert-SC ... 6

3.3 S

TATUS

R

APPORT

... 6

3.4 SMS

OCH E

-

POST

... 6

3.4.1 Grundformat ... 7

3.4.2 Valfria fält... 7

3.4.2.1 Valfritt fält - Subject... 7

3.4.2.2 Valfritt fält - Real Name ... 8

3.4.2.3 Valfri kontrollflagga ... 8

3.4.3 Text sammanlänkning ... 8

3.5 P

ROTOKOLL O

P

ROTOKOLLAGER

... 9

3.5.1 Tjänster tillhandahållna av SM-TL ... 9

3.5.2 Tjänster tillhandahållna av SM-RL ... 10

4 SMS SERVER TOOL ... 12

4.1 F

ILFORMAT

... 12

4.1.1 Text Sm... 12

4.1.2 Binärt Sm ... 13

4.1.3 Mottaget sm ... 14

4.1.4 Statusrapport ... 14

4.2 V

ALIDERING AV SMS

-

FILEN

... 15

(7)

4.3 SMSD

OCH

M

ODEMET

... 15

4.3.1 Putsms... 15

4.3.2 Getsms... 16

4.4 Ö

VRIGA FUNKTIONER

... 16

4.4.1 Status monitor... 16

4.4.2 Statistics... 16

4.4.3 Logfile ... 17

4.4.4 Event handler... 17

4.4.5 Alarm handler ... 17

4.4.6 SQL log ... 17

4.5 K

ONSTRUKTION

... 18

4.6 T

ESTKÖRNING

... 19

4.6.1 Exempel på Konfigurationsfel ... 19

4.6.2 Exempel på Kabel/Modemfel... 19

4.6.3 Exempel på kommandofel av användaren... 20

5 RESULTAT ... 20

6 DISKUSSION ... 23

6.1 S

LUTSATS

... 23

7 REFERENSFÖRTECKNING... 24

APPENDIX A... 1

APPENDIX B ... 7

APPENDIX C... 9

(8)

Förkortningar

DA Destinations Address

GMSC Gateway Mobile service Switching Centre GSM Global System for Mobile Communication HLR Home Location Register

HTU Högskolan Trollhättan/Uddevalla MMS More-Messages-to-Send

MO Mobile Originated

MSC Mobile service Switching Centre

MT Mobile Terminated

MS Mobile Station

MT Mobile Terminated

MySQL Databashantera med öppen källkod.

OA Originating Address

PDU Protocol Data Unit PID Protocol Identifier

PLMN Public Land Mobile Network

RP Relay Layer Protocol

RP-ACK Acknowledgement från RP (kvitto)

SC Service Center

SGSN Serving GPRS Support Node

SIM Subscriber Identity Module

SM Short Message

SM-AL Short Message Application Layer SM-RL Short Message Relay Layer SM-TL Short Message Transport Layer

SME Short Message Entity – Enhet som kan mottaga/sända sm. SME kan vara lokaliserd i ett fast nätverk, MS eller SC.

SMI Short Message Identifier

SMS Short Message Service

(9)

SMSD Short Message Service Daemon

TCAP Transaction Capabilities Application Part TP Transfer Layer Protocol

UDH User Data Header

VLR Visitor Location Register

(10)

1 Inledning

Integreringen av tidigare åtskilda tillämpningar såsom tal-, sms- och datakommun- ikation har medfört att nya tjänster efterfrågas.

I dagens företag och organisationer där effektivitet, tillgänglighet och tillförlitlighet är tre viktiga faktorer, både inom kommunikationen mellan människor och systemets själva funktionalitet, så ställs det stora krav på helheten. Nätverket som har en central och viktig roll och oftast är själva kärnan för att verksamhetens kommunikation ska fungera, ska vara tillgängligt på utsatta tider samt arbeta tillförlitligt under dessa tider.

Med hjälp av GSM-utrustning som GSM- modem och mobiltelefoner, i samarbete med en sms-gateway, kan idag olika mobila datakommunikationstjänster tillhandahållas för att öka effektiviteten, tillgängligheten och tillförlitligheten.

1.1 Bakgrund

Genom att använda sig utav GSM-utrustning i företag och organisationer kommer både nätverkets prestanda och IT-personalens effektivitet att förbättras. I och med att man får larmmeddelanden om kritiska händelser till en mobiltelefon behöver man inte längre sitta vid en bildskärm och övervaka systemet. Detta gör att IT-personal kan arbeta på andra platser och ändå nås av felmeddelanden. Åtgärder kan därmed sättas in fortare än om man upptäckt felen först i en senare kontroll av loggfilerna.

Därför vill även Högskolan i Trollhättan/Uddevalla öka nätverkets tillgänglighet och tillförlitlighet genom effektivare hantering av felmeddelanden. Detta vill man ska ske via ett GSM-system som vidarebefodrar e-postens inkommande larmmeddelanden från systemövervakningen till en mobiltelefon. I dagsläget får man, förutom att se i syslog- filen, vissa kritiska larmmeddelanden från systemet vidaresända till e-posten. Detta medför att nätverket kan bli obrukbart längre tid än nödvändigt, till exempel om administratören för tillfället befinner sig på annan plats och därmed inte kan läsa av e- posten. Det är viktigt att HTU’s nätverk fungerar effektivt och pålitligt då både personal och studenter i största del är beroende av det i sina arbeten.

I planerna ingår även att man ska införa tjänsterna mail till sms och sms till mail för personalen vid HTU. Genom dessa tjänster vill man även effektivisera den övriga e- posthanteringen. Vilka som ska ha tillgång till denna tjänst är dock ännu oklart.

1.2 Problembeskrivning

HTU kommer att behöva en sms-gateway för att kunna nyttja ovanstående tjänster, den behövs för pålitlig leverans mellan IP-nätverket och själva GSM-nätet.

Hur man konstruerar en sms-gateway och vad som behövs för att den ska fungera finns

det bara vaga kunskaper om. Informationsinsamling och att sätta sig in i ämnet är ett

(11)

tidskrävande arbete, som IT-enheten för tillfället inte har tid med då övriga arbets- uppgifter måste komma i första hand.

1.3 Syfte

Syftet med detta arbete är att konstruera en sms-gateway och få den att skicka sms- meddelanden från dator till GSM-enhet, och tvärtom.

Det bör dock nämnas att detta arbete kommer att vara av förundersökande karaktär. Min konstruktion av en sms-gateway är ej menad att tas i bruk efter slutfört examensarbete, utan är snarare en informationsinsamling. Detta görs för att underlätta konstruktionen av en sms-gateway i ett senare skede då sms-tjänsterna ska införas.

1.4 Avgränsningar

Tjänsten larmmeddelanden via sms kommer inte att konfigureras, inte heller sms till mail eller mail till sms då de ännu bara är på planeringstadiet. Min uppgift består endast i att få ett fungerande GSM-system med fokus på sms-gatewayen, vilken ska kunna skicka och ta emot sms.

2 Metod

All informationsinsamling angående sms- gateways samt annan behövlig information i konstruktionen av en sms-gateway, har skett från Internet. Informationen är i största del tagen från programvarutillverkarens sidor samt från specifikationsblad från standard institut. Dessa sätter nationella standarder och normer som bör följas för att befrämja internationellt användande av GSM-enheter.

Det enda kravet HTU hade var att sms-gatewayen skulle arbeta på en Linux-server. IT- enheten hade även två förslag på programvara som de var intresserade av, SMS Link och SMS Server Tool, vilka båda var Linuxkompatibla samt kunde tillhandahålla de önskvärda tjänsterna som senare ska sättas in. Efter en granskning av dessa två programvaror upptäcktes att SMS Link ofta hade webbsidor som inte fungerade och att uppdateringen var från 2001. Då erfoderlig tid saknades för detta examensarbete och tillgänglig informationen var en viktig del i arbetet så valdes SMS Server Tool, denna hade fullt fungerande sidor samt var uppdaterad 2003. SMS Server Tool är en gratis programvara med öppen källkod, vilket gör att man kan anpassa programvaran efter sina egna behov. SMS Server Tool licensieras under General Public Licence. [1]

Det praktiska momentet bestod i att först installera Linuxdistributionen Red Hat 9,0.

Därefter laddades programvaran SMS Server Tool samt OSSP mm Shared Memory

Library ner för installation och konfiguration (Appendix A). Den sistnämnda är ett

bibliotek som behövs för statistikföring tillsammans med SMS Server Tool. GSM-

modemet som HTU tillhandahöll för själva konstruktionen av sms-gatewayen var en

(12)

Nokia 6210 mobiltelefon som kopplades till ttyS0 porten på datorn, (ttyS0 är Linux

beteckning på den första seriella porten) till detta användes en Nokia DLR-3P

datakommunikationskabel. SIM-kortet som tillhandahåller abonnemangsspecifik infor-

mation till mobiltelefonen [2] och som behövdes för att kunna använda telefonen var ett

privat SIM-kort. Anledningen till detta val var att inget annat kort fanns att tillgå på

grund av att de var utlånade till andra examensarbeten. Därefter gjordes testkörningar

och ändringar för att få sms-gatewayen att skicka och ta emot sms. I efterföljande

kapitel kommer det att ges en omfattande teknisk bakgrundsbeskrivning till sms så

förklaring av begreppet sms utelämnas här.

(13)

3 Teknisk bakgrund till SMS

Ett vanligt fel är att kalla meddelanden som man skickar för SMS, SMS står för short message service och är själva tjänsten för att kunna skicka korta meddelanden, så kallade sm (short message). Därför kommer jag hädanefter att använda SMS då jag menar själva tjänsten, och sm då jag menar meddelandet.

3.1 Grunderna i SMS

Point-to-Point short message service (SMS), gör att man kan sända sm på max 160 tecken mellan GSM-enheter, detta möjliggörs genom ett service-center (SMSC) som är en central punkt där sm lagras och sänds vidare. Således behöver ett GSM Public Land Mobile Network (PLMN) för att stödja transporten av sm mellan SMSC och en mobil station (MS). [3]

SM Point-to-Point Service omfattar två grundläggande tjänster, mobile originated (MO) och mobile terminated (MT). Mobile originated är sm som skickas från en MS via SMSC och sen vidare till en mottagare. Mobile terminated är möjligheten för MS att ta emot sm från SMSC. Båda ska även tillhandahålla information om meddelandet, antingen genom en leverans-rapport eller en misslyckanderapport. Aktiva MS och SMSC’s ska alltid kunna ta emot ett sm, oberoende om det pågår ett samtal eller någon annan kommunikation. Av den anledningen ska alltid en rapport returneras till SMSC om att meddelandet är mottaget av MS, även om ett meddelande misslyckas så ska SMSC informeras om detta. Samma sak gäller tvärtom. Notera dock att transport eller mottagande av ett sm som sammanfaller med en ändring av tillståndet på MS, till exempel från upptagen till overksam kan avbryta överföringen.[3]

3.2 Informationselement

SMS omfattar sju grundelement, speciellt i presentation och mottagande av sm. [3]

− Validity-Period

− Service-Centre-Time-Stamp

− Protocol-Identifier

− More-Message-to-Send

− Priority

− Message-Waiting

− Alert-SC

(14)

3.2.1 Validity-Period

Detta informationelements parameter indikerar på tidsperioden som meddelandet är giltigt, vilket betyder hur länge SMSC kan garantera meddelandets existens i minnet innan leverans till MS förfaller. [3]

3.2.2 Service-Centre -Time -Stamp

SMSC informerar mottagande MS om ankomsttiden då meddelandet kom till Short Message Transport Layer (SM-TL) enheten hos SMSC. Tiden omfattar år, månad, dag, timme, minut och sekund. [3]

3.2.3 Protocol-Identifier

Detta element används av SM-TL, endera för att hänvisa till högre lagers protokoll som används eller indikera på ett samarbete med en särskild typ av enhet. Elementet använder sig av ett särskilt fält hos meddelandetyperna SMS-SUBMIT, SMS-SUBMIT- REPORT för RP-ACK, SMS-DELIVER, SMS-DELIVER-REPORT för RP-ACK SMS_STATUS_REPORT och SMS-COMMAND TP-Protocol- Identifier (TP-PID). [3]

3.2.4 More -Message -to-Send

Informationsfält där SMSC informerar MS om att det är en eller flera sm som väntar i SMSC på att levereras. Den använder en boolsk parameter i meddelandet SMS- DELIVER, TP- more- message-to-send (TP-MMS). [3]

3.2.5 Priority

Priority är informations elementet utsatt av SMSC eller Short Message Entity (SME) för att indikera åt PLMN om ett sm har prioritet eller inte. Leverans av icke prioterade sm kommer inte att misslyckas om MS har identifierats som tillfälligt frånvarande. Däremot misslyckas det om den inte identifierats som tillfälligt nere, oavsett om MS blivit upptäckt att inte ha någon ledig minneskapacitet kvar. [3]

Leverans av prioriterade sm kommer att misslyckas oavsett om MS har identifierats som tillfäligt nere eller inte har någon minneskapacitet kvar. [3]

3.2.6 Message -Waiting

Detta är ett tjänste element som möjliggör för PLMN att tillhandahålla Home Location

Register (HLR), Serving GPRS Support Node (SGSN) och Visitor Location Register

(VLR), med vilket mottagarens MS är associerad med och informera om att det finns ett

sm i SMSC som väntas på att levereras. Detta element används bara i händelse av

tidigare misslyckat leveransförsök, beroende på tillfälligt frånvarande MS eller

överskriden minneskapacitet. [3]

(15)

3.2.7 Alert-SC

Alert-SC är ett tjänsteelement som tillhandahålls av en del GSM PLMN’s för att informera SMSC att en MS:

− till vilken man försökt leverera ett sm har misslyckats på grund av att den var onåbar eller minneskapaciteten var slut.

− som nu är igenkänd av PLMN:

a) har återupptagit verkan.

b) nu har tillgängligt med minne och är redo att ta emot sm. [3]

3.3 Status Rapport

SMS erbjuder SMSC möjligheten att informera MS statusen på nyligen sänt sm.

Statusen kan vara:

− Framgångsrik leverering av sm till SME

− SMSC kunde inte sända till SME

Statusrapporten initieras genom en status report begäran i mobilenheten och denna rapport kan då även mottagas av sms- gatewayen. [3]

3.4 SMS och e -post

Det går även att skicka meddelanden mellan Internet e-post och SMS, detta är något som erbjuds i båda riktningarna vilket gör det möjligt att sända och mottaga e-post via sm. [3]

Detta är möjligt genom följande procedur:

− Ett SMS meddelande som ska samarbeta med e-posten bör ha sitt Protocol Identifier (TP-PID) värde satt för Internet electronic mail.

− Endera ett ensamt eller sammanlänkande sm kan användas för att transportera e- posten.

− Sammanlänkning kan åstadkommas genom TPUDH mekanismen eller genom en textbaserad metod, som beskrivs längre ner i dokumentet.

− E-postens cc fält stöds inte.

− När flera fält är representerade bör ytterligare mellanrum infogas av användaren för att förbättra presentationen av meddelandet.

− Ett speciellt grundformat, som beskrivs här nedan.

(16)

3.4.1 Grundformat

Grundformatet för att transportera e-post i båda riktningarna består av följande.

MT SM:

[<from-address><space>]<message>

MO SM:

[<to-address><space>]<message>

[ ] betäcknar valfritt fält.

Adressformatet måste vara i formen

user@domain1.domain2

eller

Username <user@domain1.domain2>

I det senare fallet kommer symbolerna < och >, som är en del i adressen att skickas med. [3]

Beroende på gatewayens natur är destination/avsändar adressen antingen erhållen från innehållet i SMS TP-OA eller TP-DA fält, eller så innehåller TP-OA/TP-DA fältet en generisk gatewayadress och to/from adressen tillsätts då i början. [3]

Flera adresser kan användas genom seperation med kommatecken.

adress1,adress2,adress3

Det är valfritt för mottagande gateway att stödja detta, om den inte gör det ska den avfärda meddelandet genom att returnera ett meddelande med lämplig felbeskrivning.

[3]

3.4.2 Valfria fält

En E-post<->SMS Gateway kan infoga ytterligare mellanrum i MT-meddelandet för presentation till användaren, den måste även acceptera infogade mellanrum i MO- meddelandet från avsändaren. [3]

Följande valfria fält stöds.

3.4.2.1 Valfritt fält - Subject

Subject placeras mellan adressen och meddelandet och avgränsas med parenteser eller föregås av ## samt ett # efter.

[<to-address>](<subject>)<message>

eller

[<to-address>]##<subject>#<message>

(17)

MO och MT kan ha endera formatet och en utvecklare måste försäkra att båda formerna stöds för full kompatibelhet. [3]

3.4.2.2 Valfritt fält - Real Name

Detta fält innehåller det riktiga namnet på avsändaren och används bara i MO- meddelanden. En SMSC eller en gateway skapar ett e-post meddelande enligt e-postens standardprocedur, innehållande: [3]

Real Name <user@domän1.domän2>

Om ett subject ska inkludera Real Name så används bara prefixet ##.

[<to-address>]#<real-name>[##<subject>]#<message>

3.4.2.3 Valfri kontrollflagga

En valfri kontrollflagga kan sättas i början av meddelandet, men bara i MO. Denna består av ett endaste tecken <CF> följt av #-symboler.

[#<CF>#][<to-address>]<space><message>

Denna kan även användas i kombination med fälten ovan. Den är avsedd att användas då en specifik funktion ska väckas upp hos en SMSC eller gateway. Det kan till exempel vara kontrollflaggan #A# som kan tillsätta en förlagrad signatur i slutet, eller

#R# som kan ändra från-adressen till ett förla grat värde, eller #5# som kan addera text, exempelvis ”Allvarligt fel har uppstått”. Alla dessa funktioner är öppna för definition av SMSC eller gatewayens operatörer. [3]

3.4.3 Textsammanlänkning

Om GSM’s binära sammanlänknings-protokoll inte stöds av sändnings- eller mottag- ningsenheten kan textbaserad mekanism användas.

Det första meddelandet slutar med ett + tecken och varje påföljande meddelande börjar och slutar med ett + tecken, den sista börjar bara med ett + tecken. [3]

<message1>+

+<message2>+

+<message3>+

+<message4>

Några headerfält (se kap. 4.1) placerade framtill på ett MO eller MT meddelande adderas inte till andra eller påföljande meddelanden. Detta sörjer för en enkel mekanism som är fullständigt bakåtkompatibel.

Det finns ingen indikation på antalet meddelanden, men skulle ett meddelande förloras av systemet eller anlända i fel ordning kan inte orginalmeddelandet rekonstrueras.

Därför bör GSM’s binära sammanlänkningsmekanism användas. [3]

(18)

3.5 Protokoll o Protokollager

Här följer en beskrivning av protokoll som används, samt lagren och tjänsterna som de tillhandahåller. Protokollagren hos SMS är strukturerade enligt figur 3.1. [3]

SM-AL Applikationslagret används av SIM-applikationer. [2]

SM-TL Transportlagret fungerar som en tjänst åt applikationslagret och möjliggör sändning och mottagning av meddelanden mellan sin motsvarande mottagare.

[2]

SM-RL Relaylagret är en relätjänst åt transportlagret som använder det till att skicka dataenheter, TPDU’s (transfer protocol data unit’s) till mottagande mot- svarighet. [2]

SM-LL Enligt GSM finns inga obligatoriska protokoll specifiserade mellan SC och MSC. Detta är en överenskommelse mellan SMSC och PLMN operatörerna.

[2]

Figur 3.1: Protokollagren hos SMS (Källa:http://amber.feld .cvut.cz/user/Pokorny/bpdp/GSM_0340.PDF)

3.5.1 Tjänster tillhandahållna av SM-TL

SM-TL tillhandahåller tjänster åt SM-AL, dessa tjänster gör det möjligt för SM-AL att sända/mottaga meddelanden till och från motsvarande lager hos kommunicerande part.

För att kunna hålla reda på meddelanden, och rapporter vilka också är meddelanden, måste meddelandet mellan SM-AL och SM-TL innehålla en short message identifier (SMI). Denna SMI är ett referensnummer till ursprungsmeddelandet, och mappas till och från den SMI som används mellan TL-RL. SMI överförs inte mellan enheter och därför kan meddelanden ha olika SMI hos MS och SMSC. SM-TL kommunicerar med motsvarande enhets lager genom protokollet protocol data unit (PDU). [3]

SM-TL omfattar sex PDU’er, enligt tabell 3.1. [3]

MS

SM-AL

SME SC

SMS-GMSC/

SMS-IWMSC MSC/SGSN

SM-TL SM-RL SM-LL

(19)

Tabell 3.1: PDU:er hos transportlagret

PDU Funktion

SMS-DELIVER Meddelanden från SMSC till MS

SMS-DELIVER-REPORT Innehållande:

a) en felorsak

b) information som en del i en positiv eller negativ acknowledgment till en SMS-DELIVER eller SMS-STATUS-REPORT

SMS-SUBMIT Meddelande från MS till SMSC

SMS-SUBMIT-REPORT Innehållande:

a) en felorsak

b) information som en del i en positiv eller negativ acknowledgment till en SMS-SUBMIT eller SMS-COMMAND

SMS-STATUS-REPORT Statusrapport från SMSC till MS

SMS-COMMAND Kommando från MS till SMSC

3.5.2 Tjänster tillhandahållna av SM-RL

SM-RL tillhandahåller tjänster åt SM-TL, dessa tjänster gör det möjligt för SM-TL att sända/mottaga TPDU’s till och från motsvarande lager hos kommunicerande part.

För att kunna hålla reda på TPDU’s, och rapporter om dessa TPDU’s måste även detta meddelandet mellan SM- TL och SM-RL innehålla en SMI. Denna SMI är ett referens- nummer till TPDU’n för ursprungsmeddelandet. SMI överförs inte via SM-RL protokoll, den använder istället relaylagertjänster vid överföring mellan SMSC och Gateway Mobile service Switching Centre (GMSC). Parametern överförs inte heller av MAP men mappas till och från TCAP Dialogue Identifier hos GMSC och den besökta MSC’n. [3]

SM-RL kommunicerar med motsvarande enhets lager genom protokollen som följer nedan. Olika protokoll krävs mellan olika par av SM-RL enheter, här framställs bara en översikt av de olika informationselementen som måste medföras mellan dessa. Notera dock att teckensystem hos protokoll, inte hos element, kan variera mellan olika GSM- specifikationer. [3]

SM-RL omfattar följande sex protokollelement enligt tabell 3.2. [3]

(20)

Tabell 3.2: Relaylagrets protokollelement

Protokollelement Funktion

RP-MO-DATA Överföring av en TPDU från MS till SMSC

RP-MT-DATA Överföring av en TPDU från SMSC till MS

RP-ACK För acknowledging RP-MO-DATA, RP-MT-DATA

eller en RP-SM-MEMORY-AVAILABLE

RP-ERROR För att informera om ett misslyckat RP-MO-DATA eller RP-MT-DATA överföringsförsök.

RP-ALERT-SC För att uppmärksamma SMSC att MS har åter- upptagit verkan

RP-SM-MEMORY- AVAILABLE

För att rapportera åt nätverket att MS nu har minne tillgängligt (information sänt från MS till HLR).

Mycket mer information finns att tillgå om protokoll och protokollagren och här har

endast de grundläggande aspekterna tagits upp. Detta har gjorts för att få en teknisk

bakgrund till sms och dess tjänster innan programvaran SMS Server Tool, som ska

användas i själva konstruktionen, kommer att beskrivas. För mer information om

protokoll och dess tjänster se ETSI-specifikationen [3].

(21)

4 SMS Server Tool

SMS Server Tool, programvaran som valdes på grund av sin lättillgänglighet, är ett paket med små program som används då man vill kunna sända och mottaga korta meddelanden, så kallade sm. Genom att använda ett enkelt filbaserat interface och en eller flera GSM- modem kan man konstruera en sms- gateway som kan köras både under Unix och Windows operativsystem. [4] Här kommer bara Unix delen att tas upp då det är under en Linux server som SMS Server Tool installerades.

Huvudprogrammet i SMS Server Tool heter SMSD och det är det som gör det möjligt att sända och mottaga sm, samt validera sms- filerna. SMSD’n erbjuder även fler funktioner, till exempel, tillståndskontroll, statistik, loggning, händelsehantering, alarmhantering och SQL- loggning. [4]

4.1 Filformat

Filformatet är enkelt och liknar i stort sett e-postens filformat. Här måste man speci- ficera mottagare samt andra inställningar [4], denna del kallas headern och är termen som kommer att användas i fortsättningen. Beskrivning av formatet hos de olika sm- typerna finns under rubrikerna text sm, binärt sm, mottaget sm samt statusrapport nedan.

För att sända ett sm måste en sms-fil skapas, denna fil används för att tala om nummret till destanitionen och innehållet i meddelandet för SMSD. Efter att man skapat sms-filen måste man flytta filen till outgoing queue, vilket är en folder i filsystemet. Sms- filen kan även skapas direkt i foldern, men detta rekommenderas inte om man inte kan försäkra sig om att filskapningen är snabb nog. SMSD kontrollerar nämligen om filstorleken ändras, om ingen ändring sker inom 1 sekund, så antar SMSD att filen är klar för sändning. För att underlätta det hela kan man skapa en folder för sms- filerna, och när de är färdiga för sändning så flyttar man dom till outgoing queue. Vilken tillåter flera sm till SMSD utan att man behöver vänta tills de är levererade. [4]

4.1.1 Text Sm

En sms-fil är en textfil som innehåller meddelandet och headern, alla sm som man vill sända måste man lagra i filer och flytta till outgoing folder. Filnamnet måste vara unikt och man skapar namnet genom att använda kommandot

^mktemp

. [4]

De olika fälten i sms- filens header är from, to, provider och flash, där endast to är obligatoriskt. (Figur 4.1)

From, används bara av loggfilen. I fältet to skriver man mottagarnummer i

internationellt format utan tecknet + framför. I Provider fältet specifierar man namnet på

destinationens operatör. SMSD’n använder denna parameter för att avgöra till vilken kö

meddelandet ska och för valideringen. Flash har värdena ”yes” eller ”no”. Sätter man

värdet till yes så kommer meddelandet att sändas som flash eller klass 0, vilket betyder

(22)

att meddelandet inte kommer att lagras i SIM-kortet hos mottagaren utan visas på displayen direkt. [4]

Headern avslutas med en tom rad och därefter följer meddelandet. Man kan även tillsätta egna fält i headern om man behöver det, SMSD’n ignorerar dessa om de är okända för den. Detta förenklar konversationen mellan e-post och sms. [4]

Alla rader måste avslutas med

^\n

.

From:

To:

Provider:

Flash:

Här kommer texten!!!

Figur 4.1: Header för textmeddelande

4.1.2 Binärt Sm

Om ett sm har binärt innehåll kommer det att sändas som 8-bitars teckenkod med en UDH flagga, binära sm innebär bland annat operatörlogos och ringtoner. Den binära datan börjar direkt efter den tomma raden och slutar i filslutet. Finns det ingen header så börjar datan i den första byten av filen. [4]

Fälten som ingår här är from, to, provider, binary och UDH, men det är bara de två sista som är nya. (Figur 4.2)

Fältet binary används av SMSD’n, den behöver veta om man använder text eller binärt sm. Här sätter man värdet ”true” om det är binärt, man kan även använda ”1” eller

”yes”. Om den binära datan innehåller en UDH talar man om det för SMSD ge nom värdet ”true” i UDH- fältet, true är standardvärdet då de flesta sm har en UDH. [4]

From:

To:

Provider:

Binary:

UDH:

Gs2389gnsakj....

Figur 4.2: Header för binärt meddelande

Binärt sm delas inte upp av SMSD om de är för långa, maxstorleken är därför 140 bytes.

[4]

(23)

4.1.3 Mottaget sm

Mottagna sm lagras i samma form som de ovan men har en del andra fält. (Figur 4.3) From_SMSC som visar SMSC’s nummer, om modemet rapporterar det. Sent är datumet då meddelandet sändes och Received datumet då det mottogs. Subject fältet innehåller modem namnet man angett i konfigurationsfilen. [4]

From:

From_SMSC:

Sent:

Received:

Subject:

Mottagen text!!!

Figur 4.3: Headern på mottaget meddelande

Filnamnet på mottagna sm ser ut enligt följande:

MODEM1.xyzxyz

Där MODEM1 är na mnet på modemet som mottog meddelandet följt av en punkt och sen sex slumpvis valda tecken. [4]

4.1.4 Statusrapport

Statusrapporten mottas från SMSC’n om man konfigurerat det i konfigurationsfilen och om modemet stöder det.

Message_id är ett nummer som identifierar föregående sända sm som denna

statusrapport tillhör. (Figur 4.4) Detta nummer är användbart när man vill logga statusen

på sända sm i en databas. Händelsehanteraren får som tredje argument på sända sm

samma message_id. Notera dock att om ett sm är längre än 160 tecken så splittras det i

flera sm. Händelsehanteraren körs varje gång ett sm blir sänt så man kommer att

mottaga en statusrapport för vaje sänd del i dessa fall. Statuskoderna som finns hittar

man i filen getsms.c. [4]

(24)

From:

From_SMSC:

Sent:

Received:

Subject:

SMS_STATUS_REPORT:

Message_id:

Discharge_timestamp:

Status:

Figur 4.4: Headern på en statusrapport

4.2 Validering av sms-filen

SMSD kontrollerar outgoing queue efter filer att sända, om en sms- fil finns där så jämförs nummret med nummren som finns i blacklist, vilket är en lista som innehåller nummer som man inte tillåter att ta emot sm. Skulle en matchning hittas kommer SMSD’n att avvisa meddelandet och flytta det till failed queue. Om däremot nummret inte finns i blacklist kommer SMSD’n att kontrollera operatörsnamnet i filen och flytta meddelandet till motsvarande operatörskö. Finns det då inget operatörsnamn i filen så kommer SMSD’n att jämföra telefonnummret med en tabell i konfigurationsfilen och flytta meddelandet till motsvarande kö. Man kan även skapa en speciell kö för okända operatörer. Om ett nummer inte skulle finnas i någon operatörstabell i konfigurations- filen så behöver sms- filen då inte avvisas. [4]

4.3 SMSD och Modemet

Modemets uppgift är att kontrollera operatörers köer efter nya sms- filer. När den hittar en fil så kommer den att låsa filen genom att skapa en spärrfil och sen anropa putsms (se beskrivning nedan). Spärrfilen förhindrar att meddelandet sänds av flera modem sam- tidigt. Detta gör att man kan koppla flera modem till en operatörs kö, vilket i sin tur förbättrar prestandan och stabiliteten. [4]

Man kan även använda mer än en dator, alla utrustade med en uppsättning modem för att sända meddelanden. Det är även tillåtet att ha flera SMSD-applikationer i drift på samma uppsättning av köer. [4]

4.3.1 Putsms

Putsms är ett litet program som styr modemet att sända ett enstaka sm. Skulle

sändningen misslyckas kommer putsms att försöka en andra gång, misslyckas det även

denna gång kommer sms-filen att förflyttas till foldern failed queue. Om tre miss-

(25)

lyckade sms- filer flyttas till failed queue utan att någon lyckad sändning skett däremellan, kommer SMSD’s modemfunktion att blockera modemet en viss tid. Har man då mer än ett modem för varje operatör kommer de andra att fortsätta arbeta, så man förlorar ingen trafikförbindelse för ytterligare meddelanden. Man kan se putsms i processlistan med kommandot

^ps

, men bara medan ett sm blir sänt. [4]

Om man använder text sm och anropar putsms manuellt så är headern (se under rubriken Filformat ovan) frivillig då man kan skriva destinationsnummret på kommandoraden. Vid användandet av binärt sm och man kallar manuellt på putsms kommer man att behöva argumentet

^–f

eller

^–F

för att särskilja mellan ASCII och binärt format. [4]

4.3.2 Getsms

Getsms är även det ett litet program, men detta mottager sm. Det kontrollerar modemets SIM-kort efter meddelanden och läser av tillgängliga sm. Mottagna sms- filer hittar man i foldern incoming queue, detta gäller även då man har flera modem. [4]

4.4 Övriga funktioner

4.4.1 Status monitor

Denna funktion visar vad modemet gör och varje tecken representerar ett modem.

Tecknen följer samma ordning som i konfigurationsfilen och statusbetäckningarna är:

o s = sänder

o r = mottager eller kontrollerar efter sm o i = overksam

o b = blockerad (tre misslyckade sm) o - = inte konfigurerad

SMSD skriver texten varje sekund till stdout, som är terminalfönstret. Detta kan man dock omdirigera till annan utrustning eller fil. För att använda status monitor skriver man

^{smsd –s}

. [4]

4.4.2 Statistics

SMSD’n samlar statistisk data, denna datainsamling visar hur många sm som sänts,

mottagits och avvisats. Statistikfilen ger även information om användandet av varje

modem och med ett kalkylprogram kan man lätt skapa diagram. Den behandlade datan

kan vara till stor hjälp en i avgörandet om och när flera modem bör tillsättas för att öka

prestandan.

(26)

SMSD’n skriver statistikfiler i konfigurerat tidsintervall. Om man stannar SMSD’n genom att trycka Ctrl+C eller använda kill- kommandot kommer den att hålla aktuella räknare i en temporär fil, denna fils räknare kommer att läggas in i nästa statistikfil. På detta sätt kommer man inte att förlora räknevärden när programmet stannar. [4]

4.4.3 Logfile

SMSD använder sig av syslog daemon, ett program som exekverar i bakgrunden och är redo att utföra en operation, för att logga meddelanden och man kan konfigurera verbosity nivå som är olika nivåer på status meddelanden, detta görs genom att ändra i syslogs konfigurationsfil. SMSD skapar fel-, varnings-, iaktagnings-, informations- och debug meddelanden. Vill man att meddelandena ska skrivas i en separat fil eller på en annan dator så konfigurerar man om det i syslog, där anges även standardplats för meddelandelog. [4]

4.4.4 Event handler

Detta är ett valfritt script eller program som körs av SMSD då den sänder och mottager ett sm eller då den inte kan sända ett sm. SMSD anropar ett script innan den flyttar sms- filen från operatörens kö till failed eller sent kö och ger två eller tre argument till event handler. Första argumentet är SENT, RECEIVED, FAILED eller REPORT, andra argumentet är namnet på sms- filen och det tredje är MESSAGE_ID på sänt sm. Denna används bara vid lyckad sm-sändning och om man har status report påslaget. [4]

4.4.5 Alarm handler

I händelse av problem kommer detta program att generera la rmmeddelanden i logfilen och kalla på ett valfritt script eller program. Denna egenskap kan användas till att generera larm på ställen där man behöver det. SMSD ger följande argument till event handler: [4]

− Alarmets nyckelord

− Datum i formatet yyyy- mm-dd

− Tiden i formatet hh:mm:ss

− Alarmgrad 0-9

− Modemnamn eller SMSD

− Alarmtext

4.4.6 SQL log

SMSD kan logga alla händelser in i en MySQL tabell som man kan använda till att

skapa rapporter. SQL log innehåller även statuskoderna från statusrapporterna om man

mottager sådana meddelanden. Man installerar scriptet som en event handler, ifall man

(27)

behöver en annan event handler och SQL log samtidigt kan man skriva ett script som kallar på båda. [4]

4.5 Konstruktion

För att konstruera en sms-gateway och få den att fungera så behöver programvaran SMS Server Tool kunna arbeta ihop med ett eller flera GSM-modem, i detta fall användes en Nokia 6210 mobiltelefon. Detta gör man enklast genom att konfigurera om exempel- filen smsd.conf (se Appendix B) som kopierats till katalogen /etc under själva installationen av SMS Server Tool, man kan även skapa en egen konfigurationsfil eller specifisera en annan fil om man så önskar, detta genom att använda alternativet

^–c

.[4]

Hur man konfigurerar smsd.conf finns i Appendix A, det bör dock tilläggas att denna fil är känslig för stora och små tecken, förutom med de boolska värdena yes, no, true, false, on, off, 1 eller 0.[4] Använder man dessutom listade element ska dessa separeras med kommatecken för att kunna läsas av SMSD, vilket är själva programmet i SMS Server Tool som använder konfigurationsfilen.

Konfigurationsfilen består av fyra delar och är listade i tabell 4.1.

Tabell 4.1: Strukturnivåerna i konfigurationsfilen Konfigurationsstruktur

Global del Specificerar modem eller modemens namn och

sökvägar till filer och kataloger samt olika globala variablar.

Kö definition Specificerar namn och sökvägar på opera-

törsköer.

Operatör definition Specificerar prefix och areanummer för

operatörerna, till exempel 4670 utan ”+”

tecknet framför.

En eller flera modem uppsättningar Specificerar inställningar för modemet.

Den globala delen börjar i toppen av smsd.conf och här specificerar man olika

sättningar (se Appendix A), här kommer endast särskilda sättningsdetaljer i konfig-

urationen att tas upp, därib land namnet på modemet som ska användas. Man kan

använda tecken som A-Z, 0-9 och _ (underscore), använd inte mellanslag eller

kontrolltecken. Detta namn kommer att återfinnas i konfigurationsfilen, loggfilen och i

statistikfilen. [4]

(28)

Skulle man vilja ha en gemensam kö för alla destinationer istället för en för varje operatör kan man använda denna lista, detta specificerar man i operatörsdelen i smsd.conf. [4]

0,1,2,3,4,5,6,7,8,9

I modemuppsättningar specificerar man inställningar för modemet, om man använder sig av mer än ett modem måste denna del i konfigurationen upprepas för varje modem.

En del mobiltelefoner kan behöva ha initsträngen satt till ATE0+CPMS="SM" eller ATE0+CPMS="ME" för att tala om för mobiltelefonen var den ska lagra och läsa mottagna sm. ”SM” betyder att den använder SIM-kortet och ”ME” att den använder mobiltelefonens interna minne. Om man är osäker på vilken sträng mobiltelefonen behöver kan man använda initsträngen ATE0, denna funkar bra med de flesta modem.

Utöver initieringen samt andra sättningar (se Appendix A) bör man specificera hastig- heten på den seriella kommunikationen med bitar per sekund, detta görs vid variabeln baudrate i smsd.conf. De flesta modem arbetar bra med 19200 baud, en del kommer dock att behöva 9600 baud. [4]

4.6 Testkörning

Efter att filen smsd.conf konfigurerats så startades SMSD’n och programmen putsms och getsms testkördes. Testkörningarna skedde i omgångar eftersom olika felmed- delanden uppstod vid körning och omkonfigurering av filen var nödvändig. Problemen som uppstod vid körning av programmet putsms orsakades på grund av konfig- urationsfel, kabelfel eller användarfel, här nedan ges några exempel på felmeddelanden som uppstod samt åtgärder för att lösa dessa.

4.6.1 Exempel på Konfigurationsfel

May 13 11:27:48 localhost smsd: Unknown variable in config file [GSM1]: eventhandler

Detta felmeddelande visar på att det finns en okänd variabel ”eventhandler” i konfig- urationsfilens modemuppsättning för [GSM1] (modemets namn). Anledningen till variabelfelet kan vara att man inte använder sig av någon händelsehanterare och detta fel löser man genom att man kommenterar bort denna rad i konfigurationsfilen med tecknet # framför raden innehållande variabeln ”eventhandler”.

4.6.2 Exempel på Kabel/Modemfel

May 13 13:14:43 localhost getsms (/dev/ttyS0): Modem is not clear to send

(29)

Parametern (/dev/ttyS0) pekar på den seriella porten så felet kan bero på att modem- kabeln är felkopplad eller att den inte stöder hårdvaru-handskakning [4], vilket är en synkroniseringsteknik som sker mellan enheter när en anslutning för datakommunik- ation ska upprättas. Detta löser man genom att koppla modemkabeln till rätt seriella port, eller om det beror på handskakningen, kommentera bort raden

^rtscts

i konfig- urationsfilen med #, alternativt införskaffa en modemkabel som har stöd för hand- skakning.

4.6.3 Exempel på kommandofel av användaren

May 14 14:33:30 localhost putsms (/dev/ttyS0): Uups, the modem said ERROR. Try option -m.

Även här används parametern (/dev/ttyS0) men av texten ”putsms” och ”Try option –m”

kan man utröna att kommandot för att sända ett sm är felskrivet. Alternativet –m kopierar hela strängen som ska sändas så lösningen här är att använda sig av –m i kommandot.

Om man försöker sända ett sm med putsms och av någon anledning misslyckas kan man se efter i /var/log/messages var felet ligger. I denna fil finns meddelanden om allt som systemet gör och den visar en detaljrik informationslista med vad som fungerar och vad som är fel. Utförlig loggfil av testkörningen finns i Appendix C.

5 Resultat

Resultatet efter felkorrigeringar är en Sms- gateway som fungerar väldigt stabilt, den både skickar och tar emot sm till operatörerna Telia, Vodafone och Comviq utan några som helst problem. En fullt fungerande sändning och mottagning av ett sm kan se ut som i exemplet nedan som är ett urklipp från terminalfönstret.

[root@localhost bin]# putsms -m sm1 -s46705008999 46706485647

"Testar bara"

[root@localhost bin]# getsms incoming From: 46706485647F

Sent: 05-14-03 15:04:11 Subject: SMS from GSM modem

Testar bara

[root@localhost bin]#

− Sändningen av sm’et är den första och andra raden, där putsms –m är själva

kommandot för att sända sm, det åtföljs av sm1 som är namnet på sms-filen, därefter

(30)

följer nummret till SMSC samt mottagarens nummer och till slut själva texten

”Testar bara”.

− Mottagardelen är där getsms kommandot användas.

− Sjäva sm- meddelandet som hämtades in är de rader som innhåller from, sent, subject samt texten ”Testar bara”.

Hur en fungerande sändning och mottagning av ett sm ser ut i filen /var/log/messages visas i exemlet nedan.

May 14 14:48:34 localhost putsms (/dev/ttyS0): Sending SMS

May 14 14:48:34 localhost putsms (/dev/ttyS0): Checking whether Modem needs PIN

May 14 14:48:34 localhost putsms (/dev/ttyS0): Checking whether Modem is registered to the network

May 14 14:48:35 localhost putsms (/dev/ttyS0): Modem is registered to the network

May 14 14:48:35 localhost putsms (/dev/ttyS0): Selecting PDU Mode 0 May 14 14:48:35 localhost putsms (/dev/ttyS0): Changing SMSC

May 14 14:49:08 localhost getsms (/dev/ttyS0): Checking incoming SMS May 14 14:49:08 localhost getsms (/dev/ttyS0): Checking whether Modem needs PIN

May 14 14:49:08 localhost getsms (/dev/ttyS0): Checking whether Modem is registered to the network

May 14 14:49:08 localhost getsms (/dev/ttyS0): Modem is registered to the network

May 14 14:49:08 localhost getsms (/dev/ttyS0): Selecting PDU Mode 0 May 14 14:49:09 localhost getsms (/dev/ttyS0): Trying to get Stored Message 1

May 14 14:49:09 localhost getsms (/dev/ttyS0): SMS received, From:

46706485647F, Sent: 05-14-03 15:04:11

May 14 14:49:09 localhost getsms (/dev/ttyS0): Message: Testar bara May 14 14:49:09 localhost getsms (/dev/ttyS0): Deleting SMS 1

PDU Modes:

0 success

1 cannot open device

2 cannot verify PIN or modem not ready.

3 modem not registered to the network 4 no SMS available

Av detta meddelande kan man läsa att ett sm ska sändas varvid programmet putsms kontrollerar om modemet behöver någon PIN-kod för att sända sm’et och om modemet är registrerat till nätverket, vilket det är. Därefter kommer selecting PDU Mode 0 som visar att en leveransrapport sänds till SMSC och därefter byter SMSC för sändning av sm’et.

Programmet getsms som kommer raden efter kontrollerar om det finns något sm som

den kan läsa av och därefter görs återigen en kontroll av PIN-kod och

(31)

nätverkstillhörande. PDU- mode 0 betyder här att det finns en leverans i SMSC som

SMSD’n försöker läsa av. Sm’et mottages och det visas från vilket nummer det kommer

och meddelandetexten, därefter tas sm’et bort från SIM-kortet. Sm’et kommer nu att

finnas i foldern incoming.

(32)

6 Diskussion

Informationsinsamling är, om än intressant och lärorikt, verkligen ett tidskrävande arbete som tar upp den största delen av ett examensarbete. En stor fördel i detta arbete var dock att IT-enheten på HTU gav två förslag på programvara att använda. Då den ena, SMSLink, inte hade fungerande sidor på webbplatsen blev valet av programvara lätt då det endast fanns ett val kvar, SMS Server tool. Stefan Frings, som skapat själva programvaran gav mig dessutom tips om var jag kunde hitta bra och relevant information för mitt övriga arbete.

Likaså var hårdvarubiten ett problem då jag fick GSM-modemet först när det bara återstod tio dagar till slutinlämning. Trots detta lilla missöde är jag ändå nöjd med arbetet då jag till slut fick sms-gatewayen att sända och mottaga sm.

Förutom konstruktionsresultatet så resulterade arbetet även i denna omfattande informa- tionsinsamling som är tänkt att underlätta för IT-enheten på HTU i deras egna konstruk- tion av en sms- gateway. Denna informationsinsamling är dock utförd på ett sådant sätt att även andra ska kunna ta del av den.

6.1 Slutsats

SMS Server tool är ett förträffligt bra verktyg att använda vid konstruktion av en sms- gateway och det är lätt att sända och ta emot sm då SMSD’n är rätt konfigurerad. Den är väldigt stabil då den är igång och för att få en misslyckad sändning så måste man nästan medvetet göra ett fel. Programvaran fungerar dock bäst om endast fåtalet sm sänds som i detta fall. I större nätverksmiljöer kan en vidareutveckling av programvaran behöva göras för att kunna sända och ta emot en större mängd sm. Man bör även använda flera GSM-modem så att GSM-systemet kan arbeta tillförlitligt även om något modem blir blockerat, såsom sker vid tre misslyckade sändningar.

Till sist bör det sägas att i denna konstruktion användes manuell sändning och hämtning

av sm vilket inte kommer att ge någon större förbättring utav ett felmeddelandesystem,

utan snarare sämre än en övervakning via ett terminalfönster. Om tjänster som fel-

meddelande via sms, mail till sms samt sms till mail överhuvudtaget ska ha någon effekt

så bör sändning och mottagnig av sm ske automatiskt i vissa tidsintervall.

(33)

7 Referensförteckning

[1] GNU General Public Licence, Free Software Foundation, Inc. (2001)[Internet]

http://www.gnu.org/copyleft/gpl.html (2003-04-07)

[2] Styrande faktorer och övergripande systemkrav vid testning av SIM-

kortskommunikation, Thord Schibler för AU-System Mobile (1999)[Internet]

http://www.e.kth.se/~e94_tsc/WWW/au/docs/tsc-exrapport.pdf (2003-05-14) [3] ETSI TS 100 901 V7.5.0 Specification, European Telecommunications Standards

Institute (1999)[Internet]

http://amber.feld.cvut.cz/user/Pokorny/bpdp/GSM_0340.PDF (2003-04-17) [4] SMS Server Tool, Stefan Frings (2003)[Internet]

http://www.isis.de/members/~s.frings/smstools_index.html

(2003-04-12)

(34)

Appendix A

Installation- och Konfiguration av SMS Server Tool på Linux Red Hat 9.0

Filer som krävs smstools-1.10.3.tar.gz

OSSP mm Shared Memory Library

Installation

1. Öppna ett terminalfönster och logga in som Root 2. Packa upp paketet OSSP mm shared memory library

tar xzf mm-1.3.0.tar.gz ./configure

#konfigurera

make

#kompilerar

make install

#installerar 3. Packa upp smstools paketet där du vill ha det

tar xzf smstools-1.10.1.tar.gz

make –s clean

#rensar gammalt

make –s

#kompilerar

make –s install

#installerar 4. Skapa kö förteckningar för varje operatör i

/var/spool/operatörsnamn

Varningen ”tempnam is dangerous” kan man ignorera om den skulle dyka upp.

(35)

Konfiguration

Exempelkonfigurations filen som ska ändras finns i

/etc/smsd.conf

. Global del:

Den globala delen börjar i toppen av smsd.conf

devices = lista av strängar

Specificerar namnet på de modem du ska använda.

spool = sträng

Specificerar sökvägen till utgående spool katalog.

failed = sträng

Specificerar sökvägen till misslyckade spool katalog. Radera denna rad om du inte vill spara misslyckade sm.

incoming = sträng

Specificerar sökvägen till inkommande spool katalog.

sent = sträng

Specificerar sökvägen till sända spool katalog. Radera denna rad om du inte vill spara sända sm.

mypath = sträng

Specificerar katalogen var du installerat SMS Server Tools binärfiler.

logfile = sträng

Namnet på loggfilen. Om du vill använda syslog daemonen för loggning raderar du denna rad. Du kan använda "1" i loglevel fältet för att skriva till konsollen.

loglevel = integer

Specificerar nivå på loggningen, 4 betyder att alla varningar och fel loggas. Om du vill se en lista med alla möjliga larmnivåer gå till katalogen /src och skriv

grep LOG_ *.c,

dessa nivåer gäller inte för syslog utan där får man konfigurera nivåerna i /etc/syslog.conf.

alarmhandler = sträng

Specificerar ett program eller script som ska anropas då ett alarm uppstår. Skriv hela sökvägen. Om du inte använder någon händelsehanterare radera denna rad.

alarmlevel = integer

Sätter nivån på alarmhanteraren, 2 betyder att endast kritiska felmeddelanden

anropar alarmhanteraren. Värden mellan 2-5 kan användas.

(36)

delaytime = integer

Specificerar den tid SMSD är inaktiv (vid tomma köer) innan den på nytt kontrollerar efter nya filer, tiden är i sekunder.

errorsleeptime = integer

Specificerar fördröjningen mellan ERROR svar från modemet och nästa försök, tiden är i sekunder.

blocktime = integer

Om tre sm misslyckas att sändas kommer modemet att blockeras för denna tid, tiden är i sekunder.

eventhandler = sträng

Specificerar ett händelsehanterarprogram eller script som kommer att utföras då ett sm sänds, mottages eller misslyckas. Skriv hela sökvägen. Om du inte använder någo n händelsehanterare radera denna rad.

stats = sträng

Specificerar katalogen där SMSD sparar statistikfiler. Filnamnet är en tidsstämpel i formatet YYMMDD.HHMMSS. Denna katalog måste du skapa själv innan du startar SMSD. Om du inte behöver några statistikfiler raderar du denna rad.

stats_interval = integer

Denna sätter timern som kontrollerar tidsskillnaden mellan varje statistikfil.

Mäts i sekunder och 3600 betyder att en fil per timme sparas. Om du inte behöver några statistikfiler raderar du denna rad.

blacklist = sträng

Specificerar ett filnamn på blacklistfilen. Ta bort denna rad om du inte ska använda en nummer som ska blockera.

whitelist = sträng

Specificerar ett filnamn på whitelistfilen. Ta bort denna rad om du inte ska använda bara vissa tillåtna nummer att sända till.

checkhandler = sträng

Specificerar ett externt program som talar om för SMSD om sms- filen är giltig.

autosplit = bool

Gör det möjligt eller omöjligt för automatisk delning av stora sms- filer.

Standardvärdet som är ”yes” delar upp sm som är mer än 160 tecken långt.

(37)

receive_before_send = bool

Gör så att SMSD ”flushar” SIM-kortets minne innan den sänder ett sm. Används med modem som inte kan sända sm med ett fullt SIM-kort.

number_parts = bool

Gör det möjligt eller omöjligt att dela nummer i början av varje splittat sm.

Standardvärdet är ”yes”.

Kö definition:

Denna del specificerar namnet på de operatörsköer du vill använda Denna del innehåller en eller flera operatörs ködefinitioner

[queue]

sträng = sträng

Första strängen är operatörens namn. Den andra är sökvägen till spool katalogen för operatören.

Operatör definition:

Operatör definition specificerar nummer prefix hos alla operatörers nät. Nummret står i formatet xxyy där xx är den internationella areakoden och yy är operatörens prefix, lokala areakoden. Använd inte + tecknet framför nummret.

[provider]

sträng = lista med nummer

Första strängen är operatörens namn och ska vara samma som i [queues]. Listan med nummer är alla nummer till operatören.

Modem uppsättningar:

Följande del specificerar inställningar för modemet, denna del måste upprepas för varje modem ifall du använder mer än ett.

[sträng]

Början av ett modemblock. Modemets namn måste vara desamma som angetts i devices raden i den den globala delen.

init = sträng

Specificerar ett modems initierings sträng. Ta bort denna rad om ditt modem inte behöver en initiering.

device = sträng

Specificerar resursens namn på den seriella porten. Normalt ligger resurserna i /dev. Linux exempel: /dev/ttyS0. Windows exempel: /dev/com1. Sola ris exempel: /dev/cuaa.

incoming = special

(38)

Specificerar om programmet ska läsa inkommande sm från detta modem. "Yes"

eller "1" betyder att SMSD läser inkommande sm. Värdet "high" eller "2"

betyder att SMSD läser med högre prioritet, vilket betyder att den bara sänder sm när det inte finns något sm att mottaga."No" eller "0" betyder att den inte läser av mottagna sm.

queues = lista med nummer

Specificerar köerna du vill serva med detta modem, använd samma operatörsnamn som i [queues] och [provider].

pin = 4 siffror

Specificerar PIN-koden på modemets SIM kort. Ta bort denna rad om du inte använder PIN-kod.

mode = sträng

Specificerar vilken version av kommandouppsättning ditt modem har.

old -används för Falcom A1 och en del äldre modem.

new -är för nästan alla mobiltelefoner och modem

ascii -för ascii läge. Denna förenklar debugging men är begränsad till 140 tecken och kan inte sända eller mottaga binära sm. En del modem och mobiltelefoner stöder inte ascii läge.

digicom -för äldre digicom modem.

smsc = nummer

Specificerar SMSC’s nummer som detta modem ska använda för att sända sm.

Ta bort denna rad om du inte behöver den, de flesta modem och mobiltelefoner använder ett standardnummer i SIM-kortet.

Baudrate = integer

Specificerar hastigheten på den seriella kommunikationen i bitar per sekund. De flesta modem arbetar bra med 19200 baud, men en del behöver 9600 baud.

rtscts= bool

Du kan koppla bort hårdvaru handskakningen genom att sätta värdet till ”no”.

Standardvärdet är ”yes”

cs_convert = bool

Om du möjliggör denna kommer programmet att konvertera meddelandets

teckenset till ISO-8859-15 vid sändning och mottagning av sm, annars sker det

utan konvertering.

(39)

report = bool

Om du möjliggör denna så kommer programmet att begära en statusrapport sm från SMSC för varje sänt sm, detta fungerar dock inte på alla modem och mobiltelefoner.

eventhandler = sträng

Specificerar ett händelsehanterar script eller program som kommer att exekveras varje gång du sänder och mottager ett sm på detta modem. Ta bort denna rad om du inte behöver den. Specificerar du en händelsehanterare i denna del kommer SMSD att ignorera den globala händelsehanteraren då den inte kan kalla på båda.

Efter att konfigurationen är klar kan du starta och slå av SMSD med kommandona:

smsd start

#daemonen arbetar i bakgrunden

smsd stop

# stoppar daemonen, alternativt Ctrl-c

Om du vill se vilka kommandomöjligheter som finns tillgängliga för smsd, putsms och getsms starta dom med alternativet -h:

smsd-h getsms-h putsms –h

(40)

Appendix B

Konfigurationsfilen smsd.conf

# Example smsd.conf. Read the manual for a description devices = GSM1

spool = /var/spool/sms/outgoing failed = /var/spool/sms/failed incoming = /var/spool/sms/incoming

#sent = /var/spool/sms/sent mypath = /usr/local/bin logfile = /var/log/smsd.log

#loglevel = 1

#alarmhandler = /usr/local/bin/alarmevent

#alarmlevel = 4 delaytime = 10

#errorsleeptime = 3600

#blocktime = 5

#eventhandler = /usr/local/bin/smsevent

#stats = /var/log/smsd_stats

#stats_interval = 3600

#blacklist = /etc/smsd.black

#whitelist = /etc/smsd.white

#checkhandler = /usr/local/bin/smscheck

#receive_before_send = no

#number_parts = yes [queues]

# Commented lines are examples for germany TELIA = /var/spool/sms/telia

# D2 = /var/spool/sms/D2

# O2 = /var/spool/sms/O2

# EPLUS = /var/spool/sms/EPLUS

# QUAM = /var/sppol/sms/QUAM

# MOBILCOM = /var/spool/sms/MOBILCOM OTHER = /var/spool/sms/OTHER

[provider]

# Commented lines are examples for germany TELIA = 4670

# D2 = 491520, 49162, 49172, 49173, 49174

# O2 = 49176, 49179, 49159

# EPLUS = 49163, 49177, 49178, 49157

# QUAM = 49150

# MOBILCOM = 49156

OTHER = 0,1,2,3,4,5,6,7,8,9 [GSM1]

#init = ATE0

# Windows: /dev/com1, Solaris: /dev/cua/a, Linux /dev/ttyS0 device = /dev/ttyS0

incoming = yes

queues = TELIA, OTHER

#You don't need a PIN for mobile phones

#pin = 1111 mode = new

smsc = 46705008999 baudrate = 19200

(41)

#rtscts = yes

#cs_convert = yes

#report = no

#GSM2]

#init = ATE0

# Windows: /dev/com2, Solaris: /dev/cua/b, Linux /dev/ttyS1

#device = /dev/ttyS1

#incoming = yes

#queues = OTHER

#You don't need a PIN for mobile phones

#pin = 2222

#mode = new

#smsc = 491710760000

#baudrate = 19200

#rtscts = yes

#cs_convert = yes

#report = no

(42)

Appendix C

Testkörningsresultat från /var/log/messages

May 13 11:27:47 localhost smsd: Reading config file /etc/smsd.conf May 13 11:27:47 localhost smsd: Unknown variable in config file:

loglevel

May 13 11:27:47 localhost smsd: Unknown variable in config file:

alarmhandler

alarmlevel

errorsleeptime

blocktime

receive_before_send

number_parts

May 13 11:27:47 localhost smsd: Unknown variable in config file [GSM1]: init

May 13 11:27:47 localhost smsd: Unknown variable in config file [GSM1]: rtscts

May 13 11:27:48 localhost smsd: Unknown variable in config file [GSM1]: cs_convert

May 13 11:27:48 localhost smsd: Unknown variable in config file [GSM1]: report

May 13 11:27:48 localhost smsd: Task for device GSM1 has started.

May 13 11:27:48 localhost smsd: UID and GID has been set in main spooler.

May 13 11:27:48 localhost smsd: Task for main queue has started.

May 13 11:28:09 localhost smsd: Reading config file /etc/smsd.conf May 13 11:28:09 localhost smsd: Unknown variable in config file:

loglevel

alarmhandler

alarmlevel

errorsleeptime

blocktime

receive_before_send

number_parts

May 13 11:28:09 localhost smsd: Unknown variable in config file [GSM1]: init

May 13 11:28:09 localhost smsd: Unknown variable in config file [GSM1]: rtscts

May 13 11:28:09 localhost smsd: Unknown variable in config file [GSM1]: cs_convert

May 13 11:28:09 localhost smsd: Unknown variable in config file [GSM1]: report