2
Agenda
● Introduction ● Architecture ● Tizen2.1 Features ● Call Flows ● Porting Telephony ● Future work
4
Introduction | Feature Overview
● Offers rich functionalities § Voice Call and Messaging services § Supplementary services, USSD § SIM, Phonebook, SAT § Packet and A-GPS services § Network services (LTE, 3G/2G)
● Plug-in based Architecture
§ Modem Agnostic § Flexible and easily customizable as per OEM needs
5
Introduction | Feature Overview
● Commercial ready ● Verified on Ref.Device-210 and Ref.Device-PQ ● Verified on Intel Medfield device
● License ● Apache License Version 2.0
● Reference plugin available ● AT commands (3GPP 27.007/ 27.010) based plugin
7
Architecture | Definitions ● Core Objects
● Executable components of a Telephony Module (SIM, CALL, SS, etc.). ● Bundle of functions and supportive database information designated to the
Module. ● Template Core Objects
● Non-Executable components, but result in executable Core Objects when cloned.
● Hardware Abstraction Layer (HAL) ● Abstracts the communication channel with modem.
● Hooks ● Mechanism to tap Requests/Notifications of other Telephony Modules of
interest.
8
Architecture | Telephony Components
The major components of Telephony are – ● Telephony libraries
● Telephony API (TAPI) library ● Core Telephony library
● Telephony Plug-ins ● Communicator plug-ins ● Modem plug-ins ● Modem Interface plug-ins (HAL) ● Free Style plug-ins
● Telephony Server
10
Architecture | TAPI library
● Telephony API library (or simply TAPI) is a standardized interface provided to applications to interact with Telephony over DBUS.
● TAPI is provided as libslp_tapi and executes in application’s context. ● TAPI provides Sync and Async APIs.
11
Architecture | Telephony Core library
● Core Telephony library (or simply libtcore) provides an API framework for Telephony components to inter-work.
● It is provided as libtcore package.
15
Tizen2.1 Features | Design consideration
● Optimize the support of various types of modem architectures from same vendor.
● Modem plug-in needs to be hardware agnostic.
● Modem Interface plug-in is the adaptation layer between the telephony framework and the hardware of your target device
● Avoid code duplication by introducing Core object templates and operations
over-riding.
Modem plug-in
Modem I/F plug-in B
Modem A
Modem I/F plug-in A
Modem B
Same Vendor
TTY
CA
IF
16
Tizen2.1 Features | Core Object cloning
● Core Objects can be cloned from ready-to-use Template Core Objects
● Template Core Objects are stored in Server
● Cloned Core object is Executable
17
Tizen2.1 Features | Over-riding operations
● Operations over-riding enables Vendors to customize the Core Objects ● Over-riding can vary from 0 – 100 % ● Callbacks for notification(s) can also be over-rided
18
Tizen2.1 Features | CMUX support
● 3GPP TS 27.010 – Terminal Equipment to Mobile Station (TE-MS) multiplexer protocol is supported
● Currently supports Basic mode operation ● Enables different Core Objects (CALL, SIM, SMS, etc) to interact with
Modem concurrently through multiple CMUX channels
19
Tizen2.1 Features | Internal CMUX ● Internal CMUX uses CMUX
feature of libtcore ● Each Logical HAL has a dedicated
CMUX channel ● Logical HALs can be shared
between Core Objects ● The HAL assignment to Core
Objects is done by the mapping table Mapping Table
Setup Mapping table
Map
ping
tabl
e re
fere
nce
HAL1 SMS CALL
HAL3
HAL2 SIM SAT
Network
20
Tizen2.1 Features | Kernel CMUX ● The MUX driver is an open
source implementat ion (N_GSM) of the 3GPP 27.010
● Multiple Physical HALs exist, each has a dedicated Kernel CMUX channel
● Physical HALs can be s h a r e d b e t w e e n C o r e Objects
Mapping Table
Mapping table reference
Setup Mapping table
HAL1 SMS CALL
HAL3
HAL2 SIM SAT
Network
21
Tizen2.1 Features | Hardware agnostic Modem plug-in
● Same Modem plug-in can operate across various types of modem architectures (from same vendor)
● Hardware specific adaptation are required ONLY in Modem Interface plug-in
Modem Modem
Modem Plug-in
Kernel space
Modem Interface Plug-in
Physical HAL
Physical HAL
Driv
er
Driv
er
Modem Interface Plug-in
Physical HAL
Driv
er Driv
er
Driv
er
Logical HAL Logical HAL
23
Call Flows | Boot-up sequence
Communicator Plugin
Server
Init
Load Load
Load
Call Init
Call Init
Call Init
Init
Init
Template CO plug-in
Modem Interface
Basic plug-‐in folder
Create communicator
24
Event ADDED_PLUGIN
Load and Initialize modem plug-in
Call Flows | Initial sequence Communicator Modem Modem
Interface Modem plug-in Server
Init Modem Interface plug-in
Modem communication setup Registers Modem
Mux Setup
Check Modem state
Mux Setup
Requests specific modem plugin loading
Init Create physical HAL(s)
Initialize sub-modules and
clone Core Objects
Assign logical or physical HALs to Core Object type
Creates interfaces
for the Sub-modules present
Modem Ready
Add Modem item
Setup Mapping table
25
Call Flows | Application request sequence Communicator Modem
Interface Modem plug-in Server
Dispatch User Request
HAL Send Request data
Creates User Request
TAPI
App Req
Plug-in
Core Object
Modem
Find the Core object
?
Dispatch User Request
Find the Plug-in
?
Core Object
function dispatcher
Enqueue Pending
26
Call Flows | Solicited Response sequence Communicator Modem
Interface Modem plug-in
Response data
Prepare and send the response
TAPI Modem
Send response to communicator
Pop pending request from the HAL queue
Emit pending response
Parse response Prepare UR response
Response Callback
Invoke Application callback for
async answer
Server
Noti / Resp?
27
Call Flows | Unsolicited Response sequence Communicator Modem
Interface Modem plug-in
Unsolicited result code
Prepare and send the notification
TAPI Modem
Dispatch notification
Emit unsolicited message
Invoke callback for
event
Server
Noti/ Resp?
Communicator
Invoke Hook functions
Invoke Notification Callback Registered by Core Objects
29
Porting Telephony | Implementing plug-ins ● All telephony plug-ins mandatorily need to provide a descriptor structure
● OEM vendors can customize each and every Telephony plug-in as per their needs.
● It is NOT mandatory that all the plug-ins need to be changed to support a specific hardware.
Descriptor Structure Descrip4on of structure elements struct tcore_plugin_define_desc { Structure referred by Telephony Server to load, iniFalize, and unload the Plug-‐in.
gchar *name; Name of Plug-‐in enum tcore_plugin_priority priority; IniFalizing priority of the Plug-‐in int version; Plug-‐in version gboolean (*load)(); Plug-‐in load funcFon reference gboolean (*init)(TcorePlugin *); Plug-‐in init funcFon reference void (*unload)(TcorePlugin *); Plug-‐in unload funcFon reference
};
30
Porting Telephony | Vendor plug-in requisites
● Modem Interface plug-in ● Establish connection to modem, additionally if required setup CMUX (either internal
or Kernel) ● Create HALs (Logical and/or Physical) ● Register new modem into server ● Assign Core Object types to HALs (logical or physical) and update Mapping Table
with the corresponding assignments ● Request Server to load modem specific Modem plug-in
● Modem plug-in ● Clone and initialize the Core Objects according the Mapping Table ● Override the operations and callbacks (if required) ● Start Telephony functionalities
Top Related