PSTFC FEUP – DEEC 2004

Ambient Networks Mobile phone integration

Carlos Rocha, Rui Botelho

i

Ambient network - Mobile phone integration

Supervisor professor: Prof. Manuel Alberto Pereira Ricardo Project supervisor: Prof. Mário Jorge Moreira Leitão Department: Department of Electrical and Computer Engineering Institutions:

Faculty of Engineering at University of Oporto

Institute of Engineering and Computer Systems of Oporto

ii

About the authors

Carlos Rocha

Carlos is a student at FEUP since 1999.

Carlos first experience on Symbian came with the acknowledgment of the project in the end of 2003. The work on this subject continues at the time of this writing.

Student number: 990503145 E-mail: carlos_emrocha@hotmail.com Telephone: 961818010

Rui Botelho

Rui is also student at FEUP since 1999.

As with Carlos, Rui Botelho heard about Symbian in late 2003 as it was a project proposal of Prof. Manuel Ricardo. Since then, this area has been one of his main interests.

Student number: 990503146 E-mail: rui_botelho@hotmail.com Telephone: 963379295

iii

We would like to thank Professor Manuel Pereira Ricardo for believing in this work and helping us to overcome the problems that we met along the semester.

We also would like to thank our colleagues, Filipe Abrantes, Ricardo Duarte and António Madureira for all the work done in the integration of our projects. A special thank you note goes to Filipe Sousa from INESC for all the help and support given.

iv

Contents

1. Introduction 1.1 Overview....................................................................................................1

1.2 Objectives ..................................................................................................2

1.3 Results .......................................................................................................3

1.4 Report structure .......................................................................................4

2. Symbian OS 2.1 Introduction to Symbian OS....................................................................6

2.1.1 Symbian History ..........................................................................6

2.1.2 Symbian OS Structure .................................................................7

2.1.3 Networking infrastructure............................................................10

2.2 Java programming for Symbian .............................................................12 2.2.1 Introduction..................................................................................12

2.2.2 Java and Symbian ........................................................................12

2.2.3 Programming essentials ...............................................................14

2.3 Symbian C++ programming....................................................................16 2.3.1 Getting started..............................................................................16

2.3.2 Development basics .....................................................................17

2.3.3 Applications structure ..................................................................18

2.3.4 Implementation Details................................................................21

2.4 Summary ...................................................................................................23

3. PC connectivity 3.1 Introduction ..............................................................................................24

3.2 Linux notes ................................................................................................25

3.3 Bluetooth connectivity under Linux .......................................................26

3.4 Summary ...................................................................................................27

4. Project description 4.1 Overview....................................................................................................28

4.2 Fundamentals............................................................................................30

4.3 Application structure ...............................................................................33

4.4 Networking ................................................................................................45

4.5 Results........................................................................................................50

4.6 Summary ...................................................................................................51

v

5. Project evaluation 5.1 Testing procedure .....................................................................................52

5.2 Test validation...........................................................................................54

6. Conclusion 6.1 Review of objectives and results..............................................................55 6.2 Main conclusions.......................................................................................55

6.3 Future work...............................................................................................56

Appendix A – Symbian’s History ............................................................ 57 Appendix B – How to create a Java application ...................................... 61 Appendix C – First approach to Symbian C++ programming................. 64 Appendix D – How to create a C++ application...................................... 65 Appendix E – Building an application..................................................... 66 Appendix F – How to create a simple installation file ............................ 69 Appendix G – The Communications Database classes ........................... 70 Appendix H – Using active objects ......................................................... 76 Appendix I – Sockets API ....................................................................... 79 Appendix J – Using Bluez tools .............................................................. 96

References ............................................................................................. 101

vi

Acronym list ACL – Asynchronous Connectionless packet

AVKON Series 60 extensions and modifications to Symbian’s Uikon and other parts of the Symbian OS Application Framework.

CBA - Command Button Area, i.e. toolbar

CDC – Connected Device Configuration

Defines a Java runtime environment for “high end” consumer devices with constrained hardware resources such as set top boxes, PDAs and Communicators. Falls under the J2ME umbrella.

CLDC – Connected Limited Device Configuration

Defines a Java runtime environment for devices with highly constrained hardware resources.

CommDb Communications database offered by Symbian. It provides access to extensible database which holds information about internet access, GPRS connections, WAP settings, proxy servers

DBMS – Database Management System

Defines a general relational database access API, and allows different database implementations to be provided.

DUN – Dial-Up Networking profile

FTP – File Transfer Profile

GAP – Generic Access Profile

GOEP – Generic Object Exchange (OBEX) Profile

GPRS – General Packet Radio Service

vii

GSM – Global System for Mobile Communications.

GSM is the world’s most widely-used digital mobile phone system.

HCI – Host Controller Interface

HTTP – HyperText Transfer Protocol

IDE – Integrated Development Environment

JABWT - Java API for Bluetooth Wireless Technology

An optional API that allows J2ME applications to access Bluetooth functionality.

JAD – Java Application Descriptor (file)

JAR – Java Archive (file).

Java Industry standard object-oriented language and virtual machine, invented by Sun Microsystems and formally released in 1996. Java is an ideal language for network applications and applets. Sun's Java specifications include many Java APIs and platforms, including the JavaPhone API and PersonalJava platform, which are included in Symbian OS.

J2ME – Java 2 Platform, Micro Edition.

The edition of the Java platform that is targeted at small, standalone or connectable consumer, and embedded devices. The J2ME technology consists of a virtual machine and a set of APIs suitable for tailored runtime environments for these devices. The J2ME technology has two primary kinds of components – configurations and profiles.

JavaPhone A Java API specification controlling contacts, power management, call control, and phonebook management, intended specifically for the programmability requirements of mobile phones.

JCP – Java Community Process

An open organisation of Java developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits.

viii

JSR – Java Specification Request

The process by which new Java specifications are defined. Part of the Java Community Process.

JTAPI – Java Telephony API

The Java Telephony API is an extensible API that offers an interface to all call control services (from those needed in a consumer device up to those of call centers). JTAPI is part of the JavaPhone API.

JTWI – Java Technology Wireless Initiative

An initiative to provide a roadmap of mobile phone related JSRs, indicating their availability in different markets around the world a specification describing the essential client components of an end-to-end wireless environment also to provide a Reference Implementation of the technology and a Technology Compatibility Kit.

JVM – Java Virtual Machine.

Kernel Core of an operating system, a kernel manages the machine’s hardware resources (including the processor and the memory), and provides and controls the way any other software component can access these resources. The kernel runs with a higher privilege than other programs (so-called user-mode programs). The power and robustness of an OS's kernel play a major role in shaping overall system design and reliability.

L2CAP – Logical Link Control and Adaptation Protocol

MIDlet An application written for the Mobile Information device profile (MIDP)

MIDP - Mobile Information Device Profile

Vertical extension of CLDC. Defines an API set for Mobile information devices such as cell phones.

MMA – Mobile Media API

An optional API providing a high level interface to sound and multimedia capabilities.

MMC – MultiMedia Card

ix

OBEX – Object Exchange protocol

A set of high-level protocols allowing objects such as vCard contact information and vCalendar schedule entries to be exchanged using either IrDA (IrOBEX) or Bluetooth.

OPP – Object Push Profile

OTA – Over-the-Air

Pairing Authentication Procedure for ensuring the identity of a Bluetooth device by using a link key.

PDA – Personal Digital Assistant

PersonalJava A Java platform optimized for the requirements and constraints of mobile devices.

Piconet – Bluetooth network

PC – Personal Computer

PPP – Point-to-Point Protocol

Proxy

An intermediary program, which acts as both a server and a client for the purpose of making requests on behalf of other clients.

RFCOMM – Protocol emulating RS-232

Scatternet – Network of multiple piconets

SCO – Synchronous Connection-Oriented packet

SDP – Service Discovery Protocol

SDK – Software Development Kit

