Multi-terminal and Multi-network Access to Virtual Home Environment

Transcription

1 Multi-terminal and Multi-network Access to Virtual Home Environment I. Roussaki 1, H. Jormakka 2, S. Xynogalas 1, A. Laikari 2, M. Chantzara 1 and M. Anagnostou 1 1 National Technical University of Athens Dept. of Electrical & Computer Engineering, Computer Science Division, Athens, GREECE Tel: , nanario@telecom.ntua.gr 2 VTT, Technical Research Centre of Finland, FIN VTT, Espoo, FINLAND ABSTRACT The materialization of the Virtual Home Environment concept will be realized if homogeneous access to the VASP applications and services is achieved independently of the type of terminal, protocol and network used. This paper proposes a Virtual Home Environment architecture located on top of an OSA/Parlay Gateway that enables VASPs to deploy their services in an homogeneous manner. Emphasis is given to two VHE components that aim to offer to the user network and terminal independent access to the VHE system, while a VHE prototype demonstration topology is presented. Key Words: VHE, Access, adaptation to terminals & networks, Parlay, OSA. I. INTRODUCTION The Virtual Home Environment (VHE) is a concept recently introduced and defined by important standardization bodies and fora (3GPP [1], ITU-T [2], UMTS Forum [3], GSM MoU [4], ETSI [5]), while it is currently being studied and analyzed by many research teams and industries. The VHE concept consists of capabilities aiming to present the end-users with the same look and feel interface regardless of location, serving network and terminal type used. A difficult task in this approach is to specify and eventually materialize entities, that allow the user to access and exploit the VHE system in an homogeneous, transparent manner, independently of terminal types and across network boundaries. This paper provides the specification and describes the cooperation of two key VHE components that serve this purpose, as they arose from the work carried out within the VESPER IST project (IST ) [6]. The rest of the paper is organized as follows: Section II proposes a VHE architecture that addresses the VHE concept requirements. In Section III both Access and Adaptation components are specified, their internal structure is depicted, while emphasis is given to their communication with the user and with each other. Section IV describes the interoperation of these VHE components within a typical VHE scenario. Section V presents the demonstration topology used to test the initial prototype developed with regards to the predefined specifications. Finally in section VI some conclusions are drawn and our plans for the near future are exposed, while a detailed Glossary follows. II. A PROPOSED VHE ARCHITECTURE One of the main goals of the standardization fora of 3rd generation networks is to provide a framework for fast service creation and service provision, rather than standardizing the set of the services as it has been done in the traditional approach. This is achieved mainly by enabling an access to network capabilities via an, which allows service developers and value added VASPs to generate new applications that benefit from functionality of the network. The Vesper architecture follows the new approach by using the already proposed by the converging 3GPP (OSA) [7] and Parlay Group s [8], adding service independent standardized components that implement and provide some kind of service capability features. The components combined by application logic into innovative applications, reduce the time and cost for provision of new services. In this way new business opportunities are generated for service providers, while the users benefit by having consistent access to personalized services. The solution provided by Vesper creates a new business role allowing new providers to enter the scene. These providers address niche market for personalized new applications satisfying the needs of a particular customer group. A high level view of the VHE Vesper architecture is presented in Figure 1. The most critical part of it is a set of components realizing the VHE concept, accessible by applications via the Vesper VHE. The VHE components are located both at the terminal and server sides. On the server side they are accessing the network and using its capabilities through an open, here the OSA/Parlay, while on the terminal side, always depending on the terminal type, they may take advantage of the terminal functionality provided by USAT [9] and MExE [10] (WAP [11], i-mode [12]).

