Transkript

1

2 Sammanfattning Denna rapport beskriver utvecklingen av ett datorprogram för att förmedla information till olika mobiltelefoner. Flera olika befintliga tekniker undersöktes samt även några kommande tekniker. Denna undersökning blev sedan den grund varpå programmet baserades. Programmet (servern) togs fram i syfte att underlätta vid distribution av information till olika kunder. Genom att bygga upp en databas med respektive kunds telefonnummer, mobiltelefonmodell och önskad distributionsmetod kan programmet själv välja meddelandets format samt hur det ska distribueras. Personal eller andra program som skickar meddelanden via denna server behöver inte känna till mottagarens mobiltelefonmodell. De som skapar meddelandet sänder det till servern som sedan hanterar konvertering, formatering och distribution av meddelandet. Till detta program konstruerades även en klient som kommunicerar med servern. Klienten togs fram som en meddelandeeditor som vid start laddar ner befintliga mallar ifrån servern. Denna nedladdningsmöjlighet medför att mallar kan läggas till och förändras på servern och sedan automatiskt distribueras ut till respektive klient vid nästa nedladdning. Denna idé samt en insticksmodul-lösning på servern medför att nya tekniker kan läggas till. Dessa tekniker smälter in i programmet och kan således utnyttjas på ett för användaren redan bekant sätt. iii

3 iv

4 Abstract This report is the result of my Master s thesis project at the First Degree Programme in Mathematics and Computer Science at Stockholm University. The title of the report is Information streams between computer system and mobile phone. A general system for distribution of text based information via different mobile phone techniques. This report describes the development of a computer program to distribute information to different models of mobile phones. First, several distribution techniques, both existing and those under development, where examined. The results obtained in the investigation were then the starting point for the development of the program. The purpose of the program (server) was to make the distribution of information to different customers as easy as possible. By building a database containing information about each customer s phone number, mobile phone model and preferred distribution method, the program can select the proper message format and how to send it. Persons or other programs that send messages through this server do not need to know the recipient s mobile phone model. The sender creates the message and sends it to the server, which then handles the conversion, shaping and distribution of the message. A client was also created that communicates with this server. The client was created as a message editor that downloads the available templates from the server. This download function allows templates to be added or changed at the server and thereafter automatically be distributed to each client at their next download. This idea and a plugin-solution on the server allow for easy addition of future techniques. New techniques are incorporated into an environment already familiar to the user. v

5 vi

6 Förord Denna rapport är ett resultat av mitt examensarbete i datalogi, omfattande 20 poäng, vid institutionen för numerisk analys och datalogi (Nada) på Stockholms universitet. Arbetet har utförts på Aktiedirekt vid Stureplan i Stockholm. Handledare på Aktiedirekt har varit Erik Agsjö och på Nada har det varit Kai-Mikael Jää-Aro. Här vill jag passa på att tacka Kai-Mikael Jää-Aro för all hjälp med rapporten. Stockholm, sommaren 2002 Olle Persson vii

7 viii

8 Innehåll 1 Inledning Rapportöversikt Teknikbeskrivning GSM GSM-teknik GSM-celler GSM-kontrollkanaler GSM-faser SIM-kort Push-/Pull-teknologi Push-teknologi Pull-teknologi Förmedlingstekniker Short Message Service (SMS) Cell Broadcast SMS (CBS) Smart Messaging (SM) Wireless Application Protocol (WAP) SIM Application Toolkit (STK) Framtida tekniker Enhanced Messaging Service (EMS) Multimedia Messaging Service (MMS) Fler tekniker Utvärdering Analys Problem Syfte Förutsättningar Krav och önskemål Övergripande analys Fas Fas Detaljerad analys Identifierare Information (meddelandedata) Val av teknik vid skickning Teknikvalssystem (upp-/nerkonvertering) Konverteringssystem (språk) Skickningssystem Design Server...36 ix

9 4.2 Klient Implementation Problem och lösningar Startförlopp Klienten Granskning Slutsatser...53 Referenser...54 x

10 Förkortningar 3GPP 3rd Generation Partnership Project AD Aktiedirekt API Application Programming Interface CBS Cell Broadcast SMS CIMD Computer Interface for Messaging Distribution DMCP Dynamic Menu Control Protocol EEPROM Electrically Erasable Programmable Read Only Memory EMS Enhanced Messaging Service ETSI European Telecommunications Standards Institute GPRS General Packet Radio Switching GSM Global System for Mobile Communication GUI Graphical User Interface HDML Handheld Device Markup Language HDTP Handheld Device Transport Protocol HTML HyperText Markup Language HTTP HyperText Transfer Protocol IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity IP Internet Protocol ISDN Integrated Services Digital Network ISO International Standards Organization ITTP Intelligent Terminal Transfer Protocol MExE Mobile Station Application Execution Environment MIME Multipurpose Internet Mail Extension MMS Multimedia Messaging Service MMSE Multimedia Messaging Service Environment MO Mobile Originating MT Mobile Terminating NBS Narrow Band Socket NMT Nordic Mobile Telephony OSI Open Systems Interconnect PAP Push Access Protocol PI Push Initiator PPG Push Proxy Gateway RAM Random Access Memory RDS Radio Data System RMI Remote Method Invocation ROM Read Only Memory SIA Session Initiation Application SIM Subscriber Identity Module SM Smart Messaging SMS Short Message Service SMSC Short Message Service Center SMTP Simple Message Transfer Protocol xi

11 STK TCP TTML UDP UI VAS WAE WAP WDP WML WSP WTA WTAI WTLS WTP XML SIM Application ToolKit Transmission Control Protocol Tagged Text Markup Language User Datagram Protocol User Interface Value Added Services Wireless Application Environment Wireless Application Protocol Wireless Datagram Protocol Wireless Markup Language Wireless Session Protocol Wireless Telephony Application Wireless Telephony Application Interface Wireless Transport Layer Security Wireless Transaction Protocol extended Markup Language xii

12 1 Inledning Detta examensarbete har utförts på Aktiedirekt (AD) som är ett nätmäkleriföretag som erbjuder sina kunder att handla med aktier och liknande papper via Internet. Examensarbetet bygger på att AD även förmedlar information till sina kunder via Internet. Nya kanaler har blivit tillgängliga och AD har arbetat för att även dra nytta av dem. En kanal som vuxit sig stark och som blivit spännande är mobiltelefonin. Mobiltelefonen är intressant då den har blivit var mans egendom, detta gäller speciellt Aktiedirekts kunder. Dagens 1 mobiltelefoner tillhandahåller inte bara teknik för vanliga telefonsamtal utan numera finns det även många olika typer av tekniker för att skicka information till mobiltelefonen. Detta är intressant då det leder till att man får en kanal till kunden som kunden har tillgång till var som helst samt när som helst. Det i sin tur öppnar för många olika tänkbara informationsförmedlingstjänster (aktiekurser, börshändelserapportering etc.). Eftersom AD får tillgång till, och förmedlar olika typer av ekonomisk information (nyheter, ekonomiska nyheter, kampanjinformation etc.) så är det både i AD och i kundens intresse att förmedla den så snabbt som möjligt. Detta eftersom denna typ av information är viktig på dagens börsmarknader. Kunden tjänar på det eftersom han får tillgång till information snabbt, dvs. han kan utnyttja den vid handel på börsen. Aktiedirekt tjänar på det då det leder till lojala och nöjda kunder. Problemet för AD har varit att det finns många olika tekniker och mobiltelefoner. Detta har gjort det besvärligt att dra nytta av de tillgängliga tekniker som finns. Aktiedirekt ville att dagens tekniker skulle granskas och sedan skulle ett program konstrueras. Syftet med detta program var att skapa en grund för befintliga och kommande tekniker så att AD skulle kunna dra nytta av dem och därmed förmedla sin information även via denna kanal. Under slutskedet av examensarbetet blev Aktiedirekt uppköpta av ett annat nätmäkleriföretag. Detta ledde till att all utveckling av programvaror lades ned direkt, vilket i sin tur ledde till att driftstester av examensarbetet inte blev möjliga. Detta gjorde att designen av klienten och servern inte kunde testas och utvärderas i en fullt realistisk miljö. 1 Granskningen av förmedlingstekniker skedde under år

13 1.1 Rapportöversikt Denna rapport består av tre större delar. Först beskrivs tekniker därefter analys och design samt sist implementationen. Kapitel 2 beskriver de befintliga tekniker som fanns och som var mest relevanta för detta exjobb. Där tas också några av de kommande teknikerna upp som skulle kunna passa in i det program som detta exjobb ledde fram till. Kapitel 3 och 4 beskriver analys och design av programmet. Först behandlas problem och syfte för att sedan gå in på en översiktlig analys. Denna efterföljs av en mer detaljerad analys som beskriver de problem och lösningar som upptäcktes. Till sist beskrivs designen av server och klient samt hur designen av användargränssnittet togs fram. Kapitel 5 tittar på implementationen av programmet, beskriver själva startförloppet för server och klient samt några av de viktigaste delarna i servern. Här visas även hur klientens användargränssnitt ser ut, används samt till sist en granskning som påtalar brister och oklarheter i programmet. 2

