1. Bug Fix of Mobile Terminal Software using Download OTA NTT DoCoMo, Inc. Multimedia Development Department Consumer Equipment Development Department 3-5 Hikarinooka, Yokosuka-shi, Kanagawa 239-8536 Japan E-mail: {takeichi, hosokawa, nasuk}@nttdocomo.co.jp E-mail: {hoshis, moriyamak, takami, terunuma}@nttdocomo.co.jp Masato Takeichi, Atsushi Hosokawa, Kazunori Nasu Seiji Hoshi, Koichi Moriyama, Tadao Takami, Kazuaki Terunuma

2. Introduction Background: 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

3. 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

4. Analysis Before bug-fix Mobile terminal software 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.

5. 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.

6. Proposal1: The servers 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

7. Allowable transfer capacity Normal traffic volume 1 1 2 24h Facility capacity 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)

8. Proposal 2: Update software at a reserved time Ensure ease of use when data transfer time is long Enable 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 Negotiation Update necessity inquiry Repeated Continuous Transfer Figure 4:Rewriting software at a preset time

9. Radio Access Network 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

10. Implementation of communications protocols and the mobile terminal Figure 6: Basic scenario of communications between mobile terminal and server Figure 7: User mobile terminal operations (Example)

11. 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 request Reserved call: Call in which software was updated at a reserved time Denied 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

12. 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 results 1.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.