summaryrefslogtreecommitdiffstats
path: root/doc/ofono-paper.txt
blob: ec6d01b96167ed64a274d89b876461f7db321fbd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
oFono - Open Source Telephony
*******************************************************************************

1.0 Introduction

Linux and other open source components are now used extensively on both desktop
and mobile embedded devices.  They provide networking, power management,
database and other core OS infrastructure.  However, up to this point no
viable open source solution for mobile telephony existed.  oFono aims to
change that; it is a telephony host stack specifically targeted at both
mobile embedded and desktop systems.

Launched on May 11, 2009 oFono aims to provide a solid framework for builidng
3GPP GSM/UMTS User Equipment (UE) standard compliant devices.  Support for
CDMA/EVDO technologies is also planned.  The goal of oFono is to provide an
easy to use, high-level API for applications.  This is accomplished by keeping
the core logic within the daemon, taking care of standards compliance and
exposing only the need-to-know aspects to the application.

The license for oFono was chosen as GPLv2.  This means that all core services
and plugins for oFono must be Open Source.  oFono accepts GPLv2 or any
GPL-compatible BSD license.  However, since oFono provides a D-Bus API, user
interface applications can be of any license.

2.0 Design Philosophy

2.1 Modern

oFono aims to be a modern implementation, ready for the 21st century.  From
the very beginning oFono was designed with support of multiple technologies
and device types in mind.  It is also designed to support multiple active
devices simultenously.  This enables greater flexibility and enables usecases
not possible with current solutions.

oFono explicitly chooses not to support some of the more archaic features
of GSM.  Specifically only limited use of the SIM for Phonebook support is
enabled.  SIM storage for incoming and outgoing Short Messages (SMS) is also
not supported.  The use of these features does not make sense on the current
generation of devices, and introduces unnessary complexity.

2.2 Fast and Light

One of the main constraints for oFono's design was to make it extremely
performant on resource-constrainted embedded devices.  This means that
high-level languages like Python could not be used and library dependencies
had to be kept to a minimum.  oFono is thus implemented in C and has minimial
dependencies: libdbus, glib.  The reference drivers introduce two other library
dependencies, gatchat and gisi, which are linked statically.

2.3 Standards Compliant

oFono is meant to be used in commercial systems, so standards compliance is a
primary consideration from the very beginning.  Whenever possible oFono takes
care of the gory details.  This includes the particulars of SMS decoding,
de-fragmentation and duplicate detection; network operator name display;
message waiting indicator processing and reporting; emergency dialing numbers,
service numbers and subscriber number management; supplementary service
control via strings defined in 3GPP TS 22.030.

3.0 Architecture

oFono provides a flexible, modular and extensible architecture with four main
components: core daemon, oFono atoms, drivers and plugins.

3.1 Core Daemon

Core daemon provides base level services within oFono, namely the loading of
plugins and drivers; utility APIs for decoding, encoding and fragmentation of
binary SMS pdus; utility APIs for reading and writing to the SIM, and
interpreting the contents of the low-level Element File (EF) contents; utility
APIs for character set conversion; utility APIs for decoding, duplicate
detection and pagination of cell broadcasts; and detection of and communication
between oFono atoms.

A big part of the core daemon is the modem device abstraction.  Each device is
managed independently, and several devices can be present and active in the
system at the same time.  The technologies for each device are not restricted
in any way, and can be customized via the use of drivers.

3.2 oFono Atoms

oFono atoms provide a clear abstraction API for the applications based on
D-Bus.  There are currently over a dozen atoms within oFono, providing access
to core functionality like voice calls, supplementary services, short message
service (SMS), cell broadcast (CBS) and sim management.

Atoms can detect the presence of other atoms and use information provided by
other atoms to provide extra functionality.  For instance, the Network
Registration atom will read low-level EF files whenever a SIM is present, and
provide enhanced operator information if the SIM is thus provisioned.

3.3 Drivers

oFono provides a way to integrate multiple device technologies through its
driver mechanism.  All modem devices and atoms provide an abstract interface
for low-level operations.  This interface is based on 3GPP TS 27.007 "AT
command set for User Equipment" and 3GPP TS 27.005 "DTE-DCE interface for SMS
and CBS".  oFono assumes that all operations are fully asynchronous.

This means that oFono can accommodate a wide variety of devices, including
full-featured modems (AT command based and otherwise), data-only cards, and
modem like devices (e.g. Bluetooth Handsfree and Sim Access Profile devices,
etc.)

oFono provides a reference AT command driver, which should work for the
majority of AT command based modems in the market.  oFono also includes an ISI
protocol based driver, which will enable the majority of Nokia devices to be
used.  Finally a Bluetooth Handsfree Profile (HFP) driver is also planned.

3.4 Plugins

Plugins provide a final piece of the puzzle.  These are used to provide device
drivers and atom drivers.  They can also be used to extend oFono or interact
with other system services.  For example, Moblin uses oFono plugins to store
all call history information within Evolution Data Server.

4.0 D-Bus API

Much thought has been given to how user interface applications will interact
with oFono.  The goal of the oFono API is to make the User Interface (UI)
application writer's job as easy as possible.  This is accomplished in two
ways: exposing only the essential details to the application and provide a
high level API.  To accomplish this, oFono sticks to the following four
basic principles of API design: Consistent, Minimal, Complete and Easy to Use.

4.1 Consistent

As mentioned previously, each atom provides a high-level D-Bus API, which is
referred to as an interface.  Each interface has a well-defined set of
properties and two special methods for managing them: GetProperties and
SetProperty.

All names within oFono are CamelCased and this naming convention is strictly
enforced.  This means that once the application writer is comfortable using
one Interface, they should be able to quickly pick up others.

4.2 Minimal & Complete

A common pitfal of API design is exposing too much and assuming that the user
has the same level of knowledge as the designer.  Almost always these
assumptions are incorrect and lead to incorrect and inefficient use of the
API.  This in turn leads to applications that are hard to write, maintain and
replace.

Instead the API should be minimal; it should make it easy and apparent to the
user how to accomplish a particular task he or she is interested in.  oFono
accomplishes this by doing as much as possible within the core and only
exposing the information which is actually required to be shown to the user.

4.3 Easy to Use

While the above three principles generally provide good results, a process of
refinement can still be applied.  oFono works with user interface designers
and implementers to continually improve its API.  This means that if a
particular feature is found to be inefficient in practice, it refined and
improved as quickly as possible.

5.0 Conclusion

oFono provides a full host protocol stack for telephony aware applications.
Today, it enables most of the commonly used features defined by 3GPP standards,
including voicecalls, sms, cbs, supplementary services and network registration.
Data connections using GPRS and 3G features are being actively worked on.  It
thus provides a viable, open source solution to system implementors seeking to
add telephony capabilities to Linux desktop and mobile devices.

6.0 Resources

Website: http://ofono.org
Mailing List: ofono@ofono.org
IRC: #ofono on freenode