A collection of tools used to develop applications.

x

SMS – Short Message Service

Service available on digital GSM networks allowing text messages of up to 160 characters to be sent and received via the network operator's message centre to a mobile phone, or from the Internet, using a so-called "SMS gateway" website. If the phone is powered off or out of range, messages are stored in the network and are delivered at the next opportunity.

SPP – Serial Port Profile

Symbian OS Symbian’s advanced open standard operating system for data enabled mobile phones. It includes a multi-tasking multithreaded core, a user interface framework, data services enablers, application engines and integrated PIM functionality and wireless communications.

UEI - Universal Emulator Interface

Interface enabling integration of emulators with tools such as the Wireless Toolkit.

UI – User Interface

UID – Unique Identifier

UMTS - Universal Mobile Telecommunications Service

A 3G standard supporting a theoretical data throughput of up to 2 Mbps.

WAP – Wireless Application Protocol

A set of communication protocol standards to make accessing online services from a mobile phone simple. WAP was conceived by four companies: Ericsson, Motorola, Nokia, and Unwired Planet (today called Phone.com). The WAP Forum is an industry association with over 200 members.

WINSCW Windows emulation platform for the Symbian OS (Metrowerks CodeWarrior)

WMA – Wireless Messaging API

An optional API providing access to wireless messaging resources including SMS.

xi

Figure List Figure 1 – Integration of a mobile phone in an AmI scenario ................................................1

Figure 2 – Symbian’s OS structure .........................................................................................7

Figure 3 – Networking architecture in Symbian OS ...............................................................10

Figure 4 – Multihoming concept .............................................................................................11

Figure 5 – Matching functionality to market needs and Symbian OS Java performance .......12

Figure 6 – Java2 platform........................................................................................................13

Figure 7 – MIDP 2.0 in Symbian OS v7.0s.............................................................................13

Figure 8 – KToolbar main window and Sun One Studio 4 ME..............................................14

Figure 9 – Series 60 MIDP Concept SDK Beta 0.3.1, Nokia edition and KToolbar settings menu. ........................................................................................................................................15

Figure 10 – Series 60 emulator running a GUI application and a console application ..........18

Figure 11 – Application launching sequence and user interface architecture .........................19

Figure 12 – Bluetooth protocol stack ......................................................................................25

Figure 13 – Mobile phone/PC Bluetooth connectivity............................................................26

Figure 14 - Mobile phone integration scenario .......................................................................28

Figure 15 – Service advertisement/request procedure ............................................................32

Figure 16 – View 1..................................................................................................................35

Figure 17 – Options menu 1 ....................................................................................................35

Figure 18 – View 9..................................................................................................................36

Figure 19 – View 2..................................................................................................................36

Figure 20 – Options menu 2 ....................................................................................................36

Figure 21 – View 6..................................................................................................................37

Figure 22 – Options menu 6 ....................................................................................................37

Figure 23 – View 8..................................................................................................................38

Figure 24 – Options menu 8 ....................................................................................................38

Figure 25 – MODEM_BEARER table information................................................................38

Figure 26 – View 5..................................................................................................................39

Figure 27 – Options menu 5 ....................................................................................................39

Figure 28 – Interface information ...........................................................................................39

Figure 29 – View 7..................................................................................................................40

Figure 30 – Options menu 7 ....................................................................................................40

Figure 31 – Route information ................................................................................................40

Figure 32 – Route introduction ...............................................................................................41

xii

Figure 33 – Options menu .......................................................................................................41

Figure 34 – Flow diagram of the SMS sending process..........................................................43

Figure 35 – Flow diagram of the picture service.....................................................................44

Figure 36 – Ipv6 network configuration..................................................................................49

Figure 37 – Views of a test application on emulator and Nokia 6600 ....................................52

Figure 38 – Internet connection sharing architecture..............................................................53

Figure 39 – Architecture used in the SMS service test phase. ................................................53

Figure 40 – Architecture used in the picture service test phase ..............................................54

Figure 41 - Flow diagram showing the life cycle of an active object .....................................77

Figure 42 – Lifecycle for data exchange using datagrams......................................................80

Figure 43 – Lifecycle for data exchange using streams ..........................................................81

Table list Table 1 – File constitution of a minimum GUI application ....................................................20

Table 2 – Main GUI systems...................................................................................................64

Table 3 – File types list............................................................................................................68

1

1. Introduction 1.1 Overview This project was born of the idea of having a simple cell phone, running Symbian OS, integrated in an Intelligent Ambient Network thus communicating, offering or using services of other devices belonging to the same ambient network. This new type of concept is called Ambient Intelligence, it characterises a system where its participants are able to adapt themselves to the medium, sensing, communicating and processing data. As this type of network is populated mainly by mobile devices, the communication between them is made essentially by wireless technologies like Bluetooth and Wireless LAN. A cell phone introduces new resources to the AmI Network like GPRS access offering more connectivity to AmI participants providing new type of services. In this case, the integration of the mobile phone in the AmI Network was made by having the phone offering services. Having a simple phone offering a SMS service, that allows an AmI component to send SMS messages and a picture service that takes advantage of the phone’s digital camera to provide a video stream, to be viewed in another device, are remarkable demonstrations of the AmI concept.

Figure 1 – Integration of a mobile phone in an AmI scenario

2

1.2 Objectives As this project is focused in a new operating system, it has specific objectives inherent to this fact. The main objectives are:

Study of Symbian Operating System

Symbian is an operating system that holds an important place in the mobile phone market, therefore, as a primary objective, stands the need to understand this new OS, to know its capabilities and limitations. The increasing importance of this OS justifies the need to have it as a project subject.

Study of Symbian’s main programming languages potential

The Symbian OS implementation has several programming languages. These languages have different characteristics, advantages, and difficulties. In order to assess its potential it is necessary to perform an evaluation of its API’s namely the Java and C++ APIs.

Testing and experimenting Symbian OS communication capabilities

One of the main features of this OS is its communication capabilities. This characteristic encourages the development of applications with multi connectivity features namely GPRS, GSM and Bluetooth.

IP connectivity over Bluetooth

This is the fundamental communication strategy of the smartphone in the Ambient Network. Due to its importance it’s desirable that this aspect is well explored, in order for it to act as the starting point to all kind of new functionalities and services. The use of IPv6 over Bluetooth is preferable.

Integration in ambient networks

As Symbian is a powerful operation system, and in order to confirm its excellent characteristics, a decisive test is to use them to allow the integration of a mobile phone in an ambient network that until now is a privilege of more complex devices like PDAs, laptops or personal computers.

3

1.3 Results This project achieved extremely motivating results for the consolidation of the Ambient Network concept, as the full integration of a mobile phone was achieved.

The main results of this project can be divided in two parts. The first one is concerned with the knowledge gained with the study of Symbian OS and the other one is the practical demonstration of the integration of the mobile phone in a network using the developed application.

As Symbian was an unknown OS, the first thing to do was the study of its capabilities and programming languages. The experimental development made with Java programming language and the evaluation of its APIs gave an overall idea of its capabilities, advantages and disadvantages. In the case of the native programming language, all the wok developed, study and implementation allowed a good acknowledgement of Symbian’s C++ programming. Although designed for the specific requirements of mobile phones this OS offers all the tools as others designed for more complex devices. Symbian includes a robust multi-tasking kernel, integrated telephony support, communications protocols, data management, advanced graphics support, a low-level graphical user interface framework and a variety of application engines. Symbian OS provides a rich core of application programming interfaces that crucial for development, particularly when using communication protocols.

Symbian’s communication capabilities were extensively tested, except in the case of Infrared technology, as it is of less interest. Multiple GPRS tests were made and total connectivity to a server was accomplished, proving the possibility of using this technology for integration purposes.

The basis for communication between the phone and other devices is the IP connectivity over Bluetooth. Using IPv6 over Bluetooth instead of over GPRS or GSM data is the main step for the integration of the mobile phone and therefore it’s one of the most important results.

