wpage.unina.itwpage.unina.it/pescape/cit/d4102-integration report.pdf · file name: simplicity...

File name: Simplicity deliverable D4102.doc

Project Number: IST-2004-507558 Project Title:

Simplicity

Deliverable Type: PU – public

Deliverable Number: D4102

Contractual Date of Delivery to the CEC:

31.10.05

Actual Date of Delivery to the CEC: 26.10.05

Title of Deliverable: Integration report

Workpackage contributing to the Deliverable:

4.1

Nature of the Deliverable: R (Report)

Editors: E. Koutsoloukas, S. Kapellaki (NTUA), R. Walker (RAL)

Authors: S. Kapellaki, E. Koutsoloukas, G. Prezerakos, N. Dellas, J. Papanis (ICCS/NTUA) G. Bartolomeo, D. Di Sorte, M. Femminella, R. Fondacci, A. Labella, A. Lombardi, C. Mastruzzi, L. Piacentini, S. Teofili (RAL) Maomao Wu, Oliver Storz (ULAN) M.Niemeyer, F. Berger (SBS) Chie Noda, John Hamard, Alexander de Luca, Fatih Coskun (DoCoMo) Seidl Robert (SAG) Agostino Rugeri, Alessandro Del Genio (TILS) Enrico Rukzio (LMU)

Richard Wisenöcker, Christa Maria Karner, Christoph Pollak (SAGO)

D4102 – Integration Report

Filename: Simplicity deliverable D4102.doc of 175

Abstract:

Deliverable D4102 “Integration Report” is the final report on integration activities within the project. It describes integration activities between the beginning of the implementation work and the final implementation of the Simplicity demonstrator. The Simplicity demonstrator evolved from five scenarios that portray the Simplicity vision in practical terms. Within the integration workpackage, the software required to implement the scenarios was accumulated and integrated in phases, following a stepwise approach. Each integration phase produced a compound software system according to specifications, expressed as a series of test cases. This compound system was then used in the next integration phase. The process ended with the delivery of the final Simplicity demonstrator to Workpackage 4.2 for system evaluation.

Keyword List:

Integration phases, timeplan, demonstrator, scenarios, configuration, test cases



TABLE OF CONTENTS ABBREVIATIONS ................................................................................................................................................5

EXECUTIVE SUMMARY....................................................................................................................................6

1 INTRODUCTION ........................................................................................................................................8

2 DEMONSTRATOR FUNCTIONALITY.................................................................................................10

2.1 INTRODUCTION .........................................................................................................................................10

2.2 DEMONSTRATOR SCENARIOS....................................................................................................................11

2.2.1 Scenario 1: Multimedia messaging for a mobile worker (SAG) .........................................................11

2.2.2 Scenario 2: Media streaming – HES environment (SBS, NTUA).......................................................13

2.2.3 Scenario 3: Tour guide (ULAN) .........................................................................................................14

2.2.4 Scenario 4: Simplicity-aware service environment (TILS) .................................................................16

2.2.5 Scenario 5: Campus Network (RAL) ..................................................................................................17

2.3 DEMONSTRATOR STORY LINE ..................................................................................................................18

2.3.1 Mobile Summit Demo Story Line .......................................................................................................18

2.3.2 Final Demonstrator Story Line............................................................................................................20

3 IMPLEMENTATION OF THE DEMONSTRATOR.............................................................................24

3.1 INTEGRATION APPROACH .........................................................................................................................24

3.2 TIME PLAN ...............................................................................................................................................25

3.3 MOBILE SUMMIT DEMONSTRATOR SETUP ................................................................................................28

3.4 FINAL DEMONSTRATOR SETUP .................................................................................................................30

4 INTEGRATION PROCEDURES AND TESTS ......................................................................................33

4.1 PRE-INTEGRATION PHASE..........................................................................................................................33

4.1.1 Network Broker pre-integration ..........................................................................................................34

4.1.2 Terminal Broker pre-integration .........................................................................................................39

4.1.3 Simplicity Device pre-integration .......................................................................................................50

4.1.4 Simplicity Device – Terminal Broker pre-integration.........................................................................54



4.2 SIMPLICITY TEST BED INTEGRATION..........................................................................................................54

4.2.1 Availability of components .................................................................................................................54

4.2.2 Event matching results ........................................................................................................................54

4.2.3 Test cases ............................................................................................................................................54

4.3 APPLICATIONS INTEGRATION ....................................................................................................................54

4.3.1 Multimedia Messaging Scenario .........................................................................................................54

4.3.2 Media Streaming Scenario ..................................................................................................................54

4.3.3 Tour Guide Scenario ...........................................................................................................................54

4.3.4 Simplicity Aware Service Environment Scenario ...............................................................................54

4.3.5 Campus Network Scenario..................................................................................................................54

REFERENCES.....................................................................................................................................................54

APPENDIX – LIST OF HARDWARE CAPABILITIES .................................................................................54



Abbreviations

ANS Access Network Subsystem AP Access Point BT Bluetooth BW Bandwidth CNAC Campus Network Access Controller CVS Concurrent Versioning System D-ITG Distributed Internet Traffic Generator GUI Graphical User Interface HES Home Entertainment System / Home Environment Server IMS IP Multimedia Subsystems MMC Multimedia Messaging Context NB Network Broker PoC Push to talk over Cellular SAIM Simplicity Application Interface Manager SBC Simplicity Broker Communication SD Simplicity Device SDAM Simplicity Device Access Manager SIP Session Initiation Protocol SPA Simplicity Personal Assistant TB Terminal Broker WP Work Package



Executive Summary

Integration activities in Simplicity lasted for 12 months, starting in October 2004 and ending in October 2005. During this period the integration workpackage had the task of observing software delivery from ongoing implementation work packages, organizing integration sessions and producing the Simplicity demonstrator, a Simplicity test bed with integrated applications showing the Simplicity vision in action.

The Simplicity demonstrator was organized around five selected usage scenarios. The five scenarios show different aspects of how the Simplicity system simplifies user interaction with various services and devices. The functionality demonstrated in the scenarios is a subset of the overall Simplicity functionality specified in the User Requirements phase of the project. Each of the five scenarios demonstrates different Simplicity functionality. All of them share core functionalities that the Simplicity system offers. The five scenarios demonstrate:

• An Adaptive Multimedia Messaging Service, in which Simplicity supports a multi-media chat service which adapts to different media (text, images and sound) and ter-minal capabilities

• A Media Streaming – Home Entertainment System, in which Simplicity helps users in their interaction with a web portal selling media content and automatically adapts media according to terminal capabilities

• A Tour Guide System that shows how Simplicity can be used to personalize a con-text-aware tour guide system, including applications and services running on devices that are not owned by users

• A Simplicity Aware Service Environment, which provides a friendly, adaptive ser-vice environment for mobile workers visiting a physical space that offers advanced, context-aware services

• A Campus Network where Simplicity exploits user preference information and network monitoring functions to manage network load

Integration activities in the project were performed in two phases. The first phase produced a subset of the complete Simplicity demonstrator for the Mobile summit conference in Dresden, on June 19-23, 2005. The Mobile Summit demonstrator included the first two of the selected scenarios and a working Simplicity core system, missing only a few of the originally planned core functions. The second integration phase produced the final Simplicity demonstrator with a full featured Simplicity core system and all five scenarios.

The same integration strategy was followed for each one of the demonstrators,. Initial pre-integration phases produced standalone Simplicity components (Network and Terminal



Brokers, Simplicity device implementations) from subsystems. Then an island integration phase built a full Simplicity system from the core components; first the TB was integrated with Simplicity Device implementations, then TB+SD combinations were integrated with the Network Broker; finally specific applications for the five scenarios were integrated in the test bed. Each phase involved different subsystems and events. The hardware and software environment became more complex at every step.

The functionality to be provided in each phase was specified in a series of test cases. The test cases provided a description of the functionality triggered by specific user actions. The test case described the conditions in which specific functions are invoked, the components involved, the triggering action and expected system behavior. The complete set of test cases provided a description of overall demonstrator functionality and served as a check list to verify that the Demonstrator was functioning as expected.

Finally, additional configuration instructions were accumulated. This deliverable includes these instructions in scenario integration sections, thus providing all the information required to rebuild the simplicity demonstrator from the delivered software.



1 Introduction

This document is the final report on integration activities within Simplicity. The integration work package, started in month 12 (December 2004) and lasted till month 22 (October 2005). The goal was to accumulate all software modules produced by the implementation work packages (WP 3.x), create a hardware and software setup and integrate everything to form the Simplicity demonstrator. Integration activities were focused around five selected scenarios, which demonstrated a comprehensive subset of the functionalities originally specified in the User Requirements work package. The five selected scenarios demonstrate:

• An Adaptive Multimedia Messaging Service, in which Simplicity supports a multi-media chat service which adapts to different media (text, images and sound) and ter-minal capabilities

• A Media Streaming – Home Entertainment System, in which Simplicity helps users in their interaction with a web portal selling media content and then automatically adapts media according to terminal capabilities

• A Tour Guide System that shows how Simplicity can be used to personalize a con-text-aware tour guide system, including applications and services running on devices that are not owned by users

• A Simplicity Aware Service Environment, which provides a friendly, adaptive ser-vice environment for mobile workers visiting a physical space that offers advanced, context-aware services

• A Campus Network where Simplicity exploits user preference information and network monitoring functions to manage network load

The organization of work within the integration work package initially focused on providing a Simplicity test bed, a minimal Simplicity system able to offer core functionality useful in all scenarios. It then proceeded to integrate scenario-specific applications, which illustrate the Simplicity vision in practical terms.

The Simplicity demonstrator integration was performed in two phases. The first phase in-volved the integration of an intermediate Simplicity demonstrator with reduced functionality to be demonstrated at the Mobile Summit in Dresden, in June 2005. This intermediate demon-strator, (in the rest of this document: “Mobile Summit Demonstrator”) included a functional Simplicity test bed, the “Adaptive Multimedia Messaging System” and the “Media Streaming – Home Entertainment System”. The final Simplicity demonstrator included the complete Simplicity test bed and all five applications scenarios.

The rest of this document is organized as follows:



Section 2 describes the five demonstrator scenarios, their goals and the setup for each sce-nario. It also provides the Simplicity demonstrator story line, an imaginary script describing the functionality a simple user would expect to see from the demonstrator

Section 3 describes the overall integration strategy, the integration phases and a time plan for the work performed. It also gives an overview of the complete intermediate and final demon-strator setups.

Section 4 analyzes each integration phase and describes the work performed. For each integra-tion phase it provides a list of components, a reference to their interfaces, the demonstrator setup and a series of test cases that describe expected functionality and tests to verify this functionality.



2 Demonstrator Functionality

2.1 Introduction

Integration activities in Simplicity were split in two phases. The first phase produced an in-termediate Simplicity system to be demonstrated at the Mobile Summit in Dresden, on June 19-2, 2005. The second integration part produced the final Simplicity system that includes all of the functions initially planned.

The intermediate Simplicity demonstrator at the Mobile Summit was scheduled to include a fully working core system (Network and Terminal Brokers, all implementations of the Sim-plicity Device) with the exception of a few functions, and 40% of the application functionality planned for the final demonstrator. The Mobile Summit demonstrator was a successful demo that included the “Adaptive Multimedia Messaging” and the “Media Streaming – Home En-tertainment Service” scenarios.

The final Simplicity demonstrator includes a more stable and fully featured core system (Net-work and Terminal Brokers, all implementations of the Simplicity Device) as well as all five scenarios. The five scenarios in the Simplicity demonstrator are derived from the user re-quirements developed during the initial phase of the project.

The five scenarios are described in the table below:

Scenario name Partner Short Description Mobile Summit Demo

Final Demo

Adaptive Multime-dia Messaging

SAG In this scenario, Simplicity supports a multimedia chat service which adapts to different media (text, images and sound) and terminal capabilities

x x

Media Streaming – Home Entertain-ment System

SBS, NTUA

In this scenario, Simplicity helps users in their interaction with a web portal selling media content and then auto-matically adapts media according to terminal capabilities

x x

Tour Guide ULAN This scenario shows how Simplicity can be used to personalize a context-aware tour guide system, including

x



applications and services running on devices that are not owned by users

Simplicity Aware Service Environ-ment

TILS This scenario shows a friendly, adap-tive service environment for mobile workers visiting a physical space that offers advanced, context-aware ser-vices

x

Campus Network RAL In this scenario, Simplicity exploits user preference information and net-work monitoring functions to manage network load

x

Table 1. The five demonstrator scenarios

The following section provides brief descriptions of the five demonstrator scenarios as well as two story lines (one for each demonstrator) showing how a user might use the demonstrator.

2.2 Demonstrator Scenarios

This section provides an overview of the Simplicity demonstrator scenarios. Each subsection briefly describes the scope of the scenario and introduces the main components underlying the scenario. The descriptions provided here are meant as a summary of the work conducted in the scenario specification, architecture and implementation workpackages. Therefore the descrip-tions are brief. Appropriate references to other deliverables are provided where necessary.

2.2.1 Scenario 1: Multimedia messaging for a mobile worker (SAG)

The Multimedia messaging service for a mobile worker is a context aware chat application, i.e. an application in which the content is adapted (media are added and removed) according to the user’s current situation, The figure below illustrates the setup.



IP-CAN

IP-CAN

IP-CAN

IP-CAN

NB

TB

NB

TB

TB

TB

Chat Server

IMSIMS

Inter PLMN IP network

Policy, Context Exchange

User and Signalling DataPolicy Control

Figure 1. Multimedia Messaging Scenario setup

The Brokers have the task of pre-negotiating the conditions and the results of the policy evaluation so that the appropriate content is transmitted by the application server to partici-pants in the chat session using appropriate media. The application shows the following fea-tures:

• Voice PoC (push to talk over cellular); voice can be added or removed

• Picture chat: the size, color depth and color1 of images are modified by an application server

• Text messaging; the media can be added or removed

Implementation details can be found in D3102 “Report on implementation of network broker system”, section 2.4.

1 Black and white or full color



2.2.2 Scenario 2: Media streaming – HES environment (SBS, NTUA)

This scenario showcases how Simplicity procedures can help users interact with a web portal selling video and music content, how they can manage the content they have purchased and enjoy it anytime, anywhere, without worrying about complex issues like authentica-tion/authorization, configuration/adaptation/personalization, billing/charging and storage. The scenario involves two Simplicity compliant web services, the “Buy Music and Video” service that offers media for purchase and the “Personal Space” service which provides network stor-age space for the media, which users can access at anytime. Additionally, a Home Environ-ment Service (HES) offers media streaming services to users. These include integrated media adaptation operations. Users are equipped with a Simplicity Device and a Simplicity compati-ble terminal, through which they interact with the three services. A typical sequence of user actions could be the following.

The user connects to the “Buy Music and Video” service and selects a media file for purchase. Simplicity automates payment procedures and automatically transfers the media file to the user’s personal storage space. Later, the user connects to the Home Environment Server, pos-sibly using a different terminal and network connection. The user requests a media file to be streamed to his terminal. The media file is automatically adapted to the network and terminal capabilities, currently available to the user.

The scenario, involves the two web services, the HES environment, the network broker which orchestrates the interactions between the three services and the user, the terminal broker (in a laptop) and a user with a Simplicity Device (e.g. a Javacard).

Figure 2. Media Steraming – HES scenario general setup

More details on the scenario implementation can be found in D3102 “Report on implementa-tion of network broker system”, sections 2.1, 2.2, 2.3.



2.2.3 Scenario 3: Tour guide (ULAN)

The Simplicity Tour Guide demonstrator is a context-aware tour guide application that can be automatically personalized using the Simplicity framework. The demonstrator shows:

• the use of the Simplicity framework to design and develop personalized services that use equipment not owned by the user

• the use of the framework to personalize applications that have not been specifically developed for use with Simplicity.

The Simplicity Tour Guide demonstrator includes the following components (Figure 3):

• a client application and a tour guide server managing and delivering content to the client application.

• a Terminal Broker, located on the mobile device hosting the tour guide application

• a Simplicity Device, identifying the user to the tour guide application. The Simplic-ity Device is attached to the terminal device, using a short-range Bluetooth connec-tion

• the Tour Guide Application itself, which interfaces with Simplicity using a specifi-cally adapted Simplicity Application Interface Manager component. The application is hosted on a lightweight terminal (in the current instantiation a small tablet PC). 802.11 wireless network links are used for communication between terminal device and network-based parts of the demonstrator.

• one or more Network Brokers that are hosted on at least one network-enabled de-vice

• one or more Tour Guide Servers that are co-located with network brokers and inter-face with them using Simplicity Application Interface Managers. These servers mainly manage and deliver content to the tour guide application.



Figure 3: Architecture of the Simplicity Tour Guide demonstrator.

The tour guide application itself was developed to reflect the functionalities of classic tour guide systems, such as [1]. Please refer to D3102 for a more detailed description of architec-ture and functionality.

The Simplicity Tour Guide demonstrator uses the Simplicity framework to store and retrieve this information. Following this model, name, information about native language, personal interests and information about special requirements regarding food are part of the user’s Simplicity Personal Profile. By inserting the Simplicity device into the tour guide system, the tour guide system is able to establish a user’s identity and retrieve the necessary information from the Simplicity framework.

This information retrieved is used by the tour guide system to personalize various aspects of the user experience:

• Personalized User Interface: In the current instantiation of the Simplicity Tour Guide demonstrator information about the user’s language preferences is used to adapt the language of UI elements and content.

• Personalized Tours: Personalized tours assist users when visiting attractions that are of most interest to them.

• Personalized Content: As part of personalized tours, the tour guide system features the adaptation and personalization of content presented to the user.

• Suspend and Resume: Being able to store information in a user’s Simplicity Personal Profile, the tour guide application is able to collect and store information about the at-tractions visited. Using this feature users are able to suspend and resume tours to/from their personal Simplicity devices.

Tour Guide

Application

Tour Guide

Server

Terminal

Broker

Network

Broker

Terminal Network

802.11b



2.2.4 Scenario 4: Simplicity-aware service environment (TILS)

This section describes the demonstrator scenarios that TILS will implement in SIMPLICITY. These scenarios fit the Mobile Worker scenario from WP2.1. They focus on providing a friendly, adaptive service environment for mobile workers visiting a physical space that offers advanced, context-aware services.

The final result for this scenario will be a demonstrator that runs within a location, such as a conference or learning center that offers advanced services to visitors.

This demonstrator is composed of two distinct sub-demonstrators which show different as-pects of the core idea.

MyPC - Simplicity-Based Customization of Leased Devices

MyPC allows mobile users to access leased devices (e.g., PCs) that are available to users in a visited environment, and to have the software environment (e.g., mailer, browser) customized instantly, to match their normal working or home environment. The demonstrator exploits and showcases the personalization capabilities that can be implemented through the SD, working in combination with a network-based service supporting storage of privacy-sensitive user data. Environments that lease PCs to visitors include public places, Internet Cafes and learning cen-ters. (For example, in its classrooms, Telecom Italia Learning Services provides PCs for stu-dents and visiting professors.)

The setup of the demonstrator envisages a number of PCs, connected to a local network, and available for visitors to use.

In the demonstrator, visitors are assumed to carry a Simplicity device, and to be registered with a provider of data storage services. The network-based data storage service is provided by a SDS node interfaced through Network Brokers

i-Provisioning (formerly known as Context-aware Client Provisioning)

This demonstrator assumes that mobile workers carry their own laptop or PDA, and their own Simplicity Device. The service environment provides users with personalized and context-aware services. To provide such services, it is necessary to dynamically download software components, and other resources, to the user terminal, on an as-needed basis. The showcase extends the reference implementation of Java 2 Client Provisioning, to show how Simplicity adaptation, policy and context management mechanisms can be exploited to implement con-text-aware client provisioning.

The infrastructure necessary for this demonstrator consists of

• an 802.11b wireless network



• an application server, used to provide information services to the visitors. Information delivered to users includes the locations and schedules of events and classes, documents (slides) for individual events, and maps for walking in the environment. Some services are web-based, while some require client software on the terminal. The server acts as a repository of software components and other resources (e.g., maps, documents) that may be helpful for users accessing the services

• a Simplicity network broker, integrated with the application server

• A location tracking mechanism (e.g., based on Wifi)

Implementation details for this scenario are available in D3102 “Report on implementation of the network broker system”, sections 2.5 and 2.8.

2.2.5 Scenario 5: Campus Network (RAL)

The goal of this scenario is to show that Simplicity is able to control the access network load by personalizing the network and application services it offers to users, using information in their profile, and data on network load.

The reference network scenario is illustrated in the figure below. We limit the scope of the demonstration to an 802.11b access network and to the browsing service.

CampusCore Network

CampusCore Network

NB

AP

AP

AP

TBSD

Ethernet Switch

TBSD

Figure 4: The Campus Network Demonstrator Scenario



The Campus Network demonstrator selects a network connection from one of a set of avail-able access points (APs) covering the same area. The selection of the AP is driven by the fol-lowing inputs:

• the APs available to the user;

• the bandwidth currently available at each AP;

• the user profile (i.e. professor, student);

• the class of APs (some of them are accessible only by people in specified categories).

“Critical network” condition (i.e., wireless link congestion) may impose further restrictions. Some categories of user, such as students, may be forced to use the service in a limited mode (for example, web browsing might only be available in “text” mode).

Implementation details for this scenario may be found in section 2.7 of D3102 “Report on im-plementation of network broker system”.

2.3 Demonstrator Story Line

The Simplicity demonstrator should have a good story to tell. Starting from the User Re-quirements phase, the project specified a series of scenarios portraying the Simplicity vision. The scenarios constituted a guide for the architecture specification and the implementation of the Simplicity system. During the planning of the Simplicity demonstrators these scenarios were assembled into “stories” showing a typical Simplicity user in action

2.3.1 Mobile Summit Demo Story Line

Simplicity user Jan interacts with Simplicity while chatting, searching and acquiring media files and receiving the media streamed to him.

