Integrating notification services in computer network and mobile telephony
di Scienze dell'Informazione
Universitą di Bologna
Via Mura A. Zamboni 7
40134 Bologna, Italy
di Elettronica Informatica e Sistemistica Universitą Bologna,
viale Risorgimento, 2
40136 Bologna Italy;
Phone: +39 0547 642 826
di Scienze dell'Informazione
Universitą di Bologna
Via Mura A. Zamboni 7
40134 Bologna, Italy
User mobility and ubiquity are two key features for the information technology infrastructure. Our aim is to define an architecture that realizes the integration between a) a set of existing Internet/Intranet services, b) the services allowed by telecommunication network c) the applications and peripherals devoted to manage alarms and control industrial processes. The defined architecture permits to realize a simple exchange system that permits notification exchanges between different systems running on different platforms. This model is particularly suitable for environments that need strong personalization of the services, offered to users, in order to extend the existing services and to support the development of new ones.
Mobile Applications and Services, Integration of Mobile and Stationary Systems, Internet Services, Personal Communications.
Telecommunications and computing technologies are converging and the infrastructure and applications for these technologies have become largely blurred. Applications are becoming indistinct. An access to the bank services realized using DTMF telephone and voice response unit differs from the same access from a computer for the different medium that uses but does not offers really different functionalities.
The future network architecture need to satisfy many requirements as, for example:
- users ubiquity (nomadic access)
- users mobility
- QoS negotiation
- privacy and encryption.
The number of mobile users is rapidly growing, so the demand for mobile services are becoming stronger and more diversified . Actually the widespread mobile technology is the digital cellular telephony and is emerging the need to integrate mobile telephony services and computer network services. The integration between information services (e.g. databases), notification services (e.g. E-mail, alarm systems) and telecommunications infrastructure (e.g. GSM, Fax, etc.) is one of the strategic issues to satisfy mobility needs . Different kinds of protocols have been developed in recent years to permit the access to Internet Service from a mobile phone. In particular WAP (Wireless Application Protocol) became the "de facto" standard for this kind of application . Actually there are different reasons, for example different costs and diffusion of terminals that are WAP compliant, to prefer hybrid systems in which are embedded both WAP based service and SMS (Short Message Service) based services. This paper describes an architecture for the integration of network applications and telecommunication services that are based on SMS.
Video on demand
Table 1: Networked Applications Taxonomy
A taxonomy classifies network applications in four classes on the basis of the functionality and the temporal relationship of interactions  (as shown in table I). The two classes based on the functionality are:
- Users to Information Server applications, in which a user interacts with a remote system to receive or access to the information stored on that system.
- User to User applications, in which two or more users participate in the same shared functionality.
The two classes based on the temporal relationship of the interaction are:
- Immediate, meaning that a user is interacting with a server or another user with certain maximum delay bound.
- Deferred, meaning that a user is interacting with another user or a server without maximum delay requirements.
The proposed architecture could be used to integrate mobile telephony both with deferred applications, using an SMS-Interface. For the immediate applications a WAP Proxy system can be used but also the SMS-Interface can give access to immediate applications to people with a no-WAP terminal.
The remainder of this paper is organized as follows. In the next Section we describe some different applications of network and telephony integrated services. In Section III, we describe the architecture and its modular structure and in Section IV we give a brief description of the interface between the different modules. Finally, Section V concludes the paper giving a description of the implemented services and introduces some future works.
A first example of service is an extension and personalization of Internet e-mail. The mail system usually maintains a user mailbox and when a new mail arrives, the system reads it and sends a notice to the destination user, using an SMS message . The user can define the set of criteria used by the system to filter the mail message and redirects to the SMS only a part of the incoming mail messages. The user can also subscribe a "digest" service to receive in the first time only a set of mail headers and then to ask (with a SMS message) for one of the mail bodies. In the same way (see fig. 1) the user can configure the system:
- to automatically redirect some mail messages to a fax,
- to convert some mail messages in audio format and to transmit them with a traditional voice phone call.
Figure 1: E-mail extension services.
On the other hand the user can use the SMS system to send e-mail; the e-mail message is composed using the cellular telephone and sent to the system telephone number. The system recognizes the data format and the e-mail sending request, extracts the e-mail data and sends it to the destination using the SMTP protocol .
A second example of services set arises from a real case. Mobile features can be added to the Internet/Intranet services that are classically offered by a university both to students and to staff people. For example mobility can be added to all this category of services:
- services that provide support to the student, such as the exam registration or the spreading of exam results,
- services that provide support to the university staff, as for example a call meeting,
- services that provide support for didactical activities, such as remote evaluation of test results,
interoperability services (send/receive a mail, send a fax).
The SMS Interface can provide access to:
- mail system,
- Personal Information Manager (PIM) of teacher and staff people ,
- didactical information provided by the teacher
- practical information taken from the Information System
Figure 2: University I.S. Mobile Interface.
This kind of application incorporates the above mentioned SMS to mail gateway and also an extension of a personal scheduler, i.e. a PIM groupware application that allow shared decision making to a set of users. A scheduler service should be used, for instance, to reserve, confirm or cancel an appointment with a teacher or to call a meeting. The system should send to the user some SMS messages in order to remember the appointments of a certain day and, on the other hand, the user can add an appointment to the planner using an SMS message. These mobility features can be added both to commercial PC based PIM (for example Lotus® Notes or Microsoft® Outlook) and to ad hoc schedulers developed for particular applications.
A third application integrates phone feature in an industrial processes monitoring system, managed from one (or more) computer, that returns some information needed by processes control and security management. Usually this information are managed by the system, but sometimes, it is necessary to notify the system status to the system administrator (as shown in fig 3). The administrator can be contacted with different types of remote notification systems, for example with an e-mail message or, to add mobile features, with a SMS message. In more difficult situations a private police or the police or the firemen can be contacted using a voice telephone call. Finally, other situations require a decision of the administrator that sends, from a mobile telephone, a sequence of commands that must be executed on the control system.
Therefore, the service permits: a) to extend the notification service, in order to decide the type of notice, b) to make use of the mobility property of cellular telephones in order to reach in any case the administrator, c) to allow the administrator to interact with the control system, sending some command sequences, using SMS messages. The last purpose requires the implementation of a remote command shell of the control system.
Figure 3: Remote Control and Monitoring of Industrial Processes
Actually, in all the organizations, different notification systems send and manage electronic notices. This section describes an architecture that can be used to integrate all the notification exchange subsystems also with the new features offered by the mobile telephone network. All the subsystems can be described as entities that are producing or sending messages. For example an arriving e-mail message can be considered as a notice produced by the SMTP subsystem. On the other hand, each subsystem can process a redirected message; for example an e-mail message redirected to the SMS is produced by the SMTP subsystem and sent by the SMS subsystem.
The service definition describes how a message arriving from a certain subsystem will be redirected to another one. Some subsystems offer only output features. For example the fax can be used efficiently only to retransmit messages because for the fax incoming messages it is difficult to define a redirection protocol. On the other hand some other subsystems are able both to produce and send the messages (for example the SMS or the mail exchange subsystem).
The architecture scheme is based on two different plans (see figure 4): a) the Control Plan that controls a certain subsystem (for example the personal planner), b) the Service Plan that defines a certain redirection service (for example the e-mail to SMS service). Different Service Plans define different services and each Service Plan uses more than one Control Plan (i.e. more than one notification subsystems), as the service definition needs.
The Control Plan, is structured in different layers:
- An Interface Layer that is responsible of the connected service (for example the SMTP service or the SMS queue module).
- A Service Selection Layer that defines an interface between the specific services of the lower level and the standard exchange primitives of the system. This layer defines:
- Which service will redirect each message,
- Error Management,
- Low level billing accounting, to maintain information about the subsystem services costs.
This layer also provides some coding/decoding primitives.
- A Control Management Layer, that provides primitives and interfaces to configure both the Interface Layer and the Service Selection Layer.
Each user of the service needs a personal service definition that can be managed and changed directly by the user.
Figure 4: The system modules
Therefore the Service Plan structure is described using multiple layers to define the user services. In particular, the Service Plan, is structured in the following layers:
- A System Service Layer that is responsible for general policies of the service. This layer defines also:
- Policies of service management,
- billing and accounting policies for the service,
- authentication policies,
- coding and decoding from a message structure to another one (for example from a mail message to an SMS message).
- More User Service Layer that define the personal redirection policies for the service. Each user of the service has got a personal User Service Layer, so the Service Plan uses one System Service Layer and more User Service Layers.
- A Service Management Layer, that provides primitives and interfaces to configure the System Service Layer. Note that only the administrator can use this layer to define general policies and user management.
- A User Management Layer, that provides primitives and interfaces to configure the User Service Layer. Note that each user can configure only his User Service Layer to define personal redirection policies.
The Control Plan and the Service Plan communicate using the interface between the System Service Layer and the Service Selection Layer. The interface primitives are the same for all the services and for all Control Plans.
All the notification exchange subsystems are classified as Deferred User to User application. This means that the communications between the control plan and the service plan are asynchronous in both the directions:
- when a Service Plan asks to a certain Control Plan to dispatch a notice, the Control Plan attempts to send the message and can give back a result only after an unpredictable delay;
- when a Control Plan asks for a redirection to a certain Service Plan, the Service Plan redirects the message to another Control Plan and waits for a result that can arrive after an unpredictable delay.
The interface between the Control Plan and the Service Plan is based on two primitives SendMSG and RedirectMSG that are briefly described in the following. A more complete description of the interface primitives can be found in .
SendMSG is used by the Service Plan to ask to a certain Control plan to dispatch a message. The primitive specification is the following:
SendMSG(<SendID>,<senderService>, <msgContent>, <priority>)
The <senderService> value identifies the Service Plan that asks for the call and the <msgContent> is the content of the message. A unique identification number is used to associate each command with the proper return-call (<SendID>) and a <priority> value specifies the priority for the redirection call.
All the Control Plans provide a server process that is waiting for SendMSG requests. Each Control Plan accepts SendMSG with the appropriate msgContent type. The msgContent can contain a verify request, for example in the mail message a receipt request can be included. All this kind of information and all the error messages are redirected to the Service Plan using the RedirectMSG primitive.
RedirectMSG is used by a certain Control Plan to submit a new message to a certain Service Plan. The primitive specification is the following:
The <SenderControl> value identifies the Control Plan that will redirect the message and the <MsgContent> is the content of the message. A unique identification number is used to associate each command with the proper return-call (<RedirectID>).
All the redirection information are include in the msgContent and are coded in a service-dependent protocol.
Different applications based on the above mentioned architecture have been developed. In particular we report about a case study, the GSM-SMS gateway, with the aim of give an example of the proposed architecture (see fig. 6). In this service gateway there are two Control Plans, one for the mail exchange subsystem and one for the SMS. The Control Plane for mobile services has been implemented on a Linux platform using a Siemensć M1ā engine  working with the GSM  protocol, that actually is the Italian digital cellular standard. The Control Plan software is written in Java and C. The Control Plan for the e-mail subsystem is a common used SMTP server, installed on a Linux platform. Both the notification subsystems produce and redirect messages, so that a message can be redirected from the mail to the SMS and vice versa. The Service Plan (written in Java and running on a Linux platform) will define:
- which mail messages are redirected on the GSM-SMS device and vice versa (in different User Service Layers);
- the billing policies for the service (in the System Service Layer).
Figure 5: Mail to/from GSM-SMS service.
In this scenario the Interface Layer is a simple SMTP server and the Service Selection Layer defines which kind of services are associated to each mail message. The criteria used by the Abstraction Layer are based on the mailbox accounting. When a new mail message for email@example.com arrives to the SMTP server (the Interface Layer), the SMTP Service Selection Layer identifies the SMTPto/fromSMS as the service plan responsible for this mail message. The message is passed to the server using:
In the mailContent are included all mail information (subject, body, from, to, date,). The Service description layer decodes the mailContent, defines the appropriate redirection rules, codes all the information in the new Content type and communicates to the Service Abstraction Layer how to redispatch the message. So if the massage is redirected effectively on the SMS system, a call to SendMSG is sent to the GSM-SMS Service abstraction layer:
SendMSG(<SendID>, SMTPtoSMS, <gsmContent>, <priority>)
The gateway between the mail and the SMS system has been completely implemented and is currently under test. In particular the user is provided with a WEB interface to permit strong personalization of the services. This interface for the User management Layer is implemented as a Java Applet (see figure 6). The user can define the set of criteria used by the system to filter the mail messages and to redirect only a part of the incoming mail to the SMS. These filters can be based on :
- a part of the mail message header (From, Priority, Subject),
- the current time,
- the presence of a certain word in the mail body.
Figure 6: Interface to the User management Layer
The user can also subscribe a "digest" service to receive in the first time only a set of mail headers and then to ask (with a SMS message) for one or more mail bodies.
Tests done with about 30 users (typically professors and member of the university staff) shows that people that receive more than 10 mail need a strong reduction of the traffic and in particular all our user have set up:
- a digest service to receive all the mail in a compact form, or
- complex filters to receive only the important and urgent mail on the GSM device.
Figure 7 shows a mail message received on the GSM device and a digest message that reports the sender and the subject of different mail messages.
Figure 7: A mail message and a digest report
We have also re-used a part of the implemented Control Plans as components of the above mentioned university Intranet services (as described in section 2.2). In particular we have implemented:
- A PIM based on Microsoft® Outlook© and developed in a multiplatform environment in which the Control Plans work on a Linux architecture and the Service Plan is implemented on an Microsoft® Windows NT Server© (with Microsoft® Exchange Server©).
- the interface with the Information System, that offers to students and teacher different the opportunity to access to support services and to upload or download didactical information, as for example exam registration and result.
More information about the implementation of the university services can be found in . We are now working on an enterprise environment in which we have realized a first service that uses GSM-SMS to provide to the clients information about the status of the manufacturing process. We are currently working on the remote control and monitoring of a part industrial process with mobile interface (as described in section 2.3).
The authors would like to acknowledge for the support and precious comments given to this work: "Fondazione Guglielmo Marconi", in particular his president Prof. Gabriele Falciasecca and "Telecom Italia Mobile S.p.A".
 Decina, M. and Trecordi, V. "Convergence of telecommunications and computing to networking models for integrated services and applications", ' Proceeding of the IEEE, vol. 85, no. 12, pp. 1887-1914, Dec. 1997
 European Telecommunications Standard Institute, GTS GSM 01.02, European Telecommunications Standard Institute, fifth edition, Mar. 1996.
 Fasbender; A., Reichert; F., Geulen; J., Hjelm; J. And Wierlemann, T. "Any network, any terminal, anywhere'', IEEE Personal Communications, pp. 22-30, Apr. 1999.
 Ghini, V., Pau, G. and Salomoni, P. "Accessing Educational Services through Computer Networks and Mobile Telephony", Proceeding of 2000 ICSEE/Western MultiConference on Computer Simulation (ICSEE/WMC'2000), accepted for publication, San Diego (USA), Jan. 2000
 Messerschmitt, D.G. "The convergence of telecommunications and computing: What are implications today?'', Proceeding of the IEEE, vol. 84, no. 8, pp. 1167-1186, Aug. 1996.
 Palmer T.D. and. Fields N.A. "Computer supported cooperative work'', IEEE Computer, vol. 27, no. 5, pp. 15-17, May 1994.
 Postel, J. "Simple mail transfer protocol'', STD 10, RFC821, USC/Information Sciences Institute, Aug. 1982.
 Siemens A.G. User Guide GSM Module M1, Siemensć A.G, 1997.
Copyright 2000 ACM
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy
otherwise, to republish, to post on servers or to redistribute to lists,
requires prior specific permission and or fee.
SAC 2000 March 19-21 Como, Italy
(c) 2000 ACM 1-58113-239-5/00/003>...>$5.00