Challenges and Novelties while using Mobile Phones as ... - CiteSeerX

Challenges and Novelties while using Mobile Phones as ICT Devices for Indian Masses Kuldeep Yadav 1 , Vinayak Naik 1 , Amarjeet Singh 1 , Pushpendra Singh1 , Ponnurangam Kumaraguru1 , and Umesh Chandra2 1 Indrapratha

Institute of Information Technology, New Delhi, India 2 NRC-Palo

Alto, Palo Alto, CA, USA

Abstract Mobile phones have emerged as truly pervasive and affordable Information and Communication Technology (ICT) platform in the last decade. Large penetration of cellular networks and availability of advanced hardware platforms have inspired multiple innovative research opportunities in mobile computing domain. However, most of the research challenges have focused on typical scenarios existing in the developed economies. Using the healthcare as an application for mobile computing, we present research challenges and novelties in mobile computing domain that take account for differences between developing such as India and developed economies based on commonly available mobile platforms, communication cost, differences in user behavior and acceptable societal norms, among others. With localization being a critical component of various mobile systems, we present early results for the application of GPS-less localization that highlight the corresponding differences in Indian context.

1

Introduction

Mobile phones have now been accepted as a truly pervasive computing platform helping people to both keep in touch with each other and manage everyday tasks [3]. With the advent of less expensive smart phones, considerable work has been done towards simple application development for extending the usability of these devices for masses, especially those in rural areas [13]. Mobile phones have a potential to change the way developing economies, such as India, deliver essential social and economic services to attain sustainable growth. In this paper, we present challenges and novelties in mobile computing domain for using mobile phones as ICT devices to attain the potential in India. Also, here we will use India and developing economies interchangebly since most of the India specific challenges can be generalized for developing economies also. There are a number of different cellphone-based services such as financial, market information, healthcare, and mobile education that are growing rapidly. We take healthcare service for illustrative purpose throughout the discussion while a similar discussion will be applicable for other applications as well. Healthcare services: Figure 1 presents a simplified modular architecture for a programmable phone. We consider some of the important modules of this architecture with respect to the healthcare application in Indian context (illustrated in Figure 2). Specifically, a healthcare worker (or a physician) can use a mobile based application to collect data of the patient being treated. This data may include personal details of the patient, vital measurements for the disease that

Figure 1: Simplified modular architecture of a programmable phone the patient is suffering from, together with allied information (photographs of patient or wounds, audio recordings for the patient encounter, among others). An external device can also be connected to the phone for measuring vitals, such as temperature, and automatically recording them on the phone. Collected data can then be synced to a central repository (hosting an Electronic Medical Records (EMR) system). Communication to the backend database server is done using Short Messaging Service (SMS). The database can either be hosted on the same machine receiving the SMS (and acting like a SMS gateway) or on a machine that can communicate over internet with the SMS gateway. An authentication server can also be used to verify the credentials for access to the database. Contributions of the paper: We categorize the discussion on potential challenges and novelties based on the different modules outlined in Figure 1. Specifically, we provide initial discussions of the outlined architecture as follows: 1. Physical: Discussion on using audio interface for communicating with the external device at low cost and low power consumption. 2. Middleware: Discussion on language portability across multiple operating systems and Quality of Service (QoS) issues associated with SMS communication. 3. Localization: Proposing a new Cell Broadcast Service (CBS) based localization approach and discussing the associated challenges. 4. Security and Privacy: Challenges associated with SMS based authentication. 5. Usability: Discussion on interfaces and applications for user friendly mobile operations.

2

Physical Interface

Within the physical interface module, several options exist for applications to communicate. These include Infrared Data Association (IrDA) interface, bluetooth, Universal Serial Bus (USB), cellular network (including GSM, CDMA, GPRS) and WiFi. Recent research in using mobile

