Universal Service Terminal: Evolving towards the TSE in MUSE Wang Xu Wireless Technology Innovation (WTI) Institute Beijing University of Posts and Telecommunications (BUPT) [email protected] Abstract The future mobile applications should be personalized, adaptive, and context-aware. And the future mobile communication system will aim to bring the Always Best Experience (ABE) based on personal preference to users. In the terminal aspect, technologies used to access heterogeneous networks and integrate facilities from apparatus are studied for a few years. Universal Service Terminal (UST) is a novel terminal architecture based on aggregations of components through personal area networks technologies to bring ABE to users. The UST no longer restricted to overcome the obstacles from heterogeneous network, on the contrary, it employs the different capabilities provided by heterogeneous networks to bring more experiences to users. The UST introduces an extensible framework, which can adjust the terminals capability dynamically according to the context even when applications are running, and the extensible and open architecture of UST will make it possible to support more personalized and professional applications to users with ABE utilizing capabilities provided by professional devices. Keywords: terminal, personal area networks (PAN), mobile communication

1. Introduction Today, with the emergence of more and more Intelligent Apparatus (IA) in human life, the personal area networks, home networks, vehicle area networks, etc. becomes more and more capable. However, todays applications cannot employ the capabilities of these networks to bring users experiences[1]. The personal area networks are more capable on context-awareness[2, 3, 4] and have more flexible structure to handle the context on the lower layers, but the local networks have few interactions with the wide area networks, e.g. cellular networks, and the applications in the WAN. On the other hand, the terminals evolve from singlemode to multi-mode and terminal utilizing Software Define Radio (SDR[5]) to overcome the inconvenience from the heterogeneous networks; however, a common terminal can

access different access networks may restrict the utilizing of the potential of every access network. Focusing this inadequacy, we have defined a research program Universal Service Terminal (UST), which is based on our previous research on terminal technologies and VHE[6] concept. To bring best experiences to users, it is obvious that application should be able to employ the capabilities provided by different components and the capability of handling context. The terminal should have several ways to access and present applications, and it should be able to select one best way or a combination of the ways based on the users personal preference to bring him (or her) the best experiences. Following this view, a new terminal technology should have an extensible architecture, and should support to provide applications employing the capabilities of devices in the users personal environment. As shown in figure 1, a UST should be a distributed terminal, in which the components are interconnected through an ad hoc network or a structural network, in which the nodes and/or the topology may change dynamically. And the components in a UST may be cellular terminals, intelligent apparatuses, vehicle devices, and some professional instruments etc. through which the UST can access WAN and applications there, and present applications to the user. The UST will provide a set of standardized interfaces to networks and service providers, through which they can provide applications to a single powerful virtual terminal rather than couples of components and utilize the capabilities provided by the devices in the users personal environment. In the long run, to detonate the potential of UST, it will become a part of the Mobile Ubiquitous Service Environment (MUSE[7]) as the Terminal Service Environment (TSE), which will cooperate with the Network Service Environment (NSE) to provide Always Best Experiences (ABE[7]) to users. This paper is organized as follows. In Section 2, the system architecture of UST will be provided. And in section 3, we define the basic procedure of UST. Finally, we summarize our major findings and outline our future work.

Figure 1. The Illustration of UST

2. The UST System Architecture We define UST as a virtual terminal, which can utilize connection technologies of wireless or wired network, e.g. PAN etc., and aggregate components having one or more terminal capabilities according to the preference of the user. It is an intelligent distributed terminal, which can employ the different capabilities of different components to provide and present services jointly, or the identical capabilities of different components to provide and present the services cooperatively. And in this section, we will introduce the architecture of UST system.

2.1. Functional model of UST As above description, the UST will provide a set of standardized interfaces to networks and service providers, through which they can provide applications and employ the capabilities provided by the components in UST. And for the extensibility of the terminal, the UST should provide another set of standardized interfaces to enable the dynamic join and exit of components. All of the above

interfaces, together with the AAA functionality, should be provided by a framework[8]. The UST should also have an Execution Environment[9], on which the local applications or clients of applications run. And the Execution Environment should dispatch the tasks from applications to corresponding capability servers, which provide the capabilities of components. The functional model is shown as figure 2. In figure 2, the applications may run either on the terminal totally or on the platforms of service providers, in which condition, the clients of the applications, which may be downloaded from the air or burned in the firmware, should run on the terminal. The framework provides interfaces to applications for initiating it, including authentication, capabilities discovery, etc. It also provides interfaces for the Execution Environment to get capabilities accessibility information, and for capability servers to register themselves. And the applications or their clients should run on the Execution Environment, which should dispatch the tasks to corresponding capability servers. And the information of the accessibility of the servers comes from framework and is based on the context and users personal policy on the

Figure 2. The Functional Model of UST applications. Thus, the user preference plays significant role in a UST, and in next subsection we will introduce the User Identity and User Information in UST.

2.2. User Identity and User Information in UST User Identity (UID) in UST exclusively represents a user entity, such as a real subscriber, a group of subscribers, or corporation user, etc., which subscribes a series of special services and has a set of preference. Besides the UID, User information also includes the subscription information, the user preferences on applications and User Interface (UI), and control policies of the user, which may be variable based on the context, e.g. the user may employ more restricted security and privacy policies in a coffee bar than at home. The user information may locate in some local media, e.g. SIM, and some of the User information may be stored in the operators network and with a URL in local media. To build a UST, the User information must be accessible, i.e. it should be contained in one of the available components or it can be access from the URL available through network connection. Thus the component containing the basic User Information and/or the URLs should be the essential element of UST, and be referred to as the primary component.

2.3. Components in UST Components with different capabilities make up of the UST, and they should have an identical architecture to interconnect each other and provide their capabilities to applications. The architecture of component in UST is shown

in figure 3. The framework and Execution Environment may provide the correspond functionality of the whole UST, and are optional in a component. However, it is obvious that there must exist at least one component in UST, which provides the framework and the execution environment. One component must have an aggregating control module. It shall control the procedures about components aggregating interacting with the framework of UST when the components need to be aggregated into a UST, be departed from a UST, or change its capabilities. And it controls the status of component in UST and reports it to the framework. One component may have one or several capability servers, which wrap the capabilities provided by the component. The Execution Environment of the UST will employ the capabilities on behalf of applications through RPC[10] services provided by capability servers and hiding the distribution of components from applications. Both OS and hardware can be referred to as the physical resources and provide the capabilities. UST shall not specify the interfaces of physical resources, i.e. UST is OS/hardware platform independent and only specifies a set of open interfaces, which may be provided by middleware. However, it is obvious that the OS/hardware must support the interconnection with other components.

3. Basic Procedures in UST The basic procedures related to the UST include the aggregation of the terminal, the migration of the framework

Figure 3. The Architecture of Component in UST capability, the login, logout, or capability change of the components, and the invocation of terminal capabilities. By all of the procedures we mentioned, the UST could provide best capabilities to support applications according to the users preference under different contexts. In this section, we will introduce them in brief. Some of the procedures are shown in figure 4 briefly, and others are similar.

3.1. The Aggregating of a UST

The terminal aggregating procedure is the construction procedure of the service execution environment of a UST. The primary component and its framework play the key roles in this procedure, which register the capabilities of components and add them into the terminal to build a distribution system. As shown in figure 4(a), the first step of aggregating is to build a minimum UST containing the only primary component. It provides some capability servers, runs the Execution Environment, loads User information to framework, and activates it. Then the other components can login and provide capability servers.

3.2. The Migration of the Framework Functionality The framework migration is the procedure defined as when there are several components that can provide framework in the service environment, if it is found that some of the component is more suitable to be the master component than the current one (which has the active framework) according to the components capabilities and the user preference, then the framework of that component will be activated and the users relative profiles or its URL will be transferred to it.

3.3. The Login, Logout, or Capability Change of a Component The login, logout, or capability change of the components procedure will occur when the uses context (e.g. location, status, or environment) has changed. Some components will login or Logout the UST and others may modify its capabilities, which can affect the running of the framework or applications. In the login procedure (figure 4(b)), the framework will send a notification to applications employing the capabilities that can be provided by the new component after registering it. On the contrary (figure 4(c)), the component

(a) The aggregating of UST

(b) Components Login

(c) Components Logout

(d) Changes from Applications

Figure 4. Some of the Basic Procedures in UST should wait for the related applications acknowledging the coming change before the component can be safely removed. And the capability change of a component procedure is similar to the above. All of these procedures are under the control of UST framework.

3.4. The Invocation of Capabilities The invocation of capabilities includes the discovery, request and invocation of the capabilities. The request, invocation and release of the capabilities may lead to the status change of some components, i.e. the status may change from idle to active or the contrary. The applications may request for capabilities during either its initialization or run-

ning.

4. Summary The UST is such a novel concept of virtue terminal that can utilize connection technologies of wireless or wired network, and aggregate components having one or more terminal capabilities according to the preference of the user. It is an intelligent distributed terminal, which can employ the different capabilities of different components to provide and present services jointly, or the identical capabilities of different components to provide and present the services cooperatively in order to bring ABE to users. Our research of the concept of UST is not restricted to

extend the traditional terminal’s connection capability, but concentrate on the upgrade of the terminals capability to bring more experiences to users. Moreover, it is no longer restricted to overcome the obstacles from heterogeneous network; on the contrary, it employs the abundant capabilities provided by heterogeneous networks and the service presentation capability of the apparatus around the users to bring more experiences to them. In the further research of UST we will consider the services, networks, ad hoc networks[11] in terminals, and terminal components jointly, and a component may have dynamic changing capabilities. Based on the support of the UST framework, when the context (e.g. users environment and status, the services status, etc.) has changed, the terminal is able to adjust the service support capability dynamically according to the users preference by the perceiving and reconfiguration of the components in the environment to realize better extensibility in order to provide ABE to the users in the future.

References [1] TT Ahonen and J Barrett, Services for UMTS: Create Killer Applications in 3G, John Wiley & Sons, LTD., West Sussex, 2002; [2] BN Schilit, N Adams, and R Want, Context-aware computing applications, Proceedings of the Workshop on Mobile Computing Systems and Applications, 1994; [3] GD Abowd, CG Atkeson, J Hong, S Long, R Kooper, and M Pinkerton, Cyberguide: A mobile context-aware tour guide, Wireless Networks, 1997; [4] A Harter, A Hopper, P Steggles, A Ward, and P Webster, The Anatomy of a Context-Aware Application, Wireless Networks, 2002; [5] SDR Forum, http://www.sdrforum.org ; [6] 3GPP TR 22.121, The Virtual Home Environment (Release 5), V 5.3.1, 2002; [7] Ji Yang, Zhang Ping, and Wang Xu, MUSE and ABE concept, WWRF11, Oslo, June 2004; [8] Parlay Group, http://www.parlay.org ; [9] 3GPP TR 23.057, Mobile Execution Environment (MExE) (Release 6), V 6.2.0, 2003; [10] G Coulouris, J Dollimore, and T Kindberg, Distributed Systems: Concepts and Design, Third Edition, Person Education Limited, 2001; [11] CK Toh, Ad Hoc Mobile Wireless Networks: Protocols and Systems, Prentice Hall PTR, New Jersey, 2002.