2.3.1.1 I- SPA

- Jan plugs his SD into his Laptop. - The SPA starts and displays the Login screen on the laptop. - Jan enters his username and password on the Login screen. - The SPA automatically discovers registered services. - The SPA displays the Desktop window and the Main menu while updating the list of regis-

tered services.

2.3.1.2 II- Chat

- Jan clicks on the Com item from the Services menu and selects “Chat”.



- Jan starts a chat session with Clara and Bernat and sends them a picture from his last vacation in Athens.

- Clara (using a mobile phone) and Bernat (using a PDA) receive a picture fitting their terminal screens (automatic content adaptation based on terminal capabilities).

- Clara arrives at the doctor’s office while still chatting with her friends. In line with her prefer-ences, her mobile phone is automatically set to silent mode when at the doctors. She cannot receive audio files during this time.

- Later on, Jan quits the “Chat” application.

2.3.1.3 III- Get AV

- Back in the Desktop window of his laptop, Jan clicks on the Media item from the Services menu and selects “Get AV”.

- The search field is automatically filled in based on the user’s Favorite Artists and Genres stored in his preferences. The name “Jim Jarmush” is displayed in the search field. Below this search field he sees audio and video content, from recent events and promotions.

- Jan presses the Search button and immediately gets a list of movies by Jim Jarmusch. - Jan presses the “Download” button below the “Permanent vacation” item in order to

download this movie. - The system displays an Alert message requesting Jan to confirm the use of the Credit Card de-

tails stored in the User Profile. This message allows Jan to edit his Credit Card details if nec-essary. A checkbox “Do not ask me again” is also displayed at the left bottom of this Alert message (provide a corresponding “Payment confirmation” checkbox in the Preferences window).

- Jan confirms the Alert message and the movie “Permanent vacation” is automatically downloaded on the “Storage/Video” storage folder. This can be accessed from other devices by using a pointer, stored in the SD.

- Once the video download has been completed the debit to the user’s Credit Card is processed. Then the system displays a Confirmation message indicating that the download of the “Per-manent vacation” video has been completed. A checkbox “Do not ask me again” is displayed in the left bottom corner of the Confirmation message (provide a corresponding “Download confirmation” checkbox in the Preferences window).

- The system finally displays an Alert message asking Jan whether the “Permanent vacation” video should be played? A checkbox “Do not ask me again” is also displayed in the left bot-tom corner (provide a corresponding “Play files after downloading” checkbox in the Prefer-ences window).

2.3.1.4 IV- SPA

- Jan removes the SD from his laptop and the SPA automatically logs him off. - Arriving home Jan plugs his SD into his desktop computer. - The SPA starts and displays the Login screen on the desktop computer. - Jan enters his username and password on the Login screen. - The SPA automatically discovers registered services. - The SPA displays the Desktop window and the Main menu while updating the list of regis-

tered services.



2.3.1.5 V- Media Streaming

- Jan clicks on the pointer –stored in the SD. This opens the “Storage” folder and the “Videos” subfolder.

- In the “Videos” subfolder Jan sees the “Permanent vacation” movie he previously downloaded.

- Since this movie is not stored on his Desktop window but is just visible from it, Jan can either download or stream it by pressing the corresponding buttons on the screen (Please note that files could also be downloaded by drag&drop from the Videos subfolder).

- Jan presses the “Stream” button. This launches the default AV player installed on the Desktop computer (If the native file format can’t be supported by the AV player then the file format is automatically converted to the most format).

2.3.1.6 VI- SPA

Jan removes the SD from his desktop computer and the SPA automatically logs him off.

2.3.2 Final Demonstrator Story Line

2.3.2.1 I- Chat

− Jan plugs his SD (Simplicity Device) into his Laptop. − The SPA (Simplicity Personal Assistant) starts and displays the Login screen on the laptop. − Jan enters his password on the Login screen. − The SPA automatically discovers registered services. − The SPA displays the Desktop window and the Main menu while updating the list of regis-

tered services. − Jan clicks on the Com item from the Services menu and selects “Chat”. − Jan starts a chat session with Clara and Bernat and sends them a picture from his last vacation

in Athens. − Clara (using a mobile phone) and Bernat (using a PDA) receive a picture fitting their terminal

screens (automatic content adaptation based on terminal capabilities). − Clara arrives at the doctor while still chatting with her friends. In line with her preferences,

her mobile phone is automatically set to silent mode when at the doctors. Consequently, she cannot receive audio files during that time.

− Later on, Jan quits the “Chat” application.

2.3.2.2 II- Get AV

- Back in the Desktop window of his laptop, Jan clicks on the Media item from the Services menu and then selects “Get AV”.

- The search field is automatically filled in based on the user’s Favorite Artists and Genres. The name “Jim Jarmush” is displayed in the search field. Below this search field he sees audio and video content, from recent events and promotions.

- Jan presses the Search button and immediately gets a list of movies by Jim Jarmusch.



- Jan presses the “Download” button below the “Permanent vacation” item to download this movie.

- The system displays an Alert message requesting Jan to confirm the use of the Credit Card de-tails stored in the User Profile. This message allows Jan to edit his Credit Card details if nec-essary. A checkbox “Do not ask me again” is also displayed at the left bottom of this Alert message (provide a corresponding “Payment confirmation” checkbox in the Preferences window).

- Jan confirms the Alert message and the movie “Permanent vacation” is automatically downloaded on the “Storage/Video” storage folder. This can be accessed from other devices by using a pointer, stored in the SD.

- Once the video download has been completed the debit to the user’s Credit Card is processed. Then the system displays a Confirmation message indicating that the download of the “Per-manent vacation” video has been completed. A checkbox “Do not ask me again” is displayed in the left bottom corner of the Confirmation message (provide a corresponding “Download confirmation” checkbox in the Preferences window).

- The system finally displays an Alert message asking Jan whether the “Permanent vacation” video should be played? A checkbox “Do not ask me again” is also displayed in the left bot-tom corner (provide a corresponding “Play files after downloading” checkbox in the Prefer-ences window).

2.3.2.3 III- Media Streaming

- Jan clicks on the pointer –stored in the SD. This opens the “Storage” folder and the “Videos” subfolder.

- In the “Videos” subfolder Jan sees the “Permanent vacation” movie he previously downloaded.

- Since this movie is not stored on his Desktop window but is just visible from it; Jan can either download or stream it by pressing the corresponding buttons on the screen (Please note that files could also be downloaded by drag&drop from the Videos subfolder).

- Jan presses the “Stream” button. This launches the default AV player installed on the Desktop computer (Please note that if the native file format can’t be supported by the AV player then the file format is automatically converted to the most format).

2.3.2.4 IV- Campus Network

The Campus Network offers two wireless Access Points A and B. Which access point is se-lected depends on the user profile (student/guest or professor) and the available bandwidth. This depends on the number of people connected to the Access Point and their activities (e.g. file download, Web surfing). Network A is basically open to everybody but when the network is busy (due to multiple con-nections) students and guest users (user profile) can only browse the Web in restricted mode (e.g. no pictures). Network B is also open to everybody except when it gets busy. In this case it is restricted to professors.

− Jan goes to the University Campus in order to access the Web and prepare a report. − He borrows a public computer to which he connects his SD.



− The SPA starts and displays the Login screen on the laptop. − Jan enters his password on the Login screen and gets automatically logged in as a guest. − The SPA automatically discovers registered services. − The SPA displays the Desktop window and the Main menu while updating the list of regis-

tered services. − Network A is currently the fastest one; it is therefore automatically selected without requiring

any user configuration. − Jan starts surfing on the Web; looking for some useful information for his report. − Network A to which Jan is currently connected is getting more and more busy. Students are

now accessing the Web after finishing their exams. Therefore Jan’s connection is automati-cally and transparently switched to network B.

− In the late afternoon, many professors connect to network B, downloading publications to prepare their next lectures. Due to Jan’s limited privileges, his network connection is switched back to network A. But since it is still busy, Jan can only access it in limited mode.

− When trying to access a Photo Gallery on the Web, an information message is displayed to Jan indicating “Pictures display not possible due to limited network access”.

− Some hours later, Jan finally gets all the information he needs and removes the SD from the public computer.

− The SPA automatically logs Jan off.

2.3.2.5 V – Tour Guide

− Jan is visiting the city of Edinburgh. − He picks up a Tour Guide (TG) unit from the tourist information centre. − He connects his SD to the TG unit. − The SPA starts and displays the Login screen on the unit. − Jan enters his password on the Login screen and gets automatically logged as a guest. − The SPA automatically discovers registered services. − The SPA displays the Desktop window and the Main menu while updating the list of regis-

tered services. − The TG unit presents Jan with the option to use the information stored in his SD profile to

personalize the application. − The TG application personalizes the user interface (UI) according to Jan's preferences, i.e.

using large buttons, fonts and German language. − Content is tailored to Jan's interests stored in his SD, in this case putting more emphasis on

history and omitting information about popular shopping areas. − Jan decides to follow a personalized tour through the city. − When constructing the tour, the TG system takes Jan's interests into account, i.e. avoiding

shopping opportunities and focusing on history and buildings. − The TG system is constantly informed about Jan's current location. − Unfortunately, Jan does not have enough time to finish the tour this morning since he has to

come back to his hotel. This, however, is not a big problem. The TG system periodically up-dates Jan's personal profile with information about the places he has already visited.

− Jan resumes his tour later on in the afternoon.



− Before Jan returns the TG terminal to the tourist information centre, he unplugs his SD, caus-ing the TG application to erase all Jan’s personal data and to return to its default state.



3 Implementation of the Demonstrator

This section serves as an introduction to the technical description of integration activities in Simplicity. First of all we present our overall approach to integration and an overview of the integration plan. The last section provides an overview of the complete demonstrator setup, for the intermediate and the final versions.

3.1 Integration Approach

The nature of Simplicity, a highly distributed system with components residing on heteroge-neous platforms, requires a stepwise integration strategy. Our approach included initial paral-lel pre-integration phases, where the core Simplicity components (NB, TB, SD implementa-tions) were built up from individual subsystems (steps 1, 2 and 3 in the figure below). These pre-integration phases ensured that software developed by different partners could be success-fully combined to form the building blocks of the Simplicity test bed. This phase was fol-lowed by an island integration phase, where core components were combined to form the Simplicity test bed (step 4: TB-SD pre-integration and step 5: SD-TB-NB Integration). This step provided a robust test bed on which the applications could be run (step 6).

Figure 5. Integration phases

The six integration steps illustrated in the figure were replayed twice in the project’s lifetime, once for the intermediate mobile summit demonstrator and once again for the final demonstra-tor. Although the intermediate demonstrator provided a working Simplicity test bed, the initial



pre-integration and integration steps 1-5 were repeated for the final demo, making it possible to test the extra functionality required by the additional three scenarios.

Each integration phase had to check the availability of required components, as well as their compliance with specified interfaces and functionality. For this reason each integration phase was based on a series of test cases allowing testing of the functionality provided by individual components. Section 4 of this deliverable describes the different integration phases, providing details about the subsystems involved, the events exchanged between them, their interfaces, and the test cases describing expected functionality and the actions required to test it.

The integration work also included the implementation of a project wide CVS repository. This ensured that partners worked all together in a common source tree and that the most recent software versions were always available. The repository provided two different source trees, one for the Network Broker software and the laptop version of the Terminal Broker and a sec-ond one containing the PDA version of the Terminal Broker. The CVS repository was setup and managed in Paderborn by SBS. More details about the CVS can be found in D3202 “Re-port on implementation of user terminal system”, chapter 5.

3.2 Time Plan

This section provides the time plan for implementation and integration activities in Simplicity. The time plan is split in two phases: the first phase describes the schedule for the delivery of the required components for the intermediate Mobile Summit demo, while the second part de-scribes the scheduling of components delivery for the final demo. Phase I of the time plan covers the period October 2004 – beginning of June 2005. Implementation was scheduled from October 2005 to mid-April 2005. The following 2 months were reserved for integration preparations and integration meetings. Part II lasted from mid-June 2005 till the end of Octo-ber. The period between mid-June and the end of September was reserved for additional im-plementation work on the final demonstrator. The period from the start of October – to the end of November is reserved for the second phase of integration for the final demonstrator.

Both phases are described below as Gantt charts.



3.3 Mobile Summit Demonstrator Setup

The Mobile Summit Demonstrator included two scenarios, the Adaptive Multimedia Messag-ing and the Media Streaming – Home Environment Server. The two scenarios required a func-tional core Simplicity system comprising a Network Broker and two versions of the Terminal Broker, one for the laptop and one for the PDA, as well as four implementations of the Sim-plicity Device (javacard, Bluetooth mobile phone, virtual and flash memory). The Adaptive Multimedia Messaging system required an IMS to manage messaging sessions and a media gateway that performed all media adaptations. The Media Streaming scenario required two servlet based services for the media portal and the user’s personal storage as well as the Home Environment server that provided streaming capabilities. These services and components were distributed across different hardware devices. These, along with the network, formed the dem-onstrator environment.

The following list describes the high level components used in these two scenarios, and their physical locations. Physical locations are provided through a label that identifies the device and the scenario it belongs to. The following conventions apply:

• PC refers to desktop, laptop or tablet PCs

• PDA refers to PDAs

• MM refers to the Multimedia Messaging scenario

• MS refers to the Media Streaming scenario

• TG refers to the Tour Guide Scenario

• SASE refers to Simplicity Aware Service Environment scenario

• CN refers to Campus Network Scenario

The hardware and software capabilities of all the devices involved in the demo are provided in the Appendix.

Scenario Component Location

All Simplicity Network Broker Software MMPC1

All Simplicity Terminal Broker Software (lap-top version)

MMPC3

Ada

ptiv

e M

ul-

time-

dia

Mes

-Simplicity Terminal Broker Software (PDA version)

MMPDA1



IMS Server MMPC1 & MMPC2

Media Gateway MMPC2

MMM client (PDA version) MMPDA1

MMM client (laptop version) MMPC3

HES Service MMPC1

Personal Storage and Buy Music and Video Services

MSPC1

Med

ia S

trea

min

g D

emo

Client applications for the Media Stream-ing scenario

MMPC3 or MSPC2

Table 2. Mobile Summit demonstrator – high level components and their physical location

The following figure illustrates this hardware setup and deployment of components. Note that MSPC2 is optional. It is possible to use only one laptop as a terminal.

Figure 6. Hardware setup and deployment of the Mobile Summit Demo



3.4 Final Demonstrator Setup

The final Simplicity demonstrator includes all five scenarios. The following table lists high level components and services and their physical location. Labeling is the same as in the pre-vious section.

Scenario Component Location

All Simplicity Network Broker Software MMPC1

All Simplicity Terminal Broker Software (lap-top version)

MMPC3

Simplicity Terminal Broker Software (PDA version)

MMPDA1

IMS Server MMPC1 & MMPC2

Media Gateway MMPC2

MMM client (PDA version) MMPC3

Ada

ptiv

e M

ultim

edia

Mes

-sa

ging

MMM client (laptop version) MMPC3

HES Service MMPC1

Personal Storage and Buy Music and Video Services

MSPC1

Med

ia S

trea

min

g D

emo

Client applications for the Media Stream-ing scenario

MSPC2

Tour Guide Server Application TGPC1

Tou

r Gui

de D

emo

Tour Guide Client Application TGPC2



Sim

plic

ity

Aw

are

Serv

ice

Env

iron

men

t Dem

o

I-Provisioning servlets MSPC1

Access Points and Bandwidth Measuring Points

CNPC1 & CNPC2

Client Application CNPC3

Cam

pus

Net

wor

k D

emo

Non Simplicity laptops, traffic generators CNPC4 & CNPC5

Table 3. Final demonstrator – High level components and their physical location

The figure below shows the hardware setup and deployment of components for the final dem-onstrator



��

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

� �� !� ��

��

� ��

�""��

� �� #� �$��

� ��%"��"��"

� ��&&��

��'

� (��)�*��$�

�%"��

��$

+��

��

,�

��%��-��

� ��.��%��

� ��*��&��%��

��%��-��

� ��%� ��$��

��%��-��

� ��/��.��&�0

� !��

,�

.��$�

��%��

��%��-��

� ��%� ��$��

� (��)�*��$�

�%"��

��$

��%��-��

� (��10"��

��

��

��#��-�� &��%�

��%��

�&��%�

� �� #��

� ��.

� (��.

� ��.

� 21��

� 2

� �3

� �

� ��#��-��-��

� ��%� ��$��

��

� ��%"��"��"

� ��&&��

��4

��

,�

.��$�

��%��

Figure 7. Final demonstrator hardware and software environment setup



4 Integration Procedures and Tests

In this section we describe the actions performed during each integration phase. In the pre-integration phase the Simplicity core-components were constructed from subsystems. The out-puts of this phase were the Terminal Broker, the Network Broker and the different implemen-tations of the Simplicity Device. Following this phase, the island integration phase merged the TB and SD into a single pre-integrated component. The Network Broker was then introduced. Finally, we integrated the applications implementing the Demonstrator scenarios.

Each phase of this procedure corresponds to a sub section below; each sub section describes the components involved, the interfaces between them (exchanged events), the test cases used describe expected functionality and the procedures used for testing.

4.1 Pre-integration phase

In the pre integration phase, the Terminal Broker and the Network Broker software were sepa-rately assembled from available subsystems. The pre-integration phase ensured that all re-quired subsystems were available and integrated with the TB or NB.

“Integrated” means that (a) the subsystem had been delivered to the central project source re-pository, and (b) that where the subsystem provided functionality internal to the TB or NB the functionality had been tested and shown to function as required.

The main difficulty in this pre-integration phase was that the critical interfaces were those be-tween the TB and the NB. Therefore it was difficult to test the TB as a single component. It was also difficult to test standalone subsystems since they are not isolated components but re-quired the presence of other subsystems, which in turn required the presence of others and so on. One way to overcome this difficulty would have been be to invest valuable time on dummy test software, implementing scenarios carefully crafted to test the operation of subsys-tems or of the NB and TB as standalone components. This testing approach would have eased the transition between the pre-integration and the integration phase, but it would also have wasted valuable implementation time. Instead, we decided to use an offline (paper) verifica-tion method to check that subsystems and events were available, that they matched with one another and that basic operations that did not require a NB (e.g. SD login, broker startup, ac-cess to SD) functioned correctly. The testing of internal TB and NB functions and more so-phisticated functionality was left to the next integration phase.



4.1.1 Network Broker pre-integration

4.1.1.1 Availability of components

The following core subsystems are located in the Network Broker. Scenario specific subsys-tems are also available. These are documented in the corresponding scenario sections (4.3.x).

Subsystem on CVS integrated

Location Subsystem x x

SDS Manager x x

ANS (Access Network Subsystem) x x

Capability Manager x x

Policy Decision Point x x

Policy Manager x x

Pricing Subsystem x x

Profile Manager (NB) x x

SBC x x

Service Manager x x

Scenario Specific

I-Provisioning Subsystem x x

MyPC Subsystem x x

CNAC (Campus Network Access Controller) x x

Media Store SAIM x x

Personal Storage SAIM x x

HES_NB x x

MMC (Multimedia Messaging Context) Manager x x



Tour Guide SAIM x x

4.1.1.2 Event matching

The following table lists Network Broker internal events, which are exchanged between send-ing and receiving subsystems.

Event Sending Subsystem

Receiving Subsystem

GetDeviceCapabilityEvent MMC Capability Manager

GetUserPrefEvent MMC SDAM

BrokerPresentEvent MMC SBC

BrokerPresentResponseEvent SBC MMC

RequestPolicyDecisionEvent MMC Policy man-ager

ReturnDeviceCapabilityEvent Capability Manager

MMC

ReturnUserPrefEvent MMC Profile man-ager

MMMPolicyResultEvent Policy Man-ager

MMC

4.1.1.3 Test Cases

The following table lists test cases specified for the Network Broker pre-integration phase. The subsequent tables provide relevant details for every test case.

Test ID Test name Description

NB1 Subscribe for events NB-MMMS Subscribe for events

NB2 Send update context notifica-tion NB-MMMS send update context notification



NB3 Unsubscribe of events for user X NB-MMMS unsubscribe of events for user x

NB4 Register SIP-stack<-> NB, Register

NB5 Re-Registration SIP-stack<-> NB, Re-Registration

Test Case NB1 Partners involved: RAL, NTUA, TILS

Name NB-MMS Subscribe for events

Goal of the test Verification of the interface between the Network Broker (NB) and the Multimedia Messaging Server (MMS).

Modules Capability Manager, Profile Manager, Policy Manager, PolicyDe-cisionPoint, SBC, MMContext Manager

Testbed configura-tion

The standalone Network Broker with the subsystems described above

Scenario Description All subsystems have to be installed with their event senders and receivers.

Call Flow MMS -> NB

Expected Results The MMS sends a Subscribe message to the NB.

Test Results Successful

Notes none


Name NB-MMS send update context notification

Goal of the test Change the profile of an active subscriber so that the medias to be used also change (change the cost limit to a lower value to force the NB to skip the picture media).






Scenario Description Change the profile of an active subscriber so that the medias to be used change (change the cost limit to a lower value to force the NB to skip the picture media).

Call Flow NB -> MMS

Expected Results From now on, the subscriber whose profile has been changed should no longer receive picture media.

Test Results as expected

Notes none


Name NB-MMS unsubscribe of events for user x

Goal of the test ChangeMediaNotification messages anymore




Scenario Description A MMS client leaves the MM session

Call Flow MMS -> NB

Expected Results The NB should not send ChangeMediaNotification messages any-more

Test Results correct

Notes none




Name SIP-stack<-> NB, Register

Goal of the test As the network broker (NB) will act like a normal SIP-client, it has to register to the IMS. Furthermore, it must be able to accept SIP-Invite messages of TBs which are used to handle sessions for the communication of TBs to a NB.




Scenario Description Start the NB, during SBC startup the SIP register should take place

Call Flow • Start the NB.

• While startup, the NB must send a SIP-Register message to the IMS.

• The IMS will reject the Register with Unauthorized to force the authentication.

• The NB will send again a SIP-Register with included authentication information.

• The IMS will accept the registration and responds with 200 OK.

• Now, the NB will complete the startup phase.

Expected Results The NB will be ready to provide services after completion.

Test Results The NB registers successfully

Notes none

Test Case NB5 Partners involved: RAL,



NTUA, TILS

Name SIP-stack<-> NB, Re-Registration

Goal of the test Verify the re-registration procedure



As described above

Scenario Description The re-registration time is set to 30 minutes. This is done in the CSCF. After waiting for more than 30 minutes, re-registration is performed.

Call Flow • As the Registration on an IMS is valid for a limited period of time, the NB has to perform a Re-Registration at the IMS. The period of time when Re-Registration is required depends on the IMS-setting.

• The NB has to send a Register message when the re registration timer expired.

• The IMS will answer with 401 unauthorized

• The a next register is send to the IMS

• The IMS will answer with 200 OK.

Expected Results The re-registration can be found in the protocol.

Test Results successful

Notes none

4.1.2 Terminal Broker pre-integration

4.1.2.1 Availability of components:

The Terminal Broker side includes the following subsystems. Scenario specific subsystems were not considered in this integration phase. They are documented in the scenario sections (4.3.x).





Profile Manager x x

Policy Manager x x


Simplicity Application Interface Manager (SAIM) x x

Simplicity Device Access Manager (SDAM) x x

Simplicity Personal Assistant (SPA) x x

Simplicity Broker Communication (SBC) x x

Service Manager x x

Scenario Specific

Home Entertainment Service (hes) x x

MediaStoreSaim x x

Messagedialog x x

MMadapt SAIM x x

MyPCSubsystem x x

Tour Guide SAIM x x

4.1.2.2 Event matching results

The following table lists the Terminal Broker internal events, exchanged between sending subsystems and receiving subsystems.


Receiving Subsystem

GetDeviceCapabilityEvent SAIM Capability Manager



GetUserLocationEventTB TGClient Location Manager

GetUserPrefEvent SAIM Profile Man-ager TB

GetUserPrefResultEvent Profile Man-ager

Different subsystems

LoginCompleteEvent SDAM Different subsystems

ModifySubnetParamEvent ANS subsys-tem TB

SDAM

QuerySDAMEvent SDAM Profile Man-ager

QueryUserProfileResponseTBEvent Profile Man-ager

SDAM

QueryUserProfileResultTBEvent Profile Man-ager

RemoveSubnetParamEvent ANS subsys-tem TB

SDAM

RequestSDAuthEvent SDAM SBC

RequestUserAuthEvent SAIM SDAM

RetrieveAllNetParamReqEvent ANS Subsys-tem TB

SDAM

RetrieveAllNetParamRespEvent SDAM ANS Subsys-tem TB

RetrieveSmtpServerListReqEvent ANS Subsys-tem TB

SDAM

RetrieveSmtpServerListRespEvent SDAM ANS Subsys-tem TB

RetrieveTunnelServiceParamReqEvent ANS Subsys- SDAM



tem TB

RetrieveTunnelServiceParamRespEvent SDAM ANS Subsys-tem TB

ReturnDeviceCapabilityEvent Capability Manager

SAIM

ReturnUserLocationEventTB TG Client Location Manager

ReturnUserPrefEvent Profile Man-ager TB

SAIM

SDAMQueryResponseEvent SDAM Profile Man-ager TB

SDAMQueryResultEvent SDAM Profile Man-ager TB

SDAuthResponseEvent SDAM SBC

SDAuthResultEvent SDAM SBC

StoreSubnetParamEvent ANS Subsys-tem TB

SDAM

SubnetConfigurationNotifyEvent SDAM SDAM

SubscribeForDeviceCapabilityChangeEvent SAIM Capability Manager

SubscribeForDeviceCapabilityChangeSuccessEvent Capability Manager

SAIM

UpdatePrefEvent Different Subsystems

Profile Man-ager

UpdatePrefResultEvent Profile Man-ager

Different Subsystems

UpdateSUPNodeEvent Profile Man-ager

SDAM

UpdateSUPNodeResultEvent SDAM Profile Man-



ager

UserAuthResultEvent SDAM SAIM

UserHasLeftEvent SDAM SAIM

UserIMSRegistrationEvent SDAM SBC

UserLoggedInEvent SAIM Different Subsystems

UserLoggedOutEvent SAIM Different Subsystems

UserPresenceEvent SDAM Different Subsystems

4.1.2.3 Test Cases

The following table lists intra broker operations that can be tested without a NB. One or more test cases are provided for each operation.


TB1 Application Start The TB application starts

TB2 Insert SD The user inserts the SD and the SPA starts (runs with real and unreal SD)

TB3 Remove SD The user removes the SD

TB4 Login Process The user logs in to the terminal, using the SPA

TB5 Logout Process The user logs out of the terminal, using the SPA

TB6 List Device Capabilities Lists the terminal device capabilities, using the ‘Device Capability’ menu entry

TB7 List User Profile Lists the user profile, using the ‘User Profiles’ menu entry

TB8 Change Device Capabili-ties The user changes the device capabilities

TB9 Change User Profile The user changes his/her user (preference) profile



The following tables provide details for these test cases:

Test Case TB1 Involved Partners: RAL, LMU, SBS, TILS, VTT

Name Application start

Goal of the test All TB subsystems have to be installed on the broker system

Modules SDAM, SAIM, SPA, Capability Manager, Profile Manager, Ser-vice Manager, Policy Manager, hes, mediastoresaim, messagedia-log, mmadaptsaim, MyPCSubsystem, PolicyDecisionPoint, SBC

Testbed configura-tion As described above.

Scenario Description All subsystems have to be installed with their event senders and receivers.

Call Flow Not applicable

Expected Results The SPA is provided on the terminal display


Notes In this stage tested only with Virtual SD

Test Case TB2 Involved Partners: RAL, LMU, SBS

Name Insert SD

Goal of the test User presses the Insert SD button on the Laptop or inserts a real SD. The SPA starts (if not started already) and shows information about the inserted SD. The SPA shows a Login Dialog to the user.

Modules SDAM, SAIM, SPA


Scenario Description



Call Flow

• UserPresencs (SDAM -> SAIM)

• (New instance of SPA (SAIM))

• SPA shows the result

Expected Results The SPA is provided on the terminal display and shows informa-tion about the inserted SD. The SPA shows a Login Dialog.


Notes Currently tested without a real SD


Name Remove SD

Goal of the test User presses the Remove SD button on the laptop (or removes the real SD). The SPA shows information about the removed SD. All added UI elements from other systems are removed from the SPA.




Call Flow

• UserHasLeft (SDAM -> SAIM)

• SAIM informs SPA

• SPA shows the result

• SPA removes all UI elements from other systems

Expected Results The SPA provides information about the removed SD and removes all UI elements of other systems.





Test Case TB4 Involved Partners: RAL, LMU, SBS, NTUA,

Name Login Process

Goal of the test Testing the Login procedure provided by the SPA.

Modules SDAM, SAIM, SPA, SBC, Profile Manager



After inserting a SD, the user enters his password in the Login Dia-log provided by the SPA. After a successfully authorization (at Policy and SD) the SBC starts and makes a connection to the net-work broker. The user profile from the SD is transferred to the NB. The capability profile is transferred to the capability manager on the NB. The SPA will keep all UI elements disabled, until it gets informed about a incoming LoginCompleteEvent from the SAIM.

Call Flow

• UserLogin

• Check login: SAIM received userLoggedIn event from Policy manager, SAIM received UserAuthResult from SD

• SDAM starts the SBC

• User profile is transferred to NB

• Capability Profile is transferred to NB

• SPA UI elements are enabled

Expected Results The SPA enables all services and menu items






Name Logout Process

Goal of the test The user uses the Logout button in the SPA menu



Scenario Description The user presses the SPA Logout menu item. All available services and menu items are disabled.

Call Flow • UserLoggedOut (SAIM -> SDAM)

• UserLoggedOut (SAIM -> SPA)

Expected Results The SPA disables all services and menu items except for the login, the close and the exit item.



Test Case TB6 Involved Partners: LMU, SBS

Name List Device Capabilities

Goal of the test The device capabilities are listed in the SPA

Modules SAIM, SPA, Capability Manager


Scenario Description The user clicks on the SPA device capability menu item. Device capabilities are listed on the SPA

Call Flow • GetDeviceCapability (SAIM -> Capa. Manager)



• ReturnDeviceCapability (Capa. Manager ->SAIM)

• Capabilities to SPA (SAIM -> SPA)

Expected Results The SPA shows the device capabilities of the terminal


Notes None

Test Case TB7 Involved Partners: LMU, SBS, RAL

Name List User Profile

Goal of the test The user profile is listed in the SPA

Modules SAIM, SPA, Profile Manager


Scenario Description The user presses the SPA user profiles menu item. The user profile is listed on the SPA

Call Flow • GetUserPref Event (SAIM -> profile management)

• ReturnUserPrefEvent (profile management -> SAIM)

Expected Results The SPA shows the user profile.

Test Results The SPA shows the user profile on the screen.

Notes None

Test Case TB8 Involved Partners: LMU, SBS

Name Change Device Capabilities

Goal of the test User can change the device capabilities by using the SPA



Modules SAIM, SPA, Capability Manager


Scenario Description The user presses the Save button in the Device Capability list of the SPA. Any changed entries in the list are stored in the capability file.

Call Flow

• SubscribeForDeviceCapabilityChangeEvent (SAIM -> Capa. Manager)

• SubscribeForDeviceCapabilityChangeSuccessEvent (Capa. Manager ->SAIM)

Expected Results The SPA shows the changed device capabilities of the terminal


Notes None

Test Case TB9 Involved Partners: LMU, SBS, RAL

Name Change User Profile

Goal of the test User can change the user (preferences) profile by using SPA

Modules SAIM, SPA, profile manager


Scenario Description The user presses the Save button in the User Profile list of the SPA. Any changed entries in the list get stored by the profile man-agement.

Call Flow • UpdatePrefEvent (SAIM -> profile manager)

• UpdatePrefResultEvent (profile manager ->SAIM)

Expected Results The SPA shows the changed user preferences on the terminal




Notes None

4.1.3 Simplicity Device pre-integration

This section provides integration details for the two more sophisticated Simplicity Device im-plementations, the Java Card implementation and the Bluetooth mobile phone implementa-tion. The Virtual Simplicity Device and the Flash Memory Simplicity Device are very simple implementations, whose functionality was provided by the Simplicity Device Access Manager (SDAM) subsystem at the Terminal Broker. Therefore they did not require integration effort.

This section provides test cases for the integration of the each Simplicity Device implementa-tion with the SDAM. Event Matching results and Availability of Components report do not apply.

4.1.3.1 Java Card SD test cases


JCSD1 Insertion/Removal Detection Detect when the JavaCard is con-

nected/removed and start/stop appropriate ser-vices accordingly

JCSD2 Authentication Authenticate User

JCSD3 Read data Read data from JavaCard storage space

JCSD4 Write data Write data on JavaCard storage space

Test Case JCSD1 Partners involved:

Name Insertion/Removal Detection

Goal of the test To verify that the Controller is notified when the status of the card changes

Modules JavaCard with applet installed, PC terminal with Controller and OpenCard Framework

Testbed configura- JavaCard with applet installed, PC terminal with Controller and



tion OpenCard Framework, JavaCard USB dongle


The JavaCard Controller is started in the terminal. The JavaCard is inserted or removed from the dongle. The OpenCard Framework is responsible for notifying the Controller of status changes. The Controller starts or stops appropriate services and notifies other subsystems.

Call Flow

The card is inserted

Card Object and Proxy to Applet are started

SDAM subsystem is notified

The card is removed

Card Object and Proxy to Applet are terminated

SDAM subsystem is notified


Expected Results The insertion and the removal of the JavaCard are handled prop-erly

Notes none


Name Authentication

Goal of the test To verify that the User is properly authenticated using his/her PIN



JavaCard with applet installed, PC terminal with Controller and OpenCard Framework, JavaCard USB dongle

Scenario Description After connection establishment, the tester is invited to authenticate himself/herself by inserting his/her password into an appropriate form displayed on the screen.



Call Flow

The server requests user authentication

The server sends password to Applet

The applet verifies password

The applet returns authentication result to the Server

The Server displays authentication result into the terminal screen


Expected Results Authentication is working properly

Notes PIN/password is supported, username not yet


Name Read Data

Goal of the test To verify that the Controller is able to read data from JavaCard memory space




Scenario Description A subsystem sends a request to read data (i.e. to read user profile) from the JavaCard

Call Flow

An event that requires reading data arrives at SDAM subsystem

SDAM is passing the read request to the JavaCard Controller

The Controller sends a read command to the Applet (via OpenCard Framework)

The applet is reading data from JavaCard memory

The applet sends the result and data back to the Controller (via OpenCard Framework)



The Controller passes the data to the SDAM subsystem


Expected Results Reading of data from the JavaCard successful

Notes none


Name Write Data

Goal of the test To verify that the Controller is able to write data to JavaCard memory space




Scenario Description A subsystem sends a request to write data (i.e. write/update user profile) in the JavaCard

Call Flow

An event that requires writing data arrives at SDAM subsystem

SDAM is passing the write request to the JavaCard Controller

The Controller sends the data to the Applet (via OpenCard Framework)

The applet is writing data in JavaCard memory

The applet sends the result back to the Controller (via OpenCard Framework)

The Controller notifies the SDAM subsystem


Expected Results Writing of data to the JavaCard successful

Notes none



4.1.3.2 Bluetooth Mobile Phone test cases


MPSD1 ConnectionEstablishment Establishment of the connection be-tween the BT phone and the PC

MPSD2 Authentication Perfom user authentication

MPSD3 WriteData Write data on the phone’s storage space

MPSD4 ReadData Read data from the phone’s storage space

MPSD5 Login Verify if the user is able to enter the

miniSPA by entering his password (as with the SPA).

MPSD6 View User Data Verify if the user is able to view his user data.

MPSD7 Change User Data Verify if the user is able to change his user data using the miniSPA.

Test Case MPSD1 Partners involved: RAL

Name ConnectionEstablishment

Goal of the test Verify if the BT client application running on the BTPhone is able to get a connection with a server running on a PC

Modules BTPhone with midlet installed, BT server running on the PC.


BTPhone with midlet installed, BT server running on the PC. PC equipped with BT Dongle.


A BT server is running on the PC; The tester press a button on his phone. The BT Device Discovery is performed by the mobile phone and finally a list of available bt device is presented to the tester which choices one of them. After verifying that a suitable service is available in the PC, the BT phone connects to the server and a notification is displayed on the screen



Call Flow

Midlet (device discovery)

Midlet -> server (service discovery)

Midlet -> server (connect)

Server -> midlet (connection established)

Test Results

Test 1 (no active bt device in the vicinity except the bt phone and the pc): successful

Test 2 (few active bt device in the vicinity): successful but slow (see notes)

Test 3 (lots of bt device in the vicinity): sometimes the test fails and the error “BT error #4” coming from the BT stack implemen-tation is displayed into the phone’s screen.

Expected Results The BTphone is able to connect to the server running on the pc.

Notes

Device discovery takes a lot of time especially when there are lots of active bt device in the vicinity. When the number of active bt device in the vicinity is very high, sometimes the test fails. A solu-tion to avoid this phase (device discovery) is required to improve performance. (e.g. caching of bt addresses on the phone’s memory)


Name Authentication

Goal of the test Verify if the the tester is able to authenticate himself through the use of a password/PIN.




Scenario Description After connection establishment, the tester is invited to authenticate himself by inserting his password/PIN into an appropriate form displayed on the screen.



Call Flow

Server (requests user authentication to the tester)

Server -> midlet (send authentication data)

Midlet (verifying data)

Midlet -> server (returns authentication result)

Server (displays authentication result on the screen)


Expected Results User authentication is correctly managed.

Notes (none)


Name WriteData

Goal of the test Verify if the BT client application running on the BTPhone is able to get receive a remote “write” command form the server running on the PC and perform a write action on its own storage space.





A BT server is running on the PC; After connection establishment and authentication, a form is displayed on the screen. The tester fills in the form with the parameters needed to the write com-mands, i.e. start position and data to write; then presses a button and a message is sent to the midlet running on the phone. The midlet writes the specified data into its storage space starting from the speficied position. Finally the midlet returns a result.

Call Flow

Server (displays a “write” from)

Server -> midlet (send command “write”)

Midlet (writes data)



Midlet -> server (returns “write” result)

Server (displays “write” result on the screen)

Test Results

Expected Results The BTphone is able to receive the “write” command sent by the server running on the pc and perform a write operation on its own storage space.

Notes (none)


Name ReadData

Goal of the test Verify if the BT client application running on the BTPhone is able to get receive and perform a remote “read” command form the server running on the PC and return the read data.





A BT server is running on the PC; After connection establishment and authentication, a form is displayed on the screen. The tester fills in the form with the parameters needed to the read commands, i.e. start and stop position; then presses a button and a message is sent to the midlet running on the phone. The midlet reads data from its own storage space and finally returns these data to the server.

Call Flow

Server (displays a “read” from)

Server -> midlet (send command “read”)

Midlet (reads data)

Midlet -> server (returns read data)

Server (displays “write” result on the screen)



Test Results Test 1: problems in reading (see notes)

Test 2: after problem fixing the test case has been successful.

Expected Results The BTphone is able to receive the “write” command sent by the server running on the pc and perform a write operation on its own storage space.

Notes (none)

Test Case MPSD5 Involved Partners: LMU, RAL

Name LogIn

Goal of the test Verify if the user is able to enter the miniSPA by entering his password (just like at the SPA).

Modules BTPhone with midlet installed.

Tested configuration BTPhone with midlet installed.


After performing Test Cases MPSD1 – MPSD4 the mobile phone should fulfil all requirements needed to use the miniSPA functionality. The user opens the miniSPA and is asked for his password. After entering it, the main menu of the miniSPA will open, otherwise he will get an error message.

Call Flow

Midlet (reads data)

Midlet (requests user to enter his password)

Midlet (verifying data)

Midlet (shows error or main menu)

Expected Results The user will be able to open the miniSPA and to log in.




Name Show User Data

Goal of the test Verify if the user is able to view his user data.



Scenario Description The user chooses “show user data” from the main menu. A form will open that displays all his data, that is stored on the BTSD.

Call Flow

Midlet (reads data)

Midlet (parses XML data)

Midlet (creates form and displays it)

Expected Results The user will be able to see his user data.


Name Change User Data

Goal of the test Verify if the user is able to change his user data using the miniSPA.




In the main menu, the user chooses “edit data”. After that, a form with editable fields will be presented to him. After editing the data, he will be able to save it. After that, changes will be stored.

Call Flow

Midlet (reads data)

Midlet (parses XML data)

Midlet (creates form and displays it)



User (edits the data)

Midlet (saves the data)

Expected Results The user will be able to open and change its data. Changes will be stored permanently.

4.1.4 Simplicity Device – Terminal Broker pre-integration

Following the SD – SDAM integration phase, it was necessary to test whether the combina-tion of the two provided the required functionality to the complete Terminal Broker system. The Simplicity Device – Terminal Broker pre-integration verified the complete SD-TB system by specifying test cases that include the SD, the SDAM and all other TB subsystems (those applicable).

This pre-integration phase did not introduce new events or subsystems to the system, therefore only the test case tables are provided:


TBSD1 NotifySDPresenceOrSDRemoval The SD notifies its presence or removal to the TB

TBSD2 RetrieveProfileDataFromSD The user profile is retrieved from the SD

TBSD3 UpdateProfileDataIntoSD The user profile data are update into the SD

TBSD4 CheckCredentials The system checks user’s creden-tials

Test Case TBSD1 Partners involved:

Name NotifySDPresenceOrSDRemoval

Goal of the test Verify if the SD presence is correctly detected

Modules SDAM, BT phone controller, midlet running on the BT phone


BT phone controller SDAM+monitor, midlet running on the BT phone, SAIM and SPA as testing stub



Scenario Description The tester press a button into the phone, the system recognizes the user presence and the SPA shows a suitable message on the screen

Call Flow

SD -> SDAM (presence message)

SDAM -> SAIM (UserPresenceEvent)

SAIM -> SPA (notify user presence)

Test Results Successful (but see also notes from the test case MPSD1)

Expected Results the SD presence is correctly detected

Notes In a similar manner the SD removal is detected.


Name RetrieveProfileDataFromSD

Goal of the test Retrieve Profile data from the SD using high level data addressing functionalities provided by the SDAM

Modules BT phone controller,SDAM, midlet running on the BT phone


BT phone controller, SDAM+monitor, midlet running on the BT phone


A user profile has been deployed into the SD. The SD is present and user authentication has been performed. User profile data are loaded from the SD by using the “recMounfFolder” functionality provided by the SDAM

Call Flow SDAM->SD (read data)

SD->SDAM (data)

Test Results Successful (but see also notes from the test case MPSD4)

Expected Results The profile is loaded from the SD

Notes We can also retrieve only parts of the user profile data using the “mountFolder” functionality provided by the SDAM.




Name UpdateProfileDataIntoSD

Goal of the test Update user profile data stored into the SD by using high level data addressing functionalities provided by the SDAM

Modules BT phone controller, SDAM, midlet running on the BT phone


BT phone controller, SDAM+monitor, midlet running on the BT phone


A user profile has been deployed into the SD. The SD is present and user authentication has been performed. After having specified a xpath and data content, by pressing the “update” button on the SDAM monitor, these data are written into the SD.

Call Flow SDAM->SD (write data)

SD->SDAM(result)

Test Results Test 1: Successful but slow (see notes)

Test 2: Successful with better performance

Expected Results Data are correctly update into the SD

Notes

System performance was slow because the SDAM performs one update per time. Especially in slow SD (JavaCard and BTPhone) this might be a problem when multiple updates are committed. The problem has been fixed by allowing the SDAM to accept more than one update per time and commit changes on the SD only when all updates have been performed. The SDAM returns a “suc-cessful update” message if and only if all the updates have been committed.


Name CheckCredentials

Goal of the test Verify if the authentication procedure works correctly



Modules SDAM, BT phone controller, midlet running on the BT phone


BT phone controller SDAM+monitor, SAIM and SPA as testing stub, midlet running on the BT phone


The system detects the presence of the SD, the SPA displays a form, the tester inserts his/her credentials (username and pass-word), the system verifies these credentials and shows a message to the tester

Call Flow

SPA->SAIM (RequestUserAuth)

SAIM->SDAM (RequestUserAuthMessage)

SDAM->SD (verify credentials)

SD->SDAM (UserAuthResult)

SDAM->SAIM (UserAuthResultMessage)

SAIM->SPA (result)

Test Results

Test 1 (wrong username and wrong password): Successful

Test 2 (wrong username and right password): Problems (see note)

Test 3 (right username and wrong password): Successful

Test 4 (right username and right password): Successful

Test 5 (after problems fixing): Successful

Expected Results The SPA correctly shows the user authentication result

Notes

In the initial specification there was a misunderstanding about user authentication: the SD was able to verify the user’s password but not the login. This issue has been fixed in a later release of the SDAM subsystem

4.2 Simplicity test bed integration

This integration phase produced the Simplicity test bed, comprising a Network Broker, a few Terminal Brokers and the different implementations of the Simplicity Device (java card, blue-tooth mobile phone, virtual SD and flash memory card).



The setup used for this phase included a minimal Simplicity demonstrator system with two PCs running the IMS and Network Broker and a laptop running the Terminal Broker, every-thing connected through a switch.

��#��-�� &��%�

��%�� &��%�

��

��

� ��%��-��

� ��%� ��$��

5� ��

� ��/��.��&�06

�� $

� (��)�*��$�

�%"��

� 2

� �3

� �

� ��#��-��-��

� ��%� ��$��

� �� #��

� ��.

� (��.

� ��.

� 21��

Figure 8. Simplicity test bed hardware and software environment setup

The hardware and software capabilities of the devices involved (MMPC1, MMPC2, MMPC3) are specified in the Appendix.

4.2.1 Availability of components

The input for this integration phase consisted of the pre-integrated core Simplicity compo-nents, TB+SD and the NB. Therefore in this integration phase we considered components rather than subsystems. The following components were involved:

Component pre-integrated tested

Network Broker + IMS Yes yes

Terminal Broker + javacard SD Yes yes

Terminal Broker + Bluetooth mobile Yes yes



phone SD

Terminal Broker + Virtual SD Yes yes

Terminal Broker + flash memory SD Yes yes

4.2.2 Event matching results

The following table lists all events exchanged between the Network Broker and the Terminal Broker. For reference purposes the table also describes the subsystems involved.

Event Sending Subsystem Receiving Subsys-tem

GetServiceEvent Service Manager (TB)

Service Manager (NB)

ReturnServiceEvent Service Manager (NB)

Service Manager (TB)

HesSendCapabilityProfileEvent Hes hesNB

HesSendCapabilityProfileEventResponse hesNB hes

HesSendUserProfileEvent Hes hesNB

HesSendUserProfileEventResponse hesNB Hes

SendUserProfileNBEvent Profile Manager TB Profile Manager NB

SendCapabilityProfileEvent Capability Manager (TB)

Capability Manager (NB)

SendCapabilityProfileResponseEvent Capability Manager (NB)

Capability Manager (TB)

SendUserProfileNBEvent MyPCdemo (TB) Profile Manager (NB)

NotifyUserProfileChangeEvent Profile Manager (NB)

MM Context Man-ager

4.2.3 Test cases

The relevant test cases involve high level core functions that involve both brokers:




ST1 TB Registration to IMS SIP-stack <-> Register to IMS

ST2 TB Unregisters from the IMS SIP-stack<-> TB Unregister from IMS

ST3 SBC discovery function TB SBC discovers NB subsystems for common TB-NB events

ST4 Loading profile branches from SDS

Parts of the profile may be stored on the network side in the SDS. During TB startup, these are

transferred to the terminal side

ST5 Profile Transfer to NB After the profile has been fully read and TB startup

finishes the profile is transferred to the network side for caching

ST6 Device Capabilities Transfer to NB

Device Capabilities are sent to the network side for caching

ST7 Service Discovery User subscribed and other available services are sent from the Network side to the Terminal side

Test Case TS1 Partners involved: RAL, NTUA, TILS, VTT, SAG, LMU

Name TB registration to IMS

Goal of the test Make sure that the TB can register to the IMS in the demonstrator environment

Modules TB Sip Stack, IMS


The testbed described above. The IMS IP should be resolved by DNS from the well known name “simplicity.net”

Scenario Description • Start a NB

• Start a TB



• Observe Login on the NB

Call Flow SDAM -> SBC (??)

SBC -> TB SIP stack register()

TB SIP stack -> IMS register

Expected Results The TB console should output a successful register response from the SIP stack

Test Results The TB successfully logs in

Notes None

Test Case ST2 Partners involved: RAL, NTUA, TILS, LMU

Name TB unregister from IMS

Goal of the test Make sure that when the user logs out the TB unregisters from the IMS

Modules SAIM, SBC, TB Sip Stack, IMS


The testbed described above

Scenario Description When the user logs out from the SPA the SAIM notifies the SBC to unregister from the IMS

Call Flow SAIM -> SBC (UserLoggedOutEvent)

SBC -> TB SIP stack unregister()

TB SIP stack -> IMS

Expected Results The TB console should output a successful unregister message.

Test Results TB unregisters successfully

Notes None



Test Case ST3 Partners involved: NTUA

Name SBC discovery function

Goal of the test SBC provides subsystem discovery for unmatched events

Modules SBC



Scenario Description After successful registration to IMS the TB SBC and NB SBC ex-change SBC discovery messages when an unmatched event is dis-patched in either place

Call Flow mediator -> TB (NB) SBC submits any unmatched event

TB (NB) SBC -> NB (TB) SBC exchange discovery messages

TB (NB) SBC -> NB (TB) SBC remotely dispatch the event

Expected Results The unmatched event should show up in the Mediator log at the other broker

Test Results Discovery function works as expected

Notes None

Test Case ST4 Partners involved: TILS, RAL

Name Loading Profile branches from SDS

Goal of the test When the deployed profile contains branches in the Simplicity Data Storage, the branch has to be transferred to the Terminal Bro-ker during startup

Modules ProfileManager TB, SDS Manager


The testbed described above, used with a profile that has deployed branches on the SDS



Scenario Description A user logs in the TB and during startup, after registration to the IMS and SBC discovery phase the missing profile branch is trans-ferred to the terminal side

Call Flow SDAM -> SDS (retrieve profile branch)

Alternatively, one of the two following:

1. SDS -> SDAM (response) , or

a timemout expires and the SDAM assumes that the SDS cannot answer. It will work anyway withouth the information contained in the requested branch.

Expected Results After full startup the SDAM console should show the complete profile

Test Results The missing branch shows up in the SDAM console after full startup

Notes None

Test Case ST5 Partners involved: RAL, TILS

Name Profile Transfer to NB

Goal of the test When the profile is fully loaded to the Terminal Side, it has to be cached to the Network side

Modules ProfileManager TB, Profile Manager NB



Scenario Description After TB full startup the two profile manager subsystems interact to cache the profile to the network side

Call Flow Profile Manager TB -> SDAM (query SDAM)

SDAM -> Profile Manager TB (response)

Profile Manager TB -> Profile Manager NB (send user profile)



Expected Results The NB console prints the complete profile when it is cached

Test Results The profile is printed as expected

Notes None

Test Case ST6 Partners involved: SBS, TILS

Name Device Capabilities transfer to the Network Broker

Goal of the test After full startup of the TB the device capabilities have to be cached to the network side

Modules Capability Manager TB, Capability Manager NB



Scenario Description After TB full startup the two capability manager subsystems inter-act to cache the profile to the network side

Call Flow 1. After the capability manager receives a LoginComplete Event, the capability profile is send from the TB to the NB.

2. If the capability profile has been changed during runtime, the ‘new’ capability profile is send from TB to the NB

Expected Results The NB receives the event SendCapabilityProfileEvent. The event includes the profile in XML style.

Test Results The capability profile is succesfully sent to the NB after the user logs in and the after the capability profile has changed.

Notes None

Test Case ST7 Partners involved: VTT

Name Service Discovery

Goal of the test Make sure that the TB and NB can cooperate to present the user



choices about services

Modules Service Manager TB, Service Manager NB, SPA



Scenario Description 1. The user logs in. The service manager fetches the subscribed services from the profile manager.

2. The user clicks on the Service menu in the SPA and searches for services.

3. The user selects one of the discovered services and subscribes to it.

4. The user selects the “Subscribed Services” choice in the SPA Services menu

5. The user removes a subscribed services from the list

Call Flow 1. Service Manager TB -> Profile Manager TB (subscription query)

Profile Manager TB -> Service Manager TB (subscription re-sponse)

2. Service Manager TB -> Service Manager NB (service query)

Service Manager NB -> Service Manager TB (service re-sponse)

3. Service Manager TB -> Profile Manager TB (subscription up-date)

Profile Manager TB -> Service Manager TB (subscription up-date)

4. SPA opens the UI displaying the subscribed services

5. Service Manager TB -> Profile Manager TB (subscription removal)

Profile Manager TB -> Service Manager TB (subscription re-sponse)



Expected Results 1. Service Manager (TB) receives the subscribed services

2. Service Manager (TB) receives the searched services

3. The subscribed services are stored by the Profile Manager and are added to the subscribed services UI

4. The subscribed services are displayed to the user

5. The subscribed services are removed by the Profile Manager and are removed from the subscribed services UI

Test Results The above mentioned functions work as expected.

Notes None

4.3 Applications integration

This section describes the integration of Demonstrator applications to the Simplicity test bed. For each scenario it provides a description of the hardware environment with reference to the overall hardware and software environment, any specific configuration steps and the test cases for the new components that each scenario introduces to the Simplicity demonstrator.

4.3.1 Multimedia Messaging Scenario

4.3.1.1 Description of the demonstration environment

On the server side, the Multimedia Messaging service needs two physical PCs. The split is required by the IMS-SW. A split of the Simplicity software was also performed.



Figure 9. Multimedia messaging scenario – Hardware and software environment setup

On the terminal side, the Multimedia Messaging demo required one terminal implementation. This could be either a laptop PC or a PDA (MMPC3, MMPDA1).

The hardware and software capabilities of all devices are provided in the Appendix (MMPC1, MMPC2, MMPC3, MMPDA1).


The Network Broker integrates the following subsystems.



Profile Manager x x

Policy Manager x x


P-CSCF

S-CSCF

I-CSCF

HSS

ASX

MG MMMS

DNS

NB

Simplicity services

IMS services

IP services

MMPC1 MMPC2

MG: Media Gateway MMS: Multimedia Messaging Server NB: Network Broker P-CSCF: Proxy CSCF I-CSCF: Interrogating CSCF S-CSCF: Servicing CSCF HSS: Home Subscriber Server ASX: Application Server DNS: Domain Name Service



Simplicity Application Interface Manager (SAIM) x x

Simplicity Device Access Manager (SDAM) x x

Simplicity Personal Assistant (SPA) x x

Simplicity Broker Communication (SBC) x x

Simplicity Device Manager (SDSM) x x

Home Entertainment Service (hes) x x

MMContext Manager x x

CapabilityNB Manager x x

MediaStoreSaim x x

PersonalStoreSaim x x

Messagedialog x x

Mmadaptsaim x x

Profile NB Manager x x

Service Manager x x

MyPCSubsystem x x

4.3.1.3 Demonstrator setup

This scenario does not require any special configuration steps, as it involves only software components developed within Simplicity and an installed PIDS 4.0 based IMS. Configuration or installation instructions for the IMS are not provided since it was delivered to the project pre-installed and pre-configured from SAG/SAGO.




The table below lists the multimedia messaging internal events, exchanged between sending subsystems and receiving subsystems.


Receiving Subsystem

SubscribeMMAdaptionInfoEvent NAs MMC

MMMAdaptMediaEvent MMC NAs

The following table lists Terminal Broker external events, exchanged between the sending subsystem and the receiving subsystem.

Event Sending Subsystem Receiving Subsys-tem

NotifyUserProfileChangeEvent Profile Manager (NB)

MMC

4.3.1.5 Test cases


MM1 Re-Registration on TB SIP-stack<-> TB, Re-Registration

MM2 Invite to NB SIP-stack<-> TB, Invite to NB

MM3 Close NB connection SIP-stack<-> TB, Close NB connection

MM4 Unregister on TB SIP-stack<-> TB, Unregister

MM5 Invite from TB SIP-stack<-> NB, Invite from TB

MM6 Close connection to TB(TB initiated)

SIP-stack<-> NB, Close connection to TB (TB ini-tiated)

MM7 Create a new MMM session (invite)

MMM client/SIP-stack<->MMMS, Create a new MMM session(invite)

MM8 A third party adds with the help of a called

MMM client/SIP-stack<->MMMS, A third party adds with the help of a called



MM9 Close connection; client initi-ated

MMM client/SIP-stack<->MMMS, Close connec-tion; client initiated

MM10 Update session, one client leaves the session

MMM client/SIP-stack<->MMMS, Update ses-sion, one client leaves the session

MM11 Check presence info(1) Start session, check presence info

MM12 Check presence info(2) User leaves session, check presence info

MM13 Check presence info(3) User joins session, check presence info

MM14 Change location Check if changed location is honored

MM15 Change pricing info(1) Check if changed service price is honored

MM16 Change pricing info(2) Check if changed price for network is honored

MM17 Change access network Check if change is honored

Test Case MM1 Partners involved: RAL, NTUA, TILS, LMU

Name SIP-stack<-> TB, Re-Registration

Goal of the test Re-registration works

Modules Capability Manager, Profile Manager, Service Manager, Policy Manager, mmadaptsaim, PolicyDecisionPoint, SBC, MMContext Manager


As described above

Scenario Description As the Registration on an IMS is valid for a limited period of time, the TB has to perform a Re-Registration at the IMS. The period of time when Re-Registration is required depends on the IMS-setting.

The TB has to send a Register message when the re registration timer expired.



Call Flow TB -> IMS

Expected Results The IMS will answer with 200 OK.


Notes none


Name SIP-stack<-> TB, Invite to NB

Goal of the test The TB should automatically send an Invite message to the NB after the successful registration (2.1).



As described above


Call Flow TB -> NB

Expected Results The NB must respond with a 200 OK to the TB.


Notes none


Name SIP-stack<-> TB, Close NB connection

Goal of the test The connection is closed

Modules Capability Manager, Profile Manager, Service Manager, Policy



Manager, mmadaptsaim, PolicyDecisionPoint, SBC, MMContext Manager


As described above

Scenario Description The logged in user logged out.

The TB should send a SIP-By message to the NB

Call Flow TB -> NB

Expected Results The NB should answer with an okay.


Notes none


Name SIP-stack<-> TB, Unregister

Goal of the test Verify that TB unregistration works correctly



As described above

Scenario Description A SIP-Unregister should be sent to the IMS after the successful completion of the SIP-By (2.3).

Call Flow TB -> NB

Expected Results User is not registered any more


Notes none




Name SIP-stack<-> NB, Invite from TB

Goal of the test SBC connection is established between TB and NB.



As described above

Scenario Description During SBC start up, after registration on IMS, a session will be set up from the TB to the NB using a SIP INVITE.

Call Flow • The TB should automatically send an Invite message to the NB after the successful registration on IMS.

• The NB must respond with a 200 OK to the TB.

Expected Results The sending of the SIP INVITE can be seen in the protocol.


Notes none


Name SIP-stack<-> NB, Close connection to TB (TB initiated)

Goal of the test Check if the user really loges out.



As described above



Scenario Description The logged in user loges out.

Call Flow The TB should send a SIP-BYE message to the NB

The NB should answer with a 200 OK.

Expected Results The UE is logged out.


Notes none


Name MM client/SIP-stack<->MMS, Create a new MM session(invite)

Goal of the test A session is established



As described above

Scenario Description One user sets up a new session in the Chat client window with two other participants

Call Flow • The UE1 sends an INVITE to UE2, UE3; this INVITE goes to the IMS server then further to the PoC server and then to UE2, UE3

• UE2 accepts and sends a 200 OK to the PoC server.

• The PoC server sends a create session to the MMS

• The MMS sends a session created to the PoC

• The PoC sends a 200 OK to the IMS

• The IMS sends the 200 Ok to the UE1, UE2



• The UE1, UE2 send an ACK to the PoC

Expected Results The RTP connection between Media Gateway and UE1 and UE2 is established


Notes none


Name MM client/SIP-stack<->MMS, A third party adds with the help of a call Id

Goal of the test Verify that a user can connect to an existing session



As described above

Scenario Description Assuming that an established session with two participants exists, a third user connects to it by providing the session ID to the chat client window

Call Flow • UE3 accepts and sends a 200 OK to the PoC server.

• The PoC server sends an update session to the MMS

• The MMS sends a session updated to the PoC

• The PoC sends a 200 OK to the IMS

• The IMS sends the 200 Ok to the UE3

• The UE3 sends an ACK to the PoC

Expected Results The RTP connection between Media Gateway and UE3 is estab-lished




Notes none


Name MM client/SIP-stack<->MMS, Close connection; client initiated

Goal of the test Verify session cancellation



As described above

Scenario Description The user click terminate session button

Call Flow • UE3, the last user sends a BYE message to MMC

• MMC releases the subscription for notification about UE3 context info on NB

• PoC sends a remove session record to MMC

• MMC sends a session removed to PoC

• PoC sends a 200 OK via IMS to UE3

Expected Results The session should be dropped in both participants


Notes none


Name MMM client/SIP-stack<->MMMS, Update session, one client



leaves the session

Goal of the test Verify what happens when a client leaves from an existing session



As described above

Scenario Description In a 3 or more participants session, one of the users clicks termi-nate session

Call Flow • UE3 sends a BYE message to MMC

• MMC releases the subscription for notification about UE3 context info on NB

• PoC sends an update session record to MMC

• MMC sends a session updated to PoC

• PoC sends a 200 OK via IMS to UE3

Expected Results All other participants see a user leave the session


Notes none

Test Case MM11 Partners involved: SAGO, NTUA

Name Check presence info (1)

Goal of the test Test what happens when a user starts a session to another user


Testbed �� onfiguretion

As described above



Scenario Description 1 user is logged in, he invites a user to a multimedia session

Call Flow • User1 inserts SD-device

• User1 logs into the system

• He selects a partner for the Multi media session and starts the session to the user2

• Now both users are in the session

Expected Results On both session GUIs the users should be seen in the start session window.


Notes none



Goal of the test Check what happens when the presence info changes in a session (a user leaves)



As described above

Scenario Description 3 users are in a session and one user leaves the session.

Call Flow • A session between user1, user2 and user3 has been established

• In the session GUI of each user a list with the 3 users can be seen.

• One user, it is user2 leaves the session.



• In user2 session GUI the users list is empty

• The session GUIs of the other two users are changed and contain now only user1 and user3.

Expected Results The two remaining users sessions should show that one user has left


Notes none



Goal of the test Test what happens when a user joins an existing session



As described above

Scenario Description 2 users are in a session and a third user joins the session with the same session identifier.

Call Flow • User1 and user2 are in a session

• User3 joins the session

• All 3 users see in their session GUI a list containing all 3 users

Expected Results The first two users should see the third user in the list of partici-pants frame. The third user should see a new established session


Notes none



Test Case MM14 Partners involved: SAGO, TILS

Name Change location

Goal of the test Test that the change of location is honored by the picture transfer



As described above

Scenario Description Two users start a session and one of them changes location.

Call Flow • User1 and user2 are in a session, user2 is at “office”

• User1 transfers a picture to user2, the picture is transferred

• User2 changes location to “home” where he has a lower cost limit

• User1 transfers a picture to user2, the picture is not displayed because the cost limit is exceeded

Expected Results After the user changes location, picture transfer should honor that.


Notes none

Test Case MM15 Partners involved: RAL, SAGO

Name Change price for service

Goal of the test Test that a change in pricing is honored by a picture transfer

Modules Capability Manager, Profile Manager, Service Manager, Policy Manager, mmadaptsaim, PolicyDecisionPoint, SBC, MMContext Manager, pricing subsystem

Testbed configura- As described above



tion

Scenario Description Two users are in a session and pricing information changes for one of them


• User1 transfers a picture to user2, user2 receives the picture

• The service costs are doubled

• User1 transfers a picture to user2, because of the high costs he receives a smaller picture.

Expected Results Changing pricing info and resending a picture should show a smaller picture size.


Notes none


Name Change price for network

Goal of the test Test that a change in pricing is honored by a picture transfer

Modules Capability Manager, Profile Manager, Service Manager, Policy Manager, mmadaptsaim, PolicyDecisionPoint, SBC, MMContext Manager, pricing subsystem


As described above

Scenario Description Two users are in a session and pricing information changes for one of them


• User1 transfers a picture to user2, user2 receives the picture



• The costs for network are doubled

• User1 transfers a picture to user2; because of the high costs he does receive a smaller picture.

Expected Results Changing pricing info and resending a picture should show a smaller picture size.


Notes none


Name Change access network

Goal of the test Test that a change in the access network is honored in the media adaptation calculation

Modules Capability Manager, Profile Manager, Service Manager, Policy Manager, mmadaptsaim, PolicyDecisionPoint, SBC, MMContext Manager, access network subsystem


As described above

Scenario Description Two users are in a session and one of them changes the access net-work

Call Flow • Two users are in a session

• One user user1 is on the access point

• The load on the access point is increased; therefore the costs for the service are also increased.

• User2 sends user1 a picture, the picture size gets smaller.

Expected Results A change in the access network should calculate a smaller picture size when sending pictures




Notes none

4.3.2 Media Streaming Scenario


This scenario environment is presented in the figure below.

Web Applications (HES)

Terminal

Network Broker

Use

r Int

erac

tion

thro

ugh

web

inte

rface

Extra informationexchange throughSimplicity specific

interaction

HES media service

ii)

i)

Figure 10. Media streaming scenario hardware and software environment setup

The Media Streaming scenario requires one PC hosting the Network Broker software, one PC hosting the HES service implementation and one PC hosting the “Personal Storage Service” and “Buy Music and Video Service” implementations, for the network side. The PC hosting the NB will be provided by SAGO as part of the Adaptive Multimedia Messaging scenario (MMPC1). The HES service will be hosted in the PC that hosts the Media Gateway for the Adaptive Multimedia Messaging scenario (MMPC2). Finally, the PC hosting the “Personal Storage Service” and “Buy Music and Video Service” is a laptop PC (MSPC1).

On the terminal side, the Media Streaming scenario requires one laptop terminal implementa-tion (MSPC2).



The hardware and software specifications for the devices involved are provided in The Ap-pendix (MMPC1, MMPC2, MSPC1, MSPC2).


The following list shows the extra components that are required in order to run the media streaming demo:

• MediaStoreSaim at the network side [class simplicity.subsystems.network.mediastoresaim.MediaStoreSubsystem]: This Saim communicates directly with the service implementation through UDP packets

• MediaStoreSaim at the terminal side [class simplicity.subsystems.terminal.mediastoresaim.MediaStoreSubsystem]: This SAIM represents the service to the terminal side. It interacts with the profile management on the terminal side and with the MediaStoreSaim at the network side.

• PersonalStorageSaim at the network side [class simplicity.subsystems.network.personalstoragesaim.PersonalStorageSubsystem]: This SAIM communicates with the Media Store service implementation, in order to notify the HES service of uploaded media files to the personal storage.

• A mySQL installation: The database hosts the personal storage files and the media store media files, as well as usernames/passwords and transactions.

• A Tomcat installation: A servlet container that hosts the Personal Storage and Media Store service implementations.

• HesSubsystem at the terminal side [class simplicity.subsystem.terminal.hes.HesSubSystem]: This Subsystem requests the profile and capability data from the terminal. After the receiving of the data he sends it to the HesSubSystemNB which is stored on the network side. After a successful transmittion the SAIM [class simplicity.subsystems.terminal.saim.BrowserControl] starts the Hes Streaming service in the default web browser.

• HesSubsystemNB at the network side [class simplicity.subsystems.network.hesNB.HesSubsystemNB] receives the profile and capability data form the HesSubsystem on the terminal side and sends it over an http request to the hes Streaming service on the Hes server.

• A Java Embedded Server (JES): A servlet container, which hosts the Hes Streaming service implementations




This section documents the steps required in order to properly install and configure the extra components listed above, for the Media Streaming section:

4.3.2.3.1 Step 1: mySQL installation

• Install mySQL version 4.1 windows build to MSPC1

• Create a user “root” with password “DlestHi”

• Set the max_allowed_packet=700MB property in my.ini and copy the file to c:\windows

• Create database “mediastore”

• Create the following tables:

drop table Users;

create table Users (username varchar(40), password varchar(40), simplic-ityUsername varchar(40));

drop table Music_Albums;

create table Music_Albums (id int auto_increment, artist varchar(80), album varchar(80), genre varchar(40), info varchar(150), price float (5,2) de-fault 0.0, price_per_track float(5,2) default 0.0, primary key(id)) type InnoDB;

drop table Music_Tracks;

create table Music_Tracks (id int auto_increment, album_id int, track_name varchar(80), track_no int default 0, price float(5,2) default 0.0, size int default 0, file longblob, foreign key (album_id) references Music_Albums (id) on delete cascade, primary key (id)) type InnoDB;

drop table Video;

create table Video (id int auto_increment, title varchar(80), artist var-char(80), description varchar(150), size int default 0, price float (5,2) default 0.0, file longblob, filename varchar(80), type varchar(40), primary key (id)) type InnoDB;



drop table Transactions;

create table Transactions (id int auto_increment, username varchar(40), al-bum_id int, track_id int, video_id int, Date varchar(40), foreign key (username) references Users (username) on delete cascade, foreign key (al-bum_id) references Music_Albums (id) on delete cascade, foreign key (track_id) references Music_Tracks (id) on delete cascade, foreign key (video_id) references Video (id) on delete cascade, primary key (id)) type InnoDB;

• Insert the user that will be used in the demo: insert into users (username, password, simplicityUsername) values (“testuser1”, “userpass1”, “TestBroker2”);

• Create the database “personal_storage”

• Create the following tables:

drop table users;

create table users (username varchar(40), password varchar(40), simplic-ityUsername varchar(40), primary key (username)) type InnoDB;

drop table files;

create table files (id int auto_increment, username varchar(40), directory varchar(600), filename varchar(200), size int, type varchar(40), file longblob, foreign key (username) references users (username) on delete cas-cade, primary key(id)) type InnoDB;

create table Transactions (username varchar(40), id int, primary key(id)) type InnoDB;

• Insert the user that will be used in the demo: insert into users (username, password, simplicityUsername) values (“testuser1”, “userpass1”, “TestBroker2”);

• Insert the default internal user: insert into users (username, password) values (“internalUser”, “internalPassword”);

• Fill in the “mediastore” database with media files.

4.3.2.3.2 Tomcat Installation

• Install Tomcat v5.5 on MSPC1

• Define the TCP port that Tomcat will listen to for default web traffic, in configuration file <Tomcat Install Dir>/config/server.log, service name = Catalina, Default non SSL connector.



• Configure the following servlet context parameters for the mediastore service storageHost: points to the host:port that will be reported to HES in order to download uploaded files MediaStoreSaimHost: points to host:port that the mediastoresaim is installed, the host will be the one that contains the NB and port should be 3500 PersonalStorageSaimHost: points to host:port that the personalStorageSaim is installed. The host will be the one that contains the NB and port should be 3501.

• Copy the two war files in <Tomcat installation dir>/webapps

• Make sure that between MSPC1 and the one hosting the NB there is no firewall blocking UDP traffic.

• Make sure that between MSPC1 and the terminal there is no firewall blocking web traffic on Tomcat’s listening port.

4.3.2.3.3 HES – Installation of Knopflerfish OSGi server

The Knopflerfish OSGi server runs on a standard PC running OS Linux Red Hat (MMPC1). The server requires a standard Java installation (e.g. Java 1.4.2). The Knopflerfish server and all necessary service bundles are stored in the HES-streaming-service.tgz file (http://server.ist-simplicity.org/d.php?C=IQokzGVBAaEJE8tL2r3C) which is uploaded to the simplicity server.

Installation, configuration and start:

• Unzip/ tar xvfz the tar file to the following location (/home/simplicity).

• Change to the folder /home/simplicity/knopflerfish_osgi_1.3.3. The server will be started by using the start script startKnopflerFish.

#!/bin/sh # set time: #echo set time #/usr/bin/sudo /usr/sbin/ntpdate timesrv.c-lab.de #echo time is set # set path echo set PATH export PATH=/usr/lib/java/bin:$PATH echo set LD_LIBRARY_PATH export LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" echo start Mimas in Knopflerfish ... java -jar framework.jar -xargs MimasPortal.xargs



• Inside this script set the PATH variable to your JAVA_HOME variable, to find the installed Java sources and the LD_LIBRARY_PATH variable which includes the necessary libaries for the streaming and converting mechanism.

• Edit the configuration file (/home/simplicity/knopflerfish_osgi_1.3.3/MimasProperties.xargs). Set the attribute

-Dde.clab.mimas.GatewayHost=192.168.138.200 to your IP

-Dde.clab.mimas.VideoServer=’PC-name’/’Your_IP’

the config file which is installed in the source tree is listed below:

#Mimas-Attribute -Dde.clab.mimas.VideoServer.port=8008 -Dde.clab.mimas.ExternStreaming.port=8282 -Dde.clab.mimas.Streaming.port=8282 -Dde.clab.mimas.InternStreaming.port=5003 -Dde.clab.mimas.UDPSocketListener.Port=2806 -Dde.clab.mimas.UDPSocketListenerPlayer.Port=2807 -Dde.clab.mimas.UseProxy=true -Dde.clab.mimas.GatewayHost=192.168.138.200 -Dde.clab.mimas.PathOfStreamingApplication=/home/simplicity/vlc/vlc-0.7.2/ -Dde.clab.mimas.PathOfConvertingApplication=/home/simplicity/vlc/ffmpeg-20041113/ -Dde.clab.mimas.PlayerTmpDir=/tmp/Player_tmp -Dde.clab.mimas.BundleSubDir=/home/simplicity/knopflerfish_osgi_1.3.3/MimasPortalBundles -Dde.clab.mimas.MountedVideoDir=/home/simplicity/video -Dde.clab.mimas.VdrTmpDir=/home/simplicity/public -Dde.clab.mimas.PlayerNoSoundEnabled=false -Dde.clab.mimas.PlayerFullScreenEnabled=false -Dde.clab.mimas.VideoServer=bobolink/192.168.138.200 -Dde.clab.mimas.Display_1=karumba/192.168.6.140 -Dde.clab.mimas.Display_2=sofia/192.168.6.200 -Dde.clab.mimas.Display_3=warwick/192.168.6.57 -Dde.clab.mimas.convertedFolder=converted #Ports for Streaming -Dde.clab.mimas.HttpInternStreamingPorts=8282;8283 -Dde.clab.mimas.HttpExternStreamingPorts=8282;8383 #Convert ranking of File-Formats -Dde.clab.mimas.operatingsystemList=Windows XP;Windows mobile -Dde.clab.mimas.mediaplayerList=Windows Media Player;vlc -Dde.clab.mimas.outputformatList=wmv;avi;mpg;mpeg;3gp;mp3 -Dde.clab.mimas.ConvertRanking=vdr;wmv;avi;mpg;mpeg;3gp -Dde.clab.mimas.videobitrateList=64;128;192;256;384;512 -Dde.clab.mimas.videoframerateList=5;10;15;20;25



-Dde.clab.mimas.videocodecList=msmpeg4v2;msmpeg4v1;msmpeg4;mpeg2video;mpeg1video;h263 -Dde.clab.mimas.mediaqualityList=2;5;10;15;20;31 -Dde.clab.mimas.audiobitrateList=8000;16000;32000;44100;48000 -Dde.clab.mimas.argumentSeparator=;

• Copy the public directory to the to the folder /home/simplicity. You will find the HES-public.tgz file on the simplicity server: http://server.ist-simplicity.org/d.php?C=xW$$teZjFHfqPX4XSYZ$

This folder includes the necessary local user and device profiles.

• Start the server and the services by running the start script: /home/simplicity/startKnopflerfish

• Without simplicity: Login to the service by using a standard firefox browser with the URL: http://’server_ip’:8008/MimasPortal/de/clab/mimas/Profile/StreamingService. The login name is ‘Jan’ and the password is ‘test1’.

• With simplicity: start the terminal broker, search the HES streaming service with the service manager, add the service, switch to your registered services and launch the service. The default web browser is started and the service is started with the simplicity user and device profile.

4.3.2.3.4 HES – Installation of streaming and converting applications

The ffmpeg conversion application and the vlc streaming application runs on a standard PC with the OS Linux. The applications are stored in the HES-applications-‘applicationname’.tgz file which are uploaded to the simplicity server.

The user can install the applications directly on the PC or use preinstallation files. The prein-stallation files have to be copied to special folder. The configuration and the make mechanism is not necessary.

Installation via configure, make and make install:

Sources are available at: http://www.videolan.org/vlc/download-sources.html

Download and unzip the following application and libraries in the folder (/home/simplicity/vlc). Then start with the configuration and installation of the applications. The list below describes the installation procedures.

• a52dec-0.7.4 (A52 - also known as AC3 - audio decoder)



• faad2-2.0 (AAC audio codec)

• faac (Libary for faad2-2.0)

• lame-3.96 (MP3 audio encoder)

• libmad-0.15 (MP3 audio decoder)

• mpeg2dec (MPEG2 Video Decoder)

• ffmpeg version 2 (conversion application)

• vlc version 0.7.2 (streaming application)

Configuration and installation:

Change to the directory /home/simplicity/vlc and start the installation with the following commands.

• a52dec-0.7.4 o ./configure o ./make o ./make install

• faad2-2.0 NOTE: The makefile comprise and error – at the end of the makefile replace the spaces with a tab!!! (Line 425 - 428)

o ./bootstrap o ./configure o ./make o ./make install

• faac o ./bootstrap o ./configure o ./make o ./make install

• lame-3.96 o ./configure o ./make o ./make install

• libmad-0.15 o ./configure o ./make o ./make install

• mpeg2dec o ./configure o ./make o ./make install



• ffmpeg version 0.4.9-pre 1 o ./configure --enable-a52 --enable-mp3lame --enable-faac --

enable-pp --enable-gpl --enable-amr_nb(-fixed ???) o ./make

• vlc version 0.7.2

o ./configure --enable-release --enable-livedotcom --disable-dvdread --enable-dshow --enable-alsa --enable-ncurses --with-ffmpeg-mp3lame --with-ffmpeg-tree=/home/simplicity/vlc/ffmpeg-0.4.9-pre1/--with-a52-tree=/home/simplicity/vlc/a52dec-0.7.4 --enable-faad --with-faad-tree=/home/simplicity/vlc/faad2 --disable-skins --disable-skins2 --disable-speex --enable-flac --enable-theora --disable-wxwindows --disable-visual

o ./make

Installation via copy:

• Create the folder ‘vlc’ in the /home/simplicity folder

• Unzip/ tar xvfz the following applications in the vlc folder:

o HES-application-a52dec.tgz

o HES-application-faac.tgz

o HES-application-faad.tgz

o HES-application-ffmpeg.tgz

o HES-application-lame.tgz

o HES-application-libmad.tgz

o HES-application-mpeg2dec.tgz

o HES-application-vlc.tgz

• Unzip/ tar xvfz the file HES-application-libaries.tgz to the folder /usr/local/lib. These libaries are necessary for the streaming and converting applications. This library path is set in the startKnopflerfish start script (LD_LIBRARY_PATH variable).

After a successful installation (copy) of the libaries, convertion and streaming applications the HES-streaming-service can be used.




The Personal Storage SAIM and Media Store SAIM introduce the following events to the NB and TB:

Event Sending Subsystem Receiving Subsystem

MediaStoreProfileRequest MediaStoreSubsystem (net-work)

MediaStoreSubsystem (termi-nal)

MediaStoreProfileResponse MediaStoreSubsystem (ter-minal)

MediaStoreSubsystem (net-work)

MessageDialogEvent MediaStoreSubsystem (net-work)

MessageDialogSubsystem (terminal)

HESNotifyEvent PersonalStorageSubsystem (network)

HESSubsystem (network)

The following events are not new, but are exchanged between the service saims and the pro-file management

GetUserPrefEvent MediaStoreSubsystem (ter-minal)

ProfileManagerSubsystem (terminal)

ReturnUserPrefEvent ProfileManagerSubsystem (terminal)


GetUserPrefResultEvent ProfileManagerSubsystem (terminal)


UpdatePrefEvent MediaStoreSubsystem (ter-minal)

ProfileManagerSubsystem (terminal)

UpdatePrefResultEvent ProfileManagerSubsystem (terminal)


4.3.2.5 Test cases

The test cases for the Media Streaming demo assume the use of the following log files:

• config/NetworkBroker/SBC.log will be referenced as NB_SBC.log



• config/TerminalBroker/SBC.log will be referenced as TB_SBC.log

• <Tomcat Install Dir>/logs/stdout_xxxxxx.log will be referenced as Tomcat.log

The following test cases are defined:


MS1 ProfileFetch Ensures that the user’s MediaStore profile can be suc-

cessfully retrieved from the SD and delivered to the ser-vice implementation

MS2 ProfileProcess Ensures that the user’s Media Store profile is successfully utilized by the service implementation

MS3 ProfileUpdate Ensures that the Media Store service can successfully up-date the user’s profile information to the SD

MS4 MediaTransfer Ensures that the purchased Media File is automatically transferred to the Personal Storage Service

MS5 MediaNotification Ensures that the HES is notified of recently transferred media files.

MS6 CapabilityProfile Process

Ensures that the Device capabilities are sent to the Hes Streaming Service.

MS7 UserProfileProcess Ensures that the User Profile is sent to the Hes Streaming Service.

MS8 StartHesService Ensures that the Hes Streaming Service is start in the de-fault web browser.

MS9 Start streaming Get the streamed media in a pop up web browser window

MS10 Start download Get the media file nad store it on HD

MS11 Start converting The media file will be converted in the format, which is placed in the capability profile

MS12 Get media infor-mation Get special media information (size, description, type)

MS13 Delete converted file The converted file can be deleted



MS14 User profile Show the simplicity user profile

MS15 Device capabilities Show the simplicity device capabilities

Test Case MS1 Partners involved: NTU, RAL

Name ProfileFetch

Goal of the test Ensure that the service gets the user’s profile from the SD

Modules MediaStore.war file, MediaStoreSAIM at the NB, MediaStore-SAIM at the TB, ProfileManagement at the TB



The user logs into the Media Store service, using the service pointer from the SPA.

The user clicks on the “View Profile” link on the Media Store front page.

Call Flow

The following call flow applies:

Service: MediaStoreServlet.viewProfile() calls the requestProfile() method of SimplicityProfileManager

Service: SimplicityProfileManager sends a UDP packet to Medi-aStoreSAIM at the NB with a profile request.

NB: MediaStoreSAIM sends a MediaStoreProfileRequest event to the TB

TB: MediaStoreSAIM interacts with the Profile Management

TB. MediaStoreSAIM responds with a MediaStoreProfileRe-sponse to the NB

NB: MediaStoreSAIM sends a UDP packet to the service with the profile.

Service: SimplicityProfileManager inserts the profile info in the



user’s session object.

Expected entries in log files

In NB_SBC.log there should be an entry about sending the Medi-aStoreProfileRequest event to the terminal broker

In TB_SBC.log there should be an entry about sending the Medi-aStoreProfileResponse event to the network broker

In Tomcat.log there should be no exceptions or error messages.

Expected Results A screen showing a table with the user’s profile should appear. The values in the screen should match the values that were inserted in the SD.


Notes none

Test Case MS2 Partners involved: NTU, LMU

Name ProfileProcess

Goal of the test Ensure that the service utilizes the user’s profile correctly

Modules MediaStore.war file, SPA




The user observes the front page which should provide personal-ized proposals for media files

The user browses the proposed media files and puts one in its shopping cart.

The user commits a media purchase and expects the payment screen to be automatically filled in.

Call Flow The following call flow applies:



Call flow is internal to the service for all functions besides the automatic form filling:

(the following functionality is simulated. Currently the service it-self fills in the forms with information taken from the profile)

The SPA implements a web proxy that automatically fills in forms.

Web traffic from the service goes to the SPA

The SPA fills in the payment form when it senses the payment URI

The SPA sends the html with the filled in form to the browser.

Expected entries in log files In Tomcat.log there should be no exceptions or error messages.

Expected Results

First Page: The Search field should be filled in with the user’s no1 preferred artist

First Page: The “May we propose” section at the bottom should provide personalized proposals for media files based on the user’s profile

Payment screen, should be automatically filled in by the SPA.

After committing the payment, the media file should be automati-cally transferred if the user has that preference or present a download link if the user does not have that preference


Notes none



Test Case MS3 Partners involved: NTU, RAL

Name ProfileUpdate

Goal of the test Ensure that the service can successfully send a profile update to the SD

Modules MediaStore.war file, MediaStoreSAIM at the NB, MediaStore-SAIM at the TB, ProfileManagement subsystem


Scenario Description The user logs clicks on the “View Profile” link

The user changes a profile preference and clicks submit changes

Call Flow


Service: MediaStoreServlet.viewProfile() calls the sendProfileUp-date() method of the SimplicityProfileManager

Service: SimplicityProfileManager sends a UDP packet to the Me-diaStoreSAIM at the NB

NB: MediaStoreSAIM sends a MediaStoreProfileRequest event to the TB with the updated profile values

TB: MediaStoreSAIM interacts with the ProfileManager

TB: MediaStoreSAIM sends a MediaStoreProfileResponse event to the NB with the updated profile

NB: MediaStoreSAIM sends a UDP packet to the service with the new profile.


In NB_SBC.log there should be an entry about sending a MediaS-toreProfileRequest event to the TB

In TB_SBC.log there should be an entry about sending a MediaS-toreProfileResponse event to the NB




Expected Results The user should logout and log back in the service, view the pro-file, and the profile should be updated with the change.


Notes none

Test Case MS4 Partners involved: NTU

Name MediaTransfer

Goal of the test Ensure that a purchased media file is automatically transferred to personal storage

Modules MediaStore.war file, Storage.war file, MediaStoreSAIM at the NB, MessageDialogSubsystem at the TB




The user browses the proposed media files and puts one in the shopping cart.

The user commits a media purchase and receives a popup window that a media transfer has successfully finished

The user logs out and logs in the Personal Storage service

The user finds the uploaded media

Call Flow


Service: MediaStoreServlet creates a FileUploader object to inter-act with personal storage.

Service: FileUploader commits the contents of the shopping cart to the Personal storage database directly



Service: MediaStoreServlet calls the sendMessage() method of the SimplicityProfileManager

Service: SimplicityProfileManager sends a UDP packet with the message to the MediaStoreSAIM

NB: MediaStoreSAIM sends a MessageDialogEvent to the TB

TB: MessageDialogSubsystem pops up the message to the user.


In NB_SBC.log there should be an entry for the transfer of the MessageDialogEvent to the TB.


Expected Results

The user should see a popup with a message saying how many media where transferred

The user should find the transferred media in the Personal storage Service.


Notes none

Test Case MS5 Partners involved: NTU, SBS

Name MediaNotification

Goal of the test Ensure that the HES service is notified of media files uploaded to the personal storage space.

Modules MediaStore.war file, Storage.war file, PersonalStorageSAIM, HESSubsystem



The user buys media files according to tesst case MS4.

The user logs out from the Media Store.

The user logs in the HES streaming service and finds the media



files.

Call Flow


Service: MediaStoreServlet creates a FileUploader object to inter-act with personal storage.

Service: FileUploader commits the contents of the shopping cart to the Personal storage database directly

Service: MediaStoreServlet calls the sendHESNotify() method of the SimplicityProfileManager

Service: SimplicityProfileManager sends a UDP packet with the message to the PersonalStorageSAIM at the NB

NB: PersonalStorageSAIM sends a HESNotifyEvent to the NB

NB: HESSubsystem : receives the event, prepares a http request and send it to the Hes Streaming Service


In DB mediastore.Transactions there should be an entry with the id of the purchased media file and the username, before the HES ser-vice collects the file.


Expected Results The user should be able to find the media file that he bought to the HES service.


Notes none

Test Case MS6 Partners involved: SBS

Name CapabilityProfileProcess

Goal of the test Ensures that the Capability Profile is sent to the Hes Streaming Service.

Modules hes, hesNB, capabilitymanager





The user want to use the Hes Streaming Service.

After selection of the service, the user profile is send from the hes on the terminal to the hesNB on the network (incl. response).

The hesNB prepares a http request and sends the capability profile with the methode sendXmlOverHttp to the Hes Streaming Service (incl. response)

Call Flow


TB: The user activates the the Hes Streaming Service in the SPA

TB: The Saim informs the HesSubsystem

TB: HesSubsystem collects capability profile and send it to the HesSubsystemNB on the network side

NB: The HesSubsystemNB prepares a http request and send the capability profile (xml style) with the methode sendXmlOverHttp to the Hes Streaming Service

Service: The Hes Streaming Service receives the the capability profile and prepares a session based communication. The sessionId will be send back to the HesSubsystemNB and to the HesSubsys-tem. All further communication are based on the sessionId.


Messages which are transported over the SBC are stored in the SBC.log file

Expected Results The user find parts of the capability profile in the Hes Streaming Service UI


Notes none




Name UserProfileProcess

Goal of the test Ensures that the User Profile is sent to the Hes Streaming Service.

Modules hes, hesNB, profilemanager




After selection of the service, the user profile is send from the hes on the terminal to the hesNB on the network (incl. response).

The hesNB prepares a http request and sends the user profile with the methode sendXmlOverHttp to the Hes Streaming Service (incl. response)

Call Flow


TB: HesSubsystem

TB: HesSubsystem collects user profile and send it to the HesSub-systemNB on the network side inclusive the sessionId from the CapabilityProfileProcess

NB: The HesSubsystemNB prepares a http request and send the user profile (xml style) with the methode sendXmlOverHttp to the Hes Streaming Service

Service: The Hes Streaming Service receives the the user profile and prepares a session based communication. The sessionId will be send back to the HesSubsystemNB and to the HesSubsystem. All further communication are based on the sessionId.


Messages which are transported over the SBC are stored in the SBC.log file

Expected Results The user find parts of the user profile in the Hes Streaming Service UI




Notes none


Name StartHesService

Goal of the test Ensures that the Hes Streaming Service is start in the default web browser.

Modules Saim, hes




After transmittion of the capability and user profile the hes Streaming Service starts in the defauft browser.

Call Flow


TB: HesSubsystem sends the received sessionId to the Saim, which start the Hes Streaming Service in the default browser over the class BrowserControl

Service: The user can act with the Service and stream, download, deleteand convert media files.

Expected entries in log files -

Expected Results The Hes Streaming Service start in the default web browser.

Test Results The Hes Streaming Service start in the default web browser

Notes If the service is not reachable, the TB concole print “Http connec-tion error ...”




Name Start streaming

Goal of the test Ensures that the Hes Streaming Service is start in the default web browser. The user receive a streamed media file.

Modules Hes service

Testbed con-figuration As described above.

Scenario De-scription

The user want to receive a media from the Hes Streaming Service.

The media file is shown in a pop up window of the web browser


Service: The user activates the streaming button .

Expected en-tries in log files

Log file on hes service:

/home/simplicity/Mimas/log/jes_simplicity_log_’date’

Expected Re-sults

A pop-up window opens and prepares the streamed media file in the wanted size and resolution.

Test Results A pop-up window opens and prepares the streamed media file in the wanted size and resolution.

Notes


Name Start download

Goal of the test Ensures that the Hes Streaming Service is start in the default web browser. The user download a wanted media file.

Modules Hes service

Testbed con- As described above.



figuration


The user want to download a media from the Hes Streaming Service.

The file can be stored on his HD.


Service: The user activates the download button .




Expected Re-sults A download window appears and the user selects the store location.

Test Results

A download window appears and the user selects the store location. Prob-lems: On some PCs the downloaded ascii code will be listed direct in the web browser window, or the media file will be start directly in the media player web browser plug-in.

Notes The problems depend on the configuration of the web browser.


Name Start converting

Goal of the test Ensures that the Hes Streaming Service is start in the default web browser. The user convert the media file in the wanted media format

Modules Hes service



The user want to convert a media from the Hes Streaming Service.

The file is stored in the correct format on the Hes server. After the con-vertion the file is ready to stream or download.




Service: The user activates the converting button .




Expected Re-sults

The media file is converted. The streaming and download buttons are en-abled.

Test Results The media file is converted. The streaming and download buttons are en-abled. The enabled buttons are listed after a reload (“Media List” button) of the services.

Notes The reload is necessary because of the servlet behavior. The http servlet need a user interaction to (re)load the UI.


Name Get media information

Goal of the test Ensures that the Hes Streaming Service is start in the default web browser. The user get information about the media file

Modules Hes service



The user want see the information of the media file.

The information page contains the file size, fiel name, date, type and a description. Furthermore any other converted format (mpg, wmv, 3gp, …) of the file are shown.


Service: The user activates the converting button .






Expected Re-sults User get different informations about the media file.

Test Results User get different informations about the media file.

Notes


Name Delete converted file

Goal of the test Ensures that the Hes Streaming Service is start in the default web browser. The user can deleted the converted media file

Modules Hes service


Scenario De-scription The user delete the media file.


Service: The user activates the delete button .




Expected Re-sults The conveted media file will be deleted.

Test Results The conveted media file will be deleted.

Notes




Name User profile

Goal of the test Ensures that the Hes Streaming Service is start in the default web browser. The user view the user profile, which was transferred from the Simplicity system.

Modules Hes service


Scenario De-scription The user profile is listed on the web browser.


Service: The user activates the User Profile button.




Expected Re-sults The user profile is listed on the web browser. The entires are disabled.

Test Results The user profile is listed on the web browser. The entires are disabled.

Notes The user can change the profile only in the Simplicity application.


Name Capability profile

Goal of the test Ensures that the Hes Streaming Service is start in the default web browser. The user view the capability profile, which was transferred from the Simplicity system.

Modules Hes service




Scenario De-scription The capability profile is listed on the web browser.


Service: The user activates the Device Profile button.




Expected Re-sults

The capability profile is listed on the web browser. The entries are dis-abled.

Test Results The capability profile is listed on the web browser. The entries are dis-abled.

Notes The user can change the profile only in the Simplicity application.

4.3.3 Tour Guide Scenario


In the tour guide scenario, the client application will run on a Motion Computing LS-800 ter-minal (TGPC2). The server-side of the Simplicity Tour Guide demonstrator is currently de-signed to run on a standard laptop (TGPC1). The Tour Guide server and Tour Guide client communicate using an 802.11b wireless link. The scenario will make use of the Network Bro-ker installed in MMPC1.

The hardware and software specifications for these devices are provided in The Appendix (TGPC1, TGPC2, MMPC1).



TGC_SAIM x x

TGS_SAIM x x



Tour Guide Client x x

Tour Guide Server x x


The Simplicity Tour Guide demonstrator stores tour guide related information in a separate <Service> element under the <ServiceList> node in the Simplicty User Profile. In the current instantiation of the Simplicity demonstrator, the Simplicty User Profile is stored in an XML file named profile.xml in the directory Simplicity/config/TerminalBroker. This XML file is then used to created “header.dat” and “SD.dat” to deploy the profile to specific Simplic-ity Devices (please refer to the file “how to deploy a profile.txt” for more detailed instructions on how to deploy a profile).

Here is a sample of a tour guide service related profile that is extracted from a user’s profile. ... <Service> <ServiceName>TourGuideService</ServiceName> <ser:Service> <ser:ServiceDescr> <ser:URL>http://www.ist-implicity.org/Service/TourGuide</ser:URL> <ser:Details>Tour Guide Service</ser:Details> </ser:ServiceDescr> </ser:Service> <PrefsPolicies> <Preference> <PreferenceKey>password</PreferenceKey> <PreferenceValue>ps</PreferenceValue> </Preference> <Preference> <PreferenceKey>groupname</PreferenceKey> <PreferenceValue>Simplicity</PreferenceValue> </Preference> <Preference> <PreferenceKey>anonymous</PreferenceKey> <PreferenceValue>false</PreferenceValue> </Preference> <Preference> <PreferenceKey>contactable</PreferenceKey> <PreferenceValue>true</PreferenceValue> </Preference> <Preference> <PreferenceKey>UIStyle</PreferenceKey> <PreferenceValue>java</PreferenceValue> </Preference> <Preference> <PreferenceKey>VisitedPlaces</PreferenceKey> <PreferenceValue>priory-3;museum-1;tic-2</PreferenceValue> </Preference> <Preference> <PreferenceKey>VisitedPages</PreferenceKey> <PreferenceValue>priory-3;museum-3;tic-4</PreferenceValue> </Preference> <Preference> <PreferenceKey>TourFollowed</PreferenceKey> <PreferenceValue>museum-tic-john;tic-john</PreferenceValue> </Preference> <Preference>



<PreferenceKey>Interests</PreferenceKey> <PreferenceValue>default-0;age-28;history-100;maritime-100;vegetarian-100;architecture-100</PreferenceValue> </Preference> </PrefsPolicies> </Service> ...

Besides general information about the service, such as name and namespace, the <Pref-sPolicies> section contains the following preference key/value pairs (all of them stored as Strings):

• password: the user’s password for the tour guide system

• groupname: if the user is currently travelling in a group, this section contains the name of the group

• anonymous: whether the user would like to remain anonymous (true/false)

• contactable: whether the user would like to be contactable by other users of the tour guide system (true/false)

• UIStyle: the user’s preferred user interface style

• VisitedPlaces: places the user has visited so far, including the number of visits per place

• TourFollowed: tours the user has followed so far

• Interests: the user’s interests, including a figure on how interested the user is in each topic on a scale from 0 (not interested at all) to 100 (extremely interested)

The name of the user, the user’s preferences regarding UI language and the user’s telephone number are retrieved from the general section of the user’s Simplicity User Profile.


Event Sending Sub-system

Receiving Subsystem

UserPresenceEvent SDAM TGC_SAIM

LoginCompleteEvent SDAM TGC_SAIM

GetUserPref TGC_SAIM Profile Man-agement



UserPref Profile Man-agement

TGC_SAIM

GetUserPref TGS_SAIM Profile Man-agement

UserPref Profile Man-agement

TGS_SAIM

GetLocationEvent TGC_SAIM Location In-formation Management

LocationEvent Location In-formation Management

TGC_SAIM

UpdateUserPrefEvent TGC_SAIM Profile Man-agement

UpdateUserPrefResultEvent Profile Man-agement

TGC_SAIM

4.3.3.5 Test cases


TG1 Detect User Presence Tour Guide client is notified about the presence of a new user

TG2 Login User logs in, Tour Guide Client receives event

TG3 Retrieve Preferences (Client-Side) Tour Guide Client retrieves user preferences

TG4 Retrieve Preferences (Server-Side) Tour Guide Server retrieves user preferences

TG5 Retrieve Location Tour Guide Client retrieves current location

TG6 Update Preferences Tour Guide Client updates preferences



Test Case TG1 Partners involved:

ULAN, RAL

Name Detect User Presence

Goal of the test Ensure that the tour guide application is able to detect the presence of a new user.

Modules SDAM, TGC-SAIM, Tour Guide Client (TGC)

Testbed configuration see above

Scenario Description User plugs in Simplicity device. Tour Guide Client is able to detect user’s presence.

Call Flow

• User plugs in Simplicity device

• SDAM generates UserPresenceEvent

• TGC-SAIM receives UserPresenceEvent

• TGC-SAIM delivers notification to Tour Guide Client

Expected Results A notification is delivered to the Tour Guide Client


Notes none


ULAN, RAL, DoCoMo, LMU

Name Login

Goal of the test Ensure that when a user has successfully logged in, the Tour Guide Application is notified.

Modules SPA, SDAM, TGC-SAIM, Tour Guide Client (TGC)



Testbed configura-tion see above

Scenario Description Users uses SPA to log in. Tour Guide Application is notified.

Call Flow

• Users uses SPA to log in

• SDAM generates LoginComplete event

• LoginComplete event is received by TGC-SAIM

• TGC-SAIM notifies TGC

Expected Results TGC receives notification from TGC-SAIM.


Notes


ULAN, TILS

Name Retrieve Preferences (Client-Side)

Goal of the test Ensure that the TGC is able to retrieve profile information from the Profile Management subsystem

Modules TGC, TGC-SAIM, Profile Management


Scenario Description Tour Guide Application attempts to receive profile information and preferences for the user currently using the application.

Call Flow

• TGC calls GetUserPref on TGC-SAIM

• TGC-SAIM emits GetUserPref event

• ProfileManagement receives UserPref event

• ProfileManagement responds with UserPref event



• TGC-SAIM returns profile information to TGC

Expected Results TGC receives requested profile information from the TGC-SAIM subsystem.


Notes


ULAN, TILS

Name Retrieve Preferences (Server-Side)

Goal of the test Ensures that the Tour Guide Server (TGS) is able to retrieve user preferences.

Modules TGS, TGS-SAIM, Profile Management subsystem


Scenario Description Tour Guide Server attempts to receive profile information and pref-erences for the user currently using the application.

Call Flow

• TGS calls GetUserPref on TGS-SAIM

• TGS-SAIM emits GetUserPref event

• ProfileManagement receives UserPref event

• ProfileManagement responds with UserPref event

• TGS-SAIM returns profile information to TGS

Expected Results TGS receives requested profile information from the TGS-SAIM.


Notes




ULAN, TILS

Name Retrieve Location

Goal of the test Ensures that the Tour Guide Client is able to obtain information about the terminal’s current location from the Location Information Subsystem.

Modules TGC, TGC-SAIM, Location Information subsystem


Scenario Description Tour Guide Application requests a location update from the location information subsystem to determine the user’s current location.

Call Flow

• TGC requests location information from TGC-SAIM

• TGC-SAIM emits GetLocation event

• Location Information subsystem receives GetLocationEvent

• Location Information subsystem emits LocationEvent

• TGC-SAIM receives LocationEvent

• TGC-SAIM delivers LocationEvent to TGC

Expected Results TGC receives requested location information.


Notes




ULAN, TILS

Name Update Preferences

Goal of the test Ensure that profile information collected while the user is using the TGC is written back to the user’s Simplicity Profile.

Modules TGC, TGC-SAIM, Profile Management


Scenario Description The Tour Guide Application updates the user’s preferences, e.g. re-flecting attractions recently visited.

Call Flow

• TGC invokes UpdateUserPref on TGC-SAIM

• TGC-SAIM emits UpdateUserPref event

• ProfileManagement subsystem receives UpdateUserPref event

• ProfileManagement subsystem updates user’s Simplicity Profile

• ProfileManagement Subsystem emits UpdateUserPrefResult event

• UpdateUserPrefResult event is received by TGC-SAIM

• TGC-SAIM communicates result to TGC

Expected Results User’s Simplicity Personal Profile is updated accordingly. TGC re-ceives information about result of operation.


Notes



4.3.4 Simplicity Aware Service Environment Scenario

4.3.4.1 MyPC scenario

4.3.4.1.1 Description of the demonstration environment

This scenario environment is presented in the figure below. The hardware and software re-quirements for the environment follow.

Figure 11. MyPC scenario

The MyPC scenario requires one PC hosting the Network Broker software and one or two PC hosting the Terminal Broker software. There are no other specific ��

The hardware and software features of the PC hosting the Network Broker are shown in the standard demonstrator environment.�

4.3.4.1.2 Availability of components

The MyPC scenario requires no additional components.



4.3.4.1.3 Demonstrator setup

The my MyPC scenario requires no specific configuration procedure; the MyPC demo is con-figured automatically.

4.3.4.1.4 Event matching

The MyPC SAIM introduce the following events to the NB and TB:


GetCapabilityProfileEvent MyPCsubsystem (terminal) CapabilityManagerSubsystem (terminal)

ReturnCapabilityProfileEvent CapabilityManagerSubsystem (terminal)

MyPCsubsystem (terminal)

GetUserPrefEvent MyPCsubsystem (terminal) ProfileManagerSubsystem (terminal)



UpdatePrefEvent MyPCsubsystem (terminal) ProfileManagerSubsystem (terminal)



LoginCompliteEvent SDAM (terminal) MyPCsubsystem (terminal)

InsertEvent MyPCsubsystem (terminal) SDS (network)

InsertResultEvent SDS (network) MyPCsubsystem (terminal)

RetrieveEvent MyPCsubsystem (terminal) SDS (network)

RetrieveResponseEvent SDS (network) MyPCsubsystem (terminal)

Table 4. events specification

4.3.4.1.5 Test cases

The test cases for the MyPC demo assume the use of the following log files:



• NB log console

• TB log console

The following test cases are defined:


SASE1 Set Wallpaper Ensures that User’s Preferred Wallpaper stored on profile is successfully retrieved from SMS and displayed on desktop.

SASE2 Set Bookmarks Ensures that User’s bookmarks are retrieved from SDS and inserted in IE/Mozilla favorites lists.

SASE3 Set Address Book Ensures that User’s Address book is fetched from SDS and correctly in-serted in the Client Outlook Express installation.

SASE4 Save Current Pro-file

Ensure that user profile is successfully updated with the current user’s preferences. Bookmarks,Addressbook and wallpaper are inserted in SDS.

SASE5 Client Restore Ensure that the client environment is correctly restored when user logout

Test Case SASE1 Partners involved: TILS, RAL, SBS

Name Set Wallpaper

Goal of the test Ensures that User’s Preferred Wallpaper stored on profile is suc-cessfully retrieved from SMS and displayed on desktop.

Modules MyPC at the TB, ProfileManager at the TB, CapabilityManager at the TB, SDAM at the TB, SDS at the NB


Scenario Description The user login on Simplicity; MyPC starts automatically.


TB: SDAM sends a LoginComplite event to MyPCsystem



TB: MyPCsystem sends a GetUserPref event to ProfileManagerTB (for the service info)

TB: ProfileManagerTB reply with a ReturnUserPref event to MyPCsystem

TB: MyPCsystem sends a GetUserPref event to ProfileManagerTB (for the profile info)


TB: MyPCsystem sends a GetCapabilityProfile event to Capabili-tyManagerTB

TB: CapabilityManagerTB reply with a ReturnCapabilityProfile event to MyPCsystem

NB: MyPCsystem sends a Retrieve event to SDS

NB: SDS reply with a RetrieveResponse event to MyPCsystem


(NB Log output)

SDS: Requested Retrieve from SDS for user: [username]

SDS: Send RetrieveResult from SDS for user: [username]

(TB Log output)

MyPC: received Login_Complite event

MyPC: send User Data Profile request event

MyPC: send preference user profile request event

MyPC: getted user profile for user MyPCsubs_userpref

MyPC: getted user profile for user MyPCsubs_userdata

CM: Received GetCapabilityProfile event for parameter

MyPC: getted device capability

MyPC: retrieved data from SDS for user "[username]", data



desciption: wallpaper_MyPC

MyPC: user wallpaper saved on local file

Test Results Desktop wallpaper successful update

Expected Results The user should be able to view his preferred wallpaper on the screen.

Notes None


Name Set Bookmarks

Goal of the test Ensures that User’s bookmarks are retrieved from SDS and in-serted in IE/Mozilla favorites lists.




Call Flow







TB: MyPCsystem sends a GetCapabilityProfile event to Capabili-



tyManagerTB





(NB Log output)

SDS: Requested Retrieve from SDS for user: [username]


(TB Log output)








MyPC: retrieved data from SDS for user "[username]", data desciption: bookmarks_MyPC

MyPC: user bookmarks saved on local file

Test Results IE or Mozilla FireFox bookmarks successful updates.

Expected Results The user should be able to find out his own bookmarks inserted in IE and Mozilla.

Notes None.




Name Set Address Book

Goal of the test Ensures that User’s Address book is fetched from SDS and cor-rectly inserted in the Client Outlook Express installation.




Call Flow











Expected entries in (NB Log output)



log files SDS: Requested Retrieve from SDS for user: [username]


(TB Log output)








MyPC: retrieved data from SDS for user "[username]", data desciption: addressbook_MyPC

MyPC: user addressbook saved on local file

Test Results AddressBook successful update.

Expected Results The user should be able to find out his own Address book avail-able from Outlook Express.

Notes None.


Name Save Current Profile

Goal of the test Ensure that user profile is successfully updated with the current user’s preferences. Bookmarks, Addressbook and wallpaper are inserted in SDS.





Scenario Description The user login off. Previous settings are restored.

Call Flow


TB: SDAM sends a UserLoggedOut event to MyPCsystem







NB: MyPCsystem sends a Insert event to SDS (for Wallpaper data)

NB: SDS reply with a InsertResult event to MyPCsystem (for Wallpaper data)

NB: MyPCsystem sends a Insert event to SDS (for AddressBook data)

NB: SDS reply with a InsertResult event to MyPCsystem (for Ad-dressBook data)

NB: MyPCsystem sends a Insert event to SDS (for Favorites data)

NB: SDS reply with a InsertResult event to MyPCsystem (for Fa-vorites data)

Expected entries in log files (NB Log output)



Requested Insert in SDS for user: [username]

Send InsertResult in SDS for user: [username]





(TB Log output)

MyPC: received User_Logged_Out event







MyPC: inserted user wallpaper in SDS for user "[username]"

MyPC: inserted user bookmarks in SDS for user "[username]"

MyPC: inserted user addressbook in SDS for user "[username]"

Test Results User personal data are stored into SDS.

Expected Results User’s profile is updated and inserted in storage. This operation is visible only from the log output.

Notes None.



Test Case SASE5 Partners involved: TILS

Name Client Restore

Goal of the test Ensure that the client environment is correctly restored when user logs out

Modules MyPC at the TB


Scenario Description The user login off. Previous settings are restored.

Call Flow None.


MyPC: save procedure started

MyPC: save user Wallpaper

MyPC: save user AddressBook

MyPC: save user Bookmark

Test Results The system environment returns to the status before the user login.

Expected Results The user should be able to verify that the previous system envi-ronment is correctly restored. User’s personal data is deleted from the system.

Notes None.

4.3.4.2 I-Provisioning Scenario

This scenario environment and its relationship with the Simplicity system are presented in the figure below.



Figure 12. I-Provisioning demonstrator setup

The i-Provisioning scenario will require only one laptop PC hosting the Network Broker soft-ware and the i-Provisioning service (included application bundles) for the network side. The laptop PC hosting the NB will be provided by TILS as part of the Simplicity Aware Service Environment scenario.

On the terminal side, the i-Provisioning scenario requires one laptop terminal implementation.

4.3.4.2.1 Availability of components

The following list shows all components that are required to run the i-Provisioning demo:

• IProvisioningSubsystem on the network side [class simplicity.subsystems.network.IProvisioningSubsystem.IProvisioningSubsystem] receives profile and capability data form the capability/profile NB manager and location information and sends them to the policy NB subsystem that processes them. A response for bundles availability is sent to the i-Provisioning server by means of an http request.

• IProvisioningTCPServer on the network side [class simplicity.subsystems.network.IProvisioningSubsystem.IProvisioningTCPServer]: this communicates directly with the service implementation through TCP socket.

• IProvisioningSaim at the terminal side [class simplicity.subsystems.terminal.IProvisioningSaim.IProvisioningClientSAIM]: this



SAIM represents the service to the terminal side. It interacts with the profile management on the terminal side and with the i-Provisioning subsystem on the network side. It also is responsible for launching of i-Provisioning service browser.

• A Tomcat installation: A servlet container that hosts the i-Provisioning service implementations.

4.3.4.2.2 Demonstrator setup

This demonstrator requires an installed Tomcat v5.5 (such as on MSPC1). The only non-automatic action is to copy war files related to service into the path <Tomcat installation dir>/webapps and make sure that there is no firewall blocking UDP traffic on the installed PC.

The Simplicity i-Provisioning demonstrator stores related information into the <Service> element under the <ServiceList> node in the Simplicty User Profile (stored in an XML file named profile.xml in the directory Simplicity/config/TerminalBroker).

Here is a sample of an i-Provisioning service related profile, extracted from the profile.xml ... <Service> <ServiceName>iProvisioningService</ServiceName> <ser:Service> <ser:ServiceDescr> <ser:CostLimit/> <ser:URL>http://www.istsimplicity.org/Service/iProvisioningService</ser:URL> <ser:Details/> </ser:ServiceDescr> </ser:Service> <PrefsPolicies> <Preference> <PreferenceKey>StartTimeWork</PreferenceKey> <PreferenceValue>9</PreferenceValue> </Preference> <Preference> <PreferenceKey>StopTimeWork</PreferenceKey> <PreferenceValue>18</PreferenceValue> </Preference> <Preference> <PreferenceKey>OfficeFinancialAppl</PreferenceKey> <PreferenceValue>yes</PreferenceValue> </Preference> <Preference> <PreferenceKey>OfficeCorporateAppl</PreferenceKey> <PreferenceValue>yes</PreferenceValue> </Preference> <Preference> <PreferenceKey>HomeGameAppl</PreferenceKey> <PreferenceValue>yes</PreferenceValue> </Preference> <Preference> <PreferenceKey>HomeShoppingAppl</PreferenceKey> <PreferenceValue>yes</PreferenceValue> </Preference> <Preference> <PreferenceKey>HomeTravelAppl</PreferenceKey> <PreferenceValue>yes</PreferenceValue>



</Preference> <Policy> <Content>String</Content> </Policy> </PrefsPolicies> <UserRelatedData/> <SessionList> <Session> <SuspendedApplication> <UserSessionData/> </SuspendedApplication> </Session> </SessionList> </Service> ...

This profile part contains general information about the service and user preferences, ex-pressed as key/value pairs (all of them stored as Strings).

4.3.4.2.3 Event matching

The two subsystem (IProvisioningSaim on TB and IProvisioningSubsystem on NB) exchange information through the following events:


IProvisioningProfileRequestEvent IProvisioningSaim (TB) IProvisioningSubsystem (NB)

IProvisioningProfileResponseEvent IProvisioningSubsystem (NB)

IProvisioningSaim (TB)

SendUserNameEvent IProvisioningSaim (TB) IProvisioningSubsystem (NB)

SendUserNameEventResponse IProvisioningSubsystem (NB)


The following events are not new, but are exchanged between the IProvisioningSaim (on TB) and the profile management and SDAM on TB

LoginCompleEvent SDAM subsystem IProvisioningSaim (TB)



GetUserPrefResultEvent ProfileManagerSubsystem (terminal)


UpdatePrefEvent IProvisioningSaim (TB) ProfileManagerSubsystem



(terminal)



4.3.4.2.4 Test cases


IP1 Retrieve capability information User logs in and i-Provisioning subsystem re-ceives event with device capability information

IP2 Retrieve Location information I-Provisioning receives notification from loca-tion on NB for a new user position

IP3 StartProvisioningService Ensures that the i-Provisioning Service has started on the default web browser.

IP4 Interaction with Policy to ob-tain a result

I-Provisioning sends to PolicyManager a get-PolicyDecisionRequest to procure a result

IP5 Start download Start specific application bundle download and store it on client HD

Test Case IP1 Partners involved: TILS

Name Retrieve capability information

Goal of the test Ensures that the Capability Profile is sent to the i-Provisioning Service.

Modules IProvisioningSubsystem, capabilityNBmanager


Scenario Description User logs in and I-Provisioning receives a notify for user device capabilities changes and it can get information it needs

Call Flow • At start-up I-Provisioning subscribes for Device Capability Changes with capabilityNBmanager



• User logs in

• The capabilityNBmanager sends to i-Provisioning subsys-tem capability file

• i-Provisioning subsystem extracts username and device in-formation


Messages on NB LogginCollector show action happened with suc-cess

Expected Results The i-Provisioning subsystem store capability info and it knows user has logged in


Notes none


Name Retrieve Location information

Goal of the test Ensures that the i-Provisioning is able to obtain information about the terminal’s current location from the Location Subsystem on NB.

Modules IProvisioningSubsystem, LocationSubsystem


Scenario Description I-Provisioning application has done a subscription for location up-dates from the location subsystem to determine the user’s current position.

Call Flow

• At start-up I-Provisioning subscribes for Location changes with Location subsystem on NB

• When there is a new user position Location subsystem sends an event to i-Provisioning subsystem that contains



position update

• i-Provisioning subsystem extracts relative information

Expected Results I-Provisioning receives updated location information.


Notes

Test Case IP3 Partners involved: TILS, SBS

Name StartProvisioningService

Goal of the test Ensures that the i-Provisioning Service is start in the default web browser.

Modules Saim, IProvisioningSaim



The user want to use the i-Provisioning Service and he push on SPA relative button.

The i-Provisioning service starts in the default browser.

Call Flow

• The IProvisioningSaim sends the received sessionId to the Saim, which start the I-Provisioning service in the default browser over the class BrowserControl

• The browser html page actives a redirect to Tomcat servlet html while is waiting for policy result (see next test case IP4…)

Expected Results The default web browser opens and the i-Provisioning service starts in it.

Test Results The i-Provisioning service start in the default web browser and an inscription like “i-Provisioning is searching for bundles…” ap-pears on it.



Notes

Test Case IP4 Partners involved: TILS, LMU

Name Interaction with Policy to obtain a result

Goal of the test To obtain policy result, i.e. a list of bundles can be shown to user by means of web browser

Modules IProvisioningSubsystem, PolicyManager, PolicyDecisionPoint


Scenario Description I-Provisioning sends to PolicyManager a getPolicyDecisionRequest to obtain a result to forward to Tomcat servlet application

Call Flow

• After web browser was opened i-Provisionig subsystem sends a request to PolicyManager that contains capabilities, location, user profile and some system information as facts

• Policy system adds facts into repository.xml

• Policy Manager forwards request to PDP

• PDP executes Jess code relative to specified policyID and it sends the event corresponding to the PolicyID to i-Provisionig subsystem containing request result.

Expected Results List of downloadable bundles appears on web browser

Test Results List of downloadable bundles appears on web browser

Notes




Name Start download

Goal of the test The user download one of available context aware bundles.

Modules IProvisioningSubsystem



The user want to download a bundle application from the i-Provisioning Service.

The file is stored automatically on his HD

Call Flow • Only one action is asked to user: to click on preferred bun-dle to stat download

Expected Results A download window appears and the user selects the store location.

Test Results A download window appears and the user selects the store location.

Notes

There may be a problem:

• If client is a laptop, it needs of JavaWebStart application to automatically run the bundle download

4.3.5 Campus Network Scenario


The scenario of the Campus Network demonstrator is depicted in the figure below. The hard-ware and software environment follow.



NB

BWmonitor

802.11 AP

BWmonitor

802.11 AP

switch Ethernet

TB

SD

non-Simplicity terminal

SPA

Simplicityterminal

Wi-Fimanager

Web Surfingmanager

non-Simplicity terminal

mediator

SBC

SBC

mediator

CNAC

SDAM/PM

SAIMCNAC

Figure 13. Campus Network scenario hardware and software environment setup

The Campus Network scenario requires one PC hosting the Network Broker software (in-cluded the CNAC subsystem) (MMPC1), two notebooks acting as 802.11 APs, (CNPC1/2) and a simple switch Ethernet. The PC hosting the NB (MMPC1) will be provided by SAGO, whereas the two AP notebooks (CNPC1/2) will be provided by RAL.

On the terminal side, the Campus Network scenario requires one Linux-based laptop (CNPC3) hosting a subset of the Terminal Broker software needed to show the access network control capabilities of Simplicity. The hardware/software requirements are reported in the ta-ble below.

Note that this scenario needs two non-Simplicity laptops (CNPC4/5) to vary the traffic load on the two APs wireless channel. We highlight that it is also possible to emulate CBR traffic load on the two APs using a software module (ChangeShMem) we have developed.

Hardware and software specifications for all devices are provided in The Appendix (MMPC1, CNPC1/2, CNPC3, CNPC4/5).




The components involved in running the Campus Network demonstration are listed below:

• Network side:

o CNAC Subsystem on the NB [class simplicity.subsystems.network.cnac.CnacSubsystem]: this is the subsystem which manage the access control to the wireless network of the campus;

o hostAP driver on each Access Point: this is the driver which allows a standard laptop with a PRISM2 wifi card to act in Master Mode (i.e. as an Access Point);

o BW monitor on each Access Point [sources in the folder <Simplicity root folder>/AppsForCnac/bwmonitor]: this is the C module which measures the actual used bandwidth on the wireless interface of each Access Point and communicates this information periodically to the CNAC on the NB through a UDP network socket;

• Terminal side:

o Wi-Fi manager on the TB [sources in the folder <Simplicity root folder>/AppsForCnac/wifimanager]: this is a C module developed to interact with the 802.11b wireless card serving the requests of the CNAC in the TB; the interaction with the wireless card is achieved using the Linux ‘wireless extensions’ available in the kernel of the Mandrake 10.0 distribution; note that these extensions support any wireless card containing a chipset whose driver supports wireless extensions; we use a PRISM2 card with hostAP driver in Managed mode;

o Web Surfing manager on the TB [sources in the folder <Simplicity root folder>/AppsForCnac/websurfingmode/Muffin]: this is a modified version of Muffin (see http://muffin.doit.org/ ), a java based proxy which serves the requests of the CNAC on the TB in order to set the correct web surfing mode;

o CNAC Subsystem on the TB [class simplicity.subsystems.terminal.cnac.CnacSubsystem]: this is the subsystem which communicates network and user context to the CNAC on the NB in order to make it selects the best allowed Access Point among those heard by the terminal and the correct web surfing mode; it then manages the wireless connection, interfacing with the Wi-Fi manager through a TCP local socket and set the correct web surfing mode interfacing with Web Surfing Manager through a TCP local socket too;



• Others:

o D-ITG (Distributed Internet Traffic Generator), available at http://www.grid.unina.it/software/ITG/index.php: this software is used to change the load condition of the wireless network; we will use a source on a legacy laptop which generates CBR traffic toward a sink located on the Access Point we want to load.


This section documents the configuration operations needed to properly run the components listed above:

• Network side:

o CNAC Subsystem on the NB: the configuration parameters are read from the file <Simplicity root folder>/config/NetworkBroker/CnacConfig/cnac.conf; this is a binary file accessed also by CnacApplication GUI [class simplicity.subsystems.cnac.cnacapplication.CnacApplication] through which it is possible to change the configuration parameters (for further information on CnacApplication and the meaning of the configuration parameters, see section 8.5.5);

o hostAP driver on each Access Point: in order to compile and install the hostAP driver, you have to:

� install the kernel sources: these are contained among the .rpm packages of the distribution CDs (file kernel-source-2.6.3-7mdk.rpm);

� install ‘pcmcia-cs’ .rpm package from distribution CDs, if not already installed on your system (file pcmcia-cs-3.2.5-3mdk.rpm);

� download the hostAP driver from http://hostap.epitest.fi/ (we used version 0.2.4) and decompress the tar.gz archive;

� in the decompressed folder, there is a Makefile file: in it change the KERNEL_PATH variable to point to the just installed kernel sources (usually /usr/src/linux);

� open a shell, position in the root of the decompressed folder (where the Makefile is) and run the following command with root privileges:

make && make install



� restart ‘cardmgr’: to restart the cardmgr you have to get its process id (pid) and use it to kill the process; to obtain the pid use (also with root provileges):

ps –aux|grep ‘cardmgr’

you will see an output with a line like this:

…

root 1086 0.0 0.1 1736 484 ? S 10:07 0:0 /sbin/cardmgr

…

in which the pid is 1086; using this number kill and restart the cardmgr with the following command as root:

kill 1086 && cardmgr

� now the driver is installed; if you plug in your wireless card, executing the command ‘lsmod’ from a shell with root privileges you should see entries relative to the ‘hostap’ module; if this is not the case , it may depend on the fact that the wireless card identifier is already associated with another driver, and you have to manually edit the file /etc/pcmcia/config as follows, otherwise continue with the ‘BW monitor on each Access Point’ section:

• with your wireless card plugged in execute as root the command:

cardctl ident

you will obtain an output like the following:

Socket 0:

product info: "Wireless", "LAN Adapter", "Version 01.02", ""

manfid: 0x0156, 0x0002

function: 6 (network)

take note of the manfid codes;

• open the file /etc/pcmcia/config, locate the section

#



# Device driver definitions

#

and add the following lines:

device "hostap_cs"

class "network" module "hostap", "hostap_cs"

• in the same file locate the section

#

# Wireless network adapters

#

and search for the manfid you have take note of; after this, change the bind to the driver as in the following in which the bind to the ‘orinoco_cs’ module has been commented:

#

# Wireless network adapters

#

……

card "Intersil PRISM2 11 Mbps Wireless Adapter"

manfid 0x0156, 0x0002

# bind "orinoco_cs"

bind "hostap_cs"

………

• now you have to kill and restart ‘cardmgr’ as previously explained; at this point the ‘lsmod’ command should show entries referred to hostap driver.

o hostapd: this is a linux daemon developed by the hostAP driver project. It is used to limit the access to the restricted Simplicity AP through a MAC filtering mechanism; the procedure to install this software is as follows:



� download the hostapd package from http://hostap.epitest.fi/ (we used version 0.3.7) and decompress the tar.gz archive;

� open a shell and position in the decompressed folder;

� run the following command with root privileges:

cp defconfig .config && make

� in the file hostapd.accept, insert the MAC address of the terminals you want to allow;

� in the file hostapd.conf make the following changes:

Original file Changes

…

ssid=test

…

macaddr_acl=0

…

#accept_mac_file=/etc/hostapd.accept

…

…

ssid=simplicity_restricted

…

macaddr_acl=1

…

accept_mac_file=./hostapd.accept

…

make sure to uncomment the line relative to the ‘accept_mac_file’ pa-rameter (i.e. remove the # character)

� run the daemon with the following command (again with root privileges and in the decompressed folder mentioned above):

./hostapd hostapd.conf

from now on only the terminals the MAC of which is listed in ‘hostap.accept’ will be allowed to associate with this AP.

o BW monitor on each Access Point:

� if not already installed on your system, install the ‘bridge-utils’ package from the distribution CDs (file bridge-utils-0.9.6-2mdk.rpm);

� if not already installed, install the ‘wireless tools’ package from the distribution CDs (file wireless-tools-26-3mdk.rpm) which will be used to configure the AP;



� configure the Essid, the Mode of operation and the channel of the AP: in order to do this you have to use an utility included in the ‘wireless tools’ for linux; the command to use, with root privileges, is:

iwconfig wlan0 essid <essid_string> mode Master channel <channel_number>

For example:

iwconfig wlan0 essid simplicity_everyone mode Master channel 3

� change the Access Point IP, netmask and broadcast address in the script file <Simplicity root folder>/AppsForCnac/bwmonitor/BridgeConfigurationScript/createbridge.sh according to those of the AP; the content of the file is reported in the following table:

#!/bin/sh

# This code create a bridge (br0) between the wired (eth0) and wireless (wlan0) interface of the Ac-cess Point

# NB: the bridge address, netmask and broacast parameters depends on the actual network

# create the bridge and add eth0 and wlan0 to it

brctl addbr br0

brctl addif br0 eth0

brctl addif br0 wlan0

#configure the interfaces to be managed by the bridge

ifconfig eth0 0.0.0.0

ifconfig wlan0 0.0.0.0

#configure the bridge

ifconfig br0 141.250.40.33 netmask 255.255.255.0 broadcast 141.250.40.255 up

� run the script with root privileges;

� in the file <Simplicity root folder>/AppsForCnac/bwmonitor/src/bwmonitor.conf change the ‘APessid’ and ‘APIP’ parameters with those of the AP on which the software is running; the other parameters in the file are default values and can be also modified remotly in run time from the CnacApplication GUI, anyway you can already change the IP address (NetworkBrokerIP)



and port (NetworkBrokerPort) on which the CNAC on the NB will listen for bandwidth data from the APs; the content of the file is reported in the following table:

# Configuration file for Bandwidth Monitoring

# Network Broker IP

NetworkBrokerIP = 141.250.40.212;

# Network Broker Port

NetworkBrokerPort = 30022;

# Access Point IP

APIP = 141.250.40.33;

# Access Point Port

APPort = 30018;

# Access Point ESSID

APessid = simplicity_everyone;

# Measure Window

MeasureWindow = 2;

# Update Period

UpdatePeriod = 2;

� in the folder <Simplicity root folder>/AppsForCnac/bwmonitor/src/ the executable ‘bwmonitor’ should be present; if not you can compile it from the sources as follows; the BW monitor module (but what follows is valid also to compile the Wi-Fi manager module) has been developed using kdevelop IDE, which is the standard software IDE for C in linux, and with ‘AutoTools’ suite for the generation of the Makefiles of the project; the version of AutoTools that ships with the Distribution CDs has anyway some bugs, to compile the sources, you have to upgrade them at least to the following versions:

• autoconf-2.5.4.tar.gz (http://ftp.gnu.org/gnu/autoconf/ )

• automake-1.6.1.tar.gz (http://ftp.gnu.org/gnu/automake/ )



• libtool-1.5.10.tar.gz (ftp://ftp.gnu.org/gnu/libtool/ )

For the installation just follow the file ‘INSTALL’ in each of the above package;

� to compile the project, open the project file <Simplicity root folder>/AppsForCnac/bwmonitor/bwmonitor.kdevelop in the kdevelop IDE; from the menu ‘Build’ run the following commands:

• Clean Project

• Distclean

• Run automake & friends

• Build project

� run the BW monitor application with root privileges, launching the ‘bwmonitor’ executable in the folder <Simplicity root folder>/AppsForCnac/bwmonitor/src/;

� It is possible to emulate CBR traffic by setting a positive offset (in Kb/s) which will be added to the measured, actual value before sending it to the NB. The process of emulating network load changes may be done real time, by modifying the offset (default value: 0 Kb/s). To do it, starting from a shell with root privileges, run the executable <Simplicity root folder>/AppsForCnac/bwmonitor/src/ChangeShMem and follow the on screen instructions; please note that the bwmonitor executable must be already running.

• Terminal side:

o for the installation of the hostAP driver see the previous section ‘hostAP driver on each Access Point’;

o in the folder /etc/sysconfig/network-scripts/ create (or edit if present) the file ‘ifcfg-wlan0’ as follows:

DEVICE=wlan0

BOOTPROTO=static

IPADDR=141.250.40.61

NETMASK=255.255.255.0



NETWORK=141.250.40.0

BROADCAST=141.250.40.255

ONBOOT=yes

MII_NOT_SUPPORTED=yes

WIRELESS_ENC_KEY=""

WIRELESS_MODE=Managed

WIRELESS_ESSID=any

where IPADDR, NETMASK, NETWORK and BROADCAST depends on the network configuration;

o Wi-Fi manager on the TB: with root privileges simply run the exetubable <Simplicity root folder>/config/TerminalBroker/CnacConfig/WifiManager/wifimanager; no additional configuration is required;

o Web Surfing manager on the TB: run the shell script <Simplicity root folder>/config/TerminalBroker/CnacConfig/WebSurfManager/startProxy.sh; in addition configure the Mozzilla Firefox browser to use the HTTP proxy on 127.0.0.1: 51966 address and port;

o CNAC Subsystem on the TB: note that in order to launch the CNAC on the TB you must already have Wi-Fi manager and Web Surfing manager configured and running; provided this, the configuration parameters are read from the file <Simplicity root folder>/config/TerminalBroker/CnacConfig/cnac.conf whose content is reported in the following table:

# Configuration file for Enhanced Access Network on the TB

# AP selection: power criteria

pwOpt -45

pwMin -85

The pwOpt parameter is also changeable from the CNAC Application GUI (for further detail see section 8.5.5), whereas the pwMin parameter has to be set to the sensitivity of the wireless card (tipical value: -85 dBm);

• Others:



o D-ITG (Distributed Internet Traffic Generator): of this package we use the sink (ITGRecv) and the source (ITGSend); there are no special configuration to do, just launch ITGRecv executable on each AP and the ITGSend on the legacy terminal to generate CBR traffic with a command like this:

ITGSend –a <ip_address_of_sink> -c <pkt_size_in_bytes> -C <pkts_per_sec> -t <duration_in_ms>

For example:

ITGSend –a 141.250.40.33 -c 1024 -C 500 -t 60000

4.3.5.4 Configuration of CNAC on the NB

Below we list the parameters to be configured by the network administrator in order to en-able/manage the access network control functions. To configure these parameters the adminis-trator uses the CNAC Application GUI, a console in the PC hosting the NB. The figure below provides a screenshot of the console



Figure 14. Access network control console in NB

• List of managed APs: through the buttons ‘ADD AP’, ‘REMOVE AP’ ‘EDIT AP’ it is possible to respectively add, remove or edit an entry in the list of APs, specifying the ESSID, the Class, A (everyone) or B (restricted), and the IP address of the AP; the ‘used bandwidth’ (expressed in kbps) of each entry is periodically communicated, if available, by the CNAC on the NB to the GUI only after ‘APPLY’ button has been clicked;

• IP Address and PORT Number of the NB: these are the address and port on which the CNAC on the NB will listen to bandwidth data about the current load status from each AP in the list;

• BW Measurement Window: the length of the measurement window (range [0-240] seconds) used by the BW monitor module within APs to compute the average load;

• BW Update Period: the time period (range [0-240] seconds) with which APs send updated measurement data to the CNAC on the NB;

• Selection Period: the time period (range [0-240] seconds) with which the CNAC checks the distribution of terminals among APs;

• Bandwidth Thresholds (kbps): the values for bandwidth assume a different meaning depending on the class of the AP it is associated with. The Everyone threshold (LE) represents the traffic load value, for the everyone APs, over which student users are allowed to browse in limited mode only. The Restricted threshold (LR) represents the traffic load value, for the restricted APs, over which student users are not allowed to access the AP. In other words, we assume that there are two classes of APs. The former (class A) is open to everyone irrespective of its load status. If the load is above a threshold, students are allowed to browse in limited mode only. The latter (class B) is open to everyone only if its load status is below a prefixed limit. Beyond this value, students are not allowed to access APs of class B.

• Power Thresholds:

o PWmin (dBm): is the power value below which an AP is not considered a candidate to be selected as a target access to the network;

o PWopt (dBm): is the power value above which an AP is considered an optimal candidate to be selected as a target access to the network.

Whenever possible, the CNAC has to drive terminals towards the APs the power level of which is higher than PWopt. Power levels between PWmin and PWopt imply that the



terminal is in the border zone of an AP, and thus that it is in a precarious situation (the network connection can be lost even with a small movement).

• Hysteresis levels:

o BW (kbps): used by the CNAC on the NB in the bandwidth metric to avoid ping-pong effects (i.e., continuous switching of the terminal between APs with similar loads).

o PW (dBm): used by the CNAC on the NB in the power metric to avoid ping-pong effects, when a terminal is near the border zone (i.e., receives a power level around PWopt).

The buttons at the bottom of the GUI has the following functionality:

• ‘CLOSE’: closes the GUI;

• ‘APPLY’: applies the configuration parameters. The CNAC on the NB will be in charge of communicating the configuration parameters relevant to the BW monitor to each AP in the list. The configuration process of an AP can be successful or not; in this latter case, after a timeout of 15 seconds, a message box will appear with a list of APs not yet configured. Note that the Used Bandwidth field in the list of APs will be updated by the CNAC on the NB only after the ‘APPLY’ button has been clicked so to communicate to the CNAC on the NB the presence of the GUI;

• ‘SAVE’: saves the currently set configuration in the configuration file (<Simplicity root folder>/config/NetworkBroker/CnacConfig/cnac.conf) which is the file also used by CNAC on the NB and the CNAC Application in initialization phase;

• ‘LAST SAVED’: loads the last saved configuration from the configuration file.


The CNAC subsystems are involved in the following events in the Campus Network demo.


GetUserPrefEvent CNAC (TB) profile management

UserLoggedOutEvent SAIM CNAC (TB)

ReturnUserPrefEvent profile management CNAC (TB)

LoginCompleteEvent profile manager CNAC (TB)



GetUserPrefResultEvent profile manager CNAC (TB)

ConfirmConnectionReqEvent CNAC (TB) CNAC (NB)

ConfirmConnectionRespEvent CNAC (NB) CNAC (TB)

SelTriggerEvent CNAC (NB) CNAC (TB)

APSelReqEvent CNAC (TB) CNAC (NB)

APSelRespEvent CNAC (NB) CNAC (TB)

4.3.5.6 Test cases

To verify the results of the test cases, we need to use:

• iwconfig and iwlist utilities: these are part of the ‘wireless tools’ linux package and allow the interaction through the shell with the wireless card on the terminal.

• log files:

o NB_CN.log: the log file of the CNAC on the NB;

o AP.log: the log file of the BW Monitor module on each Access Point.

• Firefox web browser.

• GUI of the CNAC Application on the NB.

• GUI of the CNAC-TestFramework on the TB: this is a GUI developed only for testing purposes and which has a log window to inspect the ongoing tests.


CN1 Get Received Power Ensures that the Wi-Fi Manager is able to re-trieve the power received from the current AP

CN2 Get Network Context Ensures that the Wi-Fi Manager is able to re-trieve the Network Context, i.e. the essid and

received power of surrounding APs

CN3 Force AP selection Ensures that Wi-Fi Manager is able to drive the



802.11b of the terminal toward the wanted AP

CN4 Get Best Server Ensures that the Wi-Fi Manager is able to se-

lect the best AP based on the received power of surrounding APs

CN5 Get MAC Ensures that the Wi-Fi Manager is able to re-trieve the MAC of the 802.11b card of the ter-

minal

CN6 Set Web Surfing Mode Ensures that the Web Surfing Manager is able to set the requested web surfing mode

CN7 BW Monitoring Ensures that BW monitor is able to get the

value of the current used bandwidth on chang-ing load condition

CN8 Used BW Communication Ensures that the CNAC on the NB is able to receive BW data from APs

CN9 Get User Role Ensures that the CNAC is able to retrieve the

User Role in the Campus from the SDAM/Profile Mgmt

CN10 NB and APs Configuration Ensures that the NB and APs configuration op-tions are correctly set using the CNAC Appli-

cation GUI on the NB

CN1 AP Selection Ensures that the CNAC on the NB is able to

select correctly the best AP and the Web Surf-ing Mode

CN12 Check Connection Ensures that the terminal is able to reach the NB and verify the correct construction of the

‘TB list’ on the NB CNAC

CN13 AP Selection Trigger Ensures the correct delivery of the Events in-volved in the AP selection



Test Case CN1 Partners involved: RAL-PERUGIA

Name Get Received Power

Goal of the test Ensure that the Wi-Fi Manager is able to retrieve the power re-ceived from the current AP

Modules Wi-Fi Manager, CNAC-TestFramework


Scenario Description CNAC-TestFramework requests the power level of the signal re-ceived from the current AP

Call Flow

CNAC-TestFramework � Wi-Fi Manager

getRxPower


getRxPowerResp

Expected Results In the log window of the CNAC-TestFramework we can see the request and the response with a value of received power in dBm; checking with iwconfig we obtain compatible results.


Notes

Test Case CN2 Partners involved: RAL-Perugia

Name Get Network Context

Goal of the test Ensure that the Wi-Fi Manager is able to retrieve the Network Context, i.e. the essid and received power of surrounding APs





Scenario Description CNAC-TestFramework requests the Network Wireless Context in which the terminal is, i.e. the essid and power level of the sur-rounding APs

Call Flow


getNetworkContextData


getNetworkContextDataResp

Expected Results

In the log window of the CNAC-TestFramework we can see the request and the response with a list of surrounding APs each one showed with its:

- essid identifier

- received power level

checking with iwlist we obtain compatible results.


Notes


Name Force AP selection

Goal of the test Ensure that Wi-Fi Manager is able to drive the 802.11b of the ter-minal toward the wanted AP



Scenario Description CNAC-TestFramework drive the 802.11b card toward a chosen



AP.

Call Flow


setEssid


setEssidResp

Expected Results verifying with iwconfig it can be seen that the essid set in the wire-less card change accordingly


Notes


Name Get Best Server

Goal of the test Ensure that the Wi-Fi Manager is able to select the best AP based on the received power of surrounding APs



Scenario Description CNAC-TestFramework requests the essid of the AP from which it receives the higher power level among those present.

Call Flow


getBestServerEssid


getBestServerEssidResp

Expected Results The Essid obtained from the Wi-Fi Manager in the log window of the CNAC-TestFramework is the one from which the card receives



the strongest signal as can be verified using iwlist


Notes


Name Get MAC

Goal of the test Ensure that the Wi-Fi Manager is able to retrieve the MAC of the 802.11b card of the terminal



Scenario Description CNAC-TestFramework requests the MAC address of the wireless card

Call Flow


getNicMac


getNicMacResp

Expected Results In the log window of the CNAC-TestFramework is obtained the MAC address of the 802.11b card.


Notes


Name Set Web Surfing Mode



Goal of the test Ensure that the Web Surfing Manager is able to set the requested web surfing mode

Modules Web Surfing Manager, CNAC-TestFramework


Scenario Description CNAC-TestFramework requests to set a chosen web surfing mode

Call Flow


setFilteringStatus


setFilteringStatusResp

Expected Results

Initial condition: the user can browse the Internet using Firefox in the normal mode because the filtering is disabled.

CNAC-TestFramework requests to set the limited mode: in the next visited pages, elements such as images and flash animation are no more available in the browser

CNAC-TestFramework requests to set the normal mode: in the next visited pages, elements such as images and flash animation are again available in the browser


Notes


Name BW Monitoring

Goal of the test Ensure that BW monitor is able to get the value of the current used bandwidth on changing load condition

Modules BW Monitor




Scenario Description The BW monitor measure in real time the bandwidth used on the wireless interface of the AP

Call Flow

We use D-ITG software to vary the network load condition.

We use a legacy terminal as the source of the traffic and the AP as the sink.

Loading the network with CBR traffic through the wireless inter-face at some selected rate, the BW Monitor measures the used Bandwidth.

Expected Results The measured bandwidth is compatible with the CBR load at vari-ous selected rate.


Notes


Name Used BW Communication

Goal of the test Ensure that the CNAC on the NB is able to receive BW data from APs

Modules BW Monitor, CNAC on NB


Scenario Description The CNAC on the NB listen for bandwidth information from the APs

Call Flow BW monitor � CNAC on NB

sendToNB



Expected Results In the NB_CN.log file there are entries showing that CNAC sub-system receives bandwidth data from APs and the bandwidth value is compatible with that measured on the correspondent AP.


Notes

Test Case CN9 Partners involved: RAL-Perugia, RAL, LMU

Name Get User Role

Goal of the test Ensure that the CNAC is able to retrieve the User Role in the Campus from the SDAM/Profile Mgmt

Modules SD, SDAM/Profile Mgmt, SPA, CNAC-TestFramework


Scenario Description Using the SPA the user login and the CNAC-TestFramework re-quests the user role in the Campus to the Profile Mgmt.

Call Flow

The user log in using the SPA

CNAC-TestFramework receives the LoginCompleteEvent and then send to the ProfileMgmt the GetUserPrefEvent

The Profile Mgmt answers with the ReturnUserPrefEvent contain-ing the user role

Expected Results The log window of the CNAC-TestFramework shows a User Role compatible with that contained in the SD used.


Notes




Name NB and APs Configuration

Goal of the test Ensure that the NB and APs configuration options are correctly set using the CNAC Application GUI on the NB

Modules BW Monitor, CNAC on NB, CNAC Application


Scenario Description Using the CNAC Application GUI, we set the configuration pa-rameters relevant to CNAC on NB and the APs.

Call Flow

On receiving the configuration parameters from the CNAC Appli-cation, the CNAC on NB set its correspondent parameters accord-ingly, and calls the sendConfOptionsToAPs() method to configure the managed APs. The APs answer with a configurationConfirm message.

After this phase, CNAC on NB communicates to the CNAC Ap-plication the end of the configuration process with the (possibly empty)list of the APs where there was a problem.

Expected Results In the NB_CN.log and the AP.log files there are entries which show the reception of configuration messages. The set values are compatible with those specified in the CNAC Application GUI.


Notes


Name AP Selection

Goal of the test Ensure that the CNAC on the NB is able to select correctly the best



AP and the Web Surfing Mode

Modules CNAC-TestFramework, CNAC on NB


Scenario Description The CNAC-TestFramework requests the selection of an AP ac-cording a network context set in the request message using the same CNAC-TestFramework.

Call Flow

CNAC-TestFramework � CNAC on NB

APSelReqEvent

CNAC on NB � CNAC-TestFramework

APSelRespEvent

Expected Results In the log window of the CNAC-TestFramework is shown that the selection of the AP is done accordingly with the Network Context and the user role contained in the request message.


Notes


Name Check Connection

Goal of the test Ensure that the terminal is able to reach the NB and verify the cor-rect construction of the ‘TB list’ on the NB CNAC

Modules CNAC on NB, CNAC-TestFramework


Scenario Description Using the CNAC-TestFramework we send a message that requests the confirm of connectivity with the CNAC on NB



Call Flow


ConfirmConnectionReqEvent


ConfirmConnectionRespEvent

Expected Results

In the log window of the CNAC-TestFramework there are entries which show the request and the response message. In the NB_CN.log there are entries showing that the TB has been added to the ‘TB list’ and removed after a timeout if no more Confirm-ConnectionReqEvent are sent from the CNAC-TestFramework


Notes


Name AP Selection Trigger

Goal of the test Ensure the correct delivery of the Events involved in the AP selec-tion

Modules CNAC-TestFramework, CNAC on NB



Using the CNAC-TestFramework we send a message that requests the selection of an AP to the CNAC on NB; periodically the CNAC on the NB also requests the beginning of a selection phase to the TB

Call Flow


APSelReqEvent


APSelRespEvent



…

…


SelTriggerEvent

Expected Results In the log window of the CNAC-TestFramework there are entries which shows the correct call flow of the events.


Notes



References

[1] K. CHEVERST, N. DAVIES, K. MITCHELL, A. FRIDAY, C. EFSTRATIOU: Developing a Context-aware Electronic Tourist Guide: Some Issues and Experiences. Proc of CHI’ 00, Netherlands. 17-24 March 2000.



Appendix – List of hardware capabilities

This Appendix summarizes the hardware and software capabilities of all the PCs, laptops, Tablet PCs and other equipment used in the Simplicity demonstrator. Each PC, laptop etc. is labeled with an ID based on the scenario in which it participates

MMPC1:

Hardware Category Value Taxonomy Color True color (32 bit) High Display Pixel 1024 x 768 High

Audio - - - - - - Network interface(s)

Ethernet 10/100 Mb/s High Battery Power line No restriction

SD interfaces - - - CPU P4 1.3 GHz High

RAM 256 MB High Storage capacity HD 20 GB High

HID (I/O) Keyboard / mouse High

Software Category Value Taxonomy Operating System Linux RedHat 8.0 High Progr. language C++ High

MMPC2:


Audio - - - - - - Network interface(s)


SD interfaces - - - CPU P4 1.3 GHz High



Software Operating System Linux RedHat 8.0 High Java Environment J2SDK Sun 1.4.2.04 High Progr. language C++ / JAVA High



MMPC3:


Audio Stereo sound 2 channels Middle WLAN 802.11b Max. 11 Mb/s High Network interface(s)


SD interfaces Any device CPU P4 1.3 GHz High



Software Operating System Windows XP High Java environment J2SE V 1.4.2 High Progr. Language C++ High

MMPDA1:

Hardware Category Value Taxonomy Color 65.536 Middle Display Pixel 640 x 480 Middle

Audio Speaker 1 channel Low Network interface(s) WLAN 802.11B Max. 11 Mb/s High

Battery Li-Ion rechargeable 1650mAh

350h standby – 12h working

Middle

SD interfaces Bluetooth CPU Intel PXA272 520MHz Low Class

RAM 128 MB Middle Class Storage capacity ROM 64 MB Middle Class

HID (I/O) Touch screen Middle

Software Operating System Windows Mobile 2003 Middle Java Environment IBM J9 environment Version? Middle Progr. Language C++ High

MSPC1:




SD interfaces None required CPU Celeron 2.6 GHz High

Storage capacity RAM min. 256 MB High



HD 40 GB High HID (I/O) Keyboard / mouse High

Software Operating System Windows XP High Java environment J2SE V1.4.2 High

Web Container Tomcat V5.5 High Database mySQL V4.1 windows build High

MSPC2:




SD interfaces Java Card USB port High CPU P4 1.3 GHz High

RAM min. 256 MB High Storage capacity HD 20 GB High


Software Category Value Taxonomy Operating System Windows XP/2000 High Java Environment J2SE V 1.4.2 High

Application Mozilla Firefox browser Version 1.0.3 High Application Windows Media Player Version 10 High

Application (opt.) Video LAN Client Vlc-0.8.1 NA

TGPC1:


Audio N/A WLAN 802.11b max. 11 Mb/s High Network interface(s)

Ethernet 100 Mb/s High Battery Power line No restriction

SD interfaces CPU Intel Pentium M 1.3 GHz High



Software Category Value Taxonomy Operating System Windows XP/2000 High Progr. language J2SE High



TGPC2:

Hardware Category Value Taxonomy Colour Transflective TFT active matrix High Display Pixel 8.4" High

Audio Stereo sound Sound card, microphone and speakers can be connected

Middle

Integrated WLAN 802.11b/g. High Network interface(s) Integrated Ethernet max. 100Mb/s High

Lithium Ion n.a. Middle Power Power line (if demo in-

door) No restriction

CPU Intel Pentium M 1.2 GHz High DDR SDRAM - 333 MHz 512 MB / 1 GB (max) High Storage capacity

IDE Hard Disk max 60 GB High

HID (I/O) Digitizer, digital pen Middle

Software Category Value Taxonomy Operating System Windows Microsoft Windows XP Tablet PC

Edition High

Progr. language Java, C# Program runtimes for Tablet PC version

High

CNPC1/2:

Hardware Category Value Taxonomy Display n/a

Audio n/a Fast Ethernet 100 Mb/s High Network interface(s)

WLAN 802.11b Digicom palladio wave – chipset prism2 - firmware PRI 1.1.1, STA

1.7.4 with adapter PCI1410 PC card Card-bus Controller (TI) (yenta_socket driver)

11 Mb/s High

Power Power line No restriction High

CPU Intel® Pentium 3 700MHz Middle RAM 256 MB High Storage capacity HD 20 GB High

HID (I/O) Keyboard, mouse Middle

Software Category Value Taxonomy Operating System Linux kernel 2.6.3 with Wireless Exten-

sions, Vers. 16 by Jean Tourrilhes and with hostAP driver, Vers. 0.2.4

Mandrake 10 High



Progr. language C High Software for loading the

network (sink) D-ITG (Distributed Internet Traffic Genera-

tor), available at http://www.grid.unina.it/software/ITG/index.

php

High

CNPC3:

Hardware Category Value Taxonomy Display n/a

Audio n/a Ethernet 100 Mb/s High

WLAN 802.11b Digicom palladio wave – chipset prism2 - firmware PRI 1.1.1, STA

1.7.4

11 Mb/s High Network interface(s)

Bluetooth 1 Mb/s High Power line No restriction High Power

Removable battery 1.5-2 hours of autonomy

Medium

SD interfaces FSD (optionally Bluetooth + phone) CPU Athlon XP 2000+ High


HID (I/O) Keyboard/mouse Middle

Software Category Value Taxonomy Operating System Linux kernel 2.6.3 with Wireless Exten-

sions, Vers. 16 by Jean Tourrilhes and with hostAP driver, Vers. 0.2.4

Mandrake 10 High

Progr. language C, Java High Application Mozilla Firefox browser Version 1.0.3 High

CNPC4/5:

Hardware Category Value Taxonomy

Display n/a

Audio n/a Ethernet 100 Mb/s High Network interface(s)

WLAN 802.11b 11 Mb/s High Power line No restriction High

Power Removable battery 1.5-2 hours of autonomy Medium

CPU Pentium 3 1 GHz Middle RAM 256 MB High Storage capacity HD 20 GB High

HID (I/O) Keyboard/mouse Middle

Software Category Value Taxonomy Operating System Windows 2000 High



Programing language High

Software for loading the network (source)

D-ITG (Distributed Internet Traffic Gen-erator), available at

http://www.grid.unina.it/software/ITG/index.php

High

wpage.unina.itwpage.unina.it/pescape/cit/d4102-integration report.pdf · file name: simplicity...

Documents