doc/ofono-paper.txt

   1 oFono - Open Source Telephony
   2 *******************************************************************************
   3
   4 1.0 Introduction
   5
   6 Linux and other open source components are now used extensively on both desktop
   7 and mobile embedded devices.  They provide networking, power management,
   8 database and other core OS infrastructure.  However, up to this point no
   9 viable open source solution for mobile telephony existed.  oFono aims to
  10 change that; it is a telephony host stack specifically targeted at both
  11 mobile embedded and desktop systems.
  12
  13 Launched on May 11, 2009 oFono aims to provide a solid framework for builidng
  14 3GPP GSM/UMTS User Equipment (UE) standard compliant devices.  Support for
  15 CDMA/EVDO technologies is also planned.  The goal of oFono is to provide an
  16 easy to use, high-level API for applications.  This is accomplished by keeping
  17 the core logic within the daemon, taking care of standards compliance and
  18 exposing only the need-to-know aspects to the application.
  19
  20 The license for oFono was chosen as GPLv2.  This means that all core services
  21 and plugins for oFono must be Open Source.  oFono accepts GPLv2 or any
  22 GPL-compatible BSD license.  However, since oFono provides a D-Bus API, user
  23 interface applications can be of any license.
  24
  25 2.0 Design Philosophy
  26
  27 2.1 Modern
  28
  29 oFono aims to be a modern implementation, ready for the 21st century.  From
  30 the very beginning oFono was designed with support of multiple technologies
  31 and device types in mind.  It is also designed to support multiple active
  32 devices simultenously.  This enables greater flexibility and enables usecases
  33 not possible with current solutions.
  34
  35 oFono explicitly chooses not to support some of the more archaic features
  36 of GSM.  Specifically only limited use of the SIM for Phonebook support is
  37 enabled.  SIM storage for incoming and outgoing Short Messages (SMS) is also
  38 not supported.  The use of these features does not make sense on the current
  39 generation of devices, and introduces unnessary complexity.
  40
  41 2.2 Fast and Light
  42
  43 One of the main constraints for oFono's design was to make it extremely
  44 performant on resource-constrainted embedded devices.  This means that
  45 high-level languages like Python could not be used and library dependencies
  46 had to be kept to a minimum.  oFono is thus implemented in C and has minimial
  47 dependencies: libdbus, glib.  The reference drivers introduce two other library
  48 dependencies, gatchat and gisi, which are linked statically.
  49
  50 2.3 Standards Compliant
  51
  52 oFono is meant to be used in commercial systems, so standards compliance is a
  53 primary consideration from the very beginning.  Whenever possible oFono takes
  54 care of the gory details.  This includes the particulars of SMS decoding,
  55 de-fragmentation and duplicate detection; network operator name display;
  56 message waiting indicator processing and reporting; emergency dialing numbers,
  57 service numbers and subscriber number management; supplementary service
  58 control via strings defined in 3GPP TS 22.030.
  59
  60 3.0 Architecture
  61
  62 oFono provides a flexible, modular and extensible architecture with four main
  63 components: core daemon, oFono atoms, drivers and plugins.
  64
  65 3.1 Core Daemon
  66
  67 Core daemon provides base level services within oFono, namely the loading of
  68 plugins and drivers; utility APIs for decoding, encoding and fragmentation of
  69 binary SMS pdus; utility APIs for reading and writing to the SIM, and
  70 interpreting the contents of the low-level Element File (EF) contents; utility
  71 APIs for character set conversion; utility APIs for decoding, duplicate
  72 detection and pagination of cell broadcasts; and detection of and communication
  73 between oFono atoms.
  74
  75 A big part of the core daemon is the modem device abstraction.  Each device is
  76 managed independently, and several devices can be present and active in the
  77 system at the same time.  The technologies for each device are not restricted
  78 in any way, and can be customized via the use of drivers.
  79
  80 3.2 oFono Atoms
  81
  82 oFono atoms provide a clear abstraction API for the applications based on
  83 D-Bus.  There are currently over a dozen atoms within oFono, providing access
  84 to core functionality like voice calls, supplementary services, short message
  85 service (SMS), cell broadcast (CBS) and sim management.
  86
  87 Atoms can detect the presence of other atoms and use information provided by
  88 other atoms to provide extra functionality.  For instance, the Network
  89 Registration atom will read low-level EF files whenever a SIM is present, and
  90 provide enhanced operator information if the SIM is thus provisioned.
  91
  92 3.3 Drivers
  93
  94 oFono provides a way to integrate multiple device technologies through its
  95 driver mechanism.  All modem devices and atoms provide an abstract interface
  96 for low-level operations.  This interface is based on 3GPP TS 27.007 "AT
  97 command set for User Equipment" and 3GPP TS 27.005 "DTE-DCE interface for SMS
  98 and CBS".  oFono assumes that all operations are fully asynchronous.
  99
 100 This means that oFono can accommodate a wide variety of devices, including
 101 full-featured modems (AT command based and otherwise), data-only cards, and
 102 modem like devices (e.g. Bluetooth Handsfree and Sim Access Profile devices,
 103 etc.)
 104
 105 oFono provides a reference AT command driver, which should work for the
 106 majority of AT command based modems in the market.  oFono also includes an ISI
 107 protocol based driver, which will enable the majority of Nokia devices to be
 108 used.  Finally a Bluetooth Handsfree Profile (HFP) driver is also planned.
 109
 110 3.4 Plugins
 111
 112 Plugins provide a final piece of the puzzle.  These are used to provide device
 113 drivers and atom drivers.  They can also be used to extend oFono or interact
 114 with other system services.  For example, Moblin uses oFono plugins to store
 115 all call history information within Evolution Data Server.
 116
 117 4.0 D-Bus API
 118
 119 Much thought has been given to how user interface applications will interact
 120 with oFono.  The goal of the oFono API is to make the User Interface (UI)
 121 application writer's job as easy as possible.  This is accomplished in two
 122 ways: exposing only the essential details to the application and provide a
 123 high level API.  To accomplish this, oFono sticks to the following four
 124 basic principles of API design: Consistent, Minimal, Complete and Easy to Use.
 125
 126 4.1 Consistent
 127
 128 As mentioned previously, each atom provides a high-level D-Bus API, which is
 129 referred to as an interface.  Each interface has a well-defined set of
 130 properties and two special methods for managing them: GetProperties and
 131 SetProperty.
 132
 133 All names within oFono are CamelCased and this naming convention is strictly
 134 enforced.  This means that once the application writer is comfortable using
 135 one Interface, they should be able to quickly pick up others.
 136
 137 4.2 Minimal & Complete
 138
 139 A common pitfal of API design is exposing too much and assuming that the user
 140 has the same level of knowledge as the designer.  Almost always these
 141 assumptions are incorrect and lead to incorrect and inefficient use of the
 142 API.  This in turn leads to applications that are hard to write, maintain and
 143 replace.
 144
 145 Instead the API should be minimal; it should make it easy and apparent to the
 146 user how to accomplish a particular task he or she is interested in.  oFono
 147 accomplishes this by doing as much as possible within the core and only
 148 exposing the information which is actually required to be shown to the user.
 149
 150 4.3 Easy to Use
 151
 152 While the above three principles generally provide good results, a process of
 153 refinement can still be applied.  oFono works with user interface designers
 154 and implementers to continually improve its API.  This means that if a
 155 particular feature is found to be inefficient in practice, it refined and
 156 improved as quickly as possible.
 157
 158 5.0 Conclusion
 159
 160 oFono provides a full host protocol stack for telephony aware applications.
 161 Today, it enables most of the commonly used features defined by 3GPP standards,
 162 including voicecalls, sms, cbs, supplementary services and network registration.
 163 Data connections using GPRS and 3G features are being actively worked on.  It
 164 thus provides a viable, open source solution to system implementors seeking to
 165 add telephony capabilities to Linux desktop and mobile devices.
 166
 167 6.0 Resources
 168
 169 Website: http://ofono.org
 170 Mailing List: ofono@ofono.org
 171 IRC: #ofono on freenode
 172