14 2 Teknikbeskrivning Antalet mobiltelefoner (Bild 1) ökar och nya modeller kommer ut med ny teknik. Teknikerna blir mer och mer avancerade och ger därmed utrymme för nya möjligheter till kommunikation. Bild 1 Några olika mobiltelefoner som finns på marknaden. De mobiltelefonsystem som används idag är NMT (Nordic Mobile Telephony), GSM (Global System for Mobile Communication) samt GPRS (General Packet Radio Switching) som nyligen blivit tillgängligt. Vid årsskiftet 2001/2002 fanns det 7,15 miljoner abonnemang i Sverige (NMT + GSM + GPRS) vilket motsvarar en marknadspenetration på ungefär 80 % enligt MobilTeleBranchen (MTB I Sverige är det GSM som än så länge dominerar marknaden stort. 2.1 GSM Idén om ett cellbaserat mobilt radiosystem, uppfanns i början av 70- talet vid Bell Laboratories i USA. Men inte förrän i början av 80-talet kom det analoga kommersiella system som använde den cellbaserade strukturen (förklaras i avsnitt 2.1.1). I Skandinavien lanserades Nordic Mobile Telephones (NMT)-450 och i Storbritannien/Irland kom Total Access Communication Systems (TACS). Tyskland och Portugal använde C-450 medan Frankrike och Italien utvecklade egna standarder [GSM History]. Dessa analoga system växte snabbt i Europa, speciellt i Skandinavien och Storbritannien. Ett problem som uppstod var att varje land utvecklade sina egna system. Detta ledde till inkompatibilitet mellan olika länders mobiltelefoni. För att åtgärda detta växande problem skapades 1982 Groupe Spécial Mobile (GSM) av Conference of European Posts and Telecommunication (CEPT). GSM fick i uppgift att skapa ett standardiserat cellbaserat mobilt radiosystem (GSM-förkortningen kom senare att stå för Global System for Mobile Communication). 3

15 Detta system skulle uppfylla följande kriterier: Effektivt utnyttjande av frekvenser. God ljudkvalitet. Kompatibilitet med system som ISDN (Integrated Services Digital Network). Billiga telefoner och basstationer. Stöd för internationell roaming (verbet roam betyder ungefär ströva eller flacka och internationell roaming innebär att en mobiltelefon kan röra sig fritt mellan olika länders GSM-nät). Stöd för handburna enheter. Stöd för nya typer av tjänster. Till skillnad mot de tidigare nätverken var GSM baserat på digital teknik. Vad det gällde effektivt utnyttjande av frekvenser var de digitala nätverken bättre än de analoga. Företagen bakom de analoga nätverken föreslog att ytterligare frekvenser skulle utnyttjas för att överkomma detta problem men då frekvensantalet är begränsat förkastades detta förslag GSM-teknik En viktig del i de nya mobiltelefonnäten var deras skalbarhet. Det var viktigt eftersom de skulle täcka både tät- och glesbefolkade områden. Problemet med skalbarheten har med frekvensutnyttjande att göra. I GSM900 finns 124 tillgängliga frekvenser. Om en frekvens används av en sändare kan inga andra sändare använda samma frekvens inom den första sändarens sändningsavstånd. Eftersom det bara finns ett begränsat antal frekvenser och stora områden ska täckas, så fungerar det inte att öka sändningsstyrkan för att täcka dessa. För om man t.ex. låter en sändare täcka en hel stad, kan bara 124 personer ringa samtidigt. Det kanske inte låter så farligt men om man tänker sig en stad med en miljon invånare då är det inte längre acceptabelt. Starkare sändare ger inte en skalbar lösning. Antalet samtidiga telefonsamtal i olika områden kan man dock reglera genom att införa två regler: 1. Sändningsstyrkan i varje cell anpassas så att intilliggande celler inte störs. 2. Grannceller använder inte samma frekvenser utan återanvändning av frekvenser sker i ett visst mönster. Dessa regler leder till att man kan återanvända frekvenser i olika områden och därmed får man en skalbar lösning som fungerar över stora samt olika typer av landområden. 4

16 Genom att implementera dessa regler kan man uppnå den skalbarhet som eftersöks. I områden där många samtal görs under en och samma tidsperiod placeras ett flertal master ut med låg sändningsstyrka och i områden där färre samtal sker samtidigt placeras ett mindre antal master med högre sändningsstyrka. Mast som använder frekvensmängd A Mast som använder frekvensmängd B Mast som använder frekvensmängd C Mast som använder frekvensmängd D Bild 2 Hur celler kan se ut samt exempel på hur olika frekvensuppsättningar kan placeras ut för att inte störa varandra [GSM HKP]. I Bild 2 ser man ett exempel på hur ett täckt område kan se ut. Notera att samtliga grannar till varje mast använder sig av olika uppsättningar av frekvenser för att inte störa varandra GSM-celler Cellen är, som vi tidigare sett, grunden till hur man kan skapa ett skalbart mobiltelefonnät. Det som kallas cell (se Bild 3) är området kring en eller ett fåtal sändare. M o b i l t e l e f o n m a s t Cell Bild 3 Området kring en eller ett fåtal sändare (här representerade av en mobiltelefonmast) kallas för cell. Cellens storlek (representerat av ovalen) bestäms av hur stor sändningsstyrka som sändaren/sändarna använder. 5

17 Cellerna organiseras i grupper och dessa grupper kallas för kluster. Hur många celler som ingår i ett kluster varierar i olika områden. Antalet är viktigt då det ger hur många samtal som kan ske vid samma tillfälle i klustret. Få celler per kluster medför att fler samtal kan ske samtidigt och tvärtom ger fler celler få samtal vid samma tillfälle [GSM JGS]. Eftersom cellerna ska täcka olika typer av områden, från stora områden med gles befolkning till små områden med hög befolkning, används olika typer av celler. Det finns fyra typer av celler: Macro-celler Macro-celler används i glesbefolkade områden. Dessa celler använder hög sändningsstyrka som därmed medför att ett stort område kan täckas. Det vill säga få celler kan täcka stora områden. Detta leder dock till att antalet telefonsamtal som kan göras samtidigt begränsas. Micro-celler Micro-celler används i tätbefolkade områden. I dessa celler sänder man med lägre styrka och täcker därför mindre områden. Detta innebär att fler celler behövs för att täcka området. I och med att fler celler används ökar även antalet telefonsamtal som kan ske samtidigt inom denna region. Selective-celler Ibland finns det regioner som inte lämpar sig för cirkulära celler. Vanlig micro-cell täcker 360 grader runt masten Selec tive- cell med 240 gradig täckning Selective- ce ll med 120 gradig täckning Bild 4 Till vänster en cell med 360 graders täckning. Mitten och till höger två exempel på selective-celler. Till exempel vid täckning av en tunnelmynning är det inte nödvändigt att använda en cell som täcker 360 grader utan det kan räcka med en 120-gradig selective-cell (se Bild 4) som riktas in mot tunnelmynningen. I områden/platser där inte en 360-gradig täckning behövs, används selective-celler. 6

18 Umbrella-celler Umbrella-celler används i regioner där många micro-celler korsas under en kort tid. Till exempel vid en motorväg, där små celler används, kommer det att ske många överlämningar (när en mobiltelefon förflyttas från en cell till en annan där den nya cellen övertar hanteringen av telefonsamtalet kallas det för en överlämning). Alla dessa överlämningar medför onödigt mycket administrativt arbete. För att undvika detta beteende introducerade man umbrella-celler. En umbrella-cell arbetar parallellt (på en annan uppsättning frekvenser) med ett antal micro-celler. När ett telefonsamtal genererar många överlämningar kopplas det samtalet över till umbrella-cellen. Därmed kan denna celltyp ta vid och minska antalet nödvändiga överlämningar GSM-kontrollkanaler En kontrollkanal är en radiokanal som överför administrativa data mellan mobiltelefonen och GSM-nätet. Kontrollkanalerna har till uppgift att sköta bland annat dessa uppgifter: Informera om inkommande samtal till mobiltelefonen. Sköta initiering av telefonsamtal. Tillhandahålla information om nätverkets kvalité. Hålla reda på var mobiltelefonen befinner sig. Synkronisera mobiltelefonen till nätverket. Tala om för mobiltelefonen vilken frekvens den ska använda. Hantera överlämning mellan cellerna. Kontrollkanalerna kan som sagt ses som administrativa kanaler. Men de tillhandahåller också tjänster såsom SMS (Short Message Service) som kommer att behandlas senare (se avsnitt 2.3.1). Eftersom dessa kanaler inte utnyttjar lika mycket bandbredd som vid ett vanligt telefonsamtal kan t.ex. tjänsten SMS användas även fast det inte går att ringa ett telefonsamtal GSM-faser GSM har utvecklats i olika faser. I GSM-standarden kallas de för Phases. Här följer några exempel på vad som tillfördes i de olika faserna [Phases]: Fas 1 Vanliga samtal, upptaget, inget svar. Telefonen ej nåbar. Vidarekoppling. 7

19 Spärra vissa utgående/inkommande samtal. SMS (Short Message Service) Tillåter skickning av textmeddelanden till och från mobiltelefoner (se avsnitt 2.3.1). Global roaming Besök ett annat land som har GSM samt ett roamingavtal (innebär att de två ländernas mobiltelefonoperatörer har en överenskommelse) och telefonen kan användas med sitt vanliga telefonnummer/abonnemang. Fas 2 Multipartssamtal Möjlighet till telefonsamtal med flera personer samtidigt. Vänteläge Placera ett samtal i vänteläge. Samtal väntar Informerar om ett inkommande samtal under det pågående samtalet. Mobile Data Services Tillåter handenheten (mobiltelefon eller liknande GSM-enhet) att kommunicera med datorer. Mobile Fax Service Tillåter handenheten att sända, hämta och ta emot faxmeddelanden. Nummerpresentation Tjänst som tillåter telefonanvändaren att se inkommande samtals telefonnummer innan man svarar. Samtalskostnadsöversikt Service för att hålla reda på samtalskostnaderna. Cell Broadcast Tillåter handenheten att ta emot ett slags SMS (se avsnitt 2.3.2). Fas 2+ Uppgradering och förbättring av existerande tjänster. Förbättringar av SIM. Största delen av uppgraderingen i Fas 2+ innebar förbättringar inom dataöverföringar SIM-kort I en mobiltelefon finns det ett SIM-kort (Subscriber Identity Module) som är en viktig del i GSM-nätet (se Bild 5). Bild 5 Det finns 2 storlekar på SIM-kort. Här är den mindre varianten, dock något förstorad (normalt 2,5*1,5 cm). Den större varianten är stor som ett kreditkort. 8

20 Det är SIM-kortet som ger mobiltelefonen tillgång till GSM-nätet. I SIM-kortet finns nämligen information om vilket nät (nätverksoperatör) mobiltelefonen ska koppla upp sig mot. Det finns även information som används vid autentifiering och säkerhet (bland annat finns en kryptonyckel som används av nätverket för att skydda telefonsamtalen) i GSM-nätet. SIM-kortet har ett unikt identifikationsnummer kallat för IMSI (International Mobile Subscriber Identity) som tillsammans med mobiltelefonens unika identifierare IMEI (International Mobile Equipment Identity) ger tillgång till mobiltelefonnätet. Detta ger en extra mobilitet då användaren kan ta sitt SIM-kort och använda det i vilken annan kompatibel mobiltelefon som helst och därifrån ringa och ta emot sina egna samtal (innan SIM-kortet kom var abonnemangen bundna till mobiltelefonen). För att ringa ett telefonsamtal krävs alltså både en mobiltelefon och ett SIM-kort. Det finns dock ett undantag och det är speciella larmnummer. Dessa larmnummer (t.ex. 112) kan ringas utan ett SIM-kort. SIM-kortet har också blivit ett lagringsställe för t.ex. olika telefontjänster, telefonbok, SMS och annan telefonnummerinformation som vidarekoppling, spärrade samtal och samtalstid. Kortens lagringskapacitet ökar hela tiden och numera finns det också SIM-kort med en liten processor i sig. Dessa beskrivs senare i SIM Application Toolkit (se avsnitt 2.3.5). 2.2 Push-/Pull-teknologi Det finns två olika metoder för att sända information till en användares klientenhet (t.ex. en dator eller mobiltelefon som kan kommunicera med en server) Push-teknologi Push innebär att information skickas till användarens klientenhet utan att en förfrågan har gjorts (se Bild 6). Här kan SMS användas som ett exempel. På en server genereras information som sedan skickas till användarens klientenhet utan att användaren skickat en förfrågan. Push Klient Server Bild 6 Servern initierar och skickar informationen till klienten. 9

21 Ett annat sätt att definiera push på är: Push initieras alltid ifrån servern Pull-teknologi Pull innebär att information skickas till användarens klientenhet efter att en förfrågan har gjorts (se Bild 7), exempelvis vid Internetsurfning. Användaren klickar på en länk på en webbsida. Detta genererar en förfrågan från klienten till servern. Servern skickar sedan tillbaka den efterfrågade informationen till klienten. Pull förfrågan Svar Klient Server Bild 7 Klienten efterfrågar information som servern sedan förmedlar till klienten. Ett annat sätt att definiera pull på är: Pull initieras alltid ifrån klienten. 2.3 Förmedlingstekniker Idag finns det många olika tekniker för att skicka information till mobiltelefoner. Här beskrivs de tekniker som har testats och andra liknande tekniker som eventuellt skulle kunna fungera för spridning av information till mobiltelefoner Short Message Service (SMS) SMS används för att skicka meddelanden till och från mobiltelefoner. Dessa meddelanden kan bestå av max 160 tecken eller 70 tecken om t.ex. arabiska eller kinesiska används. SMS skapades som en del i GSM Fas 1-standarden. Det första SMSmeddelandet tror man skickades över Vodafones GSM-nätverk i Storbritannien december Det skickades från en pc till en mobiltelefon [GSMWorld]. För att kunna skicka SMS behövs en mobiltelefon med stöd för SMS, ett SIM-kort med abonnemang eller kontantkort knutet till en telefonoperatör som tillhandahåller tjänsten SMS. SMS skickas med ett förbindelselöst protokoll, det vill säga det skapas ingen direktkontakt mellan sändare och mottagare då ett SMS skickas, 10

22 vilket sker vid ett vanligt telefonsamtal. Detta leder till att skickade SMS inte alltid kommer fram i samma ordning som de skickas och man kan inte heller säga när ett meddelande kommer fram till mottagaren. För att lösa det senare problemet har man infört en bekräftelsefunktion som skickar en bekräftelse till sändaren då meddelandet har levererats till mottagaren. MO (Mobile Originating) MT (Mobile Terminating) Mobiltelefonmast SMSC Mobiltelefonmast SMS Bild 8 Skiss av förloppet då ett SMS skickas. Som man här kan se sker skickningen av ett SMS i två steg, MO samt MT. [GSM 03.40] För att skicka ett SMS till en annan mobiltelefon så sker själva överföringen i två steg. Första steget kallas Mobile Originating (MO) och det andra kallas för Mobile Terminating (MT). MO är steget då meddelandet skickas från mobiltelefonen till SMS-Centret (SMSC) och MT är sista biten ifrån SMSC till den egentliga mottagarens mobiltelefon (se Bild 8). SMSC lagrar meddelandet tills det kan skickas vidare till mottagaren. Hur länge det lagras beror på flera faktorer. Vanligtvis skickas det vidare med en gång. Men om mobiltelefonen är avstängd eller av någon annan anledning inte är tillgänglig för nätverket, sparas meddelandet en viss tid. Varje SMS har en giltighetstid som kan sättas då det skickas. Giltighetstiden brukar ligga runt en vecka men varierar mellan olika mobiltelefonoperatörer. SMS-meddelandet sparas hos SMSC tills mobiltelefonen kan ta emot meddelandet eller så går giltighetstiden ut vilket medför att det kasseras. Själva överföringen av SMS sker över GSM-kontrollkanalerna (se avsnitt 2.1.3). Detta leder till ett annorlunda beteende jämfört med vanliga telefonsamtal. Då kontrollkanalerna inte behöver samma bandbredd som vid ett vanligt telefonsamtal kan SMS även skickas då det inte är möjligt att ringa ett vanligt telefonsamtal. En annan fördel är att det är möjligt att ta emot SMS då man talar i telefonen. 11

23 Man är inte bara begränsad till att skicka SMS med hjälp av mobiltelefon utan det går även att använda en dator med modem (se Bild 9). Dator Modem Dator Internet SMSC Bild 9 Exempel på olika sätt att koppla upp sig mot SMSC. Datorn ringer upp SMSC med hjälp av modemet och kommunicerar sedan via ett speciellt protokoll för att skicka SMS. Här debiteras telefonsamtalet samt kanske en viss kostnad per skickat SMS till telefonräkningen. Nu finns det även mobiltelefonoperatörer som erbjuder kommunikation med SMSC via Internet. Detta innebär att ett användarnamn och lösenord erhålls av mobiltelefonoperatören som sedan kan användas för att koppla upp sig mot SMSC med TCP/IP. Därefter sker kommunikationen med SMSC på liknande sätt som med modemet men uppkopplingstiden försvinner nästan helt. Till detta användarnamn är ett konto kopplat som debiteras enligt överenskommet kontrakt med mobiltelefonoperatören. SMS-roaming SMS-roaming innebär att mobiltelefonanvändaren kan förflytta sig mellan olika operatörers mobiltelefonnät och fortfarande kunna ta emot/skicka SMS. Detta är möjligt om bägge mobiltelefonoperatörer tillhandahåller SMS-tjänsten samt att de har en voice-roaming överenskommelse. Voice-roaming innebär att vanliga mobiltelefonsamtal kan göras mellan dessa två mobiltelefonnät. Det är inte självklart att alla mobiltelefonoperatörer vill tillåta den här möjligheten. Orsaken till det är att det tekniskt sett leder till att konkurrenter får tillgång till deras kontrollkanaler, vilket inte alla mobiltelefonoperatörer är villiga att gå med på. 12

24 2.3.2 Cell Broadcast SMS (CBS) I Fas 2 av GSM-standarden introducerades CBS [GSM 03.41]. CBS utnyttjar samma kontrollkanaler som SMS gör men mottagaren är inte en enskild mottagare utan alla som befinner sig inom ett specifikt område. Här kommer GSM-cellerna in i bilden (se avsnitt 2.1.2). CBS gör det möjligt att skicka ett slags SMS till ett område (en eller flera celler) eller rent av till hela mobila nätverket. Det är alltså möjligt att informera ett okänt antal personer som befinner sig inom ett begränsat område. Hur ofta, hur länge och vilket område som meddelandet ska sändas ut till, bestäms på förhand mellan mobiltelefonoperatören och informationsspridaren. Dessa meddelanden har en begränsning på 93 tecken per CBS. Upp till 15 CBS kan kedjas ihop (sammanbindas) till ett större makromeddelande. Varje CBS har ett identifikationsnummer som lagras i telefonen under en viss tid (tiden är olika beroende på märke/modell) för att förhindra att samma meddelande tas emot flera gånger. För att mobiltelefonen ska kunna välja vilka meddelanden som den ska ta emot så tilldelas varje CBS en meddelandeklass. Denna klass talar om vilken kategori och vilket språk meddelandet består av. Detta gör att man som användare har möjlighet att välja vilken typ av meddelanden som man vill ta emot och på motsvarande sätt vilka som ska ignoreras. Användningsområden som CBS lämpar sig för är allmän information som riktar sig till grupper inom ett specifikt område. Några exempel skulle kunna vara information om väder, trafik, reklam eller annan lokal information Smart Messaging (SM) Smart Messaging är ytterligare ett steg i utvecklingen för att förmedla information och olika sorter av data till mobiltelefonerna. Med SM kan man till sin mobiltelefon bl.a. föra över ringningssignaler, visitkortsinformation och små bilder. SM är framtaget av Nokia och är ingen öppen standard vilket betyder att det främst är Nokias mobiltelefoner som stöder denna teknik. I mars 1997 offentliggjorde Nokia sitt Smart Messaging-koncept [SM]. Den definierar format för hur olika typer av meddelanden ska se ut. Från början byggde SM på en teknik som heter Narrow Band Socket (NBS) som togs fram av Intel och Nokia. Det fanns två tankar bakom NBS: 13

25 1. Protokollet skulle modelleras efter de kända internetprotokollen UDP och TCP med viss modifikation (t.ex. minskades de paketadministrativa data som skickas med vid UDP och TCP) för att optimera transport över långsamma bärare. 2. Designen av Application Programming Interface (API) för NBS skulle använda ett redan känt API inom nätverksprogrammering. Det paradigm som valdes var portar och därmed fick utvecklarna ett välkänt API som de redan var vana att använda. Lite senare togs NBS upp i WAP Forums (se avsnitt 2.3.4) standard Wireless Datagram Protocol (WDP). Detta ledde sedermera till en rekommendation att använda WDP istället för NBS. Idag tillåter Smart Messaging en mängd olika bärare. I Bild 10 visas några av de möjligheter som finns. Smart Messages UDP/IP Över UDP Data call Över WDP WDP Andra bärare Över NBS NBS GSM SMS Nyckelordshuvud Bild 10 Exempel på hur Smart Messaging-meddelanden kan förmedlas. Som man ser i Bild 10 så kan man även skicka SM direkt över SMS. Här blir förfarandet lite annorlunda än om man skickar via WDP och NBS. För att mottagarenheten ska kunna känna igen ett SM-meddelande måste en identifierare läggas in i SMS-meddelandet. Först i varje SMS läggs ett litet huvud in som talar om vilken sorts meddelande som skickas. Detta huvud gör det även möjligt att kedja (sammanbinda) flera SMS till ett större SM-meddelande. När detta huvud upptäcks slussas den efterföljande informationen vidare till respektive tolkningsprogram. 14

26 I telefonen finns ett program som har hand om portarna och när det skickas information till en viss port förmedlas den informationen vidare till dess tolkningsprogram. I maj 1999 kom Smart Messaging-specifikationen version [SM 2_0_0] och i den finns följande meddelandeformat beskrivna: Kompakta Visitkort Visitkort anpassade för SM enheter. Generiskt Visitkort Visitkort anpassade enligt Versit vcardspecifikationen [vcard]. Servicekort Lagring av tonvalskombinationer som t.ex. kan användas som hjälpmedel vid tonvalstelefontjänster. Konfiguration av Internetanslutning Ger möjlighet till konfigurering av SM-enheten via detta meddelandeformat (t.ex. av mobiltelefonoperatören). Kalender Kalenderinformation enligt Versit vcalendarspecifikationen [vcalendar]. Ringsignaler Möjlighet att skicka och ta emot olika ringsignaler. Grafiska logotyper och ikoner Möjlighet att skicka och ta emot logotyper och ikoner. E-post-notifiering Meddelande som talar om att det finns ny e-post på servern. Dynamic Menu Control Protocol (DMCP) Gör det möjligt för en tillåten part att skapa och förändra menystrukturen på mobiltelefonen. Man skulle t.ex. automatiskt kunna ha operatörsspecifika tjänster i SM-enheten (om SM-enhetens ägare ger tillåtelse till operatören). Dessa tjänster kan sedan ändras/uppdateras automatiskt av operatören. Tagged Text Markup Language (TTML) En enklare typ av HTML. Tillåter mobiltelefoner med SMS-stöd och SM-enheter med en liten webbläsare inbyggd att presentera listor, textfält, länkar till olika tjänster osv. Detta möjliggörs genom att en speciell sorts TTML-server används. I december 2000 kom en ny Smart Messaging-specifikation version [SM 3_0_0] där Nokia (av någon anledning) har valt att ta bort några av dessa meddelandeformat ur specifikationen. Där finns t.ex. inte kompakta visitkort, servicekort, DMCP och TTML kvar längre, men dessa format fungerar fortfarande i många SM-enheter Wireless Application Protocol (WAP) Tekniken WAP ger möjlighet för en enhet, t.ex. en WAP-kompatibel mobiltelefon, att hämta information ifrån Internet. Detta görs genom att mobiltelefonen kopplar upp sig mot en WAP-gateway som sedan 15

27 ger tillgång till webbservrar på Internet. Man skulle kunna likna en mobiltelefon vid en enkel dator med en liten webbläsare. Mycket av WAP har baserats på olika Internetstandarder bl.a. XML och IP. Men eftersom nya problem tillkommer då trådlös kommunikation används, såsom ökad latens (fördröjningar), svårt att säkerställa tillförlitlighet i överföringar samt en begränsad bandbredd, har vissa modifikationer fått göras för att komma till rätta med dessa problem. Historia Det var runt 1995 som föregångarna till WAP började konstrueras. Ericsson drog igång ett projekt för att skapa ett generellt protokoll som skulle användas till Value Added Services (VAS) i mobila nätverk (VAS är en tjänst som tillför kunden ett mervärde; t.ex. kan man säga att tjänsten SMS i en mobiltelefon är en VAS). Protokollet kom att döpas till Intelligent Terminal Transfer Protocol (ITTP). Detta protokoll skulle användas vid kommunikation mellan en server och en så kallad intelligent mobiltelefon. Lite senare kom mjukvaruföretaget Unwired Planet att introducera Handheld Device Markup Language (HDML) [HDML] tillsammans med protokollet Handheld Device Transport Protocol (HDTP) [HDTP]. Detta nya koncept baserades på HyperText Markup Language (HTML) [HTML] och HyperText Transfer Protocol (HTTP) [HTTP] men då optimerade för trådlös Internetaccess. HDML användes såsom HTML för att beskriva innehåll och gränssnitt men optimerat för liten bandbredd, liten skärm och begränsade inmatningsmöjligheter. Likaså var HDTP anpassat för att vara ett lättviktsprotokoll för transaktioner mellan klient och server. I mars 1997 offentliggjorde Nokia sitt Smart Messaging-koncept (se avsnitt 2.3.3). Att företagen kom med olika koncept/tekniker medförde en risk för fragmentering mellan de olika teknikerna. En sådan fragmentering skulle varken varit bra för utvecklare eller de involverade företagen. Detta i sin tur ledde till att företagen kom överens om att ta fram en gemensam lösning. Denna lösning kom att kallas för WAP. Den 15 september 1997 publicerades WAP-arkitekturen på WAP Forum ( som då hade skapats av Phone.com (före detta Unwired Planet), Ericsson, Nokia och Motorola. 16

28 Wap-modellen Wap-modellen liknar i mångt och mycket Internetmodellen. Det som är nytt är införandet av en WAP-Gateway/Proxy mellan klient och server (se Bild 11). WAE WTA WAP-stack Kodad förfrågan (URL) Kodat resultat (Data) Kodare och avkodare av data Förfrågan (URL) Resultat (Data) HTTPserver WAP-klient Gateway/Proxy WWW-server Bild 11 En överblick av WAP-modellen. WAP-Klient För att en enhet skall anses vara WAP-kompatibel krävs det tre delar: 1. Wireless Application Environment (WAE) Det är en programmiljö som innehåller en liten webbläsare. Denna webbläsare ska klara av att hantera Wireless Markup Language (WML), WMLScript och en viss typ av bilder. 2. Wireless Telephony Application (WTA) Det är en miljö i vilken Wireless Telephony Application Interface (WTAI) tillåter tillgång till mobiltelefonens lokala funktioner/tjänster (t.ex. tillgång till telefonboken) eller nätverkets funktionalitet (t.ex. ringa upp ett telefonnummer). 3. WAP-stack Det är WAP-stacken som med hjälp av WAP-protokollet kopplar upp sig mot en WAPgateway. Den bygger på ISO OSImodellen men den består endast av fem lager (som man kan se här till höger). WAP-Stacken Wireless Application Environment (WAE) Wireless Session Protocol (WSP) Wireless Transaction Protocol (WTP) Wireless Transport Layer Security (WTLS) Wireless Datagram Protocol (WDP) Gateway/Proxy Denna gateway, som oftast också har proxy-funktionalitet i sig, har till uppgift att översätta så att förfrågningar kan vidarebefordras till Internet samt översätta tillbaka då resultatet kommer ifrån Internet. Den har också till uppgift att komprimera informationen som skickas 17

29 till WAP-klienten. Den information som skickas till/från WAPklienten är komprimerad på ett binärformat som är speciellt anpassat/optimerat för att minimera mängden data som överförs. Internet-server En internet-server är en vanlig webbserver som tillhandahåller WAPsidor. Dessa sidor är skrivna i WML. Wireless Markup Language (WML) / WMLScript WML är det format som WAP-sidor är skrivna i. Det är baserat på extended Markup Language (XML) [XML] och har vissa inslag ifrån HTML4 [HTML4] och HDML2 [HDML2]. WML är speciellt framtaget för relativt hög latens (fördröjning) och begränsad bandbredd. En liten nackdel med WML är att det inte tillåter kontroll av vilken typ av WAP-klient som används. Dvs. man kan inte kontrollera vilka förutsättningar som gäller för den aktuella WAP-enheten. Man kan bara utgå ifrån att det finns en skärm och att den troligen är liten. WMLScript är till för att tillåta dynamisk funktionalitet i WMLsidorna på WAP-enheten. Detta för att bl.a. göra det möjligt att minimera kommunikationen till servern. Man kan t.ex. göra kontroller av inmatad information med WMLScript som därmed håller nere kommunikationen med servern. Till skillnad från skript som används i HTML ligger inte WMLScript i WML-koden utan i egna filer. Detta har bl.a. gjorts med tanke på att spara bandbredd; genom att man inte hämtar WMLScript förrän de efterfrågas kan man ytterligare hålla nere den mängd data som överförs mellan klient och server. WAP Push arkitektur Ett push-förlopp (se avsnitt 2.2) ser ut ungefär som i Bild 12. Push Klient Server (PI) Bild 12 Ett enkelt Push-förlopp. WAP-push har dock ett litet problem som gör att det ser lite annorlunda ut. Detta beror på att Push Initiator (PI), som finns på Internet, 18

30 inte delar något protokoll med WAP-klienten, som ligger i WAPdomänen. För att överbrygga detta problem introducerades en Push Proxy Gateway (PPG). Det är en slags förmedlare som översätter och vidarebefordrar informationen som skickas ifrån PI till WAP-klienten. Detta förlopp beskrivs i Bild 13. Push over-the-air Protocol Push Access Protocol WAP-Klient Push Proxy Gateway Push Initiator Bild 13 WAP-Push-arkitektur. Push Initiator (PI) En Push Initiator är den part som initierar och skickar iväg Pushmeddelandet. Det kan t.ex. vara en server på Internet som ska skicka information till en WAP-klient då en viss händelse skett. Push Proxy Gateway (PPG) En Push Proxy Gateway är den del i Push-strukturen som knyter samman WAP-domänen med Internet. Den är en slags översättare och vidarebefordrare. Den tar informationen som den fått från PI och konverterar den för vidarebefordran till WAP-klienten. Eftersom PPG är en ingång till WAP-domänen har ägaren till PPG möjlighet att sätta upp en policy för vem eller vilka som ska få tillgång till WAP-domänen. Push Access Protocol (PAP) Ett protokoll som används av en Internetbaserad PI och en PPG för att kommunicera sinsemellan. Protokollet är framtaget för att enkelt kunna tunnlas (förmedlas) över HTTP eller liknande framtida Internetprotokoll. Push over-the-air Protocol Ett protokoll som används av PPG och WAP-klienten för att kommunicera sinsemellan. Det är ett tunt lager som ligger ovanpå Wireless Session Protocol (WSP). Här uppstår dock ett problem eftersom servern inte kan skapa en WSP-session (uppkoppling), utan det måste klienten göra. Detta löses genom att på WAP-klienten införa en SIA 19

31 (Session Initiation Application) som har till uppgift att lyssna efter sessionsförfrågningar samt att svara genom att skapa en session som sedan kan användas då meddelandet sänds SIM Application Toolkit (STK) SIM Application Toolkit är en teknik som bygger på att man tillför funktionalitet via mobiltelefonens SIM-kort. Genom att föra in ett slags SmartCard i en STK-kompatibel mobiltelefon kan man få ett enhetligt beteende från olika mobiltelefoner. Detta var en av anledningarna till att STK togs fram. Företag som producerade tjänster till olika mobiltelefoner ville slippa att göra om samma tjänst för olika mobiltelefoner. STK stöds av alla stora mobiltelefontillverkare idag, vilket medför att en STK-tillämpning kan nå en stor mängd kunder. Under 1995 kom de första idéerna till STK. Dessa idéer ledde till ett dokument som Special Mobile Group 9 (SMG9) gjorde till en standard. Senare, under 1996, introducerades STK i European Telecommunications Standards Institute (ETSI) standard GSM [GSM 11.14]. Den första tjänsten som baserades på STK kom i maj Det var en mobil banktjänst tillhandahållen av Cellnet/Barclaycard som byggde på GemXplore SIM-kort. Lite senare, i september 1997, lanserade Telia/PostGirot en betaltjänst som tillät kunderna att betala sina elräkningar med hjälp av en STK-kompatibel mobiltelefon och ett GemXplore SIM-kort. [SIM] Teknik SIM Application Toolkit definierar hur SIM-kortet ska kunna kommunicera och interagera med omvärlden och utökar kommunikationsprotokollet mellan SIM-kortet och mobiltelefonen. Detta medför att SIMkortet får möjlighet till en mer aktiv roll i mobiltelefonen. Det vill säga, SIM-kortet kan kommunicera med nätverket via mobiltelefonen, SIM-kortet kan initiera kommandon på mobiltelefonen samt styra mobiltelefonens användargränssnitt (User Interface UI). Det är alltså SIM-kortet som initierar och styr all aktivering av dessa kommandon på mobiltelefonen. När man lagrar en tjänst i ett SIM-kort med hjälp av STK har mobiltelefonoperatören sedan möjlighet att förändra tjänsten. Eftersom en auktoriserad operatör har tillgång till SIM-kortet kan de ändra, ta bort, uppgradera eller rent av att lägga till nya tjänster med användarens godkännande. Dessutom kan tjänsten, som ligger på SIM-kortet, flyttas och köras i en annan STK-kompatibel mobiltelefon. 20

32 Nyckelfunktionerna i STK är: Kontroll över UI -funktionalitet Styr över gränssnittet som visas på mobiltelefonens display. Kommunikationskontroll Har t.ex. möjlighet att själv initiera telefonsamtal. SMS och datahantering Kan skicka och ta emot SMS via mobiltelefonen. Meny- och tjänstehantering Möjlighet att förändra menyer och tjänster. Tillgång till SIM-information STK har tillgång till SIM som innehåller information om ägaren. Denna information ger möjlighet till säkerhetsfunktioner och identifiering. (Lämpligt för tjänster där hög säkerhet krävs, exempelvis banktjänster). Eftersom STK har tillgång till SIM-informationen tillsammans med att säkerhetsalgoritmer kan lagras på kortet, fås en mycket god flexibilitet i säkerheten. Om säkerheten skulle behöva förändras är det bara att uppdatera algoritmen till den nivå som nu eftersträvas. Reset Clock 0 V 5 V > 10 V 1/0 I n t e r f a c e CPU or CPU + Co Pro ADDRESSES RAM ROM EEPROM DATA Bild 14 En förenklad skiss på hur ett Smartcard ser ut. Visar också schematiskt vad som finns inuti kortet. I detta kort lagras t.ex. SMS och telefonboken i EEPROM medan GSM- och generell SmartCard-information ligger lagrat i ROM. Kortet är speciellt konstruerat för GSM och innehåller t.ex. säkerhetsalgoritmer för GSM. Dessa SmartCard utvecklas hela tiden, korten blir kraftfullare och deras lagringsutrymme ökas. Detta leder till att nya typer av tjänster, kanske med nya användningsområden, kan bli tillgängliga för kunden i framtiden. 21

33 2.4 Framtida tekniker Här beskrivs några existerande tekniker som skulle passa in i detta examensarbete då de blir tillgängliga för allmänheten Enhanced Messaging Service (EMS) EMS är precis som det låter en vidareutveckling av SMS. En av anledningarna till att den togs fram var för att fylla upp tomrummet som annars skulle blivit mellan SMS och MMS (se avsnitt 2.4.2) Ericsson tog fram och visade upp EMS för standardiseringskommittéerna ETSI/3GPP. För att fortsätta utvecklingen av EMS, ställde man som krav att alla stora mobiltelefontillverkare skulle gå med på att stödja denna teknik. Alla de stora tillverkarna utom Nokia ställde sig bakom EMS. Nokias reservation berodde till stor del på att de redan hade en egen teknik som liknade EMS, nämligen SM (se avsnitt 2.3.3). Nu är EMS en öppen standard [EMS] som har blivit en del av SMSstandarden. Det som gör den väldigt intressant för bland annat mobiltelefonoperatörerna är att den fungerar i samma tekniska arkitektur som SMS. Vilket innebär att alla de SMSC som redan finns inte behöver uppgraderas för att EMS ska fungera. Detta är möjligt genom att man utnyttjar User Data Header (UDH) som skickas före själva SMS-meddelandet. I UDH kan man skicka med binärdata till ett SMS. I dessa binärdata kan då formateringsdata, bilder, ljud och animationer läggas som sedan kan tolkas och visas i mobiltelefoner som stöder EMS. Detta leder till att man kan skicka denna typ av meddelanden till mobiltelefoner som inte stöder EMS. Vad som händer då är att mobiltelefonen ignorerar de binärdata som kommer med UDH och visar bara själva texten i SMS-meddelandet. Den här typen av meddelande stödjer även kedjning (sammanfogning) dvs. upp till 255 SMS kan sammanfogas till ett stort meddelande. Detta möjliggör en meddelandestorlek upp till ca 38 KB text. Första versionen av EMS kom 1999 och kallades Release 99. Den var inte så omfattande men där fanns stöd för viss textformatering samt för väldigt enkla bilder och ljud. I juni 2001 blev version 4 färdig. Samtidigt kom man överens om vad version 5 skulle innehålla. EMS kommer, i version 5, att stödja bland annat: textformatering, bilder, ljud, förbestämda ljud, ringsignaler (imelody [IMELODY]), animationer, stora bilder (max 255*255 i svartvitt, gråskala eller färg), vcard och vcalendar samt även tillföra stöd för EMS i CBS (se avsnitt 2.3.2). 22

34 2.4.2 Multimedia Messaging Service (MMS) MMS är en ny meddelandeteknik som kommer att tillåta större meddelanden med olika typer av multimedialt innehåll. Detta gör att en helt ny teknikarkitektur kommer att behövas. MMS utnyttjar inte någon typ av kontrollkanal som SMS gör för att förmedla sina data, utan här kommer mobiltelefontrafiken samsas om bandbredden med MMS. Detta leder till att man slipper den begränsade mängd av data som kontrollkanalerna kunde skicka. Dessutom kommer överföringstiden att minska beroende på vilken bandbredd mobiltelenätet tillåter/klarar av. Även fast man har velat frångå mycket av SMS-tekniken så finns det många likheter kvar. Bland annat så är MMS och SMS båda en ickerealtidsservice. Med det menar man att man inte har direkt kommunikation mellan sändare och mottagare utan informationen skickas via en mellanhand. I MMS kallas denna mellanhand för MMS Relay, i SMS kallas den för SMSC (se avsnitt 2.3.1). En annan likhet är att MMS, precis som SMS, också innehåller leveransverifikation av meddelanden. MMS är designad för att vara så framåt-/bakåtkompatibel som möjligt. Det vill säga man kommer till skillnad mot t.ex. WAP inte att behöva en ny mobiltelefon, för varje ny protokollversion som kommer, för att dra nytta av den nya funktionaliteten. För att göra det så enkelt som möjligt har man använt sig av några av Internets standardprotokoll. Multipurpose Internet Mail Extension (MIME) används för att tala om vilka format meddelandena består av och Simple Message Transfer Protocol (SMTP) används för åtkomst/kommunikation inom det så kallade Multimedia Messaging Service Environment (MMSE). [MMS] MMSE består av: MMS Relay/Server hjärtat i MMSE som har hand om förmedlingen av meddelanden mellan MMSE-enheter. MMS Store lagrar meddelanden som inte skickas vidare direkt. MMS User Agent programmet som skapar, raderar, skickar och tar emot meddelandena. MMS User Databases lagrar profiler och information bunden till användaren. 23

35 Denna nya struktur ger många förutsättningar för ett flexibelt meddelandesystem Fler tekniker Andra tekniker som inte beskrivs men som kan komma att bli intressanta är dessa: I-mode Jämförs av många med WAP. Introducerades i Japan i början av 1999 av operatören NTT DoCoMo. Har dock inte nått så stor spridning utanför Japan. Information om I-mode kan hittas på: Mobile Station Application Execution Environment (MExE) En specifikation som togs fram av ETSI och nu handhas av 3GPP [MEXE]. Det finns ett forum där mer information kan hittas: Utvärdering Alla tekniker som har beskrivits här (en överblick finns i Tabell 1 på nästa sida) kan förmedla information till en mobiltelefon på ett eller annat sätt. Nu passar dock inte alla dessa för just det här examensarbetet. Det som är intressant här är tekniker som ger möjlighet att skicka information till specifika personer. Här passar i stort sett alla de beskrivna teknikerna in förutom CBS. Detta beror på att CBS bara tillåter att information skickas till områden istället för till individer. Däremot passar teknikerna SMS, SM, WAP, STK och även de framtida teknikerna EMS och MMS alla väldigt bra. STK kan komma att behöva ett klientprogram som ligger på själva SIM-kortet för att passa in i detta examensarbete. Detta är en liten detalj som inte borde vara något problem. Men då det inte har kunnat testas bör det ändå nämnas här. Några av dessa tekniker erbjuder en viss möjlighet till att mer eller mindre formatera informationen som skickas. Det är intressant då detta ger en möjlighet att presentera informationen på ett mer tilltalande sätt för kunden. Än så länge är det WAP som tillåter de största formateringsmöjligheterna men en liten nackdel är att WAP-sidorna tyvärr ser olika ut beroende på vilken WAP-enhet som används. Detta kan leda till problem och måste tas i beaktning när konverteringen av informationen till WAP görs. 24

36 En annan sak som gör WAP-Push väldigt intressant är möjligheten att inkludera länkar i meddelanden som skickas till kunderna. Dessa länkar kan slussa kunden vidare till olika tjänster eller till ytterligare information. Information om ett visst företag skulle kunna innehålla en länk till en tjänst där man kan köpa och sälja just det företagets aktie. Tabell 1 För- och nackdelar med de tekniker som beskrivits i denna rapport. Teknik Positivt Negativt SMS Stöds av i stort sett alla mobiltelefoner. Begränsad mängd information som kan skickas. CBS Skickar till områden istället för till personer. SM Många olika typer av meddelanden kan skickas till enheten. Stöds i stort sett bara av Nokias mobiltelefoner. WAP Ger möjlighet att formatera informationen. Större mängd information kan sändas till mobiltelefonen. Fungerar ofta olika på olika mobiltelefoner. STK EMS MMS Möjlighet till vidarelänkning till ytterligare information. Fungerar oberoende av mobiltelefon bara den är STK-kompatibel. Stödjer många olika utformningsmöjligheter och olika dataformat. Stor mängd data kan sändas. Passar in i dagens tekniska SMS-arkitektur. Ännu större mängd information kan skickas än med SMS eller EMS. Stödjer ännu fler olika dataformat. Formaterad text, ljud, bild, video mm. Användaren måste köpa ett speciellt SIM-kort för att få tillgång till tekniken. Stöds ännu inte av så många mobiltelefoner. Kräver en ny teknisk arkitektur. 25

37 3 Analys För att bygga ett program som skulle kunna förmedla information via dessa tidigare beskrivna tekniker behövdes en vettig struktur/design. Här beskrivs framtagandet av denna struktur/design. 3.1 Problem Det finns idag många metoder för att skicka information till mobiltelefoner. Dessa utvecklas kontinuerligt och nya tillkommer hela tiden. Detta leder till problem eftersom nya program måste utvecklas för varje ny teknik som ska utnyttjas. Dessa nya program måste sedan anpassas för att kunna komma företaget till nytta. Om det finns en grundstruktur som den nya tekniken kan anpassas till har man vunnit mycket. Grundproblemet för Aktiedirekt var att de hade tillgång till aktierelaterad information t.ex. nyheter, kursinformation och företagsrapporter etc. Denna information ville de snabbt kunna förmedla ut till sina kunder eftersom informationen i många fall kunde påverka kundens agerande vid t.ex. aktiehandel. Men problemet var då att kunderna hade många olika mobiltelefoner som klarade av olika tekniker. Därför ville man knyta samman de olika teknikerna i ett program där programmet kunde anpassa informationen så den passade varje kunds mobiltelefon. 3.2 Syfte Avsikten var att ta fram en teknisk lösning samt implementera den i form av ett program. Detta program skulle bilda en bas för de befintliga teknikerna samt underlätta vid införandet av nya tekniker. I och med att detta examensarbete binder samman de olika teknikerna till en enhetlig struktur, kan användandet av detta program underlätta för användaren att dra nytta av nya tekniker på ett enkelt sätt. Detta beror på att användaren lär sig att hantera ett program och därmed känner sig trygg med detta. Tryggheten till detta program gör att det blir enklare att ta till sig nya tekniker då de presenteras i en för användaren redan känd miljö. 3.3 Förutsättningar Utvecklingsarbetet styrdes delvis utifrån de förutsättningar som fanns på Aktiedirekt. 26

38 Servrar Unixdatorer med operativsystemet Sun Solaris. Arbetsstationer Pc-datorer med Windows 2000 (på denna typ av datorer skulle programmet köras). Utvecklingsmiljö Pc-datorer med Linux eller Windows (dessa datorer användes vid själva utvecklingen av programmet). Databas mysql (kördes på en av unixservrarna). Utvecklingsspråk Java (det mesta som utvecklades under tiden som detta examensarbete gjordes, skrevs i Java). För att skicka SMS och SM användes protokollet CIMD2 [CIMD2] via Europolitans servrar/mobiltelefonnät. 3.4 Krav och önskemål Krav och önskemål diskuterades fram med Aktiedirekt. Under arbetets gång utökades också kravlistan p.g.a. yttre omständigheter. Kraven och önskemålen var: Programmet skulle kunna utvidgas med nya framtida tekniker. Programmet borde kunna administreras under drift. Kunden skulle kunna välja den typ av teknik som han/hon föredrog. Programmet skulle bara skicka informationen i format som telefonen klarade av. Med det menades att om telefonen inte stödde det format som meddelandet skulle skickas i, sändes inte det meddelandet till den mottagaren. Programmet skulle kunna välja bästa möjliga teknik (bästa möjliga teknik förklaras i avsnitt 3.6.4) som telefonen stödde då kunden inte valt föredragen typ. Programmet skulle kunna hantera grupper. Programmet borde hålla ner administrationen vid tillägg av nya tekniker. All kommunikation med Europolitans servrar måste ske ifrån en och samma IP-adress (krav som uppstod senare). 27

39 3.5 Övergripande analys Grundförutsättningen var att AD hade tillgång till information som de ville dela med sig av till sina kunder. I Bild 15 ses en överblick av hur uppgiften såg ut. Informationsflöde AD Program Kund med mobiltelefon Bild 15 En överblick av flödet i grundstrukturen. Det fanns tre olika delar som skulle interagera i systemet: 1. AD som var informationsskaparen. 2. Programmet som förmedlar informationen. 3. Kundens mobiltelefon som tar emot informationen. Med utgångspunkt ifrån dessa tre delar samt de krav och önskemål som beskrevs i avsnitt 3.4 började uppbenandet av uppgiften Fas 1 Första beslutet handlade om att välja mellan ett fristående program eller en klient/server-lösning. Det visade sig att för att kunna skicka SMS så fanns ett krav från Europolitan att de skulle skickas ifrån en och samma IP-adress. Detta var en anledning till att tanken på ett fristående program mer eller mindre övergavs, till förmån för en klient/server-lösning. En annan anledning som talade emot ett fristående program var kravet på möjlighet att lägga till nya tekniker i framtiden. Detta krav innebar att det fristående programmet skulle behöva uppdateras på samtliga ställen där det användes, vilket inte var ett önskvärt scenario. Vid en klient/server-lösning återfinns detta problem också. Här kan det dock lösas genom att införa en central uppdateringsfunktion som klienterna kan koppla upp sig mot och automatiskt uppdatera sig. 28

40 Så valet föll till slut på en klient/server-lösning (se Bild 16). Informationsflöde AD Klient Server Kund med mobiltelefon Bild 16 Det nya flödet i grundstrukturen Fas 2 När grundstrukturen hade valts kunde man fokusera på varje del i denna och se vad som behövde göras. Klient Först behövdes någon typ av inmatningsdel (editor) i klienten. Därefter behövde det finnas information om de kunder som meddelandet skulle skickas till. Klientens uppgift att välja mottagare konstaterades vara lika för alla olika tekniker dvs. den delen av klienten behövde inte ändras för respektive teknik. Däremot behövde inmatningsdelen vara föränderlig. Inte bara för att olika tekniker behövde olika inmatningsmöjligheter utan också för att kunna ta del av nytillkommen tekniks nya formateringsmöjligheter i framtiden. Alltså behövde en uppdateringsfunktion av inmatningsdelen införas. Det uppstod två valmöjligheter när användaren skulle skicka iväg ett meddelande ifrån klienten: 1. Meddelandet skulle skickas till mottagaren i ett speciellt format. 2. Meddelandet skulle skickas till mottagaren i bästa möjliga format. Vad dessa två valmöjligheter innebar i slutändan samt hur bästa möjliga format definierades kommer att granskas närmare i avsnitt Servern Servern skulle ta emot en lista med mottagare tillsammans med information som sedan skulle skickas iväg. Innan informationen 29

41 kunde skickas iväg till respektive mottagare var följande delsteg tvungna att göras: Val av teknik (regler som beslutade vilken teknik som skulle väljas). Upp- respektive nerkonvertering av teknikvalet beroende på vad telefonen klarade av eller konvertering till den teknik som mottagaren hade satt som föredragen typ. När en teknik var vald behövde informationen konverteras till dess format. Meddelandet sänds. Sedan återstod kravet med att kunna lägga till nya tekniker samt funktionen som tillät att klienterna kunde uppdateras för att ta del av de nytillkomna teknikerna. 3.6 Detaljerad analys För att gå vidare behövde man gå in och undersöka de olika delmoment som skedde från att informationen matats in i klienten till det att den skickats iväg till mottagarens mobiltelefon Identifierare Varje teknik behövde vara identifierbar för att olika val skulle kunna göras. Denna identifikation kom att användas i följande fall: Val av teknik (upp-/nerkonvertering som diskuteras senare i avsnitt 3.6.4). Konvertering av själva meddelandet. Val av skickningsmodul. Tyvärr fanns här ett standardproblem och problemet handlade om kompatibilitet mellan olika mobiltelefoner eller rättare sagt brist på kompatibilitet mellan dem. Tekniker var implementerade olika, vilket gjorde att det såg annorlunda ut eller rent av inte fungerade likadant, mellan mobiltelefoner av olika märken. Exempelvis fanns det i WMLspråket, som används i WAP, flera olika taggar (ord eller teckensekvenser vilka påverkar utseendet av informationen som märkts upp i ett Markup Language-dokument) som tolkades och visades olika i olika mobiltelefoner. Detta innebar att det inte räckte med en enkel identifierare av tekniken utan man behövde även ta hänsyn till märke och modell. Sedan fanns tekniken SM som bestod av flera olika meddelandeformat (se 30

42 avsnitt 2.3.3). Detta försvårade det ytterligare. Men för att förenkla det lite så antogs två saker: 1. Teknik implementerad på olika modeller av samma märke antogs fungera likadant. 2. SM, som var framtaget av Nokia, antogs fungera lika på alla deras telefoner samt att bara Nokias telefoner stödde det. Med detta i åtanke så behövde identifieraren innehålla en kombination av vilken teknik samt vilken modell/märke det var på mobiltelefonen som används. Så t.ex. (nokia, wap), (ericsson, wap), (motorola, wap) osv. Ett specialfall uppstod då man kom till Nokias SM men givet antagande 2 var märke överflödigt och kunde bytas ut mot meddelandeformat. Detta medförde att man fick en unik identifierare av typen (ttml, sm), (dmcp, sm), osv. Om det skulle ha visat sig att tekniker fungerat lika på olika mobiltelefoner då skulle en samlingsidentifierare kunnat ha introducerats. Ett exempel kunde ha varit att använda (generic, sms) för alla SMS, något som också skulle ha hållit nere antalet olika unika kombinationer Information (meddelandedata) På klienten behövdes det en inmatningsdel. I denna skulle informationen matas in för att sedan bli själva meddelandet. Ett problem som uppkom var hur denna information skulle kunna tolkas och sammanställas för att sedan skickas iväg för vidare bearbetning. Vid själva inmatandet kunde man tänkas ha två olika typer av formateringshjälp. Antingen lät man användaren använda sig av ett formateringsspråk som infogas i samband med inmatningen eller så skapade man olika mallar som kunde väljas och sedan fyllas i av användaren. Formateringsspråk Ett slags formateringsspråk (t.ex. en enkel nedbantad html-variant) skulle ha inneburit stor frihet för användaren vad det gäller utformning. Dock hade det lett till att personen som matar in informationen skulle behövt ha kunskap om hur man kunde formatera informationen. En annan nackdel hade varit om ny teknik introducerats och därmed lett till att formateringsspråket behövt ändras. Detta hade inte bara krävt en uppdatering av formateringsspråket utan också att information om denna uppdatering skulle behövt förmedlas vidare till användarna. 31

43 Sedan fanns problemet med att identifiera olika delar av den inmatade informationen. Om man skulle skicka ett meddelande där viss typ av data krävdes hade dessa data behövt märkas ut på något vis. Ta t.ex. om man skulle skicka ett elektroniskt visitkort till en kund. För att skicka ett sådant visitkort hade systemet varit tvunget att kunna identifiera vissa specifika data som namn, telefonnummer etc. Detta för att sedan kunna konstruera och förmedla visitkortet till mobiltelefonen. Denna igenkänningsfunktion skulle sedan ha behövts fungera på många olika typer av data, som även skulle kunna komma att utvidgats i framtiden då nya tekniker blev tillgängliga. Mallsystem I ett mallsystem kan man enkelt mata in information, bara att gå igenom mallen och fylla i de fält som finns. Detta var positivt då det innebar att man fick en enhetlig utformning av meddelandena. Dock kan detta även ses som negativt då det begränsar möjligheten till utformning av informationen. Vad det gällde nytillkomna tekniker så kunde detta hanteras enkelt med en ny mall. Dock måste man lösa problemet med att distribuera ut dessa mallar till klienterna på ett smidigt sätt. Problemet med att känna igen olika typer av data försvann i och med att man använde mallar. Detta berodde på att man kunde välja, redan då man skapade mallen, vilka data som skulle finnas i respektive inmatningsfält. Detta gjorde att valet föll på mallar för att på så sätt göra det så enkelt som möjligt för användaren. Sedan innebar även valet av mallsystemet att det blev onödigt att skapa en identifieringsfunktion som skulle kunna behöva uppdateras då ny teknik blev tillgänglig Val av teknik vid skickning När meddelandena skulle skickas iväg fanns en lång lista innehållande en mängd mottagare. Vad var det som då skulle göra att en viss teknik valdes till respektive meddelande? Här fanns det flera olika faktorer som styrde själva teknikvalet: 1. När meddelandet skapades valde användaren på AD att meddelandet borde/skulle skickas i den här tekniken. 2. Mottagaren hade valt att alla meddelanden t.ex. skulle skickas i tekniken WAP. 3. Huruvida mottagarens mobiltelefon stödde den valda tekniken eller inte (behandlas också i 3.6.4). De två senare fallens val kunde göras om viss information fanns tillgänglig om respektive mottagare. Den första informationen som 32

44 behövde lagras var vilka tekniker som respektive mobiltelefon stödde. Ytterligare information som krävdes för att göra dessa val var information om mottagaren. Detta gjorde att en slags profil av varje mottagare behövde skapas. I den behövde det finnas information som t.ex. telefonnummer och vilken typ av mobiltelefon som personen hade. Eftersom det också fanns som krav att mottagaren skulle kunna välja föredragen teknik behövde även denna information finnas tillgänglig där. All denna information låg nu som underlag för serverprogrammet då den gjorde teknikvalet. Tyvärr räckte inte denna information helt för att kunna göra teknikvalet. Vad som var problemet beskrivs i nästa avsnitt Teknikvalssystem (upp-/nerkonvertering) Tyvärr fanns det fortfarande ett problem kvar som ställde till svårigheter vid teknikvalet. Problemet uppstod t.ex. då man ville skicka iväg ett meddelande i bästa möjliga teknik. Problemet var huruvida man kunde eller skulle konvertera ett meddelande till annan teknik. För att kunna angripa detta problem definierades först bästa möjliga teknik. Bästa teknik ansågs vara den teknik som tillät störst textmängd samt flest formateringsmöjligheter. Det första problemet som kunde uppstå då man konverterade mellan olika tekniker var att meddelandet förstördes formatmässigt. Ta t.ex. ett SMS. Det skulle kunna konverteras upp till WAP och konvertering från WAP ner till SMS skulle även det kunna fungera. Men konvertering från WAP till SMS skulle kunna leda till problem då WAP tillåter t.ex. bilder, tabeller och andra formateringsmöjligheter som inte SMS klarar av. Alltså kunde inte alltid informationen formatmässigt konverteras till SMS. Ett andra problem var att meddelandets syfte och information förstördes. Ett exempel var t.ex. Nokias telefoner. De tillåter att man skickar ringsignaler via SM. Detta meddelande består av ett litet huvud samt text som sedan telefonen tolkar som en ringsignal. Detta meddelande kunde konverteras till WAP men syftet med meddelandet skulle gå förlorat i konverteringen, då telefonen inte kunde tolka ringsignalen i WAP. Alltså förstörde konverteringen informationen i detta fall. För att komma till rätta med dessa problem så infördes två typer av mallar, generiska och icke-generiska mallar. En generisk mall kunde konverteras upp eller ner medan en icke-generisk mall inte kunde konverteras till en annan teknik. 33

45 Genom att införa dessa två typer av mallar kunde man på förhand se till att den generiska mallen kunde konverteras till alla befintliga tekniker. Likaså gjorde man icke-generiska mallar till alla typer av meddelanden som krävde att det skickades i ett visst format och/eller teknik. Införandet av generiska och icke generiska mallar ledde till följande: Om man skickade ett meddelande via en icke-generisk mall visste man att meddelandet skulle se ut eller fungera på ett speciellt sätt, medan om tekniken inte stöddes av mobiltelefonen skulle meddelandet inte skickas. Skickades ett meddelande via en generisk mall visste man inte vilken teknik som kom att användas men däremot visste man att ett meddelande skickats (detta beror på ett antagande om att alla telefoner klarar av SMS) Konverteringssystem (språk) Meddelanden som skickades behövde konverteras till respektive tekniks format. Mall och unik identifierare skulle på något sätt producera ett formaterat meddelande som sedan skickades iväg. Här råkade det redan finnas en lösning på AD som kallades för Rendreraren. Rendreraren var ett system utvecklat för att konvertera informationsobjekt plus en identifierare till ett färdigformaterat meddelande. Rendreraren Rendreraren var ett program som byggde på en parser och en databas med en slags objektmallar. Programmet anropades med ett informationsobjekt (javaobjekt i detta fall) samt en unik identifierare som användes för att slå upp vilken objektmall som skulle användas på informationsobjekt. Därefter gick parsern igenom objektmallen som innehöll information om hur informationen skulle presenteras och formateras. I denna objektmall fanns även funktionsanrop som vid parsning utfördes på det medföljande objektet. Funktionsanropens resultat infogades sedan i objektsmallen. Då parsern var färdig hade man ett färdigkonverterat meddelande vilket returnerades. 34

46 3.6.6 Skickningssystem Detta system byggdes upp av små insticksmoduler (plugins) för varje teknik. De krav som fanns var att man skulle kunna: Lägga till ny skickningsteknik utan att ändra i skickningssystemet. Inte behöva starta om servern för att den nya skickningstekniken skulle kunna tas i drift. Första kravet kunde lösas genom att man skapade ett skickningssystem som kontrollerade vilka skickningsmoduler som fanns tillgängliga och därefter laddade dem. Det andra kunde man lösa genom att detta skickningssystem även tillhandahöll ett administrationsgränssnitt som tillät omladdning av dessa skickningsmoduler under drift. 35

47 4 Design Vid designen av klient och till viss del av servern fanns det inga egentliga riktlinjer ifrån Aktiedirekt. Detta ledde till att designen växte fram efter de behov som uppkom under arbetets gång. Det första beslutet som togs vad det gällde klient/server-designen var att lägga logiken i servern. Klienten skulle ta hand om inmatningsdelen och val av mottagare för att sedan förmedla det till servern som skulle ta hand om resten. En av anledningarna till detta var att det fanns tankar på att bygga andra tillämpningar som också skulle använda servern. För att slippa bygga in logik i varje klient (som skulle kunna komma att utnyttja servern) så lades logiken istället i servern. 4.1 Server För att ta fram en design av servern för att skicka iväg information till mottagarna så följdes skissen i Bild 17. Ta e m o t e t t m e d d e l a n d e o c h e n l i s t a m e d m o t t a g a re if rå n k l ie n t e n V a l a v s k ic k n i n g s t y p f ö r re s p e k t i v e m o t t a g a re K o n v e rt e ri n g a v m e d d e l a n d e t t i l l re s p e k t i v e s k i c k n in g s t y p Sk ic k a m e d d e l a n d e t t i ll re s p e k t i v e m o t t a g a re Sa m l a i h o p s t a t u s f ö r v a rj e s k ic k a t m e d d e l a n d e o c h re t u rn e ra t il l k li e n t e n Bild 17 Skiss över det förlopp som behövs gås igenom då ett meddelande ska skickas till ett antal mottagare. 36

48 Skissen av förloppet i Bild 17 samt den tidigare analysen ledde fram till den design av servern, som visas i Bild 18. M a ll - l a d d a re Da t a b a s - k o m m u n i k a t i o n Kl i e nt M e s s a ge C e nte r (Se rv e rn) Ko n v e rt e rin g s - a d m i n i s t ra t ö r M e d d e l a n d e - k o n v e rt e ra re Sk ic k n in g s - m o d u l M o d u l - l a d d a re Bild 18 Överblick av designen av servern. Vid framtagningen av denna design fanns det en avsikt att hålla isär de olika modulerna. Detta för att man enkelt skulle kunna förstå vad respektive modul hade för uppgift, vilket senare skulle förenkla vid förändringar och uppgraderingar. De olika modulerna som ses i Bild 18 är rätt så självförklarande. Mall-laddare Laddar de mallar som finns tillgängliga. Databaskommunikation Sköter all kommunikation med databasen. Konverteringsadministratör Sköter upp- och nerkonverteringen av meddelandetypen. Meddelandekonverterare Hanterar konverteringen av meddelandet till respektive språk. Skickningsmodul Sköter kontrollen av de insticksmoduler (plugins) som finns tillgängliga. Modul-laddare Laddar de insticksmoduler som finns tillgängliga. En del som var lite speciell var insticksmoduldesignen. Här ville man kunna lägga till moduler som skickningsmodulen skulle kunna hitta och använda utan att förändra något i koden. Detta ledde fram till följande idé: I Java finns det möjlighet att instansiera klasser under programkörning. Genom att ge varje insticksmodul möjlighet att tala 37

49 om vilken skickningstyp som den kan hantera kan man bygga upp en lista av tillgängliga skickningstyper i skickningsmodulen. Därmed var det bara att ladda alla tillgängliga moduler och instansiera dem enligt Bild 19. Leta upp alla insticksmodulklasser i en speciell katalog Instansiera och fråga respektive insticksmodul om dess skickningstyp Varje instansierad insticksmodul läggs i en hashtabell nycklad på dess skickningstyp Bild 19 Visar hanteringen av insticksmoduler. I och med detta förfarande kunde en hashtabell byggas upp nycklad på respektive insticksmoduls skickningstyp. Denna hashtabell kunde sedan användas för att hämta rätt insticksmodul, som sedan kunde användas till att skicka iväg meddelandet med. 4.2 Klient Klientens gränssnitt växte fram ur de behov som uppstod under utvecklingen av programmet. Detta gränssnitt som växt fram skulle sedan kunna testas på lämpliga användare. Tyvärr blev detta inte fallet eftersom Aktiedirekt blev uppköpta. Därmed lades all programutveckling ner direkt. Från början fanns det fyra delar som styrde designen av klientprogrammets användargränssnitt: 1. Val av mottagare. 2. Lista på valda mottagare. 3. Val av mall. 4. Själva meddelandemallen (inmatningseditorn). 38

50 Hur dessa fyra olika delar skulle interagera ihop styrdes först av ordningen man kunde utföra de olika momenten. Det fanns två olika sätt att gå till väga för att skapa och skicka iväg ett meddelande (se Bild 20). Val av mall Val av mottagare Skicka meddelandet Presentera resultat Val av mottagare Val av mall Skicka meddelandet Presentera resultat Bild 20 De två olika tillvägagångssätten för att skapa och skicka ett meddelande. Ordningen av valet av mall och val av mottagare spelade ingen roll. Detta gjorde att visning av mallar och listor med mottagare inte behövde vara synliga samtidigt. Dock när man väl valt mottagare så skulle det tydligt framgå vilka mottagare som valts samt även finnas möjlighet till att förändra val i efterhand. Detta ledde till att listan på valda mottagare placerades till vänster i klienten samt att den skulle vara synlig hela tiden. Knappar för att administrera mottagare lades under listan och en ram placerades runt knappar och lista för att tydliggöra att de hörde ihop. Till höger placerades mallarna och listorna med mottagare i två olika lager. Detta för att de som sagt inte behövde visas samtidigt (se avsnitt 5.3 för klientens utseende). För att kunna skicka iväg ett meddelande så krävdes det att minst en mottagare var vald samt att mallen var korrekt ifylld. Detta ledde till införandet av en kontrollfunktion i varje mall. Klienten kunde fråga varje mall om den var korrekt ifylld och därigenom styra om sendknappen skulle vara aktiv eller inaktiv. På liknande sätt styrdes alla andra knappar. Om knappen kunde användas var den aktiverad och tvärt om (se exempelvis Bild 21 på sidan 44). I mottagardelen skulle man kunna presentera både grupper och personer. För att tydliggöra grupper i klientens användargränssnitt användes mappar (se Bild 26 på sidan 47). Dessa mappar kunde öppnas och stängas för att antingen visa eller dölja vilka personer som ingick i respektive grupp. Denna typ av lista infördes även i den del av klienten som hanterade vilka mottagare som valts. Detta för att på samma sätt presentera de personer eller grupper som användaren valt att skicka meddelandet till. Införandet av grupper ledde dock till ett litet problem. Problemet uppstod när man skulle skicka iväg ett meddelande till två eller flera grupper. Om då grupperna innehöll dubbletter skulle det se ut som 39

51 samma person fått meddelandet flera gånger. För att undvika detta så visades efter meddelandena hade sänts inga grupper utan bara en lista med alla personer. I denna lista infördes också symboler för att förtydliga om meddelanden skickats eller inte till respektive mottagare (se Bild 28 på sidan 48). En grön bock framför mottagaren symboliserade att ett meddelande hade skickats medan ett rött kryss talade om att inget meddelande skickats. Framtagning och design av meddelandemallarna kunde göras fristående ifrån själva klienten. Eftersom lösningen tillät att förändring och nya mallar på ett enkelt sätt kunde infogas i klienten togs bara ett fåtal mallar fram (några av dessa mallar kan ses i avsnitt 5.3). Designen av dessa mallar gjordes så enkel och tydlig som möjligt men det fanns inga hinder att skapa mer komplexa mallar. Mallar med inbyggd hjälp och felkontroll hade varit fullt möjligt att införa. Ett exempel på inbyggd hjälp är räkningen av inmatade tecken i mallen för SMS (se Bild 21 eller Bild 22 på sidan 44). Ett ytterligare problem som framkom under designen var bristen av utrymme för att presentera information om t.ex. en person eller ett moment som genomförts i klienten. Detta ledde till införandet av en informationsruta (se uppe till vänster i exempelvis Bild 26 på sidan 47). Denna informationsruta användes bl.a. till att presentera ytterligare information om valda (markerade i någon lista) personer. Informationsrutan utnyttjades även till att förmedla information till användaren om olika skeenden/händelser i klienten. 40

52 5 Implementation Systemet består av en server, MessageCenter, som MessageCenter- Client kan koppla upp sig mot. På servern ligger moduler, mallar och mottagarinformation. Send-modul (insticksmodul) Varje send-modul tar hand om en viss skickningstyp, t.ex. SMS. Skickningssystemet går igenom de insticksmoduler som finns tillgängliga vid start och skapar en lista på de tekniker som respektive send-modul kan skicka. När sedan meddelandena kommer tillsammans med teknikval slussas de vidare till respektive send-modul. Det är dessa moduler som sköter ivägskickandet av meddelandena till mottagarna. Mall (Template) Mallarna är små editor-komponenter som klienten laddar ned ifrån servern. Dessa små editorer är speciellt anpassade för respektive meddelandetyp som de är skapta för. Mottagarinformation Mottagarinformationen innefattar information om mottagare (kunderna) såsom namn, telefonnummer, telefontyp m.m. Denna information lagrades på en server i en mysql-databas kallad mesgen. Nätverkskommunikation Kommunikation mellan klient och server görs med Remote Method Invocation (RMI) [RMI]. Servern tillhandahåller en mängd funktioner som klienten kan utnyttja via RMI. Detta användes bl.a. för att lösa problemet med uppdatering av mallarna. Klienten kan härigenom koppla upp sig mot servern och hämta mallarna (via en filserver). När hämtningen väl är genomförd skapas mallarna och integreras i klienten. 5.1 Problem och lösningar Under arbetets gång uppkom problem och det fanns även vissa krav ifrån Aktiedirekt. Här beskrivs några större problem och hur dessa löstes. Nedladdningsbara mallar Problem: Som tidigare nämnts i rapporten fanns det ett behov av att lätt kunna uppdatera, förändra och lägga till mallar. Detta skulle också ske utan någon förändring av klienten. 41

53 Lösningen: Dessa behov är i grund och botten ett distributionsproblem. Detta löstes genom att använda RMI (Remote Method Invocation) [RMI]. Genom RMI kan ett antal funktioner tillhandahållas av servern som klienten kan utnyttja. Via dessa funktioner kunde klienten ladda ner de nya mallarna över nätet och sedan tillät språket Java att dessa mallar kunde instansieras och infogas i klienten. Tänkbar vidareutveckling: Detta är en väldigt intressant lösning, då man i en utvecklad version skulle kunna låta hela programmet (istället för bara mallarna) laddas ner över nätet. Härmed skulle man kunna erbjuda ett dynamiskt programutbud till användarna. Programmen skapas och läggs på serven som via en minimal klient visar vilka program som finns tillgängliga. Därefter väljer användaren ett program som laddas ner och sedan startas. Automatigenkänning av send-moduler Problem: Servern var tvungen att hitta nya send-moduler. Lösning: Detta problem löstes genom att låta alla send-modulers filnamn sluta på Plugin.class samt lägga dessa i en speciell katalog. Detta gjorde att man enkelt kunde hitta alla send-moduler som fanns tillgängliga. Tänkbar vidareutveckling: Detta borde utvecklas mer för att säkerställa att det verkligen är send-moduler som finns i den katalogen. En utförligare kontroll av respektive fil skulle vara önskvärd. Exempelvis skulle man kunna utföra objektstest för att säkerställa att filen överensstämmer med vad en send-modul ska klara av. Insticksfunktionen Problem: I och med att send-moduler hittas vill man kunna utnyttja dem utan att förändra/uppdatera koden i själva servern. Lösning: Denna lösning bygger på att varje send-modul (insticksmodul) vet vad den klarar av och även kan tala om det för servern. Alltså innehåller varje send-modul en funktion som identifierar sendmodulen samt tillhandahåller information om vad för typ av meddelande som den kan hantera (skicka iväg). Vid programstart kontrollerar servern vilka send-moduler som finns tillgängliga och bygger upp en tabell (genom att fråga respektive send-modul om vad de kan hantera) som servern sedan använder i drift. 42

54 Admin-gränssnitt Problem: Vid uppdatering av mallar och send-moduler vill man slippa att starta om servern för att få dessa tillgängliga. Lösning: Detta löstes genom att införa ett slags admingränssnitt som tillhandahåller funktioner för omladdning av mallar och sendmoduler. Efter att man lagt till en mall eller en send-modul meddelar man till servern via admingränssnittet att ladda om mallar och send-moduler. Tänkbar vidareutveckling: Detta gränssnitt skulle kunna utökas till att även hantera loggningsfunktioner. Under drift skulle man kunna använda gränssnittet för att slå på/av loggar och liknande. Rangsystemet av teknikerna Problem: När man vill skicka ett meddelande i bästa möjliga teknik uppstår problem vid upp-/nerkonvertering. Lösning: Genom att införa ett rangsystem där varje teknik tilldelas ett rangnummer, beroende på hur avancerad tekniken är, kan man sedan växla upp/ner tills man hittar en teknik som telefonen klarar av. Tänkbar vidareutveckling: Detta system skulle kunna behöva ett komplexare rangordningssystem, där man mer exakt kan styra hur olika meddelanden kan/får konverteras. 5.2 Startförlopp Detta sker när server respektive klient startas: Servern: 1. Filserver startas (används för att ladda klasser via RMI till klienten). 2. Information om kunderna (userinformation) laddas. 3. De send-moduler (insticksmoduler) som finns tillgängliga laddas. 4. De mallar (templates) som finns tillgängliga laddas. Klienten: 1. Kopplar upp sig mot servern. 2. Initierar GUI. 3. Hämtar kundinformationen (userinformation) från servern. 4. Hämtar mallarna (templates) från servern. 43

55 5.3 Klienten När klienten startats (se Bild 21) finns till höger den aktuella mallen (template), till vänster en informationsruta och nedanför den en mottagaradministrationsruta (recipient administration) 2. Bild 21 Klientens startbild. Från första bilden kan man välja två vägar för att skicka iväg ett meddelande. Antingen väljer man att lägga till mottagare först och sedan skriva meddelandet eller tvärt om. I Bild 22 har man valt att börja skriva meddelandet. Bild 22 Mallen simplesms sms ifylld. 2 Klienten består av olika lager som är gömda för användare. När en förändring av klienten görs byts alltså dessa lager, dvs. alla bilder som visas här är samma fönster hela tiden. 44

56 I Bild 23 ser man vilka olika mallar som finns tillgängliga. Dessa mallar har laddats ner dynamiskt ifrån servern. Bild 23 Valbara mallar nedladdade ifrån servern. När en ny mall väljs byts den högra delen ut i klienten mot den nya valda mallen. I Bild 24 syns hur mallen generic: vcard - sm valts. Bild 24 Mallen generic: vcard sm vald. 45

57 När rätt mall är vald fyller man i mallens fält (i Bild 25 är det mallen vcard som är vald och där behövs namn, telefonnummer och e-postadress matas in). Bild 25 Mallen generic: vcard sm ifylld och redo för att skickas iväg till en eller flera mottagare. Efter att mallen är färdigt ifylld behöver man lägga till minst en mottagare för att sedan kunna skicka iväg meddelandet. I nedre vänstra hörnet i Bild 25 finns knappen Add. Denna knapp byter ut malldelen mot en person- och grupplista (se Bild 26). 46

58 Grupper och personer markeras och läggs till mottagarlistan genom att klicka på knappen Apply (längst ner till höger i Bild 26). När alla mottagare är adderade trycker man på knappen Done. Bild 26 Listor med mottagare och grupper av mottagare. Vid markering av person eller grupp presenteras ytterligare information om det valda objektet uppe till vänster i informationspanelen (se Bild 26). 47

59 I Bild 27 är meddelandet ifyllt och mottagare valda. Detta innebär att knappen Send (längst ner till vänster i Bild 27) blir klickbar. Bild 27 Ett meddelande redo för att skickas iväg. När meddelandet skickats iväg verifieras det i informationsrutan samt med en liten grön bock vid respektive namn (se Bild 28). Bild 28 Meddelandet ivägskickat till alla mottagare. 48

60 Meddelanden som skickats iväg kan undersökas lite närmare genom att de markeras i mottagarlistan. Detta gör att ytterligare information visas i informationsrutan (se uppe till vänster i Bild 29). Om problem uppstår vid skickning visas det med ett rött kryss till vänster om namnet istället för den gröna bocken och vid markering visas även ett kortare felmeddelande i informationsrutan. Bild 29 Informationspanelen upp till vänster visar ytterligare information om markerad mottagare. 49

61 Klienten har också en uppdateringsfunktion (är synlig uppe till vänster i Bild 30). Med hjälp av denna kopplar klienten upp sig emot servern och hämtar ner de mallar som finns tillgängliga samt uppdaterar grupper och mottagare. Bild 30 Menyalternativ för att uppdatera mallar och mottagarlistor. 5.4 Granskning Som med alla program så finns det alltid förändringar som man kommer på i efterhand. Eftersom testmöjligheten försvann, kunde tester under normala förhållanden inte göras. En genomgång av klienten gjordes dock i efterhand (enligt utvärderingsmetoden Cognitive Walkthrough [CW]) de oklarheter/brister som upptäcktes var: 1. Oklarhet: Vid val av mall så är det inte uppenbart vad generiska mallar innebär. Förändring: Otydligheten med generiska och icke generiska mallar skulle kunna lösas genom att införa en valmöjlighet i varje mall (t.ex. en liten kryssruta). Denna valmöjlighet borde sedan döpas om till t.ex. bästa möjliga format. Detta innebär att de mallar som är generiska har detta alternativ så att användaren kan välja om meddelandet ska skickas i bästa möjliga format eller inte. De mallar som inte är generiska har inte denna valmöjlighet. 2. Oklarhet:Vid tillägg av mottagare är knapparna Done, Cancel och Apply otydliga beträffande sin funktion (se Bild 26). 50

62 Förändring: För att förtydliga detta skulle man kunna ta bort en knapp och döpa de återstående till Add och Done. Där Add lägger till de markerade personerna/grupperna till mottagarlistan och Done stänger adderingssidan. 3. Brist: Alla listor osorterade. Förändring: Sortera grupp- och personlistorna samt sortera mottagarlistan med grupper först och sedan personer. När meddelandet skickats, ska även statuslistan vara sorterad. 4. Brist: Uppföljningsmöjlighet då misslyckade skickningar uppstår. Förändring: Detta skulle kunna lösas genom att låta förändra knapptexten Send (då misslyckade skickningar uppstått) till Resend failed ones. När man klickar på den så skickas meddelandet igen till de personer som av någon anledning inte fick meddelandet första gången. 5. Brist: En trolig brist som inte kunde kontrolleras under realistiska förhållanden var utskick till stora grupper. Här skulle troligen klienten låsa sig under själva skickandet (d.v.s. om det stora utskicket tar lång tid) för att sedan vakna när resultatet av skickningen är klar. Förändring: Detta skulle kunna avhjälpas med ett slags kösystem mellan klient och server som vid skickning tar hand om och administrerar själva skickningen. Därigenom undviker man att klienten fryser under tiden som skickningen utförs. När sedan skickningen är klar rapporterar kösystemet tillbaka till klienten och klienten kan visa resultatet. Dessa detaljer skulle kunna förbättra förståelsen och funktionaliteten för användarna. Dessutom finns det några andra lite mindre saker som skulle underlätta användandet: Ta bort telefonnummer i grupp- och personlistorna (se Bild 26) och bara visa efternamn, förnamn. Telefonnumret och annan information visas i informationsrutan då personens namn markeras i listan. En startmall (default-template) som beskriver de steg som behövs göras för att sända ett meddelande till ett antal mottagare. Denna informations-template visas när klienten startas. Lägga till draglister för att kunna förstora och/eller förminska mottagardelen/malldelen. 51

63 Eventuellt införa en Hjälp/FAQ som laddas ner ifrån servern och visas i ett separat fönster i klienten. Eventuellt införa en informationsruta i varje mall som talar om vad just denna mall är till för och hur den fungerar. På serversidan fanns det också detaljer som skulle vara lämpliga att förändra för att förenkla vid t.ex. införandet av nya tekniker: Med tanke på alla de nya teknikerna som kommer är det fördelaktigt att införa en generellare identifikator (se avsnitt 3.6.1). En utvidgning av upp- och nerkonverteringsmodulen där man mera exakt kan styra över konverteringen. 52

64 6 Slutsatser Under tiden som detta examensarbete skulle avslutas blev Aktiedirekt uppköpta av en annan Internetmäklare. Detta ledde till att all programutveckling lades ner och därmed kunde inte programmet färdigställas helt. Det som skulle behövt göras var att drifttesta systemet utförligare samt låta klienten genomgå några användartester. En slutsats man kan dra är att det är svårt att förutse brister vid design och konstruktion vilket också styrks vid granskningen (se avsnitt 5.4) som gjordes i efterhand. Tanken att centralt lagra mallar för att sedan kunna distribuera ut dem via RMI är helt klart en intressant lösning. En vidareutveckling av denna lösning är också väldigt intressant. Det är fullt möjligt att låta servern tillhandahålla en mängd program som en generell klient skulle kunna ladda ner via RMI och sedan köra. Detta skulle leda till en enkel administration vid uppgradering/förändring av program samt även ge en bra kontroll över de program som tillhandahålls. Andra utvecklingsmöjligheter skulle kunna vara: WAP-Push som ger möjlighet till vidarelänkning vilket är intressant då det leder till nya möjligheter av tjänster som man skulle kunna dra nytta av i kombination med detta program. En slags trigger -modul som skulle kunna vara konfigurerbar på en mängd olika typer av regler. När sedan ett villkor blir uppfyllt skickas denna information till kunden med hjälp av detta program. Att lägga till andra befintliga tekniker idag som inte nödvändigtvis är bundna till mobiltelefoner. En uppenbar teknik är E-post som lätt skulle smälta in i denna struktur. En positiv effekt som redan beskrivits tidigare är att detta program hjälper informationsförmedlaren (Aktiedirekt) att sända information till sina kunder. Men en ytterligare bonus är att programmet kan introducera nya tekniker i en miljö som användaren redan är bekant och känner sig trygg i. Detta är en effekt som är klart värd att nämnas. Som med alla program som skapas så finns det förändringar som skulle förbättra programmet ytterligare. Men grundtanken är dock sund och kan definitivt utnyttjas på ett bra och smidigt sätt för att snabbt sprida information till kunder via olika tekniker. 53

65 Referenser [CIMD2] Computer Interface to Message Distribution User s Guide Källa: Nokia Mobile Phones Ltd. Kontrollerad: [CW] Human-Computer Interaction (1993). Sid Utgivare: Prentice Hall Författare: Alan Dix, Janet Finlay, Gregory Abowd, Russell Beale ISBN: [EMS] Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Technical realization of the Short Message Service (SMS) (3GPP TS version Release 4) ETSI TS V4.4.0 ( ) Kontrollerad: [GSM 03.40] Digital cellular telecommunication system (Phase 2+); Technical realization of the Short Message Service (SMS) Point to Point (PP) ETSI TS V7.4.0 ( ) Kontrollerad: [GSM 03.41] Digital cellular telecommunications system (Phase 2+); Technical realization of Cell Broadcast Service (CBS) ETSI TS V7.3.0 ( ) Kontrollerad: [GSM 11.14] Digital cellular telecommunications system (Phase 2+) (GSM); Specification of the SIM Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface (GSM version Release 1998) ETSI TS V7.3.1 ( ) Kontrollerad:

66 [GSM History] Mobile Telephone History Källa: Tom Farley Kontrollerad: [GSM HKP] The cellular concept Källa: Henrik Kaare Poulsen Kontrollerad: [GSM JGS] An overview of the GSM system Källa: Javier Gozálvez Sempere Kontrollerad: [GSMWorld] SMS (Short Message Service) Källa: GSM Association Kontrollerad: [HDML] Handheld Device Markup Language Specification Källa: World Wide Web Consortium (W3C) ( Kontrollerad: [HDML2] Handheld Device Markup Language Reference Källa: Unwired Planet, Incorporated Kontrollerad: [HDTP] Handheld Device Transport Protocol Källa: Unwired Planet, Incorporated Kontrollerad:

67 [HTML] HyperText Markup Language Källa: World Wide Web Consortium (W3C) ( Kontrollerad: [HTML4] HTML 4.01 Specification - W3C Recommendation 24 December 1999 Källa: World Wide Web Consortium (W3C) ( Kontrollerad: [HTTP] Hypertext Transfer Protocol Källa: World Wide Web Consortium (W3C) ( Kontrollerad: [IMELODY] Specification for Ir Mobile Communications (IrMC) Infrared Data Association (IrDa) zip Kontrollerad: [MEXE] Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Mobile Execution Environment (MExE); Functional description; Stage 2 (3GPP TS version Release 4) ETSI TS V4.2.0 ( ) Kontrollerad: [MMS] Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Multimedia Messaging Service (MMS); Functional description; Stage 2 (3GPP TS version Release 4) ETSI TS V4.4.0 ( ) Kontrollerad:

68 [Phases] GSM Phase Implementation Källa: CellularOnline (Apr 2001) Kontrollerad: [RMI] Java Remote Method Invocation - Distributed Computing For Java Källa: Sun Microsystems, Inc. Kontrollerad: [SIM] SIM-Toolkit (28 Feb 2001) Källa: CellularOnline Kontrollerad: [SM] Introduction to Smart Messaging Källa: Nokia Mobile Phones Ltd. Kontrollerad: [SM 2_0_0] Smart Messaging Specification Revision Källa: Nokia Mobile Phones Ltd. [SM 3_0_0] Smart Messaging Specification Revision Källa: Nokia Mobile Phones Ltd. [vcalendar] vcalendar, The Electronic Calendaring and Scheduling Exchange Format, Version 1.0, a Versit Consortium specification (18 Sep 1996). Kontrollerad: [vcard] vcard, The Electronic Business Card. Version 2.1, a Versit Consortium specification (18 Sep 1996). Kontrollerad:

69 [WAP Pro] Professional WAP (Okt 2000) Utgivare: Wrox Press Författare: Charles Arehart, Nirmal Chidambaram, m.fl. ISBN: [XML] Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation 6 October 2000 Källa: World Wide Web Consortium (W3C) ( Kontrollerad: