An Ubiquitous Service Mobility Mechanism in the Cross Domain Service Framework ()
1. Introduction
Beyond the convergence of simple networks, convergence services that accept various contents, application programs, service platforms, mobile devices, PCs, TVs, and so on are beginning to earn interest. Current convergence services focus more on network convergence, where heterogeneous devices and services are provided by a single network. On the other hand, device convergence provides devices that support heterogeneous services over several networks such that the services are provided using a device’s capability of changing networks seamlessly. Recently, the convergence of services with content streaming over multiple network domains and devices using the unique characteristics of ubiquitous devices, such as 3-screen play [1,2], are entering the spotlight. The design of a convergence service should address mobility, heterogeneity, and user-centric issues [3]. There are two types of mobility: terminal and service mobility. Terminal mobility, as the classical part of mobility management, places devices at the endpoints of communication, and focuses on connection continuity over a change of access points [4]. Therefore, in order to provide consecutive communication, location and handoff of a mobile terminal is managed at four different layers of the International Organization for Standardization’s (ISO) Open Systems Interconnection (OSI) modelnamely, at the link, network, transport, and session layers. It is well known that the representative research on network layer terminal mobility is mobile IP [5]. Service mobility, on the other hand, is considered as maintaining a connection even when terminals or networks are changed due to user movement or personal preference [4]. Focusing on service mobility under user movement and heterogeneous devices, a major problem with this service convergence is to build a platform that is applicable to services supported by heterogeneous service platforms and devices with their own platforms. A platform for convergence services plays the role of an infrastructure to execute content and application programs smoothly without obstacles, and provide interoperability between devices and services. We propose an open service platform to provide the facilities stated above.
The open service framework presented in this paper is a platform that supports convergence services on devices, such as Windows PCs, Linux PCs, mobile and smart phones, and the service platforms of each device. The framework recommends the best available service for the user and device, and then constructs and executes a service execution engine for the selected service on the connected device. As the user changes the device due to movement or personal preference, the service is provided continuously with transformed content suitable for the new device.
Starting with Section 2, where various service mobility architectures are revised, we go on to present our open service framework in Section 3, where the features of the OSCD service framework to support convergence service including various service platforms and service mobility are described in detail. The prototype implementation used to verify the feasibility of the proposed service framework is described in Section 4. And finally, we summarize and conclude the paper in Section 5.
2. Related Works
There have been several studies on service mobility with user migration. The authors in Ref. [6-8] have addressed the issue of integration of heterogeneous networks. The authors in Ref. [6] and Ref. [7] have proposed the Mobile People Architecture (MPA), which aims to put a person, rather than the devices the person uses, at the endpoints of a communication session. MPA enables users to contact each other from anywhere, using a variety of communication media such as email, telephones, and ICQ messages. MPA uses a globally unique Personal Online ID to identify a user, and utilizes the personal proxy located at the user’s home network for location tracking. In this architecture, the personal proxy achieves the function of personalized and continuous service. The ICEBERG project [8] aimed to integrate cellular telephony networks with the Internet. Just like MPA, ICEBERG had the view that people will continue to use multiple devices and networks for communication. As the ICEBERG network is an overlay network of iPOPs on top of the Internet, it needs a modification of existing network components. MPA and ICEBERG emphasize providing contactability and reachability rather than a user-centric personal operating environment.
Mobile agent based frameworks [9,10] were proposed to provide personal mobility in accessing Internet services. NetChaser [9] supports three Internet services, namely, Web, e-mail, and FTP using four assistants: user, HTTP, mail, and FTP assistants. Assistants operate at a proxy server close to the user. NetChaser traces the user’s network location and records the history of service, so as to offer users the ability of maintaining service in spite of the change of terminal identity. NetChaser supports a personalization scheme only. In order to provide true personal mobility that requires the integration of contactability and personalization, Ref. [10] suggested an Integrated Personal Mobility Architecture (IPMoA). IPMoA is a mobile agent based personal mobility framework that utilizes mobile agents. There are three agents: personal application assistant (PAA), personal file assistant (PFA), and personal communication assistant (PCA). These three assistants migrate to the visiting network’s agent execution environment. These mobile agent based frameworks are organized similarly to how home agents and foreign agents are organized in Mobile IP, since they also use two subnets to locate and trace the user in this model. Therefore, the session establishment may take longer than a direct connection. Furthermore, the application time may also be longer than executing the applications on a local machine.
One important thing in service mobility is to keep the service session even when terminals or networks are changed due to user migration or personal preference. Maintaining the service session means providing people with seamless and continuous service when they change networks or terminals as they migrate. Also, it provides service synchronization by managing personal-servicespecific information in a heterogeneous service platform. However, previous works have not addressed this session mobility issue
3. One-Service-Cross-Domain Service Framework
We propose a one-service-cross-domain (OSCD) service framework as an open service framework to support convergence services. It is a technology to generalize a ubiquitous computing environment by providing an environment that eases execution and combination of domain-subordinated services and/or contents by organically integrating independent service domains. Therefore, the OSCD service framework is an optimized integrated service framework that provides continuous services that are not constrained by physical user environments such as multimedia transmission, integrated information management and preservation, educational broadcasting, and games. Figure 1" target="_self"> Figure 1 shows the structure of the OSCD service framework.
The OSCD service framework supports the registration of service and execution engines using profiling models, and performs automatic detection of a suitable service execution engine. The framework also supports a search function for services that are suitable for the user and the targeted terminal device. Moreover, it supports real-time content adaptation for targeted terminals, semantic translation including a communication protocol translation, and seamless service continuity so that a user can continue using a service across different terminals.
3.1. Profile Modeling
In order to provide the best service depending on a particular user context, support for flexible management and a decision process based on an accurate and clear description of contextual information is required. In the proposed system, a particular context is divided into three conceptual domains: terminal device, service, and
Figure 1. The proposed service framework.
execution engine, which provides a running environment for the service. Each domain is described by the name of the profile.
• Device Profile. The device profile describes the currently available resources and status of the terminal device available for running execution engines. The resource and status are represented by sets of terminal device attributes including specifications of hardware/ software/network characteristics and data gathered by sensors in the device.
• Service Profile. Each service in the proposed system has a service profile to describe its attributes. A service profile implicitly declares the minimum requirement of the execution engine for proper delivery of service.
• (Execution) Engine Profile. The execution engine, software that runs on the terminal device to deliver a service to the end user, has device resource requirements and service attributes the engine can provide. The engine profile implicitly declares the minimum resource requirements of the device and the functional specifications of the engine.
Each profile is described by a proprietary description scheme similar to UAProf [11], a concrete implementation version of CC/PP [12] based on RDF [13]. Each profile, according to the representation scheme of CC/PP, contains one or more components, where each component consists of sets of attribute-value pairs where attribute/component names, data value types, and their resolution types are defined and constrained by the vocabulary and schema. Attributes in the implemented vocabulary are categorized into five components by their logical relativity: hardware, software, network characteristics of terminal device, multimedia, and network capability of service. Attribute value types are defined in the schema, and include Boolean, number, literal, literal-bag (set of literal arguments without sequence), literal-seq (set of literal arguments with sequence), dimension, and range.
The proposed system needs contextual information to be delivered from a device to a server upon the server’s request only when a user is logged into the designated server using the user’s terminal device. Since the delivery is always initiated by the server, self notification of changed context as in SLP [14], Jini [15], and uPnP [16] are not required. Moreover, since user preference information and service/engine profiles are always located at the server side, it leaves the device profile as the only contextual information that needs to be delivered.
The device profile is presented by a combination of reference profile Unified Resource Identifier (URI) and/ or profile fragments with static/dynamic attributes. While URI and static attributes are required to be delivered only once at the initial phase, dynamic attributes should be delivered at any time upon a server’s request in order to reflect a change of device status. Therefore, unlike HTTP or Wireless Session Protocol (WSP)-based profile exchange mechanisms [17,18] used in CC/PP and UAProf, a new delivery mechanism supporting both partial and on-demand profile delivery is proposed. The proposed delivery mechanism separates on-the-run profile delivery from the initial static/dynamic profile delivery. Hence, only the updated status is transferred to the server at the minimum network cost by sending a profile fragment containing updated attribute values only. Figure 2 illustrates the device profile delivery scheme for the proposed system.
The fact that all profiles in the proposed system use a
Figure 2. Profile delivery in the proposed system.
common description scheme based on a single schema, lead to the use of a single modeling mechanism, it enables the implementation of a simple comparator for simple reasoning and decision processes. Each profile is processed into an RDF-based model with functions for merging and updating profile fragments and dynamic attribute values, using Jena [19], a Java framework for semantic Web applications.
Based on the fact that all profiles are modeled into a common RDF based model, a simple profile comparator is implemented for simple reasoning and decision processes based on the modeled profiles without any additional semantic/ontology techniques such as OWL [20], SWRL [21], or Jess [22]. The implemented comparator simply decides whether two profiles comply with a given comparison rule. Comparison rules are described in the form of the schema used in the profile description and modeling, and specifies the attributes to compare, the comparison policies, conditions, and whether or not to store the difference of two attributes in case the condition/policy is not satisfied. The comparison condition specifies whether the rule is “mandatory” or “optional”, and the policy specifies how two attribute values such as “match”, “included” and “within range” are compared. The comparator outputs the final comparison results including the compliance with the comparison rule, quantified score, and the difference of attribute values in XML format. The result is used in the following reasoning or other decision procedures.
3.2. Dynamic Configuration of Execution Engine
An execution engine, defined as software that runs on a user device to mediate a particular service to the end user, is provided dynamically for the end user’s device on the user’s connection to the OSCD service framework. This execution engine conventionally is run directly by the user, assuming it is already installed on the user device. However, using the dynamic service execution environment provision function of the proposed framework, the user simply selects one of the recommended servicesand the according execution engine is then downloaded automatically/dynamically forming an optimized service execution environment. The dynamic configuration of a service execution environment includes the following procedures: user device profiling, a search for user and device specific services, execution engine search procedure to find an engine that suites both the service selected by the user and the user device profile, transfer of selected execution engine to the user’s device, and automatic installation/execution of downloaded engine.
Figure 3 shows the entire procedure. When a user connects and logs into the OSCD service framework, as shown in j of Figure 3, the framework processes the user authentication, and the corresponding user information is inserted in a user DB, shown in A. Then, a device DB is created by obtaining profiling information from the user device executing the device profiling function, shown as B in Figure 3. For performance purposes, at the same time when the device profile is requested, the OSCD service framework simply reads the recently used service list, frequently used service list, and recommended service list from the DB using the user DB, and then sends the lists to the device, k in Figure 3. In addition, the service ensembler in the OSCD service framework creates an execution engine list that enlists the service execution engines for the user’s device through a comparison of execution engine profiles against the user device profile, as shown in C of Figure 3. When the user tries to select a service from the provided device-based service list, l in Figure 3, the framework transmits the service list corresponding to the device-based execution engine lists, D of Figure 3. When the user selects a service, m of Figure 3, the framework detects the suitable execution engine by looking at the session DB, device DB, and service DB, E of Figure 3, and then downloads the selected engine to the device. After the execution engine is downloaded to the device, the corresponding execution engine is installed or executed automatically depending on its type, as shown in n of Figure 3.
The detection of an execution engine optimized to a user-selected service and user device is performed in two steps, as shown in Figure 4, and by the service ensembler in the OSCD service framework. The service ensembler chooses an execution engine that most satisfies the requirements of the selected services and user device simultaneously. Detection of the most suitable execution engine is achieved by comparing functions offered by the execution engine and functions required by the service. The comparison is possible because of the fact that profiles are stated by the common sets of vocabulary and schema. In the first step of a profile comparison, the device profile is compared with each engine profile to check if the corresponding execution engine can be installed/executed in the device, as shown in j of Figure 4.
Figure 3. The procedure for dynamic configuration of an execution engine.
Figure 4. The execution engine detection procedure.
The device profile used in the comparison is the profile of the current user’s device and refers to the contents already registered in the DB at a log-in procedure. In the second step, each profile of the installable/executable engine is compared with the chosen service profile to check whether the relationship between final services and execution engine is satisfied, k of Figure 4. The final results of the decision procedures are scores for each compared engine using a proprietary quantization mechanism. The most suitable execution engine among the condition-satisfying engines is chosen by comparing the resulting scores.
3.3. User & Device Available Service Recommendation
The proposed framework can recommend currently available services based on user preference and device characteristics. The following sections describe a learning algorithm according to user preference gathered by examining the service usage history and a recommendation algorithm for services that can be run on the used device. Table 1 lists four DB structures used for learning about user preference.
When a service is explicitly selected, keywords and categories of the service are stored in KH-TBL and CHTBL. When specific keywords and categories are searched, they are stored in KS-TBL and CS-TBL. Each of the four DB tables has frequency and recency values, where each entry is ordered by the weighted sum of these values. The user preference learning algorithm for each table is summarized in Table 2" target="_self"> Table 2.
The recommended service list for a specific user is
Table 1. Data structures for user preference learning.
Table 2. User preference learning algorithm.
created by searching and re-ordering services that are categorized by keywords and categories with the highest scores from the learning algorithm. Since enlisted services may not have an appropriate execution engine registered for all types of devices, the framework creates an execution engine list for engines that are executable on the device, when an arbitrary device is connected. Indeed, the execution engine list by device is a service execution engine list file by device that records the score value from the device and engine profiles each time a new device is registered.
Recommendations of user and device available services are determined by these two lists. Services that exist in both the recommendation list by the user and service execution engine list by device are added to the final recommendation service list. For the implemented system, a candidate service with the highest score has the highest ranking in the list.
3.4. Seamless Service Syndicator
3.4.1. Architecture of Seamless Service Syndicator
A seamless service syndicator in the OSCD service framework provides the service synchronization function with mainly a syndication process for service synchronization between heterogeneous terminals and service servers.
Figure 5 illustrates the message flow of a seamless service syndication for a service synchronization. The seamless service syndicator consists of two parts. The first part is related to Syndication Index Save (SIS), and