2 Terminal applications Server VESPER VHE applications USAT VHE components MExE VESPER VHE VHE components USAT MExE (WAP, Java, i-mode) Parlay/OSA OSA/Parlay Gateway Terminal core functions Resource network specific NETWORKS The two VHE entities that aim to offer to the user network and terminal independent access to the VHE system, are the Access and the Adaptation components. The first one is the initial access point to the VHE provider for all potential users of the system. Implemented as terminal type and network independent component, in cooperation with Adaptation it provides the user with access to services in a personalized manner, specified by the user independent of terminal used or underlying network. The two components are described in more details in the following chapters. III. ACCESS AND ADAPTATION MODELS The state of a user's attachment to a VHE system and his involvement in service usage is maintained during a phase called VHE Session. VHE Session is a temporary association between a user and a VHE Provider, to allow the user to use VHE or VASP services. The start of a VHE Session occurs when a user contacts a VHE Provider, and terminates when the user disconnects. A VHE Session cannot be suspended or resumed. It exists only as far as a user is connected to a VHE system. The two main entities responsible for the VHE Session's maintenance are the Access and Adaptation components. The Access component (AcComp) is the initial access point to the VHE system for all potential users of the system. This includes not only subscribed users but also all the ones that may try to access the server for eventual free services, visiting users, or those providing false credentials. The AcComp interacts with the user always through the Adaptation component (AdComp) so that adaptation to terminals and networks is achieved. Additionally AcComp frequently communicates with other VHE components to support service provision. For all the reasons above, AcComp Figure 1: VHE Architecture must handle parallel communication with many entities at the same time. In order to process it in an efficient way, the number of the potential users has to be the taken into consideration as the main factor in the software design phase. To provide an efficient solution, the AcComp is divided into two parts: AccessManager and UserAgent. AccessManager (AM) is a generic, service and user independent entity. It is providing all users with the first contact to the server and handles the communication between the user and VHE Server until the user is authenticated. In case of big number of users, the component can be distributed among several servers, where the users' data can be stored based on a selected formula (ex. alphabetical order). After successful authentication of the user, AccessManager creates UserAgent that takes over the communication between the user and VHE Server. UserAgent (UA) created by AccessManager is a user dependent entity that is responsible for communication with a single user during the whole user's VHE Session. It is accessible from the user domain, always through the AdComp, regardless of the user location and is the VHE Provider's end point of a user s VHE Session. UA is service independent. It controls the whole cycle of the user's VHE Session and provides the user with access to all the services, and negotiates the user's preferences. Both entities above incorporate an action developed to handle direct communication with the AdComp receiving user requests and forwarding the adequate response. As already stated, the AcComp always interacts with the user through the AdComp so that adaptation to terminal capabilities is achieved. The adaptation

3 aspect is one of the focal points in VHE provision and is realised by the AdComp. The AdComp is responsible for adapting the contents provided to the user according to the VHE Session parameters: network, terminal capabilities and user preferences. Thus the VHE portal and service implementation are completely independent from the user environment (network type, terminal type, user preferences). The functionality offered by AdComp depends on its interaction other VHE components and with the OSA/Parlay GW. The different classes of the VHE AdComp are briefly described below: AdaptationManager: is the entry point to the usage of the component while being responsible for the management of the whole component. UIModelInterpreterManager: is responsible for the management of the UIModelInterpreters. For each VHE Session there is exactly one UIModelInterpreter instance. UIModelInterpreter: is responsible for the interpretation of the UIModels. It handles the UI callbacks from the OSA and invokes the ActionListeners of the AcComp specified in the UIModel set. UIModelContainer: is responsible for the management of the UIModels. For each VHE Session a different UIModel is created and updated under user requests. This UIModel will from now on be called the main UIModel of the user. UIModel: (User Interface Model) holds an XML description of the offered user interface. Each element of the UIModel corresponds to a different representation for every terminal type. The VHE portal UIModel that manages all user requests (service, profile, subscription or invitation relevant) is set, monitored and updated by the AcComp. Factory: is responsible for the management of the media adapters. Media: is responsible for the adaptation to different media (HTTP, WAP, DTMF and Video). In Figure 2, the structure of the VHE AdComp and its interactions with the AcComp are depicted. While the user is logged in the VHE system, using a specific terminal and network, the VHE Session created is managed and controlled by the AcComp. It interacts with the AdComp in order to initialize it, pass the necessary information to allow adaptation to the specific user environment and preferences and to pass the main UIModel that controls the service provision, the profile and subscription management and the delivery of invitations. Access Manager User1 Access Request User2 Access Request AM Adaptation Manager Adaptation User Agent 1 UA User Agent 2 UA Inte rpreter Manager Interpreter login UIModel Interpreter User1 main UIModel Interpreter User2 main UIModel Interpreter Container login UIModel Instance User1 main UIModel Instance User2 main UIModel Instance Vhe Factory VheMedia VheHTTPMedia VheWAPMedia VheDTMFMedia VheVideoMedia Access Profile OSA/Parlay Connection Internal method call VHE intercomponent method call Action Listener callback IV. Figure 2: VHE Access and Adaptation components structure INTEROPERATION OF ACCESS AND ADAPTATION COMPONENTS As already stated, terminal & network independent access to the VHE system, requires the cooperation of Access and Adaptation VHE components. The distinct areas, where this cooperation expands, are examined in this section. Depending on the type of the terminal used, two different cases are distinguished as far as the initial access request source is concerned.

