You are here
Mobile device oriented projects
Project motivation and summary
Tremendous growth of development industry for mobile devices causes great challenges in software licensing area. The specificity of mobile devices (e.g. network software distribution) makes usage of most existing desktop-oriented licensing solutions impossible. Nowadays mobile devices software licensing systems are expensive for small developers, hard in implementation or don't provide sufficient protection level. There is no standard mechanism of developing software for mobile devices with license control. As a consequence, often developer needs to implement own licensing mechanism or buy an expensive solution with level of trust, which sometimes cannot be easily evaluated. We consider OS and hardware levels to be appropriate security levels for licensing systems. However it can be pretty hard and insufficiently expensive to implement solution on these levels for small developer because it needs great amount of resources which don't correspond with product financial model.
The main idea of this project proposal is to identify a reason why the mobile device software industry doesn’t have a generic licensing system and to set recommendations for developing such a system. The project will be done in 2 parts addressing short-term and long-term targets. The first phase is expected to last about 6-16 months and focus primary on the corresponding theoretical investigation. The second long-term part is technical part that uses theoretical findings of the first part for developing and implementing prototype solution for the identified problems.
- Make an overview of existing licensing solutions for mobile devices (primary focusing on: Windows Mobile, Symbian OS and MAEMO).
- Investigate non-technical (e.g. management and business) problems in the area of mobile software licensing.
- Determine and analyze weak points of existing solutions and possible attacks on licensing systems.
- Make an overview of existing licensing mechanisms for desktop systems and to estimate possibility of their usage on mobile devices.
- Based on investigation done at step 2 provide requirements for new licensing mechanism that addresses identified problems.
- Propose new mechanism (or modifications of existing mechanisms) for licensing system including several variations for different areas (enterprise level, freeware etc.).
- Implement the proposed mechanism.'
Timeline and deliverables
The short-term (6 – 12 month) deliverables are following:
- An article describing current software licensing market conditions and determining existing problems.
- An article describing basic features of the system needed for solving of the current problems.
The long-term deliverable is a proposal and development of the full technical solution for licensing.
Contact person: Alexey Koren
Ann Ukhanova, DTU Fotonik, PhD student/Researche - team-leader
Vitaly Grinko, SUAI, student
Video communications, as already used in the internet, become the second largest mass service after voice telephony. However video telephony is assumed to be about 10% in 3G networks with voice telephony traffic 5 years after implementation.
With the most modern Video compression techniques, a fast changing video image can be compressed by approx. 10:1. Where the majority of the image is stationary as in video telephony less than 2% of the uncompressed bits need to be sent across the network, relating to a 50:1 to 60:1 compression. This encoding of changes in a video data stream is the essence of MPG ( ISO Motion Picture Experts Group ). The characteristic nature of this data stream would be most suitable to a Variable Bit Rate (VBR) bearer service. This means that the transmission over an unreliable channel should be corrected with the instruments accessible on the PHY and MAC layer. Below you can find some useful information about it.
Interfaces to the physical layer
The physical layer (layer 1) is the lowest layer in the OSI Reference Model and it supports all functions required for the transmission of bit streams on the physical medium. The physical layer interfaces the Medium Access Control (MAC) Layer and the Radio Resource Control (RRC) Layer as depicted in figure 1.
Figure 1. Interfaces with Physical Layer
Interface to MAC
The physical layer interfaces the MAC entity of layer 2. Communication between the Physical Layer and MAC is in an abstract way performed by means of PHY-primitives defined which do not constrain implementations.
The PHY-primitives exchanged between the physical layer and the data link layer provide the following functions:
- transfer of transport blocks over the radio interface;
- indicate the status of the layer 1 to layer 2.
Interface to RRC
The physical layer interfaces the RRC entity of layer 3 in the network.
Communication is performed in an abstract way by means of CPHY-primitives. They do not constrain implementations.
The CPHY-primitives exchanged between the physical layer and the Network layer provide the following function:
- control of the configuration of the physical layer.
The currently identified exchange of information across that interface has only a local significance to the UE orNetwork
Services and functions of the physical layer
The physical layer offers data transport services to higher layers. The access to these services is through the use of transport channels via the MAC sub-layer. The characteristics of a transport channel are defined by its transport format (or format set), specifying the physical layer processing to be applied to the transport channel in question, such as convolutional channel coding and interleaving, and any service-specific rate matching as needed.
The physical layer operates exactly according to the L1 radio frame timing. A transport block is defined as the data accepted by the physical layer to be jointly encoded. The transmission block timing is then tied exactly to this L1 frame timing, e.g. every transmission block is generated precisely every 10ms, or a multiple of 10 ms. A UE can set up multiple transport channels simultaneously, each having own transport characteristics (e.g. offering different error correction capability). Each transport channel can be used for information stream transfer of one radio bearer or for layer 2 and higher layer signalling messages. The multiplexing of these transport channels onto the same or different physical channels is carried out by L1.
Overview of L1 functions
The physical layer performs the following main functions:
- FEC encoding/decoding of transport channels;
- measurements and indication to higher layers (e.g. FER, SIR, interference power, transmission power, etc…);
- error detection on transport channels;
- multiplexing of transport channels and demultiplexing of coded composite transport channels;
- rate matching;
- mapping of coded composite transport channels on physical channels;
- modulation and spreading/demodulation and despreading of physical channels;
- frequency and time (chip, bit, slot, frame) synchronisation;
- closed-loop power control;
- power weighting and combining of physical channels;
L1 interactions with L2 retransmission functionality
Provided that the RLC PDUs are mapped one-to-one onto the Transport Blocks, Error indication may be provided by L1 to L2. For that purpose, the L1 CRC can be used for individual error indication of each RLC PDU. The L1 CRC will then serve multiple purposes:
- error indication for uplink macro diversity selection combining (L1);
- error indication for each erroneous Transport Block in transparent and unacknowledged mode RLC;
- quality indication;
- error indication for each erroneous Transport Block in acknowledged mode RLC.
Regardless of the result of the CRC check, all Transport Blocks are delivered to L2 along with the associated error indications.
This project also addresses the important issues of error control for video transmission over 3G. Based on the time-varying wireless channel conditions and the essential defects of the traditional hybrid ARQ for real-time service, the architecture of the channel-adaptive hybrid ARQ/FEC is discussed and an algorithm for encoder that automatically adjust the parity data length and the maximum number of retransmissions is investigated.
Figure 2. Framework of a multiuser cross-layer video transmission system over wireless networks.
Also with the advancement of video-compression technology and the wide deploymentof wireless networks, there is an increasing demand for wireless video communicationservices, and many design challenges remain to be overcome. We would like to discuss how to dynamically allocate resources according to the changing environmentsand requirements, so as to improve the overall system performance andensure individual quality of service (QoS). Specifically, we will consider two aspectswith regard to design issues: cross-layer design, which jointly optimizes resourceutilization from the physical layer to the application layer, and multiuser diversity,which explores source and channel heterogeneity for different users. We will studyhow to efficiently transmit multiple video streams, encoded by current and futurevideo codecs, over resource-limited wireless networks such as 3G/4G cellular systemand future wireless local/metropolitan area networks (WLANs/WMANs).
Alexey Koren, post -graduate student, SUAI
Alexander Sidorenko, post-graduate student, SUAI
Sergey Semenov, post-graduate student, SUAI
Natalia Voloshina, PhD, SUAI
Daria Glebova, student, SUAI
The WidSets is a new service provided by Nokia. This fast growing service provides quite big collection of small but useful applications (widgets) mostly oriented on easy and fast access to online resource in the Internet, like RSS-feeds, news, e-mail, wikipedia and much more. WidSets can be installed to any mobile phone supported J2ME and compatible with almost all popular mobile phones.
It is known that in Russia huge number of registrations is completed every week, but the number of really active returning users is not developing as well. The main target of project is to evaluate the efficiency and usability of this service according to specific issues of using online services in Russia.
Project flow and targeted goals
We suggest the following flow of the project. Project will be divided into 3 main steps:
- Start-up phase;
- General Research phase;
- Finalization phase.
First step is intended to get initial knowledge about using and developing widgets. Team will be split into few parts and roles will be assigned to any team member. We already provide classification for people who can be interested in WidSets and role assignment will be done according to this. Full information is provided into project report but the common approach is that we have 3 main groups of WidSets users:
- Actually Users – the main consumers, people who actively download and use widgets
- Developers – users which made one step further and become creators of new widgets
- Customers – people from any industry who can be interested in having WidSets coupled with services they provide.
We will easily analyze WidSets from starters’ point of view. It can be done from starter users’ point of view as well as from point of view of starter developers.
Goals of Start-up step are:
- WidSets usability testing
- Testing of developer’s tools and usability of online resources such as wiki and manuals
- Analyzing the user experience started from registration up to active usage
- Building WidSets User Model
- Performing analysis of data domain (competitors, similar technologies etc)
Second step is longest phase; most part of research activity will be performed during it. We will use result got from Start-up phase to dig deeper to WidSets technology, to understand problems and to work out the solutions for solving it.
Goals of General Research step are:
- Investigating problems with WidSets usage in Russia
- Provide solutions for solving these problems
- Analyzing WidSets User Model to understand needs of each user category
- Analyzing existing approaches for satisfaction these needs
- Provide market and technical recommendations for increasing interest of all categories of users to WidsSets platform
- Propose strategic recommendations for WidSets market intervention in Russia
Finalization step is the time where all results are combining together, formatting and preparing
to be presented to project customer.
Deliverables of Finalization steps are:
- Full project report, including all results achieved during all steps
- Presentation describing WidSets platform and its opportunities at Russian market
- Technical presentation summarizing our experience of work with WidSets, containing information about all widgets implemented and planned for implementation, ideas of widgets to encourage students auditory.
21.11.2007 – First meeting of the team, official start of the project as well as its Start-up phase
12.12.2007 – End of Start-up phase, beginning of General Research phase
31.12.2007 – WidSets developers contests deadline; team is going to participate in this contest as well as spread message about it in SPb developers community
13.02.2008 – End of General Research phase, start of Finalization phase
End of 02 – start of 03.2008 – WidSets seminar in SUAI; team is planning to present its results.
Three mobile phones supported WidSets technology should be provided to the team with the free Internet traffic from one of the Russian mobile provider (Megafon, MTS, Beeline or Tele2). WiFi-enabled devices are preferable because they help to reduce expensive GPRS traffic.
The team is looking for statistics and other data regarding WidSets usage. This data will be discussed separately. Also team is looking for support from WidSets experienced developers and architects to discuss technical issues and ways of handling it.
Year by year mobile phones are becoming more than just phones. Each modern phone is also a camera, a music player, an internet device - and a convenient address book. The downside of a mobile phone book is that it is static (just as conventional paper phonebook is). If your friend changes his or her phone number - you have to change it in your phone book manually. If you need to know your friend's home address - the best you can do is to call him and ask for it.
Is it possible to make a better phonebook, using all the possibilities that mobile technologies offer?
In order to create a solution for this problem, we must cover two directions:
- provide mobile phone users with internet-related functionality basing on the capabilities of their mobile devices (for example, offering convenient phonebook backup service to SyncML-enabled devices)
- provide external social services with information about the capabilities of a specific mobile device for determining maximum interoperability scenario (for example, allow blog-enabled Nokia phones to post photos to nanoblogging services like Tumblr)
We understand that developing both these scenarios will involve major research about ways of securing user data.
The goal of our project is to create a software solution for unification the interoperability of web services (like social networks, blog services, contact storages and encryption and security mechanisms) and mobile devices (from simple mobile phones to advanced communicator devices) and this devices' users.
The main part of the designed framework would be a universal API for communicating with different web services.
We propose the following project steps:
1. The first project phase. Widening the possibilities of an address book in a mobile phone – backup system for various types of mobile devices. We see this sub-project as a playground for testing the project workflow and gathering initial feedback from users (this phase is already completed, see next part)
2. The full solution phase. It will consist of the following:
- A server-stored phonebook that is to be synchronized with a mobile device - either via SyncML or using a direct connection with a custom phonebook application on user's smartphone.
- An open API for integrating the server phonebook with external data storages
- An algorithm for intelligent fetching contact updates from different data sources, merging it and uploading it to users' mobile phone
- An advanced phonebook application for Symbian and Windows Mobile
We will cover the intelligent fetching algorithm more thoroughly. The problem that our system will face is determining whether two identities fetched from different contact storages (for example, a contact from GMail address book and friend's Facebook profile) are in fact the same person. We are currently discovering ways to solve this problem, one of discussed options is to inspect not only the profile itself, but also its social interconnections (like a list of contact's friends), which are also provided by almost each contact storage. Studying interconnections will allow us to evaluate the degrees of proximity and likeness of different profiles. We understand that this part of project will certainly require major research, but it will also provide the most interesting results.
3. The prospective phase. A major part of developments will address the problem of securing server-stored user data. One of possible solutions would be to apply private key-based encryption to personal data stored on the server, and mobile phone client application will decrypt it using a private key. This technique will prevent identity theft even if all data on the server is compromised by an attacker.
For the sake of prototype, we propose an open system for widening the possibilities of an address book in a mobile phone. The main goal is to provide connection between the mobile device phonebook and an external contact storage - for example, a list of friends in your favorite social network. How it will look like?
For simple, non-smartphone models, we rely on SyncML protocol to update the information in the phonebook: if your friend updates his or her profile in a popular social network, like Facebook, MySpace or VKontakte.ru, all modifications to his personal data will be automatically propagated to your mobile phone.
For advanced mobile devices - like smartphones and communicators - we propose a stand-alone application to replace the built-in phonebook. The application will have all the features of a default phonebook - listing and searching contacts, initiating calls and SMS texting, but also it will introduce some social-specific features, like viewing social network profiles for a person in phonebook, tracking his or her Internet activity (monitoring blog posts, photo albums, Twitter updates, etc).
For the means of integration, we plan to create an open API for contributing to user's phonebook. This API would allow any interested developer to create a plugin to fetch data from a social network or external contact storage (for example, GMail address book) and populate the server-side phonebook with this data. For this task, we plan to involve some already instantiated standards, like Google's OpenSocial (http://code.google.com/apis/opensocial/).
At the moment, we have created a simple SyncML synchronization service (www.syncopa.ru) and are currently working on creating API to synchronize the server-side phonebook with Russia's widest social network - VKontakte.ru. Early testers are praising the usability and ease of use of our service.
We hope that our idea is in pace with Nokia Fruct directions and we look forward for an effective collaboration.
The issue of limited user space is important for all mobile devices today. Any user want to use a lot of content but don't want to pay for expensive large-volume cards to store it.
So the opportunity to share data in the ad-hoc network of mobile devices is very attractive.
Imagine that the data is distributed transparently among the net instead of being stored locally on each device. Any user can use any data in this net but has to store only the part locally.
So the idea of the project is to provide ability to use much more data on device with lack of user space by distributing data among the group of such devices in assumption that they supports networking and the sets of needed data are overlapped inside this group.
We suggest to develop serverless distributed file system to provide way to distribute data among the net of Nokia Interner Tablets, to use and to modify it remotely and so on.
We suppose to use some base conceptions of serverless distribution used in xfs file system as the heart of implementation.
As the first step this file system can be implemented as a user-space programm using the Fuse (File System in User Space) software.
The developed file system has to provide common file operations along with procedures of connecting/disconnecting to the "data community", of locating newly created data, and relocating data in the case of unbalanced usage of space among the net.
- Proof the concept and establish requirements: obtain common use cases, review related works, identify platform constraints. - 30/12/08
- Design and spec. - 01/02/09
- First prototipe implementation - 01/03/09
- First port for maemo - 15/03/09
- Investigation, estimation of achievements, planning for next iterations - 15/04/09
- Public report in FRUCT seminar (April 2009)
Project Lead: Evelina Stepanova