The application developed achieves the full integration of a mobile phone in a network. The integration is done by providing services to other participants in the ambient network, in this case a SMS and a picture services. The SMS service allows other devices with IP connectivity to the phone to send SMS messages by using the GSM/GPRS network through the smartphone. The picture service gives the chance to use the onboard camera of the phone almost as a webcam.

Other features were added to the application because of its utility. Using the application, the user can see the interfaces, routes and the internet database setting to check important information very useful when setting up a network.

4

1.4 Report structure This report is arranged in sections that are composed by individual topics, each of which is arranged in subsections. Each section is dedicated to a topic that was subject of study of this project. The first section is an overview of the project work, the second section gives an introduction to Symbian OS and its programming languages and section three is dedicated to the connectivity between a Linux PC and the phone. The fourth section makes a description of the work developed in this area and the following section is dedicated to the validation of the project results. Finally the last section draws a conclusion of the project work.

The structure of this report is as follows:

Section 1 – this section. Introduction to the project work stating the overall idea as well as the main objectives and results.

Section 2 – provides a general introduction to Symbian OS and its main programming languages.

o Subsection 1 – in this section are stated important concepts and fundamental information related to Symbian OS architecture and technologies.

o Subsection 2 – in this part is made a resumed approach to Java technology and programming for Symbian OS.

o Subsection 3 – this section is dedicated to the native Symbian programming language. This is a complete resume of Symbian’s C++ programming. The section starts with an elementary overview of C++ for Symbian then follows a description of the development basics, Symbian’s application structure and networking fundamentals.

Section 3 – offers a guide for establishing PC connectivity with a Symbian mobile phone and a Linux PC using Bluetooth. This section describes the configurations of both Linux PC and mobile phone.

Section 4 – depicts the project description stating the work done over the project’s duration. It starts with an overview of the work, then is presented the project fundamentals and described the structure of the developed application. In the end is described the networking capabilities of the application and presented the project results.

Section 5 – project evaluation. This section describes the testing procedure of the developed application and its validation.

Section 6 – in this last part the project’s work and results are reviewed and future work is suggested.

Appendix A – Symbian’s History Appendix B – How to create a Java application Appendix C - First approach to Symbian C++ programming Appendix D – How to create a C++ application Appendix E – Building an application Appendix F – How to create a simple installation file Appendix G – The Communications Database classes

5

Appendix H – Using active objects Appendix I – Sockets API Appendix J – Using Bluez tools

6

2.1 Introduction to Symbian OS 2.1.1 Symbian History The desire to be contactable at any place at any time made the cell phone an indispensable gadget for the everyday use. Most of the people already take for granted the ability to make and receive calls from anywhere at any time, but only a few yet take advantage of instantly having access to any data at any time from that very same mobile phone. The growth of wireless computing belongs to the smartphone, a powerful device that extends the voice functionality of a mobile phone into the realm of data communications. The phenomenon of the mobile phones is quite impressive and now a new generation of powerful mobile phones equipped with amazingly sophisticated software rises, offering its users a vast group of services like the exchange of pictures, emails, etc. In just a few years a vast number of people will carry handsets with colour screens, cameras, music players, support for downloadable games, and other features that are now available only in the most advanced models. But these are only the first services because the so called smartphones possess advanced computing capabilities and have the ability to handle and host a number of applications, taking mobiles phones to a next level, letting them behave like small computers. The features presented by this devices such as GPRS, IR or Bluetooth controlled by a powerful OS assures that its users are "always best connected", with the phone always jumping in and out of the networks, contacting with other phones and larger computers, acting as organizers, mobile information portals, entertainment devices and clients to all kind of sophisticated data services and other compelling add-on software. All these features facilitates both simple capabilities like easily calling someone by highlighting the phone number in their email signature, to more advanced integrated and interactive messaging capabilities.

All of this is possible due to the software that lies in the core of these phones, the Symbian OS. Symbian is an advanced, open operating system licensed by the world's leading mobile phone manufacturers. It is designed for the specific requirements of advanced 2G, 2.5G and 3G mobile phones. The Symbian coalition started out with the goal of developing an open standard operating system for existing and next generation interactive multimedia devices called smartphones. Symbian OS turned out to be a full operating system in terms of functionality and compact enough to fit in the memory of a mobile phone. It includes a robust multi-tasking kernel, integrated telephony support, communications protocols, data management, advanced graphics support, a low-level user interface framework and a variety of application engines.

Symbian was established as a private independent company in 1998 with Psion contributing EPOC32, which was used on Psion Series 5 PDA’s. Initially Symbian was owned by Psion, Ericsson, Motorola, Nokia, Matsushita (Panasonic) but soon other manufacturers like Samsung and Siemens joined the group. The first platform release of Symbian OS was v5.0 which was used in the Psion Series 5mx and Psion Revo PDAs. The Nokia 9210 Communicator was the first device using Symbian OS 6.0 and the Nokia 7650 imaging phone is built on Symbian OS 6.1. The latest available version of Symbian, at this time, is version 7.0 but its successor, v8.0 is already prepared to equip Nokia 6630 which will soon be available.

The Symbian operating system provides a full C++ API and a Java Virtual Machine. In addition, Symbian OS provides a flexible user interface (UI) framework that enables mobile

7

phone manufacturers to differentiate their products and produce innovative UIs for families of mobile phones such as mobile phones with a numeric keypad, mobile phones with touch screens and mobile phones will full QWERTY keyboards and large colour screens.

2.1.2 Symbian OS Structure Symbian OS is constituted by a series of elements disposed in layers that combined together produce software that controls the mobile phones. The following picture provides a general overview of the operating system.

Figure 2 – Symbian’s OS structure

Symbian OS provides a rich core of application programming interfaces that are common to all Symbian OS phones. Key elements of Symbian OS in its 7.0 version are:

• Telephony The telephony subsystem provides a multimode API to its clients. This abstract cellular stack makes it easier for handset manufacturers to port Symbian OS from one mobile phone standard to another. The multimode telephony abstraction in Symbian OS is key to providing integration with the rest of the operating system and to enabling the creation of advanced data services. Supported global network standards include: GSM, GPRS, CDMA2000, EDGE (ECSD, EGPRS), WCDMA.

• Networking services This contains the key frameworks and system services for wide area network communications. It provides a framework for implementing various communication protocols through a socket interface. The following functionality is: TCP, IPv4, IPv6, IPSec, WAP stack, Multiple PDP contexts, Multihoming.

8

• Messaging The messaging framework provides support for messaging protocols for sending and receiving of text messages (SMS), enhanced messages (EMS), multimedia messages (MMS), email (including POP, SMTP and IMAP functionality) and fax messages.

• Multimedia The Multimedia Framework (MMF) provides a lightweight, multi-threaded framework for handling multimedia data. The framework provides audio recording and playback, audio streaming and image related functionality. Support is provided for video recording, playback and streaming and an onboard camera API providing a consistent interface to basic camera functions. The framework allows developers to write efficient and powerful plug-ins.

• Graphics It provides Symbian OS applications with shared access to the screen, keyboard and pointing devices input, bitmap fonts and scalable fonts. It also includes anti-aliasing support, direct screen access and 2D hardware Abstraction layer.

• Applications engine Core to any mobile phone is the handling of user data. Symbian OS provides highly optimised engines and API’s for agenda (schedule), to-do, contacts, spreadsheet, alarm and world servers and the help engine.

• Applications framework As Symbian OS is oriented to small handheld devices the user interface is extremely important, it has to be simple and easy to use, change and program. In addiction, different mobile phones have different device needs, so the applications framework subsystem provides a powerful environment for licensees and partners to create differentiated user interfaces while enabling applications written in C++ and Java, by Symbian, licensees, partners and third parties to run seamlessly on open Symbian OS phones. Currently, the core GUI components are Uikon (for pen based devices) and Standard Eikon. The UI Toolkit provides generic user interface tools used in development of user interfaces. The objective is to reduce the amount of effort required for UI development. When developing applications the main features of the GUI framework, among others, are: an event-driven GUI and widget architecture, a windowing system for sharing screen, keyboard and pointer between applications and a flexible screen indicator and status bar framework.

