Bug Fix of Mobile Terminal Software using Download OTA

NTT DoCoMo, Inc.† Multimedia Development Department

‡Consumer Equipment Development Department3-5 Hikarinooka, Yokosuka-shi, Kanagawa 239-8536 Japan

E-mail: †{takeichi, hosokawa, nasuk}@nttdocomo.co.jpE-mail: ‡{hoshis, moriyamak, takami, terunuma}@nttdocomo.co.jp

† Masato Takeichi , Atsushi Hosokawa , Kazunori Nasu‡ Seiji Hoshi , Koichi Moriyama , Tadao Takami , Kazuaki Terunuma

IntroductionBackground: Size of software is growing due to increases in mobile terminal

functions⇒Increase in the possibility of bugs’ being inherent.

Present: To replace mobile terminal or rewrite the software at retail store:

An environment in which users themselves can fix bugs in their mobile terminals rather than taking them to retail stores needs to be established.

Realize to update mobile terminal software OTA. ・ Improve user convenience・ Reduce the costs to replace mobile terminal

Prerequisites

1. Enable users to update their software via easy operation and within a reasonable length of time.

2. Ensure that the impact on the mobile communications network does not exceed the allowable range.

3. Minimize the impact on the cost of mobile terminals.

4. Do not build in any reliance on the mobile terminal architecture.

Number of connections to the server and data size to be downloaded must be analyzed.

Focusing mainly on conditions 1 and 2

Analysis

Before bug-fix

Mobile terminal software Bug

Bug

Bug

Bug-fixing data

Figure 1. The bug-fixing data for the mobile terminal software

After bug-fix

Analysis:1:There is a peak in the assumed

number of connections aimed at fixing bugs.

2:The assumed number of connections is sufficiently few compared to the number of normal connections made by all subscribers.

3:Cases in which bug-fixing data may become large due to the type or scale of bug are also assumed.

Issues:1:Transfer control

appropriate to the bug-fixing data are needed.

2:Ease of use when data transfer time is long must be ensured.

Access Control Methods

Proposal 1:

　 A transfer control method where data transfer to mobile terminals is allowed only within a range that does not affect the network.

Proposal 2:

　 A reservation method of software update to enhance convenience to users.

Proposal1: The server‘s transfer control depending on Allowable Transfer Capacity(1/2)

Transfer control appropriate to the bug-fixing data is needed.Server control data transfer after the first connection request from the mobile terminal is received.

Bug-fix data 　

Negotiation

MT SV

Update necessity inquiry

'Transfer completed' notification, 'Update completed' notification

Bug-fix data transfer is restricted if facility capacity is exceeded

Negotiation

Repeated Continuous

Transfer

GW

Figure 2: Access control methods

Allowable transfer capacity

Normal traffic volume

1 12 24h

Facilitycapacity

Figure 3: Allowable transfer capacity

Using allowable data transfer capacity on the existing mobile communications network as the criterion for allowing or denying a connection

Proposal1: The server's transfer control depending on Allowable Transfer Capacity(2/2)

Data

　volume

Proposal 2: Update software at a reserved time

Ensure ease of use when data transfer time is longEnable download to occur at the time when a user is not

using the mobile terminal to update the software.

Reserved time

MT SV

Reserved

GW

Bug-fix data 　

Starting time

NegotiationUpdate necessity inquiry

Repeated Continuous Transfer

Figure 4:Rewriting software at a preset time

Radio AccessNetwork

Transfer request, etc.

Mobile communications network

Packet GW

System design

Bug-fixing data, etc.

Mobile terminal

Server

Figure 5: Overall system configuration

Bug-fixing data

maintenance tool

Implementation of communications protocols and the mobile terminal

Figure 6: Basic scenario of communications between mobile terminal and server

C a ncel

Downloading

Rewriting

>>>>- - - - - -

OK

Your updateis complete

Update is needed

Update nowUpdate required

① ②

③ ④

MT SV

HTTP POST (Request)

HTTP POST (Response)

HTTP GET (Response)

Download bug-fixing data(repeated until transfer ends)

HTTP POST (Request)'Update completed'notification

Rewriting...

HTTP GET (Request)

Update necessity inquiry

'Manufacturer', 'Model', 'Current version'

'Manufacturer', 'Model', 'New version'

'Necessity to update''URL for bug-fixing data'

'Bug-fixing data'

④

③

②

①

Figure 7: User mobile terminal operations (Example)

Evaluation of Access Control Methods

Normal call: Data communications call using i-mode, etc.Instant call: Call that was allowed to update software at the time it made the connection requestReserved call: Call in which software was updated at a reserved timeDenied call: Call that was not allowed to download and update software at the time it made the connection request

Figure 8: Results of the Simulation of the Access Control Methods

Conclusion Issues in realizing a mobile terminal software update system that

uses wireless communications for the purpose of fixing bugs were identified.

The transfer control method based on allowable transfer capacity and transfer permission granted or denied by the server was proposed.

A system design proposal that incorporates these methods was illustrated.

The validity of the proposed methods based on the simulation results1. Data volume exceeding the allowable transfer capacity did not

enter the network.2. All denied calls which became subject to the data transfer control

were completed the software update by reservation using the time frame where the traffic was lower.

At present, we are receiving feedback on the evaluation results and the principle evaluation results using function-simulation terminals based on general terminals and the server ,then working on development aimed at building the system for practical use.