![[Logo]](/images/logo.png){kind=logo} |
GPE Phone EditionGTK based solutions for mobile phones |
GPE Phone Edition Architecture
GPE Phone Edition Architecture
Instant messaging & Presence enabler
Address book & Instant messaging & Presence
Application Launcher & Home screen
GPE Phone Edition Architecture
This document intends to describe the general architecture of the GPE Phone Edition software system, which is based on part of the LiPS implementation code and GPE project, aiming at providing an almost complete software stack for mobile phones, especially smart phones.
This document will firstly give an overall introduction to the architecture, and then describe each component one by one and most importantly their interaction.
The figure above gives the general architecture of the system. From top to down, it can be divided into the following component groups: applications, enablers, UI services, OS services, IPC bus system, daemons, and hardware. Among these component groups, enablers, UI services and OS services fall into LiPS scope and are roughly compliant with LiPS standards. For general description on them and other LiPS standards, please refer to http://lipsforum.org/index.php?option=content&task=view&id=55.
Other component groups of the architecture are out scope of LiPS and general definitions are given below.
Applications provide end users specific functionalities with Graphical User Interfaces. An application calls UI services and enablers to finish its duties. Applications may also interact with each other by requesting services provided by other applications. e.g., voice call application may request address book application to find a contact for it as the remote peer to talk to. Applications use IPC bus system to interchange requests and responses.
Enabler Services provide applications with interfaces to high-level functionalities. For detailed definitions please refer to LiPS reference architecture (http://lipsforum.org/index.php?option=content&task=view&id=55).
UI Services provide applications with the services related to user input and output such as views, widgets, input events, etc. For detailed definitions please refer to LiPS reference architecture (http://lipsforum.org/index.php?option=content&task=view&id=55).
Except for applications, other components in the architecture are UI services independent.
In this system, Gtk+ is used as the UI services.
OS Services are a collection of protocols and technologies necessary for implementation of service enablers. For detailed definitions please refer to LiPS reference architecture (http://lipsforum.org/index.php?option=content&task=view&id=55).
IPC bus system provides facilities of inter-process communication between components which are located in different processes. DBus is used as the IPC bus system in this software system and a wrapper library libiac is used somewhere.
Daemons are the processes running background with some specific tasks to deal with. Normally they don't have graphical user interfaces.
Hardware provides hardware interfaces to OS services. This representation is on operating system API level, not hardware register level.
This is the driver interface to the GSM or 3G "modem" component to control voice and data "calls". This will also be the interface to listen to for external asynchronous events coming from the operator network.
This is the audio hardware interface and most probably only controls the digital sound playback, like for ringtones or multimedia contents like music.
Real time clock
Hardware interface for user keyboard input. Normally phone keypad is different with that of PC keyboard. Phone keypad has fewer keys compared to PC keyboard.
Hardware interface for user touch screen input
Address book enabler provides top level applications functionalities to access to one or several address books.
An address book is a collection of contacts. A contact is a collection of fields. A set of contacts may belong to one category based on some classifying criteria.
APIs on adding/removing/modifying/querying contacts are provided by address book enabler.
A set of standard field templates are defined by this enabler and APIs manipulating fields are provided.
APIs manipulating categories are provided too.
Currently there is no mechanism to notify the address book upgrading to interested applications. Relevant functions should be provided in the future.
Address book enabler uses sqlite indirectly via a wrapper library librecord to store its contacts/categories.
There may be different types of address book existing on the device owing to their different storage location. e.g, address book stored in the flash, sim card, or some network server, etc. Address book enabler provides applications unified APIs dealing with the different types of address books and implementation details of different address book are hidden behind the unified APIs.
For address book stored in the flash, implementations are straightforward.
For address book stored in the SIM card, things are a little different. Address book enabler doesn't talk to SIM card directly, instead it will deal with a mirror database located in RAM (/tmp directory). Once Phone server starts up, it will create this mirror database and then read out all contacts in the SIM card phone book into the database. Later it is the responsibility of phone server to synchronize contacts in SIM card and in the mirror database. Once the device is shutdown, the mirror database doesn't exist any more.
For address book stored in some network server (Network Address Book/NAB), a mirror database of NAB is locally stored in the device flash and manipulated by address book enabler . Synchronization between NAB and local database uses instance messaging & presence enabler.
The Messaging enabler provides applications unified interfaces (APIs) to send, to receive, and to manage various types of messages, including SMS, Email, MMS, EMS, Voice mail.
Each message has a unique identifier, a message header and a message body. Functions constructing a new message are provided. Each message is stored in a message repository, and indexed by a folder tree. Through the folder tree APIs, messages can be queried/added/removed/modified.
A set of transport channels are provided. Through the concept of channel, the difference of low level transport process (owing to different message types) is hidden and a generic means to send a message out of the device is provided to top level applications.
The enabler will notify top level applications a new message received through changes occurred to the INBOX folder of the folder tree. Details on how to receive a message into the INBOX folder are hidden to the top level applications and are the responsibility of messaging enabler.
Currently in the system only SMS application uses messaging enabler and Email application should be adapted to use this enabler in the future. Accordingly, currently there is only type of channel implemented in the enabler which is responsible for transmitting SMS. The channel should call TAPI service to send an SMS out, however, owing to some historical reasons, currently the channel implementation deals with phone server directly via IPC bus system. This behavior should be adapted too in the future.
Voice call enabler provides applications functions to dial, to receive, and to manage voice phone calls through a specific phone line.
Voice call enabler calls low level OS services to actually make a phone call. Though different bearers (e.g. circuit switched or IP telephony) or protocols (e.g. H323 or SIP) may be used to make a phone call, APIs provided to the top level applications should be the same.
Currently Voice call enabler uses two types of low level services, GSM TAPI and VoIP/SIP. Please refer to relevant sections to know more details about the two services.
Calendaring enabler provides functions for calendaring and scheduling applications. It has been designed as a middle layer which provides only the basic and core calendaring and scheduling functions, such as calendaring data management, date and time calculation, alarm job management.
When a new calendar event is produced, calendaring enabler stores it into a sqlite database and produces an ATD event which matches to the instance which will happen in the nearest future. ATD daemon will monitor these ATD events and notify calendar enabler when one event goes off.
It's independent from the implementation of the specific applications. Application developers can easily implement their own applications using this library. Glib-2.0, sqlite3 and uuid are the prerequisites to use the library.
Instant messaging & Presence enabler
Instant messaging & presence enabler provides applications functions to exchange instant messages and presence information with remote online users and to manage one's own presence information.
APIs on constructing a new message, sending/receiving messages are provided.
APIs on publish one's presence information, authorizing others' subscription request, pulling/subscribing to others' presence information are provided
This enabler doesn't talk to a network server directly, instead an IM proxy process running background is responsible for the communication with network server. The enabler will talk to the IM Proxy process through IPC bus system. Via this design, several client applications of this enabler can login simultaneously at the same time with the same account.
J
The open source GStreamer is used as the backend of multimedia applications. One thing should be mentioned here is that GStreamer doesn’t talk to audio device directly, instead, it will talk to sound server.
TAPI service provides APIs to access functionalities provided by the radio stack (Modem). Currently the following functionalities have been implemented: Voice call, voice call supplementary service, short messaging service, phonebook service.
TAPI service doesn't deal with the radio stack directly. It talks to the phone server through IPC bus system.
An open source component linphone is used as the VoIP/SIP services
sqlite is used as the database service. A conveniece library librecord is provided.
The Multiplexer daemon keeps exclusive access to the modem once it is started. It is based on an open source component gsmmux and implements the GSM07.10 standard. Via this daemon, two virtual channels for a single modem are created, one for AT commands and the other for data packets. Phone server talks to the AT command channel to implement telephony relevant services. PPPD talks to the data channel to implement GPRS functionalities. If the modem doesn’t support multiplexer, then the daemon can be disabled and phone server can directly talk to the modem.
Phone server keeps exclusive access right to the AT command virtual channel of the modem if multiplexer is enabled, or keeps exclusive access right to modem directly if the multiplexer is disabled.
Phone server interacts with phone relevant applications through IPC bus system. The applications request a phone relevant service, which will be passed on to TAPI, and TAPI will forward the request to phone server through IPC bus message. Once phone server receives the message, it may translate it into corresponding AT command and then write to modem or modem command virtual channel. Response of the AT command, and unsolicited event, such as an incoming call, will be send back to corresponding applications via IPC bus system again.
Phone server is started up once the device is powered on and create a mirror address book for the phonebook in the SIM card.
Sound server keeps the exclusive access right to audio chip. Applications like multimedia player, voice call, etc can't directly request audio device to play a sound, instead, they need forward their requests to sound server and the latter will talk to the audio device to play a sound.
If several applications request sound services simultaneously, sound server is able to do sound mixing to play them together.
IM proxy communicates with remote server and deals with all IM & Presence protocol relevant issues.
This is the most important component of the whole system. It will connect most of the various service providers with the service users. It offers high speed low latency message exchange through a bus like architecture. Every component that wants to use this service has to register to the bus and will then receive messages of the registered type.
DBus is used as the IPC Bus System and a wrapper library libiac is also used somewhere. There are quite a few IPC messages in the system, and among them, two types of IPC messages are needed to mentioned here:
The first type of IPC message is between applications. One application can provide some service and other applications can request that service through an IPC message.
The second type of IPC message is between enabler/service and daemons. Some enabler/service need the help of a daemon to finish its duties and it request the help from daemon also by IPC messages. e.g., TAPI need exchange messages with phone server to implement its functionalities.
This application implements the functionalities to send and receive emails. The backend of this application is tinymail.
This application implements the functionalities to send and receive sms, to store and manage sms through a set of message boxes, such as INBOX, OUTBOX, SENT, etc.
This application is able to interact with other applications such as address book. It can request address book to display the contact list window and then choose one or several contacts as the recipients of messaging. It can also provide the message composing service and adddress book application may use this service to compose a sms and then to send to a specified contact.
This application implements the functionalities relevant to voice call, such as make/accept/hold/unhold/hang up a phone call, etc. Conference call functionalities are also provided.
Two types of lines are supported, GSM line and VoIP/SIP line. If end user wants to make a phone call via VoIP/SIP, a network link such as WiFi is needed.
Voice call is able to interact with other applications such as address book application. It can request address book to display the contact list window and then choose one contact as the remote peer to talk to. It can also provide a dial service to other applications. Address book application may use this service to make a phone call to a specified contact.
Voice call is launched once the device is powered on and then runs background. Once the end user request to make a phone call or there is an incoming call, the voice call application will show frontground to the end users.
This application provides end users functionalities to view their voice call history: which calls at what time were dialled out, accepted, missed, etc.
This is a light weighted calendar application which provides functionalities to create/modify/delete/query a calendar event, to look at calendar events from different views, and to be notified when a calendar event goes off. The small footprint and the high efficiency make the application suitable to run on embedded devices.
Address book & Instant messaging & Presence
This application provides end users functionalities to manage their contacts. The application can manage contacts located in different locations, such as flash, SIM card, network server, etc.
For the contacts located in network server, end users can monitor their presence information and exchange instant messages with a online contact.
There are two multimedia applications, audio player and video player. They are simple frontends of Gsteamer component.
Application Launcher & Home screen
This application provides functionalities relevant to two categories: application launcher and home screen.
Application launcher acts like a menu and enables the user to choose from a variety of applications to be run or displayed. Application launcher manages the life cycle of each other application and keeps each application to only have a single running instance at a time.
Home screen is the default window when there is no active application/activity in the phone device. It displays a decorative wallpaper with some basic information, such as operator name, current time, etc. Home screen also displays a set of icons as the shortcut to launch corresponding applications.
Once some important event occurs, e.g., a new SMS arrives, an incoming call happens, or a calendar event goes off, corresponding notification indicator is shown on the Home screen.
This application is located at the top area of the screen and provides end users some system information indicators, such as battery level, signal strength, text input method, etc.