4 HTTP or WAP terminals: When the user selects these types of terminals to access the VHE portal, then the initial access request arrives to the web server. The latter forwards the request to the appropriate servlet of the HTTP or WAP Media, respectively. DTMF enabled terminals: If this kind of terminals is used in order to access the VHE portal, then the user request to login is received by the VHE Connection via the OSA/Parlay Gateway. Subsequently the AdComp is notified and the request is forwarded to the of the DTMF Media. Once the initial access request is caught by the AcComp, a temporary session id is created. This id is valid until the actual VHE Session is created by the AcComp. Within the temporary session the first prebuilt User Interface Model (UIModel) is interpreted and the first UI is presented to the user requesting username and password. The user response is forwarded to the action of the Access Manager, within the AcComp. The login user information is forwarded to the Security that after accessing the user records VHE server database, responds to the Access Manager with the result of the authentication. If the latter is successful, the Access Manager proceeds with the creation of the VHE Session and the User Agent that will handle all user requests from now on. A UA action is created to catch user requests while the main UI model is set by the UA. In greater detail, the aforementioned steps can be described as follows: 1. The AdComp receives the initial access requests. In case of HTTP or WAP terminal the user enters a specific address to the browser that invokes the specific HttpInitialAccessServlet or WapInitialAccessServlet, respectively. When a DTMF enabled terminal is used, the user dials one of the predefined phone-numbers of the VHE portal while the VHE Connection is triggered. 2. The AdComp initialises a temporary internal session and selects the appropriate media adapter. 3. The AdComp binds to the action of the Access Manager and that sets the pre-built login UIModel. This model is then interpreted by the Adaptation Manager and presented to the user. 4. The Security is invoked by the Access Manager, in order to validate the user s credentials. The authentication procedure takes place based on the user records database maintained by the VHE server. 5. If the user is successfully authenticated the actual VHE Session is created. The Access Manager sets the media adapter to this session. The appropriate media adapter (HTTP, WAP, DTMF) is selected from the AdComp, according to the type of terminal used. 6. The Access Manager creates a User Agent. This user specific entity will exist as long as the user is connected to the VHE portal from the same terminal. The User Agent is initialised with all the necessary information (user id, VHE Session id, connection id, adaptation manager reference, ). 7. The User Agent creates and starts an action and uses this to set the main UIModel. This is invoked every time the user tries to: retrieve maintained user specific information (profiles and subscriptions), obtain session specific network statistics, start a subscribed service, discover available services according user defined criteria, join a session he/she is invited to and terminate his/her connection to the VHE portal. The interaction scenario described above addresses mostly the initial phase of VESPER where only the VHE core functionalities apply. The VESPER consortium has currently focused its research work to expand to roaming users and more types of underlying network. V. IMPLEMENTATION A prototype implementation has been elaborated within the framework of the first phase of VESPER. Even though VESPER will eventually address various types of telecommunication networks (i.e. UMTS, IP, PSTN, ISDN, GSM), the first trial was entirely based on an IP network. A Parlay Gateway and a VHE Connection CORBA component located within the VHE server handled all connections. Two servers were installed and configured, i.e. one for the VHE functionality and one for all demo services. Both servers, as well as all client terminals were connected through IP in a laboratory LAN environment established in NTUA premises in Athens. The prototype implementation addresses all the phases presented in the scenario described in the former section. VESPER VHE Server Nokia 9999 WAP Simulator Siemens Gateway Cisco Catalyst 1900 Series LAN Switch Siemens optipoint 300 basic IPphone TERMINALS Compaq ipaq H3600 PDA Service Server Figure 3: VESPER demonstration topology TurboX PC Client In Figure 3, the VESPER demonstration topology is depicted. All server and client machines are connected to the IP-network via a LAN Switch, supporting SNMP. The terminals include: two multimedia PCs (one laptop and one desktop PC), a PDA, a WAP simulator and two Η.323 enabled IP phones for user interaction during the demonstration.