• PAN connectivity Personal Area Networking connectivity is available through support of Bluetooth, serial, USB, infrared (IrDA) and Ethernet devices. Bluetooth support is provided with a core Bluetooth 1.1 protocol stack along with full Generic Access Profile (GAP), Generic Object Exchange Profile (GOEP) and Serial Port Profile implementations. The Host Controller Interface (HCI) provides a hardware interface via a UART based reference implementation. The OBEX implementation provides an OBEX v1.2 client and server that operate over Bluetooth and IrDA. The OBEX server also provides USB support. USB class support is provided for the WMCDC WHCM and OBEX class, and for the CDC ACM class. All classes are controlled by a USB Manager component.

9

The infrared IrDA stack is contained in a socket server protocol module that implements the following IrDA layers: IrLAP v1.1, IrLMP v1.1 and IrTinyTP v1.1. The supported features are: infrared (SIR) supporting throughputs of 9.6 Kbit/s to 115.2 KBPS, IrOBEX v1.2, IrTRANP v1.0, IrCOMM v1.0.

• Base The Base subsystem provides the programming framework for all other components of Symbian OS. Base facilitates the design across multiple platforms and resources, making it easier to port Symbian OS to new types of hardware. The heart of the Symbian OS is the core operating system: a collection of device drivers, data tables, and programs that allows the user to work with computer’s hardware. Symbian OS is based on a small and efficient kernel that ensures robustness, performance and efficient power management – all important in mobile devices. Symbian OS is a 32-bit operating system, which presents an object-oriented design, supports multitasking and multithreading and runs native on ARM cores: ARM V4T, V5T and V5TJ. The main user visible elements are the file system and the common user libraries. The first one provides shared access to the filling systems the second provides the generic libraries and utilities required by Symbian OS components and third party applications. Some examples are: the cryptography library, power management framework, database engines, character encoding support, etc. The Base subsystem provides device drivers and/or software controllers for the following devices: DTE serial port, DCE serial port, Infrared (SIR), USB client 1.1, SDIO cards, Keyboard, Digitizer, Ethernet, MMC and LCD. Finally it also provides middleware widely used across Symbian OS like the C standard library and a relational database access API. The databases can be manipulated either through a subset of SQL or through a Symbian OS proprietary C++ API.

• PC connectivity Symbian OS provides a toolkit for creating PC connectivity application (such as Sync and backup services.) Each Symbian OS device manufacturer can create from these tools an appropriate connectivity solution for their device. The toolkit consists of a Connection Manager, to establish and control a link between PC and the device, and a PC toolkit to create application on the PC.

• Security The security subsystem enables data confidentiality, integrity and authentication by providing underlying support for secure communications protocols such as TLS/SSL, WTLS and IPSec. It also supports the authentication of installable software using digital signatures. This subsystem contains three elements: the Cryptography module (symmetric and asymmetric ciphers and hash functions), Cryptographic Framework module and the Certificate Management module (for authentication of other entities to the user of the phone, and for authentication of the phone user).

• Java Symbian OS provides a Java application execution environment, which is optimized for mobile devices and mobile applications, J2ME. The Java 2 Micro Edition framework is an implementation of the Java Virtual Machine as specified by Sun Microsystems for small handheld devices. This topic will be described later in detail due to its importance and extension.

10

2.1.3 Networking structure Due to the importance of networking and communications, these topics will be subjected to a more detailed description. Networking Services contain the key frameworks and system services for wide area network communications. It provides a framework for implementing various communication protocols through a socket interface. Networking support in Symbian OS includes: Transmission Control Protocol (TCP), User Datagram Protocol (UDP), IPv4/v6 stack, Internet Control Message Protocol (ICMP), Point to Point Protocol (PPP), Domain Name System (DNS), multihoming, multiple PDP contexts, dial up networking support, security protocols for secure electronic commerce: Transport Layer Security (TLS) and Secure Sockets Layer (SSL), IPSec, Telnet Protocol engine, File Transfer Protocol (FTP) engine and Ethernet support. The picture bellow shows Symbian’s networking architecture.

Figure 3 – Networking architecture in Symbian OS

An important feature implemented by Symbian OS 7.0 is an IPv6/IPv4 hybrid stack. This means that the stack does not contain separate implementations for each version of the protocol (dual stack), but functions internally as the IPv6 stack. It provides both IPv6 and IPv4 functionality and it is therefore called the IPv6/IPv4 hybrid stack. The internals of the stack do not limit or otherwise affect stack usage. When viewed from outside it contains a full implementation of both IPv6 and IPv4 protocol stacks.

Another feature is multihoming. Basically, a ‘multi-homed’ mobile device can support several network interfaces simultaneously. Symbian OS 7.0s provides multiple simultaneous OSI Level 2 datalink interfaces, each with its own unique IP address. Multiple IAPs can be active, and applications can specify which ones they will use. It allows connection to multiple GPRS and W-CDMA services simultaneously, like MMS, Internet, WAP; future devices to connect via several different access technologies simultaneously, like WLAN, CSD, W-CDMA,

11

Bluetooth; and provides access to services via Primary PDP contexts. Support also exists to allow applications to specify QoS parameters on GPRS/UMTS networks supporting Secondary PDP Contexts. A PDP context represents a connection between a mobile device and the service on the network. It has an access point name to identify the service and has its own IP address. The following picture illustrates the concept of multihoming.

Figure 4 – Multihoming concept

12

2.2. Java programming for Symbian 2.2.1 Introduction In this subsection we describe Symbian’s Java technology. It will be shown the evolution of Java on Symbian OS and how the Java platform may evolve in the future. A brief discussion of Symbian OS programming in Java will also be presented.

2.2.2 Java and Symbian The attractions of Java as a development environment were recognized very soon by Symbian, which made a key decision to provide a Java runtime environment to supplement the native C++ environment. As it would be expected, Java doesn’t offer all the answers but the opening between Java and native performance is closing down and Java functionality is being enhanced.

There are two main versions of Java in mobile phones, J2ME CLDC/MIDP and PersonalJava. A third version, JavaPhone, delivers a set of APIs that extend the PersonalJava runtime to access important native functionalities. Symbian OS v7.0s implementation provides MIDP, CLDC with Sun's CLDC Java virtual machine, Bluetooth, and Wireless Messaging. It also includes PersonalJava with the JavaPhone APIs. With PersonalJava and JavaPhone, mobile phones combine the complete power of Java with access to more specialized functionality.

Developers, network operators, and service providers benefit from the added value provided by Java on Symbian OS as Symbian’s Java implementation is robust. It is running on the Symbian OS kernel, which is itself designed to operate reliably. User data loss in Symbian OS phones is very rare, and system resets are hardly ever required

Figure 5 – Matching functionality to market needs and Symbian OS Java performance

13

The Java 2 Platform, Micro Edition is the Java platform for devices such as mobile phones, PDAs, TV set-top boxes and a large number of other devices providing a compact Java environment. Like its enterprise counterparts, the J2ME platform is a set of standard Java APIs defined by expert groups that include leading device manufacturers, software vendors and service providers. The J2ME platform delivers the power and benefits of Java technology for consumer and embedded devices, including a flexible user interface, robust security model, broad range of built-in network protocols, and support for networked and disconnected applications. With J2ME, applications are written once for a wide range of devices, are downloaded dynamically, and leverage each device's native capabilities; this by itself is a major advantage of J2ME.

Figure 6 – Java2 platform