Figure 2: Architecture for mobile based healthcare services computing for the healthcare domain is focussed on data communication from either embedded (within the mobile device) or attached sensors, for early diagnosis [17]; and transmitting the data collected from these sensors to a remote location [16] exploiting the high bandwidth GPRS connectivity. Therefore, the primary focus at the physical module, especially in healthcare domain, is on transmitting the information from mobile phone (or some sensors attached to it) to a remote location. We propose a new paradigm of exploiting the cellular network to control the operations of a hardware device remotely by attaching it with the mobile phone. This would involve sending the information in a reverse direction - from a remote location to a device attached physically with the mobile phone (Please refer to Figure 2 for illustration). Communicating to a remote device over cellular network can be compared to Interactive Voice Recognition (IVR) systems. These IVR systems have already been in use for more than a decade and are currently pervasive in several environments, including call centers and telephone banking. Based on the new paradigm of remotely controlling the operations of a hardware device over cellular network, we divide the physical module communication into: 1. Remote communication with mobile device 2. Local communication with externally attached hardware device We now discuss challenges in each of the two communication interfaces in detail.

2.1 Remote communication with mobile device While GPRS or WiFi provide high bandwidth connectivity, they also consume large amount of power [1]. In WiFi, higher power consumption is primarily due to CSMA/CD protocol at MAC layer and in GPRS, it is primarily as a result of communication over a long range. SMS has already been hailed as a killer application for mobile commerce. This can also be thought of as a low-cost and low power communication methodology to communicate with a remote mobile device. A simple application running on a mobile device can interpret the incoming SMS to pass on the corresponding commands to the attached hardware device. Power becomes one of the most critical resource for mobile phones, especially for applications in rural areas. Agrawal et. al. [1] empirically demonstrated that the power consumption of a mobile phone when using a simple GSM communication (required for SMS) is significantly smaller than GPRS and WiFi. Multi-fold difference between power consumption and bandwidth motivates development of

intelligent applications that can switch between these modes to achieve optimal power consumption. Several applications proposed for rural areas, including the healthcare application outlined by us, talk about multiple remote communication methodologies including SMS, GPRS and WiFi. Further, with on-device availability of several Giga Bytes of low cost memory and high processing power, a lot of computation can be performed on the phone to save on larger power consumption in the active communication mode. Extensive empirical evaluation, exploiting computation-communication tradeoff, has been performed in sensor networks domain [11] that can be extended to applications of mobile computing.

2.2

Local communication with externally attached hardware device

Several interfaces are outlined in Figure 2 for local communication between mobile phone and the external hardware device. While IrDA is uncommon amongst most mobile devices, both WiFi and bluetooth involve expensive circuitry at the external hardware device and high power consumption. USB is a low cost and small power consuming alternative for interfacing many external devices. However, most of the mobile phones (including many smart phones) have limited capabilities and can not function as a USB master to control any external hardware. This limitation also motivated the development of a hardware platform [12] that acts as an intermediate platform for connecting external hardware devices with mobile phones over USB. Such hardware limitations significantly increase the overall system cost for communication over USB. Motivated by the IVR systems, we propose the audio port on the mobile phone for communication with the external hardware device. Similar to IVR systems, one can think of producing a physical signal for an external hardware device based on a key press performed remotely. Specific key press produce different frequency signals called Dual Tone Modulation Frequency (DTMF). An application on mobile phone can decode DTMF signals to control an attached hardware device. This may not even require any software development at the receiving end if the already existing features, such as auto-answer capabilities1 can be put into use at the receiver side. Such a scenario provides two paradigm shifts - using audio port as a communication interface; and using the existing features such as auto-answer to extend the capabilities of a low-cost mobile devices (that do not support any programming). The audio port can also be extended to communicate data from the external device to the phone. Nano Ganesh,2 a commercially available device with similar capabilities, was our motivation for developing this paradigm shift. Based on a pre-defined numeric key press, the device controls the switching of an electric water pump remotely over a cellular network. This can easily be extended to create a simple hardware extension capable of controlling the switching of any electronic device remotely over the cellular network. Further, we hypothesize that taking such platforms and orienting the research for further enhancing their capabilities and efficiency is a 1 automated

answering of incoming call after a preset duration

2 http://www.nanoganesh.com/

OS Android iPhone Windows Mobile Blackberry Symbian Maemo

Manufacturer Google, HTC, Samsung Apple HTC, Sony, HP, Toshiba, Videocon RIM Nokia, Motorola, Sony Nokia

Language Supported J2SE, J2ME Objective C C#, VC++, J2ME J2ME Symbian C++, J2ME, Python C, Plans to support Java

Price Range ≥ USD 150 ≥ USD 450 ≥ USD 150 ≥ USD 240 ≥ USD 40 ≥ USD 200

