Get documents about "Port ONEPP from J2ME CLDC to J2ME CDC
Document Sample
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Port ONEPP from J2ME CLDC to J2ME CDC
by
Zheng Xianghan
Supervisor: Andreas Haber, Frank Reichert, Martin Gerdes
Project report for IKT 502 in Autumn 2006
based on report template version 3.0 (2006)
Agder University College
Faculty of Engineering and Science
Grimstad, 5 December 2006
Status: Final
Keywords: ONE Portable Player, UPnP, IMS, CLDC, CDC, Apache Derby, Symbian
Abstract:
Together, Ericsson and HiA are studying the role of WiFi-enabled mobile phones in residential
and outside networks. This article describes the Porting task of ONE Portable Player from J2ME
CLDC to J2ME CDC, including AV Control Point, AV Media Server, AV Media Renderer. “4+1”
view architecture diagram and some UML class diagrams are used to describe the architecture
and component of the J2ME CDC version of ONEPP.
This work is licensed under the Creative Commons Attribution-ShareAlike License (http://creativecommons.org/licenses/by-sa/2.5/).
3.0 1 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Version Control
Version1 Status2 Date3 Change4 Author5
1.0 draft 02,12 First version Zheng
2.0 review 04,12 Revise some discussion part Zheng
3.0 final 05.12 Revise some English error Zheng
1 Version indicates the version number starting at 0.1 for the first draft and 1.0 for the first review version.
2 Status is DRAFT, REVIEW or FINAL
3 Date is given in ISO format: yyyy-mm-dd
4 Change describes the changes carried out since the previous version
5 Author is the one who did the change
3.0 2 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Table of Contents
1 Introduction...................................................................................................................4
1.1 ONE project.............................................................................................................4
1.2 Process of ONE Project...........................................................................................4
1.3 Motivation ................................................................................................................4
1.3 Layout of the report ..................................................................................................5
2 Problem description......................................................................................................6
3 Background ..................................................................................................................7
3.1 4 + 1 view architecture model ..................................................................................7
3.2 CDC + PP Environment...........................................................................................7
3.3 Apache Derby..........................................................................................................8
3.4 SonyEricsson P990i.................................................................................................9
4 Design ........................................................................................................................10
4.1 Logical view ...........................................................................................................10
4.2 Process view .........................................................................................................11
4.3 Development view .................................................................................................12
4.4 Physical view.........................................................................................................14
4.5 Use case ...............................................................................................................14
5 Testing........................................................................................................................16
5.1 Test tools ...............................................................................................................16
5.2 Function Test.........................................................................................................16
6 Discussion ..................................................................................................................20
7 Conclusion..................................................................................................................21
Appendices..........................................................................................................................22
Appendix 1 Glossary & Abbreviations .........................................................................22
Appendix 2 References...............................................................................................22
3.0 3 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
1 Introduction
1.1 ONE project
Universal Plug & Play (UPnP) technology [1] is an uprising technology aiming to make home
networking simple and affordable for users so the connected home experience becomes a
mainstream experience for users and great opportunity for industry. As one of the most important
technology of Digital Living Network Alliance (DLNA), UPnP protocol would play an important role
in future home network.
Wi-Fi [2] is a brand originally licensed by the Wi-Fi Alliance to describe the underlying technology
of wireless local area networks (WLAN) based on the IEEE 802.11 specifications. Today, Wi-Fi
has been widely used for mobile computing devices, such as laptops, in LANs, and also some
advanced mobile phones. It is expected that in 2010, WiFi in mobile phones will be as common
as Bluetooth and IrDA technologies are today.
The IP Multimedia Subsystem standard, as an international, recognized standard specified by the
Third Generation Partnership Project (3GPP/3GPP2), defines a generic architecture for offering
Vice over IP (VoIP) and multimedia services. This standard, which supports multiple access
types – including GSM, WCDMA, CDMA 2000, TD-SCDMA, Wire line broadband access and
WLAN, has been regarded as one of the most advanced and promising technology in 3G and
future 3.5G and 4G era.
ONE project, lead by Prof. Frank Reichert in Agder Mobility Lab (AML), is aiming to study the role
of the UPnP, Wi-Fi, and IMS in future mobile phone. ONE project is supported by Ericsson from
2005-2009.
1.2 Process of ONE Project
ONE Portable Player is a midlet implementing UPnP AV functionality. It contains three
subsystems [3]:
Control point: Controls Media Servers and Media Renderer. This allows the users to play
media discovered on one media server on a media renderer.
Media Server: Media server provide some functionality to share the media on the local
network. Currently, it supports these file types: MP3 (.mp3), JPEG (.jpg).
Media Renderer: Media Renderer render media from media servers in the local network.
We have built the J2ME MIDP version of ONE Portable Play from Seq.2005 to June.2006. The
application is running stable in Qtek 9100, with Window mobile system.
1.3 Motivation
However, one shortcoming about multicast was found in our development: J2ME CLDC does
allow an application to send out multicast data such as SSDP SEARCH request, while loses the
support to receive multicast data from outside network, such as SSDP NOTIFY. In short, J2ME
CLDC could only support half multicast functionality.
Full Multicast support is highly important in the next step of ONE project, in which UPnP, WiFi,
and IMS technology are tried to integrated together. In the plan of Ericsson and AML, mobile
phones should have the ability to receive the multicast request from outside and make the
corresponding response. Not until this serious problem has been solved, ONE project could
move to its next step development.
3.0 4 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Also, Ericsson Service Development Studio (SDS), which is based on the Eclipse Integrated
Development Environment (IDE), will be published late this year. This set of IMS tools will
provide great convenience for IMS service creation, IMS service exploration, and IMS service
testing, all of which are the important task in the next step of ONE project. Unfortunately, these
IMS tools could not support J2ME CLDC.
In order to make the integration of UPnP, WiFi and IMS possible, We decides to port ONE
Portable Player to J2ME CDC version, which should have the ability to support multicast and
SDS in theoretically. So, this project comes.
1.3 Layout of the report
In this report, I will use “4+1” view model of software architecture and some UML class diagrams
to present the architecture and the structure of J2ME CDC version ONE Portable Player. In the
second part, I will focus one the problem description of this project; then there will be the
background in the third part, introducing the related technology and products in the project; in the
fourth part, I will specify the architecture and some components structure of CDC version ONEPP;
the fifth part is the test part of ONEPP, showing the function test result. The sixth part and
seventh part are the discussion and the conclusion.
3.0 5 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
2 Problem description
In the technical part, this project could be spitted into five parts, listed as below:
Network management
Due to the difference library between J2ME CLDC and J2ME CDC in network management,
it is necessary to replace the some of the CLDC network libraries to CDC supported libraries.
Fortunately, CDC support most of the CLDC network libraries, such as HttpConnection
class, Datagram class and so on.
File management
In CLDC version of ONE Portable Player, we save the Device and Service description into
J2ME RMS, a small J2ME database, which is not supported by J2ME CDC. Finally, we
decided to use jsr 075 to manage the device and service description and save into the
memory in the mobile phone.
Database management
Also, due to lack of the RMS support in J2ME CDC, it is necessary to find a solution to
manage the media content. Since the media content information that media server manages
could be dynamically changed, it is not trivial to use the way as File management part to
write into the static file inside the mobile phone memory. After some thinking, we decided to
try to use Apache Derby, a relational database to solve this problem. Apache Derby supports
J2ME database solutions.
Multicast support management
This part is the most important part of this project added. CDC version of ONE Portable
Player should support all the multicast request and response from the outside. For example,
ONE Portable Player should support mainly two kinds of multicast: Notify multicast, Multicast
SEARCH and so on. For each kind of multicast type, corresponding response should be
produced.
Deployment into the mobile Phone
Some technical features should be considered when selecting a mobile phone: Does this
phone support all the Java API needed? Does this phone support Wi-Fi? Does this phone
easy to get? Would some potential problem show up when deploying the ONEPP application
into this phone?
Another problem that should be solved in the beginning of the project is the psychotically
uncertainty. Although the entire plan made by Ericsson and AML is technical available and
reasonable in theoretically, this is not proved by implementation. Besides, it is not trivial to read
about 500KB J2ME CLDC code and understand the details in each class.
3.0 6 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
3 Background
3.1 4 + 1 view architecture model
Software [4] architecture deals with abstraction, with decomposition and composition, with style
and aesthetics. To describe software architecture, it is possible to use a model composed of
multiple views or perspectives. The model is made up of five main views [4]:
The Logical view, which is the object model of the design (when an object-oriented design
method is used );
The process view, which captures the concurrency and synchronization aspects of the
design;
The physical view, which describes the mapping(s) of the software onto the hardware and
reflects its distributed aspect;
The development view, which describes the static organization of the software in its
development environment.
Finally, the elements [4] in the four views are shown to work together seamlessly by using a set
of important scenarios also the instances of general use cases. This view is redundant with the
other ones (hence the “+1”), but it serves two main purposes:
As a driver to discover the architectural elements during the architecture design
As a validation and illustration role after this architecture design is complete, both on paper
and as the starting point for the tests of an architectural prototype.
The framework and the interaction of these “4+1” view architecture diagram is shown in Figure 1.
Figure 1 the “4+1” view model
3.2 CDC + PP Environment
CDC [5] is designed around two goals of Java SE compatibility and support for resource-
constrained devices. Java SE allows developers to leverage their investments in Java SE
technology, including libraries, tools and skills. Support for resource-constrained devices allows
device vendors to offer a feature-rich java runtime environment that can support secure, mobile,
enterprise applications.
A profile [5] is an additional set of APIs that support a narrower range of devices. Profiles provide
a product designer with flexibility for supporting different kinds of connected devices with a
compatible Java runtime environment. There are mainly three kinds of CDC profiles:
Foundation Profile: provides basic application-support classes such as network support and
I/O support.
Personal Basis Profile: Provides lightweight GUI support, based on AWT, JavaBeans
runtime support, and some support for xlet application programming model. Personal Basis
Profile includes all the APIs in Foundation Profile.
3.0 7 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Personal Profile: provide full AWT support, applet support, and limited bean support.
Personal Profile includes all the APIs in Personal Basis Profile. Also, Personal Profile
represents the migration path for PersonalJava technology.
The CDC profiles and the supported libararies are shown in Figure 2 [5].
Figure 2 CDC library
3.3 Apache Derby
Apache Derby [6], an Apache DB subproject, is a relational database implemented entirely in
Java and available under the Apache License, Version 2.0. Some key advantages include [6]:
Derby has a small footprint---about 2 megabytes for the base engine and embedded JDBC
driver.
Derby is based on the Java, JDBC, and SQL.
Derby provides an embedded JDBC driver that lets you embed Derby in any Java-based
solution.
Derby also supports the more familiar client/server mode with the Derby Network Client
JDBC driver and Derby Network Server
Derby is easy to install, deploy, and use.
The embedded feature of Derby engine is one of the most important features in this project.
When an application accesses a Derby using the embedded JDBC driver, the Derby engine does
not run in a separate process. Instead, the Derby engine runs inside the same JVM as the
application and acts like the other jar files. The embedded architecture is depicted below [6
db.apache.org]:
3.0 8 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Figure 3 Derby Engine
3.4 SonyEricsson P990i
SonyEricsson P990i [7], shown in Figure 4, was the first smartphone to adopt Symbian OS v9
and the UIQ 3 software platform. Several strong technical features of this phone are the reasons
that we chose for the ONEPP development:
Both CDC and CLDC support
Wi-Fi integrated
Strong library support, such as jsr 135, jsr 075, jsr 172 and so on.
Figure 4 SonyEricsson P990i
3.0 9 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
4 Design
In this part, the “4+1” view of software architecture are used to depict the design of ONE Portable
Player. Beside, some UML class diagrams are added to specify the development process. Due to
the large system and the time limit, I mainly present some UML diagrams that are regarded as
the most important in ONE Portable Player.
4.1 Logical view
Figure 5 shows the top level class diagram of the ONE Portable Player, containing 11 class
categories. The description of these class categories are listed below:
Display && User Interface: User Interface is loaded and presented when ONEPP starts. This
part is close related with Main part.
Main: Main is responsible to start the up-lever UPnP hosting framework and Multicast
services. Main also controls three components and the rest of the application.
UPnPhosting Service: provides the UPnP hosting framework service which has the function
of sending the SSDP Notify message out. Besides, this part handled the HTTP message
received.
Multicast Service: the suplement for UPnPhosting service. This part could receive and
handle the outside multicast message. SSDP Notify message and M-SEARCH message are
handled by this part of service.
Control Point: Manage the Media Servers and media Renderers in local network. This part is
mainly related with the other three parts: Media Server Management part, SOAP part, and
Media Renderer management part.
Local Media Server: provide the function of media server. When registered to UPnP hosting
service, this component including two inside services (ContentDirectory service and
ConnectionManagement service) starts up. LMS are also used by multicast part.
Local Media Renderer: provide the fuction of media renderer. When registered to
UPnPhosting service, this component including three services starts up.
DerbyServer: when ONEPP starts up, a Derby instance is created to manage the media
resource in a certain folder. This part of function are used by LMS
SOAP: Provide the mechanism for the control point to invoke the UPnP actions and services.
SOAP mechanism is combined with HTTP.
Media Server Management: provides the mechanism to manage the information of Media
server, including the services inside. This part is mainly used by control point part.
Media Renderer Management: provides the mechanism to manage the information of Media
Renderer, including the services inside. This part is mainly used by control point part.
Figure 5 Logical view
3.0 10 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
4.2 Process view
Figure 6 shows the process view of the ONE Portable Player. ONEPP process mainly contains 6
threads. Based on the different functionality and the priority, these threads are specified below:
Main controller task:
This thread is the major thread of ONEPP and starts when the application starts up. The
thread also interacts with discovery task thread, UPnP hosting task thread, multicast thread,
and Resource controller task thread.
UPnPHosting task
This thread mainly provides the up-level framework and functions for ONEPP, such as
sending out SSDP NOTIFY message, handling http request message and so on.
Multicast task:
This thread adds two kinds of multicast support to ONE Portable Player in addition to the
function of UPnPhosting task thread.
Discovery task:
This thread is responsible to discover the UPnP devices and services in local network.
Resource controller task:
This thread is used by LMS to manage the media resource information.
Notify multicast task:
Notify multicast task is activated by UPnP hosting task to send out the SSDP NOTIFY
message in a certain time period. The value is 30 seconds in ONEPP.
Watchdog task:
Watchdog watches the discovery task thread to avoid the dead lock. When the application
send out the M-SEARCH request to the local network and could not receive the response in
the certain period, watchdog would be able to detect the dead lock and cancel the running of
discovery task thread. The value is 10 seconds in ONEPP.
Three threads are responsible to interact with the outside process. They are UPnPhosting thread,
Multicast thread, and Notify thread. UPnPhosting thread could receive the outside http request
and send back the response such as device description and service description and so on.
Multicast thread could receive the outside SSDP M-SEARCH or SSDP NOTIFY message and
generate and send back the response. Notify thread, as a subordinator of UPnPhosting thread, is
responsible to send out SSDP NOTIFY message in a certain period.
Figure 6 process view
3.0 11 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
4.3 Development view
Figure 7 represents the development organization in six layers of ONE Portable Player. This is
the development architecture corresponding to the logical architecture shown in figure 5.
Layers 1 and 2 constitute a low level infrastructure environment such as hardware, operating
system, and mobile platform and IBM CVM. To this infrastructure, layer 3 adds some library
support for up-layer development. These libraries include jsr 172 for web service, jsr 169 for
J2ME JDBC and so on. Also, one outside derby.jar is used for embedded database support.
Layer 4 represents up-level ONEPP framework service, and layer contains three components in
the application. Finally, in layer 6 exist Man-Machine interface and test tools for product testing.
Figure 7 Development view
After the general introduction of the different layer in development view, I would like to add some
UML class diagrams to represent a bit more details about the components and structure of CDC
version ONEPP. Instead of present all the class diagrams, only 5 essentials classes are choose
to show. These five class diagrams shown from figure 8 – figure 12 below are regarded as the
most important diagrams in the whole application. They are UPnPHosting class,
UPnPPresenceAdvertisementHandling class, ServiceDevice class, MediaRenderer class, and
Settings class.
UPnPhosting class contains five inner classes: ConnectionHandler class for receiving HTTP
request information; DeviceNotificationTask class for sending out SSDP NOTIFY message;
SsdpHttpHandler class for handling http request. Besides, UPnPhosting class depends on mainly
the other 7 outside classes, including three kinds of UPnP exception supports. The class diagram
could be found in figure 8.
Figure 9 shows UPnPPresenceAdvertisementHandling class for multicast support. This class
could receive the multicast information. After that, UPnPPresenceInformation class is needed to
parse the information and return the head fields needed. UPnPMap is used to organize the
connection among different header fields and different UPnP devices. Finally,
UPnPDatagramSend class is used to send back the unicast response message.
3.0 12 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Figure 8 UPnPHosting figure 9 Multicast support
ServiceDevice class in figure 10 shows the structure of Local Media Server. LMS have two
services: ContentDirectoryService and ConnectionManagerService, while each service is related
to several UPnPAction and UPnPVariable elements outside. Besides, this class contains three
inner classes: FileIndexGenerator class is used for media resource management;
ConntentDirectoryHandler class is used for HTTP data transfer; and IsFileIndexFilter is used to
match the requested media and the media in the database.
MediaRenderer class in Figure 11 shows the structure of Local Media Renderer. There are three
services inside the LMS: AVTransportService which is used for render media,
RenderingControlService that is responsible to control the setting parameter such as volume,
speed and so on, and ConnectionManagerService class that is used for getting the current
connection information.
Figure 12 represent the Settings class that is useful for control point. This class relies on several
outside classes. For example, this class depends on MediaServerFactory class to find the UPnP
Media Server, MediaRendererFactory class to find UPnP Media Renderer. After that,
MediaServer and MediaRenderer classes are used to store the information of found Media
Servers and Media Renderers.
Figure 10 Local Media Server Figure 11 Local Media Renderer
3.0 13 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Figure 12 Settings
4.4 Physical view
Then we go to the ONEPP physical view. Figure 13 is the expectation physical view, although
ONEPP has not yet been deployed into the real machine due to the symbian certificate problem.
With the Wi-Fi environment, SE P990i, which has ONE Portable Player inside, should have the
ability to discover the UPnP devices in the local network, render the media source, provide media
server services for the other UPnP applications.
Figure 13 Physical view
4.5 Use case
In order to describe the corresponding sequences of interaction among objects, two use cases
are defined. Figure 14 shows the use case of the contol point when ordering the UPnP services.
The sequence is listed below:
<1> control point sends the SSDP M-SEARCH message to the local network.
<2> control point receive the UPnP device responses, including response from himself.
<3> control point go to MediaServer list to choose the media server.
<4> control point go to the MediaRenderer list to choose media renderer.
<5> send the SOAP request to order the UPnP actions.
<6> control point gets the SOAP response.
Figure 15 shows the use case of LMS or LMR when providing UPnP services. The interaction
sequence is listed below:
<1> multicast service receives the SSDP M-SEARCH request.
<2> multicast service generated the response and sends back.
<3> UPnPhosting service receives the Http request for device and services description.
<4> UPnPhosting service sends back the Http response message.
3.0 14 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
<5> UPnPhosting service receives the SOAP request.
<6> UPnPhosting sends back the SOAP response for answer.
Figure 14 Use case 1 Figure 15 Use case 2
3.0 15 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
5 Testing
In this part, we mainly focus on functionality test of ONE Portable Player, based on user’s view.
In 5.1 part, some test tools and their roles are introduced; then in 5.2 part, each components of
ONEPP CDC version are tested.
5.1 Test tools
In this project, many UPnP testing tools are used to find the device, to capture the UPnP
package, and to play the media. I will go through some most important tools.
Twonkyvison server: provide UPnP music server function.
Intel Media Renderer: provide UPnP media renderer function.
Intel Device Sniffer: capture UPnP data package, also have the functionality to find the UPnP
devices and browse the UPnP device and service description.
Inter Device spy: detected the running UPnP devices and the corresponding services.
Figure 16 TwonkyVision Server Figure 17 Intel Device Spy
Figure 18 Intel Media Renderer Figure 19 Intel Device Sniffer
5.2 Function Test
When clicks the start button of the start screen, the application starts up. See the Figure 20, the
motivation of using a textArea in the start screen is to catch the status of the application,
especially registration status of LMR and LMS. When LMR and LMS are registered, and
everything is ok, the main screen will show in figure 21. Below, the main function of ONEPP
could be separated into four parts: Control Point function, LMS function, LMR function, and
Multicast function.
3.0 16 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Figure 20 Start screen Figure 21 Main screen
5.2.1 Control Point Test
The control point function is tested in the following steps:
<1>click the “Find” button in the main screen. Two media servers and two media renderers are
discovered some seconds later. The first field in each lists is the defaulted selected device.
<2> click “Browse” button, another screen shows up and goes to the next level of media source.
<3> click again the “Browse” button to go to the bottom level of media source; we get a list of
MP3 music.
<4> click any song in the list, and click “Play” button, Inter Media Renderer is playing.
<5> click the other “Pause” or ”Stop” buttons, Inter Media Renderer pause or stop the music
playing.
<6> click the other “Next” or ”Prev” buttons, Intel Media Renderer begin to play the next or last
song.
In all, control point could control the UPnP devices and order the services efficiently.
Figure 22 Main screen2 Figure 23 Browse screen 1 Figure 24 Browse screen 2
5.2.2 Local Media Server Test
Then we go to the Local Media Server test. The test steps are listed as followed:
<1> In the main screen, select “My Media” in the first list, and click the “Browse” button. Go to the
next screen and next level media source. See the Figure 25.
<2> select the “Music” in the list and click the “Browse” button again. Go to the music level
screen in figure 26.
<3> click any song in the list, and click “Play” button, Inter Media Renderer is playing.
<5> click the other “Pause” or ”Stop” buttons, Inter Media Renderer pause or stop the music
playing.
<6> click the other “Next” or ”Prev” buttons, Intel Media Renderer begin to play next or last song.
3.0 17 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
In all, control point could control the UPnP devices and order the services efficiently.
The JPG (.jpg/.jpeg) format file is not tested since Intel Media Renderer could not support to
display the picture. However, LMS works well and could provide UPnP services to the outside
UPnP devices.
Figure 25 LMS Browse screen 1 Figure 26 LMS Browse screen 2
5.2.3 Local Media Renderer Test
The Local media Render test step is listed as follow:
<1> select “My Renderer” in main screen of figure 2. Any media server is possible, I supposed it
is LMS. Continue to click the “Browse” button, and goes to figure 25 and figure 26.
<2> select a MP3 music and click “Play” button.
No music is playing because SE P990i emulate does not support the MP3 codec, however, one
temp fold that contains media stream is created inside the SE P990i emulate directory. That
means, the UPnP media server does transfer the media datastream to the LMR.
5.2.4 Multicast test
This part is tested with the help of Intel Device Sniffer and the other outside UPnP devices. See
the following steps:
<1> start the ONEPP to the main screen
<2> send out the SSDP M-SEARCH message to the local network with the help of Intel device
sniffer.
<3> check the correctness of the reply message from the ONEPP.
<4> start a new UPnP device, such as Intel Media Renderer
<5> the name of Intel Media Renderer is shown in the main screen
<6> close the Intel Media Render
<7> the name of Intel Media Renderer disappear in the main screen
In all, multicast service in ONEPP works well to receive and handle the related multicast
message.
5.2.5 Reliability Test
ONEPP is not reliable in the 16M memory default mode. Sometimes, there might be one
exception: java.lang.outOfMemory. Not until the default memory of emulate is changed from 16
M to 20M or above, the application become reliable. The reason might be that the initialization
and the connection of the derby server spend too much memory.
Unfortunately, ONE Portable Player could not run well in the real machine due to the Symbian
certificate problem. Only 60% of Java APIs is allowed to be accessed without the symbian
certificate, while some of the Java libraries used by ONEPP, such as network support library, File
3.0 18 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Management library and so on, are included in the other 40%. Until now, all the development and
test is based on the development of P990i emulate.
3.0 19 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
6 Discussion
It is a pity that the application finally could not be tested in the real machine, Sony Ericsson P990i.
In order to test the application, many efforts are tried to pass the symbian certificate. We even
spent one week thinking of a solution to create a root certificate that could be used in SE P800
and some old symbian phones; however, this effort fails in SE P990i. From the new version of
symbian phones, such as SE P900, SE P910, and SE P990i and so on, the root certificate has
been already built inside the phone system and is protected by new version symbian system,
private key and so on. This makes the fake symbian root certificate impossible to survive.
Anyway, all the three components of CDC version ONEPP works well in emulate and could
provides attractive UPnP services and functions. This makes possible the future development of
ONEPP.
One of the main goals in the next step of ONE Portable Player is to integrate UPnP technology
with SIP technology. That is, SIP and UPnP technology would be combined together to remote
discover and manage local or remote UPnP devices and services. See the figure 27 [3] For
example, one user who moves away from his home network would still be able to order UPnP
services in his home network and in the other visited networks. The vision is described in Figure
27 [3].
SIP protocol will be the main protocol used to set up the connection. UPnP discovery and
controlling messages such as SSDP M-SEARCH and SOAP information is planning to be added
in the SIP body. Some extra components are planning to be added into ONEPP to manage the
translation between SIP and UPnP protocol.
Figure 27 SIP and UPnP combination
Another goal in the next step of ONE Portable Player is to use some of Ericsson SDS tools for
further development and testing. As the main role of IMS client, IMS Client Platform (ICP) and
Terminal emulator inside Ericsson SDS tools might be used for the development. And IMS Core
network simulator might be used for testing.
3.0 20 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
7 Conclusion
In this porting project, there are mainly three kinds of problems we solved in this project: porting
library from CLDC to CDC, Database management, and Multicast support. Currently, the
application is testing and running well in SonyEricsson P990i emulate. However, without the
symbian certificate, ONE Portable Player is not possible to deploy and test in the real machine.
From this project, I learnt many things in J2ME CDC field and have the deeper understanding in
the software engineering design and development. Besides, in over three months working in
Ericsson, Eurolab, I had a great chance to go inside an international company, from which I met
nice people, enjoyed the good working environment, and got some feelings about how an
international research center works.
Thanks for the great technical support and encourage from three supervisors, the problem met in
the process of the project could be solved in time and efficiently.
3.0 21 (22)
Zheng Xianghan Port ONEPP from J2ME CLDC to J2ME CDC
Appendices
Appendix 1 Glossary & Abbreviations
AML: Agder Mobility Lab
CDC: Connected Device Configuration
CLDC: Connected Limited Device Configuration
DLNA : Digital Living Network Alliance
IMS: IP Multimedia Subsystem
J2ME: Java 2 Micro Edition
SIP: Session Initialization Protocol
UPnP: Universal Plug && Play
ONEPP: ONE Portable Player
GSM: Global System for Mobile Communication
WCDMA: Wide Code Division Multiple Access
CDMA 2000: Code Division Multi Addressing 2000
TD-SCDMA: Time Division-Code Division Multi Addressing
VoIP: Voice over IP
WLAN: Wireless LAN
SDS: Service Development Studio
Appendix 2 References
[1] Andreas Häber, Frank Reichert, and Andreas Fasbender, “UPnP Control Point for mobile
Phones in Residential Networks, " 15th IST Mobile & Wireless Communication Summit, June 4-8,
2006
[2] WIKIPEDIA. Available: http://www.wikipedia.org/
[3] Agder Mobility Lab. Available: http://ikt.hia.no/aml
[4] Philippe Kruchten, “Architectural Blueprints---The”4+1” View Model of Software Architecture”,
IEEE Software 12, Nov, 1995, pp42 – 50
[5] CDC: JAVA PLATFORM TECHNOLOGY FOR CONNECTED DEVICES, Sun MicroSystem
[6] Apache Derby. Available: http://db.derby.org
[7] SonyEricsson. Available: http://www.sonyericsson.com
3.0 22 (22)