5 During the VESPER initial trial (November 2001) multi-terminal and multi-protocol access to the VHE system was demonstrated. The protocols used were HTTP where the Parlay GW was not involved and H.323 in cases of IP-phone and NetMeeting H.323 clients, where, via an H.323 Gatekeeper, the Parlay GW communicated with the user terminals. The final trial will be based on experiences gathered within this prototype implementation and demonstration and will also address multi-network infrastructure. VI. CONCLUSIONS One of VHE s most important features is that it enables the user to access services from any type of terminal over any type of network. The proposed architecture provides the necessary framework, within which these VHE capabilities are materialized through the cooperation between the Access and the Adaptation component. VESPER project has already specified and implemented a VHE kernel prototype that demonstrated many multi-terminal VHE scenarios over an IP-network in a lab environment using HTTP, H.323 and MSP protocols. In the final trial (January 2003), VESPER plans to provide an enhanced version of the initial prototype that deals with various networks and also addresses the needs of roaming users. Acknowledgements This work has been performed in the framework of the project IST VESPER, which is funded by the European Community. The Authors would like to acknowledge the contributions of their colleagues from Intracom Hellenic Telecommunications and Electronics Industry S.A., National Technical University of Athens, Institut National de Recherche en Informatique et Automatique, IKV++ GmbH Informations und Kommu nikationstechnologie, GMD - Forschungszentrum Informationstechnik GmbH, Fondazione Ugo Bordoni, Universita Di Catania, Portugal Telecom Inovação, University of Surrey, Technical Research Centre of Finland and SIEMENS AG Osterreich. GLOSSARY 3GPP: Third-Generation Partnership Project AcComp: Access VHE AdComp: Adaptation VHE AM: Access Manager : Application Program Interface CORBA: Common Object Request Broker Architecture DTMF: dual tone multi frequency GSM: Global Standard for Mobile Communications H.323: Protocol to transmit audio and video information over the Internet HTTP: Hypertext Transfer Protocol I-mode: The packet-based service for mobile phones offered by NTT DoCoMo IP: Internet Protocol ISDN: Integrated Services Digital Network LAN: Local Area Network MExE: Mobile Station Application Execution Environment MSP : Media Streaming Protocol OSA: Open Service Architecture PDA: Personal digital Assistant PSTN: Public Switched Telephone Network SNMP: Simple Network Management Protocol UA: User Agent UI: User Interface UIM: User Interface Model UMTS: Universal Mobile Telephone Service USAT: Universal SIM Application Toolkit VASP: Value Added Service Provider VESPER: Virtual Home Environment for Service Personalization and Roaming Users VHE: Virtual Home Environment WAP: Wireless Application Protocol XML: Extensible Markup Language REFERENCES [1] 3GPP: The Virtual Home Environment (Release 4), 3G TS v4.0.0, (October 2000). [2] ITU-T: Draft new ITU-T recommendation Q.1711: Network Functional Model for IMT- 2000, (May 1998). [3] UMTS Forum Report 1: A Regulatory Framework for UMTS, (June 1997). [4] GSM MoU: "3G Service Requirements and Concepts", PRG TG.21, V3.1.0, (April 1998). [5] ETSI: UMTS 30.01, UMTS baseline document, positions on UMTS agreed by SMG including SMG#27 UMTS version 3.5. [6] IST VESPER project (IST ): Virtual Home Environment for Service Personalization and Roaming Users, [7] 3GPP: Virtual Home Environment/Open Service Architecture, (Stage 2), (Release 1999) 3G TS v (June 2000) [8] Parlay Forum: Parlay Specifications, [9] 3GPP: "USIM/SIM Application Toolkit (USAT/SAT)" (Stage 1), (Release 1999), 3G TS V3.1.0 (March 2000). [10] 3GPP: Technical Specification Group Terminals; Mobile Station Application Execution Environment (MExE); Service description, (Stage 1), (Release 4), 3G TS V3.2.0 ( ) [11] I-mode: x.html [12] WAP Forum, Specification Home Page: