4G wireless networks make it increasingly difficult to develop and test application software for mobile terminals in comparison with 3G or earlier generations. These 4G-networks will incorporate wireless LAN technologies and mobile terminals can access the services provided by LANs, as well as global network services. Therefore, software running on mobile terminals may depend on not only its application-logic but also on services within the LANs that the terminals are connected to. To construct a correct software to run in mobile terminals for 4G wireless networks and wireless LANs, it must be tested in all the networks to which the terminal could be moved and connected to. This article presents a new approach, called Flying Emulator, to test software designed to run on mobile terminals. Like existing approaches, the approach provides software-based emulators of its mobile terminals for software designed for running on the terminals. It is unique because it constructs emulators as mobile agents, which can travel between computers. These emulators can carry the target software to the networks that the terminals are connected to and allow it to access services, provided by the networks in the same way as if it was moved with and executed on the terminals connected to the networks. The article describes the idea of the approach, its implementation, and our experience with a typical application.
The development and testing of software for 4G-enabled mobile terminals may become more difficult than that for 3G or earlier generations. 4G wireless networks will incorporate wireless LAN (WLAN) technologies in addition to cellular networks and satellite-based network technologies. Then WLANs will not only provide high-speed wireless connectivity for mobile terminals, including smart mobile phones, notebook PCs, tablet PCs, and PDAs, but also will see a shift in the nature of mobile terminal applications. At present, the goal of most WLANs is still to connect mobile terminals to wide-area networks, such as the Internet. But, WLANs can have servers within the WLANs. In fact, several recent commercial and non-commercial WLAN hotspots have offered printing services and database services about resident information, e.g., restaurants and maps, which are available only within their coverage areas. As WLANs and 4G-wireless networks expand and develop, such location- or network-dependent services will become more commonplace.
However, it is very difficult to develop and test software designed to run on mobile terminals for 4G-mobile networks and WLANs. To motivate the development of mobile terminal software for 4G-wireless networks, it is helpful to have a single example scenario in WLANs. For example, a user will visit an office building and will have a terminal equipped with a short-range wireless link, e.g., IEEE802.11x or Bluetooth. Each floor in the building has a sub-network with WLAN access points and can provide different resources, such as database servers, for location-dependent navigation information on each floor. As a user moves from floor to floor with his or her terminal, some new servers will become available from software running on the terminal or it may no longer be able to access previous servers. As a result, such software depends on not only its application-logic but also on the services available on the current sub-networks. To construct correct software, the developer must test the software using the services available on each of the sub-networks that the terminal might be connected to. This is troublesome for the developer because nobody wants to run up and down stairs, physically carrying a terminal to test whether it can successfully access contents from appropriate databases in the current sub-networks and properly display the contents on the terminal. This is a serious obstacle to the growth of 4G-mobile networks, that incorporate WLANs. Nevertheless, the task of testing network- or location-dependent software has attracted little attention.
To overcome this problem, we need a software-testing approach suitable for 4G-enabled mobile terminals. Indeed, we introduced an approach, called Flying Emulator, for developing software that runs on smart mobile terminals, e.g., notebook PCs, tablet PCs, and PDAs. The key idea of the approach is to provide the mobile agent-based emulator of a mobile terminal, where a mobile agent is autonomous software that can travel from computer to computer. Like other software-based emulators, the emulator performs application-transparent emulations of its target terminal for application software. Since it is implemented as a mobile agent, it can also carry its target software to LANs that its target device may connect to and test the software inside the environments of LANs. That is, it emulates the physical mobility of terminals by using its own logical mobility over LANs.
The approach aims at testing network-dependent application software designed to run on mobile terminals that access services available on WLANs. Emulating the performance of wireless networks. That is, bandwidth and connectivity latency cannot be addressed.
To test software for mobile terminals using WLAN and 4G-wireless networks, our approach should satisfy the following requirements.
Cooperation among mobile terminals and servers within a domestic or office network is indispensable because such cooperation will offset various features missing in the terminals. As terminals move, they may be disconnected from the current network and then reconnected to another network. A change in network and location may indicate movement away from the servers currently in use, toward new ones. A lot of work has been proposed to either transparently mask variations in mobility. For example, mobile IP technology may be useful for maintaining a terminal's connections to services in the source networks even if the terminal moves across LANs. On the other hand, terminals are often required to link up local services, provided by the current LANs, to access information available at the current locations as well as remote servers. As a result, application-level software running on moving terminals must treat the differences between the services available in the source networks and those available in the destination networks.
Mobile terminals are often managed by using service discovery mechanisms that use multicast communications to find their servers and terminals to be managed, Universal Plug and Play (UPnP) and such as Sun's Jini. These multicast messages can only be transmitted to the hosts within specified sub-networks. Therefore, to test the target software designed to run on the terminal, we must execute and test it inside a sub-network, to which the terminal can be connected.
The approach needs to avoid the movement of the developer in the testing of software. It also should be simple enough for end-users to use in testing. It must be able to run on servers, without requiring custom hardware. Application software often has its own graphical user interface (GUI), so the approach should enable the developer to test his or her target software, including its graphical user interface. All applications successfully tested in the emulator should still be performed in the same way without being modified or recompiled.
The creation of location- or network-dependent contents, e.g., museums guides on portable terminals, is as difficult as the development of location- or network-dependent software, because the creators must test their content, which is designed for being displayed on terminals, whether or not the content is valid at the locations the terminals move to. The approach should display and operate visual content for terminals.
There have been several approaches to testing software that will run on mobile terminals. We can classify these approaches into four types, as follows.
The first approach is to carry the target terminal to the LANs that the terminal may move and connect to, and test the target software running on the terminal with the servers. However, compared to desktop/notebook computers, typical mobile terminals have only limited computational resources, e.g., restricted levels of processing power, memory capacities, and poor user interface devices, e.g., clamped keyboards and small screens. Therefore, it is difficult to debug and monitor software within the terminal itself. This should only be resorted to in the final phases of software development. In other approaches software-based emulators are useful on behalf of the target terminals to solve this problem. In fact, many commercial mobile terminals, such as palm-sized PDAs and smart mobile phones, provide software-based emulators that can run on workstations and simulate the terminal execution environments. However, most existing emulators simulate only the internal execution environments of their target terminals. On the other hand, the correctness of the software running on the terminal depends on its internal execution environment and also the external environments provided by the network that it connects to.
The second approach is for the developer to physically carry the workstation that runs an emulator corresponding to the target terminal and connecting it to LANs that the terminal might move to. It can also inherit the advantages from software-based emulators, including fast turnaround time, source-level debugging, and fast execution. Like the first approach. its target software is executed within the LANs, so that it can directly access the servers provided by the LANs. However, this is difficult to actually carry the workstation to another location and connect it to the LANs in that location, even when the workstation is a portable notebook PC.
The third approach is to simulate the terminal's external environments inside local workstations. For example, Nokia provides a network server interface simulator, called Nokia Mobile Server Services, in addition to terminal emulators for their terminals. The simulator enables messages to be sent from server-side applications to a terminal emulator, and forwards messages from the terminal emulator to server-side applications. Also, several integrated development environments (IDEs), e.g., Microsoft Visual Studio and Eclipse, can be opened to provide tiny database servers and directory servers, inside the local workstations. However, it is almost impossible to exactly simulate all the services and content available in each of the actual LANs that the target terminal may connect to, inside the local workstations.
The fourth approach enables software designed for mobile terminals, to run in software-based emulators on local workstations and remotely access actual servers, instead of pseudo ones, through networks, e.g., the InfoPad project at Berkeley and Lancaster University's network emulator. However, accomplishing this in a responsive and reliable manner is difficult, and the emulators may not be capable of remotely accessing all the services within the LANs because of security protection. Moreover, the approach is not suitable for testing software using multicast communications, including service discover mechanisms, such as Jini and UPnP, and some ad-hoc networking protocols, because the reachable domains are limited within specified sub-networks to reduce network traffic. It is almost impossible to forward a large quantity of multicast-packets, which will spill over into sub-networks, to the target software, running on an emulator, in other networks via the Internet.
The existing approaches described above have their own strengths and weaknesses. This article proposes an innovative approach for testing network-dependent software on mobile terminals. The goal of this approach is not to compete with the existing approaches but to complement some of their problems. Like the three other approaches, our approach provides software-based emulators for terminals. The key idea of this approach is to implement emulators as mobile agents that can travel from computer to computer under their own control. When an agent moves to another location, the agent transfers its state, as well as its code, to the destination. After arriving at the destination, it can still continue its execution. Therefore, our mobile agent emulators can carry the code and the state of their target software to the destinations, so the carried software can basically continue its processing after arriving at the new host in the same way as if it had been physically moved with the target terminal.
The physical movement of a mobile computing computer from one LAN to another LAN is simulated by the logical mobility of a mobile agent-based emulator with the target software moving from an APH in the source LAN to another APH in the destination LAN. Each emulator permits the target software to access servers and multicast-based services provided in current networks and can have its own itinerary that corresponds to the physical movement pattern of its target terminal. Each APH is a server offering a runtime system for the execution and migration of mobile agents, including mobile agent-based emulators. Additionally, it is lightweight and does not need any custom hardware.
Each mobile agent-based emulator can carry and test software, designed to run on its target terminal. The above figure shows the structure of a mobile agent-based emulator running on an APH. The current implementation of the approach is built on Java and provides mobile agent-based emulators for typical notebook PCs, PDAs, tablet-PCs, and smart phones. Although the approach itself can support native software, we will hereafter describe mobile emulators for testing software written in Java (J2SE, JDK 1.1, Personal Java, or J2ME CDC), to illustrate how to emulate the mobility and connectivity of terminals, rather than the terminals' execution environments.
When an emulator migrates between APHs, its target software is transformed into a bit-stream along with the states and codes of the target software with the emulator. Then the software and emulator are transferred to the destination APH. The destination APH retrieves the software and the emulator from the bit-stream. The current implementation uses Java's standard JAR file format, which can support digital signatures for authentication, to pass them. The developer can control the movement of the emulator interactively through the RCS. Also, each emulator can have its own itinerary, a list of APHs that corresponds to the physical movement pattern of the target terminal.
Typical mobile terminals assign execution modes, which stationary computers may not have, on their application-level software. Accordingly, we divide the life-cycle states of the target software into three phases: networked-running, isolated-running, and suspended. Networked-running mode refers to the target software running and connecting to a LAN in the current location. In this mode, the software running in the emulator is allowed to link to servers on the LAN through the current APH. Isolated-running mode means that the terminal is still running but disconnected from the LAN. In this mode, the software still runs in the emulator, but is prohibited from communicating with any servers on the current LAN. The suspended mode corresponds to that of a terminal that is sleeping to save battery life and it avoids the risk of accidental damage while moving. In this mode, the emulator stops the target software.
This approach assumes that each terminal can connect to at most one LAN through a wired or wireless network. When a terminal is moved and reconnected to a different LAN, the software running on the moving terminal goes into a suspended mode and becomes the networked or isolated-running mode. The emulator can dispatch certain events to the target software to explicitly restart (or stop) its activities and acquire (or release) the computational resources of the current APH when the life-cycle state of the software is changed.
The emulation of the internal execution environments of terminals is basically the same as that of other existing software-based emulators. Since each mobile agent is a general program, the approach can embed a processor-instruction interpreter, which can execute software for the processor in the same way as if it were being executed by the processor, into a mobile agent. If its target software is written in Java, the Java virtual machine can shield the target software from many features of the hardware and the operating systems of mobile terminals. As a result, mobile emulators for Java software can be simple. They permit their target software to have access to the standard Java classes commonly supported by the Java virtual machine as long as their target terminals offer the classes.
Each emulator offers its target terminal's typical computational resources, e.g., file storage and I/O ports. To store and access files, the emulator maintains a database as a pair consisting of its file/directory path name pattern and its content inside it. The emulator provides basic primitives for file operation, such as creation, reading, writing, and deletion; it allows the developers to insert files into itself through the RCS. Furthermore, the approach offers a mechanism that enables its target software to access equipment running on remote computers via serial ports. The mechanism consists of proxies whose interfaces are compatible with Java's communication APIs and can forward the port's signals between the emulator and the RCS.
The target software running in a mobile agent-based emulator can interact with servers and other software running on the same or different emulators on the current LAN, and the Internet when the LAN is connected to the Internet. The current implementation simply maps the terminal's TCP/IP stack onto the TCP/IP stack, provided in the current APHs, to simulate IP connectivity. Mobile agent-based emulators for Java software inherit most network resources, including the current APH's IP address and TCP/UDP ports, through Java classes for networking, such as java.net and java.rmi packages. An emulator cannot have its own network identifier, but this is not a serious problem, as long as the target software is client-side.
This approach also has a mechanism for simulating many basic characteristics of wireless networks, such as disconnection and reconnection. This mechanism overrides Java's classes for network operations, e.g., java.net.Socket and java.net.ServerSocket, with customized classes that emulate those characteristics of wireless networks, by using bytecode rewriting techniques.
The displays and keyboards that most mobile terminals are equipped with are limited. Each emulator can explicitly constrain such user-interfaces available through the target software by using a set of its customized Java AWT classes. It can also provide pictures of the target terminal's physical user interface as it would appear to the end-user. Typical mobile terminal will include a screen that may allow the content to be displayed. Therefore, the screen is seamlessly embedded into the terminal pictures, and the basic controls of the terminal can be simulated through mouse-clickable buttons. We can display the user interface of the target software with the pictures of the terminal on the RCS's screen and operate it from the RCS's standard input devices, such as a keyboard and mouse.
The above figure shows the RCS's screen. To save the developer the trouble of testing the target software running in an emulator, our approach allows the developer to sit in front of the RCS. The developer can control the migration of each emulator and the execution mode of its target software through the graphical user interface displayed on the RCS. The RCS can run on standard workstations without any custom hardware. It is responsible for managing the whole system. It can always track the locations of all the emulators, because each APH sends certain messages to the RCS whenever a moving emulator arrives or leaves. It can also monitor the status of all APHs by periodically multicasting query messages to them. Software successfully tested in the emulator could still be run in the same way on the device, without modifying or recompiling it.
Each APH provides a runtime system for executing the mobile agent-based emulator and migrating it to another APH. The current implementation uses our Java-based mobile agent system, called MobileSpaces, but the approach itself is independent of the system and can be easily built on other mobile agent platforms. The MobileSpaces runtime system supports a built-in mechanism for transmitting the bitstream over networks by using an extension of the HTTP protocol. In almost all intranets, there is a firewall that prevents users from opening a direct socket connection to a node across administrative boundaries. Since this mechanism is based on a technique called HTTP tunneling, emulators can be sent outside a firewall as HTTP POST requests, and responses can be retrieved as HTTP responses.
The left window of the above figure is the picture of a terminal that the user interface of the target software tested in an emulator on a remote APH is embedded in. To test the user interface of the target software running on remote APHs, we used existing remote desktop systems. The current implementation uses the Remote Abstract Window Toolkit (RAWT), developed by IBM. This toolkit enables Java programs that run on a remote host, to display GUI data on a local host, and receive GUI data from it. The toolkit can be incorporated into each APH, thus enabling the graphical user interfaces of application software running in a visiting emulator to be displayed on the RCS's screen and operated using the RCS's keyboard and mouse. Therefore, the developer can always test his or her target software, including their GUIs, within the RCS, and the APHs do not have to offer user-input and user-output devices, or any graphics services.
The current implementation uses Java's object serialization mechanism as a mechanism for transforming the emulator for Java software and the target software into bit-streams, that can marshal the heap blocks of a program into bitstreams, but not stack frames. Therefore, it is impossible for any active threads to migrate from one virtual machine to another while preserving its execution state. This problem can be solved when APHS supports persistent Java virtual machines, e.g., PJava developed by Sun Microsystems and the University of Glasgow, that preserve all the Java objects' execution states, including threads and stack frames. However, such persistence-extensions of Java are still premature for attaining our goal, because they cannot transfer most computational resources and do not often coexist with essential optimization techniques for the Java language.
Security is essential in mobile agent or code techniques. This problem in our emulators becomes not serious, because they are used in only the process of software development. APHs can inherit the security mechanism of the underlying Java virtual machine and mobile agent system so that restrict agents so that software running in an emulator, can only access specified resources to protect the APHs from incorrect or malicious software.
In this section, we describe some experience with the approach through testing a prototype navigation system, which is a typical application of mobile terminals equipped with conventional wireless LAN interfaces. As the system described in the first section of this article, the system guides a visitor to the National Institute of Informatics's building. Each floor has its own local area networks and one or more WLAN access points. We assume that each visitor has a small tablet-PC to access location-dependent information from the database servers provided within the sub-network of the current floor via IEEE 802.11b. As a visitor moves from floor to floor, the tablet PC leaves the previous sub-network and joins a new one. A map-viewer application running on the terminal automatically accesses location-dependent information, e.g., maps on the current location, from the database and displays the information on the tablet PC's screen. To test the system, we constructed a mobile agent-based emulator that corresponds to the tablet PC. The emulator could migrate a map-viewer application to an APH in the sub-network of another floor and enable the application to access the local database of the floor, via the APH and display maps on the RCS's screen.
The above figure shows the target tablet PC (Sony VAIO Type-U with Windows XP) running the target software that is tested in our emulator. Both the application running on the emulator and the application running on the target terminal presented the same navigation information. That is, the tested application ran in the target terminal in the same way as it was executed in the emulator. The system uses a multicast-based service discovery technique for visiting tablet PCs to automatically detect database servers. That is, each server periodically multicasts advertising messages within the domain of its sub-network to provide its network address to visiting tablet PCs. Since software running in the emulator directly uses the current host's APIs for UDP-based networking, the emulator receives UDP-multicasting messages from servers in the domain as if the software were joined to the domain.
Furthermore, this example shows that this approach can provide a powerful method for testing not only application software for mobile terminals but also for creating location-dependent contents, such as maps and annotations about locations. It can test server-side systems and contents, when client-side terminals access them. Moreover, by using a remote desktop system, e.g., IBM's RAWT toolkit, this approach enables the content creator to view the location-dependent information that should be displayed on the tablet PC on the screen of his or her stationary RCS and to operate the software from the RCS, even while the viewer application runs in an emulator on remote APHs and accesses servers at its current location. Also, since the emulator can define its own itinerary for multiple access points, it can automatically follow the complex mobility patterns of visitors and test the contents displayed on the screen of the tablet PC. This is useful in the development of track-dependent contents in addition to location-dependent ones.
We have described an approach to testing software designed to run on mobile terminals for 4G wireless networks and wireless LANs. The approach enables the application-level software to be executed and tested with with the services and resources provided through its current network as if the software were being moved and executed on that target device when attached to the network. Software tested successfully in the emulator can be run in the same way on the target device without being modified or recompiled. Our early experience indicated that by using the approach we can greatly reduce the time and cost required to develop network-dependent software for mobile terminals with wireless-LANs.
There are further issues need to be resolved. Our approach will be available in emulating and testing application-level ad-hoc networking, since it can model the deployment of mobility of mobile terminals on different reachable sub-domains. The approach does not support terminals, which connect to multiple networks and reconnect to new networks while they are running. This limitation does not lose the utility of the approach. Nevertheless, we plan to support the emulation of seamless roaming of terminals, including multi-input and multi-output (MIMO) connectivity.
