The Mobile Services component provides a set of high-level telephony services, obviating the requirement for application developers to have a deep knowledge of the Telephony library in order to perform primary operations such as managing calls and accessing network information.
Mobile Services also caches some information in order to reduce the number of actual calls made to the phone module by various applications. Mobile Services acts as a single client for the Telephony library, and as a centralized server component for applications.
Mobile Services Architecture
Individual services available through Mobile Services are accessible through one or more Mobile Contexts. A Mobile Context enables access to basic information about the network, operator, and phone, and its functions mainly manage phone calls (incoming, outgoing, and history) and provide call status. A Mobile Context is accessed through the Mobile service.
A Mobile Context may offer complementary services aside from simple call management. This is the case for the Cellular Mobile Context that also provides information about the physical underlying network.
The Mobile Services architecture is made of three parts:
- A client library, which provides an API to applications. This API abstracts the concrete implementation and is independent of the underlying technology. The set of exposed functions is split into one or more services. A Mobile Context may not offer all of them.
- A server that dispatches requests coming from various client applications to the concrete implementation. The server resides in a separate process.
- An inter-process communication mechanism (IPC) that makes the link between client applications and the server. It vehicles requests, responses and notifications across process boundaries.
An application uses Mobile Services to make requests. The Mobile Services server connects directly to the Telephony Manager, which connects to the Connection Manager. All application-level telephony requests can be handled through Mobile Services.
The following diagram shows how a Mobile Context, part of Mobile Services, fills a niche in the process between applications and the deeper middleware components.
Figure 1.1 Telephony Manager Process Diagram
See the Networking Guide for more information about the Connection Manager.
Mobile Services Features
Mobile Services exposes a set of C structures and functions that provide actual access to services, as well as callback function prototypes that must be implemented by applications in order to respond to notifications.
Asynchronous Functions
Each API call is synchronous in order to facilitate the development of applications based on this framework. The implementation on the server side must be fast enough to not block the application.
Some function calls can be expected to delay the application (e.g., obtaining network information). In order to not block the application, the function returns ALP_STATUS_MBL_VALUE_NOT_AVAILABLE, and the information is returned using the notification mechanism.
Applications can register to the Mobile Services to receive notifications. This mechanism is not a true notification, but rather a simple method to inform an application that a value has changed. Applications must use GLib to retrieve Mobile Services notifications. If a specified value changes or becomes available, all registered applications are called using the specified callback function. See "Receiving Notifications" for an example.
Memory Management
The Mobile Services APIs as a whole do not require manual memory management. However, if you allocate memory using structures or prototypes provided by the APIs, you must also free that memory. Simply provide the pointer reference to the function alp_mbl_free(). For an example, see "Getting Call History."
Bluetooth Headset/Handsfree Support
The Mobile Services server uses DBus to receive messages sent from the Bluetooth daemon to interoperate with Bluetooth components.
When an incoming call arrives, Mobile Services enables communication with any Bluetooth accessories connected in order to make it ring. Audio is handled through the Audio service ("Audio").
Caller ID Lookup
Mobile Services uses the Contacts Data Model API to query for the best match to a given phone number string. When a new call is detected (incoming or outgoing), Mobile Services requests information about the number using the Contacts Data Model API, and then sends a notification to applications when the information is available. Thus, the Contact DB lookup is performed only once.
The Notification Manager alerts Mobile Services to any changes in the Contacts Database change. Mobile Services can then update its call log database, which ensures that the information is always synchronized.
Exchange Requests
Mobile Services provides requests to the Exchange Manager. (For more information about the Exchange Manager, see the ACCESS Linux Programming Guide.)
There are two "verbs" supported by Mobile Services:
- 'released' verb
- When a call is released, the Mobile Services server creates an Exchange request with the verb "released" so that the application may notify the user. For example, the Phone application can display a dialog with the message "call ended".
- 'authenticated' verb
- Once authentication is successfully performed, the Mobile Services server creates an Exchange request with the verb
authenticatedso that the application may notify the user. For example, the Phone application can display a dialog with the messagePin/Puk verified.
The only MIME type supported with these requests is alp_exg_generic_phone_string (see alp/exgmgr.h)
The following table illustrates the parameters for each request.
Table 1.1 Mobile Services Exchange Requests
USIM/USAT Support
USIM
A Universal Subscriber Identity Module (USIM) is an application for UMTS mobile telephony running on a UICC smart card which is inserted in a 3G mobile phone. Although the terms UICC and USIM are often interchanged, UICC refers to the physical card, whereas USIM refers to the application residing in the UICC that stores user subscriber information, authentication information and provides with storage space for text messages.
Multiple USIMs: A single UICC is able to support one or more USIM in a UMTS environment. But a USIM is associated with one and only one home environment. This enables a user to change for example from UMTS to CDMA2000 when travelling.
So the UICC becomes a "multi-application" card in the highest sense of this term, meaning that it is not only carrying data and files for different application types, but can even contain and execute applications from different providers.
In Phase 1 it is only required to support one USIM application on the UICC.
Features
The USIM service may provide the following features:
- USIM Selection: In a multi-application environment (several USIMs are stored in the UICC), a flexible application selection method is required. The Application Identifier (AIDs), stored in the EFDIR file, should be used for application selection. At switch on, the last active USIM shall be automatically selected. The last active USIM shall be stored on the UICC. By default if there is no last active USIM defined in the UICC, the user shall be able to select the active USIM amongst those available on the UICC.
- MSISDN Selection: It shall be possible for several numbers to be associated with a single subscription on a single UICC (One IMSI but many MSISDN's).
- User Profile Selection: Each USIM contains at least one user profile. But in case of multiple user profile per USIM, a selection mechanism shall be provided.
- Elementary Files Access: An elementary data file on UICC is identified by its file identifier. Since valid elementary file identifiers may not be unique over all valid dedicated file identifiers, the path Id can be used to indicate the targeted UICC directory path in case of ambiguous files identifiers. It shall be possible to read a string of bytes from a transparent EF or to read one complete record in the linear fixed or cyclic EF.
USIM API
For USIM examples, see "USIM API".
USAT
The USIM Application Toolkit (USAT) is first a standardized execution environment for applications stored on the UICC. The USAT provides mechanisms which allow applications, existing in the UICC, to interact and operate with any Mobile Equipment supporting these specified mechanisms.
The USAT Service is therefore designed to enable the Terminal Equipment to support the mechanisms which are relevant of MMI control and application control (the mobile equipment deals directly with the other mechanism issued by the USAT application).
- The USAT service provides the means for USAT to interact with the user via the input (Keypad) and output devices (Display, Loudspeaker) of the terminal equipment.
- The USAT service provides also the means for USAT to utilize certain functions of the supporting terminal equipment: Phone pad, Net Browser, WAP and Bluetooth (?).
Supported mechanisms
The USAT service supports the following mechanism:
- The Profile download mechanism: Profile downloading provides a mechanism for the terminal to tell the UICC what it is capable of.
- The USAT proactive mechanism: It is a mechanism whereby the UICC can request specific actions to be taken by the terminal by issuing "proactive commands" (to control the MMI, to manage additional Menu, to setup a call, to setup an event list...).
- The USAT envelop mechanism: It is a mechanism whereby the terminal can inform the UICC about user choice (application menu item which has been selected by the user or Call Setup user confirmation) but also about monitored events that occurred.
Features
USAT features can be classified into different categories:
- Control of the Human-Machine Interface (DISPLAY TEXT, PLAY TONE, GET INPUT...): The USAT service shall provide the means for the USAT application to fully control the display of all actions and network-responses related to the operation of the application.
- Communication Control Services (SETUP CALL, OPEN CHANNEL, CALL CONTROL...): The Usat application can instruct the mobile equipment to initiate actions that will be sent to the network (CS bearer or local bearer). The Usat service shall provide the means for the user to accept or reject these actions.
- Menu Management and application control (SETUP MENU, MENU SELECTION...): The USAT service provides the user with additional user interface functionalities to control and invoke services (e.g. menus, icons, browser etc...).
USIM API
For USIM examples, see "USAT API".