Table 1: Programmable mobile phones’ system specifications and their cost in India perfect example of bottom-up research often talked about in ICT for Development literature [7]. As an example, for mobile devices that support basic programming capabilities, one can easily conceive lowering the operational cost by performing remote switching based on an incoming SMS. As an improved feature, the SMS can be processed to have a timer based control of the remote devices.

3

Middleware

Large variation in the architecture and software platforms of mobile phones makes it very difficult to develop applications that can be widely deployed across different platforms. In our knowledge, there is no literature that compares portability of code across diverse hardware and software platforms. Further, low-end phones do not even come with high-bandwidth communication interfaces motivating the development of middleware to provide program portability code and necessary QoS over low-bandwidth interfaces. We now discuss the challenges and novelties associated with device and OS heterogeneity and guarantying QoS over low bandwidth interfaces.

3.1

Device and OS heterogeneity

Six major software platforms account for most of the handsets currently in use: Android, iPhone, Windows Mobile, Blackberry, Symbian, and Maemo. One way to overcome device and OS heterogeneity is to use a programming language that can be cross-compiled for multiple platforms with limited constraints. Table 1 describes each of these platform and the programming languages supported by them. Java 2 Micro Edition (J2ME) is a platform that is available almost on all the mobile platforms, barring iPhone. By its very nature, Java provides device heterogeneity with support for cross-compilation. Most of the mobile phones already come equipped with JVM, required for running Java programs. For phones that do not have a JVM (e.g. Windows Mobile), third party JVMs such as IBM J9 can be installed. So far, iPhone does not provide any JVM, thus preventing Java programs to run on these devices. Due to their high cost, use of iPhone is anyway limited in India. J2ME platform for mobile phones comes as a collection of Java Specification Requests (JSRs) that define the set of features in JVM supported on the corresponding platform. Sometimes the set of JSRs differ from one phone to another especially in the case of new JSRs. However, one caveat with JSRs is that the specification decides different functionalities as mandatory and optional. Thus a platform vendor might not implement a JSR fully (providing only mandatory functionality) and yet be JSR-compliant. Hence, it is necessary to not just compare the platforms in terms of JSRs supported but also to look deeper into the mandatory

and optional JSRs while making a decision on moving the code across different platforms. Table 2, identifies JSRs that are necessary to provide basic functionalities such as a GUI, file read-write, and CBS messaging. They are available on almost every device that supports J2ME including some low-end Nokia devices such as Nokia 2626 (typically S40 edition of Symbian phones) to all mid-range and high-end phones (typically S60 edition of Symbian phones) such as Nokia N series or E series devices. For our healthcare application, these JSRs are sufficient for most of the application scenarios. For advance functionalities, such as security mechanisms, one can use Bouncy Castle libraries. 1 They are open-source and provide many security mechanisms e.g. hash functions, RSA, AES, to mobile applications. Though JSR 177 also aims to provide the same functionality, it is not available on all phones. Use of Java (with limited JSRs) will enable us to overcome device heterogeneity and help in deploying our application on a wide range of devices. Other works on light-weight middleware [4] have also identified Java as an ideal cross-platform solution.

3.2

QoS for low bandwidth communication

Section 2.1 outlines several interfaces for remote communication with the mobile device. Low power consumption and wide feature availability across all phones (including low end phones) make SMS an excellent medium for connectivity. SMS packages are low-cost and widespread in India. SMS is also good for sending personalized information e.g. reminding a patient to take a medicine or visit a doctor. Several open source SMS based applications have already been proposed for healthcare applications [2]. However, when compared to high-end phones that use TCP/IP protocol for high-bandwidth communication, the QoS guarantees for SMS using low end phones are different from the standard TCP/IP connections. Some of these differences include: 1. Low bandwidth with a single SMS constrained to only 160 bytes 2. No congestion and flow control 3. No guarantee for message delivery (sometimes the delays experienced are of the order of multiple days). Therefore, to guarantee QoS while still taking advantage of the benefits of using SMS-based communication, there is a need to develop new approaches to deal with the challenges as mentioned above.

4

Localization

Each application, either modified or developed for Indian context will have several associated challenges. We specif1 http://www.bouncycastle.org/

ID JSR 118 JSR 139 JSR 75 JSR 120

API Mobile Information Device Profile(MIDP) 2.0 Connected & Limited Device Configuration (CLDC) 1.1 File Connection and Personal Information Management(PIM) CBS

Table 2: JSR IDs and their corresponding APIs ically selected the application of localization services (that return the current location of a mobile user) for discussion since they are useful across a wide range of applications including healthcare. As an example, in the healthcare domain, with doctors possibly being mobile, the mobile EMR system can get the current location of the doctor from the localization service and add it to patient’s data. Later, the location could be used for geospatial analysis of patients’ data. Localization in indian context is more challenging due to lack of extensive GIS databases and digitized maps. Traditionally, GPS, WiFi, and GSM technologies are used for localizing users. Google Maps Mobile for mobile phones3 primarily uses GPS and WiFi for localization. However, the GPS and WiFi technology can be used only on the high end phones with respective capabilities. With most of the low end phones, lacking the GPS and WiFi capabilities, GSM based localization is a good alternative as it only requires an active cellphone connection. Further, GSM based localization is more economical and energy efficient compared to using GPS and WiFi [6]. Google Maps Mobile are also extended to provide GSM based localization to be used for low end phones. We briefly discuss their service for comparative purpose while proposing an alternate solution that can be more accurate and does not require extensive database to be in place. GSM based localization from Google collects information about mobile service providers’ IDs, cell towers’ IDs, and corresponding GPS coordinates in a central repository. The repository is continuously updated by sourcing data from mobile users, who have GPS in their phones. In particular, for a user who has agreed to participate in collecting the data, his phone automatically sends messages containing its provider’s ID, the ID of the tower to which the phone is currently connected, and the current GPS coordinates of the phone. Note that the user can be located anywhere within the transmission radius of the tower. Therefore, the GPS coordinates do not precisely define the GPS coordinates of the cell tower to which the user is connected. Once an entry for a cell tower ID is created in the database, the location coordinates, even for the phones with no GPS but connected with the same cell tower, can be approximated by simply knowing the cell tower ID to which the phone is connected. However, such a database is underpopulated in India. Further, given that the cellphone operators change the IDs of the tower, even existing database gets invalidated. Therefore, a scheme using such a database has limitations. We propose an alternate GSM-based solution, which 3 http://www.google.com/mobile/maps/

