Transcription
1Message-On-Demand Service in a DecentralizedUnified Messaging SystemPrem Prakash Jayaraman, Paul Hii, and Arkady ZaslavskyAbstract— Variety of service integration concepts haveemerged during the last few years. Most of these aim at theconcept of integrating telecommunication and the datacommunication technologies. One form of such a system isUnified Messaging. Unified Messaging enables users to managetheir messages independent of location, communication deviceor communication medium. Most of the existing systems providecentralized message-store based access to messages but lackservices like user personalization, message notification and arenon-pervasive. In this paper, we define UMS as a user-centricsystem that provides messaging services based on user demandsand preferences. We have proposed a decentralized UnifiedMessaging System (DUMS) that is pervasive and context-aware.Based on our proposed architecture, we successfullyimplemented and demonstrated a messaging system called iUMS that ensures a user receives almost instantly all messagessuch as emails, instant messages and so on in an intelligent andmost appropriate manner.Index Terms— UMS, Service Adaptation, Pervasive, ServicePersonalization, UbiquitousI. INTRODUCTIONThe Internet has now become the universal mode ofcommunication letting users to communicate with each otherby a number of means like email, IM, Voice over InternetProtocol (VoIP), etc. This development has led to theconvergence of geographically separated users. Number ofmessaging technologies and services has evolved during thepast few decades with the advent of new communicationtechnologies and devices. These messaging systems work incommon to deliver messages to the user, but differ in theirarchitectures and message formats. The systems use differentcommunication medium to deliver messages and users’ usedifferent end-terminals to receive messages. E.g. SMS is sentand received over GSM network while email is sent andreceived over a transmission control protocol (TCP). Thisdiversity in the various messaging systems has left end userswith a plethora of messaging services each of which providesPrem Prakash Jayaraman is a Research Student with Monash University,Melbourne, Australia 3145 (corresponding author phone: 61-3-9903-1151,email: prem.jayaraman@infotech.monash.edu.au)Paul Hii is a Research Student with Monash University, Melbourne, Australia3145 (email: paul.hii@infotech.monash.edu.au)Arkady Zaslavsky is an Associate Professor with School of Computer Sci &Software Eng, Monash University, Melbourne, Australia 3145 vices in a different format. Also users making use of thesemessaging services have to consider the recipients’ locationand end-device to obtain prompt reply from the messagerecipients [Wj04].This approach is unsatisfactory. Hence, thisled to the investigation of a message unification service thatenables end-users to send and receive messages irrespective ofthe messaging system format and architecture. UnifiedMessaging (UM), which is a widely accepted service, aims atthis goal of integrating various messages irrespective of theirarchitecture. Unified Messaging can be defined as a systemthat enables transfer of messages independent of theunderlying message architecture, communication mediumand devices. Any form of messages such as email, SMS, fax,voicemail, etc. can be delivered via any communicationmedium [As99]. The UM can be a powerful means ofcommunication as it seamlessly integrates variouscommunication technologies hence, giving the user theflexibility to receive and send any message, anytime andanywhere [Vs00][As99].UM incorporates services that convert messages like email,fax, voicemail, SMS from one format to another format. Mostof the UMs perform this process of message conversionwithout taking into consideration the user’s preferences. Thegoal of UM is to deliver messaging services to the user’s inthe most appropriate method. Current UMs does not entirelyfulfill the goals of the unified messaging. Hence messageconversion is no longer the primary goal of a UM. The systemmust be able to adapt itself into the user’s environment. Itneeds to take in account user’s context [Dc02], user’s endterminals and user’s working environment. This is anintelligent approach that creates the foundation in developinga Unified Messaging System (UMS) that adapts itself basedon user’s location and user preferences hence enabling theMessaging-On-Demand service. The Message-On-Demand inthis context can be defined as a service that provides userswith messages on demand based on user’s preferences, user’scontext and user’s personalized service preferences. The aimof the user in such an environment is no longer to haveubiquitous access [Vs00] to messages instead personalizationof the messaging services based on user’s messagingdemands. Since the system needs to be context-aware andterminal-aware, the environment in which the devices workcan be described as a virtual personal area network (VPAN),
2where the devices function to deliver the best possible serviceto the user in a timely and most appropriate manner possible.The devices in the VPAN have enough intelligence built intothem to coordinated and exchange information with its peers(others devices that provide messaging services).The VPAN as depicted in figure 1 is a virtual environmentand is a vision of the future. Devices in the VPAN areintelligent devices that have enough knowledge about theuser’s location and the capabilities of the other devicesworking within the environment. To implement a MessageOn-Demand service in a UMS, the UMS need to be contextaware, terminal-aware and must be able to adapt itself basedon user’s personalization. Such a system working within aVPAN delivering messaging service to the user based on userdemands is more realizable using a decentralized design. Thedevices constituting the VPAN depicted in figure 1 aredecentralized which have enough intelligence to respond touser’s location. This paper discusses one such decentralizedarchitecture of a UMS that provides Messaging-On-Demandservices to the user. The decentralized UMS is a pervasive[Rg00] system.message to another message format as in the traditionaluniversal mailbox systems. The decentralized UMS functionsin the VPAN in which the user is the primary objective of thesystem. Section 2 discusses some of the existing UnifiedMessaging solutions and how they differ from the systembeing proposed in this paper. Section 3 proposes thearchitecture of a decentralized UMS. It then proposes i-UMS,a decentralized UMS that has been prototyped as a proof ofconcept system. The i-UMS system uses wired technologies,GSM, GPRS, 802.1X wireless technologies includingBluetooth for communication between user devices formessage transfer. Section 5 discusses the results obtainedfrom the implementation.II. UNIFIED MESSAGING SYSTEMS – AN OVERVIEWThere are a number of commercial Unified Messagingsolutions that try to satisfy the goals of the unified system.Current systems depend on a gateway for message deliverywhich is an obvious approach for most of the UMS. Thesesystems try to unify messages at a single end point messagestore by collecting messages from different message stores.The system aim at providing message delivery to the userswithout taking into considerations the users need. In such asystem the user has minimum capability to define his reachability from message senders. Figure 2 depicts a UnifiedMessaging solution provided by Eicon. Some of the othercommercial UM that are available are: Nortel CallPilot[No05] [Lh03], Cisco Unity [Cu04], Global Com’s Internetbased UMS [Db02] and AVST Call Xpress [Av04].Figure 1: VPAN with user devices delivering message services to the userService adaptation and service personalization is one of thekey factors of the modern systems, to implement a MessageOn-demand service. With the evolution of pervasivecomputing, users have started to feel the need of serviceadaptation and personalization in their participatingenvironment.This paper presents an overview of the challenges involvedin designing a decentralized UMS. A decentralized UMS triesto provide service personalization to the end user henceenabling message notification based on user demands. Thesystem is also location and terminal aware hence, tries toprovide the messaging services to the user in the mostpersonalized manner taking into consideration the user’scontext, location and the end terminal which the user uses tohandle the messages. The decentralized UMS also tries toovercome the challenge of delivering messages to the user ina most appropriate manner rather then just converting oneFigure 2: Eicon Diva Server [Dh03]The basic requirement to achieve for servicepersonalization and service adaptation is the ability to beaware of the user’s environment. This primary function ofbeing context-aware and pervasive is absent in the currentUMs. The current systems also have the ability to convertmessages from one form to another but they do not provideany service adaptation based on the user demands. E.g.conversion of an incoming SMS into an email and storing itin the central message store for retrieval. This exampleprovides message conversion but does not take intoconsideration the user’s context before converting themessage into the most appropriate form. This is the same in
3How long does the message needs to be storedIs message Uni or Bi directionalThe potential list of recipientsDoes system provide support for multicast,broadcastTable 1 : EMS properties [Wj03]Based on the above key properties of messaging service, thefollowing table2 [Wj03] [Wj04] gives a classification of fourmessaging systems and to which category they fall ListTable 2: Classification of four messaging systemsFrom the above table, it is clear that email messages fallshort in the most important feature of not being duplex. It is akey factor for a pervasive messaging system to use duplexcommunication which can enable the user to respondimmediately. Another problem is that email addresses only alist of users and not the world. Hence, using email as amethod of message delivery in a pervasive environment is notviable [Wj03] [Wj04]. Also if we can consider the propertiesof other messaging systems, we see that each one of them fallshort in one particular property. Hence we cannot use just oneunique method of unification. This is where the serviceadaptability plays a major role. The UM must be able to adaptthe message delivery based on the user’s location and the endterminal.Another shortfall of the existing UM solutions ispersonalisation for the end user. The current UM solutionsprovides a basic level of personalisation that enables users tofilter certain messages. This level of personalisation is sominimal that the system cannot personalize message deliverybased on user preferences. E.g. Users can block a particularperson from sending them an email irrespective of his/herIII. DECENTRALIZED UNIFIED MESSAGING SYSTEM DESIGNAND ARCHITECTUREA. System OverviewFigure 3 illustrates the overall architecture of the proposeddecentralized UMS (DUMS). The DUMS is a peer to peerarchitecture. Each device can initiate and accept a connectionrequest. The system receives incoming messages, notifies itspeer devices about the messages, gets a response from thepeer devices and replies to the sender.INCOMINGMESSAGES FROMSENDERTimeDirectionAudienceAddresslocation. But this is not satisfactory in terms of a UMS thatdelivers messages on demand. The system must be able tofilter messages depending on user current environment andhis environmental preferences. E.g. delivering a high prioritymessage to the user when the user is in a meeting. Thepriorities are set by the users and vary depending on user’spreferences. Similarly present UMs do not provide any formof service personalization. The system needs to choose theappropriate service that can be used to notify the user of anew message. As stated earlier, to implement servicepersonalization based on user’s location, the UMS must becontext aware and also terminal-aware. Service adaptabilityand personalisation plays the key in developing a MessageOn-Demand UMS. Such a system is user-centric and ispervasive. To implement such a Message-On-Demandservice, the central gateway technique that the current UMsfollow lacks the basic needs of being pervasive and not usercentric. Hence a system that is user-centric and pervasive canbe realized by using a decentralized design rather than agateway approach. Such a system is terminal-aware (userdevices) and is context-aware, hence knowing the needs ofthe user providing message delivery in the most appropriatefashion possible based on user’s demands. It also fulfils thegoal of UMS to deliver any messages any where, any time inthe most appropriate manner possible.REPLY MESSAGE TOSENDERcase of message notification. The lack of service adaptationalso raises a few more questions. Some of the UM solutionsuse only email or SMS as the one form of messagenotification. But this will not satisfy the needs of the usersince the user may have limited resources and hence cannotaccess one form of message service from another device[As99]. This approach is not always applicable in all casesespecially in our VPAN where the devices work to deliverservices to the user in a most appropriate manner possible.The method of using few types of message notification is notenough with the evolution of newer end-terminals and newermessaging technologies. To support this, we need to discussthe properties of few of the existing messaging technologiesbased on the properties show in table1 [Wj03] [Wj04]:EMAILINSTANTMESSAGESNOTIFY USEROF NEWMESSAGESMSEMAILUnified Messaging SystemSoftwareREPLY TONOTIFIEDMESSAGEUnified Messaging SystemSoftwareINSTAN TMESSAGESSMSFigure 3: Overview of decentralized UMS architectureAs we can see, the system obtains messages from externalsources, processes them and delivers to the user depending onuser’s context and end-terminal information. The deviceswork within the VPAN delivering messaging service ondemand to the user in the most appropriate manner possible.The decentralized architecture provides the option for theuser to reply to a message from any of the end-terminalirrespective of the message origination type. The DUMS takes
4care of the message conversion before dispatching it.B. Architectural DescriptionFigure 4 illustrates the DUMS architecture. The system, asseen, is split into a number of blocks, each of which performsa specific function. The entire system constitutes the DUMS.Figure 4: DUMS ArchitectureThe DUMS software on each device frequently checks fornew messages. When a new message arrives, the incomingmessage handler and notifier is the first module thatprocesses the message.Message ParserDUMS has the capability to convert messages from oneformat to another based on user’s preferences and context.The message parser is a key component which can understandthe various messaging systems message formats. It parses themessage to obtain information like sender’s address, phonenumber, message body, subject and other relevantinformation. The message parser also works on any newmessage notification/ response received from peer. In thiscase, it tries to retrieve information from the DUMS messageheader. The pseudo code in figure5 describes the function ofthe message parser.if (incoming message any message type)thenparse the informationobtain sender information message body, subjectforward this parsed information to the messagehandlerelse if ( incoming message is of type DUMSmessage)thenobtain message data from the DUMS messageforward this information to the message handlerFigure 5: Message ParserRouting ManagementThe routing management is the component that obtainscontext information, user preferences and end-terminalinformation to decide on the most appropriate message formatand the most appropriate device to be used for messagenotification. The routing management comprises a routingmanager that obtains context information from a contextmanager that is external to the DUMS. The contextinformation provides details on user’s location, hisenvironment details and end-terminal information. Contextinformation can be obtained by using a number oftechnologies most of which are still under research. Sincecontext by itself is a major field of research, this paper doesnot step into the development of a robust context managementsystem.Message HandlerThe message handler handles the inputs received from themessage parser and the routing management. The messagehandler is the one that is responsible for the Message-OnDemand service. It involves service personalization by takinginto consideration users preferences. Once message handlerreceives the context and end-terminal information from therouting manager, it uses the input from the profile manager toobtain user preferences. Based on user’s preferences andhis/her context information, the message handler decideswhether or not to notify the user of the message. The dataflow between the message handler and the other componentsis illustrated in figure6.Context, TerminalInformationRouting ManagerMessage HandlerUser preferences/demandsinformationProfile ManagerMessage InformationMessage ParserFigure 6: DFD for Message Handler, Parser and Routing ManagerMessage NotifierThe message notifier handles two tasks. New messagenotification that needs to be passed on a peer device andnotifications received from a peer device. The messagenotifier based on the inputs from the message handler takesinto consideration, user’s end-terminal device. The messagenotifier is responsible to establish a connection with the peerdevice, sending message notification to the peer device,waiting for an acknowledgement and disconnecting theconnection. If the message acknowledgement is not received,the message notifier contacts the message handler to obtaininformation of any other device that is within the user’s
5environment. If the message notifier receives a messagenotification from the peer device, it takes into theconsideration the device capability on which it is functioningand provides an appropriate notification to the user. Thepseudo code illustrated in Figure7 describes the messagenotifier functionality.Repeatif (message notification is PDA) thennotify PDAwait for ack.If ack truereturn successelse pass message back to message handlerelse if (message notification is smart phone) thennotify smart phonewait for ack.If ack truereturn successelse pass message back to message handlerelse if (message notification is laptop) thennotify laptopwait for ack.If ack truereturn successelse pass message back to message handlerwhile successFigure 7: Message NotifierReply Message Handler and DeliveryThe DUMS architecture provides a function that allows theuser to reply to any incoming message irrespective of thedevice. This functionality is achieved by the Reply MessageHandler and the Message Delivery components. The replymessage handler is an integral component of the DUMSarchitecture it can handle any reply messages that the userwishes to send. The reply message handler obtains deviceinformation to check if the same device can be used to sendthe reply message. If it cannot use the same device, it thenchooses the appropriate peer device which has the capabilityto send the message. For example, replying to an incomingSMS message notification as an SMS from the laptop. If thereply message handler decides to use a peer device to dispatchthe reply, it uses the message delivery sub system toaccomplish the task. The message delivery component usesreply message information from the reply message handler,communicates with the corresponding peer device anddispatches the user’s reply message. The format of the replymessage by default is the incoming message type. The pseudocode in figure8 describes the reply message handler anddelivery functions.Obtain and process reply messageConstruct reply message format with appropriateheadersCheck reply message typeIf require forwardingDispatch reply message to the peer device to be sent tobe dispatched to the message senderelsedispatch reply message to message senderFigure 8: Reply message handler and DeliveryC. DUMS Message FormatThe system uses the DUMS message format fortransferring messages between the peer devices. The DUMSmessage as illustrated in figure9 is made up of a set ofpredefined headers that encapsulates the original messages.IDSTYPEDTYPESADDRESSMESSAGEFigure 9: DUMS Message FormatID: This represents the Message ID. The message ID is aunique identifier used to uniquely identify each messagehandled by the DUMS.STYPE: This determines the source type of the message. Thesource type identifies in what format the message has actuallyarrived from the sender.DTYPE: The destination type identifies in which format themessage needs to be interpreted by the peer device. TheDTYPE takes the same values as the STYPE. E.g., DTPYEwill take value SMS if the destination device chosen todeliver the message is the users Smart Mobile Phone.SADDRESS: This identifies the sender of the message.IV. IMPLEMENTATION AND RESULT DISCUSSIONThe DUMS architecture differentiates itself from othersystem by being distributed, decentralized and pervasive innature. The system is aware of the user’s devices hence,allowing the system to notify the user of new messagespromptly regardless of location and time. The system is alsoadapts itself based on user’s location and messagingpreferences. The goal of the system is to send and receive anymessage anytime anywhere. The pervasive system requiresinformation about user’s context and environment. Contextinformation varies depending on the environment in whichthe user can be in. E.g. In a meeting, at home or on the movelike walking in a shopping mall or even driving a car. Sincecontext information varies based on user location andenvironment, the application of DUMS is classified into a fewscenarios based on the user’s environment. These scenariosare:At HomeIn the office / meetingOn the Move such as driving a car
6The main objective of the DUMS is to ensure promptdelivery of messages to the user in the most appropriatemanner possible. It is a major challenge to implement adecentralized system. Since the design involves a number oftechnologies that are still under research and are at variousstages of maturity, the proof of concept implementation isbased on a few assumptions. Also, as discussed earlier, sincecontext information can change depending on user’senvironment, the implementation to establish the DUMSarchitecture has been developed in specific to the HomeScenario. The system that has been developed works on theproposed DUMS architecture discussed in section3. Thisdecentralized UMS called the intelligent-UMS (i-UMS) ispervasive, context-aware and provides Message-On-Demandservice. The implementation of the prototype has been doneusing the Microsoft .Net framework. The reason behindchoosing the .Net framework was, the devices, namely laptop,PDA and smart phone were all based on Windows operatingsystem. Microsoft .Net provides rich programming api’s forprogramming mobile devices and devices with restrictedresources like the smart phone. The i-UMS developed wastested within the Home Scenario based on few real timesituations. The following section will provide a detaileddescription of the Home Scenario and the various test casescenarios with along with the results obtained.A. Home Scenario DescriptionHome Scenario is one of the typical cases of the usage ofi-UMS illustrated in figure10.Figure 10: Home Scenario VPANA simple case could be: The user might be in watchingtelevision having just the mobile phone with him/her. Aninstant message arriving on his/her laptop from an importantcontact is received and processed by the i-UMS. The systemthen contacts the location manager to obtain the locationinformation of the user and the device nearest to the user. Onobtaining this information, the i-UMS sends a messagenotification to the user’s mobile phone based on user’spreference. The user on receiving the message has the optionof replying to the message through the mobile phone. Thehome scenario is VPAN described previously where devicesare user-centric trying to deliver messaging services to theuser irrespective of time, location and message type.B. i-UMS ImplementationThe i-UMS prototyped was tested on the following types ofmessage types: email, Instant Message, voicemail and SMS.The i-UMS makes uses of Bluetooth, GSM, IEEE 802.11based wireless networks and wired networks forcommunicating between the users end-terminals. The endterminals used for the prototype implementation were thelaptop, PDA and Smart Phone. The main implementationfocus was to achieve the previously discussed goal of messagedelivery in the most appropriate format possible irrespectiveof time, location and message type. To achieve this goal, theimplementation will discuss mainly on the two primaryfunctions that is used to achieve this goal. They are messageretrieval and message delivery. The following sections willprovide the implementation details for the laptop, smartphone and the PDA.Message Retrieval and ParsingThe i-UMS on the laptop retrieves messages from theuser’s mailbox. The mailbox can be a POP3 server or anIMAP server. This operation is performed by using a thirdpart tool called the PowerTCP Mail for .NET [PT04]. The iUMS also retrieves IM from MSN messenger. The working ofthe i-UMS on the laptop is very simple. Whenever themessenger is set in away mode, i-UMS recognizes that theuser is not near the system. Hence, it immediately monitorsincoming messages. Once it receives a new message, it thenretrieves the message and passes it on to the messagenotification module as depicted by the code in figure11. Theretrieval of IM from MSN messenger is done by using theMSN messenger class module of the .NET class library. Itprovides rich class libraries to query and retrieve MSNmessenger status and IM [DM04]. The PDA can retrieveemail, IM and can notify the laptop or the smart phonedepending on the context information. The functionality ofthe i-UMS on the PDA for message retrieval is almost similarto that of the laptop with a few exceptions. In home scenario,the assumption is that the laptop is connected to the networkand, hence, has the ability to check for new messagesfrequently. Since the PDA is a low powered device, the needfor the PDA to check for new messages in this scenario is notnecessary. But the PDA does have the option of checking fornew messages which is more applicable in case of office or onthe move scenario. The message retrieval on the smart phoneinvolves the retrieval of SMS messages. i-UMS on the smartphone has the added ability to retrieve any new SMS messageand then parse the SMS message into a DUMS messageformat. Figure12 provides code snippet for monitoring andretrieving SMS messages from the smart phone.
7Public Class MessengerDim WithEvents msn As NewMessengerAPI.MessengerDim wnd1 AsMessengerAPI.IMessengerConversationWndDim contacts As MessengerAPI.IMessengerContactsDim contact As MessengerAPI.IMessengerContactEnd Sub‘Event to obtain instant message‘this is a turn around method that grabs incomingmessagePrivate Sub msn OnIMWindowDestroyed(ByValpIMWindow As Object) Handlesmsn.OnIMWindowDestroyedDim wnd AsMessengerAPI.IMessengerConversationWndwnd pIMWindowcontacts wnd.Contacts()Dim str As String wnd.HistoryFor Each contact In contactsusername contact.SigninNameNextIf msn.MyStatus 2 Then‘Construct the DUMS messageDim msg As New UMSDataUMSMSG.message msgIf str.IndexOf(msn.MySigninName) 0 ThenExit SubEnd IfUMSCollection.Add(UMSMSG)Figure 11: IM retrieval‘Retrieves new SMS messagePrivate Sub sms InboxChanged(ByVal sender AsObject,ByVal e AsSmartSMS.NETCF.InboxChangedEventArgs)Handles sms.InboxChanged'TextBox1.Text " "Dim Msg As SmartSMS.NETCF.SMSMessageDim date1 As New DateTimeDim date2 As New DateTimeDim dt() As StringFor Each Msg In e.MessagesDim timeString As String DateTime.Now.AddMinutes(-2)date1 DateTime.Parse(Msg.Time.ToString)date2 DateTime.Parse(timeString)If DateTime.Compare(date1, date2) 0 ThenmessageDispatcher(Msg)End IfNextEnd SubFigure 12: SMS retrievalMessage Notification and ReplyingMessage Notification is one of the important modules of iUMS. i-UMS does a number of processing before it actuallynotifies the user of the incoming message. i-UMS first obtainsthe priority of the message based on the user’s profile. It thencontacts the context manager to obtain the location of the userand the device that is near to the user. Once i-UMS figuresout the appropriate device to be notified, it then checks for theavailability of the devices and the technology that can be usedto communicate with the device. E.g., if the device to whichthe message needs to be forwarded to is a PDA, then i-UMSchecks if the PDA is in Bluetooth coverage. If it is not, then ituses wireless IEEE 802.11 to communicate with the PDA.This intelligence built into the i-UMS, completely makes usesof the decentralized architecture which facilitates the deviceto move from one location to another, but still keep in contactwith the other devices. Once the notification message is sentto the user’s device, the message pops up on the user’s deviceindicating the arrival of the new message. The user can viewand reply the message on the device. Once again i-UMS onthe device uses the same intelligence to find the best possibleway to forward the reply. This message dispatcher process isdescribed in figure13.Public Class MessageDispatcherPublic Function DispatchMessage(ByVal msg AsUMSMessage) As BooleanDim route As New MessageRouti
Unified Messaging. Unified Messaging enables users to manage their messages independent of location, communication device or communication medium. Most of the existing systems provide centralized message-store based access to messages but lack services like user personalization, message notification and are non-pervasive.