The J2ME architecture defines configurations, profiles and optional packages as elements for building complete Java runtime environments consequently increasing the functionality available to MIDlets. Each combination is optimized for the memory, processing power, and I/O capabilities of a specific group of devices. Configurations are composed of a virtual machine and a minimal set of class libraries. They provide the base functionality for a particular range of devices that share similar characteristics, such as network connectivity and memory footprint. At the present, there are two J2ME configurations: the Connected Limited Device Configuration (CLDC), and the Connected Device Configuration (CDC). Mobile phones belong to the first configuration.

Figure 7 – MIDP 2.0 in Symbian OS v7.0s

14

2.2.3 Programming essentials Most of Java development process for Symbian is exactly the same as for other platforms. Although, if developing extensively for Symbian devices, using Symbian Emulator for development and testing, it's worth getting to know the details of how the environment works.

Java 2 Micro Edition Wireless Toolkit offers a complete development environment that complements the Emulator. In this toolkit it can be found KToolbar that is a minimal, easy-to-use development environment for developing MIDlet suites. From KToolbar, it is possible to create a new project or open an existing one; select the target platform and API set for a project; build, run, and debug a MIDlet; tune up (improve the efficiency and speed) a MIDlet by monitoring speed, memory allocation and transmissions; generate a stub connector to access J2ME Web Services; package project files and modify the attributes a MIDlet suite.

A KToolbar project can be imported straightforward from an IDE like Sun One Studio 4 ME to be edited, compiled and debugged.

Figure 8 – KToolbar main window and Sun One Studio 4 ME

A KToolbar project is associated with a MIDlet suite. The project contains the suite’s source, resource, and binary files, as well as the JAD and manifest files that contain the suite’s attributes. The J2ME Wireless Toolkit includes emulations of various example devices. They all support the MIDP, MMAPI, WMA, CLDC, J2ME Web Services, and Java Technology for the Wireless Industry specifications. Although KToolbar emulators are good enough for the majority of development, the decisive test before using the real device is to run the application in the Emulator from the SDK of the same platform as the target device.

15

Figure 9 – Series 60 MIDP Concept SDK Beta 0.3.1, Nokia edition and KToolbar settings menu.

In KToolbar settings menu it can be defined the set of APIs that are used for a MIDlet. The target platform may be JTWI – conforms to Java Technology for the Wireless Industry (JSR-185); MIDP1.0 or 2.0 – includes MIDP 1.0 or 2.0 and CLDC 1.0 or CDLC 1.1; Custom – user defined settings. For a MIDlet suite to operate, it might need to access certain protected APIs. A request for permission to access these APIs is required the MIDlet permissions from the Permissions panel of the Project Settings dialog box.

When the code is edited KToolbar compiles and pre verifies source code in one sequence. Once built an application, KToolbar can run it immediately. Debugging is possible from within the KToolbar by connecting to remote debugging facilities, such as an IDE debugger. Once the debugging is complete it’s possible to create a package for project files or create an obfuscated package that reduces the size of the Java byte code, resulting in a smaller JAR file. When MIDlets are packaged OTA can be emulated by choosing Run via OTA command from the KToolbar’s Project menu where it can be simulated the downloading and execution of an application from a web server.

See Appendix B for further details on Java programming for Symbian.

16

2.3. Symbian C++ programming

2.3.1 Getting started C++ is the native programming language of Symbian OS. Symbian uses its own implementation of the C++ language, optimized for small devices with memory limitations. Public C++ APIs allow developers to control the full capabilities of the platform and allow access to a variety of application engines, and to diverse technologies such as Bluetooth connectivity, graphics, Infrared, multimedia, messaging, networking, and telephony. All non-privileged system facilities are directly accessible via C++ APIs available in the C++ Software Development Kit that is freely distributed, providing the full power of the operating system to software developers. C++ offers the greatest access to the Symbian OS APIs, and being the primary language, the best performance in memory use and execution speed. C++ programming is required for certain types of programs like: Servers – background programs that typically manage a system resource, such as communications ports; Plug-ins – which extend a framework provided by Symbian OS, for example, a program that converts HTML files to Symbian OS Word documents, which plugs in to the Symbian OS Converter Architecture; Device drivers – programs that interact with the Kernel.

In order to start developing for Symbian platform is necessary to have the following components supplied on the Symbian OS Development Kit: Windows-based emulators – supporting C++ development with industry standard compilers, currently (i.e. for Symbian v7.0) Metrowerks CodeWarrior for Symbian Professional or Microsoft Visual C++ 6.0. Emulators also support Java application development with standard Java tools as well as vendor tools specially targeting Symbian OS; Header files and libraries – to support development for the emulators, and for ARM-based phones and development boards; GCC-based compiler – for building for ARM-based targets; Additional tools – for managing program building and deployment; Symbian OS source code – to help debugging and documentation for the operating system and tools.

The following sections point out the development basic concepts that are essential for starting with Symbian C++, the application’s main structure and some implementation details.

17

2.3.2 Development basics Development for a Symbian OS phone is PC-hosted, based on an emulator which provides a MS Windows-based implementation of Symbian OS. As the emulator-based process accurately impersonates a real phone, the main part of the development cycle is independent of real hardware being available. The development can be based on an IDE like MS Visual C++ 6.0 or Metrowerks CodeWarrior for Symbian Professional development toolset. However, instead of linking and building against Win32, developers link and build against the Symbian OS headers and libraries. The resulting binary is then run on the emulator. Builds can be debug or release but only on debug builds the debugging facilities of an IDE can be used.

The tools supplied with the SDK help to ease the development process. The starting point for every program is an environment-neutral mmp project file that can be used to generate specific project files for the chosen IDE and the GCC toolchain that is used to compile for ARM-targets. During development, the project file manages all linking and building details. It also ensures that all outputs from the build, and any required resources, including application resource files, icons, bitmaps, sound files, among others, are built into the appropriate location for debugging on the emulator.

Building can be performed from the Windows command line, from the Metrowerks CodeWarrior or from the Microsoft Visual C++ 6.0 IDE. For CodeWarrior the output of this is called a WINSCW build. Binaries built with this compiler are put in the epoc32\release\winscw and epoc32\winscw directory trees. For Microsoft Visual C++ the output of this is called a WINS build and its binaries are put in the epoc32\release\wins and epoc32\wins directory trees.

Once installed the SDK and an IDE, applications development can be started using the following model:

• edit the code using an IDE or a text editor; • using a supported compiler, compile the code for the emulator target • run the emulator and start the application by selecting it from the application launcher • debug, edit, recompile, and repeat the cycle until the code is thoroughly debugged and

runs on the emulator without problems • using the GCC-based compiler supplied with the Development Kit, recompile the

code, for the appropriate ARM target • upload the SIS installation file from the PC to a Symbian phone, and launch the

application on the device • test exhaustively the application on the device and , edit, recompile and repeat the

cycle until no bug is found.

Further details how to compile, create the SIS installation file or install the application on the real device are presented in appendix.

18

2.3.3 Applications structure There are two types of application in Symbian OS, console and GUI applications. Console application consists of a single executable file with a file name extension of .exe. In Symbian OS, such executables are used for two main purposes: as servers with no user interface or as test applications with very simple text based interfaces (as a command line).

Figure 10 – Series 60 emulator running a GUI application (on the left) and a console

application (on the right)

Typical sophisticated GUI applications make use of the application framework and user interface libraries. A GUI application on Symbian OS actually consists of four distinct components, each with a corresponding class. It is necessary to implement all this four classes, anything less than this won’t be a Symbian OS GUI application. The classes needed are:

1. The Application ‘shell’ itself. This is derived from CEikApplication and this class is instantiated first by the framework. Once created it has responsibility for initialising the rest of the code.

2. The Document. This is derived from CEikDocument. All applications have a CEikDocument-derived class and by default CEikDocument will create a default document file the first time an application is run. However, not all applications are file based. That is, they may not need to offer the user the ability to create, open, or edit documents. In such applications the instance of the document class is little more than a shell required by the framework to create an instance of the AppUI class and typically a model/engine instance. In file-based applications the document class also manages the saving and restoring of data from persistent storage.

19

3. The AppUI. The AppUI class is derived from the UIKON class CEikAppUi. This is the class, which provides major functionality to all applications such as event handling, control creation, access to several useful system calls, etc.

4. The View. This is what the user actually sees on screen. It can be used to simply display data or to collect data from the user in more complex applications. While all applications have one default view, the most complex ones can offer many views.

A visual representation of this process is as it is shown in the left part of figure 11:

Figure 11 – Application launching sequence and user interface architecture

Although a GUI application can be implemented in only one file with all the necessary classes, a minimum Symbian OS application normally has the constitution presented in the following table.

File Short description MyAppName.cpp

The DLL entry point.

MyAppNameApplication.cpp MyAppNameApplication.h

An Application that creates the new blank document and defines the application UID.

MyAppNameDocument.cpp MyAppNameDocument.h

A Document object that represents the data model and is used to construct the App UI.

MyAppNameAppUi.cpp MyAppNameAppUi.h

An Application User Interface (AppUi) object that handles the commands generated from menu options.

20

MyAppNameAppView.cpp MyAppNameAppView.h

An Application View object that displays data to the screen.

MyAppNameView.rss Describes the application's menus and string resources.

MyAppName.hrh

Contains definitions of some UI control enumerated constants that are used in source files and resource files. These constants are Command IDs, Key IDs or View IDs specific to an application. They may be used for key handling or for command handling in dialogs.

MyAppName.loc (not mandatory) Header file that is included in the .rss file containing user interface text strings etc. to make localization easier.

MyAppName.mmp The environment-neutral project file can be used to generate specific project files.

MyAppName.pkg The file which contains installation information for applications or files.

Bld.inf

A component description file which lists all the projects in a component and gives additional build instructions.

Table 1 – File constitution of a minimum GUI application

Resource files are fundamental to a GUI application they are used to define the way an application looks. Much of the information that defines the appearance, behaviour and functionality of an application is stored in this file. Individual resources are loaded very efficiently as required at runtime to minimise memory requirements. Application resources are compiled and compressed at build time into binary files (with .rsc extension) that are used at run-time.

See Appendix D and E for further details on creating these files.

21

2.3.4 Implementation Details

Due to the particular architecture of the Symbian OS there are certain details and patterns in the way the architecture is implemented. Certain techniques are used when implementing applications based in communication and networking. These techniques are shortly described below.

• Client-Server Relationships

Symbian OS uses kernel servers to protect and manage shared resources and services. They form a sort of gateway that processes must go through to access communication functionalities. To use a server, clients need to establish a connection to the desired server. The client-server relationship is facilitated by a socket. Servers listen to socket connections, and according to the resources available, accept or deny a connection. After the request and data exchange are done, the socket is closed. There are several servers in the communication infrastructure like serial communications servers, telephony servers, socket servers, communications database servers and other kinds of servers. This client-server relationship is the way computers interact for example in a TCP/IP network. Our special interest is in communication servers, socket servers and communications database servers. This last server is CommDb, the communications database server. This server is the central repository for information regarding configuration settings for devices and has a very important function. It provides access to an (extensible) database which holds information about internet access, connection preferences, GPRS connections, modems, locations, charge-cards, location information, WAP settings, and proxy servers. The database provides a single repository of communications related information which all communications type software components and applications can access. CommDb allows multiple clients to access concurrently the tables within the communications database. The locking mechanism of the underlying DBMS allows concurrent access by multiple clients while safeguarding the integrity of the database for changes. Later in this section the Communications Database will be detailed.

• Asynchronous Events Communications programming requires some waiting. As a client, an application might wait for a response from a server. As a server, an application would always be waiting for client requests. Because waiting is so obvious and frequent, the programming model will be asynchronous; it will be an event-driven programming. With this kind of implementation method the application will be more optimized and won’t stall while waiting for a connection or a response.

• Active Objects As stated before, the programming method is asynchronous. In order to accommodate the constant waiting imposed by the asynchronous nature of communications, Symbian OS

22

uses the concept of active objects. Basically an active object is a thread – a parallel object that executes alongside the main code – that makes communications requests and handles the event that is generated when the request gets a response. An active object enables more interaction with applications and a clean interface for handling situations that might arise during communication.

• The Communications Database

The communications database is a standard Symbian OS database, manipulated by the Symbian OS DBMS system. It provides system-wide storage for all information that should need to be referenced about components of the communication infrastructure. This information set includes data pertaining to phones, modems, protocols, and Internet service provision information (network access phone numbers, Internet addresses and physical locations). From a user’s point of view, this database is accessible through the Control Panel in Symbian OS user interface. From an application perspective, it is manipulated via the conventional Symbian OS API for relational databases or through a subset of SQL commands.

The communications database is structured as a standard Symbian OS relational database, managed through DBMS procedures. The information is held in several individual data tables in a single database. Each data table is manipulated by constructing a view of the table and working with its records through that view. There is a great number of tables and each of them is composed of several records, so the first thing to do in order to access the communications database is to know which table will be used, how it will accessed and what records will be manipulated. The tables contained in the communications database are listed in Appendix G. The standard way to access this structure is through the following steps:

• Create a new database object;

• Use this database object to create a view of a data table;

• Select a record – either by creating a new record or finding an existing one;

• Manipulate this record – read from or write to it as needed;

• Commit any changes made to the record;

• When completed, delete the view and database objects.

• Routes and interfaces

In order to communicate with a remote host through a socket, a protocol must establish the IP address and port of the socket, a route to the remote host and a network interface by which to access that route. When a connection is attempted, either by the Connect() function for TCP sockets or using the functions Send(), Write() or SendTo() for UDP sockets, Symbian OS follows this standard steps in order to accomplish what was said before:

23

1. The IP routing table is checked to see if a route to the destination exists. If there is no route (including no default route), then the protocol attempts to invoke its default dial-up interface.

2. If dial-up is successful, PPP is invoked to establish a connection to the remote peer. 3. In its set-up stage, PPP obtains a local IP address from the remote peer (if so configured) and is informed of the peer’s IP address.

4. When TCP/IP is informed that the interface is up, it adds routing entries for the interface. Normally this means that the remote peer becomes the default gateway.

5. If a local address has not been set by Bind(), then the protocol sets the socket’s local address to that obtained in step 3 (which is recorded in the route entry created in step 4), and allocates an ephemeral port number. This process is called automatic binding.

2.4 Summary In this section it was presented an overall view about Symbian and its programming languages. After presenting some aspects of the history of this operating system, it was explained how Symbian is structured and described the main protocols and technologies available in this OS. Sub-section two illustrated how Java programming language is implemented in Symbian, presented its main advantages and some essential programming concepts. Symbian’s native programming language was also subject of study. This time with more detail, it were described the basic concepts of C++ for Symbian, the application’s structure and implementation aspects. The explanation of the basic structure of a Symbian’s applications (graphical and non-graphical), focused on the fundamental files that compose them and several aspects about the application launching sequence and user interface architecture. The last topic discussed, consisted in a simple overview of how Symbian implements some communication and networking characteristics, exploring aspects like the client-server relationship, active objects, and the communications database.

24

3. PC connectivity 3.1 Introduction A Symbian OS phone can have a good quality communication aptitude depending of the number of technologies available. It can have Infrared, Bluetooth, GPRS, GSM and USB connectivity. To these may be added a very simple strategy if the phone has a memory card, that is taking it out of the phone and putting it in a USB memory card reader. Wireless PC connectivity can be achieved by Infrared but it’s Bluetooth that offers the best characteristics. Bluetooth is a WLAN technology that is oriented to ad-hoc networks of low cost and short range. Its typical range is 10 metres and has a shared data rate of 1 Mbit/s while Infrared has a limited range of two metres in line-of-sight and limited number of two participants. Bluetooth allows the creation of the so called piconets, a type of small ad-hoc networks.

Bluetooth connectivity allows a multiplicity of uses for the mobile phone capabilities from both PC and phone. A common application is the use of GPRS to give internet access to the PC, in this case the phone will act as a modem; this is relatively simple and there's more than enough documentation on this subject. Once established a modem connection between the phone and the Linux box, it’s possible to use PPP to establish the connection to an ISP just as for a real modem. Another application used frequently is file transfer or beaming as it’s also known. This solution is normally used for the purposes of backup/restore and synchronization, but can also be used in a more generic sense. Under MS Windows, the software bundled with the phone or with the Bluetooth dongle is very easy to use, with Linux this is also possible.

IP connectivity over Bluetooth to a PC, from a mobile phone, is a subject that is not well documented as it is not of interest for the service providers. Getting an IP address on the phone and other one on the BT interface of the PC allows the phone to get, among other things, internet access; this avoids the use of GPRS/GSM, which can be expensive. Needless to say, this will only work if the phone is within range of a computer with Bluetooth support. The PC connectivity software for Windows, bundled with a Symbian phone creates a TCP/IP connection between the phone and the computer over the Bluetooth serial link but it’s out of question working on MS Windows as it doesn’t have an official and documented Bluetooth stack. Although no dedicated software exists for Linux it’s possible to enable this functionality. Being so, it’s necessary to enable the connectivity by configuring both Linux PC and mobile phone.

A common mistake is to think that when the phone is acting as a GPRS modem it has IP connectivity in both GPRS and Bluetooth links. As a matter of fact, when acting as a modem, the phone isn't ‘talking’ PPP itself - the PPP session is between the computer and the ISP, and the phone acts as a simple modem. To have IP on a LAN, the phone itself must ‘talk’ PPP to its host computer. When the PPP channel is established, all it gives is a ‘tunnel’ between phone and the host PC, with an IP number at each end. What gets sent down the tunnel is up to the applications at each end. An interesting thing is that some applications will use the PPP channel for networking, rather than the GPRS or GSM as long as PPP is up. This fact led to think on developing an application that worked on this great feature.

25

3.2 Linux notes There are several implementations of the Bluetooth stack for Linux kernel like Affix and BlueZ. The tool that seems to be more reliable is BlueZ, the official Linux Bluetooth stack, as it has plenty of documentation and its use is far more common. BlueZ consists of a number of kernel modules that provide basic Bluetooth stack support for the HCI and L2CAP layers of the Bluetooth protocol stack. The user side tools include control programs like hciconfig and dund, system daemons provide RFCOMM and SDP support, and libraries which contain common functions and convenience wrappers. Due to its growing importance and stability, BlueZ was merged into Linux kernel from version 2.4.5 onward. In order to get Bluetooth working, the kernel has to be recompiled and to avoid problems, a recent stable kernel version is the best option. See Appendix J for further details on setting up Bluetooth support on Linux.

Figure 12 – Bluetooth protocol stack

The most important Bluetooth layer used in this project is RFCOMM. RFCOMM basically emulates an RS-232 serial line. To the upper layers of the existing protocols it presents an interface that looks exactly like an RS-232 connection link so it allows an application to treat a Bluetooth link in a way similar to communicating over a serial port. It also interfaces with the L2CAP layer and implements a point-to-point transport method. BlueZ RFCOMM provides serial emulation over Bluetooth that lets serial port protocols like Point-to-Point Protocol (PPP) run unchanged over Bluetooth.

Dund is a tool that is used for dial-up connections. In the case of LAN interaction from a Symbian phone, dund is used to accept incoming PPP session requests in a particular RFComm channel. Dund will then use pppd to establish a connection with the smartphone.

PPP in the Bluetooth technology is designed to run over RFCOMM to accomplish point-to-point connections. PPP is a packet-oriented protocol and must therefore use its serial mechanisms to convert the packet data stream into a serial data stream. PPP is composed of three parts: a method for encapsulating datagrams over serial links, an extensible Link Control Protocol (LCP), and a family of Network Control Protocols (NCP) for establishing and

26

configuring different network- layer protocols. The encapsulation scheme is provided by driver code in the kernel. pppd provides the basic LCP, authentication support, and an NCP for establishing and configuring the Internet Protocol (IP) (called the IP Control Protocol, IPCP).

The first thing pppd does after being called by dund, is to negotiate several link characteristics with the remote end using LCP. Then it will negotiate the IP parameters with its peer using IPCP, the IP control protocol. Both will then announce their addresses to each other. After going through the IPCP setup phase, pppd will prepare the PC’s networking layer to use the PPP link. It first configures the PPP network interface as a point-to-point link, using ppp0 for the first PPP link that is active, ppp1 for the second, and so on. When interacting with a smartphone, it sets up a routing table entry that leads to the phone’s end and then to the attribution of IP addresses in both ends.

3.3 Bluetooth connectivity under Linux As it was stated previously, in order to get IP connectivity between a Linux PC and a Symbian phone it is necessary to perform some operations in both devices. There are some difficulties with using PPP to get LAN access from a Symbian phone coming from both Linux PC and smartphone.

A Symbian phone like Nokia 6600 will not accept incoming requests to initiate a PPP session because it expects to initiate the session itself. If the connection starts from the host computer it attempts to initiate a PPP session on the phone’s virtual serial line. To do this it must bind an RFCOMM device to the right channel and then use it as the port for a pppd call. When the PPP session is established, it is closed immediately by the phone. The phone then does an SDP query to find the channel number of the SP (serial port) profile on the computer. It will only find one if it has been explicitly added to the computer's SDP daemon using, e.g., the Bluez sdptool. Having got the channel number of serial port service, the phone then initiates a PPP session on it and for this to work, it’s necessary to have something listening on the appropriate RFCOMM channel on the host computer. As said previously this can be done with the dund daemon. Once the PPP session is set up, the phone immediately attempts to find the IP number of a router (gateway). This operation must succeed, or the phone will drop the connection. After the PPP session is established, it should then be possible to ‘talk’ TCP/IP between the phone and the Linux box. If, on the other hand, there is an application that starts the connection process by attempting to connect to a host whose address is not in the routing table of the smartphone the phone calls the computer directly and asks it to set up a session.

Figure 13 – Mobile phone/PC Bluetooth connectivity

27

In order to set up the Symbian OS device, it is needed to manipulate the CommDb on the Symbian OS device which holds information relating to phone and modem settings. Specifically it’s necessary to set an empty ISP dial string. This will force a direct PPP connection over the designated virtual serial port which for Bluetooth will correspond to BTCOMM::0 on Symbian OS. It used to be possible to do this manually on the Psion 5 and Revo devices using the Modem control panel applet but this functionality has been obfuscated in Symbian OS 6.0 and beyond. For Symbian OS 6.1 there is an application called Gnubox licensed under GPL that offers some pointers as to how to proceed programmatically. Gnubox turns a 1-box phone into a 2-box that can be used with Linux providing IP connectivity to the phone over Bluetooth (and infrared) through Linux. For Symbian 7.0 there are a few differences. They consist in different record and table names, especially the MODEM table that now has become MODEM_BEARER.

After having IP connectivity and explored the rich functionalities of Symbian OS, a great number of applications can be done to demonstrate the concept of ambient networks like the one developed in this project.