does not use the ID of the tower to which a phone is connected. Instead, our approach uses Cell Broadcast Service (CBS) messages, that typically encode the name of neighborhood/landmark in which the tower is installed and the service provider-specific advertisement. We can filter the advertisements (as described later in the section) and use the neighborhood names for the localization purpose. The messages are periodically broadcasted to all the cellphone users in the neighborhood. CBS uses a different frequency space than the space reserved for SMS, call setup, call and data. This provides an advantage that even when the mobile device is connected to one specific cell tower, it can still receive CBS messages from multiple cell towers which are all in the range.As an example, Figure 3a presents the various CBS message received during duration of 7hrs 4min at a static location. Figure 3b plots the corresponding neighborhood names on those CBS messages and the actual location of the phone on Google Maps using an API that returns an approximate latitude and longitude given a well known location name. Note that in reality each name is an area on the map. But given the lack of easily available GIS databases in India, we couldn’t map those names in areas and had to approximate them to points. With the density of cell towers being typically large in Indian urban context, a mobile device is then expected to receive multiple CBS messages leading to an ability to perform triangulation and better localization accuracy than the one based on cell tower ID. The detailed comparison is beyond the scope of this paper. With the road names not typically well known and houses typically not numbered in a defined order in Indian context, people prefer directions in terms of landmarks. Therefore, a low resolution localization information, as provided by CBS based localization, will suffice in Indian context. For example, a drive from IIT Mumbai to Mumbai Airport can be described in terms traveling from Powai to Saki Naka to Marol to Andheri to Vile Parle to Airport. The actual road from a landmark A to geographically next landmark B is either known to the driver or can be inquired locally when he is physically present in A. However, even the CBS based localization has several associated research challenges as follows: 1. Sanitizing the locality names: The operators usually publish commercial advertisements in addition to the landmark names in their CBS messages as shown in Table 3. So, the first task is to write regular expression to filter the advertisements from the locality names. We used ”[0-9 — ’*’—’#’][0-9—’*’—’#’][09—’*’—’#’]+” as a regular expression to filter the locality names from the received CBS messages. The advertisement, containing the names of the service provide such as Airtel, do not contain any characters or digits. But they can be detected using a simple expression containing names of all the service providers. For each of our experiments, this regular expression resulted in 100% accuracy in filtering out the advertisement. 2. Clustering the neighborhood names: In Indian context, there is no standard for the nomenclature of the neighborhood in which a cell tower is located. Often CBS messages, even for the same neighborhood with

(a) Frequency of each received CBS message

(b) Mapping the received CBS locations using Google Maps

Figure 3: Experiments while keeping a phone static at a place for 7 hours CBS Message Received *567*1041#Hadycam MANSA RAM PARK Sevak Park Night Masti 58888 R7 Airtel

Classification Advertisement Locality Locality Advertisement Advertisement

Table 3: Classification of CBS messages different service providers vary in both convention and nomenclature. This requires an intelligent clustering mechanism to combine names for same neighborhood into a single location so that the localization service is applicable across all service providers. Based on some initial experiments, correlating the neighborhood name with local business operating in the neighborhood through the Internet search can provide an efficient way to provide efficient clustering.

5

Security and Privacy

With mobile phones becoming ubiquitous, security of the data being transferred and privacy of the user are increasingly becoming critical, even in Indian context. In this section, we look at the paradigm shift in the research (leading to specific solution designs) on security and privacy issues in India. While, security and privacy issues are integral part of architecture presented in Figure 1, we only focus on the security and privacy issues with the mobile devices in conjunction with the application scenario (i.e. mobile devices and the services needed in the application scenario). Security and privacy attitudes, awareness, and concerns in India (collectivist society) is very different from the developed nations, e.g. the US (individualistic society) [5, 9]. The expectations of security and privacy is lower from technologies (mobile applications) that are being used in India. This would possibly mean that a system with low level security and privacy settings may suffice the needs of users in India. Further, people in India do not hesitate to share their personal information to strangers (co-passengers) in the bus or in train. In India, one can also hear very personal conversation while sitting in metro trains. Studies have shown that people in India are also ready to share health

information about them and their family to others more than in developed nations [9]. Even though this data was collected for non-Internet (or non-pervasive) environment, it does apply to the mobile devices scenario as well. Specific to our healthcare application, when the doctors have to update or upload information about the patients, the mobile devices, don’t need to have provisions for high-end encryption or user defined privacy preferences. With most of the proliferation happening for low end device, the applications running on the phones (for authentication, etc.) should not be expected to do a lot of computation for encryption or similar activities. Authentication in India also happens through SMS, for example, when a customer is trying to create an account for online banking, upon request, he/she receives a SMS with credentials. The customer uses the credential to complete the process of creating the account for online banking. This type of approach rarely happens in a developed nation as SMS is not a preferred mode of communication there. This brings a new challenge, specific to Indian context, to make sure that the third parties (vendors who send the SMS) will not be able to sniff the information and use it for future crime; apply appropriate encryption so that the data can be deciphered only at the customer’s mobile phone. There is an increase in the services offered through SMS on mobile phones in India, including those for healthcare applications as discussed in prior sections. Criminals are making using of this increase to easily spoof SMS to send them as though it is coming from a legitimate number/person. There are cases in which criminals have used the SMS masking facility to perform malicious activities 4 . SMS spoofing is increasing day by day and there does not exist a viable solution for this problem yet in India. SMS spoofing is there all around the world (including developed nations), but given the use of SMS in India, the problem may get beyond control if not addressed properly.

6

Usability

As discussed in Section 5, the culture and context of usage of mobile phones in countries like India throws up 4 http://timesofindia.indiatimes.com/india/Terror-SMS-from-

your-cell-phone-number-Possible/articleshow/5707029.cms

some interesting and tough “usability” problems to study. The way mobile phones are used in India is different from using it in the US. For example, giving a missed call is something very prevalent in India, while it is not the case in the US; sending an SMS is very prevalent in India, people in the US rarely use SMS as primary means of communication. Researchers have shown that language differences create challenges in interfaces [15, 10]. Majority of the users in developing nations cannot read, write, speak English and therefore keypads on mobile phones have to be developed with local/regional languages [8]. Use of local language might turn out to be one of the primary requirement for designing phones in India. Researchers have also found that in developing nations like India, error rates in health care scenario while collecting through mobile phones is highest (4.5%) through electronic forms and lowest (0.45%) when the information is collected through voice [14]. Such studies initiate interesting discussion on voice vs text as medium for communication in Indian context.

7

Conclusions

Considering the penetration of mobile phones, they have a potential of becoming the intelligent computing devices for masses in the developing countries such as India. However, most of the work has been done for using high-end/smartphones and targeting people in the developed countries. Nowadays even low-end and middle-range phones are programmable and support features (such as CBS messaging) that are not yet explored. In this paper, we considered healthcare service as a highly potential mobile service of imminent use in Indian context. We divided the system of a mobile phone into different modules. Such a division allows us to consider each module independently from the perspective of associated challenges and novelties, illustrated through healthcare system. For example, at physical module we find that using audio port is more economical than bluetooth and USB is not technically feasible. Given the heterogeneity at the hardware and OS, use of Java provides portability of code. Communication using SMS and localization using CBS is less expensive and energy efficient. From, security and privacy point of view, the requirements are less demanding as compared to those in developed countries. Finally, we present changes at the usability module to satisfy the needs of common people. We hope that such an analysis can initiate specific discussions across several research areas in mobile computing domain. In future, we plan to address several of the research challenges and novelties outlined in this paper while learning from real world field deployments.

8

References

[1] Y. Agarwal, R. Chandra, A. Wolman, P. Bahl, K. Chin, and R. Gupta. Wireless wakeups revisited: energy management for voip over Wi-Fi smartphones. In Mobisys, pages 179–191, 2007. [2] Y. Anokwa, C. Hartung, W. Brunette, G. Borriello, and A. Lerer. Open source data collection in the developing world. Computer, 42(10):97–99, 2009.

[3] R. Ballagas, J. Borchers, M. Rohs, and J. G. Sheridan. The smart phone: A ubiquitous input device. IEEE Pervasive Computing, 5(1), 2006. [4] A. Bennaceur, P. Singh, P.-G. Raverdy, and V. Issarny. The iBICOOPf middleware: Enablers and services for emerging pervasive computing environments. In IEEE PerWare’09, pages 1–6, 2009. [5] H. G. Cultures and Organizations: Software for the Mind. McGraw-Hill, 1991. [6] S. Gaonkar, J. Li, R. R. Choudhury, L. Cox, and A. Schmidt. Micro-blog: sharing and querying content through mobile phones and social participation. In MobiSys, pages 174–186, 2008. [7] R. Heeks. ICT4D 2.0: The next phase of applying ICT for international development. Computer, 41(6):26–33, 2008. [8] D. S. Katre. Position Paper On Cross-cultural Usability Issues of Bilingual (Hindi & English) Mobile Phones. In In Proc. of Indo-Danish HCI Research Symp., 2006. [9] P. Kumaraguru and L. Cranor. Privacy in india: Attitudes and awareness. In Proc of the Workshop on Privacy Enhancing Technologies, 2005. [10] M. Lin and A. Sears. Constructing chinese characters: keypad design for mobile phones. Behav. Inf. Technol., 26(2):165–178, 2007. [11] D. McIntire, K. Ho, B. Yip, A. Singh, W. Wu, and W. J. Kaiser. The low power energy aware processing (leap)embedded networked sensor system. In IPSN, pages 449–457, 2006. [12] M. Michalakis, D. N. Kalofonos, and B. Shafai. An experimental hardware extension platform for mobile devices in smart spaces. In Proc. Intern. Conf. on Pervasive Systems and Computing, 2006. [13] T. S. Parikh and E. D. Lazowska. Designing an architecture for delivering mobile information services to the rural developing world. In WWW’06, pages 791– 800, 2006. [14] S. Patnaik, E. Brunskill, and W. Thies. Evaluating the accuracy of data collection on mobile phones: A study of forms, sms, and voice. ICTD, 2009. [15] C. Pornpanomchai, D. N. Batanov, and N. Dimmitt. Recognizing thai handwritten characters and words for human-computer interaction. Int. J. Hum.-Comput. Stud., 56(3):259–279, 2002. [16] M. F. A. Rasid and B. Woodward. Bluetooth telemedicine processor for multichannel biomedical signal transmission via mobile cellular networks. IEEE Trans. on Inf. Tech. in Biomedicine, 9(1):35–43, 2005. [17] M. Yamada, H. Watarai, T. Andou, and N. Sakai. Emergency image transfer system through a mobile telephone in japan: Technical note. Neurosurgery, 52(4):986–990, 2003.