3.4 Summary This section was dedicated to connectivity issues related to Linux PC and Symbian phone. Due to the amount of information presented, it will be showed a re-examination of the most important notions depicted in the section. In the introduction, an overall view of the technologies available to provide connectivity to a PC was presented. It was also made a brief explanation of the different applications of the Bluetooth technology related with PC-phone connectivity. In the Linux notes subsection it was introduced BlueZ and some essential concepts and tools for the Linux Bluetooth communication support. BlueZ provides some of those tools like RFCOMM, dund, and sdptool that combined with the pppd allow the IP connectivity over Bluetooth. The tools interact with each other in this way: sdptool is executed to define a specific channel number for the serial port profile. After that, dund will accept incoming PPP session requests in a particular RFCOMM channel and use pppd to establish the IP connectivity over Bluetooth. Finally, it was presented a short review of the IP connectivity process over Bluetooth between Linux PC and Symbian phone stating both PC and phone configurations needed for establishing a successful IP connection link. Besides the Linux configuration (tools and initialization) referred before, the smartphone needs to update its communications database tables DIAL_OUT_ISP and MODEM_BEARER assigning a Null descriptor into the ISP number and designate BTCOMM::0 to the serial port.

28

4. Project description

4.1 Overview The mobile phone is itself the best example of mobility while maintaining connectivity. As a result of this, it is only a question of time until this device achieves the communication ability of a Laptop or a PDA that already can use GPRS, Infrared and Bluetooth in its full power. This project represents a new step towards the full connectivity of the mobile phones in a local network as it aims to the IP connectivity of the smartphones.

The idea of having IP connectivity to a surrounding environment was, from the first instant, the main step into the integration of the Symbian mobile phone in an ambient network. With IP connectivity the mobile phone can be viewed like any other member of the LAN. The major disadvantage of this device is without doubt the limited processing power and memory to enable more complex applications and also its user interface in the case of the simpler phones with no touchscreen and no QWERTY keyboard. The operating system is not, as stated previously, a limiting issue as it is a powerful OS capable of being used in more complex devices.

Having the IP link enabled it is then only a matter of choosing a set of applications for the demonstration of this new concept of mobile phone integration in ambient networks. In our case the integration is made by offering services to the other participants in the local network. The other devices in the network can be PDAs, Laptops or even personal computers in the neighbourhood of the phone. These devices can offer and use services that require resources that a mobile phone can’t have but any service offered by the phone can easily be used by a more powerful device. Although, simple applications can be designed in order to demonstrate the use of ambient services by the phone.

The scenario chosen for the demonstration of this concept consists in a network constituted by the mobile phone, PDAs and PCs. The PDAs and PCs create an ambient network in which the smartphone will be integrated. This network is the result of another project that demonstrates the concept of ambient intelligence. The services offered by the phone will be used by these elements that also have services of its own. The architecture the global scenario is shown in the following picture.

Figure 14 - Mobile phone integration scenario

29

Figure 14 shows the mobile phone integrated in the ambient network and offering services to the other participants. On its turn, these participants have a set of services like the recording and display service.

The integration stated is supported by predefined protocols that enable the proper communication between elements. This is the only prerequisite needed to the correct articulation of the data exchange.

One of the intrinsic characteristics of this type of network is that services may disappear as easily as they can appear. The Bluetooth communication link is limited to ten metres and as a participant steps away of the range of the network it automatically looses the services offered by the network and the network looses the services that the missing participant was offering. This reality brings up two more concepts: service discovery and service advertisement. When offering a service a device must send a message from time to time to the network stating the services offered by it. The other participants can now listen for the advertisement of the arrived participant and build a database with the existing services at the time, hence performing service discovery. Whenever the network looses contact with a device it will stop receiving the advertisement from the missing device and so, after a predefined time equal to the frequency of the advertisement messages, the remaining devices remove from the database the entries corresponding to the lost services. This procedure allows an efficient update of the network constitution.

To demonstrate the concept it was developed an application that turns a mobile phone into a fully fledged fully member of a LAN. This application was built upon Symbian C++ programming language and more specifically to the Symbian 7.0 platform that equips the Nokia 6600 smartphone. The application, among other things configures the phone to allow IP connectivity over Bluetooth, advertises the services and runs the servers of the services implemented. Additional features were introduced like routing information views, interface information and CommDb settings.

The services offered by the mobile phone are: a SMS service and a picture service. SMS adds another communication capability to the network. The SMS service allows any device with IP connectivity with the phone and running the SMS client program to send this type of messages. The server running inside the application handles the requests and executes them without the phone user being alerted. Needless to say, this service brings out costs to the phone’s owner. Another feature of this service is that it can recognize a SMS message and, without the user knowing, pass the message contents to the network. The message has to be constituted by determined header and content. The server and client programs must be running on both phone and client device respectively.

The picture service is a clever usage of the phone’s resources in favour of the network participants. The server program of this service takes pictures on demand of the client program and transfers the resulting JPEG file to the IP address of the client device. This procedure, when repeated results in a type of video streaming with a nice visual impact. The processing limitations of the phone don’t allow the maintaining of a high frequency rate but a minimum of one picture in each second is enough to get a good look of what’s going on. This service enabled the Nokia 6600 used in this project to act like a webcam and like a pre UMTS 3rd generation phone if it used with another phone in the same circumstances (i.e. with IP connectivity to a PC or PDA with internet connection) while maintaining a phone call.

As said previously, another feature of the application developed is the ability of see the interfaces and routes present at each moment. This functionality allows the user to have access to information that he normally wouldn’t have. This facility is extremely helpful.

30

4.2 Fundamentals As it was shown in the previous subsection, the application developed uses mainly GPRS/GSM and Bluetooth interfaces. GSM/GPRS is used to send/receive the SMS messages and Bluetooth maintains the IP connectivity to the ambient network. The usage of these interfaces is independent as the application handles both at the same time

The IP connectivity over Bluetooth is the fundamental basis of this work. As it was stated earlier, both phone and Linux PC have to be configured. On the PC side it was necessary to recompile the kernel to support Bluetooth and all the necessary tools had to be correctly configured. Although well documented, the configuration of the PC isn’t straightforward requiring a great deal of patience and some time. The networking subsection describes the process.

On the smartphone side, the internet settings database had to be altered to allow the usage of the IP protocol over Bluetooth. These changes are made, if necessary, when the application starts. The alterations on CommDb don’t have secondary effects and once made they remain even after rebooting the phone. The programming details of these changes are explained in the next subsection.

In order to accomplish the integration through the use of the services offered by the phone to the other devices it is necessary to create a protocol common to every participant in the network. This protocol will allow the correct articulation and comprehension of the advertisement or request messages exchanged between the devices. For each service there is one server and one client programs, both using the same protocol. A device that wishes to use a particular service must, first of all, comply with the protocol to be able to understand messages received by it and be understood by the other elements. Consequently, this device must already be running a server program that communicates using this protocol.

Service advertisement messages are in a XML format which is a structured language particularly good for this purpose. The first step when entering the network is to start sending announcement messages to advertise the presence of the new device. The protocol used defines a message like this: provider name provider ip address This message is send using UDP to a predefined port number. UDP allows sending these messages without any confirmation as it is desired. If any device is listening in the right port number, it will receive this message and so it will identify a new participant. As a new device can represent new services, the listening device will send a request to the arrived one in order to be informed of the services, if any, provided by it. The request message is sent, now over TCP/IP, to the provider’s IP address in the same port: The service provider program running on the phone, when recognising the request, immediately sends the XML description of the services it is offering at that moment. With this description, the devices that performed the inquiry can be acquainted with the new services. The XML description has the following structure:

31

name of the service port number

name of the client program %i %p localization of the executable

In the specific case of the services presented by the mobile phone, the XML description is:

SMS 6010

smsclient %i %p http://www.fe.up.pt/~ee99145/services/sms.exe

PIC 6011

stream %i %p %1 http://www.fe.up.pt/~ee99145/services/pic.exe

This description can be altered by the phone’s user by selecting/deselecting the correspondent service on the service offer menu in the application. According to the services selected the XML is changed to describe only the services running at the moment.

After receiving and decoding the previous description, the inquiring device adds a new entry to its database, meaning that new services have been found. Right after this the new services are shown to the user in order to allow its use. As it can be viewed in the XML above, the description contains a field with an URL where the executable client is located; with this approach any device with internet access and using the same XML protocol can use a service by downlo